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

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

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

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

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

2014/01/26(日) 16:08:34.69

>>50
計算式を使わないで、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

>>52
プロ用の技術がめんどくさくて遅くて柔軟性がないならみんなC言語なんて使わないでアセンブリ使ってんじゃないか？

>>53
確かにExcelだとその操作がネックになるよな
なんとか新しいグラフィカル言語作ってできないものかな
まあ無理ならいいけど

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

2014/01/26(日) 16:32:11.55

あげ

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

2014/01/26(日) 16:32:43.15

>>54
言語の違いは、ふさわしい適用範囲が違うだけ。
どれもプロ用。

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

2014/01/26(日) 16:34:48.31

yahoo pipes がそれっぽいなと思った記憶があるな
もう何年も前だけど

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

2014/01/26(日) 16:41:10.00

新しいグラフィカルプログラミングに求める要件
・開発期間を大幅に短縮できる
・可読性が半端ない
・処理速度は遅くても気にしない

誰か作って

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

2014/01/26(日) 16:46:33.49

>>56
どれもプロ用ってことはないでしょ
たとえばbrainfuckのプロとしてふさわしい適用範囲って何？

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

2014/01/26(日) 16:48:06.37

>>59
批判するしか脳のないバカなんだから相手するなよ

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

2014/01/26(日) 16:59:51.60

OSもCLIしか認めないんだろうか

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

2014/01/26(日) 17:04:19.87

グラフィカルなツールが出てからプログラマの
レベルが下がった事は考慮にいれないの？

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

2014/01/26(日) 17:06:26.75

MacOSXにAutomaterっていうのはある
比較的グラフィカルではあるけど…ちょっと混みいった話になると
やっぱりシェルスクリプトやAppleScriptに頼ることになるんだよなぁ

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

2014/01/26(日) 17:13:07.05

つカルネージハート

DSLとして割りきるなら、グラフィカルなプログラミングも現実的だと思うよ。
複雑な処理は専用モジュールとしてあらかじめ作り込んでおけばいい。

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

2014/01/26(日) 17:22:09.45

けどなんか結局複雑なパズルみたいになりそうな予感

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

2014/01/26(日) 17:24:56.42

結局操作方法が変わるだけで、コーディングには違いないだろうしな

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

2014/01/26(日) 17:26:59.75

>>1 がそういうDSLで我慢できるなら、これで完了だね

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

2014/01/26(日) 18:11:11.37

JP1/Scriptじゃダメなの？

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

2014/01/26(日) 18:16:30.54

>>62
本来の意味でのプログラマじゃないよな
事務屋さんがコンピュータ使ってるだけ

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

2014/01/26(日) 19:54:56.81

>>59
brainfuckの話はしてないよ。

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

2014/01/26(日) 19:57:52.06

グラフィックは文字よりも書くのに手間がかかる。
ただしコードのグラフィック化（可視化）は意味がある。
だけど、それはコードの情報を減らして重要な部分のみを可視化するというもの
だから可視化されているものから、動くコードを作るのは不可能。
実際に動くレベルの情報をグラフィックにすると手間がかかる。

よってグラフィカルなプログラミング言語というのは
開発可能だが、効率が悪い。

まあこういう結論。

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

2014/01/26(日) 20:16:17.73

>>69
そう思います。
自分は学生時代は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

おまえらツールたくさんあるのに知らないだけじゃねーの？

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

2014/01/26(日) 20:45:54.79

CADで書いてた回路図はほとんどが言語で記述されるようになった

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

2014/01/26(日) 20:46:03.90

>>75
そしてたくさん知ってる君が答えるわけだね。

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

2014/01/26(日) 20:51:35.63

>>1 によると、求められてるのは新しいグラフィカル志向だから、古いのじゃだめなんだよ

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

2014/01/26(日) 20:56:23.00

マジレスするとこの分野で最も成功しているのは普及率・完成度ともにFile Makerだと思うんだわ

プログラミングのぷの字も知らないような、おっさんが自分でかなり使いやすいツールを作ってたりする

ファイルメーカー社の仕事は、もっと評価されていい。自分じゃ使わないけど。

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

2014/01/26(日) 21:00:27.07

いや、そのFile Makerを作るプログラム言語を
グラフィカルにしたいって話でしょ？

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

2014/01/26(日) 21:11:17.20

Cに相当する部分をグラフィカルにしたいのか
そりゃ需要ないから無理じゃね

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

2014/01/26(日) 21:12:00.93

これこれこういう理由でこういうものが必要なんだという要件を明確にしてもらわんとね。
ドラえもん全部できるもの出してよって発想からは何も生まれない。

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

2014/01/26(日) 21:15:38.61

Javaはかなりグラフィカルなツールでてるじゃん？部分的とはいえね
そういうの組み合わせていったら、コード書く部分は相当減るんじゃね
１００％コードをなくしてしまうのは効率が悪くなると思う

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

2014/01/26(日) 21:18:56.05

>>82
> これこれこういう理由でこういうものが必要なんだという要件を明確にしてもらわんとね。

だから、何かがしたいんじゃなくて、
俺、コーディング書けない。書く技術力がない。
→ 書かなくていい方法ない？
って話なんだよ。

本質的には、技術力不足が原因なので
コードを他の何かに変えても、出来ないものは出来ないだろうね。

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

2014/01/26(日) 21:22:13.36

グラフィカルに表すことができる処理のコーディングなんて最近の言語使えば楽勝だろ

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

2014/01/26(日) 21:54:25.86

構文解析とは違う何か新しい革命が起こらない限り無理だな

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

2014/01/26(日) 21:59:16.47

全部できるもの出せって言われたらドラえもんはしょうがなく覚醒剤を出すかもしれない。

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

2014/01/26(日) 22:04:13.42

うーん
http://arashi50.cocolog-nifty.com/photos/uncategorized/2010/05/22/100522scratch_spiral.gif

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

2014/01/26(日) 22:12:42.81

グラフィカルの意味を教えてくれ

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

2014/01/26(日) 22:14:40.50

そういえば子供の頃夢想したなあ
レゴブロックに小さな機能をつけたようなパーツをいくつか用意しておいて
PCの画面でゲーム感覚でそれを組み立てるとどんな複雑なプログラムもかけるという空想

理屈の上で可能なのか不可能なのかよくわからんまま忘れてたらおっさんになってしまったな
まあ今思い出したから今でもよくわからん

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

2014/01/26(日) 22:16:55.19

>>90
似たようなのはあるよ
マインドストームで検索だ

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

2014/01/26(日) 22:20:15.83

>>91
おお、サンクス
名前は知ってるがあれってブロック組み合わせてロジック作成できるのだろうか？
PC上でコード書いてマイコンに送り込んで制御するものだと思っていた

出きるなら面白そうだな
ちょっと検索してみよう

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

2014/01/26(日) 22:21:21.64

>>88
それ前から思ってたんだが、テキストで書くのとの本質的な違いってどこにあるんだろ

単にアルファベットや単語の形がブロック状に変わって色がついただけのような気がする
やってることは「なでしこ」なんかと同じじゃないかな

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

2014/01/26(日) 22:23:36.42

むしろ文字だけの方が分かりやすい

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

2014/01/26(日) 22:24:10.58

本質的に同じでも、なんか楽しけりゃいいと思うよ。

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

2014/01/26(日) 22:24:40.30

>>92
ああ、ごめん
そういうのはできない
中心となるプロセッサとメモリと電気制御をするデカイパーツがあって、そこからケーブルを伸ばしてモーターやセンサーを使うってやつだ

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

2014/01/26(日) 22:27:54.36

>>96
ありがとう
今見てるんだがこれはこれでワクワクする感じだなあ

子供が出来たら買ってやろう
その前にパートナーを検索しないとだが・・・

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

2014/01/26(日) 22:31:32.38

例えばWin32APIでSendMessage(HWND,MSG,WPARAM,LPARAM)ってのがあるけど、
HWNDにウインドウハンドル書かずに矢印で対象ウインドウに線引っ張ったら分かりやすいし、
ウインドウハンドルとかいちいち書くかなくていいよね。
MSGもアイコンだと視認性が上がるよね。
WPARAMとLPARAMもどうせ何かの変数だよね。

そしたら、SendMessageって四角形にMSGのアイコン付けて、SendMessageって四角形の中のWPARAMとLPARAMには変数から矢印を引っ張って、
SendMessageって四角形から対象のウインドウに矢印引っ張るといいよね。

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

2014/01/26(日) 22:32:46.57

グラフィカルなプログラミングは
できるできないでいえば出来る。

ただし効率が悪いので使わない。

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

2014/01/26(日) 22:34:37.40

>>95
ごめん、Scratch はまさに「なんか楽しい」というのが第一の目的だからいいんだが、
たぶん >>1 の目的には合わないだろうなぁと思った。

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

2014/01/26(日) 22:35:21.81

>>99
効率は上がる
ソースはOSの操作

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

2014/01/26(日) 22:36:58.63

>>98
そのレベルで矢印を引くとなると、文字通りスパゲッティコードになるのが目に見える

デバッグやテストも描きにくいだろうし

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

2014/01/26(日) 22:38:31.26

unix派はコマンドラインに固執してコマンドラインの方がGUIより効率が良いという信念は今も変わらないじゃないのかい？

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

2014/01/26(日) 22:39:26.12

Flashなんかはタイムライン間にグィッとオブジェクトを動かせばスクリプト組まなくてもトゥイーンできたけど
条件によって動く方向やスピードを変えるというのになると途端に複雑なタイムラインを作る必要が発生して
結局ASで制御した方が楽でメンテナンス性も良かったりしたな

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

2014/01/26(日) 22:41:14.71

だから使い分けだろ
今は選択肢すら無いって話をしてるんだろ

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

2014/01/26(日) 22:42:43.70

使い分けもなにも結局複雑になるんだから
そもそも用途が無い

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

2014/01/26(日) 22:44:53.54

どこで使うんだよ

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

2014/01/26(日) 22:45:42.32

選択肢がないのはそれが使い物にならないからよ

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

2014/01/26(日) 22:47:02.82

選択肢が無いなら新しく作ればいいじゃない

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

2014/01/26(日) 22:48:02.69

今になっても出てこないってことは作る価値がないと判断されてるんだろ

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

2014/01/26(日) 22:52:46.34

>>110がこれから世に出回る全ての製品と全ての概念と全ての技術を否定しました。

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

2014/01/26(日) 22:53:29.16

馬鹿が楽してプログラミングしようとしても無理ってこったｗ

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

2014/01/26(日) 22:55:36.09

>>101
> ソースはOSの操作

今はOSの操作の話をしてるんじゃないよ。
プログラミングの話。

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

2014/01/26(日) 22:56:02.48

くんくん、権威主義に凝り固まった老害のニオイがする

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

2014/01/26(日) 22:58:01.80

まぁやっぱり
「馬鹿には無理」

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

2014/01/26(日) 22:59:20.37

ちょっと手続き型の概念から離れたら
ＧＵＩエディタもあるし
Flash、HTMLエディタ、
データベースエディタもある
UMLからコード生成したりもできる

プログラミングの役割はＧＵＩ付きツールに確実に侵食されている

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

2014/01/26(日) 22:59:34.08

>>105
プログラミングで一番多く実行する
関数の実行をどうグラフィックにするんだ？

たとえば、hoge(1234)を
グラフィックにするって話だよな？

今俺は、キーをたったの10回タイプして、
hoge(1234)って書いたわけだが、
これをグラフィックにして、手間を減らせると思う？

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

2014/01/26(日) 23:01:02.07

>>116
それって、一番重要な処理は
なにも作ってないんじゃね？

それで作ってるのはインターフェース部分だけでしょ？

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

2014/01/26(日) 23:07:59.00

本格的に3D空間にものを自在に表示できるようになったら、プログラミングの技法も若干変わるだろうよ

それまでは今と一緒だな

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

2014/01/26(日) 23:11:01.02

機能を可視化する方法は一通りではなく、より機能を正確かつ直感的に伝える可視化方法が求められる

コンピュータプログラミングは誕生してから時々刻々と新しいパラダイムが誕生しては消えを繰り替えし
未だ進化の途中にある

古くはシングルタスクのストレートフォワードなコードから始まり、関数や構造体による構造化、オブジェクト指向の台頭
GUIの一般化によるイベントドリブン型プログラミング、インターネットの普及によるウェブプログラミング
複数コアのCPUを効率的に使うためのコードの並列化、そのうちくるであろう量子コンピューティングなどなど
（適当に思いついたのを並べただけでグラフィカルプログラミングとの相性やそれぞれの概念の大小については何も考えてない）

おそらくどこかの時点でグラフィカルな言語を開発したとしても次の概念が来た際には大幅な修正や設計のし直しが求められる
PCの進歩、プログラミングの進歩が止まるまでは教育目的の簡単なものが出るに留まるんじゃあないか？

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

2014/01/26(日) 23:13:12.66

グラフィカルになったとしても、複雑な電子回路みたいな表示になりそう

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

2014/01/26(日) 23:15:26.82

複雑な電子回路は言語によるプログラミングで作られてるよ

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

2014/01/26(日) 23:21:35.72

>>50にあるような
Excelのアイデアを利用できないかな
改良を加えれば操作性はいくらでも改善できると思うし
基本的なアルゴリズムの構文なら再現できそうだよ

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

2014/01/26(日) 23:27:16.65

マインクラフトでチューリングマシンが作れるらしいからやろうと思えば何でも作れるんじゃね？
そのままでは開発効率も可読性も論外だがw
http://www.youtube.com/watch?v=kBDNzMqgJiM

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

2014/01/26(日) 23:31:00.07

>>123
1から100までの合計をExcelで出そうとすると
面倒くさいんだけど、これじゃ使いものにならないでしょ？

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

2014/01/26(日) 23:33:34.97

実行中のプログラムのメモリ配置をてグラフィカルに描画するツールないの?

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

2014/01/26(日) 23:36:02.43

insightあたりはUIがウンコだから論外

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

2014/01/26(日) 23:37:55.74

>>126
> 実行中のプログラムのメモリ配置をてグラフィカルに描画するツールないの?

デバッガ

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

2014/01/26(日) 23:38:49.77

>>125
Excelをつかうんじゃなくて
新しいコーディング手法に応用できないかと言ってるんだよ

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

2014/01/26(日) 23:39:48.92

>>128
デバッガの描画と操作性でイケてるものって？

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

2014/01/26(日) 23:41:07.92

Excelは関数型言語だぞ

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

2014/01/26(日) 23:41:44.00

>>129
だからなんで、面倒な方法を使おうとするんだよ？
文字のほうが少ない労力でできるだろうが。
視覚化が便利なのは、全体の概略、設計を把握するときだけだよ。

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

2014/01/26(日) 23:44:20.02

>>132
表計算に関してはプログラミングするよりExcel使った方が効率いいんだが

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

2014/01/26(日) 23:46:18.06

>>133
俺も写真にフィルター処理をする際にはプログラミングするよりもフォトショップ使った方が効率いいと思うぜ

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

2014/01/26(日) 23:46:48.05

書くときだけを考えるから面倒なんだ。
実行時のフローを追ったり、排他制御や並行プログラミング、
リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良い

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

2014/01/26(日) 23:47:33.73

>>133
たとえば？

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

2014/01/26(日) 23:48:22.86

>>134
> 俺も写真にフィルター処理をする際には

そのフィルター処理を作る場合の話でしょ？

あんたが言ってるのは単に画像に作ったフィルタを適用してるだけじゃん。

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

2014/01/26(日) 23:48:39.52

効率求めてマクロにするのはプログラミングだよね

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

2014/01/26(日) 23:49:17.11

>>135
訂正しておくね。

×リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良い
○リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良いと思っているが、根拠も無いし証明もできない。悔しい！

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

2014/01/26(日) 23:49:49.60

>>138
そのマクロって文字だよね？

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

2014/01/26(日) 23:51:00.20

学研の電子ブロックでグラフィカルプログラミング！

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

2014/01/26(日) 23:52:37.27

>>136
横レスするが、
Excel(もしくは相当する表計算ソフト)が存在しない世界を想像してごらん
表計算ソフトが無かった1970年代、誰もが表計算が必要になるたび、
BASIC、PASCAL、COBOLなどでいちいちプログラムを組んでいた

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

2014/01/26(日) 23:53:01.53

>>139
断固拒否する

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

2014/01/26(日) 23:53:10.52

カプセル化した内部をグラフィカルには難しそうだな
結局ここは文字で組むしかなさそう

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

2014/01/26(日) 23:54:16.89

>>144
ツール側で見せなきゃ良いだけだろ

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

2014/01/26(日) 23:54:33.15

>>137
表計算ソフトにはセル同士の値を計算する処理があらかじめ作られてるんでしょ？

あんたが言ってるのは単に打ち込んだ数字にその処理を適用してるだけじゃん。

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

2014/01/26(日) 23:56:08.33

>>145
見せる見せないじゃなく、プログラミングするのに必要な部品をどう作るかということ
これが無いと完成しない場合はどうなる？
グラフィカルが無理な箇所だから組むしかねぇだろ
なんかずっとずれた回答してるよなお前

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

2014/01/26(日) 23:57:16.15

>>147
おまえ、Smalltalkとかしらない入門者だろ

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

2014/01/27(月) 00:00:33.16

>>142
なんの話してるんだ？

ExcelがExcelで作られてるというのならわかるが、
処理の部分はグラフィックに作る理由がないんだよ。
開発効率が悪いから。

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

2014/01/27(月) 00:01:04.80

>>142
は？

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

2014/01/27(月) 00:02:03.36

>>141
それ意外に面白いかもな。組上がったロジックをPCにセーブできると。
いや～楽しそうです。

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

2014/01/27(月) 00:03:35.20

プログラミングでもエクセルでもどっちでもできることを
エクセルでやる人ってのは、
単にプログラミング技術がないからだよ。

文字で書いたほうが早いが
そもそもそれが出来ない人は
ツールを使うしかあるまい。

ようするに>>1は自分の技術力がないから
それ以外の方法を探しているだけ。
それが非効率なものであっても、
プログラミングが出来ないから、どうしようもあるまい。