1001コメント342KB

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

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

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

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

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

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

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

2014/01/28(火) 23:07:52.91

>>236
その絵は概略でしかないだろ？

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

2014/01/28(火) 23:08:40.09

色は良いよね。アイコンに近いのかも。
ディレクトリが用途とかで色分け出来たら良いのになあと思った事が何度もある。

それとディレクトリだったら、単に時系列でソート出来るだけじゃなくて、例えば使用頻度の高いファイルやディレクトリは大きく、そうじゃないのは小さく表示するとか便利だと思う。
あと平面のウィンドウが実は立方体で、ディレクトリ一覧をグルっと横に回すと中身が見れたり、タグ付けされた奥行きの情報が見れたりとか、一杯やりたい事ある。
技術が追いつけばねぇ…

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

2014/01/28(火) 23:09:43.96

>>238はちょっとプログラムとずれたか。スマソ

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

2014/01/28(火) 23:11:25.72

>>235
> でも小説と漫画を比較すると断然漫画の方が視認性高い
だが書くのに時間がかかるだろ？

コードを視覚化するのには意味があるんだよ。
だけどその視覚化されたものには、コードの全ては含まれていない。
もしコードの全てを含ませようとすると、それは巨大になり
そして作るのにもかなりの時間がかかる。

だから視覚化されたコードは、コードの一部の特徴を表したに過ぎない。
それは実際に動くプログラミングにはなりえない。
（不可能ではないが時間がかかりすぎるため、教育用として小さいコードを書くのが精一杯）

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

2014/01/28(火) 23:13:45.03

ぶっちゃけていえば、
絵っていうのは、馬鹿に説明するためにある。

小説とマンガの関係も同じ。

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

2014/01/28(火) 23:27:21.13

＞もしコードの全てを含ませようとすると、それは巨大になり
＞そして作るのにもかなりの時間がかかる

そのためにコンピュータがあるんだろ
人間は指示をするだけ
コンピュータは指示を受けてルールを構築していくだけ

出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
ただ文字だと見にくく、絵だと見やすいというだけの話

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

2014/01/28(火) 23:31:01.23

>>234
『大人のピタゴラスイッチ』でクイックソートを動画にしてたぜ

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

2014/01/28(火) 23:42:50.59

プログラムの視覚的全体像をみたい余り文字を通常の1/10に小さくしている人居たけど
文字の形がほとんど判別できないのなw
視力に頼りすぎているそいつはプログラマとしての寿命は短いだろうなと思った。

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

2014/01/28(火) 23:50:30.53

目が悪くなったら画面を大きくすればいい

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

2014/01/28(火) 23:52:19.20

>>242
ドコが見やすいのか、
バブルソートを絵にして説明してくれ。
もちろん、動かないとダメだぞ？

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

2014/01/28(火) 23:57:53.16

　 ━━━━━━━
in　→┃バブルソート┃→ out
━━━━━━━

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

2014/01/28(火) 23:58:41.88

>>247
バブルソートって
文字でかいてるなｗ

結局、文字が一番適切に説明できるんだよｗ

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

2014/01/29(水) 00:02:58.22

バブルスライムの画像を使えばどうだろう。著作権違反かな。

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

2014/01/29(水) 00:03:36.44

>>248
勝手に文字禁止なルールにするなw
グラフィカルなOSにも文字は使われてるんだぞ

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

2014/01/29(水) 00:03:40.05

バブルスライムの画像で
バブルソートが実装できるのか？

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

2014/01/29(水) 00:04:29.15

>>250
いや、だって>>247って別に罫線いらないじゃんｗ

文字だけで十分なのに、
それを絵にする意味ってなんだよ？ｗ

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

2014/01/29(水) 00:07:10.36

いやバブルスライムをクリックすると胃袋が２つに分かれて再帰的に反芻してソートして排泄するのがわかるとか。

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

2014/01/29(水) 00:10:16.81

グラフィカルに表現する利点は複数の要素の関係性が表現しやすいという点だろうな
でも関係性が増えると線が多すぎて逆に見にくくなってしまうというジレンマが・・

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

2014/01/29(水) 00:22:29.04

構造化プログラミングのせいだな

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

2014/01/29(水) 10:20:49.00

文字はグラフィックの一部だ、グラフィカル言語は文字を使ってもいい
むし抽象度や粒度を適切に制御するために文字の混在は推奨されるだろう

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

2014/01/29(水) 10:31:08.17

現実の問題で関係性が複雑すぎてグラフにするとわからなくなるようなものはあるのだろうか

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

2014/01/29(水) 10:38:56.45

コードの複雑性を隠すために条件分岐文を折りたたむという方法があるけど
あれって全体の構造をみて必要なところだけ折りたたまない実装はあるのだろうか
現実的にはファイルを分割するという形でプログラマのコントロール下に置くことになるのかな

グラフで表現するときはこういった折り畳みはその図面の中で行われるのだろうか
ダブルクリックすると機能ブロックが開いて詳細実装をみることができるとか
ズームするとグーグル地図のように詳細図に切り替わるとか

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

2014/01/29(水) 16:46:31.19

>>7
LabViewでプログラム書いてみ。
あっという間に使う気が失せるから。

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

2014/01/29(水) 20:10:31.82

>>193
データの流れをGUIでプログラムできる環境はたくさんある。

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

2014/01/29(水) 21:27:14.72

このスレがなんか一番ソフト工学してるな

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

2014/01/29(水) 22:41:53.33

グラフなら、コードの中のある変数や引数に注目して
その祖先や子孫をあぶり出し表示するのは簡単だな
テキストで同じことをするにはどうするんだろう？

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

2014/01/29(水) 23:45:37.48

>>262
何か勘違いしてそうだから言っておくけど、

コード（文字）をグラフィックに視覚化するのはいいんだよ。
これが見やすい（場合がある）ことは否定していない。

ただしコード（文字）を書かずに、最初からペンかマウスかで
画像を書いてプログラミングするのは効率が悪いという話

コードの一部（例：変数に着目して視覚化）をグラフ化するのは
何も問題がないが、最初からグラフを書くことでプログラミングなんかしたら
大変きわまりないだろ？

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

2014/01/30(木) 01:55:26.85

流れは矢印で書くほうがわかりやすくてはやいよ
詳細はコーディング

JP1/Script形式が最強だろ
もうちょい言語側がパワフルになってほしいけどな

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

2014/01/30(木) 08:34:21.58

アルゴリズムもグラフィカルにしたほうが効率いいだろ

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

2014/01/30(木) 18:49:13.28

今のままでも十分視覚化されてると思うが

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

2014/01/30(木) 22:01:37.35

比較する対象がないからだろ
ガラパゴス携帯しかない時代の人間がガラパゴス携帯が一番使いやすいと考えてるようなもんだ

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

2014/01/30(木) 22:16:48.76

だれか僕にもできるの作ってどらえもんってこと？

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

2014/01/30(木) 22:19:48.33

>>268
もっと作業効率あげれる未来の道具出してよドラえもんってことだよ

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

2014/01/30(木) 22:38:46.38

ま、タブレットとかスマホでプログラム作れる環境は欲しい。

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

2014/01/30(木) 22:46:21.88

AndroidもiOSもCのコンパイラとかPythonとかあるだろ

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

2014/01/30(木) 23:45:53.37

キーボードを見捨てた時点からあなたは無能である。

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

2014/01/31(金) 00:08:06.22

落書き見たいにプログラミングできたら楽しいだろうな

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

2014/01/31(金) 00:11:38.33

>>269
効率を上げるために絵から文字が生まれたのに、
絵に効率を求めるなんて愚かだな。
絵は見るのにはいいが描くのは大変だ。

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

2014/01/31(金) 00:28:16.99

>>274
なんでそんなに文字だけにこだわるんだ？
文字自体もグラフィカルな表現の一種なんだが
何か不都合でもあるのか？

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

2014/01/31(金) 00:29:25.24

見る側からすれば、文字だけの文より図や絵が入ったほうが
見やすいのは明らか

その図や絵を自分で書くという発想さえ抜かせば
文字よりも図や絵でまとめあげたほうが楽という感じだろうな

まぁ、出来るもんなら作ってみろって感じ

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

2014/01/31(金) 00:46:14.64

そのためにコンピュータがあるんだろ
人間は指示をするだけ
コンピュータは指示を受けてルールを構築していくだけ

出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
ただ文字だと見にくく、絵だと見やすいというだけの話

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

2014/01/31(金) 01:05:05.63

>>275
なにか不都合がって、
最初からプログラミングを
画像でやるのは不都合だって言ってるじゃん。

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

2014/01/31(金) 01:06:41.12

１００種類のオブジェクトがあるとして、
文字なら１００種類の識別子をつけられるけど
１００種類の絵で識別するのは困難。
絵だと見やすいのは幼稚なオモチャに限られる。

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

2014/01/31(金) 01:07:52.60

>>277
> 出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
> ただ文字だと見にくく、絵だと見やすいというだけの話

いやいやｗ支持を絵でやるのが難しい（時間的に）って話だろｗ
紙芝居で作業指示書を書いてみ？

なんなら、競争でもするか？

三回まわってワンと言う。

これを絵で指示してみ？
労力はどれくらい違うよ？

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

2014/01/31(金) 01:09:41.02

>>279
絵だと100種類のアイコンですむな
ドラッグアンドドロップで使用できるから楽だ

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

2014/01/31(金) 01:10:29.88

１００種類作るのがめんどくさくて微妙な違いがわからないって言ってるんだが。

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