05/12/20 01:30:21
>>941
VisualAge for JavaってのがIBMから出ててな、結構やすいからまだ手に入るなら試してみな。
そうすりゃどのくらい便利でどっからあたりでマンドクサイかよ～くわかるから。
944:デフォルトの名無しさん
05/12/20 01:57:01
graphical だと patch 作るの面倒そう。
945:デフォルトの名無しさん
05/12/20 02:08:54
>>944
そうでもないよ
画面からテキストへの写像でしかないから
UNIXから来た人は想像できなくて誤解も多いだろうけど
946:デフォルトの名無しさん
05/12/20 02:28:49
ん、一旦テキストに落とすの?
947:デフォルトの名無しさん
05/12/20 02:57:44
LispやSmalltalk界隈では普通に行われてるけど
他の言語では一般的にマーシャリングとかシリアライズと言われている機能かな
データ記述能力の低い言語ではXMLとかの別の構造に記録したりする
948:デフォルトの名無しさん
05/12/20 03:16:07
>>943
シンセのエミュで、フィルタとかを結線するのは見たことがある
949:デフォルトの名無しさん
05/12/20 03:18:14
SchemeやHaskellの話を聞いたときには、「そのうちプログラムも関数になって
参照透明に設計して、引数と返り値のやりとりだけで作るようになるんだろうなぁ」とか
思ったんですが、
なんでCの拡張のC++とか、Cの改良のJavaとかそっちへ行ってしまったのだろうか。
手続き型の呪い？
と同種の悩みなんだろうか。
950:デフォルトの名無しさん
05/12/20 06:38:49
開発が進むごとに関数が増え続ける言語では、
関数の数が多すぎて、管理しきれなくなるからだろ。
関数の使用目的や機能等で特定の関数が使用可能な領域を縛ったりすれば、
もしかしたら可能だったかもしれんが・・・
951:デフォルトの名無しさん
05/12/20 06:47:00
> 開発が進むごとに関数が増え続ける言語では
増えない言語ってあるの？
952:デフォルトの名無しさん
05/12/20 07:04:54
>>951
現在、検案中。
特定の関数の使用できる条件を、経由した関数名や
オブジェクト等で限定できるようにすれば、
関数の個数を減らす事は可能かな？とか考えてる所。
953:デフォルトの名無しさん
05/12/20 07:46:32
要するに、心当たりは無いが、将来的には存在するかもしれないって事か。
954:デフォルトの名無しさん
05/12/20 08:00:51
Cは開発が進むごとに関数が増え続ける言語だが
(Common Lispのパッケージのような名前空間すらない)、
結構大きなシステムが書かれてるよな。
>>950のいう「管理しきれなくなる」というのは
どれくらいの規模のソフトウェアなのかまず明らかにしろ。
955:デフォルトの名無しさん
05/12/20 08:30:42
しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
だからCの後継言語に名前空間が存在するわけで。
956:デフォルトの名無しさん
05/12/20 08:38:35
>>955
> しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
下調べもせずにこんな適当な思い込みで開発するのはいかがなものか
957:デフォルトの名無しさん
05/12/20 08:43:31
というか、949に対する答えとしては、950はおかしいぞ。
HakellやSchemeが「開発が進むごとに関数が増え続ける言語」で
C++やJavaが「開発が進むごとに関数が増え続けない言語」なのか？
958:デフォルトの名無しさん
05/12/20 08:57:04
C++やJavaは、関数が増え続けないように歯止めをかける事が可能な言語かと。ｗ
まあ、その機能を有効活用している例は少ないようだが。ｗｗ
959:デフォルトの名無しさん
05/12/20 10:42:50
ヘッダ＆変なプレフィクスが名前空間＆クラスになったと。
本質はあまり変わってないが言語機能でサポートされたから多少は楽に。
960:デフォルトの名無しさん
05/12/20 12:39:44
関数の数なんてソフトウェアの複雑性ではマイナーな問題だろう。
たかが関数が増えることよりも、クラスを一個定義するだけで
ポインタやらconstなポインタやら参照やらconstな参照やら
もちろんあと値渡しも、そしてconstなメンバ関数やらconstでない
それやら、関数ポインタやらメンバ関数ポインタやら……を考えないと
いけないC++の方がはるかに大変だ。
テンプレート使ってると特に。
961:デフォルトの名無しさん
05/12/20 12:40:37
えーと。
大概のLispやSchemeのような古い関数型言語には名前空間ないけど、
MLやHaskellなどちょっと新しい関数型言語には名前空間あるよ。
というつっこみを誰もしないのはなぜですか？
962:デフォルトの名無しさん
05/12/20 13:29:03
MLが新しいって?
963:デフォルトの名無しさん
05/12/20 13:44:57
すまん、全てのMLが新しいみたいに言っちゃったな。
といっても正直、古いLispや古いMLはろくに知らないんで、
少なくとも今生き残っているLisp、MLについては、ってことにしてくれ。
さらに自分で言っといてなんだけど、Schemeって名前空間ないんだよね？
オブジェクト指向っぽいメッセージパッシングなどを
エンコードする形で自力で書け、ってことなのかな。
964:デフォルトの名無しさん
05/12/20 15:45:28
LispやSchemeに名前空間がないつっても、Cと違って局所関数やクロージャ、
プロパティリストなどがあるからいくらでも階層構造に出来るしなあ。
その上大抵はベンダーがオブジェクト指向やモジュール機能
提供してるのがデフォだし。
つうか、オブジェクト指向機能を一番最初に搭載したのってLispでしょ？
965:デフォルトの名無しさん
05/12/20 16:04:57
オブジェクト指向とかそのへんはまた荒れるんで、とりあえず
関数型言語は関数が増えるから使い物にならない
か否か、だけにしとこうよ。
966:デフォルトの名無しさん
05/12/20 16:10:40
>>965
だからそのことについてだよ。
ようは、C++やJavaにクラス階層の名前空間があるから、
関数が増えても整理できるっていいたいんだろ？
だったら、Lispで出来るし、むしろLispが最初だってこと。
967:デフォルトの名無しさん
05/12/20 16:14:58
「大概のLisp」って何時のLispを指してるんだ?
Common Lispにはパッケージがあるぞ。
Schemeは処理系依存だが、次の規格で何か入るらしい。
968:デフォルトの名無しさん
05/12/20 16:16:16
>>967
CommonLispに加えて、Schemeも入れてたから。
969:デフォルトの名無しさん
05/12/20 16:18:05
つまり、関数が増えるからどうのというのはｍとんでもない勘違いでFA。
970:デフォルトの名無しさん
05/12/20 16:21:11
emacs-lispのイメージがあるんじゃないの？
あれ、なんらかの階層構造の機能を使って、増えた関数を整理するとかして
ないでしょ。
名前のつけ方を長くして階層的にしてるだけで。
971:デフォルトの名無しさん
05/12/20 16:24:30
あれはモード切り替えるから大丈夫なんじゃないか？
カレントディレクトリみたいなもんでしょ。
972:デフォルトの名無しさん
05/12/20 16:34:33
>>969
Common Lispには名前空間（パッケージ）やクラスがあるし、
Schemeにも処理系依存でそれらが存在する。
HaskellやMLにはもちろんあるでFA。
973:デフォルトの名無しさん
05/12/20 17:36:18
>>954
C言語はコンパイル単位というか、ファイルスコープやリンカが別になってて
元々環境が地続きではないから、そんなに困らなかったんじゃないかと。
干渉して困るのはプリプロセッサのマクロ定義をヘッダに置いた時とか。
974:デフォルトの名無しさん
05/12/20 18:59:09
Cは同じ名前の関数があったとしても型定義に違いがあれば誤用をある程度回避できるしな。
C++は多重定義を認めてるからそうはいかないけど。
それを考えると名前空間の採用はC++にとって必然だったんじゃないかね。
975:デフォルトの名無しさん
05/12/20 19:04:45
ス質急低
976:デフォルトの名無しさん
05/12/20 19:18:19
一気に下がったな。氷点下。
977:デフォルトの名無しさん
05/12/20 19:26:23
>>975-976
>>775
978:デフォルトの名無しさん
05/12/20 19:30:29
それより、質の高い話ってなんだろう・・・
979:デフォルトの名無しさん
05/12/20 19:32:45
ポインタの話から移ったと思えばむしろ質は向上しているよ
ついでにスレも物理的に上昇しておこうか
980:デフォルトの名無しさん
05/12/20 20:36:57
関数の数を減らせれば、CAD方式でも何とかなるのでは？
という話になると思ってたのは漏れだけか？
CAD方式の話は見事に忘れ去られているようだが。
981:デフォルトの名無しさん
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
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。