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

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
もうコーディングは嫌だ
もっと新しいグラフィカル志向なプログラミング言語が欲しい
2デフォルトの名無しさん:2014/01/26(日) 02:50:13.55
Age
3デフォルトの名無しさん:2014/01/26(日) 02:52:32.34
そうか?

じゃあ、1+1をグラフィカルに表現してみてくれ。

そっちのほうがもっと嫌になるぞ。
4デフォルトの名無しさん:2014/01/26(日) 02:58:13.49
1+1はそのままでいいんじゃね?
アルゴリズムとかオブジェクト指向なデザインパターンをグラフィカルに表現できないものかと
5デフォルトの名無しさん:2014/01/26(日) 03:08:02.14
>>1
15年位前にPrographCPXという線を結んでいくだけでプログラミング出来るのがあったよ
6デフォルトの名無しさん:2014/01/26(日) 08:32:29.85
バナッコペ「ロンーwwwwwwwwwwww」
7デフォルトの名無しさん:2014/01/26(日) 08:34:02.95
LabViewだろ
唯一まともに成功したグラフィカルプログラミング言語だぞ
8デフォルトの名無しさん:2014/01/26(日) 10:25:59.22
>>7
調べて見たけどこれ電子回路の制御限定じゃん
もっと汎用性のあるものがいいよ
9デフォルトの名無しさん:2014/01/26(日) 10:39:02.83
DSLとGUIでRADをENJOYするスレだろ
10デフォルトの名無しさん:2014/01/26(日) 10:54:23.96
マインクラフト
11デフォルトの名無しさん:2014/01/26(日) 11:06:03.69
教育用以外で汎用的なグラフィカルプログラミング言語が成功した事例は聞かないな。
結局のところ、アプリを作るのにグラフィカルな方が分かりにくく面倒な部分が多いからだろうな。

プログラミングは大きく分けて何かを宣言する部分と、何かを制御(操作)する部分がある。
前者は静的な部分、後者は動的な部分とも言える。

宣言する部分というのは例えば OR マッピングとかシェーダーツリーなど。
こちらは確かにグラフィカル(図)で表現できる。
必要な情報を狭い空間に一度に表現できるから、その方が分かりやすい。

しかし、制御する部分はそうもいかないことの方が多いだろうな。
こちらは例えばアルゴリズムがそうだ。
アルゴリズムの入門書で擬似コードと一対一に対応した図が描かれたものは皆無だろ。

アプリの種類にも依るだろうが、たいていは宣言部分より制御部分の方が
大きな割合を占めるはずだ(今まで作ってきたアプリのソースを見なおしてみるといい)。

そういう意味では、純粋関数型言語のグラフィカル表現の方がまだ可能性が無くもないと思う。
12デフォルトの名無しさん:2014/01/26(日) 11:09:43.06
関数型のグラフィカル表現ってどんなんだろう。フラクタルみたいになるのかな?
13デフォルトの名無しさん:2014/01/26(日) 11:17:35.92
LabViewは手続きや時間経過も表現できるけど
文字通り壮絶なスパゲッティになる
14デフォルトの名無しさん:2014/01/26(日) 11:49:31.47
3分間考えてみた
・関数は外から見る時はできるだけマスキングして内容を表示しない
・関数には値の入出力の箇所をもたせる
・関数への引数や戻り値の受け渡しは入出力ポートからのコネクタ(線)で表現

こんな感じ?
15デフォルトの名無しさん:2014/01/26(日) 12:01:26.36
>>14
もう1分考えてみろ

コネクタ(線)だらけになるぞ
表示する際はマスキングして見やすくできるかもしれんが、
プログラミングする際はコネクタ(線)を繋ぐ操作が面倒になる
16デフォルトの名無しさん:2014/01/26(日) 12:19:49.51
それは仕方ないだろ
関数定義の間を線で繋ぐということをしないで
別個に作れるようにしちゃうと、もうグラフィカルとは言えん
17デフォルトの名無しさん:2014/01/26(日) 12:31:33.09
この図はブルートゥース技術によりワイヤレス接続されています
18デフォルトの名無しさん:2014/01/26(日) 12:34:11.32
テキストだけで情報と情報のリンクを記述する画期的な技術を思いついた
ユニバーサルリソースロケーティングとマークアップ言語を用いたハイパーリンク技術と名づける
19デフォルトの名無しさん:2014/01/26(日) 12:38:46.04
ワープロソフトで書けばいいのに
markdownを使うのはなぜ?
20デフォルトの名無しさん:2014/01/26(日) 12:46:38.68
>>16
テキストよりも分かりやすく、プログラミングしやすく、という目的でグラフィカルにするのに、
コネクタ(線)を繋ぐ操作が面倒になるのを仕方ないで済ませたらいかんような気がする

グラフィカルにする目的が他にあれば、繋ぐ操作を犠牲にしてもいいかもしれんが
21デフォルトの名無しさん:2014/01/26(日) 12:54:34.34
視覚化するのであれば、ソースコードからUML図でもなんでも生成すればいい。

グラフィカルなコネクタによる接続の問題は、
接続を簡単なコネクタでは表現できないんだよ。

プロトコルがどうであるとか型がどうであるとかインターフェースがどうであるとか。
ブラウザとウェブサーバーは一本の線で繋げられるだろうが、その中で行ってる処理は膨大。
そういった処理や情報をコネクタに加えないと単なる概要図にしかならず動く図にはならない。
動作可能な処理や・情報をコネクタに加えたら、すごく見づらくまた作るのに手間がかかるものになる。

  実行可能なソースコード → 簡略化した図

は生成可能だが、

  簡略化した図 → 実行可能なソースコード

ということ。
22デフォルトの名無しさん:2014/01/26(日) 12:55:16.88
  簡略化した図 → 実行可能なソースコード

は、無理ということ。
23デフォルトの名無しさん:2014/01/26(日) 13:02:50.98
関数は呼び出す都度に別個で設置するということでいいよ
どうせ関数の外からはマスキングされて見えないんだから複雑になることはない

それよりも基本的なアルゴリズムをグラフィカルにいかに実現するかが難しいな
For文一つとってもコーディングより簡単に表現する方法があればいいんだけど
24デフォルトの名無しさん:2014/01/26(日) 13:17:05.13
>>23
>関数は呼び出す都度に別個で設置するということでいいよ
グラフィカルというよりIDEのソースコードの色分けみたいなもんでしょそれ
普通の関数型言語になっちゃう
25デフォルトの名無しさん:2014/01/26(日) 13:17:33.27
>>23
> それよりも基本的なアルゴリズムをグラフィカルにいかに実現するかが難しいな

はい、それがフローチャートやPADと呼ばれるものです。

明らかに情報密度が低くく、面積あたりに記述できる
量が少ないので、書くのが大変になります。
26デフォルトの名無しさん:2014/01/26(日) 13:23:10.88
>>25
なぜ既存のもので代用しようとする
27デフォルトの名無しさん:2014/01/26(日) 13:23:39.03
グラフィカル言語はエディタを含めて考えないとな
他の関数呼ぶときにいちいち広大なキャンバスをスクロールしなくても
簡単に目的の関数にコネクタを接続できるようにエディタがサポートすればいい
トポロジーを全部表示するモードと特定の関数に注目するモードの切り替えも必要だな
28デフォルトの名無しさん:2014/01/26(日) 13:33:53.54
そしてそのうち、全部テキストで書いて
グラフィカルに変換すればいいんじゃね?ってて
発想になる。

それがDOT言語などである。
29デフォルトの名無しさん:2014/01/26(日) 13:34:31.62
>>26
Scratch だって本質的にはフローチャートを描いているのと何ら変わらんが、
あれで本格的なアプリを作ろうとは思わんだろ

計算手順を図式化するのにフローチャート以外の方法があるか?
俺は思いつかん。

もちろん、その図からちゃんとマシン語なり中間言語なりにコンパイルするか、
他言語に変換できなければならない。
30デフォルトの名無しさん:2014/01/26(日) 13:39:38.35
>>29
典型的な日本人的発想だな
これだから日本からGoogleグラスやiPhoneは生まれないんだ
31デフォルトの名無しさん:2014/01/26(日) 13:48:06.94
>>30
そりゃ俺は典型的な日本人だから、こんな発想しかできんのは仕方ないだろ

じゃあ聞くが発想を転換すればいいアイデアが出るのか?

今まではどういう発想だったからダメで、どういう発想に切り替えればいいんだ?
32デフォルトの名無しさん:2014/01/26(日) 13:52:36.44
この流れwwww

Q. 永久機関は作れないのか?

  ↓

A. 無理

  ↓

>>30
典型的な日本人的発想だな
これだから日本からGoogleグラスやiPhoneは生まれないんだ
33デフォルトの名無しさん:2014/01/26(日) 13:55:15.19
とりあえず文句だけ言っとけばいい。
何も言えないならば、文句を言えば、
自分が何も言えないことをごまかせる。上から目線になれる。
34デフォルトの名無しさん:2014/01/26(日) 14:10:43.87
>>31
自分で考えろ
ここはお前の自己啓発スレじゃない

ところで
アルゴリズムをグラフィカルに実現するためには、基本的な制御文であるif、for、while、switchなんかはなるべく一種類のグラフィカルユニット?的な何かで表現できるべきだと思う
あとはそれらをつなげて行く形で組んで行けたらいいと思うんだけどどう?
35デフォルトの名無しさん:2014/01/26(日) 14:11:50.24
>>34
これお前だワロタw

とりあえず文句だけ言っとけばいい。
何も言えないならば、文句を言えば、
自分が何も言えないことをごまかせる。上から目線になれる。
36デフォルトの名無しさん:2014/01/26(日) 14:13:36.34
>>34
Scratchはそれができる

よかったな、理想のグラフィカルプログラミング言語だよ
新しく考える必要はない
37デフォルトの名無しさん:2014/01/26(日) 14:13:53.70
>>34

> if、for、while、switchなんかはなるべく一種類のグラフィカルユニット?的な何かで表現できるべきだと思う

だからそれがPADだって言ってるだろ。

お前、過去に語り尽くされたことを知らないで、
調べもしないで語るなよ。

お前、既存のものを何も知らんだろ?
そして既存のものを出したら文句言ってるだけだろ。
38デフォルトの名無しさん:2014/01/26(日) 14:21:21.49
ifとか、一行を一グラフィカルユニットにした所で
場所をとるだけだろうな。

実際の所、グラフィカルユニットにしなくても
代わりにインデントと空行を使えば、十分視覚的になる。
39デフォルトの名無しさん:2014/01/26(日) 14:26:24.98
>>38
>>1 を嫁

「もうコーディングは嫌だ」だそうだ
40デフォルトの名無しさん:2014/01/26(日) 14:30:37.98
グラフィカルにしたところで、グラフィカルなコーディングはついて回るんだから
>>1 の望みは永遠に叶いそうにないな
41デフォルトの名無しさん:2014/01/26(日) 14:33:52.73
>1
こんなん?

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
42デフォルトの名無しさん:2014/01/26(日) 14:42:21.13
ところで、グラフィカルプログラミング言語で高階関数は作れるんかな
43デフォルトの名無しさん:2014/01/26(日) 14:54:25.92
>>42
作れる。

┌──────┐
│任意の文   │
└──────┘

基本的にこの罫線の形を変えればいいだけ。
あとはどんな関数であれ処理であれ
その説明をグラフィカルな図の中に書けば良い。
44デフォルトの名無しさん:2014/01/26(日) 14:56:44.60
>>41

視覚化ではなく、その図を書けば完成。
動作可能にならないとダメなんだってさ。

コーディング書きたくないわけだからそういうこと。
45デフォルトの名無しさん:2014/01/26(日) 15:33:10.27
>>41
でも大規模な開発には向いてなさそうだけどどうなんだろ
46デフォルトの名無しさん:2014/01/26(日) 15:37:30.64
>>44
コーディングを一切排除するのは難しいならあってもいいと思う
でもなくせるなら無くしてほしいって話

あと変数名もめんどうなので無くしてほしい
いちいち新しい変数作るたびに名前なんて考えてられんわ
どうにかならんもんかな
47デフォルトの名無しさん:2014/01/26(日) 15:42:50.18
>>46
コーディングというものを二つに分けて考えよう。

文字入力部分と処理部分。

処理部分は処理をなくせない以上どうあってもなくせない。
文字入力部分は代わりに、絵にしようが音声にしようが置き換え可能。

ただし面倒くさい。

嘘だと思うのなら、バラエティ番組を思い出せばいい。
一人が問題の答え(文字)を絵でかいて、もう一人がなんて文字か当てるというやつ。
48デフォルトの名無しさん:2014/01/26(日) 15:44:38.58
>>46
全部アドレスで指定するってこと?
それの管理が面倒だから変数名って概念があるんだが…
49デフォルトの名無しさん:2014/01/26(日) 15:49:09.97
>>46
お前の言ってるのは、「面倒くさい」んじゃなくて、
「出来ない」なんだよ。

コーディングすることが「できない」
適切な変数名をつけることが「できない」

単なる能力不足。
50デフォルトの名無しさん:2014/01/26(日) 15:53:36.36
簡単な例えで申し訳ないけど
例えば1から100までの合計を求める処理を
Excelを使って求めようとした場合殆どコーディングを必要としないし変数名も使わない
あれは広い意味でいうとある種のグラフィカルなプログラミングと言えると思う
ただ応用範囲は狭いから汎用性はないってだけで
51デフォルトの名無しさん:2014/01/26(日) 15:56:40.43
ExcelといってもVBAのはなしじゃないぞ
52デフォルトの名無しさん:2014/01/26(日) 16:02:16.28
>>50
だからそれ、めんどくさいよね?

基本的に素人用の道具って
「プロ用の道具+技術」に比べたら
面倒くさくて遅くて柔軟性がないんだよ。

たとえばプロの料理人だったら包丁でかつらむきを
高速にできるだろうね。でも素人だったら無理だし、
包丁渡されても技術がなければ遅い。

つまり君はまだ「プロ用の道具」しか渡されてなく
技術がないからそういう話をしてるんだよ。
53デフォルトの名無しさん: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ボタンを押す。
こんな感じかい? 面倒くさすぎw
たぶんこの説明でわからない人もいるだろうね。

コーディングを必要としないが、面倒くさくなってるよね?
54デフォルトの名無しさん:2014/01/26(日) 16:27:34.49
>>52
プロ用の技術がめんどくさくて遅くて柔軟性がないならみんなC言語なんて使わないでアセンブリ使ってんじゃないか?

>>53
確かにExcelだとその操作がネックになるよな
なんとか新しいグラフィカル言語作ってできないものかな
まあ無理ならいいけど
55デフォルトの名無しさん:2014/01/26(日) 16:32:11.55
あげ
56デフォルトの名無しさん:2014/01/26(日) 16:32:43.15
>>54
言語の違いは、ふさわしい適用範囲が違うだけ。
どれもプロ用。
57デフォルトの名無しさん:2014/01/26(日) 16:34:48.31
yahoo pipes がそれっぽいなと思った記憶があるな
もう何年も前だけど
58デフォルトの名無しさん:2014/01/26(日) 16:41:10.00
新しいグラフィカルプログラミングに求める要件
・開発期間を大幅に短縮できる
・可読性が半端ない
・処理速度は遅くても気にしない

誰か作って
59デフォルトの名無しさん:2014/01/26(日) 16:46:33.49
>>56
どれもプロ用ってことはないでしょ
たとえばbrainfuckのプロとしてふさわしい適用範囲って何?
60デフォルトの名無しさん:2014/01/26(日) 16:48:06.37
>>59
批判するしか脳のないバカなんだから相手するなよ
61デフォルトの名無しさん:2014/01/26(日) 16:59:51.60
OSもCLIしか認めないんだろうか
62デフォルトの名無しさん:2014/01/26(日) 17:04:19.87
グラフィカルなツールが出てからプログラマの
レベルが下がった事は考慮にいれないの?
63デフォルトの名無しさん:2014/01/26(日) 17:06:26.75
MacOSXにAutomaterっていうのはある
比較的グラフィカルではあるけど…ちょっと混みいった話になると
やっぱりシェルスクリプトやAppleScriptに頼ることになるんだよなぁ
64デフォルトの名無しさん:2014/01/26(日) 17:13:07.05
つ カルネージハート

DSLとして割りきるなら、グラフィカルなプログラミングも現実的だと思うよ。
複雑な処理は専用モジュールとしてあらかじめ作り込んでおけばいい。
65デフォルトの名無しさん:2014/01/26(日) 17:22:09.45
けどなんか結局複雑なパズルみたいになりそうな予感
66デフォルトの名無しさん:2014/01/26(日) 17:24:56.42
結局操作方法が変わるだけで、コーディングには違いないだろうしな
67デフォルトの名無しさん:2014/01/26(日) 17:26:59.75
>>1 がそういうDSLで我慢できるなら、これで完了だね
68デフォルトの名無しさん:2014/01/26(日) 18:11:11.37
JP1/Scriptじゃダメなの?
69デフォルトの名無しさん:2014/01/26(日) 18:16:30.54
>>62
本来の意味でのプログラマじゃないよな
事務屋さんがコンピュータ使ってるだけ
70デフォルトの名無しさん:2014/01/26(日) 19:54:56.81
>>59
brainfuckの話はしてないよ。
71デフォルトの名無しさん:2014/01/26(日) 19:57:52.06
グラフィックは文字よりも書くのに手間がかかる。
ただしコードのグラフィック化(可視化)は意味がある。
だけど、それはコードの情報を減らして重要な部分のみを可視化するというもの
だから可視化されているものから、動くコードを作るのは不可能。
実際に動くレベルの情報をグラフィックにすると手間がかかる。

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

まあこういう結論。
72デフォルトの名無しさん:2014/01/26(日) 20:16:17.73
>>69
そう思います。
自分は学生時代はBASIC・FORTRAN・Cを、就職した後は
汎用機を任されたので10年程COBOLをやりました。

特に、就職してからは色々なプログラマと仕事しましたが、
最近プログラマになった人は(キツイ言い方すれば)本来
プログラマになるべきでない様なプログラマに向いてない
人がプログラマになった感じの人が多い気がします。
色々理由はあるんでしょうが、長い不況でとりあえず職を
探したらそれしかなかったとか、流行でなったとか。
73デフォルトの名無しさん:2014/01/26(日) 20:28:16.17
そもそも前提から間違っている
隅から隅までグラフィカルじゃなくて
要点を絞ってここをグラフィカルに出来れば大幅に効率アップ!
ってのを探るのでなければ先に進みようが無い

GUIアプリのポトペタとか
ツクール系ゲーム開発のマップエディタとか
74デフォルトの名無しさん:2014/01/26(日) 20:42:40.57
> 要点を絞ってここをグラフィカルに出来れば大幅に効率アップ!
だからそれがないんだよ。

グラフィカルってのは理解しやすくなるが、
文字に比べて情報量は減ってる。

見るときや理解するのにはいいけど
書くと効率は下がる。

だからコードを可視化するツールがあればいいのさ。
75デフォルトの名無しさん:2014/01/26(日) 20:45:15.76
おまえらツールたくさんあるのに知らないだけじゃねーの?
76デフォルトの名無しさん:2014/01/26(日) 20:45:54.79
CADで書いてた回路図はほとんどが言語で記述されるようになった
77デフォルトの名無しさん:2014/01/26(日) 20:46:03.90
>>75
そしてたくさん知ってる君が答えるわけだね。
78デフォルトの名無しさん:2014/01/26(日) 20:51:35.63
>>1 によると、求められてるのは新しいグラフィカル志向だから、古いのじゃだめなんだよ
79デフォルトの名無しさん:2014/01/26(日) 20:56:23.00
マジレスするとこの分野で最も成功しているのは普及率・完成度ともにFile Makerだと思うんだわ

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

ファイルメーカー社の仕事は、もっと評価されていい。自分じゃ使わないけど。
80デフォルトの名無しさん:2014/01/26(日) 21:00:27.07
いや、そのFile Makerを作るプログラム言語を
グラフィカルにしたいって話でしょ?
81デフォルトの名無しさん:2014/01/26(日) 21:11:17.20
Cに相当する部分をグラフィカルにしたいのか
そりゃ需要ないから無理じゃね
82デフォルトの名無しさん:2014/01/26(日) 21:12:00.93
これこれこういう理由でこういうものが必要なんだという要件を明確にしてもらわんとね。
ドラえもん全部できるもの出してよって発想からは何も生まれない。
83デフォルトの名無しさん:2014/01/26(日) 21:15:38.61
Javaはかなりグラフィカルなツールでてるじゃん?部分的とはいえね
そういうの組み合わせていったら、コード書く部分は相当減るんじゃね
100%コードをなくしてしまうのは効率が悪くなると思う
84デフォルトの名無しさん:2014/01/26(日) 21:18:56.05
>>82
> これこれこういう理由でこういうものが必要なんだという要件を明確にしてもらわんとね。

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

本質的には、技術力不足が原因なので
コードを他の何かに変えても、出来ないものは出来ないだろうね。
85デフォルトの名無しさん:2014/01/26(日) 21:22:13.36
グラフィカルに表すことができる処理のコーディングなんて最近の言語使えば楽勝だろ
86デフォルトの名無しさん:2014/01/26(日) 21:54:25.86
構文解析とは違う何か新しい革命が起こらない限り無理だな
87デフォルトの名無しさん:2014/01/26(日) 21:59:16.47
全部できるもの出せって言われたらドラえもんはしょうがなく覚醒剤を出すかもしれない。
88デフォルトの名無しさん:2014/01/26(日) 22:04:13.42
89デフォルトの名無しさん:2014/01/26(日) 22:12:42.81
グラフィカルの意味を教えてくれ
90デフォルトの名無しさん:2014/01/26(日) 22:14:40.50
そういえば子供の頃夢想したなあ
レゴブロックに小さな機能をつけたようなパーツをいくつか用意しておいて
PCの画面でゲーム感覚でそれを組み立てるとどんな複雑なプログラムもかけるという空想

理屈の上で可能なのか不可能なのかよくわからんまま忘れてたらおっさんになってしまったな
まあ今思い出したから今でもよくわからん
91デフォルトの名無しさん:2014/01/26(日) 22:16:55.19
>>90
似たようなのはあるよ
マインドストームで検索だ
92デフォルトの名無しさん:2014/01/26(日) 22:20:15.83
>>91
おお、サンクス
名前は知ってるがあれってブロック組み合わせてロジック作成できるのだろうか?
PC上でコード書いてマイコンに送り込んで制御するものだと思っていた

出きるなら面白そうだな
ちょっと検索してみよう
93デフォルトの名無しさん:2014/01/26(日) 22:21:21.64
>>88
それ前から思ってたんだが、テキストで書くのとの本質的な違いってどこにあるんだろ

単にアルファベットや単語の形がブロック状に変わって色がついただけのような気がする
やってることは「なでしこ」なんかと同じじゃないかな
94デフォルトの名無しさん:2014/01/26(日) 22:23:36.42
むしろ文字だけの方が分かりやすい
95デフォルトの名無しさん:2014/01/26(日) 22:24:10.58
本質的に同じでも、なんか楽しけりゃいいと思うよ。
96デフォルトの名無しさん:2014/01/26(日) 22:24:40.30
>>92
ああ、ごめん
そういうのはできない
中心となるプロセッサとメモリと電気制御をするデカイパーツがあって、そこからケーブルを伸ばしてモーターやセンサーを使うってやつだ
97デフォルトの名無しさん:2014/01/26(日) 22:27:54.36
>>96
ありがとう
今見てるんだがこれはこれでワクワクする感じだなあ

子供が出来たら買ってやろう
その前にパートナーを検索しないとだが・・・
98デフォルトの名無しさん:2014/01/26(日) 22:31:32.38
例えばWin32APIでSendMessage(HWND,MSG,WPARAM,LPARAM)ってのがあるけど、
HWNDにウインドウハンドル書かずに矢印で対象ウインドウに線引っ張ったら分かりやすいし、
ウインドウハンドルとかいちいち書くかなくていいよね。
MSGもアイコンだと視認性が上がるよね。
WPARAMとLPARAMもどうせ何かの変数だよね。

そしたら、SendMessageって四角形にMSGのアイコン付けて、SendMessageって四角形の中のWPARAMとLPARAMには変数から矢印を引っ張って、
SendMessageって四角形から対象のウインドウに矢印引っ張るといいよね。
99デフォルトの名無しさん:2014/01/26(日) 22:32:46.57
グラフィカルなプログラミングは
できるできないでいえば出来る。

ただし効率が悪いので使わない。
100デフォルトの名無しさん:2014/01/26(日) 22:34:37.40
>>95
ごめん、Scratch はまさに「なんか楽しい」というのが第一の目的だからいいんだが、
たぶん >>1 の目的には合わないだろうなぁと思った。
101デフォルトの名無しさん:2014/01/26(日) 22:35:21.81
>>99
効率は上がる
ソースはOSの操作
102デフォルトの名無しさん:2014/01/26(日) 22:36:58.63
>>98
そのレベルで矢印を引くとなると、文字通りスパゲッティコードになるのが目に見える

デバッグやテストも描きにくいだろうし
103デフォルトの名無しさん:2014/01/26(日) 22:38:31.26
unix派はコマンドラインに固執してコマンドラインの方がGUIより効率が良いという信念は今も変わらないじゃないのかい?
104デフォルトの名無しさん:2014/01/26(日) 22:39:26.12
Flashなんかはタイムライン間にグィッとオブジェクトを動かせばスクリプト組まなくてもトゥイーンできたけど
条件によって動く方向やスピードを変えるというのになると途端に複雑なタイムラインを作る必要が発生して
結局ASで制御した方が楽でメンテナンス性も良かったりしたな
105デフォルトの名無しさん:2014/01/26(日) 22:41:14.71
だから使い分けだろ
今は選択肢すら無いって話をしてるんだろ
106デフォルトの名無しさん:2014/01/26(日) 22:42:43.70
使い分けもなにも結局複雑になるんだから
そもそも用途が無い
107デフォルトの名無しさん:2014/01/26(日) 22:44:53.54
どこで使うんだよ
108デフォルトの名無しさん:2014/01/26(日) 22:45:42.32
選択肢がないのはそれが使い物にならないからよ
109デフォルトの名無しさん:2014/01/26(日) 22:47:02.82
選択肢が無いなら新しく作ればいいじゃない
110デフォルトの名無しさん:2014/01/26(日) 22:48:02.69
今になっても出てこないってことは作る価値がないと判断されてるんだろ
111デフォルトの名無しさん:2014/01/26(日) 22:52:46.34
>>110がこれから世に出回る全ての製品と全ての概念と全ての技術を否定しました。
112デフォルトの名無しさん:2014/01/26(日) 22:53:29.16
馬鹿が楽してプログラミングしようとしても無理ってこったw
113デフォルトの名無しさん:2014/01/26(日) 22:55:36.09
>>101
> ソースはOSの操作

今はOSの操作の話をしてるんじゃないよ。
プログラミングの話。
114デフォルトの名無しさん:2014/01/26(日) 22:56:02.48
くんくん、権威主義に凝り固まった老害のニオイがする
115デフォルトの名無しさん:2014/01/26(日) 22:58:01.80
まぁやっぱり
「馬鹿には無理」
116デフォルトの名無しさん:2014/01/26(日) 22:59:20.37
ちょっと手続き型の概念から離れたら
GUIエディタもあるし
Flash、HTMLエディタ、
データベースエディタもある
UMLからコード生成したりもできる

プログラミングの役割はGUI付きツールに確実に侵食されている
117デフォルトの名無しさん:2014/01/26(日) 22:59:34.08
>>105
プログラミングで一番多く実行する
関数の実行をどうグラフィックにするんだ?

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

今俺は、キーをたったの10回タイプして、
hoge(1234)って書いたわけだが、
これをグラフィックにして、手間を減らせると思う?
118デフォルトの名無しさん:2014/01/26(日) 23:01:02.07
>>116
それって、一番重要な処理は
なにも作ってないんじゃね?

それで作ってるのはインターフェース部分だけでしょ?
119デフォルトの名無しさん:2014/01/26(日) 23:07:59.00
本格的に3D空間にものを自在に表示できるようになったら、プログラミングの技法も若干変わるだろうよ

それまでは今と一緒だな
120デフォルトの名無しさん:2014/01/26(日) 23:11:01.02
機能を可視化する方法は一通りではなく、より機能を正確かつ直感的に伝える可視化方法が求められる

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

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

おそらくどこかの時点でグラフィカルな言語を開発したとしても次の概念が来た際には大幅な修正や設計のし直しが求められる
PCの進歩、プログラミングの進歩が止まるまでは教育目的の簡単なものが出るに留まるんじゃあないか?
121デフォルトの名無しさん:2014/01/26(日) 23:13:12.66
グラフィカルになったとしても、複雑な電子回路みたいな表示になりそう
122デフォルトの名無しさん:2014/01/26(日) 23:15:26.82
複雑な電子回路は言語によるプログラミングで作られてるよ
123デフォルトの名無しさん:2014/01/26(日) 23:21:35.72
>>50にあるような
Excelのアイデアを利用できないかな
改良を加えれば操作性はいくらでも改善できると思うし
基本的なアルゴリズムの構文なら再現できそうだよ
124デフォルトの名無しさん:2014/01/26(日) 23:27:16.65
マインクラフトでチューリングマシンが作れるらしいからやろうと思えば何でも作れるんじゃね?
そのままでは開発効率も可読性も論外だがw
http://www.youtube.com/watch?v=kBDNzMqgJiM
125デフォルトの名無しさん:2014/01/26(日) 23:31:00.07
>>123
1から100までの合計をExcelで出そうとすると
面倒くさいんだけど、これじゃ使いものにならないでしょ?
126デフォルトの名無しさん:2014/01/26(日) 23:33:34.97
実行中のプログラムのメモリ配置をてグラフィカルに描画するツールないの?
127デフォルトの名無しさん:2014/01/26(日) 23:36:02.43
insightあたりはUIがウンコだから論外
128デフォルトの名無しさん:2014/01/26(日) 23:37:55.74
>>126
> 実行中のプログラムのメモリ配置をてグラフィカルに描画するツールないの?

デバッガ
129デフォルトの名無しさん:2014/01/26(日) 23:38:49.77
>>125
Excelをつかうんじゃなくて
新しいコーディング手法に応用できないかと言ってるんだよ
130デフォルトの名無しさん:2014/01/26(日) 23:39:48.92
>>128
デバッガの描画と操作性でイケてるものって?
131デフォルトの名無しさん:2014/01/26(日) 23:41:07.92
Excelは関数型言語だぞ
132デフォルトの名無しさん:2014/01/26(日) 23:41:44.00
>>129
だからなんで、面倒な方法を使おうとするんだよ?
文字のほうが少ない労力でできるだろうが。
視覚化が便利なのは、全体の概略、設計を把握するときだけだよ。
133デフォルトの名無しさん:2014/01/26(日) 23:44:20.02
>>132
表計算に関してはプログラミングするよりExcel使った方が効率いいんだが
134デフォルトの名無しさん:2014/01/26(日) 23:46:18.06
>>133
俺も写真にフィルター処理をする際にはプログラミングするよりもフォトショップ使った方が効率いいと思うぜ
135デフォルトの名無しさん:2014/01/26(日) 23:46:48.05
書くときだけを考えるから面倒なんだ。
実行時のフローを追ったり、排他制御や並行プログラミング、
リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良い
136デフォルトの名無しさん:2014/01/26(日) 23:47:33.73
>>133
たとえば?
137デフォルトの名無しさん:2014/01/26(日) 23:48:22.86
>>134
> 俺も写真にフィルター処理をする際には

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

あんたが言ってるのは単に画像に作ったフィルタを適用してるだけじゃん。
138デフォルトの名無しさん:2014/01/26(日) 23:48:39.52
効率求めてマクロにするのはプログラミングだよね
139デフォルトの名無しさん:2014/01/26(日) 23:49:17.11
>>135
訂正しておくね。

×リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良い
○リファクタリングまでグラフィカルにできると考えたら、ずっと効率が良いと思っているが、根拠も無いし証明もできない。悔しい!
140デフォルトの名無しさん:2014/01/26(日) 23:49:49.60
>>138
そのマクロって文字だよね?
141デフォルトの名無しさん:2014/01/26(日) 23:51:00.20
学研の電子ブロックでグラフィカルプログラミング!
142デフォルトの名無しさん:2014/01/26(日) 23:52:37.27
>>136
横レスするが、
Excel(もしくは相当する表計算ソフト)が存在しない世界を想像してごらん
表計算ソフトが無かった1970年代、誰もが表計算が必要になるたび、
BASIC、PASCAL、COBOLなどでいちいちプログラムを組んでいた
143デフォルトの名無しさん:2014/01/26(日) 23:53:01.53
>>139
断固拒否する
144デフォルトの名無しさん:2014/01/26(日) 23:53:10.52
カプセル化した内部をグラフィカルには難しそうだな
結局ここは文字で組むしかなさそう
145デフォルトの名無しさん:2014/01/26(日) 23:54:16.89
>>144
ツール側で見せなきゃ良いだけだろ
146デフォルトの名無しさん:2014/01/26(日) 23:54:33.15
>>137
表計算ソフトにはセル同士の値を計算する処理があらかじめ作られてるんでしょ?

あんたが言ってるのは単に打ち込んだ数字にその処理を適用してるだけじゃん。
147デフォルトの名無しさん:2014/01/26(日) 23:56:08.33
>>145
見せる見せないじゃなく、プログラミングするのに必要な部品をどう作るかということ
これが無いと完成しない場合はどうなる?
グラフィカルが無理な箇所だから組むしかねぇだろ
なんかずっとずれた回答してるよなお前
148デフォルトの名無しさん:2014/01/26(日) 23:57:16.15
>>147
おまえ、Smalltalkとかしらない入門者だろ
149デフォルトの名無しさん:2014/01/27(月) 00:00:33.16
>>142
なんの話してるんだ?

ExcelがExcelで作られてるというのならわかるが、
処理の部分はグラフィックに作る理由がないんだよ。
開発効率が悪いから。
150デフォルトの名無しさん:2014/01/27(月) 00:01:04.80
>>142
は?
151デフォルトの名無しさん:2014/01/27(月) 00:02:03.36
>>141
それ意外に面白いかもな。組上がったロジックをPCにセーブできると。
いや〜楽しそうです。
152デフォルトの名無しさん:2014/01/27(月) 00:03:35.20
プログラミングでもエクセルでもどっちでもできることを
エクセルでやる人ってのは、
単にプログラミング技術がないからだよ。

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

ようするに>>1は自分の技術力がないから
それ以外の方法を探しているだけ。
それが非効率なものであっても、
プログラミングが出来ないから、どうしようもあるまい。
153デフォルトの名無しさん:2014/01/27(月) 00:04:11.46
>>149
じゃあ開発効率のいいグラフィカルプログラミング言語を作ればいいじゃん
154デフォルトの名無しさん:2014/01/27(月) 00:05:31.79
処理の部品が膨大にないと出来るものが限られるんじゃね?
シンプルな処理の組み合わせをするなら結局はコード書くのと同じ位グチャグチャなグラフィックになるだろうし
155デフォルトの名無しさん:2014/01/27(月) 00:05:40.23
>>149
それって、単純な処理だけエディタから書けるようにして、
グラフィカルなUI部分では隠蔽しとけば良いだけちゃうん?
156デフォルトの名無しさん:2014/01/27(月) 00:06:21.36
そもそもラピュタだってブロックから出来てたんだぜ。宮崎駿の先見性と直観力は信じられる。
157デフォルトの名無しさん:2014/01/27(月) 00:06:51.56
>>156
死ねよカス
158デフォルトの名無しさん:2014/01/27(月) 00:07:07.58
>>152
1だけど正直コーディング歴は20年のベテランです
Webアプリでもゲームでも何から何までなんでも作れます
159デフォルトの名無しさん:2014/01/27(月) 00:07:42.93
処理の順番を文字で書くのも、絵で描くのも本質的には変わらないと思うんだが…
キーボードを打つよりもマウスを動かす方が手間が多いというだけで
160デフォルトの名無しさん:2014/01/27(月) 00:08:43.27
ただの老眼だろ
161デフォルトの名無しさん:2014/01/27(月) 00:11:25.91
>>158
Smalltalkライクな環境を作り、公開してはじめて、そのレスは意味を持つ
162デフォルトの名無しさん:2014/01/27(月) 00:14:09.19
emacsなんかと比べるとVSはかなりグラフィカルだ
163デフォルトの名無しさん:2014/01/27(月) 00:14:41.31
SmalltalkといえばSqueakなんてものもあったな
これをベースに拡張していけばいいもの出来んじゃね?
164デフォルトの名無しさん:2014/01/27(月) 00:15:21.14
素人レベルの作業だと、どう考えてもemacsの方がはやい
165デフォルトの名無しさん:2014/01/27(月) 00:18:39.55
>>163
やってみろよ。死ねクズ
166デフォルトの名無しさん:2014/01/27(月) 00:23:13.94
UMLから派生させるのは無理?
167デフォルトの名無しさん:2014/01/27(月) 00:44:34.02
>>166
ありだと思う
あとはもう少し細かいアルゴリズムの表現力をつけたいが
168デフォルトの名無しさん:2014/01/27(月) 01:06:56.28
>>167
死ねゴミ虫
169デフォルトの名無しさん:2014/01/27(月) 01:09:34.32
スレチで申し訳ないんだけど、
グラフィカルな開発環境より、全ての言語の中間のような言語が欲しいかな。
それそのものは実行もコンパイルもできなくていいから、好きな言語にエクスポートできるやつ。
言語間の相互変換は試みられてるけど、完全ではないし、できないものもある。
だから最初から変換する前提で設計された、仮に「XXX言語」とでも呼ぼうか、があるといい。
言語が違うってだけで一度書いたアルゴリズムをまた書くのはうんざりだ。

XXX言語は好きな言語にエクスポートしてから使うが、開発者はXXXの文法を学ばなければならない以外は今まで通り開発できる。
C言語でコンパイルしたいのなら、コンパイラのパスを通しておけばエクスポートからコンパイルまで自動でやってくれる。
JavaScriptへだろうがJavaへだろうがボタン一発でエクスポート。
170デフォルトの名無しさん:2014/01/27(月) 01:12:03.07
haxe
171デフォルトの名無しさん:2014/01/27(月) 01:14:16.08
>>153
> じゃあ開発効率のいいグラフィカルプログラミング言語を作ればいいじゃん

ないよ。っていうかグラフィカルプログラミングの定義上、
グラフィカルでなければならないよね?

文字も絵と考えれば、グラフィックなんだ。あとはそこに載せられる情報量の話。
緻密で複雑なグラフィックである文字の方が情報量が多いのは言うまでもない。

まあドット単位で正確に絵を書くというのならば、文字よりも多くの
情報量を入れられるだろうさ。大変すぎる作業になるのは明らかだけど。

それで「あ」という文字をキーで入力するのとこれを絵として
マウスでもペンでもいいけど書くのはどっちが時間がかかるかい?
結局のところ、こういう話。文字のほうが早く入力できるんだよ。
172デフォルトの名無しさん:2014/01/27(月) 01:16:30.22
>169
前に同じアイデア、2ちゃんねるに書いたな。
スレ立てた気もする。
173デフォルトの名無しさん:2014/01/27(月) 01:18:07.80
.netもparrotも失敗したよ
この世界では規格なんてものは大嘘で、実際に手に入る実装こそが真実
デファクトな中間言語のようなものがjavascriptだとしたら、
javascriptで書いた方がはやいって考えるような世界
174デフォルトの名無しさん:2014/01/27(月) 01:19:37.07
>>171
死ねゴミクズ。おまえなんて、この世界に生まれてくるべきじゃなかった
175デフォルトの名無しさん:2014/01/27(月) 01:22:03.13
>>171
グラフィカルだからってキーボードを一切使わないという訳ではないだろ

百歩譲って効率が少し劣ったとしても
視認性や再利用のしやすさの面で優ってたら利用する価値はあると思うけどな
176デフォルトの名無しさん:2014/01/27(月) 01:26:50.53
>>173
JavaScriptいいよね。なんて言ったらいいかよくわからないけど、
JavaScriptはとても外部の環境に影響されない言語なんだ。

例を出すとC言語。実はC言語にはディレクトリという概念がない。
それはディレクトリがないOSもあるわけで、C言語標準には含めなかった。
他の言語には標準的に搭載されているスレッドとかネットワークアクセスとかも。

JavaScriptはそれよりも更に進んで、ファイルアクセスというものすら存在しない。
CPUだけで処理できるような計算処理だけに制限された言語なんだ。
もちろん外部ライブラリを使うことで計算以外もできるけどね。
177デフォルトの名無しさん:2014/01/27(月) 01:28:15.33
>>175
> 視認性や再利用のしやすさの面で優ってたら利用する価値はあると思うけどな

視認性ならコードを視覚化すれば良い。
再利用のしやすさは、コードで書いても同じ。
178デフォルトの名無しさん:2014/01/27(月) 01:31:07.67
>>176
ブラウザ上でだけの話だろ。死ねカス
179デフォルトの名無しさん:2014/01/27(月) 01:32:26.66
ブラウザ上ですら互換性ないのにバカじゃねーの
180デフォルトの名無しさん:2014/01/27(月) 01:38:44.31
>>178
今は普通にコンソールで実行できる。

>>179
互換性問題は複数の実装があれば
どの言語にも存在する問題。

何に反論にもなってない。
181デフォルトの名無しさん:2014/01/27(月) 01:45:10.13
>>177
コードは視覚化しづらいだろ
182デフォルトの名無しさん:2014/01/27(月) 02:32:18.91
>>181
コードをそのまま視覚化するんじゃなくて
コードの構造を視覚化するんだよ。

どこがどう繋がっているとか。
でもそれは元のコードのつながりだけを抽出したもの
到底動くレベルにはならない。
183デフォルトの名無しさん:2014/01/27(月) 02:48:17.80
ここまでMELなし

LabViewと並んで一度使ってみたい言語だった
184デフォルトの名無しさん:2014/01/27(月) 02:54:07.75
>>72
一時期、職安ではプログラマを勧めていたし
そういう職業訓練を受けると特典をもらえた時期があった
185デフォルトの名無しさん:2014/01/27(月) 02:57:53.08
関数型言語限定の話になるけど、構造というか、効率化と可視化はもうちょっとしたいね。
プログラミングつったら関数をいっぱい書いていくけど、自分で書いた関数一覧がIEのお気に入りみたいに右側にアルファベット順に自動で表示されて、
クリックするとキャレットのところに自動で挿入される感じとか。
あとはコードの特定の部分を関数化しようとおもってコピペしたら、自動でその部分の変数が宣言されて関数名の入力ポップアップが出るとか。
宣言したクラスや構造体変数を書いたらすぐ横にメンバ一覧が出るとか。
お気に入り一覧以外に履歴一覧もあって、他のコードで使ったコードの関数もそこに出てすぐ使えるとか。
それがさらにオンライン対応になって、企業や特定のコミュニティ内で再利用できるとか。
もちろんヘッダまで遡って自動インクルード、自作のヘッダでもインクルードする。
186デフォルトの名無しさん:2014/01/27(月) 03:03:51.60
関数型言語限定の話っていうからなにかと思ったら、
関数型言語でできる話じゃなくて、
静的型付け言語なら普通にできることが
できてないから、関数型言語限定の話って言ったのか。
187デフォルトの名無しさん:2014/01/27(月) 03:07:00.37
え?
頭の中にはC言語があった。
C言語使うことが多いからC言語でそうやって組めたらいいなという妄想だ。
188デフォルトの名無しさん:2014/01/27(月) 03:21:12.22
ちゃんとしたIDE使いなよ。
関数のリストは表示されるし、
クラス・構造体は、.や->を書いたらリストが表示されるし、
コードの特定の範囲を関数にするって、
それIDEに備わっているリファクタリングツールの機能の一つじゃないか。
189デフォルトの名無しさん:2014/01/27(月) 03:30:02.52
>>180
node.jsなんて今日日じゃ常識レベルなのに、
javascriptにはファイルハンドラがとか、おまえバカだろ
190デフォルトの名無しさん:2014/01/27(月) 03:31:15.10
>>180
中間言語への反論だよ。死ねよクズ
191デフォルトの名無しさん:2014/01/27(月) 04:14:32.20
>>189
JavaScriptにファイルハンドラないよ。
nodeはJavaScriptという言語仕様の一部じゃないからね。
192デフォルトの名無しさん:2014/01/27(月) 11:19:11.70
>>171
ペンで書いた「あ」が一文字で何種類の情報を表現出来ると思う?
193デフォルトの名無しさん:2014/01/27(月) 11:23:50.03
上の方の関数を線で繋ぐ話がすごく興味ある。
線がゴチャゴチャするだろとか批判あったけど、ネスト・階層(gui風に言うならレイヤー)があれば良いだけの話で
それが上階層に行けば最終的にはフローチャートになる、なってなきゃおかしい

で、ギターのコンパクトエフェクター繋ぐ感じとか、DTMのミックスダウンソフトみたいにデータの流れと関数(エフェクター)をgui管理出来たらメチャ楽だと思うんだよね
194デフォルトの名無しさん:2014/01/27(月) 11:52:30.19
アイディアのある人は是非作ってくれ。
195デフォルトの名無しさん:2014/01/27(月) 13:36:56.50
どれも使いにくい
それよりuml描くだけでコードに変換してくれるツールの方が良い
196デフォルトの名無しさん:2014/01/27(月) 14:55:44.66
>>191
言語仕様にファイルハンドラって意味が分かりません
例えばJavaやC#の言語仕様にファイルハンドラってものはあるんですか?
197デフォルトの名無しさん:2014/01/27(月) 18:34:27.04
>>193
関数を呼び出すたびに関数を定義している場所までコネクタを引っ張るなんて発想は
なにかしら図面をみたことがあるなら出てこないはずだよな。
ICや機能ブロックを組み合わせた回路図で、図面の端っこにICの定義が書いてあって
そのICを使うたびにそこまで線を引くとか、そんなことはありえない。そこは名前参照するだろ

グラフィカルのいいところは一次元の文字列ではなく二次元に自由に並べられるところだとおもう。
条件分岐が複雑になったときや、関数に渡す引数の前処理が多段になったときに
どこからきた値がどの分岐、あるいはどの関数のどの引数に影響するのかということを
単なるインデントではなく二次元に配置すると見通しやすくならないか?
ワイドモニタ向きだともおもうんだけどな
198デフォルトの名無しさん:2014/01/27(月) 18:42:54.49
あつかうデータ型が描画要素とか音形とか限られていると比較的作りやすいんだよね
多様なデータ型があって、処理も多様だと、とたんに処理系を作るのが面倒になる
気がする
一度作ろうとしたことはあるけど面倒になったw
なにが面倒って使えるライブラリをそろえるのが面倒くさい
Win/Macの標準GUIやDBアダプタが標準化されてるLLがあれば核にするんだけど
・・・と妄想してもう10年近く放置してたりするww
199デフォルトの名無しさん:2014/01/27(月) 18:54:50.24
ここに書いとくと誰か作ってくれそうだから昔考えたアイデアを書いとく。
グラフィカルにするとレイヤーを扱えるようになる。もちろんテキストでもできるんだけど。

たとえばデバッグコードやトレースポイント(プローブ)を通常のレイヤーに重ねて垂直に結線する
処理前後の値の相関図をデバッグレイヤーにグラフィカルに表示したり、ログを取ったあと、
不要になればデバッグレイヤーを切り離せば通常動作する回路になる
元のコードを読むときははデバッグレイヤーを不可視にすると本来のコードを読みやすい
中間データをシグナルインジェクター的に流し込んでもいいとおもう

デバッグじゃなくてもちょっと試しに改変したりパッチを当てるときにも
元のコードがまるまるそのまま下のレイヤーに残っているというのが便利
200デフォルトの名無しさん:2014/01/27(月) 19:00:23.66
どんなプログラム言語で書いても
最適化の前にはデータ構造としての「グラフ」に分解されて実行されるんだから
最初からグラフィカルに書けばいいとおもうのん。
201デフォルトの名無しさん:2014/01/27(月) 19:10:03.68
頭のいい人には関係ないことだけどコネクタを使うと中間変数を省略できるから
数字の逆唱を5個とか7個しかできない凡人にはグラフィカルにするメリットがある

かもね
202デフォルトの名無しさん:2014/01/27(月) 22:38:17.78
vimやSublime Textなどの高機能エディタが
IDEより生産性が高くなってしまったので、
IDE復権のためにグラフィカルな言語の登場が待ち望まれるね
203デフォルトの名無しさん:2014/01/27(月) 23:23:01.75
いきなり大規模なもんはできないだろうから
とりあえず小規模な基本的なアルゴリズムが組めるものを考えてみよう
204デフォルトの名無しさん:2014/01/27(月) 23:50:19.69
>>193
線をつなぐのはいいんだが、それをグラフィックでやる意味が無いだろ。

関数A → 関数B

ほら、関数を線でつなぐことが出来た。
205デフォルトの名無しさん:2014/01/27(月) 23:56:23.46
ループはどう書く?
206デフォルトの名無しさん:2014/01/28(火) 00:01:16.90
>>205
for(i in data) {
 hoge(i)
}

これを絵で書いたら分かりやすくなる書い?
あたりまえだけど、iとかdataとかhoge(i)といった
情報を捨ててはいけない。
207デフォルトの名無しさん:2014/01/28(火) 00:08:03.68
値を全部リストにする
208デフォルトの名無しさん:2014/01/28(火) 00:21:08.35
>>206

i→data→hoge

はいできた
解釈は各自好きなようにやってくれ
209デフォルトの名無しさん:2014/01/28(火) 00:23:05.96
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所
210デフォルトの名無しさん:2014/01/28(火) 01:01:04.78
J言語をグラフィカルにしてください
211デフォルトの名無しさん:2014/01/28(火) 01:06:49.10
>>206 だと
→ for
しか書けないよね。線の中身がdataで、後はforの下のレイヤーになる。

入り口と出口があってそれぞれに意味を付けられるようなのじゃないとあんま使いではないのかも

file1 →↓
file2 → [ diff ] → stdout

こんなのだったら使いやすそう。ファイルの結線を変えて比較したり[diff]にツマミが付いてて、それを回すと出力形式変えられたり。出力線を足して差分取ったり。それをまた[diff]に結線したり。
212デフォルトの名無しさん:2014/01/28(火) 01:13:15.87
csv

[ awk ]
↓→ column1
↓→ column2
↓→ column3 → [ sed ] → ‥

こういうのとかも
213デフォルトの名無しさん:2014/01/28(火) 02:30:16.72
コードを図で書くのって難しいな。
214デフォルトの名無しさん:2014/01/28(火) 02:45:05.83
図ってのは、頭のなかに描く分には自由だが、
PC上で扱うとなると、位置と大きさがあるせいで
意外と抽象化の役に立たない気がするよ。
つーか邪魔になるレベル。有り難みがない。
215デフォルトの名無しさん:2014/01/28(火) 08:16:46.62
むしろ抽象化度が低くて凡人にもわかやすい
216デフォルトの名無しさん:2014/01/28(火) 08:36:29.23
現代人が世界共通で使っている数式はオイラーからニュートンまでのそうそうたる天才達が一般化したもんだから
凡人の浅知恵じゃ超えられないよ。
217デフォルトの名無しさん:2014/01/28(火) 08:52:28.17
ライプニッツによって定義された関数を初めてy=f(x)の形で表したのもオイラーである。
wikipediaより
218デフォルトの名無しさん:2014/01/28(火) 09:39:12.15
既存の構文をいかにグラフィカルにするかという考え方だと新しいもんはできないな
要は問題をいかに解決するかが重要なんだから
例えば簡単なアルゴリズムの問題集なんかから問題を見つけてきてそれをいかにグラフィカルな手法で解決するかを模索してみた方がよっぽど発展性あるかも
219デフォルトの名無しさん:2014/01/28(火) 10:45:14.41
簡単な数式や小さな構文は文字で書いてあったほうが理解しやすいけど
関係する要素が増えてくるとグラフィカルにしたくなる
構造が簡単で入出力いずれかの数が多い>>211-212あたりがグラフィカルに向いているとおもう

並列に並ぶ要素が増えるくらいなら束ねることで閲覧性を保てるけど
構造が網目状に入り組んできたら数式でも図形でもどちらでも難読になるね
220デフォルトの名無しさん:2014/01/28(火) 15:55:56.89
自分は汎用機のプログラマ(コボラー)なんで、
便利な開発ツールなんて殆どありません。
汎用機からCOBOLのソースをftpで取り込んで
テキストファイルにして秀丸などで修正とか。

だから、汎用機以外で使われているPC系の
ツールを見ると結構羨ましい。
edit画面で、ifと打ち込んだらすぐ下にend-ifと
表示されるたりするツールを見た時はびびりました。
221デフォルトの名無しさん:2014/01/28(火) 20:03:31.85
>>218>>219
ファインマンダイアグラムなんて例として良いかもな
222デフォルトの名無しさん:2014/01/28(火) 20:49:55.31
>>219
> 関係する要素が増えてくるとグラフィカルにしたくなる

正確に言うと、グラフィカルに ”見たくなる” でしょ?

グラフィカルなプログラミング言語は
書いたものがそのまま実行可能にならなきゃいけないけど、
実行可能なレベルまで書き込むと、画像では場所とりすぎで逆にわからなくなるよ。
223デフォルトの名無しさん:2014/01/28(火) 20:52:44.85
>>219
> 構造が簡単で入出力いずれかの数が多い>>211-212あたりがグラフィカルに向いているとおもう

>>211-212は文字で書いているんだが・・・。
224デフォルトの名無しさん:2014/01/28(火) 21:52:28.06
>>222
わかりにくくなる、で済ますのではなく
いかにすれば使いやすくなるか考えるのが真の開発者だ
225デフォルトの名無しさん: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ベースってのは、あまり注目されない話題だね
226デフォルトの名無しさん:2014/01/28(火) 22:40:54.03
>>224
> いかにすれば使いやすくなるか考えるのが真の開発者だ

じゃあお前が考えろよw

文字というのは特定の形のグラフィックを
使いやすいように定めたもの。

象形文字という絵から文字が生まれた。

そもそもグラフィックをいかにすれば使いやすくなるかを
考えた結果、文字になったわけで、話がおかしいんだよ。
227デフォルトの名無しさん:2014/01/28(火) 22:43:21.10
「リンゴ」って三文字書くのと
リンゴの絵を書くのと、
どちらがわかりやすいかという問題だな。
228デフォルトの名無しさん:2014/01/28(火) 22:45:30.77
色つきでないとリンゴと梨の区別がつかないな
229デフォルトの名無しさん:2014/01/28(火) 22:48:21.72
>>228
色つけりゃいいじゃん
230デフォルトの名無しさん:2014/01/28(火) 22:49:55.51
「赤いリンゴ」を表現するために
何秒で出来るか競争してみようぜ?
231デフォルトの名無しさん:2014/01/28(火) 22:52:18.11
おーっと、ここで青リンゴの登場だー
232デフォルトの名無しさん:2014/01/28(火) 22:59:15.25
文字って凄いよな。
たったの数回キーを叩くだけで
表現できてしまう。

これを図で書く?
アホだろw
233デフォルトの名無しさん:2014/01/28(火) 23:00:30.51
class ringo{
iro=COLOR_RED;//色(赤)
omosa=300;//重さ(グラム)
suibun=95;//水分(パーセント)
 amasa=15;//糖度(度)
}

ね、文字だと簡単でしょ?
234デフォルトの名無しさん:2014/01/28(火) 23:02:17.49
リンゴみたいに具体的な形があるやつなら
まだグラフィックにするメリットがわかるんだが。

ソート処理をグラフィックにするとして
どんな形になるんだ?

バブルソート、クイックソート、シェルソート
この違いをどうやってグラフィックにするんだろうか。

文字の周りを罫線で囲むだけじゃなんの意味も無いよ。

そう、コードっていうのはグラフィックにできないんだ。
235デフォルトの名無しさん:2014/01/28(火) 23:03:17.92
>>232
3文字だと文字でも困らないな

でも小説と漫画を比較すると断然漫画の方が視認性高い
236デフォルトの名無しさん:2014/01/28(火) 23:05:26.25
>>234
大学の教授は大体絵に書いて説明してるぞ
237デフォルトの名無しさん:2014/01/28(火) 23:07:52.91
>>236
その絵は概略でしかないだろ?
238デフォルトの名無しさん:2014/01/28(火) 23:08:40.09
色は良いよね。アイコンに近いのかも。
ディレクトリが用途とかで色分け出来たら良いのになあと思った事が何度もある。

それとディレクトリだったら、単に時系列でソート出来るだけじゃなくて、例えば使用頻度の高いファイルやディレクトリは大きく、そうじゃないのは小さく表示するとか便利だと思う。
あと平面のウィンドウが実は立方体で、ディレクトリ一覧をグルっと横に回すと中身が見れたり、タグ付けされた奥行きの情報が見れたりとか、一杯やりたい事ある。
技術が追いつけばねぇ…
239デフォルトの名無しさん:2014/01/28(火) 23:09:43.96
>>238はちょっとプログラムとずれたか。スマソ
240デフォルトの名無しさん:2014/01/28(火) 23:11:25.72
>>235
> でも小説と漫画を比較すると断然漫画の方が視認性高い
だが書くのに時間がかかるだろ?

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

だから視覚化されたコードは、コードの一部の特徴を表したに過ぎない。
それは実際に動くプログラミングにはなりえない。
(不可能ではないが時間がかかりすぎるため、教育用として小さいコードを書くのが精一杯)
241デフォルトの名無しさん:2014/01/28(火) 23:13:45.03
ぶっちゃけていえば、
絵っていうのは、馬鹿に説明するためにある。

小説とマンガの関係も同じ。
242デフォルトの名無しさん:2014/01/28(火) 23:27:21.13
>もしコードの全てを含ませようとすると、それは巨大になり
>そして作るのにもかなりの時間がかかる

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

出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
ただ文字だと見にくく、絵だと見やすいというだけの話
243デフォルトの名無しさん:2014/01/28(火) 23:31:01.23
>>234
『大人のピタゴラスイッチ』でクイックソートを動画にしてたぜ
244デフォルトの名無しさん:2014/01/28(火) 23:42:50.59
プログラムの視覚的全体像をみたい余り文字を通常の1/10に小さくしている人居たけど
文字の形がほとんど判別できないのなw
視力に頼りすぎているそいつはプログラマとしての寿命は短いだろうなと思った。
245デフォルトの名無しさん:2014/01/28(火) 23:50:30.53
目が悪くなったら画面を大きくすればいい
246デフォルトの名無しさん:2014/01/28(火) 23:52:19.20
>>242
ドコが見やすいのか、
バブルソートを絵にして説明してくれ。
もちろん、動かないとダメだぞ?
247デフォルトの名無しさん:2014/01/28(火) 23:57:53.16
  ━━━━━━━
in →┃バブルソート┃→ out
━━━━━━━
248デフォルトの名無しさん:2014/01/28(火) 23:58:41.88
>>247
バブルソートって
文字でかいてるなw

結局、文字が一番適切に説明できるんだよw
249デフォルトの名無しさん:2014/01/29(水) 00:02:58.22
バブルスライムの画像を使えばどうだろう。著作権違反かな。
250デフォルトの名無しさん:2014/01/29(水) 00:03:36.44
>>248
勝手に文字禁止なルールにするなw
グラフィカルなOSにも文字は使われてるんだぞ
251デフォルトの名無しさん:2014/01/29(水) 00:03:40.05
バブルスライムの画像で
バブルソートが実装できるのか?
252デフォルトの名無しさん:2014/01/29(水) 00:04:29.15
>>250
いや、だって>>247って別に罫線いらないじゃんw

文字だけで十分なのに、
それを絵にする意味ってなんだよ?w
253デフォルトの名無しさん:2014/01/29(水) 00:07:10.36
いやバブルスライムをクリックすると胃袋が2つに分かれて再帰的に反芻してソートして排泄するのがわかるとか。
254デフォルトの名無しさん:2014/01/29(水) 00:10:16.81
グラフィカルに表現する利点は複数の要素の関係性が表現しやすいという点だろうな
でも関係性が増えると線が多すぎて逆に見にくくなってしまうというジレンマが・・
255デフォルトの名無しさん:2014/01/29(水) 00:22:29.04
構造化プログラミングのせいだな
256デフォルトの名無しさん:2014/01/29(水) 10:20:49.00
文字はグラフィックの一部だ、グラフィカル言語は文字を使ってもいい
むし抽象度や粒度を適切に制御するために文字の混在は推奨されるだろう
257デフォルトの名無しさん:2014/01/29(水) 10:31:08.17
現実の問題で関係性が複雑すぎてグラフにするとわからなくなるようなものはあるのだろうか
258デフォルトの名無しさん:2014/01/29(水) 10:38:56.45
コードの複雑性を隠すために条件分岐文を折りたたむという方法があるけど
あれって全体の構造をみて必要なところだけ折りたたまない実装はあるのだろうか
現実的にはファイルを分割するという形でプログラマのコントロール下に置くことになるのかな

グラフで表現するときはこういった折り畳みはその図面の中で行われるのだろうか
ダブルクリックすると機能ブロックが開いて詳細実装をみることができるとか
ズームするとグーグル地図のように詳細図に切り替わるとか
259デフォルトの名無しさん:2014/01/29(水) 16:46:31.19
>>7
LabViewでプログラム書いてみ。
あっという間に使う気が失せるから。
260デフォルトの名無しさん:2014/01/29(水) 20:10:31.82
>>193
データの流れをGUIでプログラムできる環境はたくさんある。
261デフォルトの名無しさん:2014/01/29(水) 21:27:14.72
このスレがなんか一番ソフト工学してるな
262デフォルトの名無しさん:2014/01/29(水) 22:41:53.33
グラフなら、コードの中のある変数や引数に注目して
その祖先や子孫をあぶり出し表示するのは簡単だな
テキストで同じことをするにはどうするんだろう?
263デフォルトの名無しさん:2014/01/29(水) 23:45:37.48
>>262
何か勘違いしてそうだから言っておくけど、

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

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

コードの一部(例:変数に着目して視覚化)をグラフ化するのは
何も問題がないが、最初からグラフを書くことでプログラミングなんかしたら
大変きわまりないだろ?
264デフォルトの名無しさん:2014/01/30(木) 01:55:26.85
流れは矢印で書くほうがわかりやすくてはやいよ
詳細はコーディング

JP1/Script形式が最強だろ
もうちょい言語側がパワフルになってほしいけどな
265デフォルトの名無しさん:2014/01/30(木) 08:34:21.58
アルゴリズムもグラフィカルにしたほうが効率いいだろ
266デフォルトの名無しさん:2014/01/30(木) 18:49:13.28
今のままでも十分視覚化されてると思うが
267デフォルトの名無しさん:2014/01/30(木) 22:01:37.35
比較する対象がないからだろ
ガラパゴス携帯しかない時代の人間がガラパゴス携帯が一番使いやすいと考えてるようなもんだ
268デフォルトの名無しさん:2014/01/30(木) 22:16:48.76
だれか僕にもできるの作ってどらえもんってこと?
269デフォルトの名無しさん:2014/01/30(木) 22:19:48.33
>>268
もっと作業効率あげれる未来の道具出してよドラえもんってことだよ
270デフォルトの名無しさん:2014/01/30(木) 22:38:46.38
ま、タブレットとかスマホでプログラム作れる環境は欲しい。
271デフォルトの名無しさん:2014/01/30(木) 22:46:21.88
AndroidもiOSもCのコンパイラとかPythonとかあるだろ
272デフォルトの名無しさん:2014/01/30(木) 23:45:53.37
キーボードを見捨てた時点からあなたは無能である。
273デフォルトの名無しさん:2014/01/31(金) 00:08:06.22
落書き見たいにプログラミングできたら楽しいだろうな
274デフォルトの名無しさん:2014/01/31(金) 00:11:38.33
>>269
効率を上げるために絵から文字が生まれたのに、
絵に効率を求めるなんて愚かだな。
絵は見るのにはいいが描くのは大変だ。
275デフォルトの名無しさん:2014/01/31(金) 00:28:16.99
>>274
なんでそんなに文字だけにこだわるんだ?
文字自体もグラフィカルな表現の一種なんだが
何か不都合でもあるのか?
276デフォルトの名無しさん:2014/01/31(金) 00:29:25.24
見る側からすれば、文字だけの文より図や絵が入ったほうが
見やすいのは明らか

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

まぁ、出来るもんなら作ってみろって感じ
277デフォルトの名無しさん:2014/01/31(金) 00:46:14.64
そのためにコンピュータがあるんだろ
人間は指示をするだけ
コンピュータは指示を受けてルールを構築していくだけ

出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
ただ文字だと見にくく、絵だと見やすいというだけの話
278デフォルトの名無しさん:2014/01/31(金) 01:05:05.63
>>275
なにか不都合がって、
最初からプログラミングを
画像でやるのは不都合だって言ってるじゃん。
279デフォルトの名無しさん:2014/01/31(金) 01:06:41.12
100種類のオブジェクトがあるとして、
文字なら100種類の識別子をつけられるけど
100種類の絵で識別するのは困難。
絵だと見やすいのは幼稚なオモチャに限られる。
280デフォルトの名無しさん:2014/01/31(金) 01:07:52.60
>>277
> 出来上がったものが文字であろうが絵であろうが人間の労力は変わらない
> ただ文字だと見にくく、絵だと見やすいというだけの話

いやいやw 支持を絵でやるのが難しい(時間的に)って話だろw
紙芝居で作業指示書を書いてみ?

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

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

これを絵で指示してみ?
労力はどれくらい違うよ?
281デフォルトの名無しさん:2014/01/31(金) 01:09:41.02
>>279
絵だと100種類のアイコンですむな
ドラッグアンドドロップで使用できるから楽だ
282デフォルトの名無しさん:2014/01/31(金) 01:10:29.88
100種類作るのがめんどくさくて微妙な違いがわからないって言ってるんだが。
283デフォルトの名無しさん:2014/01/31(金) 01:13:04.07
>>280
ボタンをポチポチクリックしていくのと命令をひたすら書いてく作業はどっちが楽だろな
確実に前者だろ?
後者だというならお前は一生グラフィカルインターフェイスに触れるな
284デフォルトの名無しさん:2014/01/31(金) 01:13:35.59
たった100種類で足りるわけ無いだろw
100種類っていったら、日本語に使われる文字より
はるかにするないぞ?

まあ、英語よりは文字数多いかもしれないけどな。

それでどうするんだ?アイコンを複数つなげて言葉を作るのか?
そりゃそうだ。アイコン一つで表せることは100種類しかないからな。
285デフォルトの名無しさん:2014/01/31(金) 01:13:50.49
>>282
ラベルはればええんちゃうか?
286デフォルトの名無しさん:2014/01/31(金) 01:14:37.45
>>283
よし、じゃあ競争だ。

お前はボタンをポチポチ、スクリーンキーボードで
入力してくれ。俺はキーボードで入力する。
287デフォルトの名無しさん:2014/01/31(金) 01:15:11.67
>>285
そしてアイコンの代わりにラベル(文字)を見るのか?
もう文字だけでいいじゃねーかw
288デフォルトの名無しさん:2014/01/31(金) 01:15:32.22
>>284
論破されすぎて混乱してきてるな
冷静になれ
289デフォルトの名無しさん:2014/01/31(金) 01:16:18.78
論破っていうのはこういうことを言うんだよ。
絵で指示するのまだできないの?

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

いやいやw 支持を絵でやるのが難しい(時間的に)って話だろw
紙芝居で作業指示書を書いてみ?

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

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

これを絵で指示してみ?
労力はどれくらい違うよ?
290デフォルトの名無しさん:2014/01/31(金) 01:17:17.39
>>285
それだとグラフィカルにする必然性が薄くなる。
残るのは関連を線でつなげることとグリグリ動かすことくらいだな。
線でつなげるのは100x100=10000本の線でスパゲッティになる可能性すらある。
動画はさらにめんどう。
291デフォルトの名無しさん:2014/01/31(金) 01:18:33.82
>>286
表計算の作業で競おうぜ
俺はエクセルつかうからお前はコーディングな
まさかエクセルは文字があるからグラフィカルじゃないとか言わないよな?
292デフォルトの名無しさん:2014/01/31(金) 01:20:28.08
じゃあエクセル対プログラムでエラストテネスの篩のプログラムで競争してくれ。
293デフォルトの名無しさん:2014/01/31(金) 01:20:53.53
>>291
何言ってるのか分からない
解説を頼む
294デフォルトの名無しさん:2014/01/31(金) 01:20:55.93
>>290
グラフィカルユーザインターフェイスってそんなに不便だったのか
でもOSの世界ではシェアが圧倒的に多いんだがな
そんな不便なものがこんなに普及しちゃつてんだから不思議だよな
295デフォルトの名無しさん:2014/01/31(金) 01:21:50.48
>>293
都合悪くなったら日本語読めない振りwwwwwwww
わろた
296デフォルトの名無しさん:2014/01/31(金) 01:22:28.51
>>294
2ちゃんねる見て、googleしてエロ動画見てるだけだろ。
そんな簡単なことができたくらいで偉そうに。
297デフォルトの名無しさん:2014/01/31(金) 01:23:50.03
>>295
エクセルで何をグラフィカルにプログラミングするの?
棒グラフ出すってこと?
298デフォルトの名無しさん:2014/01/31(金) 01:24:33.88
>>296
そんな低俗な使い方してるのは中卒のお前だけだよ
世の中じゃデスクワークや研究でも普通に使われてんだよ
もっとそとにでて現実をしれ
299デフォルトの名無しさん:2014/01/31(金) 01:26:31.18
>>297
グラフィカルのいみ調べてこいよ
表でもグラフでも、広義の意味では文字でさえもグラフィカルなんだよ
300デフォルトの名無しさん:2014/01/31(金) 01:28:41.13
グラフィカルの反対語が文字だとでも思ってんだろな
301デフォルトの名無しさん:2014/01/31(金) 01:29:55.89
>>299
じゃあ素数100万個出す競争でもする?
一行にカンマ区切りで2000個ずつ

これでいい?
302デフォルトの名無しさん:2014/01/31(金) 01:30:07.55
ドラえもん「未来のアイテムが幾らするか知ってるかい? 現代価格で100億。」
303デフォルトの名無しさん:2014/01/31(金) 01:31:28.04
>>299
何をしたいのかさっぱり分からんのだが?
304デフォルトの名無しさん:2014/01/31(金) 01:34:41.84
>>294
お前何か勘違いしているよ。

グラフィックっていうのは見やすいが
書きにくいんだよ。描くのに時間がかかる。

だからコード→グラフィックの変換はいいが、
最初からグラフィックを使ってプログラミングするのは
馬鹿なアイデアだって話。
305デフォルトの名無しさん:2014/01/31(金) 01:35:32.07
いい忘れたけど過去転送の送料が99億なんだけどね。
306デフォルトの名無しさん:2014/01/31(金) 01:35:46.17
>>299
> 表でもグラフでも、広義の意味では文字でさえもグラフィカルなんだよ

じゃあ、スレタイの
「グラフィカルなプログラミング言語ない?」って
いうのはどういう意味?

> もうコーディングは嫌だ

らしいよ。
307デフォルトの名無しさん:2014/01/31(金) 01:36:43.19
>>301
それはエクセルのまけだわ
じゃあ次は売上データを元に
月別で棒グラフを作成するって課題でやろうせ
データはCSVで用意しとくよ
308デフォルトの名無しさん:2014/01/31(金) 01:38:56.15
まぁ命令はクリックだけでできた方が楽だろな
309デフォルトの名無しさん:2014/01/31(金) 01:39:12.86
>>307
CSVで用意したデータをコーディングしないで、
グラフィカルなプログラミング言語(?)で
やるってこと?

普通にコーディングしたほうが早いと思うが?
310デフォルトの名無しさん:2014/01/31(金) 01:39:13.89
エクセルは横方向だと
A〜Z AA〜ZZ までだっけ?
311デフォルトの名無しさん:2014/01/31(金) 01:40:49.15
>>307
もちろん、ただツールを使うだけじゃダメなんだよね?
プログラミングして作らないといけないんだよね?

いや、ツールを使うなら。グラフ作成ツールに流し込めば終わりだからさ。
312デフォルトの名無しさん:2014/01/31(金) 01:41:05.37
>>307
コーディング派はグラフの作成もコーディングでやった方が速いと考えてるらしいな
仕事が早くて羨ましい
313デフォルトの名無しさん:2014/01/31(金) 01:41:46.70
>>312

おいおい、「プログラミング言語」前提の話だろ?
314デフォルトの名無しさん:2014/01/31(金) 01:42:03.03
日本語でおk
315デフォルトの名無しさん:2014/01/31(金) 01:42:35.49
>>311
既存のシステムを使うんでは比較にならないだろ
ずるはダメだぞずるは
316デフォルトの名無しさん:2014/01/31(金) 01:43:10.02
結論:エクセルやりたいならエクセルやってろ
317デフォルトの名無しさん:2014/01/31(金) 01:43:11.40
グラフィカルなプログラミング言語だから
ツールで用意された機能を使うんじゃなくて、
実際にプログラミングする時間で比べなきゃ意味が無いでしょ?
318デフォルトの名無しさん:2014/01/31(金) 01:43:25.34
>>309
エクセルだと簡単に表計算できるよ
グラフも一発だ
319デフォルトの名無しさん:2014/01/31(金) 01:44:11.44
>>309
それ、プログラミングじゃないじゃん?

>>1をみればわかるけど、
最初からプログラミング言語の話をしてるんだけど。
ちょっと話、皆についてこようよw
320デフォルトの名無しさん:2014/01/31(金) 01:45:19.51
救済処置:エクセルで満足できないやつはアクセスへ移行しろ。
アクセスで満足できないやつはブイビィーでもやってろ。
321デフォルトの名無しさん:2014/01/31(金) 01:47:22.91
命令は絵でやるより
コーディングしたほうが早いというからエクセルの例えを出したんだよ
やっぱ表計算ではエクセルに勝てないとさとったか
グラフィカルの勝利!
322デフォルトの名無しさん:2014/01/31(金) 01:49:23.54
>>317
ツールで用意された機能使うにしても
キーボードでツール呼び出すよりアイコンクリックした方が断然早いけどな
323デフォルトの名無しさん:2014/01/31(金) 01:50:34.42
エクセルで不満がないならエクセルやってればいいのに。
何か不満があるんだろ?その不満はプログラマブルに解消可能かもしれないのに、
いきなりグラフィカルになんでもやりてぇ〜〜〜〜〜!とか言っても無理な相談なんだよ。
324デフォルトの名無しさん:2014/01/31(金) 01:50:56.73
で、グラフィカルなプログラミング言語がコーディングよりも効率悪いと言う根拠はなんだ?
325デフォルトの名無しさん:2014/01/31(金) 01:53:17.11
>>312
エクセルVBAやVBなんて
コーディング量ほとんどなくなったよな
そう思えば時代は間違いなくグラフィカル!
326デフォルトの名無しさん:2014/01/31(金) 01:53:45.71
>>323
不満といえばエクセルには汎用性がないことかな
もっと操作効率を落とさず作業範囲を広げたいんだわ
327デフォルトの名無しさん:2014/01/31(金) 01:56:58.96
なんだ?このスレ
328デフォルトの名無しさん:2014/01/31(金) 01:57:29.41
結論:マイクロソフトに相談しろ。莫大な投資をすればマイクロソフトは動いてくれるはず。
329デフォルトの名無しさん:2014/01/31(金) 02:00:25.84
勝手に自分で作れよ
そして勝手に儲けろ
330デフォルトの名無しさん:2014/01/31(金) 02:02:27.12
それだけのスキルと知能はここの住人にはない
331デフォルトの名無しさん:2014/01/31(金) 02:03:09.62
>>324
> で、グラフィカルなプログラミング言語がコーディングよりも効率悪いと言う根拠はなんだ?

世の中に効率がいい「グラフィカルなプログラミング言語」というものが存在しない。

ちなみに、「グラフィカルなプログラミング言語」の定義は
普通のプログラミング言語と同じことが出来るもの。
たとえば、ifやloop、オブジェクト指向ができて、
それがそのまま実行可能であるというもの

もしかしたら効率がいい「グラフィカルなプログラミング言語」ができるかもしれないが
そもそもコーディングを上回る速さで絵を描くというのが不可能ということから、
効率が悪いというのは明らかである。
332デフォルトの名無しさん:2014/01/31(金) 02:06:00.84
まああれだ、
「三回まわってワン」という命令を
文字で書く以上のスピードで書いてくれという話。
333デフォルトの名無しさん:2014/01/31(金) 02:06:11.46
世の中にはグラフィカルなプログラミングがあふれているよ
これ以上何が必要なの?
334デフォルトの名無しさん:2014/01/31(金) 02:06:54.07
>>333
開発効率。開発スピード

「三回まわってワン」という命令を
文字で書く以上のスピードで書いてくれ
335デフォルトの名無しさん:2014/01/31(金) 02:07:52.44
>>332
それはさすがにグラフィカル系の圧勝だわw
ループチップに3回って設定して
表示チップに「ワン」と設定するだけ
ドラッグ2回とクリック2回、それと「ワン」とタイピングするだけ
336デフォルトの名無しさん:2014/01/31(金) 02:08:52.87
具体的な問題が提示されないのに解決方法なんて提示されるわけがない
337デフォルトの名無しさん:2014/01/31(金) 02:12:40.28
>>331
なんで命令する→絵を書くになるんだ?
せいぜいアイコンをクリックとかコネクタ引っ張ったり要素を配置したり変形させたりとかだろ
一つ命令するために絵を書くなんてそれはプログラミングとは言わないだろう
338デフォルトの名無しさん:2014/01/31(金) 02:13:01.27
たしか洋物のブラウザゲームであったな
ロボットを目的地まで移動させるのに
ブロック?(命令)を並べていくの

条件分岐とループはあった
関数はあったかどうか覚えてない
339デフォルトの名無しさん:2014/01/31(金) 02:14:52.47
それで、「三回まわってワン」はまだ?
340デフォルトの名無しさん:2014/01/31(金) 02:16:21.04
>>336
これだから日本でiPhoneやGoogleグラスが生まれないんだよ
具体的な問題がないなら自分で作れよ
341デフォルトの名無しさん:2014/01/31(金) 02:18:10.08
人任せ
342デフォルトの名無しさん:2014/01/31(金) 02:18:11.26
>>339
3回まわってワン実行プログラムのアイコンをクリックするだけ
お前は文字しか使えないんだったよな
俺の勝ちだ
343デフォルトの名無しさん:2014/01/31(金) 02:18:40.65
>>340
具体的な問題がないことが
証明している。

これが最終結論でいいじゃないか?

俺はこの結論でいいと思っている。
その反論を俺がやるワケがないw
344デフォルトの名無しさん:2014/01/31(金) 02:19:34.34
あった!このブラウザゲーだ
http://armorgames.com/play/6061/light-bot-20
345デフォルトの名無しさん:2014/01/31(金) 02:19:34.37
> 3回まわってワン実行プログラムのアイコンをクリックするだけ
ということは
1回まわってワン、2回まわってワン、
4回まわってワン、5回まわってワン、
一兆個以上もアイコンが必要じゃねーかwwww
346デフォルトの名無しさん:2014/01/31(金) 02:20:15.13
>>343
誰もお前に頼んでねえよ
347デフォルトの名無しさん:2014/01/31(金) 02:21:16.77
>>346
彼が一番出来るプログラマかもしれないのにそりゃないだろ。
348デフォルトの名無しさん:2014/01/31(金) 02:21:22.97
>>344
これまさに(効率の悪い)
グラフィカルなプログラミング言語だね。
349デフォルトの名無しさん:2014/01/31(金) 02:21:40.93
>>345
コンフィグでテキストボックスに回数が設定出来るんだよ馬鹿が
350デフォルトの名無しさん:2014/01/31(金) 02:22:37.38
>>347
プログラミングできても考える脳がなきゃ意味は無い
所詮かれは支持されたものしか作れないのさ
351デフォルトの名無しさん:2014/01/31(金) 02:24:45.97
考える脳がある人「じゃぁ相応の金くれ」
352デフォルトの名無しさん:2014/01/31(金) 02:26:26.25
>>344
携帯だと見れないのか・・・
353デフォルトの名無しさん:2014/01/31(金) 02:27:01.74
>>349
それはすごく使いづらそうだね!
354デフォルトの名無しさん:2014/01/31(金) 02:44:53.59
日本製のプログラミングゲームもあるよ
http://home.jeita.or.jp/is/highschool/algo/index3.html
355デフォルトの名無しさん:2014/01/31(金) 03:10:46.47
>>331
効率がいいプログラミング言語ってのはデバッグと検証の時間も含めての効率だ
短時間でカスコードを書いてデバッグは人任せなんてのは速いとはいえない

他人がみたときに問題点の有無をすぐに指摘できて改造しやすいのが効率のいいコード
356デフォルトの名無しさん:2014/01/31(金) 03:17:11.98
アイコンだけで表現するなんて妄言はいてるヤツは
小学校の地図の勉強と中学校の電気回路の勉強をやり直せ
357デフォルトの名無しさん:2014/01/31(金) 04:49:45.16
ワンワンキャンキャンしつけえな
より直感的に出来るようにするにはどうしたらいいかってことだろ
浮かばない奴は黙っとけ
夢を語らせておけばいいんだよ
358デフォルトの名無しさん:2014/01/31(金) 05:31:38.44
まず、ユーザに1以上30以下の整数をひとつ、入力してもらう。これをnとする。
1〜nの整数を並べる。これをLとする。
※Lをシャッフルする。
Lが偶然にも大きいものから小さいものへの順に並んでいたら、何回シャッフルしたかをユーザに伝え、終了する。
順に並んでいなければ※に戻り、成功するまで何度でも繰り返す。

これをグラフィカルにプログラミングすると、どうなるん?
359デフォルトの名無しさん:2014/01/31(金) 06:07:53.86
> 典型的な日本人的発想だな
> これだから日本からGoogleグラスやiPhoneは生まれないんだ

これは使える
360デフォルトの名無しさん:2014/01/31(金) 08:27:17.07
ドラえもん!たいへんだ大変だ!とにかく大変なんだ!なんでもいいから早く出してよ!

ドピュ
361デフォルトの名無しさん:2014/01/31(金) 08:33:56.47
>>358
それをみんなで考えるスレだよ
362デフォルトの名無しさん:2014/01/31(金) 08:45:24.23
基本UMLやRADベースじゃないの?
文字ベースのほうが検索とか差分とか把握しやすいからコード部分はテキストだけでも編集可能で
グラフィカルなビュー・エディタを改善していく
でだんだん面倒になってリソースもUMLもテキスト指定・・・
363デフォルトの名無しさん:2014/01/31(金) 15:25:18.49
五線譜に落とせないかな
364デフォルトの名無しさん:2014/01/31(金) 18:20:34.97
「今日の22時に>>1にレスしなさい。」
これを図形で表現するところから始めて、日常会話まで図形で網羅していく。

生活に困らない程度まで図形で会話が成り立つようになったら、プログラミング言語に
取り組む。

こういう順番のほうが良くない?
365デフォルトの名無しさん:2014/01/31(金) 18:30:04.88
何いってんの?
366デフォルトの名無しさん:2014/01/31(金) 18:32:14.40
図形でプログラミングするんじゃないの?
367デフォルトの名無しさん:2014/01/31(金) 18:38:18.65
姉貴が高校くらいの時から美顔ローラって言うのを始めたんだよね。
ゲルマニウムとかいうやつ。
もともと結構不細工だったんだけど、やり始めてからだんだん肌がきれいになったんだよ。
数年経ったらなんか顔がすっきりしてきて、今や美人と認めざるを得ない感じになってきた。
ゲルマニウムってすごいなーって感心するわ。
こんなに変わるもんなんだ。
368デフォルトの名無しさん:2014/01/31(金) 18:39:52.28
キャラクタは図形に含まれますか?
369デフォルトの名無しさん:2014/01/31(金) 18:41:39.12
象形文字ならいいよ。
370デフォルトの名無しさん:2014/01/31(金) 18:45:15.59
ゆるキャラは図形ですか?
371デフォルトの名無しさん:2014/01/31(金) 18:55:09.23
図形化したらいいよ。
写真はダメだよ。
372デフォルトの名無しさん:2014/01/31(金) 22:44:46.99
紙に穴開けてプログラミングするのはどうだい?
文字なんてもう見るのが嫌なんだろう?
373デフォルトの名無しさん:2014/02/01(土) 08:51:14.55
頑張れ低能共
低能にしか浮かばないアイディアを活かし、
低能でも優秀な人を超えるプログラムを作れるようにするんだ
期待しているよ うふふ
374デフォルトの名無しさん:2014/02/01(土) 12:41:41.25
>>358
ためしにMITのスクラッチというグラフィカルな処理系で実装してみました。
http://scratch.mit.edu/projects/17354635/
375デフォルトの名無しさん:2014/02/01(土) 12:43:42.51
>>374
それ、日本語プログラミング言語の
コードを一行一行、色付き枠線でくくっただけじゃね?
376デフォルトの名無しさん:2014/02/01(土) 12:58:15.16
>>373
これどこ視点だよ
377デフォルトの名無しさん:2014/02/01(土) 13:27:19.29
確かに有能な人が作ると有能な人にしか使えない難しい言語が出来上がる傾向にある
Haskellとか
378デフォルトの名無しさん:2014/02/01(土) 13:55:45.76
言語作者の設計思想のなかに無能な人に使ってもらいたくないというのがあったのだろう。
379デフォルトの名無しさん:2014/02/01(土) 13:58:08.78
俺が理解されないのはみんな無能だからだ
380デフォルトの名無しさん:2014/02/01(土) 14:04:05.09
無能な人に使ってもらいたくないまでは思ってないだろうけど
バカに迎合してやるつもりはない位には思ってそう
381デフォルトの名無しさん:2014/02/01(土) 14:14:32.65
>>378
まあ、無能な人が使うツールは
有能な人が作ったツールだしね。

有能な人が使ってるツールを使わなければ、
有能な人になれないのは当然なわけで。
382デフォルトの名無しさん:2014/02/01(土) 14:22:42.34
>>377
Haskellは、言語の見かけの難易度/解決出来る問題の難易度、で言えば易しい方。
383デフォルトの名無しさん:2014/02/01(土) 14:31:19.71
スキルもコーディング慣習も異なる集団の共同作業を考慮して作っていない
というのが正しい
384デフォルトの名無しさん:2014/02/01(土) 14:34:55.22
あるシステムを改良するとして、無能な人のための改良が
有能な人の足かせになるのであれば
そんなのは改良とはよべない。

無能な人でも有能な人でも、両方便利になるならそれはいいこと。

で、有能な人にとって便利になるのであれば、
無能な人は切り捨てるよ。当然だろ?
無能な人は有能な人の頑張ってなればいいだけの話だけど
その逆は不可能なんだから。
385デフォルトの名無しさん:2014/02/01(土) 14:38:06.45
有能な人を切り捨ててでも、無能な人が便利になることを
目指しているツールもある。ようするに馬鹿向けツール。

そういう馬鹿向けツールを使ってる人は、
いつまでも成長できない。
386デフォルトの名無しさん:2014/02/01(土) 14:43:51.71
html作るのに有能なブログラマは必要ない。有能>無能ではなく有能<無能なこともある。
387デフォルトの名無しさん:2014/02/01(土) 14:44:23.15
一気に広がった言語って言うと、VB、PHP、Java、Javascriptとかなんだけど、
これらって、天才向け言語じゃないよね。
言語学者自身が成功するためには、ささやかな庶民向け言語が良いんじゃないのかな。
388デフォルトの名無しさん:2014/02/01(土) 14:49:23.11
>>386
おい、今はプログラマの話をしてるんだぜ?
そりゃソフトウェアではないものを
作る人は関係ないだろw
389デフォルトの名無しさん:2014/02/01(土) 14:50:04.71
PHPなんてダメ言語とか言われてるけど、すぐに欲しいものを自分で作れるんだから、
ダメ言語と言われても使っちゃうよね。
他の言語だと、必要なライブラリの学習から始めないといけないし。
下手したら完成する前に諦めるかも。
PHPならとりあえず動かすとこまでは行ける。
使いやすいライブラリの充実も言語にとって重要なんだろね。
PHPが良かったのは、(Windowsで運用するわけじゃないのに)Windowsで
単純に開発できること、(ありものを加工して添付してるだけなんだけど)
使いやすいライブラリの充実あたりなのかな。
390デフォルトの名無しさん:2014/02/01(土) 14:51:49.85
>>387

天才向け言語と
普通の人向け言語と
馬鹿向け言語があるんだよ。

それらの言語は普通のプログラマ向けの言語。
広がった言語っていうのは全部そう。RubyとかPythonとかもね。
普通のプログラマ向け。

馬鹿向けっていうのは、日本語プログラミング言語とか
マウスでぽちぽちつくれますー。みたいなやつ。
391デフォルトの名無しさん:2014/02/01(土) 14:55:47.67
>>388
html書くのが遅くて無能プログラマだと直接言われたことがある。
田町のあの糞システム会社早く潰れないかな。
392デフォルトの名無しさん:2014/02/01(土) 14:56:12.95
(利用者が最先端技術の研究のために使っていると主張することが多いので)
Pythonは天才向けでしょ。
Rubyはそうでもないけど、一気に広まった言語じゃないよね。
ていうか、広まったともいえないかも。
393デフォルトの名無しさん:2014/02/01(土) 14:59:48.11
>>391
うん、プログラマかどうかはともかく、
お前はHTML書くのが遅かったんだろう?
つまり、その会社で必要とされる仕事が遅かったんだろう?
394デフォルトの名無しさん:2014/02/01(土) 15:01:10.70
たとえば、連絡帳みたいな簡単なアプリ。

Pythonで作ったとかだと、ボケ、カス、Pythonを汚すなって言われるでしょ。
他の言語だとあまり反響が無い。
PHPだと、俺にも使わせてってなる。

この辺り使ってる人の層が違うんだよきっと。
395デフォルトの名無しさん:2014/02/01(土) 15:02:20.71
>>392
天才が使っているのと天才向けは違います。

天才は、普通のプログラム言語も使えます。

天才が使っているかどうかではなく、
普通のプログラマが使っているかどうかで、
普通のプログラム言語かどうかが決まります。

つまり、最先端技術や研究をしてないお前が使ってるのは
全部、普通のプログラム言語(もしくは馬鹿向け?w)ってことだよ。
396デフォルトの名無しさん:2014/02/01(土) 15:02:55.77
>>394
> Pythonで作ったとかだと、ボケ、カス、Pythonを汚すなって言われるでしょ。

聞いたこと無いな。ググって探してきて。
397デフォルトの名無しさん:2014/02/01(土) 15:03:13.55
でもそれは無能プログラマとは意味が違うよね
398デフォルトの名無しさん:2014/02/01(土) 15:04:42.97
プログラマの間で、広く使われている
プログラム言語を使えないのは無能。

当たり前だな。
399デフォルトの名無しさん:2014/02/01(土) 15:22:54.54
いや、397は>>393へのレスな
それとももしかしてHTMLがプログラミング言語だと思ってるのか
400デフォルトの名無しさん:2014/02/01(土) 15:24:32.63
>>395
ほほう、では最先端技術や研究をしていない俺が趣味で勉強がてら使ってる
Haskellはバカ向け言語?
天才向け言語があるなら教えてよ
俺が使ってあげるからw
401デフォルトの名無しさん:2014/02/01(土) 15:26:14.31
HTMLはプログラム言語ではなく
マークアップ言語。

プログラム言語ではないが、
ウェブ系の会社においてHTMLを
かけるのは必須技術

たとえばタイピング技術はプログラムとは関係ないが
プログラマにとって必須技術なのと同じこと。
402デフォルトの名無しさん:2014/02/01(土) 15:28:09.60
>>400
> ほほう、では最先端技術や研究をしていない俺が趣味で勉強がてら使ってる
> Haskellはバカ向け言語?

普通向け言語だろ?

天才向け言語なんて無いと思うよ。

誰が天才向け言語なんて言い出したんだか?w
>>387だね。
403デフォルトの名無しさん:2014/02/01(土) 15:30:24.38
>>401
タイピングが遅い立派なプログラマはいくらでもいる
404デフォルトの名無しさん:2014/02/01(土) 15:31:36.65
>>403
具体的に誰?
そしてどれくらいの遅さ?
キーボードを見ながら打つレベル?
405デフォルトの名無しさん:2014/02/01(土) 15:34:39.51
呼んだ?
406デフォルトの名無しさん:2014/02/01(土) 15:36:28.65
馬鹿には無理ってよく見かけるからさ。
PythonやJS使ってる人は、自分のことを天才だと思ってるんだと、
まあそんな風に見てたんだよ。
そうでもないの??
407デフォルトの名無しさん:2014/02/01(土) 15:36:29.55
>>404
有名人がタイプしてるところは見たことないんで、具体的に誰とは言えないだが、
回り見りゃ分かるじゃん
タイピングゲームやらせたら250打/分くらいの、タイピングが普通よりちょっと遅いかな
くらいで、平均以上のプログラマーはいくらでもいるし、
タイピングの速い無能プログラマーもいる
相関関係もあまりないんじゃないかな
408デフォルトの名無しさん:2014/02/01(土) 15:40:28.03
>>407
周りってそれお前の周り見た結果だろ?

HTML書くのが遅いお前のレベルが基準で、
周り見て遅いとか立派なプログラマって言ってるわけでしょ?

お前基準じゃなにも参考にならないな。
だから、有名人の名前を聞いたのに。
409デフォルトの名無しさん:2014/02/01(土) 15:41:22.55
>>406
いや、だからさ、

天才と普通と馬鹿がいるんだよ。

お前短絡すぎ。馬鹿じゃないなら
天才と言ってるように思えるんだろう?
410デフォルトの名無しさん:2014/02/01(土) 15:42:24.61
お前ごときが知っている有名なプログラマって誰よ?
411デフォルトの名無しさん:2014/02/01(土) 15:46:32.49
無理って言われてる人って馬鹿には見えないというか、まあ傍目には
割と賢そうに見えるので。
少なくとも対象ドメインについての知識は豊富そうな感じの時が多い。
でも、結構バカとかカスとか言われてるのを見かけるんだよね。

賢そうな人に対して、馬鹿には無理とか言ってるってことは、
俺って天才!だってPython使えるから!って思ってそうな予感がしてくるんだよー。
412デフォルトの名無しさん:2014/02/01(土) 15:47:16.42
>>408
とりあえず、HTML書くのが遅いと言ってるのは俺じゃねえけどw
反論してる奴は全部同一人物だと思うのやめた方がいいぞw

まあ、HTMLなんてたいてい既存のやつをコピペするよなw
emmet使いこなせば早いけど、そんなのは経験が少なくて蓄積コードがない
やつくらいだろ
なんにせよ、javascript書いてる時間の方が圧倒的になげーよw
413デフォルトの名無しさん:2014/02/01(土) 15:49:17.10
それに対してPHPは、PHPでゴメンナサイって感じが伝わってくるんだけど、
動くから良いじゃん、便利だよありがとって素直に思えるんだよー。

Pythonの場合、天才の俺は庶民が使うものなど作らん!!って感じなんだよー。
だって動くものってほとんどPHPで出来てて、Python製って見かけない。
414デフォルトの名無しさん:2014/02/01(土) 15:54:49.97
>>412
コピペするから何なんだ?
コピペするなら速いだろう?
まさかコピペ出来ないから遅いって言う訳じゃあるまいし。
415デフォルトの名無しさん:2014/02/01(土) 15:55:11.13
そろそろ結論が出たようですね。

最強のグラフィカル言語は、マクロの記録だったようです。
まだ二月になったばかりですが、本年の最優秀グラフィカル言語処理系の栄誉を
Excelに贈りたいと思います。

ご清聴ありでした。
416デフォルトの名無しさん:2014/02/01(土) 15:55:33.44
>>413
【俺がそう思ってるんだ」って
熱弁されても困るw

お前がそう思っているからって
それが世界の常識というわけじゃない。
417デフォルトの名無しさん:2014/02/01(土) 15:56:27.45
>>414
だから、HTMLが遅いって言ってる奴はコピペが使えない事情があったんだろ
でも無能プログラマかどうかは判断できないよね
だって関係ないんだから
418デフォルトの名無しさん:2014/02/01(土) 15:56:46.61
そろそろ世界の常識になりつつある。
419デフォルトの名無しさん:2014/02/01(土) 15:58:41.92
天才用言語で書けるのはコードの断片まで。
完成された商品にはならない。
420デフォルトの名無しさん:2014/02/01(土) 15:58:59.27
まあ、この板で一人のPython信者がPythonは天才だとか素晴らしいとか主張してるのは知ってるよ
確かこいつはJavascriptが嫌いだと思う
でも、そいつ一人がそう言ってるだけじゃないかな?

それ以外の世界ではPythonは有名なLLの一つ程度の認識でしょ
421デフォルトの名無しさん:2014/02/01(土) 15:59:10.22
>>417
コピペが使えない事情が合ったというのなら、

そもそもお前が言った「まあ、HTMLなんてたいてい既存のやつをコピペするよなw 」が
使えないってことだろ?

つまりは、HTMLを一から書くのが遅いってことだろ?
それウェブ系プログラマにとって致命的な技術力不足だよ。
422デフォルトの名無しさん:2014/02/01(土) 16:00:28.48
>>421
つまり、以降が違うね
その事情のもとにおいて遅いだけなんだから
致命的な技術力不足とやらは全く違うと思うよ
423デフォルトの名無しさん:2014/02/01(土) 16:02:19.82
弘法筆を選ばずというけれども、弘法大師の残した筆コレクションを見れば
どれだけツールにこだわっていたかわかるというものです。
424デフォルトの名無しさん:2014/02/01(土) 16:02:38.20
大体さ、HTMLが遅くたって、30分が一時間になるとかその程度だろ?
一方、Javascriptが遅かったら、4時間が8時間になるぞ
致命的かどうかで言ったら前者なんて誤差の範囲だと思わんか?
425デフォルトの名無しさん:2014/02/01(土) 16:03:51.85
思いませんね。
いや、全然思わない。
426デフォルトの名無しさん:2014/02/01(土) 16:04:33.40
へー、俺は4時間損する方が30分損するよりよっぽど致命的だと思うけど
そう思わない人もいるんだ
へーw
427デフォルトの名無しさん:2014/02/01(土) 16:05:41.49
>>422
その事情っていうのは、
「一からHTMLを書くこと」なわけ?

つまり、既存のものを修正することは出来ますが、
一から作ることは出来ません。

っていいたいの?
428デフォルトの名無しさん:2014/02/01(土) 16:07:38.93
>>424
JavaScriptとHTMLの両方に優れている人は、
JavaScriptだけしか出来ない人に比べて
30分も速いですね。

一日30分が1ヶ月20日あれば10時間です。
429デフォルトの名無しさん:2014/02/01(土) 16:08:20.55
>>427
さあ、本人じゃないからどんな事情なのか分からんけど、
HTMLが遅いとかなんとか言ってるんだから、当然
コピペで終わるような状況じゃなかったってことは想像つくってぐらいかな
まあ、既存と全然違うデザインだったとかで一から作る必要があったんだろうね
で、タグの詳細仕様とかあやふやで調べながらやったとか、そんな感じだろ
430デフォルトの名無しさん:2014/02/01(土) 16:08:56.02
虚しく往きて実ちて帰るという弘法大師の言葉を振り返ってなお4時間に
こだわりを持てますか?
431デフォルトの名無しさん:2014/02/01(土) 16:09:37.83
>>428
そうですね。でもJavaScriptが得意な人はもっと速いですね。
無能プログラマかどうかを判断するなら総合的に見ないとね
432デフォルトの名無しさん:2014/02/01(土) 16:10:42.45
総合的な判断にはチャートグラフが便利です。
ここでもまたExcelの実力が証明されるわけです。
433デフォルトの名無しさん:2014/02/01(土) 16:12:29.41
ウェブプログラマならHTMLをかけるのは当然。
たった100個程度しかないタグぐらい覚えてるだろ。
それが遅いならやっぱり技術力ないってことだな。

あとなあえて今まで言ってなかったけど、
ソースコードと違ってHTMLは使いまわすものじゃないぞ。
たいてい一から書くものだ。使いまわすのはmetaタグぐらいなもんだろ。
434デフォルトの名無しさん:2014/02/01(土) 16:13:32.83
100ページのサイトを手書きで作るなら、90ページは使いまわす。
435デフォルトの名無しさん:2014/02/01(土) 16:14:26.96
普通はそこでテンプレートを使う。

HTMLを書くのが遅いというのは
テンプレート1枚を書くのが遅いという意味だろう。
436デフォルトの名無しさん:2014/02/01(土) 16:15:17.10
>>433
いや、使い回すもんでしょ
Webフレームワークは大体テンプレート機能もってて、たいていテンプレートは使い回しだし
HTML5boilerplateとか知らないの?
まあ、こいつはコピペどころか、オート生成だけどさ
437デフォルトの名無しさん:2014/02/01(土) 16:16:43.52
>>435
その場合、もっとインパクトは少なくなるよな
438デフォルトの名無しさん:2014/02/01(土) 16:16:47.59
>>436
おい、意味が違ってるぞ。
お前が言ってるのは、テンプレートをコピペするって話じゃないだろ。
テンプレートは一つで、それを使ってHTMLを生成するって話だろ。
439デフォルトの名無しさん:2014/02/01(土) 16:17:39.10
>>437
インパクトの大小は関係ないでしょ?

ウェブプログラマに必須の技術が
遅いって言われてるんだから。
440デフォルトの名無しさん:2014/02/01(土) 16:17:39.96
>>438
まあでも本質は同じだよ
揚げ足取りの類い
まあしかし、テンプレートもテンプレートのコピペが多いかなw
441デフォルトの名無しさん:2014/02/01(土) 16:17:47.39
サンプル数が100点を超えたのでそろそろ判定結果を発表します。

総合評価
☆★★★★E

講評
あなたがそう考えるのは心の弱さです、自分を見つめなおしましょう。
442デフォルトの名無しさん:2014/02/01(土) 16:18:21.51
>>439
関係あるだろ
インパクトが少ないなら必須でも
遅くていいんじゃない?
出来ない訳じゃないんだし
443デフォルトの名無しさん:2014/02/01(土) 16:18:28.10
>>440
前提が間違ってる。

そのテンプレートがコピペ出来ないって状況、
つまり一からテンプレートを書くのが遅いって話だろ。

テンプレートはコピペしないぞ。
同じものをそのまま使うものだ。
444デフォルトの名無しさん:2014/02/01(土) 16:19:33.81
>>443
テンプレートだって、部分部分はコピペだったりするでしょ
まあ、理想的にコンポーネント化されてたらそうはならないだろうけどさ
445デフォルトの名無しさん:2014/02/01(土) 16:19:37.48
>>442
それ技術力が低い奴がよく言ういいわけだよ。

できなくてもいいじゃない。別に対して時間かかってないんだから。

そういって、鍵も使わずにSSHログインで
毎回パスワード入力している人がいるぞ。
446デフォルトの名無しさん:2014/02/01(土) 16:20:12.93
テンプレートを修正して保存すると、自動的にサイトへ反映されます。
しかしこの重さ、どうにかならないものだろうか。
447デフォルトの名無しさん:2014/02/01(土) 16:20:25.92
>>445
もし、それでも総合的に時間かかってないなら、有能なんじゃないの
448デフォルトの名無しさん:2014/02/01(土) 16:21:39.44
時間かかってないとかが問題じゃなくて
基礎的なことを理解していないっていうのが問題なんだよ。

できないのに、理解しているってことはまず無い。
理解があやふやだから、間違ったことをする。

HTMLを書くのが遅いっていうのは、HTMLを理解していないわけで、
HTML5どころか、未だにCSSを使わないテーブルタグによる
レイアウトをしていると思われる。
449デフォルトの名無しさん:2014/02/01(土) 16:22:30.33
二チャンネルでビジュアル言語を開発したら、ビジュアル・インパクト・A(エース)と
名前を付けましょう!
絶対つけましょう!
450デフォルトの名無しさん:2014/02/01(土) 16:23:30.20
>>447
いやw

鍵を使ってないだけではなく、
SSHそのものを理解していない。
だからSSHに関すること全てができない。

こういう奴が更に応用技術出来ると思う?
当然できませんでした。

面倒だったよ。AWSの認証周りを理解させるのに。
(たぶん今でも完全に理解していない)
451デフォルトの名無しさん:2014/02/01(土) 16:24:10.82
>>450
あなたの周りはバカばっかりですね。
452デフォルトの名無しさん:2014/02/01(土) 16:24:32.70
>>451
はい、俺以外は馬鹿ですw
453デフォルトの名無しさん:2014/02/01(土) 16:25:14.31
お察しいたします。
チーソ
454デフォルトの名無しさん:2014/02/01(土) 16:26:37.25
>>448
俺は正直問題だと思わないなあ
例えば、最近までバックエンドのJavaプログラマはJavascriptを知らない人多かったけど
別に無能とまでは思わないしね
HTML理解してるけど、タイピングが遅くてEmmet知らないから遅いだけって可能性もあるな
ちなみにIE7以前ならテーブルタグによるレイアウトは普通に有効だと思うけど
455デフォルトの名無しさん:2014/02/01(土) 16:26:38.38
たいてい、「遅くてもいいいじゃん、そんなに時間かかってないんだし」とか言い訳してる奴は

だいたい時間かかっていて遅くて迷惑かけてるんだよね。
456デフォルトの名無しさん:2014/02/01(土) 16:28:25.27
>>450
SSHの認証周りに関しては無能なんだろうなとしか思わんけど
そいつがJavascriptはバリバリに出来るなら、フロントエンドプログラマとして有能だと思う
457デフォルトの名無しさん:2014/02/01(土) 16:29:03.12
>>454
そりゃ、仕事でやる必要がないことが
できなくても問題じゃないでしょw

だが仕事でやる必要がある以上出来ないとだめだ。

それがいやなら「それは俺の仕事じゃない」と
拒否することだね。
458デフォルトの名無しさん:2014/02/01(土) 16:30:38.11
>>455
パレートの法則やボトルネックを理解してる有能なプログラマかも知れんよ
lodash.jsの作者も、部分部分の些細な最適化していないことに関して同じこと言ってたわ
459デフォルトの名無しさん:2014/02/01(土) 16:32:21.41
>>457
でも今の話は、「無能プログラマ」かどうかだろ?
お前が言ってるのは「無能そのチームの一員」だろ
460デフォルトの名無しさん:2014/02/01(土) 16:34:11.99
>>456
だからそういうことだよ。

JavaScriptを使う仕事であれば、JavaScriptができなければ
有能にはならない。

それと同じでHTMLをやるような仕事である以上、
HTMLができなければ、有能ではない。


ついでに行っておくと、今のフロントエンドプログラマは
JavaScriptの圧縮結合でnode使って
CSSを効率化するためにLESSやSASSを使ったりしている。
その為にLinuxも使うからSSHも普通に使っていたりする。

だからJavaScriptがバリバリに出来るだけでは、
JavaScriptプログラマとしいて有能であっても
フロントエンドプログラマとしては有能にはならない。
461デフォルトの名無しさん:2014/02/01(土) 16:36:27.27
ウェブなんて馬鹿でもできるから広まったんだろ。
ウェブやってるやつがバカとか賢いとか言っててむなしくない?
単純労働に知恵なんか必要ない。
ほんとバカ!なんて馬鹿!
なるほど、馬鹿だからウェブなんかやってるのか!
462デフォルトの名無しさん:2014/02/01(土) 16:36:28.72
>>459
だから最初から言ってるだろ?
「ウェブ系プログラマ」としてって。

ウェブ系プログラマなら当然HTMLも使うんだよ。
463デフォルトの名無しさん:2014/02/01(土) 16:37:37.57
>>460
だから、それも「無能その仕事をする人」であって、
「無能プログラマー」ではないってこと
お前は配管工の仕事が要求される職場で配管作るのが苦手だったら
「無能プログラマー」だと思うのか?
俺は、HTMLはプログラミング言語じゃないと思うし、
多少それが苦手でも無能プログラマーじゃない奴はたくさんいると思う。
あと、LESSやSASS使ってるようなワークフローなら、Yoeman使って
Scafoldして、ReactみたいなフレームワークでHTML隠蔽してるかも知れんぞ
464デフォルトの名無しさん:2014/02/01(土) 16:38:24.71
>>462
使うけど、割合的にはjavaScriptに比べてずっと少ない
重要性が少ないと言ってるわけ
465デフォルトの名無しさん:2014/02/01(土) 16:43:12.30
>>464
重要性は高いぞ?

HTMLとCSSのデザイン分離の考え方を理解していなければ、
JavaScriptから直接色を変えたりとかアホか事をする。
466デフォルトの名無しさん:2014/02/01(土) 16:44:33.67
>>465
デザイン分離のコンセプトを知らないかどうかと
HTML書くのが遅いかどうかはまた別だと思うぞ
むしろ、そういうのを知ってる奴はclass属性みてるだけで
タグの詳細に疎い傾向にあるかも知れんな
467デフォルトの名無しさん:2014/02/01(土) 16:46:56.65
HTMLを理解して慣れてないと
HTMLとCSSで出来るようなことを
JavaScriptでやったりするんだよな。
468デフォルトの名無しさん:2014/02/01(土) 16:51:13.13
そもそもさ、HTML書くのが遅いとか叱られる職場って
どうせ、むちゃくちゃ低レベルな職場だろ?
で、CSSもJSもへったくれもない状況で本当に低レベルなHTMLを一から書かされて、
無能だと言われたんだろ
本人じゃねえから、事情知らねーけどさw
469デフォルトの名無しさん:2014/02/01(土) 16:57:26.22
>>468
本人だけどそんなところだ。月収6万。そこを辞めて次の職場では月収55万だった。
470デフォルトの名無しさん:2014/02/01(土) 17:00:36.64
>>469
お、おう
そうなのかw

まさに地獄から天国って感じだな。おめでとうw
471デフォルトの名無しさん:2014/02/01(土) 17:03:37.00
月収6万って手取り?さすがに手取りだよな
てことは、55万も手取りか?すげえw
472デフォルトの名無しさん:2014/02/01(土) 17:38:18.33
ごめん、点をうち忘れた。
473デフォルトの名無しさん:2014/02/01(土) 17:39:07.39
>>413
WindowsでもBlender, Inkscape, TortoiseHg辺りはPython使ってるみたいだが
ちなみに手元のUbuntuで削除しようとしたら、大量のパッケージに削除マークが付けられたんだが?
gdm, gnome-shell, compiz, gksu, ibus, software-center, unity...
もしPython削除したら、環境まるごと入れ替えが必要になりそうだなあ
ああ、別に高尚なもんだけじゃないぞ?伺かクライアントとかあったし
474デフォルトの名無しさん:2014/02/02(日) 00:51:59.43
電子回路がプログラミングっていうのはおもしろい視点だな
475デフォルトの名無しさん:2014/02/02(日) 00:56:24.03
ソフトウェアで実現可能なことはハードウェアでも実現可能だからな
たぶん
476デフォルトの名無しさん:2014/02/02(日) 00:57:28.63
普通
477デフォルトの名無しさん:2014/02/02(日) 01:25:30.99
再帰呼び出しするハードウェアとかめちゃくちゃ難しそうだな
呼び出される回数分だけ物理的にハードウェアを用意するかw
478デフォルトの名無しさん:2014/02/02(日) 01:27:21.95
そうだね
479デフォルトの名無しさん:2014/02/02(日) 01:56:20.88
>>474-477
以下の教科書では、そういったハードウェアの設計技法を解説している

5章 レジスタ計算機での計算 - 計算機プログラムの構造と解釈 第二版
  http://sicp.iijlab.net/fulltext/x500.html

このスレ向きのデータフロー図を直リンする
・図5.4 入力を読み込み結果を印字するGCD計算機
  http://sicp.iijlab.net/fulltext/fig504.png
・図5.11 再帰的階乗計算機(>>477)
  http://sicp.iijlab.net/fulltext/fig511.png

また、関数型言語の計算モデルを視覚化したものとして、
ヘンダーソン図というものも紹介されている(>>193)
・図3.31 信号処理システムと見た素数の篩(いわゆるアルキメデスのふるい)
  http://sicp.iijlab.net/fulltext/fig331.png
  http://sicp.iijlab.net/fulltext/x352.html
480デフォルトの名無しさん:2014/02/02(日) 08:50:25.86
【コラム】一攫千金を狙うならギャンブルよりもプログラムがオススメ ひろゆき (SPA!)
http://lolen235.blog.fc2.com/blog-entry-1123.html
481デフォルトの名無しさん:2014/02/02(日) 12:31:15.45
ズームアウトしたらグラフィカル、ズームインしたらテキスト、なIDEが有ればいいと思うんだ。
つまり、書く時はテキスト、眺める時はグラフィカル。
482デフォルトの名無しさん:2014/02/02(日) 20:05:48.36
>>481
それだったらリスト化されてた方がいいな
483デフォルトの名無しさん:2014/02/03(月) 01:19:20.44
ズームアウトしていくと括弧の深いレベルからどんどん非表示になっていく
ようなものってあるのかな。
484デフォルトの名無しさん:2014/02/03(月) 01:39:36.77
そんなんPythonならインデントレベルの深さに合わせて
折り畳むだけで出来るな
485デフォルトの名無しさん:2014/02/03(月) 02:08:52.97
>>484
インデントレベルは意味的な深さとイコールではないから
その実装は簡単だけど意図に沿っているとはいいにくいな
486デフォルトの名無しさん:2014/02/03(月) 02:12:01.81
>>481
アセンブラでそんな感じに紙に書いたことはある
近づいたらテキスト、離れたらグラフィカルw
消しゴムで書きかえながらレジスタチューニングしていたが
カレンダー一枚の裏からはみ出たら途端にわかりにくくなったww
487デフォルトの名無しさん:2014/02/03(月) 02:14:32.52
とにかくどの言語もコメントが書きにくい
どこからどこまでが何の処理なのかわかるようにして欲しい
四角で囲ったり色分けできたり
488デフォルトの名無しさん:2014/02/03(月) 02:15:06.17
>>487
それは関数やメソッドを切り分けるべきなんじゃないのか
489デフォルトの名無しさん:2014/02/03(月) 02:37:11.17
>>485
>>483が言う括弧の深さとは等しいだろ
意味的な深さなんて恣意的に決まるモノはともかくな
490デフォルトの名無しさん:2014/02/03(月) 03:01:42.43
20年前にBTRONで実現できてた話だが、ソースコードがハイパーテキストで、
文字を装飾したり、説明文書にリンクしたり、絵を混ぜたり出来た。

今実装するなら、Wordの*.docxファイルをソースコードとして使えるようにするとかかな。
491デフォルトの名無しさん:2014/02/03(月) 10:00:08.35
>>490
NEXTSTEPではシェルスクリプトでマークアップ出来てた気がする
492デフォルトの名無しさん:2014/02/03(月) 10:09:18.35
それビューワーの問題だろ
493デフォルトの名無しさん:2014/02/03(月) 18:30:47.47
NeXTのはWindowsのワードパッドに相当するText.appで書いたリッチテキスト
形式のファイルをシェルスクリプトがプレーンテキストと同じように解釈して
実行できた、とおもう。ワードで書いてそのまま実行できるようなもの。
エディタから実行できるわけじゃない。
ターミナルアプリでcatしたときにリッチテキスト表示されたかまでは覚えてない
494デフォルトの名無しさん:2014/02/04(火) 00:43:44.28
群衆プログラミングというのはどうだろう
それぞれ自律して動くエージェントを大量に用意して、それぞれのエージェント達に簡単な命令を与えて行く
そうすることで群衆が命令に対する目的に応じて組織的に最適解を求めていく
そんなプログラミング手法どう?
495デフォルトの名無しさん:2014/02/04(火) 00:44:40.17
あげ
496デフォルトの名無しさん:2014/02/04(火) 00:59:29.82
そして互いに矛盾する命令を与えられた集団同士が
それぞれの正義を掲げて○しあう悲劇
497デフォルトの名無しさん:2014/02/04(火) 01:04:01.11
つまりそれこそが種としての最適解
498デフォルトの名無しさん:2014/02/04(火) 01:18:34.76
凶暴な種は滅びる
定めじゃ(ご冥福を)
499デフォルトの名無しさん:2014/02/04(火) 01:24:24.79
人間がコードをひたすら書いていく作業はもう古い
人間の命令に対して自律して判断し目的を達成するエージェントシステムが理想に近い
500デフォルトの名無しさん:2014/02/04(火) 01:32:07.50
500だもん
501デフォルトの名無しさん:2014/02/04(火) 02:02:09.76
プログラマも人間ですよね?
502デフォルトの名無しさん:2014/02/04(火) 05:51:05.17
学習用だったかで、カルネージハートみたいな命令チップを並べる様なのはあったな

1つのチップは命令チップの集合体で、その中のチップ1つも命令チップの集合体で…
ってな感じでメタ的な構造にするとか
503デフォルトの名無しさん:2014/02/07(金) 20:59:18.13
ttp://internet.watch.impress.co.jp/docs/news/20131218_628113.html
>株式会社CA Tech Kidsは、小学生向けのプログラミング学習用教材を2014年1月16日までの期間限定で無償公開する。

プログラミング学習用教材ロボット BeautoRacer(1)
ttp://www.eleki-jack.com/KitsandKids2/2009/08/71beautoracer1.html
ttp://www.eleki-jack.com/KitsandKids2/cat137/cat538/
504デフォルトの名無しさん:2014/02/08(土) 11:57:27.62
http://kohada.2ch.net/test/read.cgi/prog/1190866177/816
  ↑  ↑  ↑   ↑  ↑  ↑
505デフォルトの名無しさん:2014/02/09(日) 14:30:39.52
3Dグラフィックスの世界ではもはやプログラミングは不要みたいだな。
506デフォルトの名無しさん:2014/02/09(日) 14:39:22.72
マジで?何を使って作ってるの?
507デフォルトの名無しさん:2014/02/09(日) 15:50:29.36
いやLightWave使いの人になにかエフェクト作りますと言ったら、イラネと言われたから。
508デフォルトの名無しさん:2014/02/09(日) 21:48:14.09
3DCGデザイナーからしたらいらんわそりゃwCGソフトでやれるんだしwww
フォトショとかイラレ使いの2Dデザイナーに同じような事言ってもイラネって言われるよwww
どんだけ時代に取り残されてるんだよwww
509デフォルトの名無しさん:2014/02/09(日) 22:18:55.49
3DCGで言えば、ノード繋いでプロシージャルテクスチャを設定していくのなんて、グラフィカルプログラミングってものに近い気がするな。
510デフォルトの名無しさん:2014/02/12(水) 19:21:09.27
ちょっと >>507 クンこんなことで遊んでないで早くイラネ作ってよ 待ってるんだから
511デフォルトの名無しさん:2014/02/12(水) 22:04:17.28
ここまでPiet無し
512デフォルトの名無しさん:2014/02/13(木) 08:01:37.22
>>1
障害者が訴訟を起こします
513デフォルトの名無しさん:2014/02/13(木) 14:08:40.71
俺が作ってやるよ
514デフォルトの名無しさん:2014/02/13(木) 19:24:17.40
いや俺が作ってやるよ
515デフォルトの名無しさん:2014/02/14(金) 08:49:50.03
じゃあ俺がつくる
516デフォルトの名無しさん:2014/02/14(金) 20:19:05.86
>>515
どうぞどうぞ!
517514:2014/02/14(金) 20:50:28.45
>>515
おねしゃす! 作りながらうp頼んます!
518デフォルトの名無しさん:2014/02/14(金) 22:26:20.16
絵よりも文字のほうが後に発明された。
情報を記録する上で高度な道具は文字の方。
519デフォルトの名無しさん:2014/02/14(金) 23:35:34.10
絵の方が遥かに労力かかるしな
520デフォルトの名無しさん:2014/02/14(金) 23:40:04.46
パソコンならクリック一つだけどな
521デフォルトの名無しさん:2014/02/15(土) 00:19:06.74
>>520
それが絵?暗号かと思った
522デフォルトの名無しさん:2014/02/15(土) 01:22:55.78
RPGツクールみたいな用途を限定したものなら、出来ると思うけど
限定しないと難しいよな。

>>515 に期待するのみだわ
523デフォルトの名無しさん:2014/02/15(土) 06:43:41.18
逆に難しい部分ってどこよ
基本的な文法はカルネージハート方式でも十分じゃん?
524デフォルトの名無しさん:2014/02/15(土) 07:13:01.57
軽ネジ&hearts;法師貴ってなんですか?
525デフォルトの名無しさん:2014/02/15(土) 13:26:26.91
>>523
ディティール部分、細かくなるほど難しくなると思うよ。
RPGツクールは、パラメーターからグラフィックまで全部フォーマット用意して
それを組み立てていくでしょ。この方式は細かい部分はモジュールになっていて、単に組み立て方をオリジナルに出来てその要素だけ自由でしょ。

プログラムはその制約が無い分、わからない人にはわけがわからない。
簡単にするということは、制約を作ることじゃないの?

HTMLエディターも同じような感じじゃん。
HPビルダーとかプレビューだけで作るとソースが無茶苦茶でディティールまで制御出来ない。でも簡単みたいな。
ソースだけで作れると、不自由に感じる部分で素人からしたら、簡単になる。

どこをトレードオフするかってなると、そこしかないハズ。
526デフォルトの名無しさん:2014/02/16(日) 01:02:06.00
HTMLエディタがおかしくなるのはブラウザのせいであって
ホームページビルダーのせいにするのはかわいそう・・・

出力先が紙であるソフト(Quarkなど)はかなり細かく作りこめるしな
527デフォルトの名無しさん:2014/02/16(日) 09:24:51.70
>>526
ブラウザ関係なくね?吐くソースがおかしいんだから。
528デフォルトの名無しさん:2014/02/16(日) 18:10:52.15
ソースが見苦しいってだけの話だろ
だからDSLとグルーと汎用プログラミングをごっちゃにするのはやめろと
529デフォルトの名無しさん:2014/02/16(日) 22:43:53.47
ソースの構造ではなくてむしろ処理の流れがわかりやすくなるようなもの作ってほしいな
デバッグしやすそうなやつ
もしくはバグが起こりにくそうなやつ
530デフォルトの名無しさん:2014/02/16(日) 23:03:28.77
関数型言語でいいじゃん
531デフォルトの名無しさん:2014/02/17(月) 01:24:40.23
>>530
やだよ
532デフォルトの名無しさん:2014/02/17(月) 06:43:02.45
いままでの流れをドラえもんでたとえると。
「ドラえも〜んしずかちゃんとやりたいよう〜」
「とりあえず告白すれば?」
「やだよ」
533514:2014/02/17(月) 06:43:51.98
>>532
どっか消えてくれ
534デフォルトの名無しさん:2014/02/18(火) 00:21:01.19
>>532
やりたいと付き合いたいは根本的に違う
535514:2014/02/18(火) 06:11:55.53
俺は本当に浮かんでるんだが
他に浮かんでる奴がいれば、いくらあれば作る?
俺なら200万円は最低でも欲しい
536デフォルトの名無しさん:2014/02/18(火) 08:06:03.60
つきあわなくても、やれればいいな
537デフォルトの名無しさん:2014/02/18(火) 13:55:16.23
アイディアなんか誰でも持ってる。それを矛盾なく実現するのが遥かに難しい。
538デフォルトの名無しさん:2014/02/18(火) 14:04:17.95
>>537
ドカタの発想
539デフォルトの名無しさん:2014/02/18(火) 14:13:50.81
ドカタの妄想
540デフォルトの名無しさん:2014/02/18(火) 15:48:32.72
>>538
非ドカタの驕り
非ドカタのおまえは浮かんでるだけだが、ドカタのこっちは完成寸前だ。この差は天と地ほどもある。
これはもはや天地逆転だな。
541デフォルトの名無しさん:2014/02/18(火) 16:27:17.73
誰も思いつくもの作ってるのね、乙
542デフォルトの名無しさん:2014/02/18(火) 16:39:57.59
心の安静を得るためにそう思いたいんだろ。
非ドカタにできるのはせいぜいドカタの頭を叩くこと。他は何も成せない。
543デフォルトの名無しさん:2014/02/18(火) 22:31:23.02
俺もアイデアを持っているんだが、
>>514よ。俺に出資してくれ。
544デフォルトの名無しさん:2014/02/18(火) 23:07:56.94
出資?なぜ開発に金がいるんだ?
休日か仕事終わりに作業すればいいんでないの?
会社やめて開発に専念したいから生活費くれってことか?
545デフォルトの名無しさん:2014/02/19(水) 01:41:16.47
何をするにも金が要る
そのくらい子供でも分かる
546514:2014/02/19(水) 16:24:54.08
543とか544は低能っぽい
547デフォルトの名無しさん:2014/02/19(水) 21:29:27.30
>>545
売れるもん作りゃいいだろ
548デフォルトの名無しさん:2014/02/19(水) 21:45:09.73
ネットで出資金募れるサイトあるよね
549デフォルトの名無しさん:2014/02/19(水) 23:10:01.73
>>548
だから出資って何に金がかかるの?
開発を委託すんの?
550デフォルトの名無しさん:2014/02/19(水) 23:37:24.93
絵空事いうプログラマ
551514:2014/02/20(木) 00:28:00.56
質問厨って煩わしいな
自分で考えろって話
552デフォルトの名無しさん:2014/02/20(木) 01:14:31.30
答えられないから逃げちゃった
553デフォルトの名無しさん:2014/02/20(木) 01:38:50.67
見積りも出来ない
554514:2014/02/20(木) 06:34:31.95
低能共はもっと生産的な頭を働かせろよ
生きる道が無くなってしまうぜ
555デフォルトの名無しさん:2014/02/20(木) 07:58:03.52
生産財は無料が原則だろ
ブルジョワのブタども
556デフォルトの名無しさん:2014/02/20(木) 11:35:12.55
>>554
もっと前に言って欲しかった
遅いわ
557デフォルトの名無しさん:2014/02/21(金) 20:35:08.26
>>555
と、絶対王政時代で頭の進化が止まってるエセ左翼は、今日も喚くのだあった。
558514:2014/02/22(土) 00:33:04.70
>>555みたいな奴って大概もらう権利だけ主張して
自分は何もしないという まさに圧倒的クズタイプが多いよな
まあそういう人間でいたいならそうしたらいいんじゃない
559514:2014/02/28(金) 18:30:36.23
もうちょっとスレ伸ばし頑張れよ
残ってるプロジェクトが全部終わって万が一時間余れば作ってやるからよ
560デフォルトの名無しさん:2014/03/02(日) 09:46:52.38
561デフォルトの名無しさん:2014/03/02(日) 10:21:40.13
>>560
フリーフォーマットだとこういう風にごちゃごちゃするから
やっぱ碁盤上にしたほうがいいと思うんだよ
562デフォルトの名無しさん:2014/03/02(日) 17:27:43.06
>>561
つ Excel
563514:2014/03/02(日) 18:48:24.79
フリーフォーマットもやり方しだいだろうな
564デフォルトの名無しさん:2014/03/02(日) 20:36:00.09
>>561
こういう方がスッキリしてるな
http://www.cadcamcube.jp/image/cadlusdesign01.jpg
565デフォルトの名無しさん:2014/03/02(日) 22:08:36.22
文字と図形
代数と幾何
コマンドラインとGUI
とういう構図がプログラミングにもあっていいよな
566デフォルトの名無しさん:2014/03/02(日) 22:24:23.16
まだGUIはCUIの完全な代替にはなってないんだよなあ
アプリ同士の連携やバッチが弱い
567デフォルトの名無しさん:2014/03/03(月) 07:01:40.93
prographCPXとか最初に出てるのにスルーしてんな。
http://ja.m.wikipedia.org/wiki/Prograph_CPX

Martenとかまだ動くはずだが。
http://www.andescotia.com/products/marten/
568デフォルトの名無しさん:2014/03/03(月) 07:07:41.43
Visual Studioにでもそういうの搭載されれば
569デフォルトの名無しさん:2014/03/03(月) 20:25:55.58
Prographは最初Mac用のフリーソフトで商用版がPrographCPXとして販売開始
ちょうどWindowsが広まった頃にWindows版を作った辺りで会社が消えた。
だもんで権利がどうなってるのかよくわからないので消えっぱなし。
MartenはPrographCPXのクローンみたいなの。

内容としてはオブジェクト指向でオブジェクトをアイコンで管理
アイコンのコード部を開くとパーツを置くGUIが開いて
上からの引数が流れてきて処理パーツに入り処理を済ませて下に流れてゆくデータフロー形式。

正直、あの「クラスのアイコン管理」は他の言語も取り入れて欲しいなぁ…
570デフォルトの名無しさん:2014/03/04(火) 08:33:18.24
言語じゃなくてエディタでいいだろ
571デフォルトの名無しさん:2014/03/05(水) 07:31:52.56
グラフィカルなエディタない?
572514:2014/03/05(水) 10:05:18.01
俺の発想もそれだが
見つからないならお前が作れよ
573デフォルトの名無しさん:2014/03/05(水) 14:50:02.37
574デフォルトの名無しさん:2014/03/07(金) 21:12:00.38
vvvvがまだ出て無いとか
575デフォルトの名無しさん:2014/03/09(日) 02:35:11.48
現在プログラム板のID制導入の投票を実施中です
よろしくお願いします

プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/
576デフォルトの名無しさん:2014/03/13(木) 12:17:26.62 ID:3qw6PUNb
思うんだが、これは注目するレベルに応じてビューを切り替えた方がいい。
マクロレベルではオブジェクトグラフ、オブジェクト内部はコールグラフ、そして各メソッドの実装と。
つまり3つのレイヤーでプログラムを表現できればいい。
つーことは、既存のIDEになんかのプラグインでも入れればできるんでないの?
577デフォルトの名無しさん:2014/03/13(木) 12:46:32.09 ID:ZlFTo0ST
>>576
VSのUltimateとかではそう言うのやろうとしてるが。使い物にならないけど
578デフォルトの名無しさん:2014/03/13(木) 21:59:22.22 ID:9sS6Jz5v
>>577
それどの機能の話?
使いものにならないんじゃなくて
使ったことなくて知らないだけじゃ?
579デフォルトの名無しさん:2014/03/13(木) 22:25:08.17 ID:3qw6PUNb
ID出るようになったんだな。
つか、俺のいったのは表示に関してで、編集とはちょっと違うよな。
例えばコールグラフをGUIで編集できるようにするとしたら、
各メソッドの引数、戻り値が統一されてなきゃなんなくね?
それもできなくはないけど...
580デフォルトの名無しさん:2014/03/13(木) 22:45:26.97 ID:9sS6Jz5v
GUIで編集する理由なんてあんの?
581デフォルトの名無しさん:2014/03/13(木) 22:52:54.63 ID:3qw6PUNb
いや、それはこのスレの主旨的な話さ。
だが、電子ブロックみたいな子供向けのプログラミング環境としてはありかもな。
582デフォルトの名無しさん:2014/03/14(金) 00:47:27.83 ID:bbGk2WDX
>>578
CodeMapがその方向に向いてる機能じゃねーの。
上手く使うと使えるのかもしれんけど試した限りではこれじゃない感。
使える使い方あるなら教えて欲しい
583デフォルトの名無しさん:2014/03/14(金) 07:49:27.23 ID:LN3gZcvy
電子回路図とかは GUI でやってたし、意味はあると思う。
ただ数十〜数千程度の素子並べる時代ならなんとかなってたけど数万から下手すると億に到達するような時代だとやってられない。
ソフトでも UML とかのグラフィカルなアプローチやってるが、現場ではほぼ使い物にならないと言うのが現実。
584デフォルトの名無しさん:2014/03/14(金) 07:58:47.08 ID:79aEBtIl
アナライズとしては意味アルよ、特にコードグラフは。
585デフォルトの名無しさん:2014/03/14(金) 08:50:03.98 ID:bbGk2WDX
なんかアナルライフに空目した(´・_・`)
586デフォルトの名無しさん:2014/03/14(金) 09:05:53.00 ID:jnh1VUPi
>>583
プログラムもフローチャート図とかGUIでやってたよ。
同じく数(行数)が大きくなると成り立たないけど。

やれないことはないが、無駄な時間がかかり過ぎなんだよ。
それを省くと、絵ではなくて文字で書きましょうか?ってなる。
587デフォルトの名無しさん:2014/03/14(金) 10:06:37.73 ID:Wr96zkuI
"フローチャートは現場では使い物にならない"
合ってはいるが、それはチマチマフローチャートなんて
(プログラム本体と別に)書いてるヒマねーよ!じゃね?とは思う。
588デフォルトの名無しさん:2014/03/14(金) 10:17:24.45 ID:VGn/2oRe
フローチャートじゃ表現力がなさすぎるんだよな。
コードで書けることしか描けねえなんて無意味。
589デフォルトの名無しさん:2014/03/14(金) 22:57:30.96 ID:LfDYXH1p
>>586
> プログラムもフローチャート図とかGUIでやってたよ。

ほんとにやってたか?
うちの会社その手のツール作ってたけど、作ってるやつらですらまともに使ってなかった、て言うか使い物にならなかったぞ。
普通にコーディングしたソースをフローチャートとかに変換してレビューに使うとか、クロスリファレンス出力させるとかぐらいしか使いでがなかった。
590デフォルトの名無しさん:2014/03/14(金) 23:33:45.53 ID:bbGk2WDX
フローチャートは書かないけどクラス図とインタラクション図足して2で割ったような図は自分用によく書く。

そう言うのとエディタがシームレスに連携してくれると一番いいんだけどな
591デフォルトの名無しさん:2014/03/15(土) 01:03:26.72 ID:cc30DVAn
UML1.0っぽい図は便利なんでホワイトボードに描きながらクラス考えるなぁ
592デフォルトの名無しさん:2014/03/15(土) 03:04:10.48 ID:sV7UcUOI
線がグチャグチャになったとき、巡回セールス問題を遺伝的アルゴリズムで解いて
できるだけ短くなるプログラムを作るんだ。
次に線がクロスするときはできるだけ直角に交わるように回り道するアルゴリズムを考えるんだ。
593デフォルトの名無しさん:2014/03/20(木) 23:20:06.75 ID:RB+s/yVP
ある一定分野なら非常に有効なんじゃないかな
ネットワークのプロトコル記述とか、独立したシステムが協調動作するアクター指向のシステムとか。
594デフォルトの名無しさん:2014/03/24(月) 07:59:53.69 ID:uGyWjji3
VSとか部品でUI組み立てる部分をコードでも出来ればいいんだよな
教育用とかライトなのが一番思いつく用途だけど
595デフォルトの名無しさん:2014/03/24(月) 08:47:01.17 ID:4ETr6ohB
MindStorms...
596デフォルトの名無しさん:2014/03/24(月) 11:05:15.53 ID:uGyWjji3
まあカルネジーハート・・
597デフォルトの名無しさん:2014/03/27(木) 12:15:20.38 ID:8kVj/dkv
>>590
クラス図書くとコード生成してくれるってのはあるけど
それを動的にするってこと?
598デフォルトの名無しさん:2014/03/27(木) 12:43:03.18 ID:LV/+/NZy
んー、今のファイル内で縦に固定化されてるクラスとか関数が自由にダイアグラム上に配置出来て、呼び出しなど関係あるものは近くに配置出来るとかかなー コードとして開いてるのを閉じてクラスの矩形にするとかでコード間の関係をうまいこと視覚化出来るといいんだが。
上手くやらんと使えるものにはならないのは認識してる。
599デフォルトの名無しさん:2014/03/27(木) 12:44:17.17 ID:LV/+/NZy
>>597
コード生成のためというより今のテキストで書かれてるコード間の関係をコードエディタとシームレスに見れるといいなという
600デフォルトの名無しさん:2014/03/27(木) 13:38:39.35 ID:a2ZUG3kN
グラフィカルに確認できるほうが需要あったりして
601デフォルトの名無しさん:2014/03/27(木) 18:23:07.99 ID:Ba/mki9X
昔のMacで作業ごとにデスクトップのこの辺があれ、この辺はこれみたいに
作業フォルダ分けてたみたいにクラスはもうGUIで
クラスのアイコンとインターフェイスだけすぐ観れる状態で
ばらばらと空間に置いてあって、ダブルクリックで開くと
中身参照できてそれをコードエディタで弄る。みたいにして欲しいわ。
602デフォルトの名無しさん:2014/03/27(木) 18:28:07.95 ID:oO3pwu0F
Smalltalkが一番そういう環境に近いのかもね
603デフォルトの名無しさん:2014/03/27(木) 21:14:49.17 ID:gcsG9K2Q
コードを読めない人・・・グラフィカルがいいと思っている
コードを読める人・・・テキストがいいことをわかっている。

コードを読めない人が成長すると、
コードを読める人になる。

ようするにグラフィカルがいいと思ってるのは
たんにコードが読めないから。

読めないからグラフィカルになれば俺にもわかるはずと
夢を抱いているが、それはありえないので。
604デフォルトの名無しさん:2014/03/27(木) 21:16:54.27 ID:5ta8LPYN
Visual ASMがあれば欲しいぞ
アセンブラのビジュアル化ってLEDやスイッチなどのハード化が主だな
printfデバッグならぬLEDデバッグ
605デフォルトの名無しさん:2014/03/27(木) 21:19:22.06 ID:gcsG9K2Q
ハードウェアエミュレータの話でもしているの?
ハードウェアをどうにかするって話で
言語じゃないじゃんw
606デフォルトの名無しさん:2014/03/27(木) 21:25:39.53 ID:a2ZUG3kN
図示できるとこに着目したいけどGUIとコマンドプロンプトのようにはいかないだろうか

例えば【IF】部品を引っ張ってきて
【IF(){}】のカッコ内のパラメーターを入力する
そうすると部品単位の扱いになって入力ミス等が減ると思うから
やっぱ始めに初心者向けが想定されるんじゃないだろうか
関数なら=【HOGE】ーみたいに入力とリターンがあるとかなのかな?
607デフォルトの名無しさん:2014/03/27(木) 21:29:03.37 ID:gcsG9K2Q
>>606
そうやって長々と説明しているけど、
文字で書けば一行だからねw

そう、効率の問題。
608デフォルトの名無しさん:2014/03/27(木) 22:35:43.10 ID:5x1Sftni
むしろ、効率の問題的にわざわざコードでタイプしないでも
オブジェクト指向なんだから基底クラスの"フォルダ"に
使うクラスをポイポイぶち込んで、プルダウンで
その新クラスが使えるメソッド選んでオーバーライドコードを
チョロっと打てば、はい新しいクラス完成でいいじゃん。って思ってるだけだけどね。
609デフォルトの名無しさん:2014/03/27(木) 22:41:10.78 ID:a2ZUG3kN
>>607
ストレスの問題も
610デフォルトの名無しさん:2014/03/27(木) 23:50:42.62 ID:gcsG9K2Q
>>608
それ、クラスのインターフェースしか
作れて無いぞw

そんなインターフェース定義よりも、
量が多いのは、インターフェースの中身だろう?
611デフォルトの名無しさん:2014/03/28(金) 01:08:01.74 ID:gsNmkNiG
>>610
>オーバーライドコードをチョロっと打てば
612デフォルトの名無しさん:2014/03/28(金) 07:30:10.24 ID:6qvQp8ZA
学習、実用、文章派
向いてる方がそれぞれ違うな
613514:2014/03/28(金) 14:27:22.81 ID:TjE6hC/t
下手に知識を持った低能はマイナスに作用するな
無知でも地頭が良いやつの発想こそ縛られて無くて良い
614デフォルトの名無しさん:2014/03/28(金) 18:38:02.70 ID:Ek64RinZ
地頭がいいやつって評価されるけどさ、
地頭がいいだけじゃだめだろ。
615デフォルトの名無しさん:2014/03/28(金) 20:24:24.68 ID:6qvQp8ZA
学歴の話か
616デフォルトの名無しさん:2014/03/29(土) 12:38:20.30 ID:XkBeFzjm
地頭いいやつって、無理に知ったかする必要ないから
617デフォルトの名無しさん:2014/04/04(金) 11:01:09.73 ID:YtPgho8U
中卒高卒の発想は爆笑もので下手な芸人より面白い。
618デフォルトの名無しさん:2014/04/04(金) 23:49:54.04 ID:JslAeCyW
お前はその芸人よりつまらんけどな
619デフォルトの名無しさん:2014/04/05(土) 00:16:27.28 ID:LgbTmWdZ
大人になっても低い『自己肯定感』を飛躍的に高める5つの習慣

1.ほめられたら「ありがとう」といってみよう

2.台所をきれいにして、お料理をしてみよう

3.失敗したら「今回は失敗した」と考えるくせをつけよう

4.「D言語」を禁止する

5.自己肯定感は高けりゃいいもんじゃない!

ttp://goodluckjapan.com/jikokoute2/
620514:2014/04/05(土) 00:40:28.92 ID:m2nwt+w+
「青は藍より出でて藍より青し」
621デフォルトの名無しさん
なんでや、D関係ないやろ