1001コメント342KB

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

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

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

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

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

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

かもね

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
大学の教授は大体絵に書いて説明してるぞ

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