グラフィカルなプログラミング言語ない？
■ このスレッドは過去ログ倉庫に格納されています
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そりゃ俺は典型的な日本人だから、こんな発想しかできんのは仕方ないだろ
じゃあ聞くが発想を転換すればいいアイデアが出るのか？
今まではどういう発想だったからダメで、どういう発想に切り替えればいいんだ？
0032デフォルトの名無しさん
2014/01/26(日) 13:52:36.44Q. 永久機関は作れないのか？
↓
A. 無理
↓
>>30
典型的な日本人的発想だな
これだから日本からGoogleグラスやiPhoneは生まれないんだ
0033デフォルトの名無しさん
2014/01/26(日) 13:55:15.19何も言えないならば、文句を言えば、
自分が何も言えないことをごまかせる。上から目線になれる。
0034デフォルトの名無しさん
2014/01/26(日) 14:10:43.87自分で考えろ
ここはお前の自己啓発スレじゃない
ところで
アルゴリズムをグラフィカルに実現するためには、基本的な制御文であるif、for、while、switchなんかはなるべく一種類のグラフィカルユニット？的な何かで表現できるべきだと思う
あとはそれらをつなげて行く形で組んで行けたらいいと思うんだけどどう？
0035デフォルトの名無しさん
2014/01/26(日) 14:11:50.24これお前だワロタｗ
とりあえず文句だけ言っとけばいい。
何も言えないならば、文句を言えば、
自分が何も言えないことをごまかせる。上から目線になれる。
0036デフォルトの名無しさん
2014/01/26(日) 14:13:36.34Scratchはそれができる
よかったな、理想のグラフィカルプログラミング言語だよ
新しく考える必要はない
0037デフォルトの名無しさん
2014/01/26(日) 14:13:53.70> if、for、while、switchなんかはなるべく一種類のグラフィカルユニット？的な何かで表現できるべきだと思う
だからそれがPADだって言ってるだろ。
お前、過去に語り尽くされたことを知らないで、
調べもしないで語るなよ。
お前、既存のものを何も知らんだろ？
そして既存のものを出したら文句言ってるだけだろ。
0038デフォルトの名無しさん
2014/01/26(日) 14:21:21.49場所をとるだけだろうな。
実際の所、グラフィカルユニットにしなくても
代わりにインデントと空行を使えば、十分視覚的になる。
0039デフォルトの名無しさん
2014/01/26(日) 14:26:24.98>>1 を嫁
「もうコーディングは嫌だ」だそうだ
0040デフォルトの名無しさん
2014/01/26(日) 14:30:37.98>>1 の望みは永遠に叶いそうにないな
0041デフォルトの名無しさん
2014/01/26(日) 14:33:52.73こんなん？
UnrealEngine3のUnrealKismet
シーケンス処理や状態遷移を視覚化
ttp://udn.epicgames.com/Three/KismetExamplesJP.html
ttp://udn.epicgames.com/Three/rsrc/Three/KismetExamples/ex_proc_normal.jpg
Automator
プログラミングできない人も作業を自動化できる
ttp://support.apple.com/kb/HT2488?viewlocale=ja_JP&locale=ja_JP
ttp://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT2488/HT2488_image05----ja.png
Simulink
プログラミングでは表現が難しい制御系を簡単に表現できる
ttp://www.mathworks.co.jp/products/simulink/
ttp://www.mathworks.co.jp/cmsimages/69963_wl_simcoder_fig1_wl.jpg
0042デフォルトの名無しさん
2014/01/26(日) 14:42:21.130043デフォルトの名無しさん
2014/01/26(日) 14:54:25.92作れる。
┌──────┐
│任意の文 │
└──────┘
基本的にこの罫線の形を変えればいいだけ。
あとはどんな関数であれ処理であれ
その説明をグラフィカルな図の中に書けば良い。
0044デフォルトの名無しさん
2014/01/26(日) 14:56:44.60視覚化ではなく、その図を書けば完成。
動作可能にならないとダメなんだってさ。
コーディング書きたくないわけだからそういうこと。
0045デフォルトの名無しさん
2014/01/26(日) 15:33:10.27でも大規模な開発には向いてなさそうだけどどうなんだろ
0046デフォルトの名無しさん
2014/01/26(日) 15:37:30.64コーディングを一切排除するのは難しいならあってもいいと思う
でもなくせるなら無くしてほしいって話
あと変数名もめんどうなので無くしてほしい
いちいち新しい変数作るたびに名前なんて考えてられんわ
どうにかならんもんかな
0047デフォルトの名無しさん
2014/01/26(日) 15:42:50.18コーディングというものを二つに分けて考えよう。
文字入力部分と処理部分。
処理部分は処理をなくせない以上どうあってもなくせない。
文字入力部分は代わりに、絵にしようが音声にしようが置き換え可能。
ただし面倒くさい。
嘘だと思うのなら、バラエティ番組を思い出せばいい。
一人が問題の答え（文字）を絵でかいて、もう一人がなんて文字か当てるというやつ。
0048デフォルトの名無しさん
2014/01/26(日) 15:44:38.58全部アドレスで指定するってこと？
それの管理が面倒だから変数名って概念があるんだが…
0049デフォルトの名無しさん
2014/01/26(日) 15:49:09.97お前の言ってるのは、「面倒くさい」んじゃなくて、
「出来ない」なんだよ。
コーディングすることが「できない」
適切な変数名をつけることが「できない」
単なる能力不足。
0050デフォルトの名無しさん
2014/01/26(日) 15:53:36.36例えば1から100までの合計を求める処理を
Excelを使って求めようとした場合殆どコーディングを必要としないし変数名も使わない
あれは広い意味でいうとある種のグラフィカルなプログラミングと言えると思う
ただ応用範囲は狭いから汎用性はないってだけで
0051デフォルトの名無しさん
2014/01/26(日) 15:56:40.430052デフォルトの名無しさん
2014/01/26(日) 16:02:16.28だからそれ、めんどくさいよね？
基本的に素人用の道具って
「プロ用の道具＋技術」に比べたら
面倒くさくて遅くて柔軟性がないんだよ。
たとえばプロの料理人だったら包丁でかつらむきを
高速にできるだろうね。でも素人だったら無理だし、
包丁渡されても技術がなければ遅い。
つまり君はまだ「プロ用の道具」しか渡されてなく
技術がないからそういう話をしてるんだよ。
0053デフォルトの名無しさん
2014/01/26(日) 16:08:34.69計算式を使わないで、1から100までの合計を出すコードを
愚直に書くならこんな感じか
var sum = 0;
for(var i = 1; i <= 100; i++) {
sum += i
}
これをエクセルで書くとしたら、1入力して、2入力して
1、2を選択してずずーっと引っ張ると3, 4, 5・・・と埋まっていくから
100の所で止めて、そしてセルを選択して、sumボタンを押す。
こんな感じかい？ 面倒くさすぎｗ
たぶんこの説明でわからない人もいるだろうね。
コーディングを必要としないが、面倒くさくなってるよね？
0054デフォルトの名無しさん
2014/01/26(日) 16:27:34.49プロ用の技術がめんどくさくて遅くて柔軟性がないならみんなC言語なんて使わないでアセンブリ使ってんじゃないか？
>>53
確かにExcelだとその操作がネックになるよな
なんとか新しいグラフィカル言語作ってできないものかな
まあ無理ならいいけど
0055デフォルトの名無しさん
2014/01/26(日) 16:32:11.550056デフォルトの名無しさん
2014/01/26(日) 16:32:43.15言語の違いは、ふさわしい適用範囲が違うだけ。
どれもプロ用。
0057デフォルトの名無しさん
2014/01/26(日) 16:34:48.31もう何年も前だけど
0058デフォルトの名無しさん
2014/01/26(日) 16:41:10.00・開発期間を大幅に短縮できる
・可読性が半端ない
・処理速度は遅くても気にしない
誰か作って
0059デフォルトの名無しさん
2014/01/26(日) 16:46:33.49どれもプロ用ってことはないでしょ
たとえばbrainfuckのプロとしてふさわしい適用範囲って何？
0060デフォルトの名無しさん
2014/01/26(日) 16:48:06.37批判するしか脳のないバカなんだから相手するなよ
0061デフォルトの名無しさん
2014/01/26(日) 16:59:51.600062デフォルトの名無しさん
2014/01/26(日) 17:04:19.87レベルが下がった事は考慮にいれないの？
0063デフォルトの名無しさん
2014/01/26(日) 17:06:26.75比較的グラフィカルではあるけど…ちょっと混みいった話になると
やっぱりシェルスクリプトやAppleScriptに頼ることになるんだよなぁ
0064デフォルトの名無しさん
2014/01/26(日) 17:13:07.05DSLとして割りきるなら、グラフィカルなプログラミングも現実的だと思うよ。
複雑な処理は専用モジュールとしてあらかじめ作り込んでおけばいい。
0065デフォルトの名無しさん
2014/01/26(日) 17:22:09.450066デフォルトの名無しさん
2014/01/26(日) 17:24:56.420067デフォルトの名無しさん
2014/01/26(日) 17:26:59.750068デフォルトの名無しさん
2014/01/26(日) 18:11:11.370069デフォルトの名無しさん
2014/01/26(日) 18:16:30.54本来の意味でのプログラマじゃないよな
事務屋さんがコンピュータ使ってるだけ
0070デフォルトの名無しさん
2014/01/26(日) 19:54:56.81brainfuckの話はしてないよ。
0071デフォルトの名無しさん
2014/01/26(日) 19:57:52.06ただしコードのグラフィック化（可視化）は意味がある。
だけど、それはコードの情報を減らして重要な部分のみを可視化するというもの
だから可視化されているものから、動くコードを作るのは不可能。
実際に動くレベルの情報をグラフィックにすると手間がかかる。
よってグラフィカルなプログラミング言語というのは
開発可能だが、効率が悪い。
まあこういう結論。
0072デフォルトの名無しさん
2014/01/26(日) 20:16:17.73そう思います。
自分は学生時代はBASIC・FORTRAN・Cを、就職した後は
汎用機を任されたので10年程COBOLをやりました。
特に、就職してからは色々なプログラマと仕事しましたが、
最近プログラマになった人は（キツイ言い方すれば）本来
プログラマになるべきでない様なプログラマに向いてない
人がプログラマになった感じの人が多い気がします。
色々理由はあるんでしょうが、長い不況でとりあえず職を
探したらそれしかなかったとか、流行でなったとか。
0073デフォルトの名無しさん
2014/01/26(日) 20:28:16.17隅から隅までグラフィカルじゃなくて
要点を絞ってここをグラフィカルに出来れば大幅に効率アップ！
ってのを探るのでなければ先に進みようが無い
ＧＵＩアプリのポトペタとか
ツクール系ゲーム開発のマップエディタとか
0074デフォルトの名無しさん
2014/01/26(日) 20:42:40.57だからそれがないんだよ。
グラフィカルってのは理解しやすくなるが、
文字に比べて情報量は減ってる。
見るときや理解するのにはいいけど
書くと効率は下がる。
だからコードを可視化するツールがあればいいのさ。
0075デフォルトの名無しさん
2014/01/26(日) 20:45:15.76■ このスレッドは過去ログ倉庫に格納されています