1001コメント342KB

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

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

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

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

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

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

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

2014/01/27(月) 00:04:11.46

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

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

2014/01/27(月) 00:05:31.79

処理の部品が膨大にないと出来るものが限られるんじゃね？
シンプルな処理の組み合わせをするなら結局はコード書くのと同じ位グチャグチャなグラフィックになるだろうし

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

2014/01/27(月) 00:05:40.23

>>149
それって、単純な処理だけエディタから書けるようにして、
グラフィカルなUI部分では隠蔽しとけば良いだけちゃうん？

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

2014/01/27(月) 00:06:21.36

そもそもラピュタだってブロックから出来てたんだぜ。宮崎駿の先見性と直観力は信じられる。

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

2014/01/27(月) 00:06:51.56

>>156
死ねよカス

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

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

>>152
1だけど正直コーディング歴は20年のベテランです
Webアプリでもゲームでも何から何までなんでも作れます

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個しかできない凡人にはグラフィカルにするメリットがある

かもね

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