- 1 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 19:45:18 ]
- プログラミング言語処理系の開発に興味のある人達のスレッドです。
字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。
前スレ
1 pc.2ch.net/tech/kako/981/981672957.html
2 pc2.2ch.net/test/read.cgi/tech/1021136715/
3 pc5.2ch.net/test/read.cgi/tech/1070089173/
4 pc5.2ch.net/test/read.cgi/tech/1100097050/
5 pc8.2ch.net/test/read.cgi/tech/1106129164/
6 pc8.2ch.net/test/read.cgi/tech/1115335709/
7 pc8.2ch.net/test/read.cgi/tech/1129287390/
関連リンクは多分 >>2-10 あたり
- 784 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:21:25 ]
- また、言語は設計当時の技術水準を前提にして設計されているし、
当時重要であった課題を優先して解決するように設計されている。
FORTRANの例で言えば：
FORTRANの行指向な言語設計は行単位に1枚のカードが使われていた
ハードウェア技術に大きな影響を受けている。
構文解析が案外面倒な面倒な算術式のパース技術が取り入れられた背景としては
当時算術演算を手軽に記述できる言語が他になく正にそれが求められていたからだ。
その一方で計算機のメモリやディスクの容量が限られていたこともあって
プログラム規模が当時は現代より比較的小さかったので
ユーザ定義のデータ型への需要は相対的に小さかったためそういう機能は貧弱だ。
LISPの例で言えば：
何よりAI研究で必要な柔軟なデータ形式である
リンクリストやそれを利用したツリーを簡単に操作できることが優先目標だったから
それが充実している一方で、算術式はお世辞に読みやすいとは言えないし、
効率のよいランダムアクセス可能な配列といった機能はなかった。
（近年LISPを語る際によく言及される、
メタな機構が充実したのはちょっと後のことで誕生当時の古LISPでのことではなかった筈だ。
言語のメタな構造がLISPが解く意図するツリー構造と相性がよかったこと、
元々の適用分野がAI研究だったことなどが影響しているのだろう。）
- 785 名前：訂正 mailto:sage [2005/12/14(水) 15:24:35 ]
- 解く意図する→得意とする
- 786 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:25:54 ]
- ここは公開オナニー劇場ですか
- 787 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:26:55 ]
- 宗教戦争なんてしてたっけ。
- 788 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:27:18 ]
- >>782
日記など書く趣味はないよ。
言語戦争の発端のグチを>>654-の記事の一部にポロっと書いた責任を取って
正攻法で技術論に戻して収拾しようとしてるだけ。
- 789 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:33:02 ]
- ｳｻﾞｽ
２、３行で要約しろよ
- 790 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:36:33 ]
- 冗長でも誤りを見つけやすくするため云々は一理あるけど、
冗長に書かないといけないせいで入るバグもあるから
トレードオフであることは意識しないとね。
「把握しやすい」ってのも、
その感覚はユーザによってばらつきがとても大きい。
これを意識しないで話すと宗教戦争になる。
- 791 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 15:41:37 ]
- >>787
顛末は例によってRubyが貶されて信者が暴れただけ。
- 792 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:10:36 ]
- >>783-784
知識の垂れ流し、結構なことです。
が、ここはお前の落書き帳じゃねーんですよ。
各言語の歴史的経緯についてなんかは言語仕様書の冒頭にでも
書いてありそうなことだし、こんな所で長々と解説されても信憑性も
疑わしいわでだんだん話が薄っぺらくなっていくだけですよ。
こちらとしては、そんなものより要点だけ数行でまとめて書いてくれると
読みやすいわ疲れないわでとてもありがたいわけですよ。
- 793 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:12:53 ]
- ｳｻﾞｽ
２、３行で要約しろよ
- 794 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:14:04 ]
- >>793
一行で要約できますた。
「ここはお前の落書き帳じゃねーんですよ。 」
- 795 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:25:20 ]
- つまり過剰な冗長さは悪し、という例ですな。
- 796 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:29:39 ]
- 長くなると（読解力が不足がち人には）ウザイってのはそうだろうけど
（なら読み飛ばせば？とも思うのではあるけども
読み飛ばしてもくれずわざわざウザイと書いてしまう
不思議な心理があるようですね。）
信憑性が薄くなるってのはよくわからないな。信憑性は内容の問題でしょ?
読解しきれないと内容が理解できないからそういう読み手にとっては
信憑性が薄く「感じられる」というなら納得。
ちなみに要約、要約と言ってるけど
要約というのも情報処理だから当然情報量が減るわけですが、
そこはわかってますか？
要約された梗概ばっか読んでたら
そりゃ目は楽だろうけども身のある話はできませんぜ？
要約なんてのは言わば骨格標本みたいなもので肉はないんだから。
それにこの程度のことで知識の垂れ流しと言われるのも心外。
議論のためのほんのとっかかりのつもりだし、
ちょっと年寄りの言語屋なら別に知るともなしに知ってるような話であって
自慢するほどの知識じゃない。
…と>>792を見た瞬間に思ったけども、>>794にある要約が>>792の真意なら
あまり意味はない単なる煽りなわけで無視したほうがいいのかな？
- 797 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:32:08 ]
- >>795みたいな茶々いれの冗長性はどんなもんすかね？
- 798 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:37:55 ]
- >>796
一行で要約できますた。
「無視したほうがいいのかな？」
- 799 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:42:58 ]
- 梗概が読めなかった。「こうがい」って読むのか。
- 800 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:53:40 ]
- >>796
>自慢するほどの知識じゃない。
そう。
あなたの知識の垂れ流しは、言わばほとんど無駄な情報＝ノイズなわけですよ。
あなたの言う骨と肉で例えると、見るに耐えないブヨブヨです。
すなわち骨が入ってるのかどうかさえ確認するのは困難です。
それをいちいち探りながら読んでいると時間も掛かり頭痛も絶えないわけでして、
長文をお書きならもうちょっと読ます文章を心掛けて書いて頂けませんか？
ということですが、お分かりになられませんかね。
- 801 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:00:51 ]
- よし、１０行縛りにしようぜ
- 802 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:08:25 ]
- >>797
丸ごと読み飛ばされる冗長性に比べると、一行コメントぐらいの冗長性ですな。
- 803 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:15:34 ]
- 3人の旅人がおりました。
ホテルを見つけて、そのホテルのオーナーに宿泊料金をたずねると、オーナーは「3人部屋で30ドルです」と答えました。
そこで、旅人はひとり10ドルずつ払って、そのホテルに泊まることにしました。
しばらくして、オーナーは3人の旅人の泊まっている部屋の料金は、本当は25ドルだったということに気付きました。
そこで、ボーイを呼んで「あの3人の旅人に、この5ドルを返してきておくれ」と頼みました。
ボーイは、3人に5ドルを返しても割り切れないと思い、自分のポケットに2ドルしまい込み、残りの3ドルを、３人の旅人に1ドルずつ返しました。
3人の旅人は、ボーイから1ドルずつ返してもらったので、9ドルずつ払ったことになり、9ドル×3人で27ドルです。ボーイのポケットの中の2ドルを足すと、29ドル。
さて、残りの1ドルはどこへいったのでしょうか？
- 804 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:33:35 ]
- ＞9ドルずつ払ったことになり、9ドル×3人で27ドルです。
問題が間違ってますよ。30-5+3で3人で28ドルですが。
端数切捨てですか？
- 805 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:37:43 ]
- いや3人が払ったのは27ドルでしょ。27-2=25ドルがオーナーの受け取った金で。
と、おいらも釣られてみましたよ。
- 806 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:38:31 ]
- >>784
いや、一番最初のLISPの目標は計算モデルを記述すること(チューリングマシンの代替)だろ。
それはまた、自分自身の処理系を簡潔に記述できる構造であることを意味する。
だからメタな機構はLISPの根本だと思うよ。メタサーキュラーな処理系があれば
それを種にして何でも出来るんだから。マクロやMOPは使い勝手の上で
追加されたおまけみたいなもん。
- 807 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:40:19 ]
- >>781
このスレ6から読み始めたので、2〜5のdatどれかしら持ってたらうｐしてもらえませんか？
- 808 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:43:32 ]
- 論争 Rubyで大規模プロジェクト 採用企業４割拡張ライブラリ使わず
www.toyama.hokkoku.co.jp/_today/T20051210002.htm
あるチーフプログラマーは「日本人なら、Ruby。大規模プロジェクトでも拡張ライブラリは必要ない」と言い切り、
今後も拡張ライブラリとの併用はしない考えだ。
- 809 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:46:47 ]
- 掲示板は書き手同士のコラボレーションで成り立ってるから、
そういうTPOとか特性を考えた上て書けってことだろ
そろそろこのスレの趣旨の話に戻せよ
- 810 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:53:38 ]
- >>808
この業界では技術に保守的なだけでもクズだというのに、
ついにナショナリストまで登場しているのか（笑）
- 811 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:59:31 ]
- >>808
ネタのつもりなんだろうけど、そういうまるっきりウソ流し続けてると
コミュニティ過激派から訴えられるかも知れんぞ
- 812 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 18:01:50 ]
- おれは2が欲しい
- 813 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 18:14:18 ]
- おれはお前が欲しい
- 814 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 19:13:58 ]
- >>803
真相をお話します。
オーナーはご想像の通り、物忘れが酷い人物ですが慈悲深く、
ボーイもまた欲深いという欠点を持つ人物ですが、それでも
ボーイはオーナーの人格を信頼して付き従っておりました。
さて、実はこのホテルのシステムは後払い方式なのですが、
オーナーの物言いにボーイは素直に頷き、オーナーから
預かった５ドルを欲深さからそのまま着服しました。
翌日オーナーは例外なくそのことを忘れており、
チェックアウトした旅人へ謝罪し２５ドルを受け取りました。
結局その時ホテルで５ドルの損失が発生したのですが、
オーナーはそれに気づかず運営を続け、やがて倒産してしまいました。
しかしその後ボーイは着服で貯めた金で大成し、
路頭に迷った元オーナーを雇ってあげたという話です。
経営者としてはボーイの方が格上だった、が正解です。
- 815 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 19:42:02 ]
- ﾋｿ(´д)(д｀)ﾋｿ
- 816 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 22:26:28 ]
- 3人の言語オタがおりました。
このスレを見つけて、そこの住人に最高と思う言語をたずねると、
「RubyとLisp以外です」と答えました。
- 817 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 22:28:14 ]
- eagerな言語は使う気がしない
- 818 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 22:42:51 ]
- クロージャまわりのメモリ管理ってどうやってます？
・基本はスタック上で、捕捉されたらヒープにコピー
・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
・めんどいので全部ヒープに取ってGCまかせ
・その他
と、ネタ投下してみる。
- 819 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 23:13:26 ]
- >>807
makimo.to/cgi-bin/search/search.cgi?q=%83R%83%93%83p%83C%83%89%81%40%83X%83N%83%8A%83v%83g&andor=AND&sf=0&H=&view=table&D=tech&shw=2000
- 820 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 23:57:16 ]
- >>818
全部ヒープでやってる。速度は今のところ考えてない。
いずれはスタック使いたいんだけどね。
とりあえず論文読み中。
www.cs.indiana.edu/~dyb/pubs/3imp.pdf
- 821 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 01:12:12 ]
- >>818
>・基本はスタック上で、捕捉されたらヒープにコピー
捕捉されたらとは？生成のこと？
>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
クロージャの生成構文を別々に設けるということ？
これらの意味は？
おれの見解ではクロージャを使うだけであればスタック、
クロージャを生成する際、親フレーム以下があれば
ヒープに落としてフレーム参照を繋ぎかえる、
この時既にヒープに落ちていれば何もしない、
という戦略がスマートというか、一般的じゃないかと。
使用回数＞生成回数という場合ね。
CPSやジェネレータみたいな使い方しかしない場合は
コピーが連続して不利になるけど、こんなことは
やろうと思わなければめったにない。
- 822 名前：807 mailto:sage [2005/12/15(木) 01:28:06 ]
- >>819
どもありがと。さいこー
- 823 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 02:53:00 ]
- >>818ではないですが面白そうな話題ですね。
>クロージャの生成構文を別々に設けるということ？
エスケープ解析とか？
>おれの見解では(略
すまん、理解不能。
といってもクロージャ変換で実装したことしかない俺の知識が足りないだけ。
興味あるので「一般的」の参照をくれるとうれしい。
- 824 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 04:31:04 ]
- >>803
○○○○○.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ 最初に支払ったお金３０ドル
↓
●●●◎◎.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ ３ドル返す ２ドルくすねる
└┼┘└┤└───────────┬─────────────┘
│ │ └ 主人の手元に２５ドル
│ └ ボーイの手元に２ドル
│
└ お客の手元に３ドル
支払ったお金は２７ドル
９×３＝２７ ９ドルずつを３人で払った
３０−３＝２７ ３０ドル払って３ドル返してもらった
２５＋２＝２７ 主人に２５ドル、ボーイに２ドル払った
ボーイがくすねたお金２ドルは、客が支払ったお金（２５＋２）の一部
だから支払った２７ドルにさらに２ドルを足すことが間違い（２５＋２＋２・・・×）
最初の金額３０ドルを求めるには、実際に支払ったお金２７ドルに 戻ったお金３ドルを足さなければならない
- 825 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 04:51:17 ]
- エスケープ解析というのを知らなかったのでぐぐってみたのですが、
関数等のスコープの中で定義した変数やクロージャの
利用がスコープの中だけで完結し、外には持ち出されないことを
調べるということでしょうか。
- 826 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 13:44:56 ]
- そうです。
- 827 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 17:01:53 ]
- >>783-784
おもしろい。長くてもいいからやってくれ。
くだらん短い書き込みより、長くてもおもしろいほうがいいや。
長いのがいやなら読まなきゃいいだけ。
>JavaはCが存在していて必要ならば使うことができることが前提だから
>比較的汎用指向の言語でありながら
>Cで書くことが適切であるようなハードウェアレベルの記述機能を
>潔くスッパリ切り捨てた設計ができている。
ここらへんはたぶん違ってて、Javaに低レベルの記述がないのは単にJavaがバイトコードインタプリタを採用したからであって、Cがあるから云々は関係ないと思う。
ポインタをなくしたのもGCを導入しやすくするためで、やっぱりCとは関係ない。
- 828 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 18:15:07 ]
- >>827
そのへんは、鶏が先か卵が先かみたいなもんじゃね？
>>780
>人の認知科学的な処理特性を無視することはできない。
認知科学的には、冗長だとミスが増える法則もあるので
トレードオフだよね。
>ユーザが把握しやすい動作モデルを提供する
同じ物でも「把握しやすさ」はユーザによって
ばらつきが大きいんだよね。
ここを意識しないと宗教戦争になる。
- 829 名前：デフォルトの名無しさん [2005/12/15(木) 21:03:36 ]
- >>827
ポインタはあるよ。
論文ばかり読んでる○○研究者か？
- 830 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 21:05:42 ]
- >818
継続も使いたいから
>めんどいので全部ヒープに取ってGCまかせ
かね……
- 831 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 21:35:49 ]
- >>823
>興味あるので「一般的」の参照をくれるとうれしい。
図にすると下みたいなイメージだけど、その辺は「クロージャ」が
出てくる速い処理系のソースかドキュメントでも読んでよ。
今の所これ以外に速い実装は思いつかないが。
※ |****| はフレームの変数とかの中身
※ (矢印)はフレームポインタ
スタック |******親1******|(←)|******親2******|(←)| ★クロージャ生成直前
ヒープ ヒープはまだ空の状態
↓ ヒープに落としてフレーム参照を繋ぎかえる
スタック | 親1 |(↓)| 親2 |(↓)| ★クロージャ生成完了
ヒープ |******親1******|(←)|******親2******|(←)|
エスケープ解析までするなら特定の親のみしかヒープのコピーは発生しない。
例えば親1のフレームしか参照しないのであれば親2のフレームは
そのままスタックに残しても良い。
スタック | 親1 |(↓)|*******親2*****|(←)| ★クロージャ生成完了
ヒープ |******親1******|(←)| ←─── 生成されたクロージャは直接親1を参照
- 832 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 22:12:03 ]
- >>829
参照のことをポインタだって言い張ってる人はいますね。
- 833 名前：デフォルトの名無しさん mailto:sage [2005/12/15(木) 22:43:17 ]
- Javaでポインタがあるっていう人間は低脳。バイトコードの仕様書読み直してから来い
- 834 名前：818 mailto:sage [2005/12/16(金) 01:44:55 ]
- >>821
>>・基本はスタック上で、捕捉されたらヒープにコピー
>捕捉されたらとは？生成のこと？
「生成されたクロージャが、
子孫のスタックフレームでないフレームに捕まえられたら。」かな。
例えばforeach的な関数にクロージャを渡してそのまま捨てるような状況なら
コピーは要らないわけです。
これをやると破壊的な処理がやたらと高くついたり、
いざコピーとなったときにやたらと高くついたり、
その他色々と面倒なことになったりしそうですが。
>>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
>クロージャの生成構文を別々に設けるということ？
コンパイル時に絶対にコピーが要らないとわかったときのみ、
フレームはスタック上に置いて、
それ以外は最初から親フレームはヒープに置いておこうと。
「関数aはクロージャを引数に取るが、それはどこにも保存されない」
ということになればa以外を呼ばない関数のフレームはスタック上に置いて良いでしょう。
が、やっぱり色々あって面倒なことになったりしそうです。
どっちもクロージャより親フレームが長生きなら問題ないよねという方針。
- 835 名前：デフォルトの名無しさん [2005/12/16(金) 18:53:57 ]
- Javaでポインタが無いと信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
- 836 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 19:38:44 ]
- 個人的な主観かもしれないけど、
ポインタ演算が無いものは参照と呼ばないか？
- 837 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:21:09 ]
- 例えば、Cのポインタをタンイポと呼ぶように2006年から改正したら、
2006年からポインタが無いことになるぞ。
ポインタだのタンイポだのと言われてることが全て。
- 838 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:41:20 ]
- ポインタをタンイポと呼ぶためには法改正が必要なわけだが、2006年からというのは早急すぎるな。
まずは有識者を集めた小委員会の設置を図った上で、再来年以降の国会提出でも十分だと思う。
- 839 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 20:44:35 ]
- 配列のイテレーターと参照と参照ポインタとメモリアドレスのポインタとを
一括してポインタと呼ぶべきでない。
- 840 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:04:11 ]
- >>835
Javaでポインタが有ると信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
- 841 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:05:31 ]
- え、ポインタと参照の違いは常識だと思ってたのですが。
またトンデモ本の誕生ですか。
- 842 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:01 ]
- >>840
ほんたまですか？
- 843 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:22 ]
- 塗るタンイポえくせぷしょん
- 844 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:06:32 ]
- 懐かしい名前を出さないでください。せっかく忘れていたのに。
- 845 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:07:45 ]
- Pascalのポインタは演算できないけどポインタと呼ぶな
だから正解は>>837
- 846 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:10:09 ]
- でも一般的に見たら、参照とポインタの一般像みたいなもんはあるだろ。
Pascalは例外じゃないか？
- 847 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:12:33 ]
- PascalはInc, Decができるじゃん。
- 848 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:12:34 ]
- たしかにポインタの演算はできないけど数値にキャストできるから同じ事では。
- 849 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:21:12 ]
- みんなそんなにボロカスに言うなよ。
Mさんが可哀想じゃないかｗ
- 850 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 21:22:33 ]
- まあ少なくともJavaの参照はポインタではないことは確かだ。
名前が参照だから。
- 851 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:35:58 ]
- そんなの実際どうとかじゃなくて、
設計者がどう定義したかと、その思想によるだろう。
だから>>850が正しい。
- 852 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:41:17 ]
- 名前はともかくとしても、実際の内容を素直に受け止めれば
いいと思うけど。なので >>835 が正解。
- 853 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:42:47 ]
- >>835とか>>852は、ポインタと読んでCのポインタを連想した上で書いてるわけっしょ？
だったらやはりCの言葉の定義に(ry
- 854 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:44:40 ]
- 実際の所、Rubyにはポインタは存在するがLispには存在しない。
- 855 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:46:11 ]
- >>853 ポインタという言葉の定義or使用はＣが最初ですか？
- 856 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:48:01 ]
- RubyもLispもPascalも、同じ太陽を感じ、同じ月を見て. 同じ空気を吸っているのだから
ポインタの有無くらいで区別するのはよくないと思います。
- 857 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:50:26 ]
- しかし、ポインタの有無は実用性を大きく左右するんだよ。
- 858 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:51:20 ]
- うむ。
- 859 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:52:51 ]
- 結局は宗教論争。
和平への道はアセンブラ原理主義しかない。
- 860 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:53:34 ]
- >>855
ALGOL60にPOINTERという型は既に存在したらしいぞ
ttp://www.99-bottles-of-beer.net/language-algol-60-24.html
- 861 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:55:01 ]
- Java ポインタ の検索結果 約 197,000 件中 1 - 10 件目 (0.03 秒)
www.google.co.jp/search?hl=ja&q=Java+%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF&lr=
Java 参照 の検索結果 約 2,830,000 件中 1 - 10 件目 (0.24 秒)
www.google.co.jp/search?hl=ja&q=Java+%E5%8F%82%E7%85%A7&lr=
この様にJavaポインタ派は、Java参照派と比較するとごく少数です。
どうやら集団で勘違いされているみたいです。
>>856
Rubyにはポインタはありません。
ポインタに相当する機能は持ってますが、
それはポインタではありません。
- 862 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 22:58:05 ]
- 実にくだらない話題に収束したな。
- 863 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:29:43 ]
- ポインタ演算とか、インクリメントとかデクリメントとか、数値へのキャストとかそういうのを
わざと制限したものは普通、ポインタじゃなくて参照って言わない？
- 864 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:33:18 ]
- >>857
同意。ポインタのある言語は領域破壊のバグが頻繁に紛れ込むが、
Javaのようにポインタのない言語はそうしたバグは非常に少なくなる。
- 865 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:33:48 ]
- いわないね。
Delphiだと明確に区別されてるし。
- 866 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:34:56 ]
- >>865
Delphiは言うじゃん。参照って。
- 867 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:37:26 ]
- つまり、865は「ポインタとは言わない」と言いたいちゃうんかと。
- 868 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:40:25 ]
- あぁ、863へのレスのつもりなのね。
- 869 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 23:52:19 ]
- >>857
つまりLispは実用的でない証明ってこと言いたいわけ？w
- 870 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:05:20 ]
- lispにポインタはありません。ポインタの無い言語は実用性で勝ります。864を参照。
- 871 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:10:12 ]
- Cにはポインタがあります。ポインタのある言語は自由度と汎用性で勝ります。864参照。
- 872 名前：デフォルトの名無しさん [2005/12/17(土) 00:10:39 ]
- Lispにポインタはあるが、そういえば、Lispのポインタって完全にJava、Rubyなどで言う参照だよな。
結局その言語でそれをなんと呼ぶかってことだな。
- 873 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:11:26 ]
- >>871
確かにバグを出す自由度で勝りますねｗ
- 874 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:19:31 ]
- ようやくLispが出てきたか
やっぱこのスレの主役はLispだよな！
- 875 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:20:01 ]
- Lispこそがすべての源流であるということは認めざるを得ない。
- 876 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:23:32 ]
- そもそも「Javaでポインタ」って話は、C++使いにJavaの参照を教えるときに「C++の参照と違ってポインタみたいなもんですよ」って説明するだけの話じゃなかったっけ？
それ以外の時に普通Javaの参照はポインタとは言わない罠。
まあ「何かを指し示す」って意味に限定すればJavaの参照とCのポインタは一緒だから「存在しない」とまでは言う気ないけど。
ポインタ演算ができるかどうかなんてポインタの本質じゃないでしょ。
- 877 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:25:38 ]
- >>876
一般に参照とポインタの区別を云々する場合、ポインタ演算の有無こそが本質のうちの1つです。
- 878 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:26:56 ]
- >>877
そうなの？ポインタキボンヌ。
- 879 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:27:45 ]
- ポインタ演算があるのと無いのとではバグの量と種類に大きな違いが出るのだよ。
- 880 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:29:26 ]
- Cのポインタは、演算によって「値をずらす」ことができるだろ。
int a;
int *p = a;
p += 1; //←これ
参照はそれができない。
- 881 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:30:15 ]
- それはポインタ演算の有無の話であってポインタの有無の話ではないですね
- 882 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:31:08 ]
- 間違った。
int a;
int *p = &a; //アドレスを代入
p += 1; //←これ
*p = 1; // 任意のアドレスのデータを破壊
参照はこれができない。
- 883 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:32:00 ]
- ポインタの有無の話ですよ。今や、それが出来ないものをポインタではなく参照とよぶことが多いんですから。
- 884 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:32:51 ]
- ポインタは任意のハードウェア例外を引き起こす。
*(int *)(0) = 0; // 不正なアドレスへの書込み
参照ではこれはできない。
- 885 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:33:23 ]
- これぐらいか？
●同じ点
Javaの参照もCのポインタも、どちらも間接参照を表すためのものである。
●異なる点
Javaの参照はヒープ上にあるオブジェクトしか指す事ができない。
Cのポインタはどこにあるオブジェクトも参照できる。
Javaで参照されているオブジェクトは決して消滅しない。
Cで指されているオブジェクトはいつの間にか消滅している可能性がある。
(そして、消滅したオブジェクトへの参照をたどった場合の動作は未定義である)
Javaの参照にはCのポインタ演算のような機能はない。
Cのポインタ演算は、配列の要素を指すポインタのみに使う事ができる。
それ以外の場合の動作は未定義である。
Javaの参照の動作はかなり厳密に定義されている。
Cのポインタに対する操作には「未定義である」という部分が多い。
それを利用して環境依存の色々な技が使えたりする。
- 886 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:34:20 ]
- Cのポインタが安全性を保証してないだけの話じゃん
- 887 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:35:50 ]
- クロージャの話しようぜ
- 888 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:37:11 ]
- >>887
まずクロージャを定義してださい。
- 889 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:38:20 ]
- ポインタは本来、「何かを指し示すもの」という意味でした。
この言葉は、アドレスやそれを格納した変数などにたいして用いられてきました。
しかし、時代が移り変わるにつれ、ポインタ演算によって、頻繁に深刻なバグが
発生することがわかってきました。ポインタ演算の有無が非常に重要だという
ことがわかってきたのです。
かくして、本来は本質でなかったポインタ演算の有無が、時代とともに重要視
され、ポインタの本来の意味が変わってきたわけです。
- 890 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:38:34 ]
- ださいとかいうなや
- 891 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 00:42:25 ]
- ポインタ演算を適用できる変数やアドレスの数値と、参照との区別を明確にするため、
前者のことを特にポインタと呼ぶようになったのです。
特に言語として、Cがダントツで有名になったこともこの背景にあります。
- 892 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:05:55 ]
- ・ポインタ演算を元に考えればJavaやその他の言語にポインタはない。
・そうでなければいわゆる参照（C++の参照を除く）はポインタみたいなもん。
ってことでFA？
- 893 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:12:47 ]
- 代入なんかをインスタンス化してしまう言語にはポインタがない、参照切れもない。
- 894 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:16:58 ]
- >>892
あと、
・その言語がポインタと呼んでいないものは、その言語ではポインタではない。
- 895 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:18:08 ]
- >>893
ポインタ演算ができないからでしょ。
>>894
そんなこと言ったらJavaScriptにはクロージャはないってことになるじゃん。
- 896 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:21:50 ]
- いろんな言語のポインタ、いろんな言語やハードのアドレスは、それぞれ別のものを
別々に定義可能。
それらの用語の使い方は仕様によって異なる。
時々これらを混同して、「アドレスはポインタか？」とかの議論で、おかしな議論を
展開しちゃってる人がいるけど。
- 897 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:23:05 ]
- >>895
クロージャを他の機能で代替してるだけなら、
厳密な意味ではクロージャはないんじゃないの？
- 898 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:25:39 ]
- ECMAScriptの仕様書のP144にクロージャ出てきますが何か？
- 899 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:25:40 ]
- 厳密な意味ならね。
- 900 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:26:56 ]
- >>896
禿同。
このスレは変な議論で盛り上がるよなｗ
- 901 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:26:57 ]
- その言語がそれをクロージャと呼んでいないなら、クロージャじゃない。
- 902 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:29:06 ]
- >>898訂正
×P144
○P132
- 903 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:32:05 ]
- ああ、Cのポインタは実装によってマシンのアドレスと違うことがあるから、
アドレスはポインタではないとかいっちゃってる人いますね。
Cのアドレスとマシンのアドレスを混同しちゃってる例ですかね。
- 904 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:46:37 ]
- 要はどっちでもいいだろって話でしょ。
Javaの言語仕様に関する議論で「ポインタは〜」とか言ってたら指摘すべきだが、>>876みたいな文脈で「ポインタみたいなもん」って言ってるだけでつっこむとしたら揚げ足取り以外の何物でもない。
- 905 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:51:38 ]
- ポインタをマシン語のアドレスと思ってあつかうと
マルチコア、マルチタスク、マルチキャッシュなＣＰＵでは
競合が発生して、かなりわけわからんことになる昨今。
- 906 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:53:11 ]
- >>888
では混乱を無くすために
クロージャ＝Schemeのクロージャ（あるいはラムダ式、無名関数）
と定義するよん。他の言語も右に倣えだから意味論はほとんど同じ。
例えばクロージャのある言語ではnewのような特別な構文を
定義することなくオブジェクトの生成を記述できる。
(define new-point
(lambda (x y) ;---メンバ変数に相当、隠蔽される
(lambda (message . args) ;---this、selfに相当
(case message
((getx) x) ;--- getter
((gety) y)
((setx) (set! x (car args)) x) ;--- setter
((sety) (set! y (car args)) y)
(else (error "unknown method " message))))))
実際にやっていることはクロージャを生成するクロージャを
定義しただけ。それでも以下の様にオブジェクトとして扱える。
(define point (new-point 1 2))
;メンバ変数はどうやってもアクセサ経由でしか参照できない
(point 'getx) ;=>1
(point 'gety) ;=>2
(point 'setx 3)
(point 'getx) ;=>3
- 907 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:58:41 ]
- 燃料投下
Javaでは、NullPointerExceptionっていう言語定義された例外が存在するんですがｗｗｗｗｗ
- 908 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 01:59:53 ]
- NullPointerExceptionを考えた馬鹿を吊るし上げればいいだけだお^^
- 909 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:01:45 ]
- >>906
なるほど
JavaScriptやlua、perlもそれと同じだね。
- 910 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:04:49 ]
- >>907
Javaにポインタがあるとか言ってる奴の主張はそれじゃなくて
参照のことだろ。
- 911 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:08:44 ]
- ttp://nantan.xrea.jp/tag/Java
「ポインタ(pointer)」と「参照(reference)」とは、同じようで微妙に異なる。
簡単にいうと、「参照」はデータを間接的に参照することで、「ポインタ」は
その実現方法。つまり「参照」は仕様であり、「ポインタ」は実装である。
よく「Javaにはポインタがない」「いや、Javaの参照変数はポインタ
そのものだから、Javaにもポインタがある」という論争があるけど、
前者は「Javaの言語仕様にはポインタがない」ことを後者は「Javaの
実装にはポインタが使われている」ことをそれぞれ言っている。
つまり話の焦点がずれているため、両者の議論はかみ合うはずがない。
ただまあ、「NullPointerException」という名前はよくなかったな
- 912 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:11:13 ]
- もし NullPointerException を改名するとしたら何にするのがよい？
- 913 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:12:26 ]
- NullpoException
- 914 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:14:25 ]
- CantDereferenceException
- 915 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:31:26 ]
- 燃料の質が悪かったか。精進します。
- 916 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 02:36:52 ]
- NullReferenceException
www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemnullreferenceexceptionclasstopic.asp
- 917 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 03:54:34 ]
- で、そのポインタ論争がこのスレと何の関係があるんですか
マ板のぬるぽスレでも行って騒いでなさい
- 918 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 03:56:44 ]
- ポインタについては、このスレで議論することですか？
- 919 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:44:46 ]
- このスレで議論することは何ですか？
- 920 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:49:30 ]
- 質(略)
- 921 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:50:09 ]
- 次スレの準備かな。
- 922 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:51:33 ]
- まだ早いよ
- 923 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 05:53:08 ]
- 元々クロージャの話だったからそれをギロンすればいい
- 924 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 06:00:54 ]
- じゃ、まずはおまいからギロンを始めてくれ。
- 925 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 10:10:43 ]
- ぎろーん
- 926 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 10:47:16 ]
- ポインタなどという用語を不用意に使うような糞言語は捨てですね
何も反省していないということがわかる
やっぱりLISPですね
- 927 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 11:01:35 ]
- 昔の言語だったらしょうがないけど、今時ポインタという用語使う言語の方が珍しい。
- 928 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 12:15:13 ]
- >>911
>「ポインタ」は実装である。
これの一次情報ってどこなんだろう？
少なくともCの仕様書ではそうなってない。
言語はC言語で実装することが多いので、
参照を表すのにポインタが直接使えるだの使えないだのという話はするけど。
- 929 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 13:02:20 ]
- ポインタはCでは仕様、Javaでは実装ってことじゃね？
- 930 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 18:08:17 ]
- >>926
Emacs Lispのリファレンスマニュアルだと、全編を通じて
「ポインタ」という用語を使っているわけだが w
www.fan.gr.jp/~ring/doc/elisp-manual/elisp_81.html#SEC82
- 931 名前：930 mailto:sage [2005/12/17(土) 18:14:58 ]
- ごめん、URLはこっちとかの方が適切だね。
www.fan.gr.jp/~ring/doc/elisp-manual/elisp_84.html#SEC85
- 932 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 19:30:44 ]
- まあｃより古い言語なんだし、その辺は仕方ないんじゃない？
lispのポインタは今でいう参照だな。
- 933 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 21:10:48 ]
- だから、lispはポインタ無いって何度いえば（ry
- 934 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 21:23:52 ]
- もういいよ、その話題は。
- 935 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 00:32:13 ]
- だから、rubyはポインタ（ry
- 936 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 00:52:22 ]
- さて、そろそろ次スレの準備かな。
立てたい奴、テンプレのリンク切れてるのチェックしてきてくれよ。
- 937 名前：デフォルトの名無しさん mailto:sage [2005/12/18(日) 07:04:06 ]
- 4年前の発掘
pc.2ch.net/tech/kako/1004/10048/1004873294.html
- 938 名前：デフォルトの名無しさん [2005/12/18(日) 23:03:22 ]
- コンパイラ作る人は、「デバッガ」を、どのくらい「親切モード」に
搭載しているんだろう。手取り足取りでは作る手間かかりすぎるし、素っ気
なさ過ぎると、それはそれで文句言う奴も出てくるはず。
- 939 名前：デフォルトの名無しさん [2005/12/19(月) 18:04:56 ]
- コンパイラヤサンは、でばっがやさんとは捌
- 940 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 22:11:29 ]
- 938が誰に何を聞きたいんだかさっぱりわからんのだが。
(VC++とかgccとかの)広く使われている処理系について、どのくらい親切な
デバッガが搭載されてるか、なんてことなら、938の使ってる処理系についてなら、
938自身がよく知ってることだろう。
そうじゃなくて、
「コンパイラを作るとき、デバッガをどの程度意識して作るものなのか。
コンパイラ屋さんはたいして意識せず、デバッガ屋さんががんばるものなのか、
それともコンパイラ作る段階で相当意識するものなのか。」
という疑問であるとか、
「なあみんな、処理系作るときどれくらいデバッガ意識してる?」
という問いかけであるのならわかるんだけど。
- 941 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 23:56:40 ]
- SmalltalkやObjectCの話を聞いたときには、「そのうちプログラムも部品化・汎用化されて
CADのように配置して、入出力を線で結んで作るようになるんだろうなぁ」とか
思ったんですが、
なんでエディタで変数名をマウスで触ると宣言が出てきたりとか、コード補完してくれるとか
そっちへ行ってしまったのだろうか。
キーボードの呪い？
- 942 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:08:13 ]
- >>941
CAD方式のほうがめんどくさいことがわかったからだ
- 943 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 01:30:21 ]
- >>941
VisualAge for JavaってのがIBMから出ててな、結構やすいからまだ手に入るなら試してみな。
そうすりゃどのくらい便利でどっからあたりでマンドクサイかよ〜くわかるから。
- 944 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 01:57:01 ]
- graphical だと patch 作るの面倒そう。
- 945 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:08:54 ]
- >>944
そうでもないよ
画面からテキストへの写像でしかないから
UNIXから来た人は想像できなくて誤解も多いだろうけど
- 946 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:28:49 ]
- ん、一旦テキストに落とすの?
- 947 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:57:44 ]
- LispやSmalltalk界隈では普通に行われてるけど
他の言語では一般的にマーシャリングとかシリアライズと言われている機能かな
データ記述能力の低い言語ではXMLとかの別の構造に記録したりする
- 948 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 03:16:07 ]
- >>943
シンセのエミュで、フィルタとかを結線するのは見たことがある
- 949 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 03:18:14 ]
- SchemeやHaskellの話を聞いたときには、「そのうちプログラムも関数になって
参照透明に設計して、引数と返り値のやりとりだけで作るようになるんだろうなぁ」とか
思ったんですが、
なんでCの拡張のC++とか、Cの改良のJavaとかそっちへ行ってしまったのだろうか。
手続き型の呪い？
と同種の悩みなんだろうか。
- 950 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 06:38:49 ]
- 開発が進むごとに関数が増え続ける言語では、
関数の数が多すぎて、管理しきれなくなるからだろ。
関数の使用目的や機能等で特定の関数が使用可能な領域を縛ったりすれば、
もしかしたら可能だったかもしれんが・・・
- 951 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 06:47:00 ]
- > 開発が進むごとに関数が増え続ける言語では
増えない言語ってあるの？
- 952 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 07:04:54 ]
- >>951
現在、検案中。
特定の関数の使用できる条件を、経由した関数名や
オブジェクト等で限定できるようにすれば、
関数の個数を減らす事は可能かな？とか考えてる所。
- 953 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 07:46:32 ]
- 要するに、心当たりは無いが、将来的には存在するかもしれないって事か。
- 954 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:00:51 ]
- Cは開発が進むごとに関数が増え続ける言語だが
(Common Lispのパッケージのような名前空間すらない)、
結構大きなシステムが書かれてるよな。
>>950のいう「管理しきれなくなる」というのは
どれくらいの規模のソフトウェアなのかまず明らかにしろ。
- 955 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:30:42 ]
- しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
だからCの後継言語に名前空間が存在するわけで。
- 956 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:38:35 ]
- >>955
> しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
下調べもせずにこんな適当な思い込みで開発するのはいかがなものか
- 957 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:43:31 ]
- というか、949に対する答えとしては、950はおかしいぞ。
HakellやSchemeが「開発が進むごとに関数が増え続ける言語」で
C++やJavaが「開発が進むごとに関数が増え続けない言語」なのか？
- 958 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 08:57:04 ]
- C++やJavaは、関数が増え続けないように歯止めをかける事が可能な言語かと。ｗ
まあ、その機能を有効活用している例は少ないようだが。ｗｗ
- 959 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 10:42:50 ]
- ヘッダ＆変なプレフィクスが名前空間＆クラスになったと。
本質はあまり変わってないが言語機能でサポートされたから多少は楽に。
- 960 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 12:39:44 ]
- 関数の数なんてソフトウェアの複雑性ではマイナーな問題だろう。
たかが関数が増えることよりも、クラスを一個定義するだけで
ポインタやらconstなポインタやら参照やらconstな参照やら
もちろんあと値渡しも、そしてconstなメンバ関数やらconstでない
それやら、関数ポインタやらメンバ関数ポインタやら……を考えないと
いけないC++の方がはるかに大変だ。
テンプレート使ってると特に。
- 961 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 12:40:37 ]
- えーと。
大概のLispやSchemeのような古い関数型言語には名前空間ないけど、
MLやHaskellなどちょっと新しい関数型言語には名前空間あるよ。
というつっこみを誰もしないのはなぜですか？
- 962 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 13:29:03 ]
- MLが新しいって?
- 963 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 13:44:57 ]
- すまん、全てのMLが新しいみたいに言っちゃったな。
といっても正直、古いLispや古いMLはろくに知らないんで、
少なくとも今生き残っているLisp、MLについては、ってことにしてくれ。
さらに自分で言っといてなんだけど、Schemeって名前空間ないんだよね？
オブジェクト指向っぽいメッセージパッシングなどを
エンコードする形で自力で書け、ってことなのかな。
- 964 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 15:45:28 ]
- LispやSchemeに名前空間がないつっても、Cと違って局所関数やクロージャ、
プロパティリストなどがあるからいくらでも階層構造に出来るしなあ。
その上大抵はベンダーがオブジェクト指向やモジュール機能
提供してるのがデフォだし。
つうか、オブジェクト指向機能を一番最初に搭載したのってLispでしょ？
- 965 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:04:57 ]
- オブジェクト指向とかそのへんはまた荒れるんで、とりあえず
関数型言語は関数が増えるから使い物にならない
か否か、だけにしとこうよ。
- 966 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:10:40 ]
- >>965
だからそのことについてだよ。
ようは、C++やJavaにクラス階層の名前空間があるから、
関数が増えても整理できるっていいたいんだろ？
だったら、Lispで出来るし、むしろLispが最初だってこと。
- 967 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:14:58 ]
- 「大概のLisp」って何時のLispを指してるんだ?
Common Lispにはパッケージがあるぞ。
Schemeは処理系依存だが、次の規格で何か入るらしい。
- 968 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:16:16 ]
- >>967
CommonLispに加えて、Schemeも入れてたから。
- 969 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:18:05 ]
- つまり、関数が増えるからどうのというのはｍとんでもない勘違いでFA。
- 970 名前：デフォルトの名無しさん [2005/12/20(火) 16:21:11 ]
- emacs-lispのイメージがあるんじゃないの？
あれ、なんらかの階層構造の機能を使って、増えた関数を整理するとかして
ないでしょ。
名前のつけ方を長くして階層的にしてるだけで。
- 971 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:24:30 ]
- あれはモード切り替えるから大丈夫なんじゃないか？
カレントディレクトリみたいなもんでしょ。
- 972 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 16:34:33 ]
- >>969
Common Lispには名前空間（パッケージ）やクラスがあるし、
Schemeにも処理系依存でそれらが存在する。
HaskellやMLにはもちろんあるでFA。
- 973 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 17:36:18 ]
- >>954
C言語はコンパイル単位というか、ファイルスコープやリンカが別になってて
元々環境が地続きではないから、そんなに困らなかったんじゃないかと。
干渉して困るのはプリプロセッサのマクロ定義をヘッダに置いた時とか。
- 974 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 18:59:09 ]
- Cは同じ名前の関数があったとしても型定義に違いがあれば誤用をある程度回避できるしな。
C++は多重定義を認めてるからそうはいかないけど。
それを考えると名前空間の採用はC++にとって必然だったんじゃないかね。
- 975 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:04:45 ]
- ス質急低
- 976 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:18:19 ]
- 一気に下がったな。氷点下。
- 977 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:26:23 ]
- >>975-976
>>775
- 978 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 19:30:29 ]
- それより、質の高い話ってなんだろう・・・
- 979 名前：デフォルトの名無しさん [2005/12/20(火) 19:32:45 ]
- ポインタの話から移ったと思えばむしろ質は向上しているよ
ついでにスレも物理的に上昇しておこうか
- 980 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:36:57 ]
- 関数の数を減らせれば、CAD方式でも何とかなるのでは？
という話になると思ってたのは漏れだけか？
CAD方式の話は見事に忘れ去られているようだが。
- 981 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:42:01 ]
- 950があまりにもとんちかんすぎただけだな。
- 982 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:51:26 ]
- スレタイからずいぶん距離のある議論になっているな
- 983 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:06:52 ]
- CAD方式のスクリプト、もしくは言語って、何がある？
- 984 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:07:44 ]
- CAD方式は機能が限定されているような狭い言語でないと、うまく行かないと
分かって来たからな。なので最近は（一部の研究を除いて）全く利用されていない。
- 985 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:17:47 ]
- LabViewがそうだったな。
漏れは使ったことないが、特定分野では成功してるみたいだよ。
www.asahi-net.or.jp/~WR9K-OOHS/Pages/Aboutlv/WWJ/WWJ03/wwj03.html
- 986 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:19:02 ]
- >>984
それって言い換えるなら、機能限定をうまく設定できればうまくいく、という事では？
ネームスペース以上に関数や変数等の摘要範囲を限定するような機能を設定できれば、
何とかなるのでは？
- 987 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:43:14 ]
- >>985
ほとんど電子回路だな。
漏れ的にはUMLのシーケンス図みたいなのを期待してたんだが……
CAD形式みたいなのは「作る人にとって」分かりやすい方式になりがちなのかな？
- 988 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 21:43:33 ]
- 「コンパイラ・スクリプトエンジン」相談室9
pc8.2ch.net/test/read.cgi/tech/1135082582/
- 989 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 07:04:47 ]
- CAD方式は言語というよりもツールになのでは？とか思ったが、
GUI形式の言語という見方をするならば、たしかに言語かもしれんな。
- 990 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 08:03:14 ]
- 複雑になっていくと、他の人や昔の自分が描いたソースを読めなくなりそうだ。
建築設計図ですら欠陥が見抜けないのに、ソフトウェアになったら…
- 991 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 08:52:00 ]
- いや、それはちゃんとコンポーネントを設計して、
ちゃんとコメントを残していけばいい話だろう。
テキスト形式の言語だって最初から完璧だったわけじゃない。
初期の言語で幾多の失敗を重ねたおかげで今の言語があるわけだ。
要はCAD方式言語は研究も経験も蓄積がなさすぎるだけ。
あと、俺らがすでにテキスト方式に慣れすぎてるというのもあると思う。
問題は、テキスト方式の蓄積を捨ててまで
CAD方式に乗り換えるメリットがあるかどうかだが…。
- 992 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 09:11:39 ]
- CAD形式を扱う場合のメリットは、UMLを扱う場合のメリットと同じかと。
図形にすると、処理の流れは分かりやすくなる。
しかし図形には、処理の論理が分かりにくいというデメリットもある。
- 993 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 09:39:02 ]
- UMLはUMLで、オブジェクト指向に関する政治的な駆け引きが色々と絡んで、
ややこしくなってる部分があるからなぁ……
その意味では、CAD形式言語に関しては、図形をいかに定義するかが焦点になりそうだな。
- 994 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 09:54:58 ]
- その場しのぎのやっつけ仕事の場合だと、
むしろCAD形式の方が楽かもしれんな。
世間の仕事の９割ぐらいは、やっつけ仕事だろ？
- 995 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 10:35:34 ]
- UMLはCAD形式の言語？
- 996 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 10:46:20 ]
- フローチャートもCAD方式の言語という事になるな
- 997 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 11:19:07 ]
- CAD型まではいかんが、MAX/MSPやPDは非テキスト型プログラミングの
試みとしては一番成功している部類だろう。
- 998 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 12:01:15 ]
- ﾏﾃﾏﾃ、CAD方式には致命的な欠点があるぞ。簡単にはコピペができんだろ。
特定のツールでしか作れないから、拡張も難しい。
- 999 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 12:47:21 ]
- むしろテキストを図形表示する方が色々と楽かもな。
- 1000 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 13:13:35 ]
- 普通に１０００ゲット
- 1001 名前：１００１ [Over 1000 Thread]
- このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
|
 |
