グラフィカルなプログラミング言語ない？
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2014/01/26(日) 02:49:36.10もっと新しいグラフィカル志向なプログラミング言語が欲しい
0002デフォルトの名無しさん
2014/01/26(日) 02:50:13.550003デフォルトの名無しさん
2014/01/26(日) 02:52:32.34じゃあ、1+1をグラフィカルに表現してみてくれ。
そっちのほうがもっと嫌になるぞ。
0004デフォルトの名無しさん
2014/01/26(日) 02:58:13.49アルゴリズムとかオブジェクト指向なデザインパターンをグラフィカルに表現できないものかと
0005デフォルトの名無しさん
2014/01/26(日) 03:08:02.1415年位前にPrographCPXという線を結んでいくだけでプログラミング出来るのがあったよ
0006デフォルトの名無しさん
2014/01/26(日) 08:32:29.850007デフォルトの名無しさん
2014/01/26(日) 08:34:02.95唯一まともに成功したグラフィカルプログラミング言語だぞ
0008デフォルトの名無しさん
2014/01/26(日) 10:25:59.22調べて見たけどこれ電子回路の制御限定じゃん
もっと汎用性のあるものがいいよ
0009デフォルトの名無しさん
2014/01/26(日) 10:39:02.830010デフォルトの名無しさん
2014/01/26(日) 10:54:23.960011デフォルトの名無しさん
2014/01/26(日) 11:06:03.69結局のところ、アプリを作るのにグラフィカルな方が分かりにくく面倒な部分が多いからだろうな。
プログラミングは大きく分けて何かを宣言する部分と、何かを制御（操作）する部分がある。
前者は静的な部分、後者は動的な部分とも言える。
宣言する部分というのは例えば OR マッピングとかシェーダーツリーなど。
こちらは確かにグラフィカル（図）で表現できる。
必要な情報を狭い空間に一度に表現できるから、その方が分かりやすい。
しかし、制御する部分はそうもいかないことの方が多いだろうな。
こちらは例えばアルゴリズムがそうだ。
アルゴリズムの入門書で擬似コードと一対一に対応した図が描かれたものは皆無だろ。
アプリの種類にも依るだろうが、たいていは宣言部分より制御部分の方が
大きな割合を占めるはずだ（今まで作ってきたアプリのソースを見なおしてみるといい）。
そういう意味では、純粋関数型言語のグラフィカル表現の方がまだ可能性が無くもないと思う。
0012デフォルトの名無しさん
2014/01/26(日) 11:09:43.060013デフォルトの名無しさん
2014/01/26(日) 11:17:35.92文字通り壮絶なスパゲッティになる
0014デフォルトの名無しさん
2014/01/26(日) 11:49:31.47・関数は外から見る時はできるだけマスキングして内容を表示しない
・関数には値の入出力の箇所をもたせる
・関数への引数や戻り値の受け渡しは入出力ポートからのコネクタ(線)で表現
こんな感じ？
0015デフォルトの名無しさん
2014/01/26(日) 12:01:26.36もう1分考えてみろ
コネクタ(線)だらけになるぞ
表示する際はマスキングして見やすくできるかもしれんが、
プログラミングする際はコネクタ(線)を繋ぐ操作が面倒になる
0016デフォルトの名無しさん
2014/01/26(日) 12:19:49.51関数定義の間を線で繋ぐということをしないで
別個に作れるようにしちゃうと、もうグラフィカルとは言えん
0017デフォルトの名無しさん
2014/01/26(日) 12:31:33.090018デフォルトの名無しさん
2014/01/26(日) 12:34:11.32ユニバーサルリソースロケーティングとマークアップ言語を用いたハイパーリンク技術と名づける
0019デフォルトの名無しさん
2014/01/26(日) 12:38:46.04markdownを使うのはなぜ？
0020デフォルトの名無しさん
2014/01/26(日) 12:46:38.68テキストよりも分かりやすく、プログラミングしやすく、という目的でグラフィカルにするのに、
コネクタ(線)を繋ぐ操作が面倒になるのを仕方ないで済ませたらいかんような気がする
グラフィカルにする目的が他にあれば、繋ぐ操作を犠牲にしてもいいかもしれんが
0021デフォルトの名無しさん
2014/01/26(日) 12:54:34.34グラフィカルなコネクタによる接続の問題は、
接続を簡単なコネクタでは表現できないんだよ。
プロトコルがどうであるとか型がどうであるとかインターフェースがどうであるとか。
ブラウザとウェブサーバーは一本の線で繋げられるだろうが、その中で行ってる処理は膨大。
そういった処理や情報をコネクタに加えないと単なる概要図にしかならず動く図にはならない。
動作可能な処理や・情報をコネクタに加えたら、すごく見づらくまた作るのに手間がかかるものになる。
実行可能なソースコード → 簡略化した図
は生成可能だが、
簡略化した図 → 実行可能なソースコード
ということ。
0022デフォルトの名無しさん
2014/01/26(日) 12:55:16.88は、無理ということ。
0023デフォルトの名無しさん
2014/01/26(日) 13:02:50.98どうせ関数の外からはマスキングされて見えないんだから複雑になることはない
それよりも基本的なアルゴリズムをグラフィカルにいかに実現するかが難しいな
For文一つとってもコーディングより簡単に表現する方法があればいいんだけど
0024デフォルトの名無しさん
2014/01/26(日) 13:17:05.13>関数は呼び出す都度に別個で設置するということでいいよ
グラフィカルというよりIDEのソースコードの色分けみたいなもんでしょそれ
普通の関数型言語になっちゃう
0025デフォルトの名無しさん
2014/01/26(日) 13:17:33.27> それよりも基本的なアルゴリズムをグラフィカルにいかに実現するかが難しいな
はい、それがフローチャートやPADと呼ばれるものです。
明らかに情報密度が低くく、面積あたりに記述できる
量が少ないので、書くのが大変になります。
0026デフォルトの名無しさん
2014/01/26(日) 13:23:10.88なぜ既存のもので代用しようとする
0027デフォルトの名無しさん
2014/01/26(日) 13:23:39.03他の関数呼ぶときにいちいち広大なキャンバスをスクロールしなくても
簡単に目的の関数にコネクタを接続できるようにエディタがサポートすればいい
トポロジーを全部表示するモードと特定の関数に注目するモードの切り替えも必要だな
0028デフォルトの名無しさん
2014/01/26(日) 13:33:53.54グラフィカルに変換すればいいんじゃね？ってて
発想になる。
それがDOT言語などである。
0029デフォルトの名無しさん
2014/01/26(日) 13:34:31.62Scratch だって本質的にはフローチャートを描いているのと何ら変わらんが、
あれで本格的なアプリを作ろうとは思わんだろ
計算手順を図式化するのにフローチャート以外の方法があるか？
俺は思いつかん。
もちろん、その図からちゃんとマシン語なり中間言語なりにコンパイルするか、
他言語に変換できなければならない。
0030デフォルトの名無しさん
2014/01/26(日) 13:39:38.35典型的な日本人的発想だな
これだから日本からGoogleグラスやiPhoneは生まれないんだ
0031デフォルトの名無しさん
2014/01/26(日) 13:48:06.94そりゃ俺は典型的な日本人だから、こんな発想しかできんのは仕方ないだろ
じゃあ聞くが発想を転換すればいいアイデアが出るのか？
今まではどういう発想だったからダメで、どういう発想に切り替えればいいんだ？
■ このスレッドは過去ログ倉庫に格納されています