05/12/20 20:42:01
950があまりにもとんちかんすぎただけだな。
982:デフォルトの名無しさん
05/12/20 20:51:26
スレタイからずいぶん距離のある議論になっているな
983:デフォルトの名無しさん
05/12/20 21:06:52
CAD方式のスクリプト、もしくは言語って、何がある？
984:デフォルトの名無しさん
05/12/20 21:07:44
CAD方式は機能が限定されているような狭い言語でないと、うまく行かないと
分かって来たからな。なので最近は（一部の研究を除いて）全く利用されていない。
985:デフォルトの名無しさん
05/12/20 21:17:47
LabViewがそうだったな。
漏れは使ったことないが、特定分野では成功してるみたいだよ。
URLﾘﾝｸ(www.asahi-net.or.jp)
986:デフォルトの名無しさん
05/12/20 21:19:02
>>984
それって言い換えるなら、機能限定をうまく設定できればうまくいく、という事では？
ネームスペース以上に関数や変数等の摘要範囲を限定するような機能を設定できれば、
何とかなるのでは？
987:デフォルトの名無しさん
05/12/20 21:43:14
>>985
ほとんど電子回路だな。
漏れ的にはUMLのシーケンス図みたいなのを期待してたんだが……
CAD形式みたいなのは「作る人にとって」分かりやすい方式になりがちなのかな？
988:デフォルトの名無しさん
05/12/20 21:43:33
「コンパイラ・スクリプトエンジン」相談室9
ｽﾚﾘﾝｸ(tech板)
989:デフォルトの名無しさん
05/12/21 07:04:47
CAD方式は言語というよりもツールになのでは？とか思ったが、
GUI形式の言語という見方をするならば、たしかに言語かもしれんな。
990:デフォルトの名無しさん
05/12/21 08:03:14
複雑になっていくと、他の人や昔の自分が描いたソースを読めなくなりそうだ。
建築設計図ですら欠陥が見抜けないのに、ソフトウェアになったら…
991:デフォルトの名無しさん
05/12/21 08:52:00
いや、それはちゃんとコンポーネントを設計して、
ちゃんとコメントを残していけばいい話だろう。
テキスト形式の言語だって最初から完璧だったわけじゃない。
初期の言語で幾多の失敗を重ねたおかげで今の言語があるわけだ。
要はCAD方式言語は研究も経験も蓄積がなさすぎるだけ。
あと、俺らがすでにテキスト方式に慣れすぎてるというのもあると思う。
問題は、テキスト方式の蓄積を捨ててまで
CAD方式に乗り換えるメリットがあるかどうかだが…。
992:デフォルトの名無しさん
05/12/21 09:11:39
CAD形式を扱う場合のメリットは、UMLを扱う場合のメリットと同じかと。
図形にすると、処理の流れは分かりやすくなる。
しかし図形には、処理の論理が分かりにくいというデメリットもある。
993:デフォルトの名無しさん
05/12/21 09:39:02
UMLはUMLで、オブジェクト指向に関する政治的な駆け引きが色々と絡んで、
ややこしくなってる部分があるからなぁ……
その意味では、CAD形式言語に関しては、図形をいかに定義するかが焦点になりそうだな。
994:デフォルトの名無しさん
05/12/21 09:54:58
その場しのぎのやっつけ仕事の場合だと、
むしろCAD形式の方が楽かもしれんな。
世間の仕事の９割ぐらいは、やっつけ仕事だろ？
995:デフォルトの名無しさん
05/12/21 10:35:34
UMLはCAD形式の言語？
996:デフォルトの名無しさん
05/12/21 10:46:20
フローチャートもCAD方式の言語という事になるな
997:デフォルトの名無しさん
05/12/21 11:19:07
CAD型まではいかんが、MAX/MSPやPDは非テキスト型プログラミングの
試みとしては一番成功している部類だろう。
998:デフォルトの名無しさん
05/12/21 12:01:15
ﾏﾃﾏﾃ、CAD方式には致命的な欠点があるぞ。簡単にはコピペができんだろ。
特定のツールでしか作れないから、拡張も難しい。
999:デフォルトの名無しさん
05/12/21 12:47:21
むしろテキストを図形表示する方が色々と楽かもな。
1000:デフォルトの名無しさん
05/12/21 13:13:35
普通に１０００ゲット
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。