1001コメント342KB

グラフィカルなプログラミング言語ない？

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2014/01/26(日) 02:49:36.10

もうコーディングは嫌だ
もっと新しいグラフィカル志向なプログラミング言語が欲しい

0159デフォルトの名無しさん

2014/01/27(月) 00:07:42.93

処理の順番を文字で書くのも、絵で描くのも本質的には変わらないと思うんだが…
キーボードを打つよりもマウスを動かす方が手間が多いというだけで

0160デフォルトの名無しさん

2014/01/27(月) 00:08:43.27

ただの老眼だろ

0161デフォルトの名無しさん

2014/01/27(月) 00:11:25.91

>>158
Smalltalkライクな環境を作り、公開してはじめて、そのレスは意味を持つ

0162デフォルトの名無しさん

2014/01/27(月) 00:14:09.19

emacsなんかと比べるとVSはかなりグラフィカルだ

0163デフォルトの名無しさん

2014/01/27(月) 00:14:41.31

SmalltalkといえばSqueakなんてものもあったな
これをベースに拡張していけばいいもの出来んじゃね？

0164デフォルトの名無しさん

2014/01/27(月) 00:15:21.14

素人レベルの作業だと、どう考えてもemacsの方がはやい

0165デフォルトの名無しさん

2014/01/27(月) 00:18:39.55

>>163
やってみろよ。死ねクズ

0166デフォルトの名無しさん

2014/01/27(月) 00:23:13.94

UMLから派生させるのは無理？

0167デフォルトの名無しさん

2014/01/27(月) 00:44:34.02

>>166
ありだと思う
あとはもう少し細かいアルゴリズムの表現力をつけたいが

0168デフォルトの名無しさん

2014/01/27(月) 01:06:56.28

>>167
死ねゴミ虫

0169デフォルトの名無しさん

2014/01/27(月) 01:09:34.32

スレチで申し訳ないんだけど、
グラフィカルな開発環境より、全ての言語の中間のような言語が欲しいかな。
それそのものは実行もコンパイルもできなくていいから、好きな言語にエクスポートできるやつ。
言語間の相互変換は試みられてるけど、完全ではないし、できないものもある。
だから最初から変換する前提で設計された、仮に「XXX言語」とでも呼ぼうか、があるといい。
言語が違うってだけで一度書いたアルゴリズムをまた書くのはうんざりだ。

XXX言語は好きな言語にエクスポートしてから使うが、開発者はXXXの文法を学ばなければならない以外は今まで通り開発できる。
C言語でコンパイルしたいのなら、コンパイラのパスを通しておけばエクスポートからコンパイルまで自動でやってくれる。
JavaScriptへだろうがJavaへだろうがボタン一発でエクスポート。

0170デフォルトの名無しさん

2014/01/27(月) 01:12:03.07

haxe

0171デフォルトの名無しさん

2014/01/27(月) 01:14:16.08

>>153
> じゃあ開発効率のいいグラフィカルプログラミング言語を作ればいいじゃん

ないよ。っていうかグラフィカルプログラミングの定義上、
グラフィカルでなければならないよね？

文字も絵と考えれば、グラフィックなんだ。あとはそこに載せられる情報量の話。
緻密で複雑なグラフィックである文字の方が情報量が多いのは言うまでもない。

まあドット単位で正確に絵を書くというのならば、文字よりも多くの
情報量を入れられるだろうさ。大変すぎる作業になるのは明らかだけど。

それで「あ」という文字をキーで入力するのとこれを絵として
マウスでもペンでもいいけど書くのはどっちが時間がかかるかい？
結局のところ、こういう話。文字のほうが早く入力できるんだよ。

0172デフォルトの名無しさん

2014/01/27(月) 01:16:30.22

>169
前に同じアイデア、２ちゃんねるに書いたな。
スレ立てた気もする。

0173デフォルトの名無しさん

2014/01/27(月) 01:18:07.80

.netもparrotも失敗したよ
この世界では規格なんてものは大嘘で、実際に手に入る実装こそが真実
デファクトな中間言語のようなものがjavascriptだとしたら、
javascriptで書いた方がはやいって考えるような世界

0174デフォルトの名無しさん

2014/01/27(月) 01:19:37.07

>>171
死ねゴミクズ。おまえなんて、この世界に生まれてくるべきじゃなかった

0175デフォルトの名無しさん

2014/01/27(月) 01:22:03.13

>>171
グラフィカルだからってキーボードを一切使わないという訳ではないだろ

百歩譲って効率が少し劣ったとしても
視認性や再利用のしやすさの面で優ってたら利用する価値はあると思うけどな

0176デフォルトの名無しさん

2014/01/27(月) 01:26:50.53

>>173
JavaScriptいいよね。なんて言ったらいいかよくわからないけど、
JavaScriptはとても外部の環境に影響されない言語なんだ。

例を出すとC言語。実はC言語にはディレクトリという概念がない。
それはディレクトリがないOSもあるわけで、C言語標準には含めなかった。
他の言語には標準的に搭載されているスレッドとかネットワークアクセスとかも。

JavaScriptはそれよりも更に進んで、ファイルアクセスというものすら存在しない。
CPUだけで処理できるような計算処理だけに制限された言語なんだ。
もちろん外部ライブラリを使うことで計算以外もできるけどね。

0177デフォルトの名無しさん

2014/01/27(月) 01:28:15.33

>>175
> 視認性や再利用のしやすさの面で優ってたら利用する価値はあると思うけどな

視認性ならコードを視覚化すれば良い。
再利用のしやすさは、コードで書いても同じ。

0178デフォルトの名無しさん

2014/01/27(月) 01:31:07.67

>>176
ブラウザ上でだけの話だろ。死ねカス

0179デフォルトの名無しさん

2014/01/27(月) 01:32:26.66

ブラウザ上ですら互換性ないのにバカじゃねーの

0180デフォルトの名無しさん

2014/01/27(月) 01:38:44.31

>>178
今は普通にコンソールで実行できる。

>>179
互換性問題は複数の実装があれば
どの言語にも存在する問題。

何に反論にもなってない。

0181デフォルトの名無しさん

2014/01/27(月) 01:45:10.13

>>177
コードは視覚化しづらいだろ

0182デフォルトの名無しさん

2014/01/27(月) 02:32:18.91

>>181
コードをそのまま視覚化するんじゃなくて
コードの構造を視覚化するんだよ。

どこがどう繋がっているとか。
でもそれは元のコードのつながりだけを抽出したもの
到底動くレベルにはならない。

0183デフォルトの名無しさん

2014/01/27(月) 02:48:17.80

ここまでMELなし

LabViewと並んで一度使ってみたい言語だった

0184デフォルトの名無しさん

2014/01/27(月) 02:54:07.75

>>72
一時期、職安ではプログラマを勧めていたし
そういう職業訓練を受けると特典をもらえた時期があった

0185デフォルトの名無しさん

2014/01/27(月) 02:57:53.08

関数型言語限定の話になるけど、構造というか、効率化と可視化はもうちょっとしたいね。
プログラミングつったら関数をいっぱい書いていくけど、自分で書いた関数一覧がIEのお気に入りみたいに右側にアルファベット順に自動で表示されて、
クリックするとキャレットのところに自動で挿入される感じとか。
あとはコードの特定の部分を関数化しようとおもってコピペしたら、自動でその部分の変数が宣言されて関数名の入力ポップアップが出るとか。
宣言したクラスや構造体変数を書いたらすぐ横にメンバ一覧が出るとか。
お気に入り一覧以外に履歴一覧もあって、他のコードで使ったコードの関数もそこに出てすぐ使えるとか。
それがさらにオンライン対応になって、企業や特定のコミュニティ内で再利用できるとか。
もちろんヘッダまで遡って自動インクルード、自作のヘッダでもインクルードする。

0186デフォルトの名無しさん

2014/01/27(月) 03:03:51.60

関数型言語限定の話っていうからなにかと思ったら、
関数型言語でできる話じゃなくて、
静的型付け言語なら普通にできることが
できてないから、関数型言語限定の話って言ったのか。

0187デフォルトの名無しさん

2014/01/27(月) 03:07:00.37

え？
頭の中にはC言語があった。
C言語使うことが多いからC言語でそうやって組めたらいいなという妄想だ。

0188デフォルトの名無しさん

2014/01/27(月) 03:21:12.22

ちゃんとしたIDE使いなよ。
関数のリストは表示されるし、
クラス・構造体は、.や->を書いたらリストが表示されるし、
コードの特定の範囲を関数にするって、
それIDEに備わっているリファクタリングツールの機能の一つじゃないか。

0189デフォルトの名無しさん

2014/01/27(月) 03:30:02.52

>>180
node.jsなんて今日日じゃ常識レベルなのに、
javascriptにはファイルハンドラがとか、おまえバカだろ

0190デフォルトの名無しさん

2014/01/27(月) 03:31:15.10

>>180
中間言語への反論だよ。死ねよクズ

0191デフォルトの名無しさん

2014/01/27(月) 04:14:32.20

>>189
JavaScriptにファイルハンドラないよ。
nodeはJavaScriptという言語仕様の一部じゃないからね。

0192デフォルトの名無しさん

2014/01/27(月) 11:19:11.70

>>171
ペンで書いた「あ」が一文字で何種類の情報を表現出来ると思う？

0193デフォルトの名無しさん

2014/01/27(月) 11:23:50.03

上の方の関数を線で繋ぐ話がすごく興味ある。
線がゴチャゴチャするだろとか批判あったけど、ネスト・階層(gui風に言うならレイヤー)があれば良いだけの話で
それが上階層に行けば最終的にはフローチャートになる、なってなきゃおかしい

で、ギターのコンパクトエフェクター繋ぐ感じとか、DTMのミックスダウンソフトみたいにデータの流れと関数(エフェクター)をgui管理出来たらメチャ楽だと思うんだよね

0194デフォルトの名無しさん

2014/01/27(月) 11:52:30.19

アイディアのある人は是非作ってくれ。

0195デフォルトの名無しさん

2014/01/27(月) 13:36:56.50

どれも使いにくい
それよりuml描くだけでコードに変換してくれるツールの方が良い

0196デフォルトの名無しさん

2014/01/27(月) 14:55:44.66

>>191
言語仕様にファイルハンドラって意味が分かりません
例えばJavaやC#の言語仕様にファイルハンドラってものはあるんですか？

0197デフォルトの名無しさん

2014/01/27(月) 18:34:27.04

>>193
関数を呼び出すたびに関数を定義している場所までコネクタを引っ張るなんて発想は
なにかしら図面をみたことがあるなら出てこないはずだよな。
ICや機能ブロックを組み合わせた回路図で、図面の端っこにICの定義が書いてあって
そのICを使うたびにそこまで線を引くとか、そんなことはありえない。そこは名前参照するだろ

グラフィカルのいいところは一次元の文字列ではなく二次元に自由に並べられるところだとおもう。
条件分岐が複雑になったときや、関数に渡す引数の前処理が多段になったときに
どこからきた値がどの分岐、あるいはどの関数のどの引数に影響するのかということを
単なるインデントではなく二次元に配置すると見通しやすくならないか？
ワイドモニタ向きだともおもうんだけどな

0198デフォルトの名無しさん

2014/01/27(月) 18:42:54.49

あつかうデータ型が描画要素とか音形とか限られていると比較的作りやすいんだよね
多様なデータ型があって、処理も多様だと、とたんに処理系を作るのが面倒になる
気がする
一度作ろうとしたことはあるけど面倒になったw
なにが面倒って使えるライブラリをそろえるのが面倒くさい
Win/Macの標準GUIやDBアダプタが標準化されてるLLがあれば核にするんだけど
・・・と妄想してもう10年近く放置してたりするww

0199デフォルトの名無しさん

2014/01/27(月) 18:54:50.24

ここに書いとくと誰か作ってくれそうだから昔考えたアイデアを書いとく。
グラフィカルにするとレイヤーを扱えるようになる。もちろんテキストでもできるんだけど。

たとえばデバッグコードやトレースポイント(プローブ)を通常のレイヤーに重ねて垂直に結線する
処理前後の値の相関図をデバッグレイヤーにグラフィカルに表示したり、ログを取ったあと、
不要になればデバッグレイヤーを切り離せば通常動作する回路になる
元のコードを読むときははデバッグレイヤーを不可視にすると本来のコードを読みやすい
中間データをシグナルインジェクター的に流し込んでもいいとおもう

デバッグじゃなくてもちょっと試しに改変したりパッチを当てるときにも
元のコードがまるまるそのまま下のレイヤーに残っているというのが便利

0200デフォルトの名無しさん

2014/01/27(月) 19:00:23.66

どんなプログラム言語で書いても
最適化の前にはデータ構造としての「グラフ」に分解されて実行されるんだから
最初からグラフィカルに書けばいいとおもうのん。

0201デフォルトの名無しさん

2014/01/27(月) 19:10:03.68

頭のいい人には関係ないことだけどコネクタを使うと中間変数を省略できるから
数字の逆唱を5個とか7個しかできない凡人にはグラフィカルにするメリットがある

かもね

0202デフォルトの名無しさん

2014/01/27(月) 22:38:17.78

vimやSublime Textなどの高機能エディタが
IDEより生産性が高くなってしまったので、
IDE復権のためにグラフィカルな言語の登場が待ち望まれるね

0203デフォルトの名無しさん

2014/01/27(月) 23:23:01.75

いきなり大規模なもんはできないだろうから
とりあえず小規模な基本的なアルゴリズムが組めるものを考えてみよう

0204デフォルトの名無しさん

2014/01/27(月) 23:50:19.69

>>193
線をつなぐのはいいんだが、それをグラフィックでやる意味が無いだろ。

関数A → 関数B

ほら、関数を線でつなぐことが出来た。

0205デフォルトの名無しさん

2014/01/27(月) 23:56:23.46

ループはどう書く？

0206デフォルトの名無しさん

2014/01/28(火) 00:01:16.90

>>205
for(i in data) {
　hoge(i)
}

これを絵で書いたら分かりやすくなる書い？
あたりまえだけど、iとかdataとかhoge(i)といった
情報を捨ててはいけない。

0207デフォルトの名無しさん

2014/01/28(火) 00:08:03.68

値を全部リストにする

0208デフォルトの名無しさん

2014/01/28(火) 00:21:08.35

>>206

i→data→hoge

はいできた
解釈は各自好きなようにやってくれ

0209デフォルトの名無しさん

2014/01/28(火) 00:23:05.96

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

0210デフォルトの名無しさん

2014/01/28(火) 01:01:04.78

J言語をグラフィカルにしてください

0211デフォルトの名無しさん

2014/01/28(火) 01:06:49.10

>>206 だと
→ for
しか書けないよね。線の中身がdataで、後はforの下のレイヤーになる。

入り口と出口があってそれぞれに意味を付けられるようなのじゃないとあんま使いではないのかも

file1 →↓
file2 → [ diff ] → stdout

こんなのだったら使いやすそう。ファイルの結線を変えて比較したり[diff]にツマミが付いてて、それを回すと出力形式変えられたり。出力線を足して差分取ったり。それをまた[diff]に結線したり。

0212デフォルトの名無しさん

2014/01/28(火) 01:13:15.87

csv
↓
[ awk ]
↓→ column1
↓→ column2
↓→ column3 → [ sed ] → ‥

こういうのとかも

0213デフォルトの名無しさん

2014/01/28(火) 02:30:16.72

コードを図で書くのって難しいな。

0214デフォルトの名無しさん

2014/01/28(火) 02:45:05.83

図ってのは、頭のなかに描く分には自由だが、
PC上で扱うとなると、位置と大きさがあるせいで
意外と抽象化の役に立たない気がするよ。
つーか邪魔になるレベル。有り難みがない。

0215デフォルトの名無しさん

2014/01/28(火) 08:16:46.62

むしろ抽象化度が低くて凡人にもわかやすい

0216デフォルトの名無しさん

2014/01/28(火) 08:36:29.23

現代人が世界共通で使っている数式はオイラーからニュートンまでのそうそうたる天才達が一般化したもんだから
凡人の浅知恵じゃ超えられないよ。

0217デフォルトの名無しさん

2014/01/28(火) 08:52:28.17

ライプニッツによって定義された関数を初めてy=f(x)の形で表したのもオイラーである。
wikipediaより

0218デフォルトの名無しさん

2014/01/28(火) 09:39:12.15

既存の構文をいかにグラフィカルにするかという考え方だと新しいもんはできないな
要は問題をいかに解決するかが重要なんだから
例えば簡単なアルゴリズムの問題集なんかから問題を見つけてきてそれをいかにグラフィカルな手法で解決するかを模索してみた方がよっぽど発展性あるかも

0219デフォルトの名無しさん

2014/01/28(火) 10:45:14.41

簡単な数式や小さな構文は文字で書いてあったほうが理解しやすいけど
関係する要素が増えてくるとグラフィカルにしたくなる
構造が簡単で入出力いずれかの数が多い>>211-212あたりがグラフィカルに向いているとおもう

並列に並ぶ要素が増えるくらいなら束ねることで閲覧性を保てるけど
構造が網目状に入り組んできたら数式でも図形でもどちらでも難読になるね

0220デフォルトの名無しさん

2014/01/28(火) 15:55:56.89

自分は汎用機のプログラマ（コボラー）なんで、
便利な開発ツールなんて殆どありません。
汎用機からCOBOLのソースをftpで取り込んで
テキストファイルにして秀丸などで修正とか。

だから、汎用機以外で使われているPC系の
ツールを見ると結構羨ましい。
edit画面で、ifと打ち込んだらすぐ下にend-ifと
表示されるたりするツールを見た時はびびりました。

0221デフォルトの名無しさん

2014/01/28(火) 20:03:31.85

>>218 >>219
ファインマンダイアグラムなんて例として良いかもな

0222デフォルトの名無しさん

2014/01/28(火) 20:49:55.31

>>219
> 関係する要素が増えてくるとグラフィカルにしたくなる

正確に言うと、グラフィカルに ”見たくなる” でしょ？

グラフィカルなプログラミング言語は
書いたものがそのまま実行可能にならなきゃいけないけど、
実行可能なレベルまで書き込むと、画像では場所とりすぎで逆にわからなくなるよ。

0223デフォルトの名無しさん

2014/01/28(火) 20:52:44.85

>>219
> 構造が簡単で入出力いずれかの数が多い>>211-212あたりがグラフィカルに向いているとおもう

>>211-212は文字で書いているんだが・・・。

0224デフォルトの名無しさん

2014/01/28(火) 21:52:28.06

>>222
わかりにくくなる、で済ますのではなく
いかにすれば使いやすくなるか考えるのが真の開発者だ

0225デフォルトの名無しさん

2014/01/28(火) 22:05:20.62

>>211,212,223
スレタイのグラフィカル言語(視覚的言語)からは外れた話題だとは思うけど、
EmacsによるCUIベースのリアクティブ・プログラムという観点であれば
「編集=計算」パラダイム(Computing-As-Editing Paradigm、CAEP)に
関連があるかもしれない
・編集=計算パラダイムと例によるプログラミング
　　http://ci.nii.ac.jp/naid/110002929606
・「計算=編集」パラダイムに基づく例からのプログラミング
　　http://ci.nii.ac.jp/naid/110003743922

GUIベースの視覚化言語/計算環境であれば提案や製品は数多くあるけど、
CUIベースってのは、あまり注目されない話題だね

0226デフォルトの名無しさん

2014/01/28(火) 22:40:54.03

>>224
> いかにすれば使いやすくなるか考えるのが真の開発者だ

じゃあお前が考えろよｗ

文字というのは特定の形のグラフィックを
使いやすいように定めたもの。

象形文字という絵から文字が生まれた。

そもそもグラフィックをいかにすれば使いやすくなるかを
考えた結果、文字になったわけで、話がおかしいんだよ。

0227デフォルトの名無しさん

2014/01/28(火) 22:43:21.10

「リンゴ」って三文字書くのと
リンゴの絵を書くのと、
どちらがわかりやすいかという問題だな。

0228デフォルトの名無しさん

2014/01/28(火) 22:45:30.77

色つきでないとリンゴと梨の区別がつかないな

0229デフォルトの名無しさん

2014/01/28(火) 22:48:21.72

>>228
色つけりゃいいじゃん

0230デフォルトの名無しさん

2014/01/28(火) 22:49:55.51

「赤いリンゴ」を表現するために
何秒で出来るか競争してみようぜ？

0231デフォルトの名無しさん

2014/01/28(火) 22:52:18.11

おーっと、ここで青リンゴの登場だー

0232デフォルトの名無しさん

2014/01/28(火) 22:59:15.25

文字って凄いよな。
たったの数回キーを叩くだけで
表現できてしまう。

これを図で書く？
アホだろｗ

0233デフォルトの名無しさん

2014/01/28(火) 23:00:30.51

class ringo{
iro=COLOR_RED;//色（赤）
omosa=300;//重さ（グラム）
suibun=95;//水分（パーセント）
　amasa=15;//糖度（度）
}

ね、文字だと簡単でしょ？

0234デフォルトの名無しさん

2014/01/28(火) 23:02:17.49

リンゴみたいに具体的な形があるやつなら
まだグラフィックにするメリットがわかるんだが。

ソート処理をグラフィックにするとして
どんな形になるんだ？

バブルソート、クイックソート、シェルソート
この違いをどうやってグラフィックにするんだろうか。

文字の周りを罫線で囲むだけじゃなんの意味も無いよ。

そう、コードっていうのはグラフィックにできないんだ。

0235デフォルトの名無しさん

2014/01/28(火) 23:03:17.92

>>232
3文字だと文字でも困らないな

でも小説と漫画を比較すると断然漫画の方が視認性高い

0236デフォルトの名無しさん

2014/01/28(火) 23:05:26.25

>>234
大学の教授は大体絵に書いて説明してるぞ

0237デフォルトの名無しさん

2014/01/28(火) 23:07:52.91

>>236
その絵は概略でしかないだろ？

0238デフォルトの名無しさん

2014/01/28(火) 23:08:40.09

色は良いよね。アイコンに近いのかも。
ディレクトリが用途とかで色分け出来たら良いのになあと思った事が何度もある。

それとディレクトリだったら、単に時系列でソート出来るだけじゃなくて、例えば使用頻度の高いファイルやディレクトリは大きく、そうじゃないのは小さく表示するとか便利だと思う。
あと平面のウィンドウが実は立方体で、ディレクトリ一覧をグルっと横に回すと中身が見れたり、タグ付けされた奥行きの情報が見れたりとか、一杯やりたい事ある。
技術が追いつけばねぇ…

0239デフォルトの名無しさん

2014/01/28(火) 23:09:43.96

>>238はちょっとプログラムとずれたか。スマソ

0240デフォルトの名無しさん

2014/01/28(火) 23:11:25.72

>>235
> でも小説と漫画を比較すると断然漫画の方が視認性高い
だが書くのに時間がかかるだろ？

コードを視覚化するのには意味があるんだよ。
だけどその視覚化されたものには、コードの全ては含まれていない。
もしコードの全てを含ませようとすると、それは巨大になり
そして作るのにもかなりの時間がかかる。

だから視覚化されたコードは、コードの一部の特徴を表したに過ぎない。
それは実際に動くプログラミングにはなりえない。
（不可能ではないが時間がかかりすぎるため、教育用として小さいコードを書くのが精一杯）

0241デフォルトの名無しさん

2014/01/28(火) 23:13:45.03

ぶっちゃけていえば、
絵っていうのは、馬鹿に説明するためにある。

小説とマンガの関係も同じ。

0242デフォルトの名無しさん

2014/01/28(火) 23:27:21.13

＞もしコードの全てを含ませようとすると、それは巨大になり
＞そして作るのにもかなりの時間がかかる

そのためにコンピュータがあるんだろ
人間は指示をするだけ
コンピュータは指示を受けてルールを構築していくだけ

出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
ただ文字だと見にくく、絵だと見やすいというだけの話

0243デフォルトの名無しさん

2014/01/28(火) 23:31:01.23

>>234
『大人のピタゴラスイッチ』でクイックソートを動画にしてたぜ

0244デフォルトの名無しさん

2014/01/28(火) 23:42:50.59

プログラムの視覚的全体像をみたい余り文字を通常の1/10に小さくしている人居たけど
文字の形がほとんど判別できないのなw
視力に頼りすぎているそいつはプログラマとしての寿命は短いだろうなと思った。

0245デフォルトの名無しさん

2014/01/28(火) 23:50:30.53

目が悪くなったら画面を大きくすればいい

0246デフォルトの名無しさん

2014/01/28(火) 23:52:19.20

>>242
ドコが見やすいのか、
バブルソートを絵にして説明してくれ。
もちろん、動かないとダメだぞ？

0247デフォルトの名無しさん

2014/01/28(火) 23:57:53.16

　 ━━━━━━━
in　→┃バブルソート┃→ out
━━━━━━━

0248デフォルトの名無しさん

2014/01/28(火) 23:58:41.88

>>247
バブルソートって
文字でかいてるなｗ

結局、文字が一番適切に説明できるんだよｗ

0249デフォルトの名無しさん

2014/01/29(水) 00:02:58.22

バブルスライムの画像を使えばどうだろう。著作権違反かな。

0250デフォルトの名無しさん

2014/01/29(水) 00:03:36.44

>>248
勝手に文字禁止なルールにするなw
グラフィカルなOSにも文字は使われてるんだぞ

0251デフォルトの名無しさん

2014/01/29(水) 00:03:40.05

バブルスライムの画像で
バブルソートが実装できるのか？

0252デフォルトの名無しさん

2014/01/29(水) 00:04:29.15

>>250
いや、だって>>247って別に罫線いらないじゃんｗ

文字だけで十分なのに、
それを絵にする意味ってなんだよ？ｗ

0253デフォルトの名無しさん

2014/01/29(水) 00:07:10.36

いやバブルスライムをクリックすると胃袋が２つに分かれて再帰的に反芻してソートして排泄するのがわかるとか。

0254デフォルトの名無しさん

2014/01/29(水) 00:10:16.81

グラフィカルに表現する利点は複数の要素の関係性が表現しやすいという点だろうな
でも関係性が増えると線が多すぎて逆に見にくくなってしまうというジレンマが・・

0255デフォルトの名無しさん

2014/01/29(水) 00:22:29.04

構造化プログラミングのせいだな

0256デフォルトの名無しさん

2014/01/29(水) 10:20:49.00

文字はグラフィックの一部だ、グラフィカル言語は文字を使ってもいい
むし抽象度や粒度を適切に制御するために文字の混在は推奨されるだろう

0257デフォルトの名無しさん

2014/01/29(水) 10:31:08.17

現実の問題で関係性が複雑すぎてグラフにするとわからなくなるようなものはあるのだろうか

0258デフォルトの名無しさん

2014/01/29(水) 10:38:56.45

コードの複雑性を隠すために条件分岐文を折りたたむという方法があるけど
あれって全体の構造をみて必要なところだけ折りたたまない実装はあるのだろうか
現実的にはファイルを分割するという形でプログラマのコントロール下に置くことになるのかな

グラフで表現するときはこういった折り畳みはその図面の中で行われるのだろうか
ダブルクリックすると機能ブロックが開いて詳細実装をみることができるとか
ズームするとグーグル地図のように詳細図に切り替わるとか

■ このスレッドは過去ログ倉庫に格納されています