2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

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

1 :デフォルトの名無しさん:2014/01/26(日) 02:49:36.10
もうコーディングは嫌だ
もっと新しいグラフィカル志向なプログラミング言語が欲しい

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
うーん
http://arashi50.cocolog-nifty.com/photos/uncategorized/2010/05/22/100522scratch_spiral.gif

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
どうぞどうぞ!

517 :514: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
いままでの流れをドラえもんでたとえると。
「ドラえも〜んしずかちゃんとやりたいよう〜」
「とりあえず告白すれば?」
「やだよ」

533 :514:2014/02/17(月) 06:43:51.98
>>532
どっか消えてくれ

534 :デフォルトの名無しさん:2014/02/18(火) 00:21:01.19
>>532
やりたいと付き合いたいは根本的に違う

535 :514: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
何をするにも金が要る
そのくらい子供でも分かる

546 :514: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
絵空事いうプログラマ

551 :514:2014/02/20(木) 00:28:00.56
質問厨って煩わしいな
自分で考えろって話

552 :デフォルトの名無しさん:2014/02/20(木) 01:14:31.30
答えられないから逃げちゃった

553 :デフォルトの名無しさん:2014/02/20(木) 01:38:50.67
見積りも出来ない

554 :514: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
と、絶対王政時代で頭の進化が止まってるエセ左翼は、今日も喚くのだあった。

558 :514:2014/02/22(土) 00:33:04.70
>>555みたいな奴って大概もらう権利だけ主張して
自分は何もしないという まさに圧倒的クズタイプが多いよな
まあそういう人間でいたいならそうしたらいいんじゃない

559 :514:2014/02/28(金) 18:30:36.23
もうちょっとスレ伸ばし頑張れよ
残ってるプロジェクトが全部終わって万が一時間余れば作ってやるからよ

560 :デフォルトの名無しさん:2014/03/02(日) 09:46:52.38
http://fr.audiofanzine.com/tests_v3/native_instruments/reaktor5/spacedronestructure.jpg

561 :デフォルトの名無しさん:2014/03/02(日) 10:21:40.13
>>560
フリーフォーマットだとこういう風にごちゃごちゃするから
やっぱ碁盤上にしたほうがいいと思うんだよ

562 :デフォルトの名無しさん:2014/03/02(日) 17:27:43.06
>>561
つ Excel

563 :514: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
グラフィカルなエディタない?

572 :514:2014/03/05(水) 10:05:18.01
俺の発想もそれだが
見つからないならお前が作れよ

573 :デフォルトの名無しさん:2014/03/05(水) 14:50:02.37
http://cs.brown.edu/~spr/codebubbles/

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
学習、実用、文章派
向いてる方がそれぞれ違うな

613 :514: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/

620 :514:2014/04/05(土) 00:40:28.92 ID:m2nwt+w+
「青は藍より出でて藍より青し」


621 :デフォルトの名無しさん:2014/04/05(土) 22:05:47.34 ID:b1rT6Y5k
なんでや、D関係ないやろ

622 :デフォルトの名無しさん:2014/04/12(土) 21:19:25.80 ID:yu+dq9iZ
UE4のBluePrint見た感じだいぶイメージに近そうだったんだが(´・_・`)

623 :デフォルトの名無しさん:2014/04/13(日) 04:13:02.39 ID:k0ITP6j1
こんなん?
http://www.forest.impress.co.jp/docs/news/20140410_643817.html

624 :デフォルトの名無しさん:2014/04/13(日) 06:15:49.38 ID:qYmwgSBw
「Squeak(スクイーク)はSmalltalk環境のひとつ(中略)
キーボードの扱いに馴れていない低年齢層ユーザーにも容易に扱うことができる」

- Wikipedia

625 :514:2014/04/13(日) 08:13:58.14 ID:ZdrtJqAv
そんなん見ててもパッとせんな

626 : 忍法帖【Lv=3,xxxP】(2+0:5) :2014/04/14(月) 04:38:30.87 ID:P7KpY7jf
>>1
データの流れが見える新プログラミング言語
>「Flower」はデータの流れを見ながら、簡単なマウスや画面タッチ操作でプログラミングができる、新世代のビジュアルプログラミング言語。
>業務フローの可視化、スケジューリングの構築などさまざまな場面に応用でき、
>すでにARMプロセッサを搭載したシングルボードコンピュータ「RaspberryPi」を利用したセンサーネットワーク構築の事例も出ているという。
https://codeiq.jp/magazine/2014/03/7352/

Flowerはどないや?

627 :デフォルトの名無しさん:2014/04/14(月) 10:11:10.80 ID:/RTDqAVd
電気回路の回路図などは昔からグラフィカルだが意味のある動作をする
電気回路が誰にでも簡単に設計できる訳では無い。
これらを設計するには理論や原理等を理解しているしている必要がある。
プログラミングも同じ。グラフィカルだと取っつきやすいような気がするが
プログラミングその物の難易度は下がらない。

628 :デフォルトの名無しさん:2014/04/14(月) 10:22:54.89 ID:mUlG9Vof
>>626
まともにリンクも貼れんのか(´Д` )

629 :デフォルトの名無しさん:2014/04/14(月) 10:25:17.27 ID:QEqaYkvm
中のロジック動作はともかくオブジェクト指向なんかで
クラスとかのやりとりなんてインターフェイスとメソッドを
プルダウンで選択するようにすりゃいいじゃんとは思う。
なんで独立したユニット同士の定型文まで21世紀にもなって
バッチスクリプトみたいにいちいち手で書いてるのか意味わからん。

630 :デフォルトの名無しさん:2014/04/14(月) 10:40:47.81 ID:/RTDqAVd
>>629
何らかのIDE使えば普通に出来るけど。。。。
20世紀から有るよ。

631 : 忍法帖【Lv=3,xxxP】(1+0:5) :2014/04/14(月) 21:57:21.95 ID:P7KpY7jf
>>628
ワザワザ一部だけ全角にしてるのはリンク貼れないかったからだ

分かるだろ普通

632 :デフォルトの名無しさん:2014/04/14(月) 22:04:16.20 ID:40FGP0zN
プログラマの自分がいうのもアレだが、コーディングってほんとくだらない作業だと思う。
やりたい事は同じなのに、成果物は千差万別。
ある程度技量のあるプログラマのコードを見比べたら、その優劣を誰もつけられない。そして、そういうのは大抵どうでもいい部分。

プログラムをグラフィカルに組むってことは、個人差が出るようなどうでもいい部分を削ぎ落として、
設計の実現に注力することになるだろうから、
そうなったらいいなーとは思うわ。

633 :デフォルトの名無しさん:2014/04/14(月) 22:22:58.81 ID:IFskYdvB
>>632
多分お前が夢見てるようなことは起こらんぞw

634 :デフォルトの名無しさん:2014/04/14(月) 22:29:59.91 ID:1BzKypQe
>>632
なんかいろいろ勘違いしてるね。

コーディングというのは言葉だよ。
ロボットを動かす時に長々と説明するか短い説明をするか。

右へ5、下へ5に動かす時に、
右に1、下に2、右に2、下に4、右に1、上に1 と書いていて、
これが正しいかどうかすぐに分かる?

動けばなんだっていいというやつはいるが、じゃあ時間かかってもいいのか?
開発時間と実行時間、バグが起きた時の対応時間、動けば時間かかってもいいのか?

よく、コーディングと設計を比べて設計のほうが重要だからコーディングはどうでもいいという
間違ったことを言う奴がいる。正解は、コーディングも設計もどちらも大事。
設計のほうが大事という意見が正しかったとしても、コーディングも大事なんだよ。
両方なければシステムは作れないので、両方大事なのは当たり前。

さて、君がいいたいのは、設計があればコーディングはどうでもいい。なのかな?
その答えはどちらも必要だよ。設計とコーディングは別々のものであり、設計からコーディングは生成できない。
だから「グラフィカルにコーディング」できないかぎり、コーディングはなくせない。
グラフィカルなコーディングは、テキストによるコーディングよりも時間がかかる。

635 :デフォルトの名無しさん:2014/04/14(月) 23:47:48.86 ID:mUlG9Vof
>>634
BluePrint見てる限りテキストよりも時間かかるとは言えん。
少なくとも可読性ははるかに上と予想。

636 :デフォルトの名無しさん:2014/04/15(火) 00:55:32.03 ID:/D3JYxjA
設計とコーディング、間違えた時に後から修正にかかる時間が大きいのは設計
だから設計のほうが大事

637 :デフォルトの名無しさん:2014/04/15(火) 00:59:56.50 ID:eckJgNjF
>>634
> なんかいろいろ勘違いしてるね。

またでかいブーメラン持ってきたなぁ (w

638 :デフォルトの名無しさん:2014/04/15(火) 07:21:37.65 ID:irAkhtzu
オバQは「ブラーメン」と言ってたな。

639 :デフォルトの名無しさん:2014/04/15(火) 08:11:31.92 ID:KwDwkm6v
>>637
うん、それでまた言い返せなかったの?

あ、いらないよ。俺へのヘスはw

640 :デフォルトの名無しさん:2014/04/15(火) 08:12:16.74 ID:KwDwkm6v
>>635
BluePrintだけじゃ、アプリは動かない。

641 :デフォルトの名無しさん:2014/04/15(火) 08:12:55.26 ID:KwDwkm6v
>>635
だから、どっちも大事でしょw

設計が正しくても、コードが読みにくいってことはあるんだから。

642 :デフォルトの名無しさん:2014/04/15(火) 08:22:12.84 ID:D5PUC5mL
言い返す内容だと思ってるんだ (w

643 :デフォルトの名無しさん:2014/04/15(火) 08:44:59.34 ID:KwDwkm6v
レスしたってことは言い返したいんじゃないの?w
だまってれば、俺もレスしないよ?

まあこういうくだらない煽りを始めた時点で
あぁ、この程度の人間かって思っただけだけどね。

はいどうぞ。一人で空回りしててください。

644 :デフォルトの名無しさん:2014/04/15(火) 09:32:46.44 ID:z2jBvvBj
>>633
俺もそう思う。まぁ仰る通りの夢ですわw

>>634
どちらも必要なのは誰でもわかる。
どちらが欠けても動かないからどちらも大事だなんていうのは思考停止に近い。

俺が言いたいのは、コーディングにはどうでもいい部分が多いから、そういうことを意識せずに物が作れたらその方が良いじゃんってこと。

右へ5、下へ5とかの例だって、そもそも人がコードを書いてる現実があるから、そんな話題になるわけで、
例えば、実行効率だけを重視したなら最適化は出来る。
でも人が読むことを前提としてるから、可読性やら保守性やらを考慮しないといけなくて、結局最適解が得られない。
そういうのが実にくだらない事だと思ってるんだ。

簡単にいえば、人が関わる部分を減らしたい。
グラフィカルに作ることは、それに向かうための一歩かもしれぬと思うわけ。

645 :デフォルトの名無しさん:2014/04/15(火) 09:47:18.34 ID:7sxQZ0IC
>>644
それはいわゆる宣言的って奴やね

646 :デフォルトの名無しさん:2014/04/15(火) 13:13:23.17 ID:xRAyq3Ng
なんかかわいそうな人がいるな (w

647 :デフォルトの名無しさん:2014/04/15(火) 16:30:10.72 ID:aVa6WvNE
hspに線で結ぶやつなかったっけ

648 :デフォルトの名無しさん:2014/04/16(水) 00:21:54.59 ID:FwnwH35E
>>644
> どちらが欠けても動かないからどちらも大事だなんていうのは思考停止に近い。

思考停止は、コーディングはどうでもいいと決め付けることだよ。

当たり前の話だけど、人間は曖昧に言ってそれなりに正しければOKだけど、
コンピュータには正しく動くことを期待している。
それが人間への命令とコンピュータへの命令の大きな違い。

コンピュータを正しく動かすには完璧な命令を書かなければ動かない。
それがコーディングによって書かれた命令。
コンピュータを正しく動かす以上これを省くとこは出来ない。

君が言ってるのは、永久機関はできないと証明されているのに、
永久機関を作るにはどうすればって言っているようなものだよ。

相手はコンピュータなので、人間ならわかるレベルの簡易な説明じゃダメ。
コンピュータ用に抜けのない完璧な命令を書きつつ、可読性や保守性を保つ必要がある。

もしくは、AI作るかだよ。曖昧な命令、複数の意味に取れる命令でありながら
人間が思ったことを読み取るエスパーみたいなAI。
このはしをわたれと言って俺が意図したとおりに動くそんなAI。

649 :デフォルトの名無しさん:2014/04/16(水) 04:07:28.85 ID:n1CQwedO
>>648
>>644のいってることは高級言語がアセンブラを抽象化してる延長のことを言ってるだけだぞ

650 :デフォルトの名無しさん:2014/04/16(水) 07:22:34.73 ID:sTkDhmLM
まあ建築とかでも設計と土方(大工とか)両方居ないと良い家は作れないかもだけど、土方は幾らでも代わり効くし馬鹿でも出来る
そして素晴らしい建築物は設計が命
ソフトウェアでもそれは一緒だと思うんよ、だからコーディングしか能がないコーダーはIT土方と揶揄される

651 :デフォルトの名無しさん:2014/04/16(水) 07:25:06.44 ID:sTkDhmLM
つまり低脳でも出来る土方が設計より評価されることは永遠にないってことさね(´・ω・`)

652 :デフォルトの名無しさん:2014/04/16(水) 07:42:52.76 ID:sTkDhmLM
シリコンヴァレー各社が選ぶ「NBBJ」のオフィス設計
http://wired.jp/2014/03/25/google-amazon-samsung-tap-architects-design-offices-future/

これだと例として分かりやすいかな?
有名企業の先進的でお洒落で快適なオフィス建築も評価されるのは設計側なんだよね
一々そこに現場で汗かきながらやってる大工土方工事する人達を表立って世間は評価したりはしない
彼等は基本的に設計通りに手を動かしてるだけで、いや勿論彼等が汗かいて土方してくれるから建築物は完成するんだけど、
そこにクリエイティブに頭を働かせて先進的でお洒落で快適な建築物をゼロから生み出してるわけではないんよな

653 :デフォルトの名無しさん:2014/04/16(水) 12:19:48.92 ID:n1CQwedO
それでいくと実際の建築コストや技術を省みない新国立競技場の設計案とか出て来て設計士バカかよと言われる流れですかね。

654 :デフォルトの名無しさん:2014/04/16(水) 12:21:57.60 ID:1bKB36mk
すべての部品がオーダーメイドで補修費用がバカ高くなるような感じ?

655 :デフォルトの名無しさん:2014/04/16(水) 16:17:33.09 ID:Wy9kGQMK
設計よりデザインセンスじゃね?

656 :デフォルトの名無しさん:2014/04/16(水) 23:49:37.13 ID:J3In2oUI
違います。

657 :デフォルトの名無しさん:2014/04/17(木) 00:49:03.28 ID:qRf+hhIu
低能よばわりされたので永遠に教えてやらない。そしておまえらの未来は永遠に閉ざされている。

658 :デフォルトの名無しさん:2014/04/17(木) 01:43:56.44 ID:QuWSFXEi
>>652
「設計者がゼロから作り出してる」という思い込みを早く止めた方が良いぞ。

659 :デフォルトの名無しさん:2014/04/17(木) 03:26:41.45 ID:KNGPRiph
>>652
うん。ソフトウェアの話はわからないからやめたのかな?

660 :デフォルトの名無しさん:2014/04/17(木) 03:27:12.89 ID:KNGPRiph
ソフトウェアに置いてはソースコード=設計書なんだよね。

661 :デフォルトの名無しさん:2014/04/17(木) 05:06:36.26 ID:Ps18C1l0
プログラム作成の工程を良く建築に例えられるけど。
ソースコード=設計図、プログラマ=設計士なのに
日本では何故かプログラマ自身が現場の土方とか言うんだよなw
一応、言っておくとコンパイラ=大工だよ。

いくら此処で言う日本語で書かれた立派な設計書(もどき)が有っても
何の役にも立たない。例)TRON

662 :デフォルトの名無しさん:2014/04/17(木) 05:40:41.35 ID:inN/bsNV
肉体労働だからドカタ。

663 :デフォルトの名無しさん:2014/04/17(木) 06:26:59.39 ID:LTgKQb5W
>>661
ソースコードを建築の設計図に類推するのはおかしい。
ソースコードを書く前にプログラム全体の構造を記した図が必ずあるので、それが建築の設計図に該当する。

ソースコードとは評価可能な性能を持った構造であり部材であるので、
それは建築でいうと鉄骨の梁やコンクリートの外壁にあたる。

664 :デフォルトの名無しさん:2014/04/17(木) 07:14:20.08 ID:Ps18C1l0
>>663
>ソースコードを書く前にプログラム全体の構造を記した図が必ずあるので、それが建築の設計図に該当する。
へー、その図をコンパイルして実行できるの?
それって建築で言うところの見取図やスケッチじゃないの?

>ソースコードとは評価可能な性能を持った構造であり部材であるので、
>それは建築でいうと鉄骨の梁やコンクリートの外壁にあたる。
建築の設計図だって評価可能でしょ?
評価不能なら設計コンペとか意味ないじゃん。
それからプログラムの部材はデータとアルゴリズムだろ。

665 :デフォルトの名無しさん:2014/04/17(木) 07:24:28.31 ID:LTgKQb5W
>>664
見取り図やスケッチがスタートラインの設計図だよ。
それ無しにいきなり基本設計図を書くわけではない。
ましてや詳細図や施工図である必要はない。

666 :デフォルトの名無しさん:2014/04/17(木) 07:28:09.19 ID:LTgKQb5W
分野が違うので完全に対応させるのは難しいだろうし、どれだけ意味があるかはわからんが、
まず言えるのは「ソースコードを建築の設計図に類推するのはおかしい。」
ソースコードを「詳細図や施工図」に対応させるのなら、まだわからなくもない。

667 :デフォルトの名無しさん:2014/04/17(木) 07:29:48.58 ID:pGxOYlwd
たとえ話が妥当かどうかに話が切り替わってるぞー

668 :デフォルトの名無しさん:2014/04/17(木) 07:32:56.83 ID:PNN74mcF
デジドカ = コーダー = 図面の清書屋

669 :デフォルトの名無しさん:2014/04/17(木) 07:37:00.39 ID:LTgKQb5W
もとは、ソースコードと設計、どっちが大事かという話だったか。
これをしつこく建築に類推すると、同じプランを鉄骨でやるかRCでやるかみたいな話だろう。
プログラミングで言うと、同じ設計をJAVAで書くかObjective-Cで書くかみたいな事だろうか。

670 :デフォルトの名無しさん:2014/04/17(木) 07:41:10.95 ID:UhlhPJVz
ノイマン型に縛られるかどうかじゃなくてグラフィカルかどうかってww(大笑

671 :デフォルトの名無しさん:2014/04/17(木) 09:05:28.65 ID:KNGPRiph
>>663
> ソースコードを書く前にプログラム全体の構造を記した図が必ずあるので、それが建築の設計図に該当する。

それは概要。

建設の設計図でも概要はあるが、
詳細なものも設計。

672 :デフォルトの名無しさん:2014/04/17(木) 09:30:57.32 ID:LTgKQb5W
>>671
じゃあ、根本的に重要なのは概要という事になる。
設計は他の言語で置き換えが効くが、概要が駄目ならそのプログラムには利用価値が無い。
ソースコードを設計に含めるのならね。

673 :デフォルトの名無しさん:2014/04/17(木) 09:52:34.18 ID:WDbWaLnY
概要だけ書いて後はゴーストライターに書かせても
自分の物って主張していいのね。

674 :デフォルトの名無しさん:2014/04/17(木) 11:00:28.39 ID:1P5IhohW
客のものやで

675 :デフォルトの名無しさん:2014/04/17(木) 21:26:14.72 ID:KNGPRiph
>>672
えとさ、誰に対して重要なのかの考慮が
完全に抜け落ちてるよ?

素晴らしい概要も、作れなきゃ絵に書いた餅なんだよ。

概要に含まれる情報っていうのは、
作るのに必要な情報の、ほんの僅かしか含まれていない。

グラフィカルに表現できるものっていうのは、
概要でしかない。作るための情報の大部分が抜け落ちている。
だからグラフィカルじゃ作れないって言ってんの。

676 :デフォルトの名無しさん:2014/04/17(木) 23:05:44.36 ID:OhLybx2x
Java Studioが出てないな

677 :デフォルトの名無しさん:2014/04/18(金) 00:33:57.32 ID:Db0qmgf/
>>675
別にグラフィカルだから概要しか表せないんじゃなくて、概要を表す物が多いだけだ。

678 :デフォルトの名無しさん:2014/04/18(金) 00:35:45.22 ID:DmASV5Ul
多くても概要は概要。
それだけでは役に立たない。

679 :デフォルトの名無しさん:2014/04/18(金) 00:42:39.14 ID:8Q5cnPxF
>>675
グラフィカルどうこうよりも、設計orソースの二元論でソースも設計だという主張だろ?
ソースも大事なのはそりゃそうだが、ソースまで設計に含めたら全部一緒くただろうw

680 :デフォルトの名無しさん:2014/04/18(金) 00:43:49.38 ID:DmASV5Ul
全部一緒くたで何が悪い?
そもそも分けるなって言ってるんだよ。

681 :デフォルトの名無しさん:2014/04/18(金) 00:57:53.33 ID:8Q5cnPxF
それは、設計がはっきりしないままコード書き始めて、何度も書き直した末、
出来上がったものには利用価値が無いという可能性があるな。
そのよくわからないものに人的リソースを投入する判断ができるのか?

682 :デフォルトの名無しさん:2014/04/18(金) 01:09:58.11 ID:Db0qmgf/
>>678
お前は読解力無いの?グラフィカルという性質上概要を表す物が多いから、お前みたいにグラフィカルなものは概要しか表せないと勘違いする奴がいるって意味だけど。

683 :デフォルトの名無しさん:2014/04/18(金) 01:16:55.87 ID:DmASV5Ul
>>681
> それは、設計がはっきりしないままコード書き始めて、何度も書き直した末、

どうせさ、お前が言ってる設計って
エクセルかテキストファイルに書くんだろう?

どちらでもいいが、お前一発で
そのテキストを書けるのか?

なんども書き直すだろ。その設計を。
それと何が違うのさ?

684 :デフォルトの名無しさん:2014/04/18(金) 01:19:38.01 ID:DmASV5Ul
>>682
グラフィカルで詳細なものを書くことは可能だが、
時間がかかりすぎる。

たとえば i++ というのを
グラフィカルに書いてみろよ。

たったこれだけのことでも
文字で書くのとグラフィカルに書くのに大幅に差が出るだろ?

それともやっぱり、グラフィカルに書くときは
必要なことを端折ってかくのかい?
それが概要ってこと。

685 :デフォルトの名無しさん:2014/04/18(金) 01:20:33.96 ID:8Q5cnPxF
>>683
>それと何が違うのさ?
残念でした。全然違うよw
俺は何から何まで一人でやる個人開発者だが、全然違うよ。

686 :デフォルトの名無しさん:2014/04/18(金) 01:22:42.33 ID:DmASV5Ul
説明できないんだけど
ぜんぜん違うんだよ!

ちゃんとここまで書いてくれないと
面白く無いぞw

687 :デフォルトの名無しさん:2014/04/18(金) 01:41:14.30 ID:rhB3kkKM
>>684

i++は簡単に表現できる。

面倒なのは再帰呼び出しとか、スタックを使うようなものだと思う。
あと、数式の可読性が落ちる場合があるね。

Labviewを使ったことあるけど、データの処理部分は文字で書いた方が楽だった。

FPGAの開発環境にもグラフィックと文字による記述を混在させる機能があるけど、
トップ(主要モジュール)だけグラフィックにして、詳細はVHDLで書いた方が楽だね。

688 :デフォルトの名無しさん:2014/04/18(金) 01:42:28.07 ID:DmASV5Ul
> i++は簡単に表現できる。

じゃあ書いてくれよ。

i++ キータイプ3文字。

はい、君は、マウスで
何秒かかって書くんだい?w

689 :デフォルトの名無しさん:2014/04/18(金) 03:25:59.61 ID:48w9VKgS
なんかどーでもいい話してるなーとは思ってたけど
はい、Prograph

http://www.geocities.co.jp/SiliconValley-PaloAlto/4654/sikai/doc1-1/cpx_sikai1-1.html

-1って入ったオペレーションボックスがi--

さすがに議論してる対象をどれ一つ知らないでとか勘弁。

690 :デフォルトの名無しさん:2014/04/18(金) 04:54:21.11 ID:OAxsyaFj
何かイミフなレスが多いと思ったら、"グラフ"を絵とか、図の事だと勘違いしてるのか。

691 :デフォルトの名無しさん:2014/04/18(金) 05:47:17.17 ID:QhGo445E
>>661
日本のIT土方は設計出来ないだろw
だから土方と揶揄されるwただのコーダーだ

692 :デフォルトの名無しさん:2014/04/18(金) 05:49:41.77 ID:QhGo445E
>>663>>668
正解

693 :デフォルトの名無しさん:2014/04/18(金) 06:04:39.32 ID:48w9VKgS
俺がこんなところで燻ってるのは
オバマが俺の邪魔をしてるせいだ!とか
ネットで書き込んでそうだなこの人。

694 :デフォルトの名無しさん:2014/04/18(金) 09:08:47.04 ID:Db0qmgf/
>>687
言語も一つの記号であってグラフィカルでも必要ならばその記号が定義されていてそれが簡単に選択出来ればいいだけ。プリミティブが揃ってたら後は自分でルーチンなり拡張してくってのも同じ話だ。
再帰は結果を元のところに流し込むだけだから特に難しくもなくない?
まぁそのグラフィカルがデータフロー的な物としてだけど。

>>688
専用の記号が用意されててその使って早いとホルホルしてるとかバカ?そんなのグラフィカルでも同じだよインターフェイス次第でクリックで選択で終了だわ。
それよりも100行以上に相当する関数なりメソッドの依存関係を表現してみろよ。あ、IDEの呼び出し関係の表示とかなしでな。
長い関数は分割するならって言うならその分割した物同士の依存関係含めて出せよ。

695 :デフォルトの名無しさん:2014/04/18(金) 20:50:58.31 ID:DmASV5Ul
> 言語も一つの記号であってグラフィカルでも必要ならばその記号が定義されていてそれが簡単に選択出来ればいいだけ。

つまりそれは、スクリーンキーボードってやつだよね?
マウスで記号を押せる。

これがキーをタイプするよりも早いって
ほんとうに思ってるの?

696 :デフォルトの名無しさん:2014/04/18(金) 20:54:21.07 ID:DmASV5Ul
> それよりも100行以上に相当する関数なりメソッドの依存関係を表現してみろよ。

えとさぁ、

「見る」のと「書く」のをごっちゃにしてるじゃん。

書く話をしていたよね? 言語なんだから。
表現するのは見ること。

「**文字** で書いたものを把握するためにグラフィカルに変換する」ことには
なんの異論もないんだよ。

依存関係の表現というのは、関数とメソッドに含まれる情報のうち
「依存関係」だけを取り出したもの。一部を取り出しただけ。

依存関係の情報だけじゃ、動きません。

697 :デフォルトの名無しさん:2014/04/18(金) 22:01:52.71 ID:8KmkbQh1
>>695
なんか、頭固くね?

698 :デフォルトの名無しさん:2014/04/18(金) 22:39:31.73 ID:Db0qmgf/
>>696
お前が文字で書くことでしかプログラム出来ないと思い込んでることは分かった。
文字を書くことでお前が何をしてるのか考えてみたら?

699 :デフォルトの名無しさん:2014/04/18(金) 23:51:44.86 ID:8Q5cnPxF
認識の次元が一個足りないんだろう。
二次元人に三次元の世界を説明するようなもん。

700 :デフォルトの名無しさん:2014/04/18(金) 23:58:03.99 ID:YRS/MpoC
なんか文句言いたいのはわかるけど、反論がなかった
やっぱりグラフィカルってのは効率悪いんだな。

まあ、そもそも人類の歴史で文字は後に発明された。
最初は壁画だった。文字の最初は象形文字だった。

今の文字は、書く効率をあげるために
長い歴史で進化してきたものなのだ。

701 :デフォルトの名無しさん:2014/04/19(土) 00:02:26.78 ID:EY4uPe0I
いや、ここで話してるのは効率の問題じゃなくて空間認識の問題だよ。
だから認識の次元が足りないって言ってるのw

702 :デフォルトの名無しさん:2014/04/19(土) 00:05:13.71 ID:QyTZzyQd
認識なら、プログラム言語で書いたコードの
ある側面、つまり一部を頭に変換してくれるツールが有るだろ。

それは決して、動くコードではないが
誰もそうやって変換した図を否定していない。

たとえばこれ。最初っからすでにわかってたこと。


21 名前:デフォルトの名無しさん[sage] 投稿日:2014/01/26(日) 12:54:34.34
視覚化するのであれば、ソースコードからUML図でもなんでも生成すればいい。

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

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

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

は生成可能だが、

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

ということ。

703 :デフォルトの名無しさん:2014/04/19(土) 00:07:26.26 ID:QyTZzyQd
グラフィカルなプログラム言語は、プログラムするための言語ではない。
コードを簡略化したグラフィカルな図であり、
プログラムするための言語には成り得ない。

704 :デフォルトの名無しさん:2014/04/19(土) 00:18:43.41 ID:MP1hLwSA
教育用プログラミングが限界だな

705 :デフォルトの名無しさん:2014/04/19(土) 00:19:34.95 ID:EY4uPe0I
>>702-703
そんな前提はここにいる全員がわかってて話をしてると思うが。

706 :デフォルトの名無しさん:2014/04/19(土) 00:24:46.60 ID:QyTZzyQd
>>705
ソースコードを図にすることは誰もヒチしていない。
図をかいてプログラムすることが効率が悪い。

だからグラフィカルなプログラム言語というものは
あっても使いものにならない。

グラフィックで把握したいなら、コードを変換すれば良い。
それは既にあるしみんな便利に使っている。

グラフィカルなプログラム言語というのが馬鹿な考え。

それがわかっているわけでしょ? それで何の話してるの?w

707 :デフォルトの名無しさん:2014/04/19(土) 00:27:15.86 ID:EY4uPe0I
>>706
だから頭が固いって言われるのさ、いろいろとw

708 :デフォルトの名無しさん:2014/04/19(土) 00:29:09.39 ID:QyTZzyQd
やれやれw 具体的なことは何も言わないで
言い返したつもりか。

なんか文句言いたいってことだけはわかったよw

709 :デフォルトの名無しさん:2014/04/19(土) 00:33:18.36 ID:BdrlSiRk
例えば、文字で記述されたLispの構文木はアイコンと←で簡単に
置き換えられると思う。

このアイコン(関数やListを表す)と←で表現されたプログラムは
グラフィカルなプログラム言語と呼んでいいの?

710 :デフォルトの名無しさん:2014/04/19(土) 00:37:30.73 ID:BdrlSiRk
>>706
紙の文章に印鑑を押していくワークフローにおいては、
中途半端な電子化はかえって非効率になることもある。

でも、電子化を前提に初めからワークフローを見直せば
紙ベースの時よりも効率化することが可能。

グラフィカルな言語も十分検討に値すると思うけど。

711 :デフォルトの名無しさん:2014/04/19(土) 00:37:48.42 ID:QyTZzyQd
>>709
それはグラフィカルなメリットがあるのか?w

コードの一部分だけを取り出して
図にしない限り、意味は無い。

一対一で置き換えても、何も意味は無いよ。

だから、グラフィカルな図は簡略化したもので
それは到底動くものではなく、プログラム言語とはよべないと
UML図は便利だが、プログラム言語ではないのと同じ。

712 :デフォルトの名無しさん:2014/04/19(土) 00:39:08.91 ID:QyTZzyQd
>>710
プログラム言語は、紙ベースではなく
最初からコンピュータに入力しますが?

713 :デフォルトの名無しさん:2014/04/19(土) 00:45:15.77 ID:3iojgwbR
>>704
わかりやすくてタイプミスや文法のミスをしづらいのが利点だと思うんだよ

714 :デフォルトの名無しさん:2014/04/19(土) 00:46:26.18 ID:QyTZzyQd
補助輪みたいなものか。

715 :デフォルトの名無しさん:2014/04/19(土) 00:49:32.14 ID:QyTZzyQd
自分で言っといてなんだが、補助輪ってのは言い得て妙だな。

グラフィカルをありがたがろうとしている奴の話を聞くと
まともに動くプログラムを書けないか、
自分でコードは書かずに(かけずに)、分かった気になりたいかの
どちらかが、書かずに見ることだけしか考えないで
言っているようにしか見えない。

補助輪使えば、初心者にとっては簡単かもしれないが、
プロにとっては開発スピードを妨げる足かせでしか無い。

716 :デフォルトの名無しさん:2014/04/19(土) 00:50:25.93 ID:BdrlSiRk
>>711
効率的かどうかは別に、グラフィカルにプログラミング可能
だということは合意できたのかな?

次に、Lispの構文木を文字で書く場合と、マウスで書く場合、
どちらが効率的か考えた場合、普遍的な答えがあるだろうか?

結局、条件次第でしょ?

>"コードの一部分だけを取り出して図にしない限り、意味は無い。 "

要約は文字で表現されたものの特権ではない。
たとえば、サムネイルとか、細部は省いて概略を見せたものでしょ。

717 :デフォルトの名無しさん:2014/04/19(土) 00:50:34.89 ID:QyTZzyQd
あ、もしかしてもっとひどくて
タイピングが出来ないのかもw

718 :711:2014/04/19(土) 00:55:22.37 ID:ZOoFAELE
>>716
誰も可能かどうかの話なんかしていない。
>>1ぐらい読み返してみたら?

>>3ですでに" 俺が" >>1に反論しているが
グラフィカルなプログラム言語の方が嫌になる。

なぜなら面倒くさい、効率が悪いからだ。

> 1 名前:デフォルトの名無しさん[] 投稿日:2014/01/26(日) 02:49:36.10
> もうコーディングは嫌だ
> もっと新しいグラフィカル志向なプログラミング言語が欲しい
>
>
> 3 名前:デフォルトの名無しさん[sage] 投稿日:2014/01/26(日) 02:52:32.34
> そうか?
>
> じゃあ、1+1をグラフィカルに表現してみてくれ。
>
> そっちのほうがもっと嫌になるぞ。

719 :デフォルトの名無しさん:2014/04/19(土) 01:00:19.93 ID:pzsg7m6u
いいからBluePrint見てこいよw
俺かっけーと思いながらバカを晒してるバカを見るのはつまらなくもないけど長いと飽きてくる(´・_・`)

720 :デフォルトの名無しさん:2014/04/19(土) 01:02:22.10 ID:rLS4KdYY
> BluePrint見てこいよ

"書いてこいよ” じゃない所が
全ての答えを示しているなw
まさに語るに落ちたってやつだ。

721 :デフォルトの名無しさん:2014/04/19(土) 01:02:54.05 ID:BdrlSiRk
>>718

>>702
>ある側面、つまり一部を頭に変換してくれるツールが有るだろ。
>
>それは決して、動くコードではないが
>(略

可能かどうかの話をしているように見えるけど。

で、効率的かどうかは結局のところあなたの主観以外に何か根拠が
あるの?

722 :デフォルトの名無しさん:2014/04/19(土) 01:04:50.15 ID:rLS4KdYY
> で、効率的かどうかは結局のところあなたの主観以外に何か根拠が
> あるの?

根拠は、人類の歴史。
記録の効率を上げるために、文字が生まれた。

どちらが新しい発明かと言われれば
絵ではなく文字なんだよ。

i++をグラフィカルにして、3文字タイプより
効率良く作れるという証拠は未だ出てない。

723 :デフォルトの名無しさん:2014/04/19(土) 01:11:08.15 ID:pzsg7m6u
>>720
こいつリアルでいたらモンペとかになってんだろwww
客商売大変そうだわー(´・_・`)

724 :デフォルトの名無しさん:2014/04/19(土) 01:20:28.39 ID:BdrlSiRk
>>722
だから、それがあなたの主観に基づく推測でしかないと言ってるわけだが・・・。

建物や機械や回路は図で表現するけど、あなたの理屈で説明がつくかな?

それと何を根拠にi++を効率性を決定する代表的な例に選んでいるの?

725 :デフォルトの名無しさん:2014/04/19(土) 10:12:47.17 ID:SVxJm38+
>>724
722は、シンタックスとセマンティックとの区別が付いて無いんだと思う。
今時のプログラミングツールは、見かけがCUIで有っても、大抵はセマンティックベース。

726 :デフォルトの名無しさん:2014/04/19(土) 10:55:43.42 ID:Fb4YL4It
低能:
知ったか勘違い野郎
教えてクレクレちゃん
一生懸命叩きたがるあら探し君

スルーでおk

727 :デフォルトの名無しさん:2014/04/19(土) 10:58:02.59 ID:2/jFRqDT
むしろグラフィカルの方が効率がいい例なんていくらでも出てて
じゃあ、なんで〜って話となると答はごくごく単純で
どんな環境でも最低CUIとテキストエディタはあって汎用性あるけど
GUIは環境依存だから使われても環境といっしょにポシャるから
なかなか広まらない。
上のPrographCPXとか実用され始めてたのに会社ポシャってそのまんま。
(ルノー社内とか日本だとセガのサウンドチームがツール作るのに使ったりしてた)

728 :デフォルトの名無しさん:2014/04/19(土) 11:12:13.59 ID:MP1hLwSA
フォームみたいにグラフィックのほうが扱いやすいものは、そこの部分だけIDEが自動コード生成をすればいい

729 :デフォルトの名無しさん:2014/04/19(土) 11:27:55.56 ID:rLS4KdYY
>>724
> 建物や機械や回路は図で表現するけど、あなたの理屈で説明がつくかな?

あぁ、十分説明ができる。

それは、実際に形あるものだからだ。

最終的に絵になるものは、絵で書いた方がいい。

しかしコードというのはそのほとんどが、動作、命令だ。
コンピュータを動かすための、正確な命令だ。

それを絵で書くということは、さながら
ジェスチャークイズのようなものだ。
ジェスチャーで命令を伝える。
効率が悪いということはよく分かるだろう?

730 :デフォルトの名無しさん:2014/04/19(土) 12:03:13.17 ID:Fb4YL4It
オブジェクト志向に精通していれば
コードがまさにグラフィカルになってるプログラムになるよな

コードをより書きやすくするためのグラフィカルなら悪くないがな

例えばじゃんけんアプリのイメージを直接グラフィカルに表現して、
そのままプログラムになるなら当然良いだろう。

だが、作れるなら作ってみてくれって感じだな俺は
どうせコーディングのほうが俺にとっては早い

731 :デフォルトの名無しさん:2014/04/19(土) 12:29:50.78 ID:3iojgwbR
i++を書くコストは手書きのほうが格段にいいだろうけど
デメリットだけじゃなくてメリットの側面も考慮したほうが良いのでは?

732 :デフォルトの名無しさん:2014/04/19(土) 13:43:46.72 ID:q67SPze0
汎用言語とDSLを区別せずにごっちゃにしてるから話が進まないんだ
汎用言語の効率の悪さを叩くところから始めよ

733 :デフォルトの名無しさん:2014/04/19(土) 13:59:02.14 ID:3iojgwbR
for(i=1, i<10, i++) {
x += i;
}

loop 1,9,1 {
x += cnt
}

734 :デフォルトの名無しさん:2014/04/19(土) 15:15:26.14 ID:rLS4KdYY
>>730
ならねーよw

コードで書いたもの中のほんの一部分、
インターフェースやクラスの関係を
図に変換するだけだ。

その図も普通に文字で書いて変換した方が早いという。

意味があるのはスケッチ程度だ。
それじゃ何も動かない。

735 :デフォルトの名無しさん:2014/04/19(土) 15:25:36.29 ID:2/jFRqDT
だめだこの子w
自分が知らない知る気もないものに
"ダメに違いない"って自分の願望を
唱え続けてるだけだw

736 :デフォルトの名無しさん:2014/04/19(土) 15:27:19.98 ID:rLS4KdYY
↑ダメだ、また文句をいうだけで、終わった。

737 :デフォルトの名無しさん:2014/04/19(土) 16:14:51.85 ID:waqEll9H
上で言ってるシンタックスとセマンティックスが的確だな。
コードも何かを意味する記号に過ぎなくグラフィックも同様で、何か意味を記述する方法はコードもグラフィックも各々あるはずなのに、こいつはコードで書くのに適切なやり方をグラフィックだとやり辛いだろwって言い続けてるだけ。
今迄も散々そうじゃない例が上がってるはずだが、いくら言っても意味が通じないならコミニュケーション無理だな(´Д` )

738 :デフォルトの名無しさん:2014/04/19(土) 16:21:43.23 ID:rLS4KdYY
> コードで書くのに適切なやり方をグラフィックだとやり辛いだろ

それは正しい。

反論はでてない。

739 :デフォルトの名無しさん:2014/04/19(土) 17:14:02.67 ID:2/jFRqDT
だから>>689のPrograph言語の説明リンク見てないか
見てもまったく理解できてないだろ。
void main(void)
{
WindowPtr aWindow;
Rect aRect;
InitToolBox();
SetRect(&aRect,100,100,300,200);
aWindow = NewWindow(0,&aRect,"\pHello",TRUE,documentProc,(WindowPtr)-1,FALSE,0);
if(NULL != aWindow)
{
SetPort(aWindow);
MoveTo(50,50);
DrawString("\pMacintosh world");
while(!WaitMouseButtonPress());
DisposeWindow(aWindow);
}
}
ってCのソースコードが
http://www.geocities.co.jp/SiliconValley-PaloAlto/4654/sikai/doc1-1/cpx_sikai1-111.gif
という一枚のグラフィカルコードになるって説明されてんだろが。アホが。

740 :デフォルトの名無しさん:2014/04/19(土) 17:23:12.79 ID:rLS4KdYY
>>739
できるかどうかじゃない。
どっちが簡単かだ。
そこを履き違えるな。

741 :デフォルトの名無しさん:2014/04/19(土) 17:26:01.90 ID:MP1hLwSA
>>739
それ途中までだろ

742 :デフォルトの名無しさん:2014/04/19(土) 17:30:26.78 ID:waqEll9H
>>738
だからそんなやり方しねぇのに、これがやり辛いってwww
いけ沼www

743 :デフォルトの名無しさん:2014/04/19(土) 17:32:02.75 ID:rLS4KdYY
>>742
だから証明すればいい。

俺は何度も証明した。

i++

変数に1を加えるという処理を
たったの3文字で書き上げた。

これをグラフィカルにしてみよ。

744 :デフォルトの名無しさん:2014/04/19(土) 17:41:52.74 ID:aRoRY9CC
>>743
やり方は幾らでもあるだろうけどけど、iに対を使うところXがあるとして、iからXに引く、引いた線をクリックしたまま出てくる処理リストから++を選ぶ。
あれ、2操作でできちゃった(´・_・`)
元からXに引かれていたら
1操作だな(´・_・`)

745 :デフォルトの名無しさん:2014/04/19(土) 17:42:16.33 ID:aRoRY9CC
>>743
やり方は幾らでもあるだろうけどけど、iに対を使うところXがあるとして、iからXに引く、引いた線をクリックしたまま出てくる処理リストから++を選ぶ。
あれ、2操作でできちゃった(´・_・`)
元からXに引かれていたら
1操作だな(´・_・`)

746 :デフォルトの名無しさん:2014/04/19(土) 17:42:52.92 ID:aRoRY9CC
->iを使うところ

747 :デフォルトの名無しさん:2014/04/19(土) 17:53:40.27 ID:rLS4KdYY
>>744
えと、まさか変数やメソッドの数だけ
アイコンが存在するとか言うわけ?

なん百個もボタンがあって、
そこから選ぶんだよね?

笑えるwww

748 :デフォルトの名無しさん:2014/04/19(土) 17:57:55.18 ID:rLS4KdYY
RubyのIntegerのメソッドを調べてみた。
http://docs.ruby-lang.org/ja/2.0.0/class/Integer.html

> 引いた線をクリックしたまま出てくる処理リストから++を選ぶ。

これが引いた線をクリックしてでてくる、処理リスト
この中から使用するメソッドを選んでください。

chr
denominator
downto
even?
gcd
gcdlcm
integer?
lcm
next
succ
numerator
odd?
ord
pred
rationalize
times
to_i
to_int
to_r
to_s
upto

あぁ++がないや。実用的にするにはもっと沢山リストがだね。

749 :デフォルトの名無しさん:2014/04/19(土) 19:04:52.36 ID:qjQsToAi
>>748
横だけど一応…

Rubyに ++ 演算子は元々無いぞ

750 :デフォルトの名無しさん:2014/04/19(土) 20:02:00.67 ID:eci6DTQA
>>747
相変わらず既存の言語基準に物事を考えてるんだな。
バカ丸出しですね(´・_・`)

751 :デフォルトの名無しさん:2014/04/19(土) 20:48:43.71 ID:rLS4KdYY
>>749
あぁ知ってる。

> iに対を使うところXがあるとして、iからXに引く、引いた線をクリックしたまま出てくる処理リストから++を選ぶ。

なんて言ってたから、よりにもよって
++をリストから選ぶのかよww
って思っただけ。

752 :デフォルトの名無しさん:2014/04/19(土) 21:01:29.62 ID:2/jFRqDT
>>743
だから何度も見りゃ一目でわかるだろアホ、と掲示したろ。
http://www.geocities.co.jp/SiliconValley-PaloAlto/4654/sikai/doc1-1/cpx_sikai1-110.gif

データフロー言語だから左上の-1って入ってるオペレーションボックスがi--だよマヌケ。
-1された入力はなんらかの再帰処理通って
元の数字と掛け合わされた後出力されてる。
どれだけ頭カラッポなんだコイツ。

753 :デフォルトの名無しさん:2014/04/19(土) 21:27:36.93 ID:rLS4KdYY
-1 ってのはどう見ても文字だが・・・?

754 :デフォルトの名無しさん:2014/04/19(土) 21:31:13.34 ID:rLS4KdYY
-1と文字で書く代わりに、
えと、-1と文字で書いて(代わりなのに同じことするの?)、
その周りにいろんなボックスを配置する。(余計な作業増えてるじゃない?)

大変だなぁ。グラフィカルに作成するのってw

755 :デフォルトの名無しさん:2014/04/19(土) 21:44:12.64 ID:bRkrR4OG
>>752
どんだけ凄いかと思って画像開いたら
無限ループしてるバグコードでワロタw

756 :デフォルトの名無しさん:2014/04/19(土) 21:51:45.71 ID:pzsg7m6u
>>754
うーんそーだねー、一切キーボード使っちゃダメなんて知らなかったんだー。ぼくちゃんすごいねー(´・ω・`)

757 :デフォルトの名無しさん:2014/04/19(土) 22:13:30.64 ID:rLS4KdYY
>>756
キーボード使ってもいいよ。

ただし、-1を書くよりも簡単なら

(プラスアルファで囲いをつけたら逆に大変になってるだけだけどねw)

758 :デフォルトの名無しさん:2014/04/19(土) 22:27:59.76 ID:MP1hLwSA
すくなくともi--よりもたいへんだね

759 :デフォルトの名無しさん:2014/04/19(土) 23:00:49.02 ID:Firi/9oq
このときiをデクリメントする
とか設計書に書いている人にとってはより簡単なんだろ?

760 :デフォルトの名無しさん:2014/04/19(土) 23:07:57.78 ID:rLS4KdYY
俺がテンプレート(定規みたいなやつ)使って
フローチャート書くのが効率が悪いと気づいて
擬似コードを書くようになったのはいつだろうかな。
たしか高校の頃にはフローチャートは使わなくなっていた。

初学者に説明する時に使うのはいいかもしれないが、
プログラム言語をネイティブ言語のように扱えるプロとプロとの会話では
余計な装飾でしか無い。

761 :デフォルトの名無しさん:2014/04/20(日) 02:30:11.75 ID:jJiPXZnf
>>1
「グラフィカルな言語が欲しい」理由によるけどね。
タイプミス気にしながら、何度も同じコードを入力してるレベルなら、上のセマンティックス対応IDEで解決。
セマンティックスを構築したい(アルゴリズムが未知)領域の問題なら、グラフィカル言語を自作した方が早い。

762 :デフォルトの名無しさん:2014/04/20(日) 03:28:16.00 ID:lTNz4KpL
> (アルゴリズムが未知)領域の問題なら、グラフィカル言語を自作した方が早い

それは、たとえば、どんな問題ですか?

763 :デフォルトの名無しさん:2014/04/20(日) 03:33:18.17 ID:lTNz4KpL
一応書いておくか、何故未知な問題なのに
グラフィカル言語が適していると思うのか。

今あるアルゴリズムだって、発見されていなかった時代はあったわけだが
それに適していたのはグラフィカルでない言語だっただろう?

その不自然さが引っかかったからさ。
さも言ってみただけだろみたいな感じがね。

764 :デフォルトの名無しさん:2014/04/20(日) 03:44:13.54 ID:lUreprKb
つ VisualBasic

765 :デフォルトの名無しさん:2014/04/20(日) 07:04:25.39 ID:/jjV4rgn
まあ、グラフィカルプログラミングは上でもでている通り、
これからも出てくると思うよ

そしてまた日本はITで遅れを取るわけだな

766 :デフォルトの名無しさん:2014/04/20(日) 10:49:26.47 ID:zhWQwDWG
>>763
自分でなんかのアルゴリズム考えたことないの?

767 :デフォルトの名無しさん:2014/04/20(日) 12:07:00.82 ID:lTNz4KpL
>>766
あるよ。

グラフィカル言語を自作したほうが早かったことは
一度もなかったけどな。

768 :デフォルトの名無しさん:2014/04/20(日) 14:38:26.20 ID:LrvaI9Ps
>>760
プログラミングが上達するまではフローチャートのお世話になってた

というところなんじゃないかと、グラフィカルなプログラミング言語も

769 :デフォルトの名無しさん:2014/04/20(日) 18:11:41.84 ID:15F0t0Ka
>>763
>一応書いておくか、何故未知な問題なのに
>グラフィカル言語が適していると思うのか。


761の文は、「(既存の物を探すより)自作した方が早い」だろ?
763がコンテキスト解釈をミスった経緯って、言語解析の課題としては興味深い。

770 :デフォルトの名無しさん:2014/04/20(日) 18:20:42.09 ID:rd4ayzzb
>>767
> グラフィカル言語を自作したほうが早かったことは一度もなかったけどな。

自作したことなんかないだろ (w

771 :デフォルトの名無しさん:2014/04/20(日) 19:52:53.30 ID:hw+s/A6T
761 名前:デフォルトの名無しさん[sage] 投稿日:2014/04/20(日) 02:30:11.75 ID:jJiPXZnf
「グラフィカルな言語が欲しい」理由によるけどね。
タイプミス気にしながら、何度も同じコードを入力してるレベルなら、上のセマンティックス対応IDEで解決。

セマンティックスを構築したい(アルゴリズムが未知)領域の問題なら、グラフィカル言語を自作した方が早い。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


769 名前:デフォルトの名無しさん[sage] 投稿日:2014/04/20(日) 18:11:41.84 ID:15F0t0Ka

761の文は、「(既存の物を探すより)自作した方が早い」だろ?
763がコンテキスト解釈をミスった経緯って、言語解析の課題としては興味深い。



769って馬鹿なの?

772 :デフォルトの名無しさん:2014/04/20(日) 19:57:38.47 ID:LrvaI9Ps
貴様らが望む言語を作れば良い

773 :デフォルトの名無しさん:2014/04/21(月) 11:42:59.88 ID:mIseuF+c
馬鹿に構ってる暇があるならアイディアを出せ

774 :デフォルトの名無しさん:2014/04/21(月) 12:33:23.27 ID:giub/94P
「少なくとも自分にとって」未知のアルゴリズムを考える時は普通、解決に使えそうなオレオレ言語仕様をその場で考えて、図に書いてみるんじゃないの?
そういう意味で使えるグラフィカル言語があると嬉しいけどね。
>>1の動機は多分、761の前半なんだろうけど。
Lisperは構文木を直接書くから、AST=グラフと出来るらしいが、俺の練度では理解不能。

775 :デフォルトの名無しさん:2014/04/21(月) 13:27:02.44 ID:2fxw+XGi
アイデアを出せってお前が出せ

776 :デフォルトの名無しさん:2014/04/21(月) 18:59:05.88 ID:+mIOXj6e
FRP的なものやデータフロー言語的なものはグラフィカルな方が向くよね。可読性やデバッグとか含めたトータルだとグラフィカルの方がコスト低そう。スレッドコンテキスト境界を出たり入ったりするようなものはなおさら。
もちろんコードの方が効率的に書けるものはあるだろうけど、理想的なのはグラフィカルとコードをシームレスに混在できるもの。
上のバカみたいに++がコードより簡単に書けるかとか本当無意味だわ。
とりあえずUE4はグラフィカルとコード両方で書けるからこれがどっちがより多く使われるのか、成り行きみてみたいものだ。

777 :デフォルトの名無しさん:2014/04/21(月) 19:07:47.24 ID:8o/8KwGl
カルネージハート

778 :デフォルトの名無しさん:2014/04/21(月) 21:47:20.70 ID:yaM3rCK5
>>776
グラフィカルに見るのはいいけど、
書くのはやっぱりテキストのほうがいいよ。

779 :デフォルトの名無しさん:2014/04/21(月) 22:04:42.27 ID:Qx+MR827
絵と言語の関係について考えてみると、確かに絵の方が情報量が多いのは確かだな。
だからといって、絵では表現できない情報も多い。
文章を書かずに絵で説明しようとしてもすぐに限界が来てしまう。

いままでのプログラミング言語は文字(文章)で書かれてきた。
フローチャートなど、処理のつながりを視覚化しようとする取り組みもかなりあるが
文字を打った方が確実に早いという結果に終わっているのも現実。

なので、「グラフィカルなプログラミング言語」は
既存の言語とは異なる思想で組み立てられるべきだと考える。

780 :デフォルトの名無しさん:2014/04/21(月) 22:41:32.11 ID:1M7O1iaQ
能書きはいいからさっさと作れや。
できないなら引っ込んでろ。

781 :デフォルトの名無しさん:2014/04/21(月) 23:06:33.12 ID:giub/94P
>>779
>なので、「グラフィカルなプログラミング言語」は
>既存の言語とは異なる思想で組み立てられるべきだと考える。

まあ今のコンピュータ自体、数学上の「計算不可能な領域」の存在が証明されたから発展したもんだからな。
意味論構築には、取り敢えず記号があれば着手出来たから、文字ベースが発達したとも言える。
SysMLとか、Haskellでの計算領域拡張の試みが有るには有る。

782 :デフォルトの名無しさん:2014/04/22(火) 17:04:56.36 ID:aSUm92Xm
作業ディレクトリ から initファイルを開く

783 :デフォルトの名無しさん:2014/04/22(火) 17:32:20.70 ID:g8uMh2CA
上のPrographとか昔はなんでデータフローとか変なアーキティクチャ選んだんだ?
と思ってたけど、20年間いろんな言語見てきたら
一行ずつ処理を実行するという"スクリプトを書いてゆく"って
テキストベースの思考じゃなくて、グラフィカル言語だと
車とかの生産ラインみたいに
"入り口からデータが入ってきてそれを順次加工して出力を作る"って方が
"作業図"としては自然だからって理由が見えてきて「へー」となったよ。
LISPとかPrologとか変な言語を見る時もそうだけど
なんでそんな変なことを?って思う側が実は
特定の環境下で特定の事をやるのが"本物のプログラミング"だ!って
常識に囚われてることは多いよね。

784 :デフォルトの名無しさん:2014/04/22(火) 19:46:28.49 ID:aSUm92Xm
今の子供はどうか知りませんが、昔の子供は小学校で英単語やアルファベットを知らない子供が殆どでした。
そういう意味で、小さい頃からプログラミングをするならば、ローマ字や英単語を使うよりは日本語を使えるほうが良いのではないかと思いました。
また、2chでもI can’t write English well.で日本語で書くほうがスラスラと書けます。
そういう意味では、とてもライトな使用目的で日本語のプログラミング言語というものはありだと思いました。
ということで、グラフィカルなプログラミング言語という話題からは逸れますが、

もし あ<10 なら
  い = 0
そうでなく あ<0 なら
  い = −1
そうでなければ
  い = 1。

のように日本語で書ける言語も良いのではないでしょうか?なでしこという言語はありますが。

785 :デフォルトの名無しさん:2014/04/22(火) 20:21:17.31 ID:w4l4IAka
だから、なでしこでいいじゃん

786 :KAC:2014/04/22(火) 20:29:40.70 ID:vPp3xv6K
>>784
昔、Mindを使ったプロジェクトをやったことあるけど
入力が日本語になるといろんな要因で遅くなってしまうという弊害が大きくて
普通にCで書いた方が確実に早いという結論で終わった。

自由な日本語で書けないってことは
初心者にとっても結局難解なものになってしまうわけで・・・

787 :デフォルトの名無しさん:2014/04/22(火) 20:35:33.45 ID:M6IufU5g
>>783
まあ確かに++iというシンタックスを、GUIパーツで表現する積極的な意味は現在でも無いけどね。
元々のプログラミングは、グラフ指向(xyグラフとかじゃなく、有向グラフとかの)なんだが、問題は当時のマシンの処理能力。
基本構成単位がゲートICレベル未満だから、表示装置に文字を出すので精一杯。
現代なら、++iとかじゃなく、モナドとかの基本概念を電子回路図みたいに繋いでいくアプローチも面白そうだ。

788 :デフォルトの名無しさん:2014/04/22(火) 20:50:13.08 ID:aSUm92Xm
>>785
なでしこでいいよ
書いてなかったけどそのままc系の言語に移行できるって条件もあって
なでしこは文法が特殊なんだよね

789 :デフォルトの名無しさん:2014/04/22(火) 20:54:12.34 ID:aSUm92Xm
>>786
そうそう
だから日本語で書けるというだけ

if a<10 {
b = 0
else if a<0
b = -1
else
b = 0
}

変数がローマ字や英語で予約語が英語
俺は小学生の頃にBASICのような言語にあった命令のplayをピー・エル・エー・ワイと読んでたから
英語を知らないうちは日本語のほうが楽
んで、ちょっとしたことなら英語じゃなくて>>784のように記述できても楽っちゃ楽
そんだけ

790 :デフォルトの名無しさん:2014/04/22(火) 21:58:29.91 ID:aceH+mSU
++バカは消えたのか(´・_・`)

791 :デフォルトの名無しさん:2014/04/22(火) 21:58:48.17 ID:aceH+mSU
++バカは消えたのか(´・_・`)

792 :デフォルトの名無しさん:2014/04/22(火) 22:03:44.05 ID:w4l4IAka
continueとかスペルわかりにくいもんなー

793 :KAC:2014/04/22(火) 22:16:18.41 ID:vPp3xv6K
>>789
単語を簡単にってのなら、そういえば
ぴゅう太 の G-BASIC があったな…
昔の人は色々考えてたんだなぁ。

 10 モシ a < 10 ナラバ 30 ニイケ
 20 100 ヲヨベ
 30 オワリ
 100 カエレ

794 :デフォルトの名無しさん:2014/04/22(火) 22:38:50.70 ID:yZExreoi
プログラムが難しい理由が、
”英語だから" と間違って考えている人がいる限り
日本語プログラミング言語なんて馬鹿げた考えが
何度も出てくるんだろうなw

プログラマ上級者まで行かなくても
中級者レベルなら、英語というか
エセ英語のプログラミング英語は
何の苦もなくもなく使える。

795 :デフォルトの名無しさん:2014/04/22(火) 22:48:23.08 ID:DwFEDI7c
英語読めないなんて、プログラマでなくとも邪魔なゴミだから死ねばいいよ

796 :デフォルトの名無しさん:2014/04/22(火) 22:50:52.54 ID:yZExreoi
英語が苦手だからグラフィカルなーなんて言ってんのかもな。

797 :KAC:2014/04/22(火) 23:04:03.84 ID:vPp3xv6K
C言語がこんな感じだったらみんな理解しやすいんだと思う・・・か?

虚無 主処理 ( 虚無 ){
 文字 揮発 * 表示文字列;
 数字 愛 = 0;
 する間( ! 表示文字列[0] ){ 寝る(愛);愛++; }
 書式付表示("%s\n",表示文字列);
}

798 :デフォルトの名無しさん:2014/04/22(火) 23:38:20.42 ID:z8WHMXPV
書けない読めないからグラフィカルにしたいなんて奴がどっかにいたのか

799 :デフォルトの名無しさん:2014/04/22(火) 23:38:54.78 ID:yZExreoi
>>797
それをグラフィカルにしてみたらどうなるの?

800 :デフォルトの名無しさん:2014/04/22(火) 23:49:10.28 ID:3kjpv9g4
>>793
その手の奴はいつでもやってる
関西弁バージョンとかも定番だし
http://inforno.net/articles/2008/03/04/japanese-language-programing-in-scala

801 :デフォルトの名無しさん:2014/04/23(水) 00:37:00.37 ID:ArDtJbWQ
いや、お前ら(>>794,>>796)馬鹿か?
英語に固執する理由が無いっての
中高生以上ならプログラミング程度の英語は出来て当然
それが大前提だから英語力がどうとかいう話じゃないの
英語できるとかプログラミング書けるとかそういうところに優越を感じるレベルでもなくて
ただ単に書きやすいとか、やりやすいとかそういうこと
よくカスタマイズ出来るとかを粋に感じてiphoneに対してandroid推してる奴とかいたけど
そういうどうでもいいとこではなくて、チョチョイとシミュレーション計算したいとか
プログラミングを負荷が少なくもっと簡単に勉強したいとか
日本語でパラパラと書きたいとか、そういうニーズもあるっちゃあるでしょ?ってこと

802 :デフォルトの名無しさん:2014/04/23(水) 00:40:04.58 ID:7vo5B08Z
なんでもいいなら、英語でいいじゃん?
キーボードは英語を一番入力しやすいように
作られてるんだし。 1キー = 1文字

まあ、アルファベットを使う言語なら
英語じゃなくてもいいけど。

803 :デフォルトの名無しさん:2014/04/23(水) 00:51:49.49 ID:jGDL0Z25
>>794
別に英語知らんでも
「えふおーあーる、かっこ…あいえぬてぃー・あいは最初ゼロ、あいが10より小さい間繰り返す、毎回あい増やす」
「あいえふ、あいパーセント2がゼロなら、ぴーゆーてぃーえす偶数」

こんな読み方してようが、1人でプログラミングするには支障ないしな
そもそも複数人だろうと、例えばC言語の関数名とかは
略した名前が多いから割と読み方に個性出ると思うが、意外と意思疎通できるし…

804 :デフォルトの名無しさん:2014/04/23(水) 01:00:32.01 ID:7vo5B08Z
>>803
名前つけるときどうするの?

805 :デフォルトの名無しさん:2014/04/23(水) 01:02:36.23 ID:ArDtJbWQ
>>802
英語でいいじゃんて人がいてもいいけど、それは全員ではないの
わざわざ日本語で覚えるくらいなら、英語で覚えた方がいいのはある程度当然としても
(ifなんかはどの共通なわけで)

かんすう あれ(なに、それ)
  これ = なに + それ + なに * それ
  もどす これ。

function func(a,b)
c = a + b + a * b
ret c
end

まあ、どっちでもよくて日本語のバージョンがあってもいいんだよ
本格的にプログラミングしてなにかを作りたいとかなら
英語とか日本語云々よりC++とかJAVAとかの言語の選択になると

806 :デフォルトの名無しさん:2014/04/23(水) 01:04:00.95 ID:oGKIc+Vk
>>793
それを2000年頃に当時の2ちゃん語を使って書いたことがある。
 10 モシモダヨ a < 10 ナラバ 30 ニイッテヨシ
 20 ホザケ ”オマエモナー”
 30 シネ
のような感じで。
それを面白がった人たちが実際に動くようにしたのが
ギコBASIC

…もはや過去の遺物だが

807 :デフォルトの名無しさん:2014/04/23(水) 01:06:51.79 ID:ArDtJbWQ
ギコ何とかは2ch臭がするからジョークの中のジョークだろ
もっとNHK教育的なやつwwwWWWW

808 :デフォルトの名無しさん:2014/04/23(水) 01:21:41.16 ID:7vo5B08Z
>>805
日本語の文法を守れないのに、
日本語にする必要あるの?

809 :デフォルトの名無しさん:2014/04/23(水) 01:24:26.80 ID:ArDtJbWQ
>>808
楽さが人によって違うんじゃないかな?
日本語文法をできるだけ守ろうとするのはなでしこだけど
単に全角の日本語で書けてもいいよねと
簡単な例しか書いてないけど、通常の長いプログラムとかはとにかく「英語」なんだよ
日本語の方が、日本語に接してきた人なら瞬間的に認知しやすいというのはあると思う

810 :デフォルトの名無しさん:2014/04/23(水) 02:19:22.18 ID:jGDL0Z25
>>804
ローマ字でいい、組むことそのものにはあんま関係ないよ

…と言うか、俺なんて英語よりプログラミングが先で
プログラミングに出てくる単語から英語覚えたけどな

フォー、ワイル、イント、プリントはともかく
IFは実際アイエフだったし、LOCATEなんてロカテだったw
AUTOは見事にアウト…w

811 :デフォルトの名無しさん:2014/04/23(水) 02:23:40.86 ID:ArDtJbWQ
AUTOネタの正体見たり!

812 :デフォルトの名無しさん:2014/04/23(水) 19:43:25.97 ID:SR7M9SSi
プログラムは英語記法で
エージェントは日本語が有ってるかも

813 :デフォルトの名無しさん:2014/04/23(水) 23:18:37.09 ID:pr9pTfEN
グラフィカルなプログラミング言語ってスレタイ見た時、まずわかりやすく平易という方向性が見えた
これをもう少し拡大して考えると、EnableNantokaSwhithとか英語で書かれまくってるプログラミング言語は実は日常使わない英語なのでパッと見敷居が高い
初心者からちょっとしたプログラムやアプリケーションを作るまでの労力が現在10なら、それを5や6まで少なする
電卓くらい当たり前に使えるプログラミング言語があってもよくて、それがグラフィカルなものだったり日本語のものだったり
プロフェッショナルな方向性ではなく、初歩の習得の容易さや簡易なプログラムに対する敷居の低さを考える

パソコンでも文房具でもスマホでもそうだけど、一般向けの物は利便さだけではなく使用することの敷居の低さや容易さ、安さ、耐久性、確実さなどを追求するベクトルがある
だから、簡易な言語や機能としてプロや上級者のためではないものあっていい

814 :デフォルトの名無しさん:2014/04/23(水) 23:29:57.94 ID:+4GGWROK
Webシステムに特化したものだったら使いたい

815 :デフォルトの名無しさん:2014/04/23(水) 23:41:44.76 ID:+4GGWROK
MVCにかわる新たなモデルを作れないかな
さらには欲を言えばRDBMSの概念もグラフィカル思考に近づけたい

816 :デフォルトの名無しさん:2014/04/23(水) 23:50:28.55 ID:+4GGWROK
iPhoneで片手で気軽にプログラミングできるようなものが理想

817 :デフォルトの名無しさん:2014/04/23(水) 23:52:03.83 ID:+4GGWROK
Age

818 :デフォルトの名無しさん:2014/04/24(木) 02:25:29.86 ID:vGFJI3hL
>>816
わかる

819 :デフォルトの名無しさん:2014/04/24(木) 04:36:49.95 ID:6xlhO1bi
>>813
能書きはいいから、さっさと考えろよ。

820 :デフォルトの名無しさん:2014/04/24(木) 06:23:51.17 ID:+kum9QE5
>>815
何がしたいか分からなきゃ、モデル作り用がないんだが。

821 :デフォルトの名無しさん:2014/04/24(木) 06:45:54.71 ID:6xlhO1bi
グラフィカルにしたーいっていうだけで
何もアイデアを持っていない。

まず何が問題で、何を解決したいのか自分でわかっていない。
よくよく聞いてみると、結局プログラミングが苦手なだけという。

822 :デフォルトの名無しさん:2014/04/24(木) 07:38:52.76 ID:liWFOTCB
プログラミングが得意な人間が作るとIDEを作ることになる

苦手か、もしくは知らない人間が作るとどうなるかっていうとこが知りたいだけだ

823 :デフォルトの名無しさん:2014/04/24(木) 09:11:40.08 ID:6xlhO1bi
苦手な人用の機能はプロの足かせになることがある。
たとえば自転車の補助輪は、
競輪選手にとっての足かせになるように。

そういうプロの人にとって役に立たないどころか
逆に生産性を下げるようなものは受け付けられない。

824 :デフォルトの名無しさん:2014/04/24(木) 09:57:19.29 ID:jKz35WZ5
まーた「おれがやってる順番に実行するスクリプトをテキストエディタで編集するのがプログラミングだ!」さんかい?

825 :デフォルトの名無しさん:2014/04/24(木) 10:17:58.42 ID:N7H+wX8T
>>815
ER 図編集したら、データベースの定義スクリプト吐く奴ってないんだっけ?

826 :デフォルトの名無しさん:2014/04/24(木) 10:27:43.60 ID:k8u3HaH4
>>823
能書きはいいからさっさと考えろよ

827 :デフォルトの名無しさん:2014/04/24(木) 11:27:35.33 ID:463WpYd+
カルネージハートの思考パターンみたいな物くらいかな

828 :デフォルトの名無しさん:2014/04/24(木) 12:18:45.72 ID:bkiqjmph
壊れた機械みたいに俺が書いたカルネージハートを連呼してるな
頭がおかしい

829 :デフォルトの名無しさん:2014/04/24(木) 15:14:17.15 ID:KT8TA3nl
simulink
max/msp

830 :デフォルトの名無しさん:2014/04/24(木) 21:12:35.44 ID:1zyCBOxG
>>820
MVCモデルって書かれてる時点でWebだってわかるだろ馬鹿か?

831 :デフォルトの名無しさん:2014/04/24(木) 21:13:46.23 ID:1zyCBOxG
>>821
アセンブラでもやってろ

832 :デフォルトの名無しさん:2014/04/24(木) 21:57:05.61 ID:6xlhO1bi
>>825
> ER 図編集したら、データベースの定義スクリプト吐く奴ってないんだっけ?

あるよ。俺が知っているので言えば、MySQL Workbench

ただプログラム(ストアドプロシージャ)に関しては
ER図からストアドなんか生成できなかったはず。
MySQL Workbenchで管理できるけどコード自体は手入力。

で、今思い出したけど、Accessにはクエリビルダって言ってテーブルを線で結んで
JOINを作って、表示・更新フィールドをリストから選んで・・・ってやって
SQLを生成する機能あるよ。

https://www.bitpower.co.jp/software/muryou/%E3%82%AF%E3%82%A8%E3%83%AA%E3%81%AE%E6%AD%A3%E4%BD%93.pdf

SQLがプログラム言語のカテゴリになるのかは知らないけど、
これなんか、グラフィカルなプログラム言語として理想的な機能なんじゃないの?

もっとも俺はSQL直接書いてるけどね。今はAccess使ってないし、
複雑なものはクエリビルダでは作れなかったので。

今も実際に使っている人どう? 自分が使っていた時から
15年ぐらい経つけどあれから何か便利になった?

833 :デフォルトの名無しさん:2014/04/24(木) 22:00:05.28 ID:6xlhO1bi
>>830
MVCモデルというのはウェブが一般に普及していなかった時代に
SmalltalkでGUIアプリを作る時に使う設計だよ。

ウェブのMVCモデルというのはMVC2とも言って
元々のMVCとは似て非なるもの。

834 :デフォルトの名無しさん:2014/04/24(木) 22:04:37.65 ID:+kum9QE5
>>830
>>833の言う通りだな(´・_・`)なんつーか付け焼き刃が粋がってバカを晒してる感じかね

835 :デフォルトの名無しさん:2014/04/24(木) 22:10:36.66 ID:OqTnxjBg
googleでちょっと検索して出てたのを知ったかして書き込んだんでしょw

836 :デフォルトの名無しさん:2014/04/24(木) 22:12:00.19 ID:f6grzxUJ
minecraftのレッドストーン回路とか
グラフィカルどころか立体だけど

837 :デフォルトの名無しさん:2014/04/24(木) 22:17:22.30 ID:6xlhO1bi
>>836
これかな?
http://www26.atwiki.jp/minecraft/pages/26.html

真理値表 に対応するオブジェクトをminecraftで作ってみたって感じかな?

838 :デフォルトの名無しさん:2014/04/24(木) 22:52:32.69 ID:jKz35WZ5
smalltalkの直接の影響下にあるObjective-Cが開発言語のiOS/MacOSXは
公式のガイドでMVCで作りなさいよ、iPhoneのUIはシングルウィンドウで
タッチインターフェイスのMacOSXのようなものだから
MVCで役割分離することでビューの差し替えで簡単に
iPhone、iPad、Mac間で相互で動くアプリが作れますよって説明されるな。
http://i.imgur.com/ON47ypg.jpg


…そういやAppleはMVCでビュー分離して環境ごとに最適化したUIを作れゆーてるけど
Windows8とかAndroidはデスクトップとタブレットとモバイルで
UI切り替えろゆーてないのかしら…

839 :デフォルトの名無しさん:2014/04/24(木) 22:58:35.84 ID:ZwmdV8jX
グラフィカルなプログラミングなんて研究分野では珍しくない。

Labview
http://www.ni.com/newsletter/51735/ja/

Matlab
http://www.tech.plym.ac.uk/sme/mech331/fuel5.htm

840 :デフォルトの名無しさん:2014/04/24(木) 23:16:05.97 ID:h8TOm7ug
>>832
そう言われれば Access もあったな。
いまいち痒いところに手が届かなかったから、おらも SQL てで書いてたな。
Access97 の時代だから、今どうなってるのからさっぱりだわ。

841 :デフォルトの名無しさん:2014/04/24(木) 23:19:23.92 ID:6xlhO1bi
>>839
おー、やっと分かった。
http://www.ni.com/video/1875/ja/

これの3:10秒ぐらいの所、

(39.10 - 32.00) * (5.00 / 9.00) という計算式を
グラフィカルに書くとああなるんだな。

842 :デフォルトの名無しさん:2014/04/24(木) 23:31:39.53 ID:jKz35WZ5
グラフィックプログラミングによくあるデータフロータイプのは
そーゆーのだとだいぶ前からこのスレで出てたじゃない。

843 :デフォルトの名無しさん:2014/04/24(木) 23:34:44.39 ID:6xlhO1bi
でもまさか本当にキーボードで入力すれば済むような
+とか−とかのアイコンをポトペタで置いていくとは
思わないでしょ?

844 :デフォルトの名無しさん:2014/04/24(木) 23:37:42.36 ID:6xlhO1bi
あ、一つ聞きたいんだけど、
>>841の「温度計」っていうのは、
最初から用意されたパーツなわけ?
それともあれも作れるの?

データ変更時イベント発生時(onchange)に
他のパーツに値をセットするだけの処理じゃなくて、
あのパーツそのものをどうやって作るのかを見てみたい。

845 :デフォルトの名無しさん:2014/04/25(金) 00:01:59.39 ID:jKz35WZ5
トップのビデオでコンパネとコード作るとこから始めてるじゃないの。
http://www.ni.com/labview/why/ja/

846 :デフォルトの名無しさん:2014/04/25(金) 00:03:54.29 ID:Pkyhb6hg
おまえらはもうPLDで我慢しとけよ

847 :デフォルトの名無しさん:2014/04/25(金) 01:04:32.37 ID:4klH39dY
>>845
それ用意されているものを配置しているだけでしょう?

848 :デフォルトの名無しさん:2014/04/25(金) 06:25:18.34 ID:8Y6XQoMM
MVCといえばIBMがMVPというのを一時やろうとしてたが消えちゃったね

849 :デフォルトの名無しさん:2014/04/25(金) 08:24:52.16 ID:IMABWYJa
>>847
普通の言語も用意された機能やライブラリを書いてるだけだが?

850 :デフォルトの名無しさん:2014/04/25(金) 11:28:40.59 ID:4klH39dY
>>849
えと、だからそのライブラリ(用意されているパーツ)を
どうやって作るのかを見てみたいって話なんだけど。

851 :デフォルトの名無しさん:2014/04/25(金) 11:46:57.09 ID:IMABWYJa
>>850
一般的な話としてはプリミティブな奴は普通の言語で作ればいいでしょ?
グラフィカルな奴で作ったものを部品として使いたいならそう言う仕組み (ライブラリアンとか) 作ればいいだけで、普通の言語と同じでしょ。
>>839 の奴が具体的にどうしているか知りたいなら、ベンダーに聞けばいいだけだし。

852 :デフォルトの名無しさん:2014/04/25(金) 12:20:07.17 ID:4klH39dY
残念、結局普通の言語で作るのか。
グラフィカルなプログラミング言語というより
用意されているものを、つなげるだけなのね。

853 :デフォルトの名無しさん:2014/04/25(金) 12:53:00.71 ID:IMABWYJa
>>852
いや、だから普通の言語と同じでしょ。
いったい何を期待してるんだ?

854 :デフォルトの名無しさん:2014/04/25(金) 13:40:48.39 ID:4klH39dY
>>853
> いや、だから普通の言語と同じでしょ。

それは言い方がおかしい。

君が言った
> 一般的な話としてはプリミティブな奴は普通の言語で作ればいいでしょ?
からすると、

グラフィカル言語が普通の言語と同じなのではなく、
パーツを作るときにはグラフィカル言語のやり方ができないので、
普通の言語で作るしか無いという意味でしょう?

855 :デフォルトの名無しさん:2014/04/25(金) 14:01:10.07 ID:IMABWYJa
>>854
>>851 の最初の文しか読んでないのかよ (w

856 :デフォルトの名無しさん:2014/04/25(金) 14:02:45.52 ID:4klH39dY
>>855
だって、プリミティブなもの(=パーツ)を
どうやって作るのかを質問したのですから・・・。

857 :デフォルトの名無しさん:2014/04/25(金) 14:08:15.68 ID:IMABWYJa
>>856
パーツが必ずしもプリミティブというわけじゃないぞ。
とにかく適当な言語の実装調べてこいよ。

858 :デフォルトの名無しさん:2014/04/25(金) 14:08:56.01 ID:3vuOghX4
CコンパイラはCで書かれている。って言われて
混乱してる素人臭がすげぇ

859 :デフォルトの名無しさん:2014/04/25(金) 14:15:39.70 ID:jrLTZF6i
プリミティブかどうかは関係ないなら
パーツの作り方を聞いて、なんでプリミティブとか言い出したんだ?

パーツの作り方を答えるべきだろう。
グラフィカル言語でも用いる、
グラフィカルなパーツを作るには
結局は普通の言語を使うしか無いってのが答えかね?

たとえば>>841に用意されている
「+」というアイコンの代わりに
任意の関数を使うときどうするんだ?

っていうか「+」アイコンを使う時点で笑えるがww

>>841に書いてある数式だったら一行ですんでいるのに
マウスでポチポチとwwww

860 :デフォルトの名無しさん:2014/04/25(金) 14:30:06.92 ID:3vuOghX4
(ひとつの例だけやっと見たと思ったら今度はそれが全てだと思って
その言語でこれはできるのか!とか言い出したよ…
どう見ても計測器用のデータフロー言語になに言ってんだコイツ)

861 :デフォルトの名無しさん:2014/04/25(金) 14:31:30.74 ID:jrLTZF6i
グラフィカル言語っていうのは
汎用言語には成り得なくて
DSLみたいなもんだってことですねwww

862 :デフォルトの名無しさん:2014/04/25(金) 15:06:43.15 ID:IZttWr8m
レゴブロックで説明した方が早そうな感じ

863 :デフォルトの名無しさん:2014/04/25(金) 15:07:26.19 ID:YQS1C1Wk
>>858
プログラムが無い状態ではCPUにわかる命令がメモリに保存されていないとコンピューターが動作しない
コンピューター(CPU)を動作させる命令は機械語と呼ばれているもので、
数値で表せば10011101010のように2値の組み合わせで表される
まずこれが最初にあって、その後その命令でアセンブラのようなより簡易にプログラミングできる言語環境が提供される
さらに、C言語など人がよりプログラミングしやすい言語環境が提供されるが
すでに、それら環境が提供されている状態ではC言語でC言語をコンパイルする環境を構築することも可能である
なぜならば、C言語で書かれたプログラムは多くの場合、最終的には機械語に翻訳されるためC言語でC言語の環境を作成しそれを機械語に翻訳するという作業には何もおかしなところがないからである

864 :デフォルトの名無しさん:2014/04/25(金) 15:08:04.90 ID:jrLTZF6i
>>862
> レゴブロックで説明した方が早そうな感じ

期待してる。

865 :デフォルトの名無しさん:2014/04/25(金) 19:35:22.43 ID:+wM+/P+I
>>859
こいつ++バカだろ。
相変わらず視点が矮小すぎて笑えるw

866 :デフォルトの名無しさん:2014/04/25(金) 19:36:34.78 ID:KbLWmMY4
いや、グラフィックが効率が悪くて学習とか用のなのは同意だが、ネイティブに近いパーツを他の言語で作るのは全く悪くないよ
C#とかも一部はCなんかのコードを呼び出してるし、スクリプト言語でもその言語自体で実装された処理系があるのは人と金が大量にあるほんの一部の言語だけ

867 :デフォルトの名無しさん:2014/04/25(金) 19:58:12.69 ID:jPmvuOB6
粒度の大きい部分しか扱えないはずだし
汎用言語と競合するものじゃない
DSLでなにがわるい

868 :デフォルトの名無しさん:2014/04/25(金) 20:00:43.11 ID:MZsAYGmz
Windows95が世に出たころにオーサリングツールの宣伝動画を見た記憶がある。
なんというソフトだったかは忘れた。

10年後にはコーディングなんて原始的な作業になっていてオーサリングツールを
使ってグラフィカルインターフェイスだけでプログラミングする時代になるんだろうな
なんて想像していたけど、そんな時代はまだまだ先の話みたいだね。

869 :デフォルトの名無しさん:2014/04/25(金) 20:13:21.91 ID:jPmvuOB6
グラフィカルインターフェースだけでスマホの筐体の色を変えられます

870 :デフォルトの名無しさん:2014/04/25(金) 20:28:22.17 ID:nsFgzzSj
>>868
言語能力とライブラリが飛躍的に向上したからね。

昔(Window 95時代)は入力値が変わると
出力が変わるみたいな、データフロータイプな処理は
入力が変わったことを検知するループを作ってとか
受け取ったメッセージを適切な型に変換してとか
色々煩雑な処理が必要だってけど、今はjQuery風に書くと

$('#src').on('change', function() {
 var val = $(this).val();
 val = 色々計算(val)
 $('#dest').val(val);
});

この程度で書けるようになってしまったしね。

少なくともデータフロータイプに関しては言語ではなくて、
用意されているライブラリぐらいにしか価値がなくなってる。

871 :デフォルトの名無しさん:2014/04/25(金) 21:22:12.57 ID:u79u0vmH
>>868

Klick&Playのこと?

872 :KAC:2014/04/26(土) 15:40:43.79 ID:+E4Yxb7w
グラフィカルときいて連想するのが人によってバラバラだな。
YPSみたいに構造化を視覚化する開発環境を連想するものもいれば、
アニメ「宇宙のステルヴィア」みたいに文字などが一切でないものを連想するものもいる。

前者なら、いろいろな会社からすでに製品が出されているから実現は可能。
後者なら、「どうやって表現するのか」が議論ななるんだろう。

別のことを思っている者が会話しても話は進まんよ。

873 :デフォルトの名無しさん:2014/04/27(日) 07:40:59.71 ID:XY8MAa1t
当たり前の質問したいんだけど。
Windowsでエクスプローラーで、

・C:\AAAのBBB.txtってファイルをC:\CCCにcopyする時
・C:\AAAのBBB.txtってファイルをC:\CCCにmoveする時

ってそれぞれ内部的にはDOSコマンド(今はコマンドプロンプト?)の様な

copy C:\AAA\BBB.txt C:\CCC\BBB.txt
move C:\AAA\BBB.txt C:\CCC\BBB.txt

こんな感じで動いているんでしょうか?

874 :デフォルトの名無しさん:2014/04/27(日) 07:48:21.87 ID:PjLFHi1Y
APIを呼び出している

875 :デフォルトの名無しさん:2014/04/27(日) 13:15:11.97 ID:t1mtJyDY
>>873
初期のWindowsならそういうこともあったかも知れんね、DOS上で動いてたし
ただ今はコマンド自体もWindowsAPI呼んでるだろうし
Explorerからコマンド経由でAPIなんてことワザワザやらんかと

それに近いことやってるのはLinux世界かな
基本的なファイル操作は流石に枯れてて今更GUIからコマンド経由せんでもいいが
開発の続いてる技術に関しては、まずコマンドで実装される傾向があるから
ガワだけ作って内部でコマンド呼ぶ、フロントエンドってやり方はよく使われる

876 :デフォルトの名無しさん:2014/04/27(日) 13:33:59.88 ID:TcUJdg0l
> 初期のWindowsならそういうこともあったかも知れんね、DOS上で動いてたし

ねーよ。適当な事言ってんな。

877 :デフォルトの名無しさん:2014/04/27(日) 13:40:24.86 ID:t1mtJyDY
どっちに「ねーよ」と言ってんのか知らんが、
かも知れんは、かも知れんレベルの話として受け取ってもらうしかないぞ

878 :デフォルトの名無しさん:2014/04/27(日) 13:50:17.75 ID:TcUJdg0l
> 初期のWindowsならそういうこともあったかも知れんね、

ねーよ。

879 :デフォルトの名無しさん:2014/04/27(日) 13:52:20.88 ID:t1mtJyDY
そうか、無いと教えてくれてありがとうな

880 :デフォルトの名無しさん:2014/04/27(日) 13:56:26.98 ID:jKbi43u9
そもそも初期の Windows にエクスプローラなんてあったっけ?

881 :デフォルトの名無しさん:2014/04/27(日) 14:04:07.25 ID:t1mtJyDY
ファイルマネージャだな

882 :デフォルトの名無しさん:2014/04/27(日) 14:36:46.06 ID:udbvuRA2
プログラミングはプログラマーがするものっていう考え方は古い
子供から年配の人まで気軽にできるようなものを作りたい

883 :デフォルトの名無しさん:2014/04/27(日) 15:14:36.87 ID:s0NPrJow
>>882
おもちゃコントロール言語なら
https://www.youtube.com/watch?v=lKqIJPGK3sg
(Lego Mindstorms EV3)
https://www.youtube.com/watch?v=qOh9Qlx4itI
(Lego MindStroms nxt)
子供が解説してるのを選んでみた。

なかなか、ぱっと見でよく分かるサンプルがないぜ...(公式サイトにも)

884 :デフォルトの名無しさん:2014/04/29(火) 01:39:09.29 ID:BVOx6MN/
>>883
おもちゃじゃなくて使用性の高い言語って意味

885 :デフォルトの名無しさん:2014/04/29(火) 01:42:16.09 ID:bQ2SMtm3
きみは使用性の高い言語を出されたら
意味すら理解できなかったじゃないの。

886 :デフォルトの名無しさん:2014/04/30(水) 22:02:58.74 ID:xx8J+Or/
excelってすごいな

887 :デフォルトの名無しさん:2014/05/01(木) 00:11:25.73 ID:x4N+3w9l
>>886
いろんなショートカット覚えたら尋常じゃないくらい作業早くなって行くしな

888 :デフォルトの名無しさん:2014/05/01(木) 01:45:26.75 ID:7LtY7D/L
886だが
入力や出力の個数の変化に応えられるし定型化された操作を振るだけで結果が出る
そして大抵の事務作業はこれに適していること
これはかなり理想に近いんじゃないかと思う(あくまで仕事をこなすのがプログラムとした場合の記述方法として)
対応できないのも相当にあるけどこのスレの目指すグラフィカルな言語ってのは
やっぱりある程度の妥協点(目的に特化、図としての利点を伸ばす)がないとテキスト記述にゃ叶わないと思うわ
確かに図は人間に分かり易いし直感的なんだが文字に直感が働くよう訓練するほうがコンピュータへの指示においては色々便利
曖昧さがないし解析も容易
結局グラryであっても解析は行うだろうけど得られる結果が同一であるものを目指した場合にどっちが人間が正確に書けるかっていう

889 :デフォルトの名無しさん:2014/05/01(木) 16:08:08.75 ID:Uxtylliz
人のプログラムを読む時にもしかしたら図付きの方が見やすくなるかなと思った

890 :デフォルトの名無しさん:2014/05/01(木) 16:23:27.03 ID:qCDJU0g+
仕様を決めるときに、図を書かないと全く理解できない場合がある。

891 :デフォルトの名無しさん:2014/05/02(金) 12:52:36.78 ID:Pfd+HO5D
> 確かに図は人間に分かり易いし直感的なんだが

その図というものを、俺はフローチャート もしくは PADで
イメージしているんだけど、こんな感じであってる?

http://www.hitachi.co.jp/Prod/comp/soft1/manual/pc/d378270/LANG0027.HTM

892 :デフォルトの名無しさん:2014/05/02(金) 13:48:20.37 ID:D33zk24n
>>891
今時は、UMLかSysML。

893 :デフォルトの名無しさん:2014/05/02(金) 13:54:08.00 ID:Pfd+HO5D
UMLってクラス定義しか生成できなかったと思うけど?
実装は空。

894 :KAC:2014/05/02(金) 15:05:10.87 ID:I4CxCkey
>>893
UMLってのはクラス図だけじゃなくて、
構造と振る舞いを記載できる仕様記述言語だよ。

動きなら、状態遷移図とかシーケンスとかであらわす。

895 :デフォルトの名無しさん:2014/05/02(金) 15:20:03.73 ID:AiE+A4Zp
関数型とUMLって相性いいん?

896 :KAC:2014/05/02(金) 15:43:39.35 ID:I4CxCkey
>>895
オブジェクト指向で設計したもの(UMLで記載)が
C言語で実装できるかとかそういう話?

ちゃんと理解してれば実装できるけど、
相性がいいかと言われればNoだな。

897 :デフォルトの名無しさん:2014/05/02(金) 15:50:04.40 ID:s2AKWD4F
なんで関数型でC言語が出てくるw

898 :KAC:2014/05/02(金) 15:58:37.18 ID:I4CxCkey
あぁ、関数型しか書いてないから
関数型定義で擬似オブジェクト指向を造る話のほうかとかと思たよ。

関数型言語ならそう書いてくれ。

899 :デフォルトの名無しさん:2014/05/02(金) 17:13:01.73 ID:VGttU68Q
俺も関数型ってHaskellとかLispのこととしか思わんかったが…何故そういう解釈になったw

900 :デフォルトの名無しさん:2014/05/02(金) 17:17:32.32 ID:VGttU68Q
そもそも擬似オブジェクト指向ってなんだ…

オブジェクト指向は考え方だから、C言語だろうが何言語だろうが
その考え方に基づいてプログラミングしたらオブジェクト指向だよ

オブジェクト指向プログラミング言語はそれを行い易く設計された言語だから
普通はそれを使うけど、C言語でやったとしてもそれは擬似とかじゃないぞ

901 :デフォルトの名無しさん:2014/05/02(金) 17:23:14.07 ID:+HoqucNW
>>900
OOPでググれ

902 :デフォルトの名無しさん:2014/05/02(金) 17:32:51.27 ID:YjmVn3e2
オブジェクト指向は俺はC++でこれは違うと思って
Javaでまだなんか違うと思って
Objective-Cでああこれだ、と納得したクチなので
たぶんあれぐらいみんな自分のいるとこがオブジェクト指向だと
認識がバラバラの言葉もないと思う。

903 :デフォルトの名無しさん:2014/05/02(金) 17:34:36.24 ID:MIIxms9b
>>900
Cでメソッドのオーバーライド実現させる方法わかる?

904 :デフォルトの名無しさん:2014/05/02(金) 17:40:00.07 ID:s2C1A73T
C++て初期の頃はプリプロセッサでCに変換されてコンパイルしてたんだよ。

905 :デフォルトの名無しさん:2014/05/02(金) 17:56:08.78 ID:YjmVn3e2
Cでメソッドって時点で文字列渡しかな〜と考えるので
関数の頭の方に記述してあるであろう"メソッド文字列判定部"の
本来の処理の前の部分に違う処理書いて"オーバーライド"?
たぶん実際背後ではこれに似たことやってるだろうから
Cプログラマはオブジェクト指向嫌うのかもな。

906 :デフォルトの名無しさん:2014/05/02(金) 18:00:53.34 ID:pCCcCqiJ
オブジェクト指向も慣れれば
頭の中でグラフィカルに展開されるけどな
結局は何と何が繋がってるかに過ぎないわけで
右脳使え右脳

907 :デフォルトの名無しさん:2014/05/02(金) 18:02:33.37 ID:s2AKWD4F
>>905
Objective-CっだってランタイムはCで書かれてるから、Cでも出来ない事は無いだろ。
メソッドは文字列で管理してるな。
レシーバがサブクラスならサブクラスのメソッドリストを探してとかやるんじゃね?

908 :デフォルトの名無しさん:2014/05/02(金) 18:18:29.52 ID:kG5D/T/U
>>903
関数ポインタ使ったらあかんの?

909 :デフォルトの名無しさん:2014/05/02(金) 18:26:07.73 ID:YjmVn3e2
Objective-Cのクラスは全部ポインタだな。
C+smalltalkだからポインタなんて知らない人もみんな
(hoge*) hageで*はおまじない扱いでインスタンス宣言しとるな。

910 :デフォルトの名無しさん:2014/05/02(金) 18:52:35.67 ID:AiE+A4Zp
>>896
今時関数型書いて構造プログラミングもないだろw

いや言いたかったのは関数型にしたときに分類されるデータなどはオブジェクト志向のクラスとはまた粒度とかことなってくるからUMLがうまく適合するのかなーって話。

911 :デフォルトの名無しさん:2014/05/02(金) 22:21:52.27 ID:Pfd+HO5D
>>894
> 動きなら、状態遷移図とかシーケンスとかであらわす。

状態遷移図やシーケンス図って
そんなに書きますか?

複雑な場合には使いますけど、
さすがにフローチャートの代わりにはならないと思いますが?

912 :デフォルトの名無しさん:2014/05/03(土) 01:37:53.52 ID:xxSHnc2z
>>911
つーか言語仕様としては書けるけど誰も書いてなくね

913 :デフォルトの名無しさん:2014/05/03(土) 02:01:13.97 ID:57QiFJuQ
UML発案者たちがインタビューでUML2.0はクソ
標準化したせいで言語としての厳密さとか使わない書き方とか
盛り込まれて、仕様の8割使わない。ってボロクソ言ってたから
逆に標準UML2.0に厳密に従えば言語の代わりになるんじゃね?

俺3種類ぐらいの書き方しか使わないけど。

914 :デフォルトの名無しさん:2014/05/03(土) 02:06:22.91 ID:Nb5eUXCJ
XViewのソース見ればCでOOPやろうとするとどうなるか良くわかる

915 :デフォルトの名無しさん:2014/05/03(土) 03:05:14.18 ID:BzVjbdP5
>>912
組み込み系とか通信系とかなら普通に使うぞ > 状態遷移図、シーケンス図

916 :デフォルトの名無しさん:2014/05/03(土) 12:35:24.66 ID:NUO+XoEk
UML2-- を定義しろ

917 :デフォルトの名無しさん:2014/05/03(土) 12:50:46.89 ID:pGCoyN25
>>915
状態遷移図やシーケンス図だけで組み込みアプリ作ってるの?
使うのは組み込みアプリの中の一部分だけじゃない?ってことなんだけど。

思うにグラフィカルなものが適しているのって
「特定の種類のアプリ」ではなくて「アプリの中の一部分」だと思うんだ。

一つのアプリを作るとき、状態遷移図が適している部分には
状態遷移図を使うだろうけどそれ以外の部分には使わないでしょ?
フローチャートでは書くことができるけど、状態遷移図では
書けないってものがあるはず。

それと同じでグラフィカルなものが適している部分はあるけれど
アプリ全体全てがグラフィカルで作るのに適しているものはないんじゃないかな。

918 :デフォルトの名無しさん:2014/05/03(土) 13:03:16.36 ID:BzVjbdP5
>>917
適材適所って言葉知ってる?

なんか、使 { わない理由 | えない言い訳 } を探してるとしか思えない。

919 :デフォルトの名無しさん:2014/05/03(土) 13:06:34.71 ID:pGCoyN25
>>918
いや、だから俺も適材適所の話をしてるのよ。
一つのアプリの中で適材適所というものがあって、
アプリ全体を一つのやり方で作れないって話。

たとえばクラス図があれば、クラスの雛形、つまり関数定義はできるけど
その関数の実装はクラス図じゃできない。関数の実装は
フローチャート図だろうねってこと

920 :デフォルトの名無しさん:2014/05/03(土) 13:37:07.04 ID:QUw1rPx0
>>919
お前なんかグラフィカルに親でも殺されたの?

921 :デフォルトの名無しさん:2014/05/03(土) 13:49:56.05 ID:jNwOiaKe
前も出たけどグラフィカルで組むとデータがクラスに入ってきて
そのデータに加工や処理をしていくというデータフロータイプの書き方の方が自然な場合が多くて
処理の方を順番に書く、いわゆるフローチャートをスクリプトに起こした形の
"普通のプログラム"とはだいぶ描き方が変わるよ。

922 :デフォルトの名無しさん:2014/05/03(土) 14:06:05.99 ID:pGCoyN25
>>920
あの、>>919では一言も「グラフィカル」のこと言ってないんですけど?
ちょっと過剰反応すぎやしませんか?

923 :デフォルトの名無しさん:2014/05/03(土) 14:08:38.05 ID:pGCoyN25
>>921
> そのデータに加工や処理をしていくというデータフロータイプの書き方の方が自然な場合が多くて

それはデータフロー図ってことでいいのでしょうか?

こういうのです。

https://www.google.co.jp/search?q=データフロー図&tbm=isch

924 :デフォルトの名無しさん:2014/05/03(土) 14:09:45.12 ID:pGCoyN25
データフローダイアグラムともいいましたね。

http://www.dab.hi-ho.ne.jp/sasa/hyoryuki/dfd/

925 :デフォルトの名無しさん:2014/05/03(土) 14:12:00.76 ID:BzVjbdP5
>>919
> アプリ全体を一つのやり方で作れないって話。

当たり前でしょ?
何を言いたいのか、さっぱりわからんのだが。
理想の開発環境でも追い求めてるのか?

926 :デフォルトの名無しさん:2014/05/03(土) 16:58:14.16 ID:zk/sfJQ0
まあこのスレはグラフィカルなプログラミング「言語」のスレだからなあ
最終的にグラフィカルでなくなるなら、それグラフィカル言語なのか?とは思う

927 :デフォルトの名無しさん:2014/05/03(土) 17:34:30.03 ID:PCsgWtGl
>>925
通常の言語と同じようにグラフィカルな言語を使うとどうかみたいな話題が以前にあったからそういう系統の話なんじゃないかと

928 :デフォルトの名無しさん:2014/05/03(土) 20:20:48.09 ID:QUw1rPx0
>>922
お前のグラフィカルが言語的なものを指してるのか知らんけど、俺は図とか使ってるもの全体を指してるので何もおかしくはないけど。
つーかこの流れでシーケンス図とかクラス図とかでてそれがグラフィカルの範疇に入らないと思ってるのはお前だけだろ。

>>926
最終的にはマシンに対する命令になるんだからその理論は意味ない。

929 :デフォルトの名無しさん:2014/05/03(土) 20:34:46.14 ID:PCsgWtGl
コンパイルして機械語になるならそこを想定して言語と言いたくなるとはちょっと思った

930 :デフォルトの名無しさん:2014/05/03(土) 21:58:36.05 ID:BzVjbdP5
>>929
Rational Rhapsody とか使えば、クラス図と状態遷移図からソースコード吐いてくれるよ。
まあ、各状態の処理は個々に書かないといけないけど、状態遷移図とソースコードが必ず一致してる安心感と、シーケンスが正しいかのチェックができるのはいいと思う。
ただ、ちょっと高過ぎる。

931 :デフォルトの名無しさん:2014/05/03(土) 22:16:48.24 ID:PCsgWtGl
まだそういうのが高いってことでいいのかな?

932 :デフォルトの名無しさん:2014/05/03(土) 22:42:04.39 ID:FV78T//N
>>928
いつから、シーケンス図やクラス図が
”プログラム言語” になったの?

UMLはその名の通り、モデリング言語っていうのならわかるけど、
プログラム言語かどうかだよね?

933 :デフォルトの名無しさん:2014/05/03(土) 22:43:37.31 ID:ygYVYAmb


934 :デフォルトの名無しさん:2014/05/03(土) 22:46:39.09 ID:FV78T//N
わからないならわからないでいいよ。

HTMLはプログラミング言語じゃないし、
UMLもプログラミング言語じゃない。

それだけのことだからw

反論するならどーぞ。
しないなら、それはそれでいい。

935 :デフォルトの名無しさん:2014/05/04(日) 08:09:16.81 ID:y/dXxXPg
>>932
>>917がおまえと同じか知らんがシーケンス図でプログラムかけるのとか他でもそれでソース生成がとか話に上がってんだろ。
とりあえずおまえの定義と1mmでも違ったらそれは間違ってる言うならどんな議論も成り立たないよきっと。俺の知識はこんなにただしいんだうりいいいいい!ってしたいならブログにでも書けば?

936 :デフォルトの名無しさん:2014/05/04(日) 11:48:18.44 ID:ph7JBR1/
>>935
定義というのは個人の定義ではなくて
一般的な定義にしましょう。

それなら(UMLやHTMLはプログラム言語ではないけど)
文句は無いでしょう?

937 :デフォルトの名無しさん:2014/05/04(日) 12:39:23.97 ID:M/fXRR5a
>>935
> シーケンス図でプログラムかける

細かい話だが、シーケンス図は動作の結果を書いてる図なので、これからソースを生成できる奴って見たことないんだけど、見落としてるのかなぁ。
ソースとシーケンス図が合ってるかをチェックするのはあるけど。

938 :デフォルトの名無しさん:2014/05/04(日) 12:40:55.09 ID:M/fXRR5a
>>934
> HTMLはプログラミング言語じゃないし、
> UMLもプログラミング言語じゃない。

プログラム言語の定義教えて

939 :デフォルトの名無しさん:2014/05/04(日) 13:13:54.60 ID:89Z5u5ml
逐次処理、分岐選択、繰り返しの3つが記述可能なことは必須、とよく言うね

940 :デフォルトの名無しさん:2014/05/04(日) 13:16:14.35 ID:M/fXRR5a
>>939
それなら UML の状態遷移図は含まれるよな。

941 :KAC:2014/05/04(日) 14:52:35.79 ID:nXeCksGu
>>938
普通にプログラミング言語といえば、プログラムを記述できる言語の事だろ。
だから、記述したものをコンパイラやインタプリタ使って実行できればいい。

たとえばUMLで記述したシステムがコンパイルして動けるなら、
UMLもプログラミング言語とよんでもいいとは思うけど、
さすがにそれは無理じゃない?って事を>>934は言ってるんじゃないの?しらんけど。

942 :デフォルトの名無しさん:2014/05/04(日) 15:27:00.22 ID:M/fXRR5a
>>941
Rhapsody とか ZIPC も知らないってこと?

943 :デフォルトの名無しさん:2014/05/04(日) 17:06:25.72 ID:/8HFkyur
>>897,899
おそらくKACは
 C言語は関数でプログラムを構成するから関数型言語
なんだろ

KACのプログラミング知識なんて、そんなレベルだよ

944 :デフォルトの名無しさん:2014/05/04(日) 17:27:35.58 ID:ItV5J5ts
今日もKACの厨二理論が炸裂中

945 :デフォルトの名無しさん:2014/05/04(日) 19:35:43.35 ID:y/dXxXPg
>>936
プログラムの何かを記述したり定義する言語ではあるけれど汎用的な言語ではないかもね。
で?

946 :デフォルトの名無しさん:2014/05/04(日) 20:09:00.51 ID:syIl/0tX
>>943
そんな捻た読み方するのはお前だけw

947 :デフォルトの名無しさん:2014/05/04(日) 20:09:40.78 ID:syIl/0tX
>>942
ん?

948 :デフォルトの名無しさん:2014/05/04(日) 20:20:50.07 ID:/8HFkyur
>>946,947
KACさん、またコテを付け忘れてますよw

949 :デフォルトの名無しさん:2014/05/04(日) 20:21:35.02 ID:Wf2XX2VO
「グラフィカルな"言語"なんてないね!」
「? あるよ?(例示)」
「ちゃんとプログラムできる奴だよw」
「??できるよ?(なに言ってんだコイツ?)」
「(∩ ゚д゚)アーアーキコエナーイ」

「グラフィカルな"言語"なんてないね!」(再登場)
以下ループ

950 :KAC:2014/05/04(日) 21:25:36.39 ID:nXeCksGu
>>942
どうだろ。
その辺のツールを知らないか、
よく知ってて「細かいところまでやろうと思うと結局ソースにてが入る」事を経験してるかじゃない?

モデリングツールはプログラミングに対して万能じゃないよ。
ソースの流れの概要までは出してくれるけどそれ以上はつらい。
だからこそ、特殊なコメントまで埋め込んで編集後のソースからでも
モデリングツールに読み込めるようにしてるんだし。

951 :デフォルトの名無しさん:2014/05/04(日) 22:36:39.12 ID:y/dXxXPg
>>950
誰もグラフィカルが全てにおいて万能だなんて話はしてないと思うぞ。

952 :デフォルトの名無しさん:2014/05/04(日) 22:58:52.97 ID:/8HFkyur
>>941,950
あいかわらずKACは無知だなあ....

HTMLはマークアップ言語でUMLはモデリング言語だよ
プログラミング言語とは目的が異なる、ただそれだけのこと

モデリング言語と似たものに仕様記述言語がある
どちらも言語をそのまま実行したり(=インタプリタ)
コードを自動生成できる実装が存在する
でも、そうだからといってこれら言語をプログラミング言語とは呼ばない
なざなら、これら言語の目的は設計や仕様の検証が目的だから

953 :デフォルトの名無しさん:2014/05/04(日) 23:35:53.95 ID:DsKCbJTj
>>949
「グラフィカルな"言語"はあるよ!」
「開発効率は悪いよ。」
「 あるよ!」
「いやあっても開発効率は悪いって言ってるんだよ。1+1とか書いてみw」
「あるよ!!」
「だから開発しやすいかどうか話だよ?(なに言ってんだコイツ?)」
「グラフィカルにすると見やすい!」
「見るんだじゃなくて、書く時の話だよ。コードから変換することは否定してない。」
「(∩ ゚д゚)アーアーキコエナーイ」

「グラフィカルな"言語"あるよ!」(忘れたように登場)
以下ループ


こういう話だろ?
アーアーいってないで聞きなさい。
最初っからあっても効率が悪いって話だ。
見る時じゃなくて、書く時の話だ。
マウスでアイコンおいて線引くのかよ?
どうせまたあるなしの話にすり替えるんだろうなw

954 :デフォルトの名無しさん:2014/05/04(日) 23:37:53.40 ID:AIHO5oyw
programming languageの訳を、プログラミング言語としちゃったから、人類が使う自然言語とごっちゃにした間違いが起こる。
自然言語に、チューリング互換性なんか求めないだろ?
本来は「プログラミング"表記"」だから、図形でも良い。

955 :デフォルトの名無しさん:2014/05/04(日) 23:43:01.20 ID:y/dXxXPg
>>953
うんだからね?UE4のブループリント、皆コード書かないで済むよヒャッハー!って騒いでるんだけどその辺はどう説明するの?

956 :デフォルトの名無しさん:2014/05/04(日) 23:51:59.96 ID:DsKCbJTj
>>955
あー、あれはよくある勘違い。

あれで重要なのは「グラフィカルな言語」ではなくて
グラフィカルなモデリングツールだ。

モデリング、つまり3Dオブジェクトを作って
プレビューするといったものは、ツールで良い。

でもそれはプログラム言語部分ではない。
プログラム言語部分のみにフォーカスするとやっぱり作りづらい。
どっちみち、"文字"がかかれたアイコンを置いて、線でつなげて
そしてやっぱり、そのアイコンの置き場所で悩んで、どんどん
フローチャートのような図が大きくなって、複雑なことはできなくなる。

コード書かないで済むと言っているのは、たんにモデリングできるが
プログラムが出来ない人が、喜んでるだけ。
簡単な事しか出来んよ。プロは使わない。

957 :デフォルトの名無しさん:2014/05/04(日) 23:56:05.67 ID:DsKCbJTj
だいたい昔からコードを書かずにプログラムが作れる!って
いうものあるけど、どれも使えないものばかりだったんだよね。

たとえばFlash。最初は本当にコードがなかったのだけれど、
簡易なマクロがついて、結局最終的にはActionScriptという
JavaScriptのような言語がついてしまった。

コードなしでできないことはないけど、やっぱり限界があるんだよね。

HTMLでもビジュアルなHTMLエディタあってもプロはテキストで書くのは
望んだことが出来ないからなんだよ。素人にとっては簡単かもしれないけどさ。

958 :デフォルトの名無しさん:2014/05/05(月) 00:06:30.97 ID:/DynsGqU
>>952
ごめん。よくわかんない。
プログラミング言語とは排他なの?

959 :デフォルトの名無しさん:2014/05/05(月) 00:08:47.80 ID:fsdaxj0E
>>958
(文字の)プログラミング言語 と
たとえばGUIエディタは、組み合わせて使えるけど?
RADツールとか。

でもそんな話はしてないよね?
RADツールのプログラミング言語部分を
グラフィカルに書こう(見るのではなく)って
話がしたいんでしょ?

960 :デフォルトの名無しさん:2014/05/05(月) 00:09:26.93 ID:/DynsGqU
>>957
え、942で書いてるのも使えないの?

961 :デフォルトの名無しさん:2014/05/05(月) 00:11:58.74 ID:Bc7ofltv
>>959
952はそうじゃないポイ
排他だって意見にみえるんだけど

962 :デフォルトの名無しさん:2014/05/05(月) 00:14:18.10 ID:Bc7ofltv
952って取り敢えず反論した感がハンパ無いな

963 :デフォルトの名無しさん:2014/05/05(月) 00:16:32.67 ID:er9naDA4
>>956
やっぱりろくに知らないくせにうんちく垂れてるのか。
なんで完全にそれのみで完結しないとダメって思考になってるんだろうね。
汎用的な言語でもUI絡みはフォームエディタ使ったり一部マシン語なりc++で書いたりとかするんだけどそれと本質は何も変わらないんだが。
適材適所で向いてるところに向いてるものを使うだけ。
全てをグラフィカルでかけないからダメだとか言ってんのはお前ぐらいだよ。

964 :デフォルトの名無しさん:2014/05/05(月) 00:23:27.22 ID:fsdaxj0E
>>963
「全てをグラフィカルで書く」って誰が言ってるんだ?

現在、「文字で書いているプログラミング言語部分」を
グラフィカルで書くって話だろ?

そしてその答えは「存在するけど、開発効率悪い」だろ?

なんどもで出てる答えだよね?

965 :デフォルトの名無しさん:2014/05/05(月) 00:24:02.80 ID:fsdaxj0E
なお、フォームエディタは
プログラミング言語ではない。

966 :デフォルトの名無しさん:2014/05/05(月) 00:33:40.50 ID:diJrhHdz
>>958
目的別の分類だから「排他」だね
モデリングは設計でプログラミングは実装であって
抽象化のレベルが異なるから両立できないしすべきではないと思う
少なくとも両立した言語の存在を自分は知らない

あと、テキストやグラフィカルといった言語の表現とは「交差」できる
たとえばSDLと呼ばれる通信プロトコルの仕様記述言語では、
テキスト表現(SDL/PR)とグラフィカル表現(SDL/GR)が
ISO国際標準規格として定義されている

967 :デフォルトの名無しさん:2014/05/05(月) 00:34:26.26 ID:h1xpH1kA
GUIとかに専用のツールが有るのは
「作成画面」=「人間が見る最終的な出力結果」だからなんだよ。

モデリングツールもそう
「作成画面」=「人間が見る最終的な出力結果」

でもプログラミング言語部分は、たとえグラフィカルに書いたとしても
「作成画面」!=「人間が見る最終的な出力結果」
だから、ツールを使う必要性がない。

こういう所をわざわざ作成が面倒な
グラフィカルで作る理由がないんだよね。

968 :デフォルトの名無しさん:2014/05/05(月) 00:37:56.73 ID:er9naDA4
>>964
言語で書いてるもののうちグラフィカルで書いた方が適切なものがあるって話だろ。
それを++がーとか言ってるのはお前だけだよ。

969 :デフォルトの名無しさん:2014/05/05(月) 00:38:15.81 ID:er9naDA4
>>964
言語で書いてるもののうちグラフィカルで書いた方が適切なものがあるって話だろ。
それを++がーとか言ってるのはお前だけだよ。

970 :デフォルトの名無しさん:2014/05/05(月) 00:39:51.35 ID:er9naDA4
>>964
言語で書いてるもののうちグラフィカルで書いた方が適切なものがあるって話だろ。
それを++がーとか言ってるのはお前だけだよ。

971 :デフォルトの名無しさん:2014/05/05(月) 00:40:10.19 ID:er9naDA4
>>964
言語で書いてるもののうちグラフィカルで書いた方が適切なものがあるって話だろ。
それを++がーとか言ってるのはお前だけだよ。

972 :デフォルトの名無しさん:2014/05/05(月) 00:44:13.45 ID:er9naDA4
タイムアウト繰り返して複数回書き込みした。すまそ。

973 :デフォルトの名無しさん:2014/05/05(月) 00:45:51.33 ID:QeoO3ajw
GUIエディタは便利だけど、それはプログラミングじゃないよね
ソースコードが吐かれようがなんだろうがやってる事はデザインの作成でしか無い
プログラミング言語でデザインまでやってた所をデザインツールで出来るようになりましたって話で
グラフィカルにプログラミング出来るようになったわけじゃない

974 :デフォルトの名無しさん:2014/05/05(月) 01:14:36.50 ID:er9naDA4
>>967
目に見える物でしかツールが有効でないってのは何も根拠がないと思うけどね。
エクスプローラで操作するファイルは目に見えないけど大方の人は使ってるんじゃない?
そもそも言語にしても記号を操作してるだけ。どうして他の可能性がないとするのか理解に苦しむ。

975 :デフォルトの名無しさん:2014/05/05(月) 02:10:42.90 ID:vcPa62FD
グラフィカルな言語なんてない!
↓(修正)
グラフィカルだけじゃ言語にならない!
↓(修正)
グラフィカルじゃ効率悪い!1+1とか!


わかってることだけどバカだろコイツ

976 :デフォルトの名無しさん:2014/05/05(月) 04:48:10.29 ID:h1xpH1kA
>>975
何言ってるんだ? 最初から効率が悪いって話だろうが

最初の方のレスを見てみようか?

>>3
> じゃあ、1+1をグラフィカルに表現してみてくれ。
> そっちのほうがもっと嫌になるぞ。

できないといってない。(できるが)嫌になると言ってる。


>>11
> 教育用以外で汎用的なグラフィカルプログラミング言語が成功した事例は聞かないな。

事例はあるが、成功したものがないと言っている。

>>15
> コネクタ(線)だらけになるぞ
> 表示する際はマスキングして見やすくできるかもしれんが、
> プログラミングする際はコネクタ(線)を繋ぐ操作が面倒になる

面倒になると言っている。

977 :デフォルトの名無しさん:2014/05/05(月) 05:14:33.47 ID:vcPa62FD
うん、それぜんぶ論破されたよね。

で、毎回「(∩ ゚д゚)アーアーキコエナーイ!」ってやって
ほとぼり冷めたらぜんぶ聞こえなかったフリして
また一からおんなじこと言い出してただけだよね。

バカだから。

978 :デフォルトの名無しさん:2014/05/05(月) 05:54:54.50 ID:h1xpH1kA
>>977
論破ってなにそれ?

最初から「グラフィカルじゃ効率悪い」という話だよってことなんだが、
なにを論破したの?効率が悪く無いって話?

言ってることがおかしいよね。

俺が言ってるのは>>975が間違いだってこと。
つまり「グラフィカルな言語なんて無い」が最初ではなくて
グラフィカルじゃ効率悪い!という話が最初だって言ってるんだ。

少なくともこっちは論破できなかったね?

979 :デフォルトの名無しさん:2014/05/05(月) 08:26:52.40 ID:NiHw4eoO
>>950
> ソースの流れの概要までは出してくれるけどそれ以上はつらい。

お前ツール使ったことないだろ
ソースから概要とか出すんじゃなくて、UML 図とか状態遷移表を書いてそれからソースを出すんだぞ

980 :デフォルトの名無しさん:2014/05/05(月) 09:43:17.42 ID:er9naDA4
>>978
また++がかけないからとか言ってんの?
ブループリント、概ね好評みたいだけどそれはみない振りか。
ブループリントの開発効率が悪かったら最初から使われないと思うんだけどそこはどう説明するのかなー

981 :デフォルトの名無しさん:2014/05/05(月) 10:09:44.49 ID:8Z9tRs18
ブループリントと騒いでいる奴がいるだけで、
誰も使ってないとかなw

982 :デフォルトの名無しさん:2014/05/05(月) 10:10:39.17 ID:oKQjmaE2
ブループリントが使われてないのがすべてを語ってないか?
使いにくいものは使われない。
あれ誰が喜んでるんだろ?w

983 :デフォルトの名無しさん:2014/05/05(月) 10:12:10.70 ID:OifrO0XJ
散々既出だけど、結局グラフィカルな部分を作るのには
グラフィカルツールでいけど、
そういうのってプログラム言語じゃないんだよね。

プログラム言語をグラフィカルに作る?
何のメリットが有るの?

984 :デフォルトの名無しさん:2014/05/05(月) 10:13:16.32 ID:0tLYXgLs
結局プログラムが書けない無能が
俺にもできることがある!って
ツールの力で俺は一人前になるって
叫ぶだけの話だったよなw

985 :デフォルトの名無しさん:2014/05/05(月) 10:14:34.33 ID:7JcvWRkH
>>979
ツールから生成するって、それ関数定義だけだし。
ヘッダファイル程度が関の山
その後のコードがプログラム言語が必要とされる部分だよ。

986 :デフォルトの名無しさん:2014/05/05(月) 10:16:09.28 ID:wP+kEzIq
1+1をグラフィカルに書けが決定打だったな。

実際に書いてみたら、1をマウスでもってきて〜
プラスをマウスで持ってきて〜
1をマウスで持ってきて〜

ほら、絵がかけました。
だもんな、

たった1+1に一体どれだけ時間かけてるんだよとw

987 :デフォルトの名無しさん:2014/05/05(月) 10:16:44.15 ID:wP+kEzIq
>>980
> ブループリントの開発効率が悪かったら最初から使われないと思うんだけどそこはどう説明するのかなー

使ってませんよw

2ちゃんねるにスレありますか?

988 :デフォルトの名無しさん:2014/05/05(月) 10:17:28.87 ID:wP+kEzIq
グラフィカルなものを作るなら
グラフィカルツールでいいけど、

処理の内容はグラフィカル化できないんだから
そこはテキストで書けばいいだろ。

適材適所だよ。

プログラムは、プログラム言語で書け。

989 :デフォルトの名無しさん:2014/05/05(月) 10:18:57.45 ID:wP+kEzIq
プロはWordじゃなくて、テキストを使う。

HTMLでさえ面倒でMarkdownを使う。

グラフを書くならGraphvizやdot言語などを使う

それがプロの世界なのに・・・

990 :デフォルトの名無しさん:2014/05/05(月) 10:21:53.24 ID:wP+kEzIq
プロがグラフィカル言語を求めてるならともかく、
素人がグラフィカル言語を求めてるって構図だからな。

グラフィカルな言語のセールスポイントが
コード書かなくてもできる!

って時点でダメじゃない?

コードでは生産性が悪い所を改善できるじゃないと。

生産性の改善ってのは、問題点を認識して
問題がある部分のみの改善だけど、
グラフィカルな言語ってのは、
あなた無能でしょ?これならわかるでしょ?
って暗に言ってるしね

991 :デフォルトの名無しさん:2014/05/05(月) 10:24:09.93 ID:tFZ+anNx
"教育用の"グラフィカルな言語の存在が
グラフィカルな言語が必要とする人が誰かって
言ってるようなもんじゃないの?

992 :デフォルトの名無しさん:2014/05/05(月) 10:24:57.12 ID:tFZ+anNx
グラフィカルな言語が欲しい=今はグラフィカルな言語がない。

なんでだと思う?

993 :デフォルトの名無しさん:2014/05/05(月) 10:25:58.41 ID:tFZ+anNx
グラフィカルな言語な言語がないわけじゃないよ。
ろくな言語がないだけ。

作れないんじゃない。

必要とされないから作らない。
作っても逆効果だから作らない。

994 :デフォルトの名無しさん:2014/05/05(月) 10:27:36.25 ID:tFZ+anNx
昔は実行可能な設計図を作ろうって話もあったみたいだけど
頓挫してしまったみたいね。

995 :デフォルトの名無しさん:2014/05/05(月) 10:29:06.60 ID:dxultKAH
グラフィカルな言語はいらない。
あっても効率が悪いだけ。
教育用ならいいんじゃない?
コード書けない人は喜ぶだろうよ
ってのがプログラマの総意かな。

996 :デフォルトの名無しさん:2014/05/05(月) 10:30:45.41 ID:KBFSeQTd
グラフィカルな言語で効率が良くなったことを
示す証拠ぐらいだしてほしいもんだが。
まあ、ないものは無理か。

あーグラフィカルなツールは
グラフィカルな言語ではないですよw

997 :デフォルトの名無しさん:2014/05/05(月) 10:31:31.73 ID:6SOgkiHN
素人が、自分の技術不足であることを
認めたくないスレw

998 :デフォルトの名無しさん:2014/05/05(月) 10:32:54.88 ID:3OAh4o8h
プログラム経験のないSEが
まともな設計ができないように、

文字でプログラム経験がないやつが
ツールの力を借りたって、ろくなコードは書けないよ。

無から有を作り出すツールではなくて、
面倒くさいものを取り除くツールだから
できないことは、どんなツールを使っても出来ない。

999 :デフォルトの名無しさん:2014/05/05(月) 10:33:57.19 ID:WB2pXc1Y
グラフィカルな言語で生産性が上がるとは思えんが?

1000 :デフォルトの名無しさん:2014/05/05(月) 10:34:49.23 ID:nZonQTuf
結局、使えないツールを欲しがるのは
使えない人間ってだけさ。
道具に使われてる。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

262 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)