05/12/13 01:41:20
ＬＩＳＰはなんなんですか
688:デフォルトの名無しさん
05/12/13 01:43:01
まあ俺はPHPを言語処理系っていう側面から見て埋め込みかどうかに疑問を思ったんだが、興味ない奴は読み飛ばしてくれい。
>>686が良い切り返ししてくれたので先に進むけど、「データへの埋め込み言語」って何だろう？
一瞬スタックオーバーランみたいにマシンコード埋め込んで攻撃することだと思ったんだけど違うよね？
あーマシン語は「言語」じゃないか・・・
689:デフォルトの名無しさん
05/12/13 01:46:03
どうか>>687をスルーしてくれ
690:デフォルトの名無しさん
05/12/13 01:55:57
embedded ruby
691:デフォルトの名無しさん
05/12/13 03:42:12
たいていのプログラミング言語に対して正規表現が使えるけど、
あれは一種の埋め込み言語であると思う。
692:デフォルトの名無しさん
05/12/13 03:57:10
>>691
なるほど。確かに。
大抵は正規表現用に、言語自体の字句解析とかとは別口のモジュールで解析してるもんな。
693:デフォルトの名無しさん
05/12/13 04:06:40
たいていのプログラミング言語に対して整数が使えるけど、
あれは一種の埋め込み言語であると思う。
って言ってるのと変わらないぞ、それ。
ていうか、「埋め込み」の厳密な定義なんてないんじゃね？
「埋め込み」の厳密な意味を議論する意義はあるの？
と思いつつも>>654に集まる期待。
694:デフォルトの名無しさん
05/12/13 04:42:12
>>693
> ていうか、「埋め込み」の厳密な定義なんてないんじゃね？
> 「埋め込み」の厳密な意味を議論する意義はあるの？
むしろembedded＝組み込み系って流れじゃなかったっけ？
このスレなんかおかしな方向に行ってるな。
695:デフォルトの名無しさん
05/12/13 04:42:20
プログラム言語なんか研究してる人がいるんだね。
あんなのは有名なのも含めて全部趣味で俺言語作ってるのと
同じレベルだと思ってた。
まさか真面目に研究した成果が、あの行き当たりばったりの
つぎはぎだらけの仕様とはねｗ
696:デフォルトの名無しさん
05/12/13 04:51:01
正直、仕様がつぎはぎになるまで使われる言語なんて全体の 0.1% にも満たないと思うんだが。
697:デフォルトの名無しさん
05/12/13 04:52:38
D言語は最初からつぎはぎでしたが何か？
698:デフォルトの名無しさん
05/12/13 04:53:02
まあいいじゃん。楽しく俺言語つくろうぜ。
699:デフォルトの名無しさん
05/12/13 04:54:28
>>697
つぎはぎってそういう意味なのか？
700:デフォルトの名無しさん
05/12/13 04:55:57
おまいら、>>695みたいな100%の釣りですらスルーできないのかよ…
>>680のような巧妙な釣り(後であからさまになったけど)ならともかく…
701:デフォルトの名無しさん
05/12/13 04:57:30
釣って釣られて盛り上がるのが醍醐味ですが何か？
702:デフォルトの名無しさん
05/12/13 04:57:59
>>700
自分たちでも理解できるレベルになったのが、
嬉しくてしょうがないんだろう。ほっといてやれ……
703:デフォルトの名無しさん
05/12/13 05:03:01
それじゃそろそろprogram representationsとインテンショナル・プログラミングの話をしようか
704:デフォルトの名無しさん
05/12/13 07:29:09
>>696
Ｃ言語の事でつか？
705:デフォルトの名無しさん
05/12/13 10:24:35
>>694
embeddedのIT業界でのデフォはそれで正解
ただ、ここは言語すれなので
706:654
05/12/13 11:07:54
期待されても大して何もでないぞ。
埋め込まれた言語っていってもHTMLファイル
（データ記述のための言語で書かれたデータなんでデータでもあり言語でもあり）
にスクリプトを～くらいしか念頭にはなかったし。
（ちなみにJavaScriptあたりをイメージしてた。PHPはよーしらんです。）
まぁ、ライブラリで提供される正規表現を言語内に埋め込まれた言語と見る
というのもあるかなとは思う。
それに整数など数値演算が埋め込まれた言語というのは
理論上そういう観点もありえなくはないかなという気がする。
こういうのは視点の問題であって一つの存在が一通りにしか解釈できないと
決まったものでもないわけで。
大体今時の言語の文法定義自身が再帰的に部分文法を"埋め込んで"定義されてるわけで
この観点から言えば埋め込まれてる言語とホスト（宿主）言語の区別ってのは
結構便宜的なモンでしかないんじゃないかと思う。
分けて考えるのが便利なときは分けて考えることもできるし、
全体で一個の文法と見るのが便利ならばそう見ても問題ない。
余談だけどそう思ってみると
数値演算につきものの演算子の結合や優先順位の規則の文法的表現ってのは
言語の文法定義の中でもそれ以外の部分とは若干異質な部分でもある。
言語定義をする人は皆、当たり前なんで慣れてしまっているけどね。
707:654
05/12/13 11:37:54
例をあげて考えてみる。
まずはライブラリなどとして提供されるユーザ定義のデータ型が
ベースとなる言語に埋め込まれてベースとなる言語を拡張している例。
データ型といっても整数演算くらいだと見慣れているだろうし、
あんまりピンとこないかもしれない。
けども複雑なテキストデータは実際にパースしないといけないわけだから
単に観念の問題ではなくて技術的にも結構言語チックではある。
既に出ている正規表現もそうだし、例えば昔、私が多項式型を作ったときには
多項式のインスタンスを文字列リテラルで初期化するようにしてみたことがあって
このような場合だと単にユーザ定義のデータ型のリテラル
（正確にはそのように見立てた文字列リテラル）の癖に
その中に「変数」（数学的には不定元か）や「演算子」なんかがあって
その"埋め込まれた"リテラルの扱いはミニ言語っぽくなる。
多項式はデータ・値として4則演算の対象であると同時に
実際に値を代入（数式処理的には「置換」）することで関数のように評価もできたりする。
逆に通常一個の言語として見ている言語の定義を
幾つかのミニ言語を埋め込んで組み立ててあるとみることも実際に可能。
例えばC++を
式言語を制御構造言語に埋め込んでそれを関数宣言言語に埋め込んで、
それらと単純型宣言言語を合わせてクラス宣言言語に埋め込んで、
さらにそれをtemplate宣言言語に埋め込んだものとして考えることもできる。
この時例えばtemplate宣言言語は関数型言語として見ることができて
実際にそのようにプログラミングすることもできるというのが
テンプレート・メタプログラミングだったりする。
708:デフォルトの名無しさん
05/12/13 12:16:37
>>706-707
禿しく納得した。あんたにゃ脱帽。
709:デフォルトの名無しさん
05/12/13 13:23:05
>>654って例の、外国人とRubyに悩まされてる人か？
もしそうならかなり煮詰まってるな。
710:デフォルトの名無しさん
05/12/13 14:06:54
>>709
な、なぜそう思うのかな？
711:デフォルトの名無しさん
05/12/13 15:08:51
>>709の元ネタがよくわからん罠
712:デフォルトの名無しさん
05/12/13 15:12:04
ｽﾚﾘﾝｸ(prog板:924番)
と思われ。
713:デフォルトの名無しさん
05/12/13 15:12:40
いずれにせよ、Rubyに好意を持っていない所から類推すると、
研究畑の人間だと思われる。
714:デフォルトの名無しさん
05/12/13 15:14:23
>654は別にRubyについては何も書いてないよな。
715:デフォルトの名無しさん
05/12/13 16:12:53
>>713
研究の人はルビー嫌いなの？
716:デフォルトの名無しさん
05/12/13 16:22:54
>>715
いんや、少なくとも>>712のリンク先のそのまたリンク先のヨーロッパ人研究者には大好評のようだゾ。
717:デフォルトの名無しさん
05/12/13 16:32:43
日本の研究の人は、自分よりも名前が売れていることでRubyを妬んでいるのです
718:デフォルトの名無しさん
05/12/13 16:44:49
妬むかどうかはさておきRubyの人が（昔はリーマンしながら作ってたようだけども）
いまやオレ言語で食えているのがウラマヤシクないと言えば嘘になろう。
プログラミング言語研究も成熟してきた昨今、
どうしても言語研究で食っていこうとすれば全く新しい俺言語の開発ではなく
言語の一部（例えば既存言語の拡張とか最適化とか）をテーマにすることに
ならざるを得ないが、言語屋の多くは俺言語への夢ってモンをやっぱり持ってるからな。
まぁそういう研究屋業界の世知辛い世情はRubyの人も（出身は言語屋なわけだし）
分かってるからあくまで彼が自称するのは言語オタクであって
研究者とは名乗らないし、開発に徹して研究者的な活動には深入りしないのだろう。
719:デフォルトの名無しさん
05/12/13 16:47:28
>>710
>>714の言う通りRubyについちゃ何も言ってないんだけど、
>>654の最後の「風変わりな実装」と「Windowsに移植」ってとこでそう推測した。
あと>>707であげられている例やら「埋め込まれた言語」に対する態度やらから
そうなのかなあと。
過去ログを調べたら、例の人を2chで初めて見かけたのは2ヶ月以上前だ。
まあ>>654とは別人だろうな。
720:デフォルトの名無しさん
05/12/13 16:50:22
>>712の引用のしかたにﾜﾛﾀ
マ板経由かよｗ
721:デフォルトの名無しさん
05/12/13 16:51:47
別段Rubyに含むところはないが
Unitテストもなしに6万行もあるバギーな拡張ライブラリはキライｗ
特にキャストやテンプレートを濫用して型がスパゲティ化しているプログラムはｗ
722:デフォルトの名無しさん
05/12/13 17:16:30
Rubyとかそういう問題じゃないな。
他の言語でもそれは嫌だぞ。
723:デフォルトの名無しさん
05/12/13 17:28:21
>>722
まぁ、そういうことですよｗ
Rubyが使われてるプログラムの移植でヒドい目に合ってるからRubyの話題も出るけど
それは多分に使い方の問題であってRubyの問題じゃない。
例えば、C++でそんなデカイもんを作るなら最初からC++で書いてRubyから呼び出すとか、
RubyでBisonやflexやXMLパーサ用のコードを生成するとかなんて構造・設計は
勘弁なってくらいでいずれも問題はRubyそのもの良し悪しや好き嫌いの話ではない。
以上誤解のないように。
724:デフォルトの名無しさん
05/12/13 17:30:15
謹んで訂正>>723
誤> 例えば、C++でそんなデカイもんを作るなら最初からC++で書いてRubyから呼び出すとか、
正> 例えば、C++でそんなデカイもんを作るなら最初からC++で書いておいてくれればよいわけで、
Rubyから呼び出すとか、
725:デフォルトの名無しさん
05/12/13 17:43:02
やっぱRubyじゃ巨大プロジェクトの開発は無理か。
せいぜい数千行程度？
726:デフォルトの名無しさん
05/12/13 18:25:20
さぁ？
「やっぱ」とあるが>>723-724はそういう問題ではないだろう。
まぁ、一応Script言語はそれ単体であまり大きな規模の開発を行うことは
想定してないとは思うので個人的にそういう目的に用いることをオススメはしないが、
どこにそのラインがあるかは自明でないのでキッパリ無理とも言い切れない。
727:デフォルトの名無しさん
05/12/13 18:27:04
>>725
別にRubyで何万行書いてもいい。
むしろRubyだけで書く限りであればそれほど問題はないと思う。
Rubyがアホなとこは、そうやって書くと思いっ切り遅くなることがわかってるから、
現実は他の速い言語で拡張ライブラリ作ってツギハギしてくしかないってこと。
拡張ライブラリが順調に動いている内はいい。が、そこでバグが発生したりすると
もうグダグダになる。拡張ライブラリが絡むと環境やモジュール連続性もなく
まず原因の特定が困難で専用のデバグ環境もない。もはやまともなデバグなど
期待できない。だから拡張ライブラリを書いた場合は事前のテストが重要となる。
が、現実はこれをまともにやっている人間は少ないようだ。
ほんとは他の言語で書かす拡張ライブラリみたいなアホな非常口は言語の
作者の目の届かない所でもあるし、とっとと廃止した方がいいのだけど、
Rubyはそれをいつまでもやめないし、既にRubyの仕様上速くなる手段は
閉ざされており、もう誰もがアホだとわかっていてもその非常口に突っ込んで
自滅するしかない、という悪循環がどうみても出来上がっていました。
ありがとうございました。
728:デフォルトの名無しさん
05/12/13 18:30:33
精子コピペすか？
729:デフォルトの名無しさん
05/12/13 18:34:25
わかってはいるが、わかるわけにはいかん！
というやつだね。
墓穴は掘り終わりましたか？
730:デフォルトの名無しさん
05/12/13 18:41:06
>>727
遅くなるって言うけど
手軽さではなく早さが求められるようなプロジェクトで
Script言語を選んじゃう見識は問われないの？
731:デフォルトの名無しさん
05/12/13 18:51:28
言語というより、開発手法や設計のお話だな。
732:デフォルトの名無しさん
05/12/13 18:52:31
この件でRubyの拡張ライブラリがヤバイ事はよくわかった。
733:デフォルトの名無しさん
05/12/13 18:59:05
そういやRubyはVMにできないみたいな話が以前のスレにあった気がするけどあれってなぜ？
734:デフォルトの名無しさん
05/12/13 19:08:15
そろそろスレ違いに気づけ。
Rubyヤバイとかは専用スレがあるんだからそこで騒げ。
735:デフォルトの名無しさん
05/12/13 19:11:25
>>725
デカいプロジェクトだと開発以前に、運用で却下。
保守できる人間が少ないのは怖いし。
もっともここで話す問題ではないが。
736:デフォルトの名無しさん
05/12/13 19:29:06
そう思うなら余所逝けよ。
737:デフォルトの名無しさん
05/12/13 22:21:58
ちょっと勘違いしてるようだけど、数千行のRubyコードって
数十万行のLispコードに匹敵する処理内容が記述できるでしょ。
なので、スクリプト言語≒簡易処理というのは全くの思い違いだと思うよ。
速度が遅くなるのは同意だけど、
738:デフォルトの名無しさん
05/12/13 22:24:27
オ～レ～～～。オ～レ～～～。ジャカジャカジャン！
ま・つ・け・ん・さあ～んば～～～
739:デフォルトの名無しさん
05/12/13 22:48:17
数十万行のC言語のコード、というならともかく・・・
740:デフォルトの名無しさん
05/12/13 23:16:02
>>737
だいぶ勘違いしてるようだけど、RubyとLisp比較するなら
記述量的にはあんま変わらない気がするけどな。
速度気にするならまともなコンパイラ付いてるLispで書いた方が
良かったんじゃないの？
Rubyと違って処理系も色々選択できるし、拡張ライブラリを
速度のために別言語で書く、みたいな馬鹿馬鹿しい問題もない。
741:デフォルトの名無しさん
05/12/13 23:27:55
Lispは、チェックを省いてプロトタイプを作ろうとすると、めちゃくちゃ少ないコード記述量に
なるけど、パフォーマンスを考えてチューニングしようとしたり、エラーチェックを厳密に
やろうとすると他の言語と同じぐらいになってしまう。
742:デフォルトの名無しさん
05/12/13 23:55:27
>>741
憶測だけで言ってない？
つか、付けたしだけで速くなるなら別の言語で書き直すよりは
そっちの方がいいよね。
下のサイト見ると行数もそれほど変わらないし
チューニングコード入れなくても速いみたいだが。
元々速度では勝負にならん差があるけど。
Ruby
URLﾘﾝｸ(shootout.alioth.debian.org)
Lisp
URLﾘﾝｸ(shootout.alioth.debian.org)
URLﾘﾝｸ(shootout.alioth.debian.org)
743:デフォルトの名無しさん
05/12/14 00:14:14
>>742
Rubyが速度で上回るのはstartupだけか。
ひでえなこりゃ。
Rubyってコンパイラ作れないの？
744:デフォルトの名無しさん
05/12/14 00:31:28
ハッキリ言ってしまえば、速度なぞ時間がすぐに解決するんだけどなw
リアル社会を知らない音質Lisperはアクキンにしる！
745:デフォルトの名無しさん
05/12/14 00:33:18
>>743
コンパイラは作ってもあまり意味がないというか、
そもそも作る人がいないという話だった気がする。
746:デフォルトの名無しさん
05/12/14 00:33:43
>>743
作れるはずだし、
作ってる人も（複数人）いるっぽい。
実用になったという話は聞いてないけど。
747:デフォルトの名無しさん
05/12/14 00:41:45
>>744
Ｒｕｂｙはそう言われてきたＪａｖａと事情がだいぶ違うし
言語仕様的に無理かも。
あと１０年待とうね。
748:デフォルトの名無しさん
05/12/14 00:44:51
プロセッサがマルチコア方向にシフトしてきてるっぽいので、
ネイティブスレッドに対応しないと辛いかもね。
749:デフォルトの名無しさん
05/12/14 00:49:15
>>742
おいおい、そこのコードは速度を上げるために
かなりチューニングしてるぞ。
少なくかけるところをあえて速度が上がるような
書き方してる。
750:デフォルトの名無しさん
05/12/14 00:49:52
だから、コード量は、本当はlispはめちゃくちゃ少ないよ。
751:デフォルトの名無しさん
05/12/14 00:50:18
PythonはPython自身で書かれたり他の言語やVMに変換して速くしたりできるっぽい
そういう意味ではPythonの方は将来期待できるかも
752:デフォルトの名無しさん
05/12/14 00:53:09
これなんて象徴的だよな。
本当は5行で終わるところを12行かけて書いてる。
コメントにその5行のコードが書いてあるｗ
URLﾘﾝｸ(shootout.alioth.debian.org)
753:デフォルトの名無しさん
05/12/14 00:56:25
Pythonって構文をちょっと変えたLispそのものだからな
754:デフォルトの名無しさん
05/12/14 01:03:49
出来るだけタイプ量少なくすることで競うならperlが最強。
755:デフォルトの名無しさん
05/12/14 01:04:33
>>752
そのコメント部だけのコードでも動的言語の割には結構速度出るね。
やっぱこの差はネイティブコンパイルしてるからかね。
756:デフォルトの名無しさん
05/12/14 01:04:59
>>754
C++は最下位。
757:デフォルトの名無しさん
05/12/14 01:08:10
>>756
COBOLだろ
758:デフォルトの名無しさん
05/12/14 01:12:24
>>754
LispやSmalltalkなんかは前提とするコアイメージ弄くればなんでも1行で書けるよ。
それに配布物も本体とコアファイルの２ファイルだけで
perlみたいにごちゃごちゃライブラリディレクトリ掘ったりする必要ないし。
759:デフォルトの名無しさん
05/12/14 02:01:41
いや待て、言語同士を競争させるのにコアやライブラリを弄っちゃいかんだろ。
760:デフォルトの名無しさん
05/12/14 02:13:34
Smalltalkならいじるのが当たり前なんだが
761:デフォルトの名無しさん
05/12/14 02:31:30
ライブラリ弄っていいんだったらどの言語でも1～数行で終わって
比較する意味ないじゃん。
762:デフォルトの名無しさん
05/12/14 03:17:26
ライブラリ弄るとかいう発想じゃなくて、LispやSmalltalkでは
言語環境が最初から違うスタート地点に立てる、という観点が
使ったことのない人には想像つかないのかな。
OSで言えば最初からスタンバイ状態になってると考えればいい。
そもそも「出来るだけタイプ量少なくすることで競う」って話だし。
763:デフォルトの名無しさん
05/12/14 03:19:35
いやいや駄目でしょ。
Lispは結構知ってるし、Smalltalkもある程度は知ってるけどさ。
標準ライブラリで、標準のコアで勝負でしょ。
764:デフォルトの名無しさん
05/12/14 03:22:05
まあ拡張を定義した部分まで行数に入れるんだったら
もちろんいい。
765:デフォルトの名無しさん
05/12/14 03:23:18
他の言語じゃ不可能な時点で勝負にもなんないね。
766:デフォルトの名無しさん
05/12/14 03:23:25
あと、その言語として自然な記述で比べること。
7行プログラミングスレみたいな奇怪なコードならCでも短くなるけど、
そういうコードで比べるのも反則。
767:デフォルトの名無しさん
05/12/14 03:23:52
>>765
別に不可能じゃないよ。ライブラリなんてどの言語でも書ける。
768:デフォルトの名無しさん
05/12/14 03:27:34
>>766
ああいう奇怪なコードで書くのがPerlの自然な流儀ですが何か？
769:デフォルトの名無しさん
05/12/14 03:27:56
こんな夜中に何を必死になってんだ
770:デフォルトの名無しさん
05/12/14 03:46:42
>>767
知ってていってるならしょうがないが
開発環境と実行環境が一体化してるもんだから
単なるライブラリとは違う。
771:デフォルトの名無しさん
05/12/14 03:59:21
いくらそんなこと言ったって、同じにしなくちゃ駄目だろう。
やっぱりライブラリを作ってこれ使えば一行とか言ってるのと同じぐらい
反則に俺には感じる。
772:デフォルトの名無しさん
05/12/14 04:00:09
いい加減宗教戦争は勘弁して下さいよ、本当に。
773:デフォルトの名無しさん
05/12/14 04:56:09
スレの質が急激に低下してまいりました
774:デフォルトの名無しさん
05/12/14 05:33:44
>>1 に出てくる語句について教えてください。
「データ分散」って何ですか? NUMAとかのヘテロなアーキテクチャでの話?
「スクラッチメモリ」って何ですか? CellのSPEが持っているような
プロセサ固有のメモリ?
775:デフォルトの名無しさん
05/12/14 05:54:04
>>773
おまえが上質なネタを投下しろよ
776:デフォルトの名無しさん
05/12/14 06:08:41
>>775
おまえが上質なネタを投下しろよ
777:デフォルトの名無しさん
05/12/14 06:51:03
>>774
>>1に聞けよ
778:デフォルトの名無しさん
05/12/14 08:16:38
HTML化されてる最初のスレはかなりレベル高かったみたいだね。
今の>>1-5のテンプレはいつごろからあったんだろ？
779:デフォルトの名無しさん
05/12/14 14:52:11
>>774
厳密にはともかく概ねそれで合ってんじゃない？
>>772
宗教戦争になるのは
優劣を計ろうとしていながら物差しがちゃんと定義＆評価されてないからだと思う。
言語設計ということを理解するに当たって既存の言語を比較対照することそのものは
悪くないと思うのだけれど、基準が独りよがりすぎるから感情論になる。
それにRubyがでてくるのは話の流れとしてまだわかるが
Lispはいくらなんでも唐突過ぎる。
イキナリRubyと比較してるが使われる局面も設計時の背景や目的も明らかに違うから
何を比較したいのだかよーわからんことになってる。
言語設計の課題は設計目的にどのくらい適っているかどうかだし、
言語選択の問題は開発対象の性質に言語がどのくらい適合しているかだろう。
いずれにせよ目的も基準もハッキリしない漠然とした優劣は問題ではない。
780:デフォルトの名無しさん
05/12/14 14:55:35
プログラムの長さ、記述量が問題になっていたようだが…
情報理論の教えるところによって符号化という視点で考えれば
プログラムもまたプログラムの仕様という情報を符号化したもの。
言語が違えば符号化の体系が違うと考えられるわけで、
単純にコードの文字数を云々することにはあまり意味がない。
例えばコードの中でよく使われるパターンが短く、
あまり使われない構文が長くといった設計上の戦略もある筈だから
どういう目的で設計されているかということを考える必要がある。
また誤り訂正符号などの例のように純粋に内容の情報
（プログラムなら例えば中心となる内容はデータ構造とアルゴリズムだろう）
だけでなく誤りを見つけやすくするための付加情報が含まれるケースもある。
特にプログラミング言語という符号体系は人と機械の間をとりもつ際の
ユーザ側インターフェイスであるわけで
人の認知科学的な処理特性を無視することはできない。
例えば制御文と式と宣言文の構文が分かれていたり、
意味が連想しやすい名前がキーワードに使われるとか、
ユーザが把握しやすい動作モデルを提供するというのは
文字数単位でコード量（端的にはタイプする量）が増えても
そういう観点からは意味がある。
781:デフォルトの名無しさん
05/12/14 15:01:42
>>778
4からじゃね？
782:デフォルトの名無しさん
05/12/14 15:07:53
>>779-780
なげーよ
日記なら他所でやれ
783:デフォルトの名無しさん
05/12/14 15:20:39
言語の設計には必ず設計目的があり、
設計目的はその時点での背景がある。
そういうことを考えずに闇雲に優劣をつけようとするのは無意味なことだ。
以下に技術的背景が言語設計に及ぼした影響について幾つか例を挙げる。
まず言語は既存言語の存在を前提にしている。新しいものは特にそうだ。
Javaの例で言えば：
JavaはCが存在していて必要ならば使うことができることが前提だから
比較的汎用指向の言語でありながら
Cで書くことが適切であるようなハードウェアレベルの記述機能を
潔くスッパリ切り捨てた設計ができている。
例えば、バイトコード＆仮想マシンの採用やポインタ演算の放棄などがそうだろう。
Javaではそれらと引き換えにより厳密な静的型検査が可能になり、
それがバイトコードの検証といったセキュリティ技術、
ひいてはモバイル・コードの実現といった当初の設計目標を支援している。
784:デフォルトの名無しさん
05/12/14 15:21:25
また、言語は設計当時の技術水準を前提にして設計されているし、
当時重要であった課題を優先して解決するように設計されている。
FORTRANの例で言えば：
FORTRANの行指向な言語設計は行単位に1枚のカードが使われていた
ハードウェア技術に大きな影響を受けている。
構文解析が案外面倒な面倒な算術式のパース技術が取り入れられた背景としては
当時算術演算を手軽に記述できる言語が他になく正にそれが求められていたからだ。
その一方で計算機のメモリやディスクの容量が限られていたこともあって
プログラム規模が当時は現代より比較的小さかったので
ユーザ定義のデータ型への需要は相対的に小さかったためそういう機能は貧弱だ。
LISPの例で言えば：
何よりAI研究で必要な柔軟なデータ形式である
リンクリストやそれを利用したツリーを簡単に操作できることが優先目標だったから
それが充実している一方で、算術式はお世辞に読みやすいとは言えないし、
効率のよいランダムアクセス可能な配列といった機能はなかった。
（近年LISPを語る際によく言及される、
メタな機構が充実したのはちょっと後のことで誕生当時の古LISPでのことではなかった筈だ。
言語のメタな構造がLISPが解く意図するツリー構造と相性がよかったこと、
元々の適用分野がAI研究だったことなどが影響しているのだろう。）
785:訂正
05/12/14 15:24:35
解く意図する→得意とする
786:デフォルトの名無しさん
05/12/14 15:25:54
ここは公開オナニー劇場ですか
787:デフォルトの名無しさん
05/12/14 15:26:55
宗教戦争なんてしてたっけ。
788:デフォルトの名無しさん
05/12/14 15:27:18
>>782
日記など書く趣味はないよ。
言語戦争の発端のグチを>>654-の記事の一部にポロっと書いた責任を取って
正攻法で技術論に戻して収拾しようとしてるだけ。
789:デフォルトの名無しさん
05/12/14 15:33:02
ｳｻﾞｽ
２、３行で要約しろよ
790:デフォルトの名無しさん
05/12/14 15:36:33
冗長でも誤りを見つけやすくするため云々は一理あるけど、
冗長に書かないといけないせいで入るバグもあるから
トレードオフであることは意識しないとね。
「把握しやすい」ってのも、
その感覚はユーザによってばらつきがとても大きい。
これを意識しないで話すと宗教戦争になる。
791:デフォルトの名無しさん
05/12/14 15:41:37
>>787
顛末は例によってRubyが貶されて信者が暴れただけ。
792:デフォルトの名無しさん
05/12/14 16:10:36
>>783-784
知識の垂れ流し、結構なことです。
が、ここはお前の落書き帳じゃねーんですよ。
各言語の歴史的経緯についてなんかは言語仕様書の冒頭にでも
書いてありそうなことだし、こんな所で長々と解説されても信憑性も
疑わしいわでだんだん話が薄っぺらくなっていくだけですよ。
こちらとしては、そんなものより要点だけ数行でまとめて書いてくれると
読みやすいわ疲れないわでとてもありがたいわけですよ。
793:デフォルトの名無しさん
05/12/14 16:12:53
ｳｻﾞｽ
２、３行で要約しろよ
794:デフォルトの名無しさん
05/12/14 16:14:04
>>793
一行で要約できますた。
「ここはお前の落書き帳じゃねーんですよ。 」
795:デフォルトの名無しさん
05/12/14 16:25:20
つまり過剰な冗長さは悪し、という例ですな。
796:デフォルトの名無しさん
05/12/14 16:29:39
長くなると（読解力が不足がち人には）ウザイってのはそうだろうけど
（なら読み飛ばせば？とも思うのではあるけども
読み飛ばしてもくれずわざわざウザイと書いてしまう
不思議な心理があるようですね。）
信憑性が薄くなるってのはよくわからないな。信憑性は内容の問題でしょ?
読解しきれないと内容が理解できないからそういう読み手にとっては
信憑性が薄く「感じられる」というなら納得。
ちなみに要約、要約と言ってるけど
要約というのも情報処理だから当然情報量が減るわけですが、
そこはわかってますか？
要約された梗概ばっか読んでたら
そりゃ目は楽だろうけども身のある話はできませんぜ？
要約なんてのは言わば骨格標本みたいなもので肉はないんだから。
それにこの程度のことで知識の垂れ流しと言われるのも心外。
議論のためのほんのとっかかりのつもりだし、
ちょっと年寄りの言語屋なら別に知るともなしに知ってるような話であって
自慢するほどの知識じゃない。
…と>>792を見た瞬間に思ったけども、>>794にある要約が>>792の真意なら
あまり意味はない単なる煽りなわけで無視したほうがいいのかな？
797:デフォルトの名無しさん
05/12/14 16:32:08
>>795みたいな茶々いれの冗長性はどんなもんすかね？
798:デフォルトの名無しさん
05/12/14 16:37:55
>>796
一行で要約できますた。
「無視したほうがいいのかな？」
799:デフォルトの名無しさん
05/12/14 16:42:58
梗概が読めなかった。「こうがい」って読むのか。
800:デフォルトの名無しさん
05/12/14 16:53:40
>>796
>自慢するほどの知識じゃない。
そう。
あなたの知識の垂れ流しは、言わばほとんど無駄な情報＝ノイズなわけですよ。
あなたの言う骨と肉で例えると、見るに耐えないブヨブヨです。
すなわち骨が入ってるのかどうかさえ確認するのは困難です。
それをいちいち探りながら読んでいると時間も掛かり頭痛も絶えないわけでして、
長文をお書きならもうちょっと読ます文章を心掛けて書いて頂けませんか？
ということですが、お分かりになられませんかね。
801:デフォルトの名無しさん
05/12/14 17:00:51
よし、１０行縛りにしようぜ
802:デフォルトの名無しさん
05/12/14 17:08:25
>>797
丸ごと読み飛ばされる冗長性に比べると、一行コメントぐらいの冗長性ですな。
803:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/12/14 17:33:35
＞9ドルずつ払ったことになり、9ドル×3人で27ドルです。
問題が間違ってますよ。30-5+3で3人で28ドルですが。
端数切捨てですか？
805:デフォルトの名無しさん
05/12/14 17:37:43
いや3人が払ったのは27ドルでしょ。27-2=25ドルがオーナーの受け取った金で。
と、おいらも釣られてみましたよ。
806:デフォルトの名無しさん
05/12/14 17:38:31
>>784
いや、一番最初のLISPの目標は計算モデルを記述すること(チューリングマシンの代替)だろ。
それはまた、自分自身の処理系を簡潔に記述できる構造であることを意味する。
だからメタな機構はLISPの根本だと思うよ。メタサーキュラーな処理系があれば
それを種にして何でも出来るんだから。マクロやMOPは使い勝手の上で
追加されたおまけみたいなもん。
807:デフォルトの名無しさん
05/12/14 17:40:19
>>781
このスレ6から読み始めたので、2～5のdatどれかしら持ってたらうｐしてもらえませんか？
808:デフォルトの名無しさん
05/12/14 17:43:32
論争 Rubyで大規模プロジェクト 採用企業４割拡張ライブラリ使わず
URLﾘﾝｸ(www.toyama.hokkoku.co.jp)
あるチーフプログラマーは「日本人なら、Ruby。大規模プロジェクトでも拡張ライブラリは必要ない」と言い切り、
今後も拡張ライブラリとの併用はしない考えだ。
809:デフォルトの名無しさん
05/12/14 17:46:47
掲示板は書き手同士のコラボレーションで成り立ってるから、
そういうTPOとか特性を考えた上て書けってことだろ
そろそろこのスレの趣旨の話に戻せよ
810:デフォルトの名無しさん
05/12/14 17:53:38
>>808
この業界では技術に保守的なだけでもクズだというのに、
ついにナショナリストまで登場しているのか（笑）
811:デフォルトの名無しさん
05/12/14 17:59:31
>>808
ネタのつもりなんだろうけど、そういうまるっきりウソ流し続けてると
コミュニティ過激派から訴えられるかも知れんぞ
812:デフォルトの名無しさん
05/12/14 18:01:50
おれは2が欲しい
813:デフォルトの名無しさん
05/12/14 18:14:18
おれはお前が欲しい
814:デフォルトの名無しさん
05/12/14 19:13:58
>>803
真相をお話します。
オーナーはご想像の通り、物忘れが酷い人物ですが慈悲深く、
ボーイもまた欲深いという欠点を持つ人物ですが、それでも
ボーイはオーナーの人格を信頼して付き従っておりました。
さて、実はこのホテルのシステムは後払い方式なのですが、
オーナーの物言いにボーイは素直に頷き、オーナーから
預かった５ドルを欲深さからそのまま着服しました。
翌日オーナーは例外なくそのことを忘れており、
チェックアウトした旅人へ謝罪し２５ドルを受け取りました。
結局その時ホテルで５ドルの損失が発生したのですが、
オーナーはそれに気づかず運営を続け、やがて倒産してしまいました。
しかしその後ボーイは着服で貯めた金で大成し、
路頭に迷った元オーナーを雇ってあげたという話です。
経営者としてはボーイの方が格上だった、が正解です。
815:デフォルトの名無しさん
05/12/14 19:42:02
ﾋｿ(´д)(д｀)ﾋｿ
816:デフォルトの名無しさん
05/12/14 22:26:28
3人の言語オタがおりました。
このスレを見つけて、そこの住人に最高と思う言語をたずねると、
「RubyとLisp以外です」と答えました。
817:デフォルトの名無しさん
05/12/14 22:28:14
eagerな言語は使う気がしない
818:デフォルトの名無しさん
05/12/14 22:42:51
クロージャまわりのメモリ管理ってどうやってます？
・基本はスタック上で、捕捉されたらヒープにコピー
・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
・めんどいので全部ヒープに取ってGCまかせ
・その他
と、ネタ投下してみる。
819:デフォルトの名無しさん
05/12/14 23:13:26
>>807
URLﾘﾝｸ(makimo.to)
820:デフォルトの名無しさん
05/12/14 23:57:16
>>818
全部ヒープでやってる。速度は今のところ考えてない。
いずれはスタック使いたいんだけどね。
とりあえず論文読み中。
URLﾘﾝｸ(www.cs.indiana.edu)
821:デフォルトの名無しさん
05/12/15 01:12:12
>>818
>・基本はスタック上で、捕捉されたらヒープにコピー
捕捉されたらとは？生成のこと？
>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
クロージャの生成構文を別々に設けるということ？
これらの意味は？
おれの見解ではクロージャを使うだけであればスタック、
クロージャを生成する際、親フレーム以下があれば
ヒープに落としてフレーム参照を繋ぎかえる、
この時既にヒープに落ちていれば何もしない、
という戦略がスマートというか、一般的じゃないかと。
使用回数＞生成回数という場合ね。
CPSやジェネレータみたいな使い方しかしない場合は
コピーが連続して不利になるけど、こんなことは
やろうと思わなければめったにない。
822:807
05/12/15 01:28:06
>>819
どもありがと。さいこー
823:デフォルトの名無しさん
05/12/15 02:53:00
>>818ではないですが面白そうな話題ですね。
>クロージャの生成構文を別々に設けるということ？
エスケープ解析とか？
>おれの見解では(略
すまん、理解不能。
といってもクロージャ変換で実装したことしかない俺の知識が足りないだけ。
興味あるので「一般的」の参照をくれるとうれしい。
824:デフォルトの名無しさん
05/12/15 04:31:04
>>803
○○○○○.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ 最初に支払ったお金３０ドル
↓
●●●◎◎.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○ ３ドル返す ２ドルくすねる
└┼┘└┤└──────┬───────┘
│ │ └ 主人の手元に２５ドル
│ └ ボーイの手元に２ドル
│
└ お客の手元に３ドル
支払ったお金は２７ドル
９×３＝２７ ９ドルずつを３人で払った
３０－３＝２７ ３０ドル払って３ドル返してもらった
２５＋２＝２７ 主人に２５ドル、ボーイに２ドル払った
ボーイがくすねたお金２ドルは、客が支払ったお金（２５＋２）の一部
だから支払った２７ドルにさらに２ドルを足すことが間違い（２５＋２＋２・・・×）
最初の金額３０ドルを求めるには、実際に支払ったお金２７ドルに 戻ったお金３ドルを足さなければならない
825:デフォルトの名無しさん
05/12/15 04:51:17
エスケープ解析というのを知らなかったのでぐぐってみたのですが、
関数等のスコープの中で定義した変数やクロージャの
利用がスコープの中だけで完結し、外には持ち出されないことを
調べるということでしょうか。
826:デフォルトの名無しさん
05/12/15 13:44:56
そうです。
827:デフォルトの名無しさん
05/12/15 17:01:53
>>783-784
おもしろい。長くてもいいからやってくれ。
くだらん短い書き込みより、長くてもおもしろいほうがいいや。
長いのがいやなら読まなきゃいいだけ。
>JavaはCが存在していて必要ならば使うことができることが前提だから
>比較的汎用指向の言語でありながら
>Cで書くことが適切であるようなハードウェアレベルの記述機能を
>潔くスッパリ切り捨てた設計ができている。
ここらへんはたぶん違ってて、Javaに低レベルの記述がないのは単にJavaがバイトコードインタプリタを採用したからであって、Cがあるから云々は関係ないと思う。
ポインタをなくしたのもGCを導入しやすくするためで、やっぱりCとは関係ない。
828:デフォルトの名無しさん
05/12/15 18:15:07
>>827
そのへんは、鶏が先か卵が先かみたいなもんじゃね？
>>780
>人の認知科学的な処理特性を無視することはできない。
認知科学的には、冗長だとミスが増える法則もあるので
トレードオフだよね。
>ユーザが把握しやすい動作モデルを提供する
同じ物でも「把握しやすさ」はユーザによって
ばらつきが大きいんだよね。
ここを意識しないと宗教戦争になる。
829:デフォルトの名無しさん
05/12/15 21:03:36
>>827
ポインタはあるよ。
論文ばかり読んでる○○研究者か？
830:デフォルトの名無しさん
05/12/15 21:05:42
>818
継続も使いたいから
>めんどいので全部ヒープに取ってGCまかせ
かね……
831:デフォルトの名無しさん
05/12/15 21:35:49
>>823
>興味あるので「一般的」の参照をくれるとうれしい。
図にすると下みたいなイメージだけど、その辺は「クロージャ」が
出てくる速い処理系のソースかドキュメントでも読んでよ。
今の所これ以外に速い実装は思いつかないが。
※ |****| はフレームの変数とかの中身
※ (矢印)はフレームポインタ
スタック |******親1******|(←)|******親2******|(←)| ★クロージャ生成直前
ヒープ ヒープはまだ空の状態
↓ ヒープに落としてフレーム参照を繋ぎかえる
スタック | 親1 |(↓)| 親2 |(↓)| ★クロージャ生成完了
ヒープ |******親1******|(←)|******親2******|(←)|
エスケープ解析までするなら特定の親のみしかヒープのコピーは発生しない。
例えば親1のフレームしか参照しないのであれば親2のフレームは
そのままスタックに残しても良い。
スタック | 親1 |(↓)|*******親2*****|(←)| ★クロージャ生成完了
ヒープ |******親1******|(←)| ←── 生成されたクロージャは直接親1を参照
832:デフォルトの名無しさん
05/12/15 22:12:03
>>829
参照のことをポインタだって言い張ってる人はいますね。
833:デフォルトの名無しさん
05/12/15 22:43:17
Javaでポインタがあるっていう人間は低脳。バイトコードの仕様書読み直してから来い
834:818
05/12/16 01:44:55
>>821
>>・基本はスタック上で、捕捉されたらヒープにコピー
>捕捉されたらとは？生成のこと？
「生成されたクロージャが、
子孫のスタックフレームでないフレームに捕まえられたら。」かな。
例えばforeach的な関数にクロージャを渡してそのまま捨てるような状況なら
コピーは要らないわけです。
これをやると破壊的な処理がやたらと高くついたり、
いざコピーとなったときにやたらと高くついたり、
その他色々と面倒なことになったりしそうですが。
>>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
>クロージャの生成構文を別々に設けるということ？
コンパイル時に絶対にコピーが要らないとわかったときのみ、
フレームはスタック上に置いて、
それ以外は最初から親フレームはヒープに置いておこうと。
「関数aはクロージャを引数に取るが、それはどこにも保存されない」
ということになればa以外を呼ばない関数のフレームはスタック上に置いて良いでしょう。
が、やっぱり色々あって面倒なことになったりしそうです。
どっちもクロージャより親フレームが長生きなら問題ないよねという方針。
835:デフォルトの名無しさん
05/12/16 18:53:57
Javaでポインタが無いと信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
836:デフォルトの名無しさん
05/12/16 19:38:44
個人的な主観かもしれないけど、
ポインタ演算が無いものは参照と呼ばないか？
837:デフォルトの名無しさん
05/12/16 20:21:09
例えば、Cのポインタをタンイポと呼ぶように2006年から改正したら、
2006年からポインタが無いことになるぞ。
ポインタだのタンイポだのと言われてることが全て。
838:デフォルトの名無しさん
05/12/16 20:41:20
ポインタをタンイポと呼ぶためには法改正が必要なわけだが、2006年からというのは早急すぎるな。
まずは有識者を集めた小委員会の設置を図った上で、再来年以降の国会提出でも十分だと思う。
839:デフォルトの名無しさん
05/12/16 20:44:35
配列のイテレーターと参照と参照ポインタとメモリアドレスのポインタとを
一括してポインタと呼ぶべきでない。
840:デフォルトの名無しさん
05/12/16 21:04:11
>>835
Javaでポインタが有ると信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。
841:デフォルトの名無しさん
05/12/16 21:05:31
え、ポインタと参照の違いは常識だと思ってたのですが。
またトンデモ本の誕生ですか。
842:デフォルトの名無しさん
05/12/16 21:06:01
>>840
ほんたまですか？
843:デフォルトの名無しさん
05/12/16 21:06:22
塗るタンイポえくせぷしょん
844:デフォルトの名無しさん
05/12/16 21:06:32
懐かしい名前を出さないでください。せっかく忘れていたのに。
845:デフォルトの名無しさん
05/12/16 21:07:45
Pascalのポインタは演算できないけどポインタと呼ぶな
だから正解は>>837
846:デフォルトの名無しさん
05/12/16 21:10:09
でも一般的に見たら、参照とポインタの一般像みたいなもんはあるだろ。
Pascalは例外じゃないか？
847:デフォルトの名無しさん
05/12/16 21:12:33
PascalはInc, Decができるじゃん。
848:デフォルトの名無しさん
05/12/16 21:12:34
たしかにポインタの演算はできないけど数値にキャストできるから同じ事では。
849:デフォルトの名無しさん
05/12/16 21:21:12
みんなそんなにボロカスに言うなよ。
Mさんが可哀想じゃないかｗ
850:デフォルトの名無しさん
05/12/16 21:22:33
まあ少なくともJavaの参照はポインタではないことは確かだ。
名前が参照だから。
851:デフォルトの名無しさん
05/12/16 22:35:58
そんなの実際どうとかじゃなくて、
設計者がどう定義したかと、その思想によるだろう。
だから>>850が正しい。
852:デフォルトの名無しさん
05/12/16 22:41:17
名前はともかくとしても、実際の内容を素直に受け止めれば
いいと思うけど。なので >>835 が正解。
853:デフォルトの名無しさん
05/12/16 22:42:47
>>835とか>>852は、ポインタと読んでCのポインタを連想した上で書いてるわけっしょ？
だったらやはりCの言葉の定義に(ry
854:デフォルトの名無しさん
05/12/16 22:44:40
実際の所、Rubyにはポインタは存在するがLispには存在しない。
855:デフォルトの名無しさん
05/12/16 22:46:11
>>853 ポインタという言葉の定義or使用はＣが最初ですか？
856:デフォルトの名無しさん
05/12/16 22:48:01
RubyもLispもPascalも、同じ太陽を感じ、同じ月を見て. 同じ空気を吸っているのだから
ポインタの有無くらいで区別するのはよくないと思います。
857:デフォルトの名無しさん
05/12/16 22:50:26
しかし、ポインタの有無は実用性を大きく左右するんだよ。
858:デフォルトの名無しさん
05/12/16 22:51:20
うむ。
859:デフォルトの名無しさん
05/12/16 22:52:51
結局は宗教論争。
和平への道はアセンブラ原理主義しかない。
860:デフォルトの名無しさん
05/12/16 22:53:34
>>855
ALGOL60にPOINTERという型は既に存在したらしいぞ
URLﾘﾝｸ(www.99-bottles-of-beer.net)
861:デフォルトの名無しさん
05/12/16 22:55:01
Java ポインタ の検索結果 約 197,000 件中 1 - 10 件目 (0.03 秒)
URLﾘﾝｸ(www.google.co.jp)
Java 参照 の検索結果 約 2,830,000 件中 1 - 10 件目 (0.24 秒)
URLﾘﾝｸ(www.google.co.jp)
この様にJavaポインタ派は、Java参照派と比較するとごく少数です。
どうやら集団で勘違いされているみたいです。
>>856
Rubyにはポインタはありません。
ポインタに相当する機能は持ってますが、
それはポインタではありません。
862:デフォルトの名無しさん
05/12/16 22:58:05
実にくだらない話題に収束したな。
863:デフォルトの名無しさん
05/12/16 23:29:43
ポインタ演算とか、インクリメントとかデクリメントとか、数値へのキャストとかそういうのを
わざと制限したものは普通、ポインタじゃなくて参照って言わない？
864:デフォルトの名無しさん
05/12/16 23:33:18
>>857
同意。ポインタのある言語は領域破壊のバグが頻繁に紛れ込むが、
Javaのようにポインタのない言語はそうしたバグは非常に少なくなる。
865:デフォルトの名無しさん
05/12/16 23:33:48
いわないね。
Delphiだと明確に区別されてるし。
866:デフォルトの名無しさん
05/12/16 23:34:56
>>865
Delphiは言うじゃん。参照って。
867:デフォルトの名無しさん
05/12/16 23:37:26
つまり、865は「ポインタとは言わない」と言いたいちゃうんかと。
868:デフォルトの名無しさん
05/12/16 23:40:25
あぁ、863へのレスのつもりなのね。
869:デフォルトの名無しさん
05/12/16 23:52:19
>>857
つまりLispは実用的でない証明ってこと言いたいわけ？w
870:デフォルトの名無しさん
05/12/17 00:05:20
lispにポインタはありません。ポインタの無い言語は実用性で勝ります。864を参照。
871:デフォルトの名無しさん
05/12/17 00:10:12
Cにはポインタがあります。ポインタのある言語は自由度と汎用性で勝ります。864参照。
872:デフォルトの名無しさん
05/12/17 00:10:39
Lispにポインタはあるが、そういえば、Lispのポインタって完全にJava、Rubyなどで言う参照だよな。
結局その言語でそれをなんと呼ぶかってことだな。
873:デフォルトの名無しさん
05/12/17 00:11:26
>>871
確かにバグを出す自由度で勝りますねｗ
874:デフォルトの名無しさん
05/12/17 00:19:31
ようやくLispが出てきたか
やっぱこのスレの主役はLispだよな！
875:デフォルトの名無しさん
05/12/17 00:20:01
Lispこそがすべての源流であるということは認めざるを得ない。
876:デフォルトの名無しさん
05/12/17 00:23:32
そもそも「Javaでポインタ」って話は、C++使いにJavaの参照を教えるときに「C++の参照と違ってポインタみたいなもんですよ」って説明するだけの話じゃなかったっけ？
それ以外の時に普通Javaの参照はポインタとは言わない罠。
まあ「何かを指し示す」って意味に限定すればJavaの参照とCのポインタは一緒だから「存在しない」とまでは言う気ないけど。
ポインタ演算ができるかどうかなんてポインタの本質じゃないでしょ。
877:デフォルトの名無しさん
05/12/17 00:25:38
>>876
一般に参照とポインタの区別を云々する場合、ポインタ演算の有無こそが本質のうちの1つです。
878:デフォルトの名無しさん
05/12/17 00:26:56
>>877
そうなの？ポインタキボンヌ。
879:デフォルトの名無しさん
05/12/17 00:27:45
ポインタ演算があるのと無いのとではバグの量と種類に大きな違いが出るのだよ。
880:デフォルトの名無しさん
05/12/17 00:29:26
Cのポインタは、演算によって「値をずらす」ことができるだろ。
int a;
int *p = a;
p += 1; //←これ
参照はそれができない。
881:デフォルトの名無しさん
05/12/17 00:30:15
それはポインタ演算の有無の話であってポインタの有無の話ではないですね
882:デフォルトの名無しさん
05/12/17 00:31:08
間違った。
int a;
int *p = &a; //アドレスを代入
p += 1; //←これ
*p = 1; // 任意のアドレスのデータを破壊
参照はこれができない。
883:デフォルトの名無しさん
05/12/17 00:32:00
ポインタの有無の話ですよ。今や、それが出来ないものをポインタではなく参照とよぶことが多いんですから。
884:デフォルトの名無しさん
05/12/17 00:32:51
ポインタは任意のハードウェア例外を引き起こす。
*(int *)(0) = 0; // 不正なアドレスへの書込み
参照ではこれはできない。
885:デフォルトの名無しさん
05/12/17 00:33:23
これぐらいか？
●同じ点
Javaの参照もCのポインタも、どちらも間接参照を表すためのものである。
●異なる点
Javaの参照はヒープ上にあるオブジェクトしか指す事ができない。
Cのポインタはどこにあるオブジェクトも参照できる。
Javaで参照されているオブジェクトは決して消滅しない。
Cで指されているオブジェクトはいつの間にか消滅している可能性がある。
(そして、消滅したオブジェクトへの参照をたどった場合の動作は未定義である)
Javaの参照にはCのポインタ演算のような機能はない。
Cのポインタ演算は、配列の要素を指すポインタのみに使う事ができる。
それ以外の場合の動作は未定義である。
Javaの参照の動作はかなり厳密に定義されている。
Cのポインタに対する操作には「未定義である」という部分が多い。
それを利用して環境依存の色々な技が使えたりする。
886:デフォルトの名無しさん
05/12/17 00:34:20
Cのポインタが安全性を保証してないだけの話じゃん
887:デフォルトの名無しさん
05/12/17 00:35:50
クロージャの話しようぜ
888:デフォルトの名無しさん
05/12/17 00:37:11
>>887
まずクロージャを定義してださい。
889:デフォルトの名無しさん
05/12/17 00:38:20
ポインタは本来、「何かを指し示すもの」という意味でした。
この言葉は、アドレスやそれを格納した変数などにたいして用いられてきました。
しかし、時代が移り変わるにつれ、ポインタ演算によって、頻繁に深刻なバグが
発生することがわかってきました。ポインタ演算の有無が非常に重要だという
ことがわかってきたのです。
かくして、本来は本質でなかったポインタ演算の有無が、時代とともに重要視
され、ポインタの本来の意味が変わってきたわけです。
890:デフォルトの名無しさん
05/12/17 00:38:34
ださいとかいうなや
891:デフォルトの名無しさん
05/12/17 00:42:25
ポインタ演算を適用できる変数やアドレスの数値と、参照との区別を明確にするため、
前者のことを特にポインタと呼ぶようになったのです。
特に言語として、Cがダントツで有名になったこともこの背景にあります。
892:デフォルトの名無しさん
05/12/17 01:05:55
・ポインタ演算を元に考えればJavaやその他の言語にポインタはない。
・そうでなければいわゆる参照（C++の参照を除く）はポインタみたいなもん。
ってことでFA？
893:デフォルトの名無しさん
05/12/17 01:12:47
代入なんかをインスタンス化してしまう言語にはポインタがない、参照切れもない。
894:デフォルトの名無しさん
05/12/17 01:16:58
>>892
あと、
・その言語がポインタと呼んでいないものは、その言語ではポインタではない。
895:デフォルトの名無しさん
05/12/17 01:18:08
>>893
ポインタ演算ができないからでしょ。
>>894
そんなこと言ったらJavaScriptにはクロージャはないってことになるじゃん。
896:デフォルトの名無しさん
05/12/17 01:21:50
いろんな言語のポインタ、いろんな言語やハードのアドレスは、それぞれ別のものを
別々に定義可能。
それらの用語の使い方は仕様によって異なる。
時々これらを混同して、「アドレスはポインタか？」とかの議論で、おかしな議論を
展開しちゃってる人がいるけど。
897:デフォルトの名無しさん
05/12/17 01:23:05
>>895
クロージャを他の機能で代替してるだけなら、
厳密な意味ではクロージャはないんじゃないの？
898:デフォルトの名無しさん
05/12/17 01:25:39
ECMAScriptの仕様書のP144にクロージャ出てきますが何か？
899:デフォルトの名無しさん
05/12/17 01:25:40
厳密な意味ならね。
900:デフォルトの名無しさん
05/12/17 01:26:56
>>896
禿同。
このスレは変な議論で盛り上がるよなｗ
901:デフォルトの名無しさん
05/12/17 01:26:57
その言語がそれをクロージャと呼んでいないなら、クロージャじゃない。
902:デフォルトの名無しさん
05/12/17 01:29:06
>>898訂正
×P144
○P132
903:デフォルトの名無しさん
05/12/17 01:32:05
ああ、Cのポインタは実装によってマシンのアドレスと違うことがあるから、
アドレスはポインタではないとかいっちゃってる人いますね。
Cのアドレスとマシンのアドレスを混同しちゃってる例ですかね。
904:デフォルトの名無しさん
05/12/17 01:46:37
要はどっちでもいいだろって話でしょ。
Javaの言語仕様に関する議論で「ポインタは～」とか言ってたら指摘すべきだが、>>876みたいな文脈で「ポインタみたいなもん」って言ってるだけでつっこむとしたら揚げ足取り以外の何物でもない。
905:デフォルトの名無しさん
05/12/17 01:51:38
ポインタをマシン語のアドレスと思ってあつかうと
マルチコア、マルチタスク、マルチキャッシュなＣＰＵでは
競合が発生して、かなりわけわからんことになる昨今。
906:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/12/17 01:58:41
燃料投下
Javaでは、NullPointerExceptionっていう言語定義された例外が存在するんですがｗｗｗｗｗ
908:デフォルトの名無しさん
05/12/17 01:59:53
NullPointerExceptionを考えた馬鹿を吊るし上げればいいだけだお^^
909:デフォルトの名無しさん
05/12/17 02:01:45
>>906
なるほど
JavaScriptやlua、perlもそれと同じだね。
910:デフォルトの名無しさん
05/12/17 02:04:49
>>907
Javaにポインタがあるとか言ってる奴の主張はそれじゃなくて
参照のことだろ。
911:デフォルトの名無しさん
05/12/17 02:08:44
URLﾘﾝｸ(nantan.xrea.jp)
「ポインタ(pointer)」と「参照(reference)」とは、同じようで微妙に異なる。
簡単にいうと、「参照」はデータを間接的に参照することで、「ポインタ」は
その実現方法。つまり「参照」は仕様であり、「ポインタ」は実装である。
よく「Javaにはポインタがない」「いや、Javaの参照変数はポインタ
そのものだから、Javaにもポインタがある」という論争があるけど、
前者は「Javaの言語仕様にはポインタがない」ことを後者は「Javaの
実装にはポインタが使われている」ことをそれぞれ言っている。
つまり話の焦点がずれているため、両者の議論はかみ合うはずがない。
ただまあ、「NullPointerException」という名前はよくなかったな
912:デフォルトの名無しさん
05/12/17 02:11:13
もし NullPointerException を改名するとしたら何にするのがよい？
913:デフォルトの名無しさん
05/12/17 02:12:26
NullpoException
914:デフォルトの名無しさん
05/12/17 02:14:25
CantDereferenceException
915:デフォルトの名無しさん
05/12/17 02:31:26
燃料の質が悪かったか。精進します。
916:デフォルトの名無しさん
05/12/17 02:36:52
NullReferenceException
URLﾘﾝｸ(www.microsoft.com)
917:デフォルトの名無しさん
05/12/17 03:54:34
で、そのポインタ論争がこのスレと何の関係があるんですか
マ板のぬるぽスレでも行って騒いでなさい
918:デフォルトの名無しさん
05/12/17 03:56:44
ポインタについては、このスレで議論することですか？
919:デフォルトの名無しさん
05/12/17 05:44:46
このスレで議論することは何ですか？
920:デフォルトの名無しさん
05/12/17 05:49:30
質(略)
921:デフォルトの名無しさん
05/12/17 05:50:09
次スレの準備かな。
922:デフォルトの名無しさん
05/12/17 05:51:33
まだ早いよ
923:デフォルトの名無しさん
05/12/17 05:53:08
元々クロージャの話だったからそれをギロンすればいい
924:デフォルトの名無しさん
05/12/17 06:00:54
じゃ、まずはおまいからギロンを始めてくれ。
925:デフォルトの名無しさん
05/12/17 10:10:43
ぎろーん
926:デフォルトの名無しさん
05/12/17 10:47:16
ポインタなどという用語を不用意に使うような糞言語は捨てですね
何も反省していないということがわかる
やっぱりLISPですね
927:デフォルトの名無しさん
05/12/17 11:01:35
昔の言語だったらしょうがないけど、今時ポインタという用語使う言語の方が珍しい。
928:デフォルトの名無しさん
05/12/17 12:15:13
>>911
>「ポインタ」は実装である。
これの一次情報ってどこなんだろう？
少なくともCの仕様書ではそうなってない。
言語はC言語で実装することが多いので、
参照を表すのにポインタが直接使えるだの使えないだのという話はするけど。
929:デフォルトの名無しさん
05/12/17 13:02:20
ポインタはCでは仕様、Javaでは実装ってことじゃね？
930:デフォルトの名無しさん
05/12/17 18:08:17
>>926
Emacs Lispのリファレンスマニュアルだと、全編を通じて
「ポインタ」という用語を使っているわけだが w
URLﾘﾝｸ(www.fan.gr.jp)
931:930
05/12/17 18:14:58
ごめん、URLはこっちとかの方が適切だね。
URLﾘﾝｸ(www.fan.gr.jp)
932:デフォルトの名無しさん
05/12/17 19:30:44
まあｃより古い言語なんだし、その辺は仕方ないんじゃない？
lispのポインタは今でいう参照だな。
933:デフォルトの名無しさん
05/12/17 21:10:48
だから、lispはポインタ無いって何度いえば（ry
934:デフォルトの名無しさん
05/12/17 21:23:52
もういいよ、その話題は。
935:デフォルトの名無しさん
05/12/18 00:32:13
だから、rubyはポインタ（ry
936:デフォルトの名無しさん
05/12/18 00:52:22
さて、そろそろ次スレの準備かな。
立てたい奴、テンプレのリンク切れてるのチェックしてきてくれよ。
937:デフォルトの名無しさん
05/12/18 07:04:06
4年前の発掘
URLﾘﾝｸ(pc.2ch.net)
938:デフォルトの名無しさん
05/12/18 23:03:22
コンパイラ作る人は、「デバッガ」を、どのくらい「親切モード」に
搭載しているんだろう。手取り足取りでは作る手間かかりすぎるし、素っ気
なさ過ぎると、それはそれで文句言う奴も出てくるはず。
939:デフォルトの名無しさん
05/12/19 18:04:56
コンパイラヤサンは、でばっがやさんとは捌
940:デフォルトの名無しさん
05/12/19 22:11:29
938が誰に何を聞きたいんだかさっぱりわからんのだが。
(VC++とかgccとかの)広く使われている処理系について、どのくらい親切な
デバッガが搭載されてるか、なんてことなら、938の使ってる処理系についてなら、
938自身がよく知ってることだろう。
そうじゃなくて、
「コンパイラを作るとき、デバッガをどの程度意識して作るものなのか。
コンパイラ屋さんはたいして意識せず、デバッガ屋さんががんばるものなのか、
それともコンパイラ作る段階で相当意識するものなのか。」
という疑問であるとか、
「なあみんな、処理系作るときどれくらいデバッガ意識してる?」
という問いかけであるのならわかるんだけど。
941:デフォルトの名無しさん
05/12/19 23:56:40
SmalltalkやObjectCの話を聞いたときには、「そのうちプログラムも部品化・汎用化されて
CADのように配置して、入出力を線で結んで作るようになるんだろうなぁ」とか
思ったんですが、
なんでエディタで変数名をマウスで触ると宣言が出てきたりとか、コード補完してくれるとか
そっちへ行ってしまったのだろうか。
キーボードの呪い？
942:デフォルトの名無しさん
05/12/20 00:08:13
>>941
CAD方式のほうがめんどくさいことがわかったからだ
943:デフォルトの名無しさん
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
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。