型なし言語逝ってよし

Perl, JavaScript もろもろ型のはっきりしない言語は逝ってよし

###########このスレ終了###########

もうちょい使ってから言え。
###########このスレ終了###########

せめてなんで逝って良いかいってみれ。

>>1
ごめんな。

>>1 形無しだね（ﾜﾗ

音無です。

門外漢なんだけどLispって形無し言語？

(yesp)

型なしだと見つけにくいバグの元になるし、
型ありだと、コンパイルの段階で確実に発見できる誤りが多く
なる。

('yes)

hoge

型なしのデメリットと型ありのメリットを認識していることはわかた。
型なしのメリットをあげてみれ。

>>9
>>11
t か nil で答えれ。

JavaScriptとか、型が無いからわざわざ変換する必要がなくて、
さくっと何かくだらないもの書くにはいいね。

そうそうコンパイルもしないような言語で型があっても
中途半端に使いづらいだけ。

配列の添え字に文字をつかってみたり(藁
こんなかんじ
a["abc"]++;

Lispは型ありだろ。「強く型付けされて」はいないけど、
型は間違いなく存在する。潜在的な型というんだっけか?
型は変数とではなく値と結びつけられているんだよ。

「型があってそれを破るのが型破り。
型がないのは型無しっていうんだよ。」
って歌舞伎の偉い人が言ってたな。関係ないけど。

>>19
その論理から言えば、 Variant こそ型破りだな

形無し言語は初心者がとっつきやすい。
でもそんなとっつきやすさはいらない。
従って1に同意。

「耳なし法師逝ってよし」に見えた。鬱だ。

型なしっていうと、アセンブリ言語も含むのかな?

型変換がめんどくさいとか言ってる人は、
よっぽどキー入力が遅いんだね。（藁

型って、テンプレートのこと？　(^-^;

>>24
何を入力すべきか判断するにはもっと時間がかかるのでは？

実際の所、暗黙の型変換が便利だと思ったのは、
数値→数値と、数値→文字列ぐらいなもんだから、
型無しにする必要なんて全く無いと思う。

型なし（に近い）ので代表的なのは、PerlとRubyだよな？
後他にあったっけ？
Pythonはっどち？

豚=(デブ)なっち;

>>28
awk

>28
Pythonも形無しに近い、ここらへんの動的なオブジェクト指向言語は(Smalltalkとか)
簡便化以上の理由があってやってるように思えるけどね。

>>31
Smalltalkが簡便化のために動的に？
そんなわけはないです

Smalltalkって型無いの？

>>32
ﾊｧ?(ﾟДﾟ)y─┛~~
説明して見ろよ。んぁ？

型無し言語わかりずらい

>32
あ、書き方悪かったかな？もちろんそのとおり。上のほうで形無しのメリットが
初心者がとっつき易いとか書いてあったから、それだけじゃないんじゃない？
って言いたかった。

＞34
なんで？動的に型定義を変更するためじゃん。ポリモルフィズムとか
より柔軟に行えるよ。

型がないというのはオブジェクト・インスタンスの参照を保持する変数が
一種類しかない・型を区別する必要がない、ということ。
オブジェクト自身は特定の型・クラスから生成される。
ってことでいいのかな。

＞38サンの言うとおりですです。

型なし言語は開発環境の支援が受けにくいから
開発環境が貧弱で古くさくて進歩の止まってる
UNIXでしか流行らないでしょ(藁

JScript?

本来ホブジェクト指向は
形無し、動的（ガベージコレクション、インタープリタ）
のほうが実装に向いている

で、なんで、型なしだと、便利なの？
なんで動的オブジェクト指向に向いてるの？

>>43

>>37-38を読め。

コンパイル時には型あり、インタープリタ時には型なしなどと、
状況に応じて使い分けられる言語があればよいのかな？
それでいて尚且つコンパイルされれば高速で動作する。
そういうのあるのかな？ ないならば設計可能だろうか？

>コンパイル時には型あり、
この時点ですでに型あり言語になっちゃってるよ。
型なしはコンパイル時というか実行直前には型を決定できない。

コンパイラと同等のチェックはunitで行える。

「型なし」って何を指すんだろ。

Ruby だと変数に型は無いけど、データには型があるよ。
1 + "1" はエラー。

>>45
N88-BASICはどうか。
普通の変数名(HOGEとか)は型なしだが
HOGE$だと文字列 HOGE%で整数 HOGE!が浮動小数点と
型を意識することもできる。

個人的には型がどうこうよりも宣言なしに変数を使える言語が嫌だが。

それは形無しとはいわない。

型無し言語は、簡単に言えば
整数も浮動小数点数も文字列もポインタもオブジェクトも
全部一つの型だけですませてしまう言語。

省略設楽単精度でした。
逝ってきます。

型チェックをしない理由

１.　初学者のため。
２.　型チェックがウザいから（昔Pascalが嫌われた理由）
３.　C++のtemplateやAdaのgenericのような、複数の型について汎用性のある機能を実現する際に、
　　　型チェック有りだと、C++やAdaのように複雑な機構と文法を導入しなければならないが、
　　　型チェックなしなら、そのような面倒な一切ない。Smalltalkが好例。

４．予測できない。
ネットワークからのダウンロードなどで
未知のモジュールと動的リンクする場合、
タグつきの変数などが必要。
悪口を書くと、安定動作するかどうかも
予測できない。

52には同意だけど、53は不同意

JavaのVectorなんかのようなコンテナ系を見ていると、
いちいちキャストがうざい。
変数に型がないのは利点も多いと思う。

自分の低脳を理屈で正論化させるなっつーの。
型チェックが甘いことでいいことなんかあるわけねーだろ
開発者側の勝手を堂々とほざくな

>>53
　そういった大きな機能に focus するなら、変数に型があるか
どうかよりも、「型」そのものが first class object かどうか、
reflection が可能かどうかといったような、言語(＋実行時環境)の
機能的な側面の影響の方が大きいと思う。

>56
parameterized typeを使用にまぜろ、ってサンにいっとけ。

>>56
ちっさい見通しの聞くスクリプトに型なんていらないよ。

>>56の方が低脳に思えるが…

>>52

３番には意義あり。
タイプセーフのメリットの前には、その複雑さは対したペナルティではない。
大きなプロジェクトでは、構文の複雑さよりも、作ろうとするものの複雑さが問題になる。
逆に形無し言語にとって、簡便さと引き換えに失ったタイプセーフのペナルティは大きい。
大規模なシステムの開発には使い物にならない。
Smalltalkが、あれだけ優れた言語でありながら普及しなかった理由は、
全く実用にならないから。言語として優れていても、道具として劣っている。

そして>>1に戻る。

>>62

実用にならないということはないですよ。

Cincomのホームページを見れば分かるけど
ハドソンの関連会社のプロバイダというのがあって、
そこではSmalltalkを採用することを決めたそうです。
また、そこにはNASDAの名前もあったので、
ああいう言語でもロケットを飛ばせるのか、すごいもんだと思いました。

でもチーム開発にはあまり向かないと聞きました。

Objective-Cのid型は？

アセンブラからCをやると、型変換がうざい。
（字を打つのが面倒くさいんじゃなくって、わざわざ宣言するのが）

言語の基本スタイル的には、
変数の長さ（メモリ使用範囲と言い換え可）があり、
その後、ユーザーが必要であれば型を指定すべきじゃないのだろうか

>>63
Smalltalkで開発しようとした・開発されたシステムはそれほど珍しくない。
しかし、継続して Smalltalk が使われることは少ない。
Smalltalk で作りかけたものを捨てて VB で作り直したという話もある。
それはなぜか？
使ってみれば代わる。
実用にはならないけど、夢を見させてくれる。
Smalltalkは人を惑わせる魅惑の言語だ。
JavaもC++も不完全な言語だけど、実用性ではSmalltalkよりずっと上。

代わる→判る

>>65
メモリ参照のバグを取ることに比べたら、
型変換の手間のほうがずっと楽だよ。
コンパイラがバグを取ってくれるんだから、
利用しないとソンソン。

型がない言語なぞクソとか言う人間は
goto使ったプログラムは全部だめとか
GUI以外はすべてだめとか
CUI以外はすべてだめなど
思考停止している低能厨房と同類
よって >>1 が逝ってよし

型あり->大規模向き
型なし->小規模向き
ってことかな？
Perl, Python, Rubyとかで
大規模なプロジェクトを成功させた実例ってあるのかな？
特にオープンソースもので。

bioperlは、、ちょっと意味合いが違うかもね。

型が無いと言う点で致命的に大きなマイナスなんだから、
型がないのに良い言語になるわけが無い。

>>70

ないんじゃないの?多分。
PHPならある程度あるだろーけど。

# PHPも、一見型あるけど実際は無いに等しいよな。

>>70
objective-Cはid型だと事実上型無しだけど
CocoaやWebObjectのようなフレームワークも存在する。

めちゃくちゃ苦労すれば劣った言語でも、大規模な物を
作ることはできるだろう。
しかし問題は、それがどの程度やりやすいかということ。
それがおのずと数に表れてくる。

>>70

Cecilという言語のHPみたら
探索的な（Smalltalkのような）プログラミングと
生産的なプログラミングの両方をサポートする
と書いてありましたよ。
型ありのオブジェクトベース言語とかいうものだそうです

言語に総合的な優劣をつけようとするのは厨房の証明
言語なぞただの道具だから、適正があるだけ。

(変数の：Objectのじゃなくて)型チェックって、
プログラムの中に無数にある「守らないとならんこと」のうちの
1つに過ぎないって感じがするなぁ。だから変数の型くらい
無くなってもあんまり痛くない。
型どころか手続き呼び出しの引数の数さえ形式的に押えられない言語
(Forth系とか)すら有るわけで。

ProC(笑)で、DBのテーブルの構造に「ぴったり」合わせた構造体を
ちまちまちまちま作るウザッタさを思うと、実行時に機械が
合わせてくれるほうがずっとマシ。

変数の型の信者な人でも、C++みたいな境地までいくと
型ゆえに却って面倒だ、と思ったり、しませんか？
少なくともC++は絶対やりすぎだと思う。
型のコンパイル時解釈の迷路(=選択肢が無数に有る中から
正しいものを選ばないとならない)に、自分ではまってるんだもん。
コンパイルが遅いったらありゃしない。

Objectに型があれば、変なことしたら実行時に
例外で蹴ってくれるし。
逆に値のほうの型がふらふらな言語は
使ってて恐いなあ。C++も。


あと、対立ってものでもないぞ、という意見もありそうだし。
javaやdelphiくらいの「中くらいの」言語も有るわけで。

LISPやSchemeは変数（束縛されたシンボル）に型は無いけどデータ型はある。
関数定義もデータ型とみなす事ができる。
変数に格納されたデータ型を判定するには(〜p 変数) (〜? 変数)などの述語が使える。
よって型の特定が必要な時にこれらの述語を適切に使用すれば実行時エラーは発生しない。
（コンパイラを持つ処理系ではこれらの型情報を使用して最適化されたコードを出力する可能性がある。）
結局、型を特定しない限り安全なプログラムにはならない。
で、あってる？>LISP/Scheme使いの人

>>78
実行してみるまで型が合っているか分からない、ってのが致命的なんでしょうが。
コンパイル時に型間違いといった初歩的なミスを検出できるってのが大事です。
型が違うって例外を吐くようなプログラムが使い物になると思いますか？

それからdelphiが「中ぐらいの言語」ってどういう意味？ Delphi は Pascal 言語が
元なので型チェックは厳しいんだが。

>型のコンパイル時解釈の迷路(=選択肢が無数に有る中から
>正しいものを選ばないとならない)に、自分ではまってるんだもん。

それはあなたの勉強不足＆プログラム構造を把握していないだけ。

>>77
同意。厨房が多いのは春だから？

>それからdelphiが「中ぐらいの言語」ってどういう意味？

PascalとOOPは元々あんまり反りが合わないんじゃないかと
思うのは俺の勝手とはいえ、そう思いませんか？

RTTIなんか使える言語を、型がちがちなだけの言語とは
呼べないように思うです。クラス違い(親子兄弟でもなく)でも
同名プロパティをつつけますから。
＃ん？まぁキャストと同じとも言えるけどさ…

>勉強不足＆プログラム構造を把握していないだけ。

せめてtempleteはGenericJavaくらいまで簡素なものにしたほうが
よいと思うです。

あとこのスレとは関係ないけど、Objectを変数に埋めこめるのも
OOP言語として見れば致命的だよなC++。使いにくいったらありゃせん。

「自分ではまってる」ってのは、それゆえコンパイル遅いべや、
という意味でして。コンパイラが請け負うべき仕事が多すぎ。

あ。あと、TClassの存在も、
delphiを「少し柔らかい」と呼ぶ論拠だったりします。
ちょっと変則的だけどメタクラスもどき。

あれ？C++って今でも、Class(Instanceじゃなく)を
変数に代入したりできないよねえ？
Class(Instanceじゃなく)メソッドの多態も無いよねえ？

>「自分ではまってる」ってのは、それゆえコンパイル遅いべや、
>という意味でして。コンパイラが請け負うべき仕事が多すぎ。

あ、そういう意味でしたか。すみません。

>RTTIなんか使える言語を、型がちがちなだけの言語とは
>呼べないように思うです。クラス違い(親子兄弟でもなく)でも
>同名プロパティをつつけますから。

んー。RTTI情報でプロパティを触るためには、RTTIアクセス関数を使った
プログラムを組まないといけないですよ。RTTI情報をコンパイラが勝手に
使ってプロパティに自由に触れるってことは無いです。

RTTIを使わないでプロパティに触るには、前もって宣言されていることが
必要なので型チェックの厳しさは元祖Pascalとあまり変わりないです。

>＃ん？まぁキャストと同じとも言えるけどさ…

蛇足ですが、キャストと同じではありません。

Perl6では型宣言できるように（ただし義務ではない）なるらしいですね。

interface A{x();y()};
class N : A;
class M : A;

A a;
a = Creator.FactoryMethod();
a.x();

というプログラムがあったとして、別の所で使われていた、
interface B{x();z();}
class P : B;
class Q : B;

というインターフェースBもこのファクトリーからでてくるようにしたい場合、
型があると、BとAの共通部分のインターフェースを作らなきゃいけない、
と思うのだが。それをCとした場合、interface Aとかいてる所を
interface Cと書き直さなきゃいけなかったり、いろいろあると思う。
型が無ければCreatorの中を直せばいいだけ。
これがいいか悪いかは使う人の好みの問題だと思うが？
少なくとも利点が誰にも無い、という事はないと思う。

>86
なるほど。そーゆーのは経験したことあるなぁ。

＃ C#な人なんでしゅね・・。

A しか利用してはならない関数やコンテナで困る。

ある A 用のコンテナの中に間違って B を登録すると、致命的なバグを引き起こすことが判っている。
しかし別のコンテナの中には B を登録したい。
A 用のコンテナと B 用のコンテナは、扱うデータが違うだけで、
ルーチンは全く同じだから共有したい。
規模が大きく、同じ物を２つ作るようなことは避けたい。

こういうとき、C++ ならテンプレートで、型安全と、ソースの汎用性を共存できる。
型のないクラスや、Java のような言語では静的なチェックができない。

AnyContainer<A> con_a;
AnyContainer<B> con_b;

con_a.push_back(A());
con_b.push_back(B());
con_a.push_back(B());//コンパイルエラー

ま、形無し言語擁護派のほとんどは、大規模なソフトウェア開発に
従事したことが無いんだから仕方がねぇよ。
学生か、研究所を出たことがないか、cgiくらいしか作ったことのない奴だろう。
あるいは、一人だけで作ってるのかもな。

そういう小さなプロジェクトなら、形無し言語の簡易性が優れて見えるんだろうが、
中規模以上のプロジェクトになると言語の問題よりも、仕様の把握ミスとか、
連携ミスとか、ドキュメントの準備不足とか、そういうところが問題になってくる。
下請けの会社が、こちらのライブラリを、意図したどおりに使ってくれるとは限らない。
むしろ予想外の使い方をされることが多い。
またテスト・デバッグにかかる時間も長期に及ぶから、言語のデバッグのしやすさが
コストに直接響いてくる。

従って、形無し言語は逝ってよし。
いくらスマートで簡便でも、デバッグに時間がかかる言語は要らない。

>>89

なるほど、説得力がありますね。
でも「いってよし」というほどではない。

逝って良しと言うほどのことだと思う。
それに、見つけにくいバグ程嫌なものは無い。

ん？つまり用途によって使い分けよう、じゃないのか？

>>92
それ言うと終了しちゃうじゃないか。ほんとに。

ML みたいに勝手に型を推測して欲しいね。C++ には。

GJ使えよ

＞89
ちょいはずれますが、.NETで言語の枠がなくなるという意見があります。
この場合下請けの人は同じ言語で開発する必要が無くなり、それを実行した場合
デバッグは不可能に近くなります。そう考えると.NETの言語を選ばない
という機能も逝ってよしなんでしょうか。それとも設計、テストにさらに
重要性をおく事で避けうるのでしょうか。

>>89 の発言を論理的に整理すると、
「デバッグ効率の悪い言語は逝ってよし」であって、
「型無し言語逝ってよし」ではないわな。
そこの論理の飛躍に難ありだね。
なお、私は型無し言語を擁護したいわけではない。
私は型無し言語は好まない。

>>86 さんの意見も、型無しの方が面倒な手順を省略できるって論ですよね。
型無しの便利さはそれしかないんでしょうか？

そもそも、型が作られた理由は何でしょう？
（この辺の話は板違いかもしれません）

機械語を人間にわかりやすくしていったのがプログラム言語と思えば、
型があるのが極めて自然だから… ＞ 型が作られた理由

逆にOOPを突き詰めていけば型が無い方が自然に思えるんだけれど。
オブジェクトは基本的に任意のメッセージを受け取れて（任意の操作の対象となり得て）、
それに反応するかどうかはオブジェクトの内部実装次第、ってなってるべき。

現状でデバグが激しく面倒なのは同意。>>89
が、その辺は徹底的に形なし思考なプログラム構成を考えてけば、また別の結論にならんかな。

そうか・・・現状では、
特定のメッセージを受け取れるかどうかをチェックすることを、
型チェックで代替しているという見方もできるわけですね。

>>98
おーい。型が「機械にとって」自然なのか？それは初耳かも。
変数の「中」つまりビットパターンの使い方という意味では
たとえば整数とFloatはプロセッサによる取扱われかたが全然違うんで
たしかに機械にとって自然だが、変数の「外」つまり
複数の型を組み合わせる(構造体とかObjectとか)場合には、
単にメモリ上のどのアドレスにどの値を置くか？の違い
でしかないんだから、これが機械との相性問題に発展するってのは
一般的な計算機ではあまり無いことなような気がするが。

構造体をダンプしたパターンをそのまま食わせられるように
設計されたハード(周辺機器とか画面とかかな)っていうなら
わかるが、そーいう場合の配置の「保証」を例えばCはしてくれないわけで、
そういう意味では(少なくともCの)型が機械には役立っていないと思うぞ。
特定コンパイラ実装の特定オプションという限定までつければ別だが、
そりゃそろそろ言語の「型」の議論をするのにしては範疇を越えてる。

>>52
>２.　型チェックがウザいから（昔Pascalが嫌われた理由）

Pascal「の」型チェックのやりかたがダサイ、
ということなんじゃないかなあ。

型にも色々ありそうなもので、つーかあるんだけど、
Pascal時代の「全ての型は互いに無関係」ってやり方だと
めちゃめちゃしんどいのな。
型同士の関連性ってのが使えると凄く楽になることがある。
それの1つの解決策がOOPでいう継承だわない。

ちなみに解決策を提示せずに逃げたのがC。尤もあの時代だと
CPU能力および言語研究進行度(ってのは嘘だな：研究者じゃなくて世間
(頭回転速くない人(笑)も一杯いるであろう集合)での認知度の問題か)
からして、しかたないことではあったろうけど。

>>98 >>99
>別の結論
うん。それが無いことはないんじゃないかと思う。
少なくとも無いと証明はされてない…のかな？＞識者よろしく

MLだかいう言語に型推論だかいう仕掛けが有ると小耳に挟んだけど
使い心地どうなんでしょうか？＆どれくらい「問題」を解決して
くれるんでしょうか？＞使ってる人

>>88
>ある A 用のコンテナの中に間違って B を登録すると、致命的なバグを引き起こすことが判っている。

いつも不思議に思うんだけどさ。
「間違って登録する」のを防ぐ「ために」型ってのがあるの？
コーディングするとき、色んな変数をあてずっぽう(笑)に
ソースのある個所に突っ込んでみて、
それでコンパイルエラー出ないかどうか？を以って、
その変数をソコに書いてヨイかどうか決定していたりするのか？(笑)

冗談はさておき。つまり変数(値じゃなく)に基づいて
書き間違いをチェックする、1つの手段ってわけだ。

ならば、型以外の色んな概念を使って(も)チェックできるように
なっていて欲しいもんだ。
とりあえずOOPだと、いやOOPじゃなくても
「同じ型の変数」なんて腐るほどたくさん作れるわけで、
それの書き間違いに対しては型チェックは無力なわけよ。
型のチェック「だけ」推挙されても困ってしまうと思う所以がソレ。

例えば。

どうせなら、型と双璧をなす(俺主観)、「ロール」も
チェック対象になるような言語が欲しいです。
ロールプレイングのロールね。つづりはRoleで良いんだっけ？
「役割」って訳されるみたい。
つまりこの変数は「どういう役目の」ものか？を
記述できる言語が欲しい。
たとえばCount RoleとSize RoleはたぶんどちらもInteger型なんだろうけど、
Countな変数を書くべきところにSizeな変数を書いたり(逆も)するのは
多分形式論的(意味論より前)に間違いなのだろうと思われる。
だから、直接書いたらコンパイルエラーになるようにすべき。

型「だけ」じゃ物事を一面的に捉えすぎ。
型と違う(型概念と直交かどうか色々ありそうだが)概念も扱える、
つまり変数チェックの方法として型以外にも色々なものを
(形式的に)扱える、そんな言語が欲しいかも。

＃あ。ここでいってる話は、変数だけじゃなくてObjectにも当てはまると思う。

>どうせなら、型と双璧をなす(俺主観)、「ロール」も
>チェック対象になるような言語が欲しいです。
俺もこれ考えたことある。

でも役割って型=クラスそのものじゃないの？
class Size < Integer
class Count < Integer
とかって型をひたすら細分化してけばいいわけじゃん。

実際にこれをやらないのは単にSizeとIntegerに機能的な違いがないので
手を抜いてそのままIntegerを使ってるというだけで、
クラスを使ってSizeの役割が表現できないということではないと思う。

型＝クラスにしてしまったのはC++だけでしょう？そんなことない？

>型＝クラスにしてしまったのはC++だけでしょう？
意味わからん。
C++のintやtypedef int Sizeって型だけどクラスじゃないよ？

>>100
> 複数の型を組み合わせる(構造体とかObjectとか)場合には、
> 単にメモリ上のどのアドレスにどの値を置くか？の違い
> でしかないんだから、

うにゃー。↑俺が言いたかったのはまさしくここの違いの話でして。
要するに別種の構造体なら、扱い方（＞メモリに値を置く置き方）を
変えなきゃいけないわけだろ？プログラム内のどの場所においても
変数の種類に応じて扱い方を変える、っていうのが要するに「型」じゃないか？

ごみん、逆。クラス＝型に訂正>>105

>>106
>変数の種類に応じて扱い方を変える、っていうのが要するに「型」じゃないか？

細かい話だけどここが肝なんで。

たとえば型弱い言語のうちの幾つかでは、
「変数じゃなくて値」に「型」をつけてるわけですわ。
型とはなにか？と問われたときに、「変数」という単語が
必ずデフォで出るとは限らない、ってのが、ね。

>>103
>でも役割って型=クラスそのものじゃないの？

うーん。少なくともそう言いきれる理由を俺は知らない。
なんか決定的な理由が有りますか？
反例は…有ったようなきもするけど思い出せない(うつ
従属なんかどうか全然自信ないです。誰か答え知らない？

役割とクラスは、概念的(ぉ)には違うと思うです。
そういやロープレの紙(みようみまねで1回やったことが
あるだけなんでアヤフヤ御免)にClassって欄があったなあ(^^;。
種族って訳すんだっけか。
種族は人とか魔物とか。一方ロールは坊主とか盗人とか。
つまりそういう差だよね、クラスとロールは。

…もしかしてClassと違ってRoleは、動的に着脱できる必要があるかも知れない…
つまり「変数宣言」なんていう呑気なことを言ってられないかも、という。
Classは一度作ったら変化しない(例外はあるが)んで
宣言とかすれば話は解決するんだけど。

>>108
比喩はあくまで比喩に過ぎないので、もう少し具体的
な「役割」の定義を希望します。

どうも「インスタンスの振る舞いなら」に近いことを
考えているように見えますが、それだとクラスと変わ
らない。

>>109
うーん困ったな。俺も全然詰められてないもんでして。
型以外のなんかが有るってのは直感的(笑)には判るんだけど。
＃でも、人と坊主で、説明って足りるんじゃないかなあ？

まぁRoleそのもの(だけ)について言ってもしょーがないんで、
さっき書いたのの延長で、たとえば「着脱可能な、
型と似てるけど別なもの」っていう仕掛けが
有るとしたらどんな使い心地かな？とか考えてみるテスト。

振る舞いを変えさせる必要はないかも知れませんよ。
たとえば振る舞い「を許可」するかどうかを変えるとかね。
アクセス属性「の集合(メソッドごとに属性が付いてるんで、
それらの集合ね)」を一撃で切り替えるとか。
Roleを職能とか権限とか訳すこともあるようだし。
で着脱可能だとすると、場合に応じてRoleをとっかえることで
どのメソッドを使えるか？が変化する。

うむ。また変な案。
「変数には」Roleをつけ、「Objectには」Classをつけたら
どうかなあ？
Objectが生まれながら持ってる能力はClassで記述し、
それを実地でどう使う(使わせてもらえる)かは
変数が決める、っていう。
つまりどの変数を介してアクセスされるか？で
使ってよいメソッドが変化するっていう。
だめ？

なるほどね。今でもカウンタ変数に触ると警告を出すコンパイラ
があるけど、それを拡張したみたいなもんか。つめればいいかも。

型付けの強い言語が好まれる理由は、
それが自然だからではなくて、単に有益だからだよ。
型が違う変数同士の演算は、間違いである可能性が非常に高いわけ。
これは事実だと思う。

>112
演算だけの問題か？

型無しの善悪は、その言語の能力とのバランスで考える必要があると思う。

データベースアプリケーションで「削除」ボタンに「よろしいですか？」
の確認メッセージがあるのに対して、「閲覧」ボタンにはそれが無い。

作業を簡便化するだけならば、削除確認メッセージなどウザいだけだが、
これが無いアプリケーションは不安で使ってられない。
間違えて削除ボタンを押してしまった時、取り返しがつかないからだ。
UNDOがあったとしても、そもそも削除ボタンを押したことにその場で
気が付かないかもしれない。

もちろんこれも場合によるが。

それと同じで、言語の「型」というものは、確認メッセージのようなものだ。
記述を間違え、それにその場で気が付かなかった場合、どれぐらいの損失があるのか？
その損失と、型宣言をする労力を比較した場合、どっちを取るべきか？

個人的には、現在ちまたにあふれている一般的なプログラミング言語は、全て型付
けの必要があると思う。
上の例で言えば、全ての言語が「閲覧」以上の機能を持っている。

型無しで書いていいのは、絶対に記述を間違わない人間か、間違ったとしてもたい
した問題を起こさない言語においてのみ許される・・・と思う。

>>114
同意。
形無し言語派の主張は、間違いは後で訂正できる
（実行時にチェックできる）というものだけど、
それは人間が実行時にチェックをするように仕組
まないといけないという時点で、弱い。

機械が自動的にチェックを入れてくれるなら
そのほうがずっと楽に決まっている。

目先の手間にとらわれているようだけど、コーディング
の手間よりもデバッグの手間を軽減してくれるほうが嬉しい。
テスト期間＞設計期間＞コーディング期間。
コーディングの手間なんかにはたいしたコストはかからない。

>>115

ええと。弱型ゲンゴでも、例外あげてくれたりはする
という意味では「機械が自動的にチェック」ではあるんですけど。

値(Object)の型が、勝手に変化するタイプの言語
(awkとか。perlは全然知らないがコッチかな?)と
そうじゃなく例外あげる言語(rubyとか)が有るけど、
一応その差も考慮したほうがいいかも。

型以外の面は結局別の手段チェックしないとならんわけで、
「事前チェック項目が1つ多いか否か」の差でしかない
とやっぱり感じるです。勿論多いほうが良いかもではあるが。

ところで弱型は駄目だと思う人って、
やっぱりOOPの多態も嫌いなんだろうか？
同じじゃないけど少し近いじゃん。
C++は多態嫌いな人が作った言語なんだろうなと
いう気は凄くするけど。

機械があげる例外を漏れなくテストで拾い上げるのが大変なんだろうが。
テスト期間の短縮が目的だといっているのに、それでは意味が無い。
指数関数的に増える組み合わせのパターンによる不具合が、
機械的に漏れなく全部出力されないと困る。

OOPの多態が嫌いってのは論外。
多態ができなきゃOOPなんて成り立たないし。
もし嫌いなら、なんでテンプレートが多態と組み合わせると
おいしいのか説明できない。

型付けの強いOO言語
・大規模向き(型宣言・キャストのタイプのコストが相対的に小さい)
・コンパイル時にチェック可能
・高速(実行時のチェックが少ない。通常コンパイラ)
・統合開発環境と相性が良い

型付けの弱いOO言語
・小規模向き(型宣言・キャストのタイプのコストが相対的に大きい)
・実行時にチェック可能(小規模であればコンパイル時のチェックのメリットが少ない)
・低速(実行時にチェックすべきことが多い。通常インタプリタ)
・UnitTestにより事前チェックが可能
・統合開発環境と相性が悪い
・OOLとしての機能が柔軟で豊富

>>118
・OOLとしての機能が柔軟で豊富 < このへん詳しく知りたい。
UnitTest とかいってる所を見ると Ruby な人と想像するけど、
型付けの弱さとオブジェクト指向言語として機能の関連性を
説明してほしいです。(多態が片付けの弱さと関係あるってことかしら

>>118
Smalltalk（やSELF）は型付けが弱く、かつ完全な統合開発環境を持っているので、
「相性が悪く」はないはずです。

Cecilというわりと新しいＯＯ言語は、動的な型付けと静的な型チェックを
両方兼ね備えた言語らしいです。知っている方います？

>>110
それはまんまポリモーフィズムでは？
変数の型がクラスで、実行時の本当の型がロール。

>>117
>機械があげる例外を漏れなくテストで拾い上げるのが大変なんだろうが。

うん。最初からそう(=正しく)書こうよ。

>指数関数的に増える組み合わせ

ところでXPでいうUnitTestって
まさに指数問題に対する挑戦だと思うんですが。
「Unit」ってところが味噌ね。指数的組み合わせを
行う前にやるテストなのが味噌。
で、型レベルの間違いは「Unit」テストで挙がるよね。
挙がらなかったらそれは使われない機能だから無視
なのだから。XPでは(笑)。

…あ。118の人が既に書いてる。

>なんでテンプレートが多態と組み合わせると
>おいしいのか説明できない。

え？おいしいっすか？
相補的な存在っていうか、片方が出来ないことを
もう片方でやれるって感じはするけど、
2粒で3倍美味しい相乗効果だと思ったことは無いなぁ。

>>121
>変数の型がクラスで、実行時の本当の型がロール。

違うと思う。
その解釈だとたとえば、「長さ」と「重さ」の入れ違いを
コンパイル時に刎ねられないので。

あ。でもそれ以前に俺の案が全然変だな。捨てます。

>>UnitTest とかいってる所を見ると Ruby な人

蛇足ですけど…UnitTestからRubyへの連想って、ちょっと…
本家はJavaでしたっけか。

それはさておき。デザイン「パターン」をしばしば
単なるライブラリにおとしめる(笑)ことが出来るのは
たしかに弱型の「メリット」だとは思います。
FactoryなんてClassが変数に代入可能なら
ごたいそうなコーディングは不要だもんね。
概念の普遍性は残るけど。

>>120
>「相性が悪く」はないはずです。

うい。むしろ弱型のほうが相性よいと思う。
統合環境そのものを実装してるコードが
まるっきり未知のユーザー定義クラスを
扱えるのって、弱型の恩恵の1つ…だよね？
＃勿論色々迂回すれば弱型じゃなくて一見同じことは出来るが。

うーん。あれでdelphiにRTTI解決を勝手にしてくれる構文とかが
追加されたら、お洒落なんだろうな。

>122
>>>120
>>「相性が悪く」はないはずです。
>
>うい。むしろ弱型のほうが相性よいと思う。
型なし言語の統合開発環境って
n．
と打ったときにオブジェクトnのメソッドを列挙したり、
そのメソッドの引数のヒントを表示するってことは、
コーディング時にはできないんじゃない？
nの型がわからないから。
Smalltalkってできるの？

>>123
あ。そっちの話か。
うーん知らないです。
RubyでEmacs(例)な人教えてちょ。

Roleって考え方は面白いね。

>>102
| つまりこの変数は「どういう役目の」ものか？を
| 記述できる言語が欲しい。
| たとえばCount RoleとSize RoleはたぶんどちらもInteger型なんだろうけど、

ここなんだけど、Integer型から派生させたCountRole型とSizeRole型を
作ればいいんじゃないかな。例えばC++のint型は、対応するクラスを
持たないために派生させるということはできないが、JavaのInteger型
であればできる。つまり、RoleはClassで表現可能なのではないかな？

Uvaという言語は、Javaと同じく強い型付けを持つ言語だが、Javaの
プリミティブ型(intなど)にもクラスがあり、Objectを祖とするクラ
スツリーに収まっている。こういった言語であれば、内部的にはint
の実装を持つCountRole型のオブジェクトという表現ができる(土壌
がある)。ただし、使い勝手を考えるとInteger->CountRoleへの
暗黙の変換が欲しいところ。

>125
103が言ってる。

>>123
オブジェクトの型が分からない、ということはありません。
むしろ、全く正反対で、オブジェクトが自分自身のことをすべて知っていると考えられます。
C言語のソースで、変数の型を知っているのは、Emacsであって、変数nではありません。
Smalltalkでは
n class
として「print it」（結果を表示）すればnのクラス名が表示されますし、
n class inspect
とすればnのクラスについて調べることが出来ます。

>>127
それは実行時型情報ですよね？
>>123 は開発・コーディング時の話ですけど。

Uvaってまいなーだなー

誰かVisual StudioとSmalltalk両方使いこなしてる人いないの？

>>128
Smalltalkってインタプリンタで開発環境も含めての実行環境だから
問題ないのでは。

>>131
でも、コンパイル時と、インタプリタの実行時では全然違うと思うんだけど。

みんな、開発方法論とやらに洗脳されていない？
そんな方法論なんてつまらないし、やりたくないし、本当の意味で
開発効率があがるとは思えない。
ちょっとおりこうな人なら、スパイラル開発が一番だって知ってい
るはずだよね？
完全な設計なんて神様でない限り不可能だし、とりあえずプロトタ
イピングして、すこしづつパッチを当てて行く方が実は速いし、プ
ログラミングも楽しくなるってもんでしょ。
と言うわけで CommonLisp一番宣言。

はいはいスレ違い亡者はあっち逝ってね。

開発方法論とやらに洗脳されてるおばかさんをさらしage
　　　　　　　　　　　　　 ↓↓↓↓↓↓↓
>ちょっとおりこうな人なら、スパイラル開発が一番だって知ってい
るはずだよね？
>完全な設計なんて神様でない限り不可能だし、とりあえずプロトタ
イピングして、すこしづつパッチを当てて行く方が実は速いし、プ
ログラミングも楽しくなるってもんでしょ。

スパイラルな開発は、現在のオブジェクト指向開発ではメジャーな開発方法論ですな。

↓ここで「繰り返し開発」って書かれているのがそれ。
http://210.171.126.27/rational/ru/ru_detail.asp?CRS=510008462

これを知らないということはラショナル統一プロセスを知らないということで、
ラショナル統一プロセスを知らないということは UML を知らないということで、
UML を知らないということはオブジェクト指向設計を知らないということである。

133がオブジェクト指向の素人だということの証明終わり。

>>134
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ。

>>135
キミのすさまじい論理展開に乾杯。

スパイラルな開発って何よ？
そんなんアセンブラ時代からやってるよ（藁

元々｢型｣なんて無いんです。
単なる 0 と 1 の羅列…
それが現在のコンピュータ。

そこに何故｢型｣が導入されたのか？
その後、何故｢型無し言語｣が出てきたのか？

その辺を自分で考えられるようにならなきゃ
プログラマーなんてヤメたほうがイイです。

形無しｵﾌﾞｼﾞｪｸﾄは恐ろしい。
何でも吸い込んでしまう。
ﾌﾗｯｸﾎｰﾙ夕″。

うひー

>>138
自分でって、最初から意見交換を否定してどうすんだよ。
オタクか？
オマエ、納品間際まで進捗報告一度もしないクチだろ。

>>141
考えた人とは意見を交換するのでは。
確かに考えない奴とは意見を交換したくないよな。

>>125
>ここなんだけど、Integer型から派生させたCountRole型とSizeRole型を
>作ればいいんじゃないかな。

少しは(笑)考えてみました。

で、まぁ現状のC++やJavaみたいな言語を前提として考えるとして、
Integer型とSizeRole型の
どっちを変数の型として
どっちをObjectの型とすべきか？ってのが、
実は困った問題になるんじゃないかなと。
＃変数と型の両方を同じClass/Roleにしてしまうのは無意味なのでパス。

変数がIntegerでObjectがSizeである場合、
代入とかのRole違いをコンパイルではねることが出来ないので駄目(前述)。

変数がRoleでObjectがIntegerである場合、
(C++/Java系つーか、Classを階層として管理する言語を使う限りは)
そもそも代入できない(笑)

てなわけでどっちも無理があるような気がするんです。

敢えて代案を考えるならば、
Javaでいうinterfaceで全部やっちゃう感じかも。
そうすりゃ一応、直交(階層とは無関係)に出来るだろうから。

Integerable、SizeRolable…

…それって、ちょっと悪趣味…

うーん。それとも
interface Sizable{
Integer getSize();
void setSize(Integer);
}
かな？

少なくともサブクラス関係は駄目だと思う。

>>139
ん？型なし「オブジェクト」の話って
今回それほど無かったような気がするけど？
型なし「変数」の話は散々出てるが。

変数だけに(強い)型付けがあって、値のほうには
「全然」無いっていう言語の話って、
たぶん考えてもあんまりメリット無いんじゃないかな…

ところでAWKは値の型が無しだと言って良いんでしょうか？
たしか値の型を非破壊に調べる方法がない言語だったと思ったけど。

>>131
>>132
実行時型情報…
Smalltalkではオブジェクトを宣言するというのは
生きているオブジェクトを作成するに等しいのです
Smalltalkには変数に静的な型というものはありませんので「実行時」
の型情報しかありません。Rubyとかも同じといえば同じ。
でもRubyとちがうのはSmalltalkは、より動的であることが自然である、オブジェクトが生きているということです。

ええと、確かこのあたりの議論は - interface で済ませてしまえ、
という原始的なものはともかく - lisp で関数の定義域と値域を
宣言的に記述することによってテストデータを半自動生成するとか、
そんな研究など結構語られていたような気が。20年くらい前かな。

そんでAdaなんかはここらのことに関する巨大な仕様を持ってたり
して、その辺を考えるとこの辺のナニソレはやりすぎると強力だが
人間にとって習得しにくい言語が出来てしまう恐れが...

結局>123の機能はSmalltalkにはあるの？

「ここらへん」ってのは143方向ね。

>>147
何を列挙すれば「123の機能」になるの？

>>145
そこまで言っちゃうと、ちょっと違うぞと思う。残念ではあるが。

Objectが「生きて」いるか？といえば
RubyだってSmalltalkと同じなハズだし。

あえていえば、(たしか出来るんだったよね)変数「を」
Objectとして色々生かしてしまえば、なにか変わった事が
出来る…のかも知れないけど。

「ソースは」Objectじゃないってのは、味噌だわな。
ソースとObjectは、残念ながらどうやっても
同じ「レベル」にはなれない。
両者の間には、 シンボルto値 の変換という溝があるだけ。
勿論パーサー(はObjectたりえる)もまたソースじゃないし。

てーかさ、ソースって、どうしようもねーよあれは。
「Objectになれない」という意味では、ね。
＃それ以外のデメリット(????)についてはとりあえずパス。
(テキストで書かれた)ソースってやつは、
少なくともObjectとは目茶目茶かけ離れている。

>Smalltalkではオブジェクトを宣言するというのは
>生きているオブジェクトを作成するに等しいのです

Smalltalkってオブジェクトを「宣言」なんてする
言語なのでしたっけか？細かいことは俺知らないんですが。
オブジェクトを「生成」するだけじゃないか？
＃真のOOP言語ならなおのこと。
そして我々がいじれるのはあくまで「ソース」だけ。
そしてソースはあくまでObjectの生成(操作)「手順」を書いてるだけ。
Objectそのものは結局触れていないよね。
あ。GUIでObjectをいじるかのようなソフトを組めば
むしろかなり生に近いけどさ。

OOPから見てテキストなソースが痛いのは、同一を同一と書けない点。
同一を同値(つまり同じ「単語」が再び出現する)で
代用して表現するしかない。
ついでにいえばそれの延長に存在するのが変数。
同一変数を表現するためにソース上で同値の文字列を再度書く
ことで代用している。
GUIだとさっきと同じ「もの」を掴む(ようなUIを作る)
ことでナントカなるんだけど。

＃というわけで、言語上のObjectとGUI部品とのMapが
＃オプションに過ぎないVC++のダイアログ編集機能は、却下(笑)

>>146

定義域と値域。俺も三日前に(笑)気付いて
結構頭抱えました。

そういやPascalにも
配列のところに簡単な定義域的概念があるんだっけ。
たしかに使ってて面倒になってきます(ぉ

あとMLとかいう言語の超入門を読み始めて、
やっぱりそういう概念が出て来たり。

>>150
かなりいい線の事言ってますね（←偉そう＜自分）
宣言ではなくて、生成でしょう。
Smalltalkはたしかにオブジェクトが見えるレベルまで
メタ的な環境ではないですが、まあ、オブジェクトの自主性、能動性という
意味ではかなり高いレベルまでいっているでしょう。
Rubyはそういうオブジェクトの自主性やメタプログラミングというよりは
スクリプト言語としての記述力を自然な形で高めるために使っている
という意味合いが強いと思います。

>Objectそのものは結局触れていないよね。
>あ。GUIでObjectをいじるかのようなソフトを組めば
>むしろかなり生に近いけどさ。
これってコンポーネントだかコントロールだかjava beansのことなんじゃないの？
Delphiのコンポーネントって設計中に既にインスタンスが生成されてて、
はじめてみたとき どびっくりしたよ。

>>153
そうか、じゃあSmalltalkとかいって粋がらなくても
Delphiでもそういう感覚の一端は味わえるのか

C++ Builderでも？

>>152
>意味合いが強いと
というか、現状の使われかたはさておき、
潜在能力(笑)は似たようなものなんじゃないかと。
決定的な違いを探すと、VM内のそれこそ生きたObjを
ホストOSのディスクにダンプする能力が洗練されてること
くらいかなーと。rubyのVMを明示的に作ろうとかいう話が
英語MLのほうで挙がっているってほんと？＃英語はちょっと…

>>153 >>154

あ。それ言えてると思います。
アレは半ばGUIのサポートのためだけに有る感じはするけど、
delphi/C+Bでは、一応そうでないObjectでもサポートしてる。
＃手掴みできるけどGUI系じゃない「TComponent」というクラスが有る。

おおマヂでインスタンス生成されるんですよねdelphi系って。
DBコンポが設計時にデータ見えるのもソレだし、
そもそもComponentに「今自分は設計環境に居るか？」
と問うメソッドが有る(笑)。だから状況(?)に応じて
むちゃくちゃ(良くも悪くも)な挙動をするObj(のClass)を作れる。

で、そのclassをIDEに「登録」すると使えるようになる。
IDEが未知のclassを操る(少なくともPropertyとかは
幾つ＆どんな型のが有ろうが、自由にアクセス出来ないとならん)
のにはRTTI使ってる。

＃で、生C++じゃそんなこと逆立ちしたってできねー(よね?)んで
＃C+Bはまず言語仕様をdelphi寄りにゆがめる(笑)ことから始まった。

>>119

OOPで良く言われるポリモーフィズムというのは要するに、異なるクラスのオブジェクトに対して同じメッセージを送るということである。

これを静的な型の無い(変数に型が無い)言語で行うのは至極簡単だ。変数が参照しているオブジェクトに対し普通にメッセージを送ってやるだけで良い。要はその変数が参照しているオブジェクトのクラスが異なる場合があるというだけの話なのだ。

静的な型のある言語では、まず異なるクラスのオブジェクトを同じ変数が参照するということが出来ない。静的な型の役割のひとつがそれなのだから当たり前の話だ。だがそれではポリモーフィズムが出来ないのでキャストという魔法を使用する。
あるクラスのオブジェクトの参照は、そのオブジェクトのスーパークラスの参照へキャストできる。この決まりを使うことによって、同じ変数が異なるクラスのオブジェクトの参照を保持することが出来るようになり、ポリモーフィズムが実現できるわけだ。

つまり、静的な型付けを行うことにより、キャストというある種の魔法が必要になってしまうというペナルティが発生するのである。
この問題はコレクションクラスを実装するときにも発生する。C++はテンプレートという仕組みを用意し、Javaはオブジェクトの共通の祖先であるObjectクラスのコレクションを用意することでしのいでる。しかしJavaではほぼ確実にサブクラス側へのキャストという禁忌されるキャストが必要になるので、あまり心象は良くない。

このように、静的な型を取り入れるとOOPは途端に複雑なものになってしまう。
以上、お分かりかな?

>>156
スーパークラスなの変数に
サブクラスなインスタンス(の参照)を
代入することを許す、という程度の規則緩和(笑)は、
流石に今時(いや昔から)の型強言語もやっているんで、
それはちょっと違うのでわ？

＃というわけで、そういうOO的に当たり前の仕掛けを阻害する、
＃C++の変数埋めこみインスタンスは、捨て捨て。

ただし、「必要になる」ってのが
「必要になる場合もある」の意味ならば、合ってるけど。

ところで、OSみたいなものを強型言語で記述しちゃうと、
少なくとも言語のOOPな機能をそのままアプリとの間で
共有できなくなっちゃわないか？
OSをコンパイルしたときに確定してしまうInterfaceしか
使えないので、まるっきり新しいInterfaceを追加したくなったら
OS本体がOpenSouceでないと不可能(笑)ということになりそう。

COMは弱型に属すると言っていい…のかな…？

>スーパークラスなの変数に
>サブクラスなインスタンス(の参照)を
>代入することを許す、という程度の規則緩和(笑)は、
>流石に今時(いや昔から)の型強言語もやっているんで、
>それはちょっと違うのでわ？

　明示的にせよ暗黙的にせよキャストしていることには変わらないと思うが、いかがなものだろうか。

>>156

>つまり、静的な型付けを行うことにより、キャストというある種の
> 魔法が必要になってしまうというペナルティが発生するのである。

どこがペナルティなんですか？

>どこがペナルティなんですか？

もしかしてキャスト大好き人間?

オブジェクトが受け取ったメッセージを処理できなかったときはどうするのよ？
静的な型の無い言語では、この点がペナルティとなるんだが。

静的な型の有る言語では実行前、つまりコンパイル時にチェックできる。

＞161
158-160でキャストの話してるのに、タイミング悪いっすよ。
その意見は結構上の方でみんな言ってるのではないでしょうか。
現状では正しいと思います。ただこれからもっとうまくやる言語
（開発環境）が出てくるような気がしますが。

>158
>>　明示的にせよ暗黙的にせよキャストしていることには変わらないと思うが、いかがなものだろうか。
これ↓は普通（暗黙の）キャストとは言わないし、特にペナルティもない。
>>スーパークラスなの変数に
>>サブクラスなインスタンス(の参照)を
>>代入することを許す、

静的な型付け言語が面倒になるのは
genericなコンテナクラスを作るときのみ。

いや、型チェック依存症の人間。テンプレートらぶらぶ :)

で、C++はSTLに走っちゃったんだよね。
俺はあんまり好きではない（といいつつ使ってるけど）。
内部はvoid*で処理して出入り口で型チェックするような
最小の仕掛けが欲しかった。

C#のコンテナはどうなってるんだろ？

>>158
あれはキャストって言わないよ。
キャストってのは型情報を「いったん捨てて勝手に別なのにすりかえる」
こったろ(なんか違うがまぁ

スーパークラスとかサブクラスとか使うアレは、
変換が許される型へ変換してるだけだから、いいの。

いや、変換ってのは嘘だな。
なんか世の中にはタイプ理論とかいうのが有るとか聞いた
(中身は全然知らぬ)が、それの教えるところによると、
サブクラス化とかいうのは、「1つのObjectや変数に
複数の型を同時に与えたもの」と解釈するのだそうだ。＃ほんと？
サブクラスな変数やObjectは、スーパークラスの型と
サブクラスの型を、同時に持ってると見なすっつー。

だからサブクラスなインスタンスをスーパークラスの変数に
代入するってのは、インスタンスのスーパークラスな面(だけ)を
今は採用しますよって言ってることになる。

>>165
>内部はvoid*で処理して出入り口で型チェックするような

それってGenericJavaに近くない？
チェックは静的だけど、「トランスレーターが」
チェックをするんであって生javacは関係ないから
C++よりもあっさり味のtempleteなのだとか。
＃ほんと？＞識者

アップキャストに何か問題があるの？
サブクラスはどうせスーパークラスのインターフェイス
持ってるんだから、別に何も問題起きないでしょ？

スーパークラスをテンポラリにしていとこクラスインス
タンスをやり取りするとか、そういう邪悪なことをしてる
のか？

アップキャストに問題があるわけではない。キャスト自体が、静的な型のある言語にとっては余り好ましくない存在のはずだ。そのなるべく使いたくないものを使わなければポリモーフィズムを行うことが出来ない、そこがある種のペナルティだといえるだろう。

変換可能だから、問題が起きないからあれはキャストではないというのはどうだろうか。
C言語においてchar*型のポインタをvoid*型の変数に代入した場合、これは暗黙的にキャストされ問題も起こらないが、これは間違いなくキャストが発生しているといえるはずだ。

> キャスト自体が、静的な型のある言語にとっては余り好ましくない存在のはずだ。

それはなぜですか？

>>168
深い意味があるのかと思ったけど、アップキャストに関して
「ペナルティがある」というのは単にプログラマの気分の問
題なんですね。じゃ、私は気にしないので問題ない :)

キャストといった場合、float と int の間の型変換のよう
にビットパターンを変更するものと、char * と int * の
変換のように、ビットパターン自体は変えずに型を再解釈す
るものの二通りがあります。（説明が C++ 寄りだけど、言
いたいことは分かるよね？）

私は型チェックらぶらぶな人ですが、前者の型変換は問題視
していません。可能な限り避けたいのは、後者の型再解釈の
キャスト。理由は、これを使うと型あり言語が提供する、コ
ンパイル時型チェック機能を実質的に無効化してしまうから
です。

アップキャストに関しては、たとえ使ったとしても、コンパ
イル時型チェックは依然として有効に機能する（たとえば存
在しないメソッドを呼び出すようなミスはコンパイラが弾い
てくれる）ので、使うに躊躇はしません。

人間が明示的にするキャストは問題無いよ。
問題はコンピュータが勝手にやってしまう暗黙のキャストだよ。

＞人間が明示的にするキャストは問題無いよ。
あんた何いってんの？

>>172

おれは優秀だからいーんだってことだろ（藁

>>170
アップキャストにペナルティがあるのではなくて、キャストを使用しなければならないということがペナルティであるということをご理解していただきたい。
何故キャストがペナルティであるかは、ご自身が述べている通り。

アップキャストは型再解釈型のキャストである。型再解釈型のキャストは避けたいという意志があるにも関わらず、アップキャストの使用は躊躇しないというのは矛盾しているように思える。これは明らかに欺瞞であろう。
もっとも、型あり言語でオブジェクト指向を成すためにはアップキャストは避けられない道なのだから、その使用を躊躇っていてはどうにもならない。必要悪の欺瞞と言えるわけだ。

なんか用語の認識間違ってないか？
ベースクラス(=スーパークラス)
アップキャスト：ベースクラス→サブクラス
ダウンキャスト：サブクラス→ベースクラス

それにアップキャストって型情報は失われない暗黙的な変換だから普通意識しないと思うんだけど。

>>175 の書き方だと誤解がありそうなんで、補足。

アップキャストは、派生クラスから派生元（基底）クラスへと
変換すること。C++ 風に書くと、こう。

class Base {}
class Deriv : public Base {}

Deriv objDeriv;
Base *pBase = &objDeriv;　/* アップキャスト */

クラス図を書くときに基底クラスを上に書くのが一般的だけど、
それに合わせてアップ・ダウンの方向も覚えておくのが良い。

>>175
例外として、C++ で実体を扱う場合には、コピーコンストラク
タに要注意ですね。

もっとも、一般にはオブジェクトといったら参照もしくはポイン
タを使います (Java のように、そもそも実体を使う方法がない
言語も多いし)。C++ でも、積極的に実体を使うのは具象クラス
ぐらい。

キャストって明示的な変換のことを言うんじゃないの？？

>>178
暗黙のキャストもキャストでしょう。

>>174 は、キャストの問題をちゃんと理解していないと思う。
型付言語のポリシーを理解していない。

コンパイラが正当だと判断したキャストにはエラーは出さない。
コンパイラが不当だと判断したキャストにはエラーを出す。
明示的なキャストは、コンパイラが不当だと判断したキャストでも
エラーを抑制してしまう。ここに問題がある。

つまり、キャストはすべてペナルティになるのではなく、
明示的なキャストがペナルティを生むんだよ。
>>170 の人が言っていることと同じような気がするけど、
ここを誤解されると話が進まないから、
安易に流し読みせず、よく考えてくれ。

そうは思わない。明示的でないキャストもかなりの問題を生じる。
なぜならば、「人間が気付かない所でキャストが起きる」からだ。
明示的ならば、キャストの起こっている個所は特定しやすいが、
明示的でない場合、バグの個所がわからない。

意味わからん。
蝿を昆虫として扱う事のデメリット・ペナルティを具体的に教えてくれ。
あるいはバグの発見が困難であるような具体的なコードを例示してくれ。
言語は問わないから。

>>181
例えば、

hoge=1;
hage="test";

となってるとする。print hageとやりたい所を
間違えて、print hogeとしてしまった時など。

>>182
hoge をプリントするのが正しいのか、
hage をプリントするのが正しいのかは、
人間でしか判断できないでしょう？

どちらのオブジェクトもそのメッセージを受け入れるんだから、
コンパイラが「そのオブジェクトにこのメッセージは送れない」
というエラーを出すわけが無い。

暗黙のキャストがエラーを出さないということは、
メッセージのインターフェイスに矛盾が無いということを保証するだけ。
メッセージそのものが正当かどうかまでは保証しないよ。
この保証の範囲を勘違いしてるんじゃないかな？

強型言語の話をしている人は、前者の保証のメリットと、
明示的キャストでこの保証をスポイルする危険性の話をしている。

182は、私たちが後者の保証までコンパイラに期待しているものと誤解しているよ。
後者の危険性は、確かに明示的であろうと暗黙であろうと危険。
でも強型言語ではこの点については考えられていないし、
型なし言語でも同じ。間違いの無いコードを書くか、実行時に自分で判断する以外に無い。

いや、でもね。
182のような例でエラーになってくれるとすぐバグが発見できる
のに対し、エラーにならない場合は、状況によってはものすごく
発見しにくいことになる（182の状況はあまり適切な状況ではないが）

ようするに、間違って適切でない型を使ってしまったのに、暗黙の
キャストで適切な型に変えられてしまうと、人間が気付きにくいバグに
なってしまう可能性が高くなるわけ。

>>183
できる限りコンピュータが判断してくれた方がいいに決まってる。
182のような例なら、可能性としては判断できる。

>185
わからんです。もう少し具体的（ありそう）なコードを書いてくれませんか？

>>186
184を読み直してよ。そこに書いてあるから。
読まない人には、文章で説得することはできないよ。

あと、>>182 をエラーかどうかを判断する基準を教えてください。
そんな基準は無いと思うけどね。

万能チューリングマシンでは解決できない問題があることは
すでに証明されているんだよ。

>189
pre/post conditionではねてくれるコンパイラ考えようとしたけれど
無理だった。そーゆーことだな。

単に>156が型あり言語（と議論の流れ）を理解してないだけだよ。
話が全然かみ合ってない。

>181 蝿を昆虫として扱う事のデメリット・ペナルティを具体的に教えてくれ。
の例でいえば蝿->昆虫のキャストと蝿->金槌のキャストの
（危険性の）違いを区別できてない。

ついでに言えば全く関連のない蝿と金槌を
統一的に扱えてしまう型なし言語は
結局お手軽言語でしかない。

>>191
統一に扱うべきでないオブジェクト群を、
統一に扱うようなコードを書くのが悪いかと。
設計問題だよ。

>>192
もちろん設計が腐ってる場合には、いくら言語が手厚い
サポートをしても無駄。でも、型なし言語だと、

std::string str;
str.length();　// 存在しないメソッド, size() ならある
str.lengt(); // スペルミス

なんてコードを書いても、実行時まで検出できないのが嫌。

>>193
>str.length();　// 存在しないメソッド, size() ならある

それはなんだかむしろ逆なことを感じるなあ。

つまり、ライブラリ「全体」において、
無節操にlengthとsizeという紛らわしいメソッド名を
混在並存させているのが、寒いのでは？

型なし言語派(というのも寒い捉え方だが)なら
むしろそういう心配の仕方をするんじゃないかと憶測。

つまり「名前の」設計ね。

重要だぜ。matz氏の言葉なんぞ引用するまでもなく重要だと思う。
つーかあの言葉を氏が書いていたからこそ、rubyには
ある一定の安心が得られるなあと思うのだった。

実行時まで検出不能というけど、その実行ってのは
単体テストとかのかなり早い段階である「べき」だよね。
たしかにjavaよりrubyのほうがUnitTestを
より強く渇望しているのかも知れない(笑)。

>>194
渇望ってあんた、ベルセルク読んでる？

>>194

>つまり、ライブラリ「全体」において、
>無節操にlengthとsizeという紛らわしいメソッド名を
>混在並存させているのが、寒いのでは？

複数の会社のライブラリを使うのは実務では普通です。
音声認識パッケージを富士通から買ってきて、
自社のサウンドパッケージにかぶせるとき、
「富士通さん、うちの会社では size を使ってるから、
length を size に変えてよ」って言うのか？
これだから研究者は……。

>>185
182で十分だと思うけど。
具体的に何がわからないの？

>>186
> 182は、私たちが後者の保証までコンパイラに期待しているものと誤解しているよ。
> 後者の危険性は、確かに明示的であろうと暗黙であろうと危険。

後者の完全な保証までコンパイラに期待してるわけではない。
それが「一般的な場合に」保証できなくても、182ではエラーで間違いを
訂正してくれることにはかわりはない。
つまり、メッセージそのものが正当であるかどうか「一部」判断できて
いるということ。この点はかなり大きいと思うよ。

> でも強型言語ではこの点については考えられていないし、
> 型なし言語でも同じ。間違いの無いコードを書くか、実行時に自分で判断する以外に無い

実際182の場合、実行時に判断する必要は無い。
強型言語ならコンピュータが判断できる場合も一部にはあるってことだよ。

例えば、引数などを間違えた場合、型の不一致で
コンパイラがエラーを出してくれる場合が多い。
これは実行時に判断するよりも圧倒的に便利だよ。

ところが、暗黙の型変換されてしまったらエラー
をださずにコンパイルが通ってしまい、実行時に
判断するしかない。これは不便極まりない。

>>187
fprintf(file_stream, format, char_arg);

とすべき所を

fprintf（format, char_arg);

としてしまった。ところが、char* 型がFile* 型
に変換され…
などとなってしまったらどれだけ不便かわかるだろ？

>>187と>>189の間違いだ。すまん。

>>199
それは、暗黙の型変換が許されない、したがってコンパイル
時エラーになる例に見えるんだけど。まさか File を char
から派生させてないよね？

197=198=199 かい？

強型言語が型付けによってエラーを認識できる範囲は、
インターフェイスの正当性に限られ、メッセージの意味にまでは及ばない
というのは判ってもらっていると思う。
それで、さらにオブジェクトの意味についても、もっと深くつっこんで
エラーを検出できるのではないかという質問をしているのだと思う。
確かにそれができれば便利だけど、それは永久にできないだろう。
（しつこいけど、アラン・チューリングを扱った書籍なんかを調べてみてくれ。）

要するに、強型言語の限界を指摘することで、
あまり強い型づけは無意味だと言いたいのでしょう。
だけど意味的なエラーを検出するのは、ごく一部の例外を除いて、コンピューターにはできない。
強型言語は、明らかに矛盾したインターフェイスの間違いを指摘してくれるに過ぎない。

しかしインターフェイスのチェックだけでも非常に価値があることなんだよ。
これによってどれほどの工数を削減したか、計り知れない。
確かに型によってチェックできるところは部分的なものでしかないけど、
だからといって型付けの価値が希薄かというと、そんなことはない。

ところで1はまだ居るんかいな？

>>201
だから、もしもエラーにならなかったら困るだろう？
という話なんだが。

>>202
>それで、さらにオブジェクトの意味についても、もっと深くつっこんで
>エラーを検出できるのではないかという質問をしているのだと思う

いや、そうじゃない。インターフェイスの正当性がきっちりと
検出できれば、エラーで誤りを検出できる機会が多くなるの
ではないかということ。

> 要するに、強型言語の限界を指摘することで、
> あまり強い型づけは無意味だと言いたいのでしょう

ん？俺は暗黙の型変換に都合の悪い点があるといってるのだが。
なんか、かなりの誤解が無いか？

>>204
形なし言語を擁護しているんじゃなかったのか。
スレ違いの話だったんだな。
まぁ相手してやるよ。

暗黙の型変換に問題がある（許さない）としたら、
どういう解決方法がある？

型なし言語にする？
それは全部暗黙の型変換にするということだろう。
何の解決にもなっていない。

型を変換するときは必ず明示的にキャストしなければならないようにする？
それは型変換しているコードはエラーにならないようにすることと等しいだろう。

基本的に暗黙の型変換は、インターフェイスに互換性がある場合にのみ許される。
このようなルールのもとに、インターフェイスに互換性がない部分をふるい落とすことができれば、
機械的なエラーチェックとして十分な効力を持つ。
これこそ型付き言語の基本理念だと思うけど。

次に、インターフェイスの正当性をもっと厳密にして、検出できるエラーを増やすということについて。
ここは C++ や Pascal や Java なんかでは十分に達成していると思う。
多少の改良の余地はあるだろうけれど、現在の理論では、
根本的な解決は望めないでしょう。
UMLの設計ツールからJavaやC++のコードを出力するのは、一つの改良になると思う。
しかしそれでも、メッセージの送信ミスは、コンパイラレベルでは検出できない。
デバッグするか、テストツールに頼るしかないだろうね。

>>205
> 型を変換するときは必ず明示的にキャストしなければならないようにする？
> それは型変換しているコードはエラーにならないようにすることと等しいだろう。

なんで等しいんだ？
この場合、間違った型にキャストすればエラーになるだろう？

俺はどっちかというと、CやJava擁護派。暗黙の型変換が型なし言語に比べれば
少ないし、暗黙の型変換が完全に無い方が良いとまでは思ってないしね。

うーむ、首突っ込みそこねた。悲しい。

>>206
ここでいう「形無し言語」って perl とか VB のこと？
Smalltalk みたいな言語だと、明示的でない型変換はそもそも
発生しない。で、AsInteger で整数化、というようにメソッド
としてしか型変換は存在しない。

で、意味論的には メソッド名 = インターフェイスとなっている
わけだけど、(isKindOf なんかのテストも含めて)いずれにせよ
実行時テストでしかない、というところが問題だ、と。

Smalltalk やら LISP の流儀のまま、変数や引数や戻り値が特定の
インターフェイス(メソッド群でもよい)を持つことを宣言的に記述
してゆくとどうなるのか、というと...Javaになるのか。

加減算乗除算が可能、大小の比較が可能、何かのオブジェクトへの
参照を保持する、というような軽いインターフェイスが整備されて
いれば、「インターフェイス抽象」が「強い型付け」と結びつけて
受け取られがちな現状は防げたような。

>199
頭のなかで流れが十分に理解できていないのだけれど、
暗黙のキャストはどれもだめなの？
僕は181に賛成なんで暗黙のキャストがまずいとは思わない。
たとえば、Javaのコンテナで言えば、

container.add(obj);

とできるところを、

container.add((Object)obj);

としたほうが良いってことですよね？
ああ・・、そうすると、overloadの概念に似ているのか・・。
う〜ん。

>>199
型付き言語はC言語だけじゃないぞ。Pascalだって型付き言語だし、Javaもそう。
>>199のミスはPascalでは起こり得ないんだが。

月光仮面おじさん登場!!!
ホームページを作ったものの、まったくアクセスが上がらな
くて悩んでいる人のためにお役に立ちましょう。
効率よく宣伝できる共有宣伝掲示板を18個設置しました。
全部宣伝して回ればなんと1,000以上の掲示板にカキコしたこ
とになり即、効果が期待できます。さらに共有掲示板の隠し
リンクを発見してそれらも全部宣伝して回ると計2,000以上の
掲示板にカキコしたことになり、さらにアクセスアップを期
待できます。もう、今日からアクセスが無くて悩むことは無
いです。今すぐここからアタックアタック!!

http://home9.highway.ne.jp/cym10262/

Perlプログラマーは他のプログラマーに劣ってはいません。
反論はこちらのスレッドで。
http://tako.2ch.net/test/read.cgi?bbs=perl&key=987424296&ls=100

>>212
激しく同意！！

すみません。Perl板の厨房が暴れているようで...。
放置してやってください。

VB板とかできないのかな･･･

>>215
VB厨房隔離スレ
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=986993653

age

>>208
VBは型無しじゃないぞ。
Vaviant型を指すなら、もっと表現に気をつけるべき。

>>218
Variant型ね。そうなってるか？
ディスプレイ死亡寸前でよめねぇ！

ＶＢ厨房、ＶＢ厨房うるさい人がいるけど、マシンがここまで
高速になったんだからいいじゃん。
Ｃ言語だって、その昔はアセンブラ派から「くそ遅いカメ言語」
「コンパイラにバグはっけん！！俺がコンパイラ作ってやろうか。
ダメダメ開発者くん」
と毎日爆笑されていたことを忘れるべきではない！

というか、ｃ＋＋やっててＶＢ笑っている人っているの？
考え方いっしょだよね。ｃ＋＋ごとき言語もさ。

VBはランタイムが無いと動かないからだめ？
C++も同じだよ。ただ、意識させないだけ

>C++も同じだよ。ただ、意識させないだけ

処理系にもよりますが、たいていはスタティックリンクも選択でき
ます。VBの場合はその選択肢がないことに問題があるんですが。

>高速になったんだからいいじゃん。

それこそ、今時これだけCPUが速くなったのに、
＃今やPDAでも最適化度低いInterpreter言語がさくさく動くんだもんな…
言語の優劣を速度(だけ)で計るほうが間抜けでわ？

ここでもＶＢ叩きが・・・定期的に現れるよねこの話題。
マシン性能が上がったのはいいのですがむしろ客から言われる
のは、「なんで最新のＰＣ買ったのにこんなに遅いの？」
なんだよね・・・
速度も重要なファクターなんだな。

もちろんＶＢでも問題に最適なアルゴリズムを選んだり、
ActiveXコントロールの数を制限したり、実行ファイルやDLLを
分割してロード時間を短くしたりといった工夫は出来ます。

Delphiの様にDLLを必要な時に動的にロード出来る機能は欲しい。
初期ロード時に時間が掛かりすぎるのはつらい。

VBが遅いって言われるのって、たいてい、起動に時間が
かることなんだよね。ディスクがガリガリ鳴ってなかなか
起動しない

OOやVBの話になってんなぁ。
awkなんかで、簡単なプログラムを組む時、
一つの変数の内容を数字としても扱えるし、文字列としても扱えるし、
これで楽させてもらったな。

多態はある意味型無しか？

>224
同意。みんなは言語仕様に対して文句言っているんだろ。

>>228
結局、変数によって「型が全然確定できない」奴と
「一意に確定できる」奴、そして「幾つかに絞り込める」奴の
三種類がある、という言い方が正しいのだと思う。
1つ目は弱型言語。2つ目は強型のうち古典C/Pascalのような類。
そして3つ目が多態つきの強型言語。

変数の側から見た「多態」は、こういう説明になると思う。

Objectの側から見た「多態」は…
なんだろうね(^^;
ちょっと飲まされて頭パーだからまた明日。
＃あ。毎日飲まされてるわけか(笑)

パー万あげ

VBが遅いってあんた当たり前でしょうが。
何のためにActiveＸコンポーネントやら、
ActiveＸコントロールかましてんのよ。
そんなに速さを求めたかったら全部
APiで組みなさいよ。
VBはやる気になりゃあ、ウインドウの
描画から全部APIに置き換えて、Ｃと同等
の速度まで上げられるよ。

ActiveＸを利用して楽チンプログラミング
というVBのスタイルを全く理解してない事に
驚きを感じる。
つーか、ゲーム作るならVB以外でやれよ！

>>232
C++だと以外とゲーム用のフレームワークとかあちこちにあるよね
(ELが良い例)

>>233
たしかに、ゲームを作りたいって時は
C++が一番いいような。

Eiffelとか、Javaとか、Smalltalkとか＾＾；いっても
使えるフレームワークないからね

>>233
ELってたしか、ぞっとするくらいに非OOPなFramework
だったようなオボロゲナ記憶があるんですが…違ったっけ？

>>234
SqueakのMorphなんとかってのが…
ゲームFrameworkではないが、あれはマヂびびった。すごい。

そういやドッカの誰かがRubyでFramework
(ゲームの、だと思うが)を作るとか
Javaで以下同文とか、言っていたようだが、
どうなったかな…

>>235
ELはヘッダーファイルがギョッとしました。

>>236
つかEL=ヘッダファイル

>>237
そう、「あれ？本体は？」と思ってヘッダーファイルを見てみると「ギョッ！」

あ、実装方法に驚いたってだけで、ELの中身についての事じゃないです。ｱｼｶﾗｽﾞ

たしかに EL のあの実装方法ははじめてみるとギョッとなるよねｗ
そういう方法もあるって事で面白いけど、大きなプロジェクトには
むきませんな。作者も当然わかっててそうしてるとは思うが。

ウリが「EasyLink」なんだから当然なんだろうけど
・グローバル変数ヘッダファイルに書いたり
・関数の多くがマクロ展開されてたり
・クラスを名前空間代わりに使ったり
するのはちょっと恐くはある。

DirectX使っててC++を理解してないということはないだろうけど、
もし作者さんが本当は理解していなかったらと思うと・・・ちょっと恐い。

DirectShowのVideo再生とかにも結構早くから対応していたので、
作者さんが混乱しているという事はなさそうです。
作者さんがあの方法で突っ走っている所は素直にスゴイと思いました。

>>242
個々の技術に対応する能力と、言語「に」対応する能力とは
微妙に別かも知れませんので、なんとも言い難く…

ELってたしか、Cマガに紹介記事のったアレですよね。
うーん。あれ読んで、「やばいよこれ」と思った。
あそこまで凄いと、なんていうか
OOPに対するFUDじゃねーか？とか思ったもんでした。
そこまで「OOPは難しい」という発想に凝り固まる必要も
ないんじゃないの？とね。

後輩新人君がゲームを自作したとかいって見せてくれた。
それ自体はまぁ綺麗でヨイ感じだったんだけど、
ライブラリにコレ(だよね)使ってるのを見たもんで、
「おまえ、下げ」って言い放ってしまったよ俺ぁ…。
これからソースをやり取りする仲(=一緒に仕事する)になる相手に
あのノリを覚えられたくは無いなぁと、痛切に思った。
ruby matz氏の言葉じゃないが、あれは簡易つーか安易だよ。

OOを潰すことがそんなに「簡単」を招くんだろうか？
たとえ小規模でも、却ってしんどくなるだけだと思うんだが。
往年の吉田じゃねーが、ゲームにこそOO、なんじゃないの？

>>243
なんだか話がアサッテの方へ逝きそうなので、
とりあえず話題をもどしましょうか。

御意。戻しましょう(笑)

ええとなんだっけ。そうそう。Objectから見た多態ね。
今日も飲んでるけど(笑)軽快に。

ずばり。関数ポインタが定数じゃなく変数になってること。
以上(笑)。

ただ、そのポインタがどこに有るか？は
言語によって色々なようですね。
多くの言語では(概念上)Classの中に持たれていますね。
Classを値として扱える言語なら、きっとそれ自体が
構造体みたいになってるんでしょう。
そういやCOMが露骨にソレだっけ…

型なしは、長所であり、短所でもある。
それが解らない、１はアホである。

Perl まんせー
ようは適材適所だよ。

暗黙の型変換がないと、catch/throwで困ります、どぞよろしく。
Common Lispみたいに、型の宣言したい時に可能であれば、perl、もちょっといい感じ。

暗黙の型変換がないと、catch/throwで困ります、どぞよろしく。
Common Lispみたいに、型宣言したい時に可能であれば、perl、もちょっといい感じ。

>>248-249
(catch 'tag body...(throw 'tag result))
だっけ？
resultの最後の評価値がcatchの値

>>248
全然知らない分野みたいです。どう困るか教えてください。

例外の話ですよねえ。うーむ？
{{hogehoge raise}{== hogehoge}{== hogehoge}try}

こんなスレあるの知らなかった。惜しい。

いままでざっと見てきたけど、
　・コードを組みながら設計＝型無し
　・設計を完全にしてからコーディング＝型あり
ってことではないのか？
大規模では設計しないと話にならんから、型無し言語嫌われそうだが。

前の方の「小話で書いたプログラムをあとでVBに移植」みたいな話も
そういうことだろう？

>前の方の「小話で書いたプログラムをあとでVBに移植」みたいな話も
>そういうことだろう？

そうなのかなあ？
なんせVBじゃん(笑)、半分は「VBは要らない」スレの話題に
繋がる恐れがありそうで。単にマーケティングとか
業界勢力図とかのモンダイだという面は、結構あるのでわ？

不勉強で申し訳ありませんが、使用したいインターフェイスが確かにクラスに実装
されているかをクラス定義時じゃなくて、オブジェクト→インターフェイス参照の
代入時にのみ検証するような言語ってありますか？

>>254
java.lang.Class#isAssignableFrom(java.lang.Class class)

そのまんま。

＞255
ありがとです。

久々に本題(笑)。

ふと気づいたんだけど、「配列」。

配列そのものを、ひねりのない普通のCLASSとして
素直に実装できる言語って、
型なし言語だけなんじゃあるまいか？

Javaはアレだし。
C++は使い物になる配列はclass templete(用語参考=憂鬱本だったよね)だし。

要するに、型有り言語だと、少なくとも
パラメタライズドクラスとかのワザを使わないと
まともな(型有りに似合った)配列を実現できないのかなと。

もちろんそれが悪いことだと言いきれるわけじゃないんだけど、
ストレートな配列クラスが存在しないと、それはそれで色々と
面倒なことも多いなぁと思う。

というか、面倒の数が掛け算的に増えるんだよね、
普通の変数の型に関わる面倒さよりも。

型有り言語に馴染んだ後に見たrubyの配列クラスは、
その独立性と自由度という意味で、
ちょっとショックだった。

C++ のテンプレート版配列で何か問題あります？　具体例希望。

>>258 例えば整数と実数とリストを同じ配列にぶちこめない
とかじゃないか？
基底クラス作ってサブクラス化すればできるけどよ。

結局、継承関係(ツリー構造にならねばならんという制約がある)を
解決しない限り、問題解決が先に進まない、というのが
時として厄介な問題になるんじゃないかと。

>>259
単に効率的なインデックス参照を考えている場合は
ポインタの配列という風に抽象化すれば解決します。

つーかコンテナに関しては全部そうじゃん。>257

>ポインタの配列という風に抽象化すれば解決します。

それ、何重にも変じゃないですか？ここの議論的に。

ポインタにしたくらいで抽象化できるってのがまずナニだし
(というか効率とかの話はここでは関係ないし)。

>>262
いやまさにそのとおりなんですけどね(^^;。
とりあえずコンテナの代表者つーかサブクラスの1つとして、
配列っていっただけ。

型有り言語だと、Classを値として扱うのは
結構大変というか能力制限されるよね。
Delphiでもやっとこせって感じだ。

型無しの言語って、コンパイル時に型の整合性から
エラーを検出するということが出来ないんだよね？
もしそれが出来ないのなら途方もなく大きなペナル
ティだと思うが、どうやって解決してるんだ？

>>266
例えば
「メソッドがありません。」ってエラーが発生する
そんだけ。
それが問題だったら、例外送出してリカバリする。
コンパイル時に検出できればその時にエラーが出る。

>>267
例えば、文字列しか引数に取らない関数があったとして、
間違って数値が入った変数を引数に与えてしまったら、
実行時にしかエラーが検出できないのか？

このスレunitで検索してみ >>266

>>269
結局、いちいちUnitTestやってないと見つからないのか？
それではやはり大きなペナルティだろう。
しかし一応、回避策の一つではあるな。

>270
>結局、いちいちUnitTestやってないと見つからないのか？
そのとーり。
UnitTestの有用性は示されつつあるけど、
それが強制されるってのはよろしくないね。
その上デバッガも貧弱だからソース汚してprint
ばら撒かなきゃならないので余計にUnitTestしないといけなくなる。

逆にUnitTestさえやってれば大規模開発
できるのかどうかってことに興味があるね。
Ruby信者あたりが無茶して挑戦してくれないかな :-P

>>その上デバッガも貧弱だからソース汚してprint

それって本質か？
もしかしてGDB(とか)が使えないことを指しているならば、
それは単に「今まで」Cとかが主役だったんで
それ用のデバッガが元気だ、という話でしかないはず。
ようはデバッガ「作れば」いいんでしょ？違う？

>Ruby信者あたりが無茶して挑戦

無茶かなあ？

たとえばCみたいに死にポインタをばんばん作れてしまう言語でも
みんなOSとかばりばり書いている(笑)のは無茶じゃないの？

不便が少ないほうがよいという文意ならば賛成するけど、
ある不便と別の不便とのどっちが深刻な不便か？については
一応考えたほうがよいと思う。

単なる「慣れ」が答えだったら、大笑いかも知れない。

>>272
貶されるのが嫌なのはわかるが、話がそれている。

>>273
逸れてるかなあ？…
少なくとも前半は
むしろアチラが逸れてるんだと思うが。

そうそう。JDBC見て型有り言語にむかついたんだった。
物凄い数(百以上とか)のメソッドがあるんで
なにごと？と思って見てみたら、
同じような機能のメソッドの型違い版がうじゃうじゃあるだけ(笑)

で、更に不思議に感じるのが、出力の返し値の型に応じて
メソッドは多数あるんだけど、入力のほうはOverloadで
同名に揃えているんだよね(笑)。
あれってどっちかに統一できませんかね？
つまりそういう言語作れませんかね？
出力のほうでもOverloadできるような言語。

>>274
私は逆に VBScript + ADO を使ってて、型なし言語にむかついた
けどなぁ。どうも比較がおかしいってんで調べたら、テーブルを
作った人間が、フィールドの型を間違えてたので、型が違っていた
のが原因。……勘弁してくれ。

出力を Overload っていうと、C++ の template に型推論を組
み合わせたような代物？　あれば便利かも。

int f();
int *f();
g(int n);
g(int *n);
で
g(f());
はどう解釈されるの？
なんか無理っぽい気がする

結局UnitTestしか逃げ道はないのか？

>>276
やっぱそこで頓挫するかあ…うーむ…

形無し言語は関数のオーバーロードって需要あると思います？
(ていうか、意味あります？)
同一クラス内での話で、多態とは別の話です。

>>279
引数の型じゃ分類できないから、引数の「数」で分類することになるかな。
まぁそれはそれってきもするけど、
たとえばunixのshellみたいな環境を思うと、
やっぱりやめたほうがよいかとも思う。
unixにしばしばある、引数の数で動作を変化させるプログラムって
使っててすごく鬱陶しいと思わないっすか？俺は思う。
＃てゆーかオーバーロードは全部鬱陶しいと俺は思うんだけど。

ところでSmalltalkの文法つーかメソッド呼び出しの引数の書き方、
御存知っすか？
初めてみた(それまではCとかBasic(笑)とかのスタイルしか
知らなかった)ときはびびった。あれ卑怯だよなあ(誉め言葉)。
オーバーロードの是非を悩んでいた自分の肝っ玉が小さく思えた。
はるかにお洒落な解決方法が有ったのに！

ああ、引数の「数」で区別するんだと、
C++でいう「初期値」を許してる場合区別つきませんねー。
func(param1, param2 = init2)←こういうやつ。
やっぱり意味無さそうですね。
>御存知っすか？
Smalltalkは知りませんが、こういうやつですか？
obj(method, param) //objにmethodメッセージをparam付きで送る。

あ、逆だったかな？
obj (param method)
ちなみにSchemeでは何もかも自作なのでどっちでも可(汗
(obj 'method param ...)
(obj param ... 'method)

http://www.sra.co.jp/people/aoki/SmalltalkIdioms/chapter2/Chapter2.htm#KeywordMessage
っす。
いわば引数1つづつに名前がついてる(笑)。
なにがずるいって、「メソッド名」=「1つの単語」じゃない、という所。
copyFrom: 2 to: 4
だったら、
copyFrom to
という2語(笑)がメソッド名であり、引数はメソッド名の「間」に挟まるかんじ(^^;

なるほど。複数書けるのは斬新（古いんだろうけど）ですね。
#[10 20 30 40 50] at: 3; copyFrom: 2 to: 4
これは配列のメソッドat,copyFromを呼ぶって事になるんでしょうか。
只の配列の様な無名コンテナにもメソッドがあるのは
独特な感じがします。（ステートメントかもしれませんが）
でも返却値（センダ）は最初のオブジェクト（評価値じゃなくて）
の最後のメソッドの結果なんですね。
↓こうじゃない。
#[10 20 30 40 50] at: 3
30
30 copyFrom: 2 to: 4 => エラー?

最初のメソッドの評価結果は捨てられて最後の評価値が返る。
#[10 20 30 40 50] at: 3
30 =>捨て
#[10 20 30 40 50] copyFrom: 2 to: 4
=>#[20 30 40]

うーむ、copyFrom:に対して toは付随する構文にも見れるん
ですが違うのかな？
copyFrom x => x〜をコピー
copyFrom x to y => x〜yをコピー （コピーするにはyが決定してないと駄目）
to y => yまでを返す。
メソッドが独立だとすると、実際にはx以降全部をコピーし、
y以降を分断するって解釈になりますね。(効率が悪い？)
もしかしたら
copyFromTo x y
とかの方が効率がよくなるとか（汗

>只の配列の様な無名コンテナにもメソッドがあるのは
>独特な感じがします。（ステートメントかもしれませんが）

これはフツーだと思いますよ。rubyもそうだし。

というか小噺なら本気で「すべてObject」でしょうから、
なんでもかんでもメッセージ送りであるはず。
＃Classの定義もSuperclass(だったよね)へのメッセージだし。

「;」は、1つのレシーバへの複数発のメッセージ送りを
連発するための構文、とかでしたよね。うん。

>付随する構文

そゆのはたしか無かったような記憶が。
前述のURLの前後をうじゃうじゃ読むと書いてあったような
気がします(ぉぃぉぃ)が、メッセージ送りの文法は3つあり、
引数なし、引数1つだけ、引数複数、に
分類されるんだったような。
＃で、いわゆる演算子は引数1つのメッセージ送りとして実現されてる(笑)

効率は変わらないと思いますよ。単なる構文。
パーサーがどんなイイ仕事をするか？にだけ依存する問題ですから。

>>283
>copyFrom to
>という2語(笑)がメソッド名であり、引数はメソッド名の「間」に挟まるかんじ(^^;

でなくて、メソッド名というかメッセージ名は copyFrom:to:
コロンは区切子とかそいうのではなくて、単にメッセージ名の一部だったりする。

あげるね。

2 + 4 * 5
が35。
これは設計ミス？

あ、3 + 4 * 5でした。

>289
どういう計算しているんだ？（藁

だから>>290で直したでしょ。SmallTalkの話。

オブジェクト指向の話になるとすぐRubyを持ち出す人多いねえ。
「Rubyだと」とか「Rubyでも」とか。

じゃぁ、このスレの次レスから900まではRuby発言禁止。
ぜってー禁止！つーことでみなさんよろしく。

Ruby

>>289
そうか？演算子に優先順位なんてものがあるってのも、
それを算数/数学のソレに合わせないとならないってのも、
なんか必然あるの？イミナイじゃん。
あるとすれば俺たちが義務教育に飼い慣らされたせいだ(笑)
+が*より弱いことの尤もな理由って有る？ないよね？
それどころか計算機言語にこの概念が移植されて以来(特にC)、
計算以外にも多数ある「演算子」にも優先順位っていう概念が
濫用されて、ぐちゃぐちゃになっちゃったじゃん。
優先順位に付き合ってられないから括弧使いましょう、ってのは
プログラムの鉄則の一つになっちまった。結局優先順位って蛇足だっただけ。

そういうウザイものをうっちゃってくれた小噺には拍手。

>>293
rubyが、無難というか没個性(笑)なOOPLだから、じゃないの？
こういう状況で話のネタにしやすいんだよ、rubyの仕様は。
ふつーの(笑)プログラマが、退屈に感じながら想像しがちであろう
仮想OOP言語の仕様って、結構多くの部分がRubyと重なると思う。
勿論演算子優先順位あるし(笑)。

>>296
数学的には
a*(x+y) = (a*x) + (a*y) は成り立つが
a+(x*y) = (a+x) * (a+y) は成り立たない
だから*のほうを強い演算と定義しておくと記述が楽になるのだ。
詳しくは群論とかやるとよくわかるよ

>>296
3 + 4 * 5ってどう見ても中置記法に見えるけど。
+*が「演算子では無い」事を知らなかったら誤解するよ。
メソッドの引数の取り方がobject mehod paramで、
左から順に評価される事を知らなかったら理解できない。
3 + 4 * 5
↓
((object3 method+ param4) method* param5)
↓
(object3 method+ param4) => tmp-object7
(tmp-object7 method* param5) => object35
これはかなり変な感じ。
C++みたいに優先順位固定なのもアレだけど。

そういう考え方だとlispの方が自然だよ。
(* (+ 3 4) 5)の方が誤解なくて良い。
+や*は演算子じゃなくて関数だから優先順位も元から無い。
括弧はウザイけどさ。
必要なら
(infix->prefix '(3 + 4 * 5))
=> (* (+ 3 4) 5)
という手もあるけど。

>>298 >>299
つまり、演算子なんてものが存在することを
忘れりゃ(=計算機畑に持ち込まなければ)ヨイんじゃない？
知らなかったら誤解するもへったくれもなく、
最初から演算子を知らなければ誤解のしようがない。

いや、まさに俺は忘れたいんだけどさ。

Forth系もいいですね。PostScriptなんか結構綺麗。

Forthつーか後置記法だと
3 4 + 5 *
述語が後ろにあるからMIND風に、
「3 と 4 を足して 5 を掛ける。」
=> 35
と書ける。'と'や'を'は区切り子。

コンパイラが賢くなって、型推論がもっと進めば
型付けが強い言語は廃れてくんじゃないかなあ・・
型付けが強い言語でガチガチに組むの疲れるんで、そうなってほしい。

型推論といえばMLが思い浮かぶんですが、
書きやすさや実行効率はどうなんでしょうか。

MLは型推論を取り入れた、「強く型付けされた言語」だよ。
型推論と型多相の概念があるから、型があっても定義は少
なくて済む。型による厳密性を保ちつつ、柔軟性も実現で
きている。
型推論というのは、型が廃れるどころか、逆に型のある言語の
不利を解消してくれるものだと思う。

型推論でgcを全く使わない処理系が存在するらしい。>303
関数型言語スレにリンクがあった筈。
書きやすさは、慣れればCと大して変わらないと願いたい。(w

>>296
rubyが没個性という意見は共感できます。

ちなみに、Rubyのドキュメントなどに
「教育上の配慮としては」
というフレーズが出てくることからして、Ruby開発者周辺は
Rubyを教育に使える言語だと思っているらしい。
俺はそれにはちょっと疑問を感じる。

MLと同じような言語であるHaskellにはGCあるよ。
クイックソートは次のようになるらしい。

qsort [] = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
where
elts_lt_x = [y | y <- xs, y < x]
elts_greq_x = [y | y <- xs, y >= x]

C言語よりは書きやすそうだ。

>>302
型の無い言語でちょっとしたミスが次々とバグになっていく
方が疲れる。
型がある言語はコンパイル段階でバグがある程度発見されるから
ある種の信頼感のようなものがあっていい。

型がなくてもいいかなと思いますね。

- 契約に基づくプログラミング
- Testing Frameworkによる保証

的なことがないと、チームで使う気にはなれませんが。

Testing Frameworkを適用するにしても、全ての関数に関して
Unit Testを実行するのか？
なんか、型による効率を全面的に回復してくれるものとは
思えない。
それに、契約によるプログラミングでも、ケアレスミスを犯して
しまったら、実行時のバグになるから、型によるチェックの代替
になるようなものでもないと思う。

そういう人に限ってテストをおろそかにする傾向があります。
(「コンパイル通ったから」つって人に渡す様な人ね。)
>ミスが次々とバグになっていく
このセリフが全てを物語っているのでは？

形無しだと単体テスト前提なのでそんな事はありません。

>>311
単体テスト前提ってどういうこと？
引数間違えたら実行時のバグになるだろ？

引数間違えるのをテストケースの一部にすればいいんじゃないの？
頭悪いの？>312

あれま、これまでのレス全部よんだんだけど、
かたなし擁護派が、Testing Frameworkやら持ち出す戦法は
とっくにやられてるのね。じゃ、なんか、新しいこと書かないとね。

形無しは、あるていど小人数のプロジェクトに限られちゃう傾向が
あるのはそのとーりでしょうね。あと全メソッドに対してテスト書くのか？
っていう突っ込みいただいてますが、それはそんなことはしないです。
pragmaticに考えましょ。っていう回答になりますね。

>>312
引数間違えくらいのものでしたら、単体テストの段階でひっかかるでしょうね。

でっかいものをかたなしでやれんのか？　というお話でてますが、
こんぽーねんと、というかカタマリにしてやって、それより外は

- えーい、CORBAをしゃべらせちゃえ
- SOAPいってみる

なんて、型の世界も利用しちゃったりするのもありだし。

だから、要するに単体テストなりUnit Testなりが前提ということは、面倒って
ことだろ？
ていうか、全部の関数をテストするわけじゃないんだから、全然駄目だと思うんだが。

ところで、MLの型推論は型無し派から見てどうなんすかねぇ。

型あり普段つかってっけど、単体テスト便利よ。
Testing Frameworkはべつに形無し野郎の専売特許じゃないっしょ。

>>318
確かに便利でも、それさえあれば型による不利が全部なくなってしまう
というものでもないと思うのだが。
むしろ型あり、無しとは関係の無い所で新たな便利さを付加するもの
であると思うけども。

おいらも含めて世の中ろくでもないプログラマーばっかだから、
型で守られてても、信用なんねー、イテテ、という目にもあうし、

テストがついてないと心配だし、テストがついてたら、まぁその範囲で
信用しましょ、で、細かいところは見てる暇もないから、とらぶったら、
中身もみます。

>316
単体テストは別に面倒ではないよ。
型に縛られる言語は思考の妨げになっている事が多い。

>>317
型推論って詳しく知りませんスマソ
ラクチンできるとか、いろいろ餌を与えてくれれば
尻尾ふってよろこぶプログラマーは多いと思います。

>>321
何もしないよりは面倒だから全部の関数をテスト
したりしないんだと思うけど。違う？

結局は、手間がかかるからテストは限られる。
テストは型の無い言語が失ったチェック機能を完璧に
補うことにはならないと思う。
その代り、型の有無に関係の無いメリットをもたらす
ものだと思う。

>>313
何か勘違いしてないか？
引数を間違えるというのは、hoge(a, b)をhoge(b, a)に間違えて
呼び出してしまった場合など。
この時、型の有る言語ならコンパイル時にこのバグを発見してく
れる可能性が高いけど、型が無いと実行時のエラーになる。
間違えるつもりはなかったのにうっかり間違えてしまったのだから
テストケースにすればいいという問題でもないだろ？

>>325
呼び出し側の単体テストで引っかかるとか。
あるいは呼び出し側で単体テストがなけりゃ機能テストで引っかかるね。
で、あわてて、こりゃまずいね。引っかかるように単体テスト用意しとこね。
って話になるような。

あと、Programming by Contractの場合は、メソッドの入り口の検査で
ひっかかるよね。

>>326
でもそれだと、呼び出し側の関数内にエラーがあることしかわからない。
結局、不利なことにかわりは無いと思うが。

>>327
心配してるのがランタイムエラーの防止なら目的は達成できてるっしょ。

>>328
いや、問題はどれだけ直ぐにどの個所にエラーがあるかを
特定すること。
その点ではランタイムエラーや、実行時のエラーとならないバグは
コンパイルエラーと比べてタチが悪いってこと。
結局、コンパイルエラーほど便利なものは無い。

なるほど。
型システムのメリットを否定するつもりはございません。
ケースバイケースですが、はまることもあるのは事実でしょうね。

いじわるな例:
(int,int,int)な型のメソッドって順番変わってもだめじゃーん。

>>330
まあ確かに、型によるコンパイラのチェックと言っても万能じゃない。
でもかなり有効なのは間違いないと思うが。

形無しのメリットを聞いてみたかったり。時間あったらよろしく！
おいらこれから新幹線のってお仕事なんだな。はぁ。
じゃまたね。

>>330
>いじわるな例:
>(int,int,int)な型のメソッドって順番変わってもだめじゃーん。
IDEのエディタは入力時に
foo(int size, int count, int length)
のようなチップヘルプを表示してくれて
どの引数が何を意味してるかを教えてくれる。
順番間違えるなんてミス最近したことないな。

>>332
>形無しのメリットを聞いてみたかったり。
記述が冗長でない->シンタックスシュガーってだけでしょ。結局。
>>118参照

>>333
ということは、VC6のように、IDEさえしっかりしていれば、
型なんていらないということにならないか？

>>318
んだ。型ってのは、無数にあるであろうチェックしなきゃならん事柄
のうちの一つなんで、型あろうがなかろうがUnitTestは役立つ。
というか、コンパイラが変数の型を調べるってのはつまり
型に対するUnitTestをコンパイラ(と言語の文法)が内包している
ということに他ならない(笑)。

>チップヘルプを表示してくれて
>どの引数が何を意味してるかを教えてくれる。

それって「Role」に話通じるよね。
というかツールチップがしてくれるその仕事ってのは
Roleのサブセットに過ぎないんじゃないかと思う。

ところで型の話と関係ないが、
VC6ってしっかりしてるといえるのかなあ？
俺は処理のデバッグだけじゃなくてObjectのデバッグもしたいが、
VCでもあまり積極的にサポートされてないよね。
あるインスタンス…変数じゃなく値Objectを、
Scopeに依存しない形で状態変化の追跡をしたい
と思うことが多いのだが、不可能か面倒かどっちかだよね。
だからいつもストレス感じている。Instance(クラスじゃなく)「に」
ブレークポイントというかWatchを置きたいのにのに。

>>334
前にもあった話だけど、型なし言語で
Object(の型)に基づいたメソッド名一覧を
出せるのか？という疑問があったようだし。

で、その話を外挿すると、多態を使うと
メソッドの「名」は表示できるが、
メソッドの「実装」へワンタッチでジャンプする
ような仕掛けってのは、破綻するといえるよね。
そういやVCでも、メソッド名の定義だか実装だかを
検索させるときは、同名メソッドの一覧をずらりと
提示してくれちゃうよね。絞りようがないとも言える。

型も勿論便利だけど、型だけじゃやはり太刀打ちできないので、
少なくともコンパイルエラー「だけ」を頼るような
ドキュなプログラミングスタイルは逝ってくれないと困る。

>>332
型なしのメリットは自由度だと思う。
継承関係とかにとらわれずにプログラミングできる。

自由度は諸刃の刃ではあるけどね。

型無し言語は実行時エラーでしかミスを判断できない、
という意見があるけど、なんか、
型無し＝インタプリタ、型あり＝コンパイラ、という
前提を元に批判しているように思える。
僕の勘違い？

>338
もう少し詳しく説明してよ。
そうじゃないと君の書き込みは厨房な書き込みに見える。

> 型無し言語は実行時エラーでしかミスを判断できない、

この意見は別に

> 型無し＝インタプリタ、型あり＝コンパイラ

こんな前提なぞ関係無しに成り立つ話でしょ。

>>335
チップヘルプの話をしてるのに、いきなりなんでデバッグに話が飛ぶの？
全然会話がかみ合ってないよ。

>>339
最近のレスでいうと、>>325のケアレスミスの件は、
コンパイル時に見つけられればOK、実行時に見つけられれば
NG、という括りをしているように読めました。
>>329の「コンパイルエラーほど便利なものは無い」というのも
型あり言語のコンパイラを前提としたレスに読めました。

前提が無いのなら、そういうアプリケーションの機能ではなく
言語の文法や機構等につっこみを入れるべきなのではないかと
思います。

>>340
型あり派の人たち全員がそういう前提で話しているとは言いませんが、
上記のレスの印象から、そういう人たちが混ざっているように感じました。
言葉が足りませんでした。気分悪くしたらゴメンナサイ。

>>342
だから、型なしだとコンパイルの時にエラーが発見できないんだよ。
コンパイラだろうがインタプリタだろうが。
わかってる？

最近は純粋なインタープリタってあまり見ないよね。

>>343
いえ、型無しに関してはそうなのですが、
型ありのインタプリタというのは
考慮されていないということでしょうか。
私も型ありのインタプリタの実例を知らないので
何ともいえないのですが。

PerlもPythonもRubyも不純？

実行前に中間コードに変換するから？

>>343
型無し＝インタプリタ、という前提は私の勘違いでした。
ごめんなさい。

C/C++のインタプリタって存在するよ。
利点はバイナリ作らなくても実行できてお手軽ってだけ。
コンパイラ・インタプリタ（純粋・中間コード）の区別って
基本的には速度が違うだけで機能面では差はないよ。
# CPUがインタプリットするかインタプリタがインタプリットするかの違いだから

ついでに、型無し言語のコンパイラってあまり意味がない。
結局バイナリ自身にインタプリタ的な
機能を持たざるを得ないから速度が出ない。

ただソースを隠せるという副作用があって
こっちのほうがメリットがあるかもね。

>>349
そのC/C++のインタプリタでは、例え純粋なインタプリタでも
実行前にエラーを出すんですか？
出せないなら型の意味が薄れることになるけど。

この板UnitTest=TestingFrameworkの話題が結構出てくるけど
実際どの程度の人が実践してるんだ？
XPの完全導入なんて皆無だと思うんだけど。

「設計サボって後から泣く泣く手直し」を
リファクタリングって呼んでるやつは多そうだけど(藁

>>350
その前に、C/C++の純粋なインタプリタって存在するのですか？

インタプリタの実装の質による話だよ。
CINTのソースでも呼んでみれば？

癒し系っていわれんじゃないの。> XP,Refactoring,TestingFramework

初芝電気の会長のセリフじゃないが、
愛がなきゃチームはうまくいかない。

>>349
CINTというインタプリタは知っています。
ただ、動かしたことがありませんので詳細はわかりません。

>>356
型有り言語は静的な型のチェックが可能です。つまり実行する前に型の間違いを
見つけることが出来ます。(型無し言語は動的な型チェックしかできない。)

型有り言語のコンパイラ／インタプリタであっても、静的な型チェックを行わず
動的な型チェックのみを行う実装がもしかしたら存在するかもしれない。

言語の仕様的に静的な型チェックが可能かどうかが大事なので
ここでコンパイラ／インタプリタの話を持ち出すのは無意味。

test1

test2

>>357
コンパイラやインタプリタを前提にしているというのは
僕の勘違いということで納得しました。
私が指摘した>>325や>>329等は文脈的に「コンパイラ」という
単語が出てきただけという認識に改めました。
以上。失礼しました。逝ってまいります。

age

逝かなくて良しage

急浮上

型無し言語も、型推論による型チェック導入すれば逝かなくて良し！

というネタはどうよ？>364

>>365
型チェックする時点で型あり言語。

型無し言語＋型推論　＞　型有り言語　＞　型無し言語
ですか？

> 型無し+型推論
ってなんだ？
そんな言語ないだろう？
MLは型あるし。（しかもキツイ）

>型無し言語＋型推論
明示的型宣言の必要無い言語って意味？
MLは推論失敗したら型聞いてくるよ

Smalltalkは動的に強く型付けされた言語(データ型あり)
Eiffelは静的に強く型付けされた言語(データ型あり)
Pascalは静的に強く型付けされた言語(データ型なし)
C++は静的に弱く型付けされた言語
型なし言語ってBCPLみたいなのをいうと思う。

BCPLはモノタイプじゃないの？

>>371
OOP言語は、
(Objectについてはという意味で)必ずデータに動的な型が有るよね？
C++もDelphiもJavaも。そうでないと多態ができない。

型無し言語っすか。awkなんかが該当するんかな。
外因によって暗黙のうちに型(?)が変わっちゃう。

>>372
モノタイプは型なし言語だと思う。

型無し言語というのは、一般的には、コンパイル時において、
変数の型が決まっていない言語のことだろ？
だから、Smalltalkは型無し言語だろう。
型推論というのは、コンパイル時に型を推論して演繹し、決定
する行為の事を呼ぶのだから、型無し言語＋型推論というのは
普通は、ありえない。
型推論なら、型有り言語。
部分的に型無し言語＋部分的に型推論というのなら、可能性
としてはありえる。

変数に型がある=静的型
オブジェクトに型がある=動的型

>>375
そもそも「コンパイル時」って解釈がおかしいよ。
HaskellやMLにはインタプリタもある。

>>375
Smalltalkは型あり言語

>>377
正しくは、「プログラムが実行し始めるより前に」だな。
ところで、HaskellやMLの代表的なインタプリタは中間形式に
コンパイルするぞ。

>>378
Smalltalkは普通、型無し言語と言われていると思うが･･･

正確には違うかもしれないが、
変数に型があるなら、型有り言語
オブジェクトだけに型があるなら、型無し言語
だろ？

Perlの型あり言語の仲間になるらしい。知らなかった。。。

Perlは最も不細工で半端な型有り言語だな。
型を（有限な）記号で明示するなんてセンス悪すぎ。

>>382
Perlの変数に使う「型」という言葉は普通の言語の型と違うから、
Perlは型なし言語と言って良いと思う。

Perl6からね。（自分的には）良い感じに変わるんだよね。

急浮上させておいて、自分で忘れてた。

う〜ん、Ruby好きよ。
ってかネタ無い。逝きます。

実行するまで型が分からんのが型無しだと解釈しとおりましたが…

コンパイル言語の場合どうやって実現してるのだか？

>>386
RTTI

>>387

カタナシダトプログラムしててわけわかんなくなるよ
ちょーむかつくー

>>385
やっぱりPerlの開発者たちも型有りの言語の方が
有用だって気づいたのかな？
楽しみだね。

>>390
型が無いせいじゃなくて
自分のノヲミツォが無いせいだろ。

>>392
どう考えてもわけわかんねーだろ
なにに使われてるかよくわからんし、
勝手に配列のサイズが変わってるし、エラーでねーし

Perl ファンのオレとしてはPerlが叩かれているのは痛い。
・型宣言した変数はその型に限定される。
・型宣言しなかった変数は型なし変数として扱われる。
・あるコマンドラインオプションを指定すると、型なし変数がある場合に警告を出す。

　というのが、いかにも折衷言語のPerlらしくていいと思うけど。
　つーか。その方が実行速度が上がりそう。

>>393
ハァ？
配列のサイズか変わるのは
動的型か静的型かとは関係ないだろ。

>>393
配列のこと以外は激しく同意。

型の重力に魂を引かれてるね...

>>387
なにをコンパイルするか？という問題だ。

仕事で使ってる某社の独自言語なんだけど、
メソッドの内容はほぼCってかんじの言語で書き、
一方Interfaceはなにやら妖しげなしかけを使って
ほぼInterpreter状態でやっている。
なので変数の型を見てもObjectが何かは全然不明。

動的にメソッドディスパッチをして
(Network分散Objectなシステムなので、静的は無理なんだよな)、
いっぽう走るメソッド実装はCゴリゴリ
(分散したときのメソッド実装は、しょうがないから
それぞれのマシンに予めInstallしとけ、という仕様(笑))。

要するに入り口と中身の建て方が違うっていうだけ。
そういうのも可能だよ。
ん。良く知らぬがObjectiveCってのもソレなんじゃなかったか？

型あり言語至上主義者は石頭の馬鹿。
ちょこちょこっと組むプログラムの場合
面倒くさいだけなのが分からんかボケ！
その点、型無し、型あり、ケースバイケースで
対応できるVBの柔軟さは素晴らしい！

oioi
VBはクソ

判で押したように「VBは糞」としか言えない奴は
洗脳済み思考停止の阿呆

>VBはクソ
++;

VBはうんち

おまえの性格がうんちだ

>>399
ケースバイケースでVB使うのではなく、
ケースバイケースで使う言語を選べ。
VBはやっつけ仕事に最適。

>>400
バカ、あほ、糞、氏ね
プログラム技術板憲法第五条に
「VB厨は放置しましょう。」
と書いてあるだろうが！！

>>399
お・・・おいおい。
ＶＢでも型はちゃんとしとかないとダメだよ。
Option Explicitだよ。

>>380 >>381
では、そういうことで。でも、
今からこのスレッドは「動的型付け言語逝ってよし」になりました。

>>380 >>381
では、そういうことで。でも、
今からこのスレッドは「動的型付け言語逝ってよし」になりました。

>>407
だから、どんな場合でもOption付けるのが
四角四面の糞真面目馬鹿だっていってるんだよ。
小さいプログラムにゃウザイだけ。
なんでオプションなのかわかってねーよそれ。

>>410
馬鹿はおまえだ馬鹿市ね

>>410
あなたは小さいプログラムしか組んだことがないんですね。
だから気にならないだけですよ。

型有りの言語でも型の宣言をする必要が無い言語は存在する･･

状況に応じて、型ありになったり、型無しになったり
インタープリタになったり、コンパイラになったり、
ダイナミックリンクになったりスタティックリンクになったり
配列のインデックスが１から始まったり０から始まったり、
選択できるVBの柔軟性は素晴らしい。

>>413
でも関数型言語とかの型推論って
型の不整合が発見されても
実際のバグを探すのはすごく大変だよね。
型宣言を省略するんなら
それこそ小規模でないとやってらんない。

でも型有りの変数と無しの変数は混在させられないよね。
その点はPerlの方が柔軟。
宣言を必要に応じて使ったり使わなかったり出来る型推論
も柔軟かな。

>>415
は？何言ってるの？
型推論だろうが、そうでなかろうが、バグを発見
するのは同じだと思うけど？

>>417
1. バグってる型情報から矛盾が発覚するまでに
既に多くの型演繹がおこなわれている場合が多い。
2. 推論の過程が見えにくい。
3. 推論の順番によって結果が大きく異なる。

だから、特に高階関数を多用した時には
原因を追跡/特定しにくい。
特に宣言を省略するとグチャグチャ。
ちゃんと多相型で関数の型宣言をしたほうがいい。

>>415=>>418はMLを使ったことないに三億モナー

>>418
型推論は良く知らないが、まるで型無しの言語で実行時に型
の不整合が起こった場合の欠点のようだな。

普通はどの箇所で型の不整合が起こってるのかわかれば
たちどころにバグが発見できるものだが。

>>414
そこまで言うとDel厨房が対抗措置を発動するぞ(藁

ちなむとPascalは配列添え時範囲は任意の整数に出来る。
マイナスだってなんだって有り。配列宣言するときに好きに決める。

リンク形態はこのスレとは無関係。

インタプリタも無関係。実装部をどう扱うかと
Interfaceをどう扱うかは別問題なんだから、
実装部は爆速コンパイルが一番良いに決まってるし、
Interface部は混成(多態を使うために)でOK。

混成というか多態の仕掛けがあるので
「なかば型無し」なんだよOOP言語は。
そういう意味ではVBの素朴な戦略より
OOP言語のほうが少しマシ。

あと、あんな単純なやり方で切り替えができるのは
文法がそれだけ冗長というかまとまりが無いことの
裏返しじゃないのか？

>>419
MLはもう5年以上使ってないなあ。
最近の処理系じゃあ型のデバッグ環境が
しっかりしているってことでしょっかー？
知らんかったです。炒ってきます。

2回書き込んでしまった。すみません。

>>380 >>381
型チェックはコンパイル時と実行時があります。
1 コンパイル時と実行時に型チェックする言語(静的型付け)
　　C++ Eiffel
2 実行時に型チェックする言語(動的型付け)
　　Smalltalk lisp scheme
3 コンパイル時に型チェックする言語(静的型付け)
　　C Pascal
4 型チェックしない言語
　　BCPL

また、型付けに強いと弱いがあり、スタティックキャストと関係があります。
C++ はスタティックキャストができるので、弱く型付けされた言語です。
Eiffelはスタティックキャストができないので、強く型付けされた言語です。
(ダイナミックキャストはできる)

なぜ、3は実行時に型チェックができないことが
あまり議論されないのだろう？

>>1
どっちもありだと思うけどな。
ラウンジマンセー！！

この議論はOOPLが前提になっているから３は論外ってことでしょ。

>また、型付けに強いと弱いがあり、スタティックキャストと関係があります。
この分類ってはじめて聞くんだけど出典希望。
型の強弱って変数に格納できる値の制限の強弱ってことだと思ってたけど。

>>425
「オブジェクト指向言語のはなし」
>型の強弱って変数に格納できる値の制限の強弱ってことだと思ってたけど。
はじめて聞いた。くわしく教えて。

http://saki.2ch.net/test/read.cgi?bbs=qa&key=993396409

>>425
OOPLが前提だとなんで3が論外なんだ？

virtualによる多態性はlate bindingが前提だから。

３の範囲内でクラス実装するとしたら
virtual無しになってしまう。

Object Pascal は >>423 の (1) に入るんだよね？

>>425
その他いろいろな本に書いてある。
「CよりPascalの方が型付けが強い」とか。

>>425
型の強弱について知りたい場合は、ML 関連の本を読むとよくわかると思う。

Perlの型付けって、
my Dog $spot; # Perl5
my int $colors; # Perl6
とか
my INT @hit_count is dim(100,366,24); # Perl6
のこと?

どっちかっつーと実装ヒントっていう印象が強いんだけど。
型推論とかしないよね。

MLの型推論って、場合によっては非現実的なほど推論に時間がかかると
いうよね（めったに起こらないとは言うが）。

MLやHaskelみたいな強く型付けされた関数型言語が、異なる言語で書
かれたライブラリを利用する方法を持つなら、それがベストって気がす
る。（実行時効率を追求する場面では、C++なりEiffelなりのお世話に
なると思いますけど。）

型推論って型の明示省けるっていう
シンタックスシュガー以上の意味はあるの？

>>435
自明な宣言を強制されるというのは、bookkeepingを人間に強制する
ということだから、好まれないのは明らかでは？

自明な型にまで宣言が要求されるのはコンパイラに負担をかけないた
め以外に理由があるの？

たとえば

int i = a.size()

みたいな式のintは、a.size()が整数を返すと決まっているなら
不要だよね。でもって、ここでint型に定義されたiを余所で別の
型が期待される文脈で使用していたら型不一致でコンパイル時エ
ラーにできるでしょ。つまりint型と明示的に宣言する必要はな
いわけですよ。

>>437
で、「var i = a.size()」の方が人間に親切なの？
プログラムって人間が読む/書くためのもんじゃないの？

読む(直す)立場を重視するか書く立場を重視するかの違い

>>438
intと書きたいときは書けばいいの。それがML｡
ついでに言っとくと、MLでは一度定義した変数の値を
代入によって変更することはできない。それもバグの
ないプログラムを実現するために良い仕掛け。

型推論ってのは、動的型付け言語であっても、不要な実行時型判定をしてる
部分をバッサリ取っ払うとかの用途で有効だと思う。
最適化の無いインタプリタではモロに速度に影響するでしょ。

>>439
>書く立場を重視するか
おおっ、perlとの意外な接点が!!
よってPerl=ML=糞言語

>442
きみ、理解してないと思う。

>>441
それはコストがかかる割に効果があがらないんじゃないかなあ。
ソースコード上に型不一致があると「実行時に型を決定」し、ソース
コード上に型不一致がないと「コンパイル時に型を決定」するという
話でしょ。そこまでやるなら、コンパイル時に型を決定すべき（つま
りコンパイル時に型チェックする）変数・関数・式はそれと宣言させ
た方が良いってことになる。

たとえばObjective-Cの場合、型チェックを実行時に遅らせるときに
はid型を使えば良く、コンパイル時に型チェックさせたいときにはク
ラスを特定する変数宣言を使えば良い。

ためになるので、あげ

逝ってよしというやつが逝ってよし

だれか型推論するコード書いてくれ。

なんか、最新のPerlって、Cソースコードを埋め込んで実行時にコンパイルって
いうのができるとかなんだとか

もう汚れキャラで開き直ってるんだなあって思った。

外部のＣコンパイラ起動すんの？>448
そんなのPerlじゃなくてもできるけど。
それともC->Perlトランスレーターとかかい？

Perl6はCにトランスレートしたときの効率を
結構重視していると思われ。

>>448, 449
use Inline;のことかな。
スクリプトを初めて実行したときに、うめ込まれたCコードをコンパイルして
.so(または.dll)を作成する。

二回目以降は、(ソースコードのMD5ハッシュが変わってなければ)
以前にコンパイルした.soをロードして使う。

どちらかと言うと、今までXSとかSWIGとかでガリガリ書いてた
C実装のモジュールを作りやすくした仕組と言った方が正しい。
Makefile.PLを書かなくていいとか、Perlソースと一元管理できるとか、
そういうことがメリットだと思う。

> もう汚れキャラで開き直ってるんだなあって思った。
粋狂な人がいればそういうことをするモジュール(Inline.pm)
「も作れる」ということだね。むしろ懐の深さ。

ﾌﾟﾌﾟﾌﾟﾟﾌﾟﾌﾟ必死だな（ﾜﾗ
Ruby以外の言語は糞。

>Perl6はCにトランスレートしたときの効率を
>結構重視

ruby作者も言っているが、
動的な要素の多いScript言語と静的なCとじゃ
うまく噛み合わないことが多いはずだぞ。

>>451
その程度のことしかしないなら、他の多くの言語でも出来る。
VBですら出来るだろうな。
少なくともPerlの懐を認める論拠にはならん。
尤も浅いとも言明できぬが。

>>440
つまりMLは書くための言語なのね。
「読むため」の比率が高い方がいいという考えもあり得るヨ。

>>454
はあ？
なんか全然わかってないね。MLで書かれたプログラムを多少なりとも
読めば、きわめて「読みやすい」言語だってことがわかると思うがな。
何のために「参照透過性」にこだわってると思ってるの？　プログラ
ムを読むときに各変数の値がどうなっているか「追いかける」必要を
なくすためでしょ。

たとえばフィボナッチ数を計算するコードは次のように書ける。

fun fib 0 = 1
  | fib 1 = 1
  | fib n = fib (n-2) + fib (n-1);

どこにも型宣言は出てこないが、0や1が整数である以上、nも整数なのだ。
（整数は整数同士でないと足し算も引き算もできない）
fib 0の場合、fib 1の場合、fib nの場合とで「パターン」で分けてコー
ドを書けるのもきわめて明快だと思うがな。

>>455
0や1なの? 2や1じゃなくて。

>>455
だから、そういう地べたのデータ構造扱うのは別に
どうでもいいよ。なんか大きなプログラム組むので、
抽象データ型とか定義しまくったとするじゃない
(MLでできるのは知ってる)。で、それらを利用する
コード書いてるとき、この引数はこの型とか考えて
宣言書いて、構造ができてきたら実装書いて、とか
いう順で書かないのかな。これ疑問その1。

疑問その2として、実装からバリバリ書いて型推論
あるから自分は宣言つけなくていいと思ったとして、
それを読まされる人は書いた人じゃないわけだから、
読むのがつらいんじゃないかな？それを指して「書く
人に寄ってる」と表現するのは正しくないと思う？

やらない？型推論

>>457
MLは関数型言語だから、これこれの型の引数をとってこれこれの型の
戻り値を返す関数を……という発想が先行する。プログラムを関数の
集合に還元し、個々の関数をひとつひとつボトムアップ的に実装する
ことでプログラムを実現するので、先に抽象データ型を定義しまくる
という発想にはなりにくいと思う（オブジェクト指向じゃないからね）。

引数の型にしても、リストやタプルが強力だから（LISPでは何でも
リストで解決するし、それで不自由はないわけです）、やたらめった
ら新しいデータ型を定義しないと困るわけでもない。むしろ、特定の
処理だけに使う関数を定義するのではなく、より抽象的な汎用性の高
い関数を定義することに関心が向かうはず。

たとえばC++でもテンプレートってあるでしょう？　あれみたいに任
意の型に対して処理を行う関数を書くことができるし、LISPでいう
mapみたいな処理を使って手続き抽象を行うこともしばしばだから、
457さんの心配しているような世界とは根本的に違うんじゃないかと
思う。

>>456
1や2と書いた方がわかりやすかったね。
でも、0や1でも正しいのです。
整数を引数にとって整数を返す関数定義であることは1行目で自明なので、
他の行にそうではない定義があれば型不一致のコンパイル時エラーになります。

つーか、MLは数学的定義とプログラムコードが対応しやすいように
設計されてて、MLのコードを見れば、その数学的な意味がつかみや
すいようになっているわけ（MLプログラマはそのように意識してコー
ドを書くということでもある）。

（たとえば）Cのコードから、その数学的な意味をイメージすること
は困難である場合がほとんどでしょ。そういう意味では、Cに代表さ
れる手続き型言語はどれもこれもコメントなしには読んでられない
わけよ。

プログラミングを関数書きにmapする、という発想が
今なにかソースを書こうとしてる自分にとって
自然な発想かどうか？という問題だな。

>やたらめったら新しいデータ型を定義しないと困るわけでもない。

OOPでいえばBuilderパターンって奴ですな。
単純なObjectをかき集めて大きな複合Objectを作る、
という手順を書くというパターン。

まぁ定義というほど大げさなもんじゃなくて、
prototype型OOPみたいな奴だと
かなりLispに近い世界だと思うが、どうか？
クラスが無いから、インスタンスをコピるか
属性(大抵は参照)をいじるか、どっちかしかできない。
CAD/CDRの世界と殆ど同じだと思う。

逆にいうとそういうBuilderを運良く(わら)1つにまとめる
ことが出来たならば、それをClassというものにする
ことが出来る言語、ってのもある、というだけのことだ。

#C++は痛いよ。OOPの本質を考える暇を与えてくれないから。

>たとえばC++でもテンプレートってあるでしょう？

C++のアレは、任意の型といっても、
構造かまたはInterface(字面の)が
事前に決めといた奴であることが前提なんで、
あんまり高度(抽象度の高い)なことは出来ないと思われ。

>Cに代表される手続き型言語はどれもこれもコメントなしには
>読んでられないわけよ。

それは変な主張だな。任意(?)の言語のソースを数学に「おとす」ことが
可能でありかつ人体にとって自然だ、という前提が必要だろう。
でもそれは常に言える前提か？
俺ぁ数学の式にこそコメントを書きたいと思うことが有る(わら
俺の体にはあれは自然だと感じられないので。

蛇足だが、プログラミングにおいて短い変数名を
妙に愛する奴がたまにいるが、あれは数学畑から
持ちこんだ悪い病気だと思う。

>>459
てことは、全パターンひっくるめて型が推論されるわけ?

>>462
まさにそのとおりです。
関数は意味のある戻り値しか返さず、たとえば引数が定義域外だった
場合などには例外を投げます。逆に言えば戻り値が返ってくるかぎり
は確実に有意味であり、型一致も保証されているのです。

>>461
そうねえ……バグのないプログラムを指向していくと、プログラムの
仕様を形式的に定義することに行き着くと思うんだけど、形式的な仕
様定義はどうしたって数学的な記法・発想法に基づかざるを得ないと
思うんだね。

それをより抽象度の低い（具象性の高い）方法で実現しているのが、
Eiffel流のAssertion（事前表明、事後表明による、programming
by contract）もひとつの方法だよね。

> 蛇足だが、プログラミングにおいて短い変数名を
> 妙に愛する奴がたまにいるが、あれは数学畑から
> 持ちこんだ悪い病気だと思う。

形式主義の立場からすれば、任意の型について有効な関数は、無意味な
変数を象徴的に使うことが本質的だと思われ。

型チェックをコンパイラにやらせるというのは、
1) 実行時に型チェックすると実行時効率が落ちるから
2) コンパイラで検出できるエラーはコンパイラに検出させるべきだから
ということに理由があるけど、Javaなんかはキャストを多用せざるを得
なくてウザいってのはあるよね。

たとえば、動物族を格納するコンテナがあるとして、そこに格納された
動物の正確なクラスを実行時に調べて、そのクラス別に処理を変えたい
ような場合（その動物がライオンであれば吠えさせ、サイならば突進さ
せる、みたいな処理）はキャストがどうしても必要になる。でも、その
キャストって本質的なのかなあって気がするときがしばしばなのよね。
実行時にクラスを調べて、キャストしてからクラス別の処理に入るみた
いな仕組みは動的な関数ディスパッチより、かえって効率落としてるん
じゃないかって思うんだけど……。

Objective-Cのように実行時に関数ディスパッチすることを選択できれ
ばキャストは不要なのにって思う。

>>458
分かりました。オブジェクト指向じゃないのなら私の知らない
(というか普段使わない)世界なので引っ込みます。

オブジェクト指向で大きいもの作るなら「たとえ型推論があった
としても」明示的な型宣言をする方がよいと考えていますが、
それは関数型パラダイムとは別のオハナシ、ということなのです
よね。

>>465
それは、「ライオンなら吠え、サイなら突進」という動作に対応
するメソッドを定義して、ライオンとサイで別のコードを貼り付
けておき、dynamic dispatchに仕事をさせるべきなのです。Java
でキャストを必要とするのはむしろ、「生き物型」の変数に「動物」
を(サイでもライオンでも)入れてあって、それをまた「動物」と
しての扱いに戻したいといった「視点の切り替え時」じゃないかな。

で、Javaでこれが多用されるのは、型パラメタがないためコンテナ
には全部Objectとして入れて、出して来たらまた元の型にキャスト
し戻す、というのがやたら多いせいでしょ？

>>466
吠えるのと突進するのを同名のメソッドとして定義するってこと？

>>467
「敵対行動をとる」といったような一般化されたメソッドを考え、
ライオン⇒吠える、サイ⇒突進、
といった具合いに特化したメソッドで実装する。

このメソッドを利用する側からみれば、
テンプレートメソッドパターンということになるのでは。
でも、OOSEに説明されているようなメソッドスペシャリゼーションの
問題が浮上してきそうではありますな。

>>468
なるほど...でも、ちょっと苦しくない？
敵対行動が一種類しかとれないとは限らないし（クラスによって、
特化したメソッドの種類と個数が違うなんてことはありがちでし
ょ？）。

Javaって、関数ディスパッチを実行時に遅らせる方法ってあるん
だっけ？

抽象データ型の定義の際に、定義域を明示的かつ簡便に定義できる
言語ってあります？ あったらいいな。

int height(min: 100, max: 200)

みたいにすると、heightは100以上200未満の整数しかとらない、みたいな。
現状ではセッターを定義して手作業でチェックしないといけない言語ばっかり
なんですけど、すごく頻繁に使いますよね？

>>470
Pascalがある。

type height = 100..200;

と定義すればOK。

>>470
Adaがそうです。
タイプを定義するときに範囲を指定できます。

    type HEIGHT_TYPE is range 100 .. 200;
とか、
    subtype HEIGHT_SUBTYPE is INTEGER range 100 .. 200;

とかいった具合いになります。

>>470の関数宣言の例
> int height(min: 100, max: 200)
だと、

    procedure HEIGHT(X: in HEIGHT_SUBTYPE);

といったところになるでしょうか。

>>435
明示的に関数の型を宣言した場合にも、
その型宣言の中で型変数を使ったら(つまり多相型の場合)
それらの型変数に関して型推論しなきゃならないと思う。

というわけで型推論は宣言の手間省きだけじゃあないと思う。

age

詳細知らんけどschemeにも型推論するパッケージがあるらしい。

>>468
>なるほど...でも、ちょっと苦しくない？
>敵対行動が一種類しかとれないとは限らないし
それこそテンプレートメソッドの出番なのでは？
敵対行動がいくつかあるなら、それを選択するのはそれぞれのクラスの責任で。

Javaにも型指定ができるコンテナが欲しい。。。あるのか？

久々にage

>>477
ｱﾎ?

荒しは放置 > ALL

>>479
なんか、さっきから「アホ？」「バカ？」ってのが多いね。

>>476
最初は JDK 1.4 に載せるといってたけど、結局は間に合わなかった。今のスケジュー
ルだと 2003 年にリリースされる JDK 1.5 に載ることになってる。

そういうわけで公式にはまだだけど、Java に Generics を加えるプロセスは進行中で、
プロトタイプは出た (jsr14)。既に Public Review 期間終わってるけど、いちおう公式
ページへのリンク張っときます。

http://jcp.org/aboutJava/communityprocess/review/jsr014/index.html

関連ページ

GJ
http://www.research.avayalabs.com/user/wadler//pizza/gj/index.html

PolyJ
http://lirone.lcs.mit.edu/polyj/

型なし変数ってヒープ領域に陣取ってるの？

>>423
> 型チェックはコンパイル時と実行時があります。
> 1 コンパイル時と実行時に型チェックする言語(静的型付け)
> 　　C++ Eiffel
> 2 実行時に型チェックする言語(動的型付け)
> 　　Smalltalk lisp scheme

Common Lispは、変数や関数だけじゃなくて、式の型も宣言できる。
多相性を損なわないかなり柔軟な形で。静的なcheckを行なう処理系あるし。
完全ではないし、まったくやらないでもいいから、1と2の中間くらいだな。

Lispの性質を露わにして面白いから、型に関心のある人は読んでみ
http://www.math.uio.no/cltl/clm/node103.html
http://www.math.uio.no/cltl/clm/node44.html

>>435
> 型推論って型の明示省けるっていう
> シンタックスシュガー以上の意味はあるの？

省いた型宣言を他から推論するという意味においては、
高階関数がない言語ではprogrammerにとってそれほど強力な武器ではない。

ただ、ここでいう推論は論理学でいう推論なので、
型の充足性のcheckが行なわれるだけでも「推論」です。
つまり型の整合性を調べるための汎用の枠組です。

∀とか∃を使った論理式の推論と多相型やパッケージの型推論の数学的関係がはっ
きりしているから、どういう型構造が型推論が出来て、それが現実のプログラミング
言語の要素とどういう関係にあるかはっきりしている。

今時の強い多相型を持つ言語を設計をする人には必須の教養。
C++のtemplateのように型変数持てば、必ず型推論と同じ事やるわけだから。

>>482
> 型なし変数ってヒープ領域に陣取ってるの？

基本的にはそうだが、最近関数型言語では、静的な解析によって、
stackに置いたり、type tagを省いたり(unboxing)する。

Adaは理論的に美しくて好きだったけど、厳密すぎて生産性は良くなかった。
VBでは、とりあえずVariant型で動くプログラムが作れる。
仕事として利益を上げるには、ある程度割り切りが必要かなと思う今日この頃。

＞とりあえずVariant型で動くプログラムが作れる
これが生産性が高いことだと思っているのなら
大変な勘違い。
VBの生産性が高いのは別の理由。

動的な型システムがないために面倒なコーディングを強いられるって
こと、現実にはあるよ。分析・設計がなってないって言われるかも知
れないけど、そのあたりは場数を踏まないとスキルがあがらないんで、
初心者のうちは多少バギーでも、とにかく動くものができるだけで自
信がつくってのはあると思う。

# そこで止まっているベテランは困るけどねー

>>486
良く知られていると思うが、STLはAda上での汎用コンテナの研究の成果。
Adaは抽象的な仕様を持った強力な言語だった。

じゃあAdaについて「厳密すぎて生産性が良くない」って指摘はどうなの？
俺はあたってると思うけどー。

昔のことでうろおぼえだけど
ひとつの関数で引数の型が複数あるような場合、型の数だけ同名のの関数を
作る必要があったような。
正の整数でも「０」を含むかどうかで「NATURAL」「POSITIVE」という異なる型
になり、使い分けに気をつかった。（コンパイラが厳しい）
文法はスマートで好きだったけどね。

C++のテンプレートなどに見られる総称型は、
厳密で静的な型であるにもかかわらず関数は
一つ用意するだけでいい。
つまり、不必要に関数を増やさなくて済む
というのは型の無い言語の利点では無い。

こんなのどう？
テキストファイル開くときの、ファイル番号は何型だったっけと悩んだとき
・まあいいや Variant型 でコーディングだ〜 5秒中断
・ヘルプで調べて正しい型でコーディングすべきだ！ 2分中断
この違いが、最終的な工数（利益）に大きく影響する。
言ってて自分でも いいかげんだな〜と思うけど一理ない？

>テキストファイル開くときの、ファイル番号は何型だったっけと悩んだとき
意味不明

ところで
name compatibilityと
structural compatibilityについては
みなさんどんな嗜好をおもちで？

>>493
MLみたいな型推論があれば、明示的な型宣言は不要。
その上で、型不一致は検出してくれるからね。
もちろん動的な型システムでも、破壊的な代入（初期化以外の代入）を
意識的に避ければ似たような効果は得られるけど、実行時効率は静的な
型決定に及ばないからな。

MLの詳細情報きぼ〜ん

MLとは型を明示しないことでソースの可読性を下げることが出来、
これによって読み手が型を推論する必要が出てきます。
これを型推論と呼びます。

型推論はML（StandardML）というか、ObjectCaml、Haskellなどの
代表的関数型言語に共通の特徴だね。

>>498
>MLとは型を明示しないことでソースの可読性を下げることが出来、
ワザトか？(w

型無し言語というのは値に型があって変数に型が無いということ。
つまり、型推論の時と同じように変数に格納されてる値の型を自分で推論する必要がある。
結局、型推論でも可読性は型無し言語以上に下がらない。

>>495
structural type compatibilityを採用している言語ってどんなの?
研究途上だったらいろいろとあったような記憶がおぼろげながらあるが…

>>501
型推論を採用してる言語でも宣言をつけることができるしね。
状況によって宣言をつけるか省くか都合のいい方を選べる。

>>498
可読性の話をするなら、だらだら長い関数定義こそが一番だめだよね。
関数型言語で関数定義するとき、だらだら長い関数定義になる例って
あまり見かけないけどね。CやPascalの方が、だらだら長い関数定義
を生みがちだと思う。偏見？

>>504
たしかに、関数型は余計な準備無しにダイレクトに表現してるって感じがする。

>>502
んー、Modula-3とかそうだったと思う。
一応コンパイラも実装されてるよ。

関数型言語において関数を定義するときは、引数の定義域について、
よくよく厳密に考える癖がつくな。個人的な体験だけどね。

手続き型言語で関数を定義すると、どういうわけか、定義域につい
ていいかげんな態度をとってしまいがち。境界情報にバグが潜むと
いうのは常識なのに、与えられる入力について楽観的に考えてしま
う傾向が、手続き型言語でプログラミングするときには、なぜかあ
るなあ。

>>498
慣習の話だけど、
Haskell みたいに関数の型ぐらいは
明示したほうがよいとは思う。

>>504 >>507
同意

age

>>507
関数型言語だと、何が来た時に何を返すかを考えるわけだけど、
手続型言語だと、何時、何をどうイヂルかを考えるわけで、
その辺の違いじゃないかな。

んなこたーない

>>464
Bertrand Meyerはopen and closed moduleにstatic typingは必須だと言ってるが、
本当にそうなのかな？
Eiffelのassertion自体、実行時検査にしか使っていないんだから
dynamic typingな言語にassertion実装してもヨサゲに思うのだが。
浦島でスマソ

>>512
動的言語ならassertionぐらい各自で実装できるのでは？
そういう意味じゃない？

>>512
staticに出来る事はstaticにやるにこした事はない、という主張でしょう。
Meyerの立場からすれば、当然の方向かな。俺はLisp好きだけど。

>>513
言いたかったのは、なぜMeyerはstatic typingに拘るのかなー
っつー素朴な疑問なんだけど。
インスタンス変数やメソッドの引数に指されるオブジェクトの契約も使いたい、
っつーことかなー、と、何となく思ってたんだけど、でも、
実行時にのみ検査するだけなら、別にstatic typingかどうかとは関係ないかなー、
と思ったんだ。
まとまってなくてスマソ。

まあ、それはそれとして、
動的言語にadd-hocにassertion実装するにしても、
それを継承とスリ合わせたり
(postcondition, precondition, invariantの継承)、
bytecode毎に必要なinvariantのチェックしたり、
結構compiler自体に手を入れなきゃいかん部分が
多いように思われ。

>>515
おれには難しすぎてわからん
もうちょっとやさしく説明してほしいぞな

>>515
おれの理解では、programming by contractを強制するために
assertionがあるのだと思っている。モジュールが何に責任を持っ
ているか表明することによって、たとえば事前条件がマッチして
いるのに事後条件がマッチしないとすれば、モジュール内部にバ
グがあるとわかるみたいにね。

static typingにこだわりがあるのは、モジュールの利用される
「文脈」を限定したいからでしょう。つまり、モジュールの有効
範囲をあいまいさのないかたちで表明するためには、static
typingによるコンパイル時チェックで支援するのが有効だという
考えですよね。違うかな？

るついでに
話の流れからすると要するに、動的言語でもassert()を入れろって事ですか？
>>464 のEiffel流、ってどんな感じでしょうね。

>>518
関数の入出力について、型チェックの他に、
意味的に正しいのか判定するということなんじゃないかなあ・・。
それを処理の事前、事後にassertすると。

型揚げ

>>515
static typing にこだわるのは型の宣言が assertion の一部だから。

1.　a　　　　　　　　　 -- なんでも代入できる。
　　invariant a>0

2.　a: INTEGER　　　-- a は INTEGER型
　　invariant a>0

1 の invariant は a が INTEGER型ということを保証できないので不完全である。
というわけで
動的型付けの言語の assertion は最初に型チェックするコードを書くことになる。

動的型付けの言語の柔軟性もほしいし assertionもほしいとなると
Objective-C のような型チェックにするのが無難だと思う。

>結構compiler自体に手を入れなきゃいかん部分が
>多いように思われ。

Smalltalkならメタクラスをつかえばできると思う。

assertionそれ自体は動的型付けでも静的型付けでも実装できますよね。
むしろ動的型付けの方がassertionの考え方には馴染むし。
静的型付け言語において効率の良いassertionを実装する方が、はるかに
困難な気がするなあ。

型がある言語の利点 :
プログラマが変数内に格納されている値についての型変換処理を記述する手間が省ける。
型がある言語の欠点 :
仕様上予期しない型の値が入っていた場合に、問題を見つけ出すまでが一苦労。

変数(というかメモエリア上に)にどんな種類の値が入りうるのかを、
プログラマがきちんと意識しておかなくてはならないのは、
どんなプログラム言語でもいっしょ。
その中身を使う時には、「どんな型の値が入っているのか」を考えなくてはいけない。

プログラムを解析する際に、型がある言語の場合なら
あらかじめ入りうる値の型を、変数の宣言と定義を見るだけで
把握可能だが、もし型がないと、最悪その変数の値を使用する
処理ロジックまで追っかけなくてはならなくなる。
数十行の程度のスクリプト言語での記述なら、
追いかけるのもさほど苦労はないだろうが
これが数千行や数万行のプログラムだったとしたら・・・

#「型の有用性」をきちんと意識して、それでもあえてVariant型のような
# 汎用型を使っているVBプログラマばかりだったらいいんだが。
# 保守性や可読性に頭が回らない「ぱーぷープログラマ」がこれを使って
# 書き散らしたプログラムを保守しなければならなくなった場合のことを
# 考えると鬱になる。

>>523
そういうのもあるけど、型ありの一番の利点は散々言われてるように
ミスを事前に報告してくれることだと思う。
これによる恩恵は計り知れない。

強い型付けをもった言語の場合、コンパイル時にすべての変数や
式の型が決定しているから、実行時に型をチェックする必要がな
い。だから実行時効率が良い。それが最大のメリットだよね。

>>523で言われているようなことは、型付けが強くても弱くても、
事前条件や事後条件をチェックすれば済むことであって（逆に言
えば型付けが強くても事前条件や事後条件をチェックせずには済
まないケースも多々あるということ）、型付けの主たる理由では
ないと思う。

>>524については同意。要するにそのルーチンの有効な文脈を定
義できるから、不正な文脈でそのルーチンを使うとコンパイラが
発見してくれるってことだよね。機械的にチェックできることは
機械に任せる方が良いって発想ね。

# でも、遅すぎるコンパイラもまた実用的ではないねー。
# 開発中はインタプリタとして動作し、安定したソースからバッ
# クグランドでインクリメンタルにコンパイルしてくれる
# Smalltalkの処理系みたいなのを、強い型付けの言語で実現し
# ている処理系はないかしらん？

>>525
SML/NJ．ただし速いかどうかは謎．

動的型付けの言語は事前条件や事後条件に型チェックを含む必要があるので
その分遅くなるのはデメリットだと思う。

>>525
> 強い型付けをもった言語の場合、コンパイル時にすべての変数や
> 式の型が決定しているから、

型の強い弱いと動的静的を混同している。
ある程度因果関係があるのは確かだけど。
Dynamic polymorphismを持ったstrong typedな言語の例。>>526

> 実行時に型をチェックする必要がない。

型が、静的でなければ実現できなくて、強ければ強いほど効果的になる、という関係。

型チェックって、そんなに高くつくの？
事前条件や事後条件の検査の方が高くつきそうだけど。

動的型付けのオブジェクト指向言語の場合、当然メソッドディスパッチが実行時
に行われるけど、それは高くつきそうな気がする。静的な型付け言語の場合、メ
ソッドディスパッチがコンパイル時に行われているのが強みでは？

んで、SML/NJって、動的なポリモーフィズムなの？
SML/NJにおけるポリモーフィズムって、型変数を引数にもてるってだけじゃん。
動的なメソッドディスパッチとかしないと思うんだけど...？

# もし、違ってたら、知ったかでスマソ。

>>529
いや、引数としていろいろな型を取る関数とかかけますよ〜
（関数の中でその引数に対して使われる関数や演算子もそうならば）

>>530
あ、それはそうだった。
でも、そのメソッドディスパッチって動的に行われているの？
俺にはコンパイル時に静的に決定している気がするのだがー。

>>531
Javaのinterface型の変数へのメッセージ送信では
動的型付け言語と同じコストがかかる。
(同一interfaceをimplementsしているclassは型階層上の任意の個所に
出現しうるから)

class型の変数へのメッセージ送信ならオブジェクトのclassは変数の型の
subclassに限定できるからvtable参照だけで済むけどね。

>>531
コンパイル時に決定してる。動的なディスパッチはしない。
ただ、代数型のタグを区別するのはcaseで動的にやるけど...

型って根本的な意味はデータ幅のことだろう。
それを意識しないでソフト書くと言うことはプログラムサイズやメモリ容量は
考慮しないと言うことだな。
でもハードが高速になって、メモリも大量につめばそのうち
生産性から形無し言語が当たり前になるかもよ。

そいつぁオジサンも形無しだ

>>534
型無し言語って変数に型がないだけだろ？
データ型の概念が皆無な言語なんて無いよ。
たとえアセンブリ言語でも。

オブジェクト指向の高級言語は型が無くてもいいんでは無いかい？
アセンブラは型が無いと書けないよ。
って言うかそれが〜ビットＣＰＵのアーキテクチャだ。

>532
interfaceのvtable作ってないの？(Javaは知らない、COMは作ってたと思った）
>533
対話モードの時とか……

>>537
クラスは型の一種だろ。

>>523
> 型がある言語の欠点 :
> 仕様上予期しない型の値が入っていた場合に、問題を見つけ出すまでが一苦労。

今更だけど、こりゃ酷い誤解だなあ。
問題があるから、仕様上予期しない型の値が入ってしまうわけであって、
型無しの言語だと、実行して現象を観察するまで予期しない値が入った
ことすらわからない。なかなか実行されないコードだったらなおさら
わかりにくくなる。
それが、型があると問題があることがコンパイル時にわかってしまうから
格段に問題を見つけ出すのが簡単になる。

問題を見つけ出すのが容易なのが、型がある言語の長所だよなあ。。

>>540
Cみたいに型チェックが甘い言語と、
も少しまともな言語（Javaとか）を比べると、
後者の方がコンパイル通るまでは時間かかるけど
動くまでは早いね。

でも、LispやSmalltalkの生産性が高いといわれるのは
なぜなんだろう？

>>541
Smalltalkはオブジェクト指向を追及した斬新な発想で、
多くの有能なハッカーをひきつけたから。
そういう人たちによって作られた開発環境もレベルが高い。
Lispも同じように、驚異的な柔軟性で当時の学問畑の人
を引き付けたし、その柔軟性で生産性は高くなる。
だけど、こういうマニア向けの言語でも、最近は型有りの
SMLやHaskellが登場してる。

型の種類
1.チビ
2.厨
3.ﾃﾞｶ

これらに適当なサイズを割り振ってしまえば
これぐらいでいいんじゃないの？
メモリ容量、速さを意識しないんで有ればの話だけど。

>>541
まず、Smalltalkの場合だけど、デバッガが強力なのと、
UnitTestに代表されるようにSmalltalkに適した開発技法によって
動的に型付けする言語であることの欠点がカバーされている。

静的に強く型付けされた言語ではコンパイル時に型不一致を教えてくれるけど、
経験を積んだSmalltalkerはSmalltalkの急所をわきまえていて、
それをうまく回避する知恵を身につけているってことだな。

その弱点さえ克服してしまえば、明示的なコンパイルは必要ないし、
書いたコードはその場でテストできる。だから開発効率が良い。
強く型付けされた言語のコンパイルが、
しばしば重い作業になることを思えば、
コンパイルせずに書いたコードをテストできるメリットは大きい。

Lispの場合も同様で、
書いたコードをすぐさまテストできることのメリットは
大きいといわざるを得ないね。

強い型付けの言語は、各クラスやメソッドの適用範囲を厳密にするが、
その分、開発初期の設計上の決定が後々まで影響することが多い。
スパイラルな開発工程を前提にすると、
型付けの弱い動的な言語の方がプロトタイピングに適しているので、
採用されやすくなる傾向はあると思う。

>>543
利点が良く分からない。実装が楽になるとか？
ocamlみたいに、Cと同等の効率の処理系がすでにあるのに、
なんで効率を落さなきゃならん？

>>544
大筋で同意なんだけど、もうちっと突っ込むと、
refactoringに関しては静的/動的で向き不向きはあるのかな？
って問題があると思う。
もし大差ないんだったら、それは言語自体の問題じゃなくて
運用(あるいは開発チームの文化)の問題だよね。

>>538
やれば可能だけど、class型の変数へのメッセージ送信のように
単純かつ効率的じゃあなくなる。
例えば単純な実装方法を一つ考えてみると、

1. まずは各classについて、そのclassがimplementsするinterface
　　ごとにvtableを用意する。
　　(classとinterfaceの組み合わせ個数のvtableが必要)
2. message receiverから変数の型として宣言されているinterface用の
　　vtableを引く。この時、compilerはinterface名しか知らない事に注意。
　　(classからinterface用のvtableを参照するテーブルを単純な配列で
　　実装するのなら、システム中の全interfaceの個数分のサイズが必要で
　　それを実行時にもclass毎に用意しておく)
3. 得られたinterface用のvtableでmethodを引いてdispatchする。

実行時にclassをloadしたりしないという前提でも、これだけ面倒な事になります。
また、実行時にclassをloadしなくて、かつ、これだけvtableのために
メモリを使う余裕があるのなら、動的型付け言語でも同様な事ができる。
つまり、各class毎に、システム中全てのmethod名についてのvtableを作ればいい。
これなら参照が一段で済むから、上記のinterface用vtableよりずっと速い (藁

>547
なんですべての組み合わせ個数必要なの？明示的にimplementsした分だけでいいでしょ。

　　

2が意味不明

俺は547じゃないが

>>548
interfaceごとに数字をふって、それをindexにして
classのinterface表を引く→vtblが得られる。
プログラム中にinterfaceが100あるとしたら、
classのinterface表の大きさは100になる。

これはclass　×　interface　→　vtbl
という表を作ってるのと同じ。
もちろんスカスカの表だが。

>>549
MyInterface i = ...;
i.interfaceMethod(...);
としたとき、

(1) iのクラスのインターフェース表を、
　　MyInterfaceにふった番号で引く。vtblが得られる。
(2) vtblをinterfaceMethodの番号で引く。methodが得られる。

>>547の最後は、classとinterfaceに通し番号をふって
(class　or　interface)　×　method名　→　method入り口番地
という表を作れと逝っているのだな。

こういう表をダブル配列に圧縮して持つという
Smalltalk処理系があるよ。

>550
どうも。
でも静的な言語なら、>>547の2まではコンパイル時にできるから実行時には関係ないし、
コンパイル時なら、表でやってもいいけど、リストで線形検索でもいいんじゃないんですか？
Javaについての話じゃなかったんですか?>>547
>Smalltalk処理系があるよ。
面白いですね。

>>551
＞でも静的な言語なら、>>547の2まではコンパイル時にできるから実行時には関係ない
そうでもないよ。例えばリフレクション機能のことを考えてみてくれ。
まあどこまでを静的/動的というかによるが。

>>551
どうやって静的にやるの？
コンパイル時に分かるのは
インターフェース名とメソッド名だけで、
実際のクラスは実行時まで分からないと思うんだが...

例えば
void foo(MyInterface i) { return i.interfaceMethod(); }
をコンパイルするときとか。

(C++はどうやってるんだろ？)

>>546
リファクタリングは静的で強い型付けの言語でもできる。
でも、静的で強い型付けの言語で開発を行うときは、
いかに無駄なコンパイルを避けるかが効率的な開発の肝となるよね
（少なくとも心理的には）。
すると、いきおい分析・設計フェーズをしっかりやろうという気分
になるね。それはそれで良いことだけど、プロジェクトによっては
早くプロトタイプがほしいってことはあるんじゃないの？　オレは
頭悪いから、自分向けにもプロトタイピングしたいぐらい。だから、
静的な言語はやや苦手だな。

>552
あ、そうですね。
>553
iにはMyIntefaceのvtableについての情報を与えられる。
クラスからインターフェースをつりだす処理は呼び出し側の位置でコンパイルする。
って感じだと思いますけど。

>>555
うーん、そうだね。理論的には可能な気がしてきた (藁
特に純粋なコンパイラ言語なら実装してみると面白そう。

ただJavaでの話に限定すると、
現状のJavaVMのinvokeinterfaceの仕様ではvtableを渡すことはできないのが残念。

ちなみに
547でcompilerといってるのはVMというべきだったね。
スマソ。

>>
インターフェース型の変数は、オブジェクトへの参照だけじゃなくて
オブジェクトとvtblへのポインタの2つ（またはその２つのペアへの
ポインタ）を持つようにするとか。

クラスCがimplementしているインターフェースI1, I2, ...ごとに、
getVtblI1(), getVtblI2(), ...,という隠しメソッドを作っておく。
インターフェース変数に代入するときや、インターフェースを引数に
持つメソッドを呼び出すときには、これらを使ってvtblを取り出す。

インタプリタでは面倒だが、JITならできるかも。

>>558
method dispatchingというより、interface型へのtype castingで押さえるべきだね。
ただ問題はmethod dispatchingなりassignmentする時にvtableを渡そうとすると
bytecodeの仕様にも手を入れないといかんこと。

ある関数を書くときに、引数の型をどこまで厳密に意識できるかな。
不必要なまでに型の範囲を厳しくすると、使いにくい関数になるよね。
たとえばIteratorパターンを実装するときは、必要なメソッドが定義
されたインターフェイスを継承しているなら、あとはどんなオブジェ
クトでも問題ないわけさ。こういうのが良いパターン。
動的な言語なら、必要なメソッドを持っていないオブジェクトが実行
時に発見されると例外が投げられるだけで、コンパイル時にはわから
ない。たしかにこれはよくない。
でも、その関数（メソッド）の引数が「本質的」にどのような性質を
持っているべきか（どんなインターフェイスに対応しているべきか）
を関数を作っているときに見通せるとは限らない。その関数が処理す
る問題についての深い洞察と経験が必要になると思う。デザインパター
ンだって、一朝一夕に発見されたわけじゃないわけだし。

だから、プロトタイピングには動的な言語の方が便利だよね。でもっ
て枯れてきたクラスは、静的な言語に移植すると良いんじゃないかな。

>>560
あと、最初から適切なインターフェースを定義できるかって問題もあるね。
必要になりそうなメソッドの集合があったとして、
それを重なりなく適切なグルーピングを施さなければいけない。
で、後々定義されるであろうクラスにピタリとフィットしなければいけない。
かなりの洞察力がいるな (藁

やっぱ俺は動的言語がいいわ。

動的な言語なんて嫌だな。
デバッグに何時間もかけて非常嫌な思いになる。
型でどれだけ助かってることか･･･

>>560
わからないときは暫定的に適当な型を決めておいて、やってる途中で
型を変えたくなったら、ソースコードを変更すれば良い。

で、変数の型無しな言語だったらソースを変えなくて良いかって言うと
そうでもない。
だって、いくら変数に型の無い言語でも、ある特定の関数の引数には
扱えない型の値と扱える型の値があるんだから、型にあわせた関数に
変えなくちゃいけないからね。
変数に型の無い言語には、引数の型によって処理を変えてくれる関数って
のもたしかにあるけど、それは型あり言語のポリモーフィズムと全く
同等でしょ？
ま、確かに型有り言語の方が最初から受け入れる型を狭めやすいコードを
書いてしまいやすいってのはあるけどね。テンプレートとか継承とか
面倒だからね。

で、変数に型の無い言語の利点て、そういうのよりも、柔軟な言語仕様
にあると思う。特異メソッドとかね。

>>563
特異メソッドってなんですか？

>>564
オブジェクト固有のメソッドのこと。
Rubyの方言かもしれない。

じゃあ知らんわ（ｗ

>>564
プロトタイプベースのオブジェクト指向言語にある機能のひとつ。

やっぱ遊ぶならlispがいい。
構文解析がほとんど必要ない事でインタプリタ自身がそこそこ速い。
eval呼出しのオーバーヘッドは、インタプリタの速度を許容できる
なら無いと言っていい。ホットスポットには、動的にバイトコード
にコンパイルすれば良い。いつでもＳ式に対して最適化を施す事が
できる。

アホには使えん言語

>>565 普通はメタメソッド(meta method)と呼ばれる。

>>563
俺的には、
型自体は正しいプログラムを書くために必要な事だと思う。
しかし、多くの(オブジェクト指向)静的型付言語では
変数の型とオブジェクトの型が混同されているんじゃないかと思う。
少なくともclassを変数型として使うのは変な話だ。
実装上の型階層への依存と制約を増やしてしまう弊害が大きすぎると思う。
interfaceの集合を変数型として使い、classをオブジェクトの型として使うのなら
静的型付もアリかなと思うが。

まともな議論は会社員が寝た後にはじまるなぁ（しみじみ）

>>572
型理論やってるやつもいるかと思えば、なんだかわかんないうちに職業プログラマになったやつもいるので、
まあ、しかたないっちゃしかたない。
ちなみに俺も昔は学生だった。

強い型付けを指向していくと、やっぱりMLとかHaskellに至る気がする。
単に型を型チェックのために使うだけでなく、プログラムの「意味」を
明確にするために使うという方向へ進むことになるんじゃないかなあ。

Eiffelがなんだかんだといってassertionを多用するのって、ad hoc
な印象をぬぐえない。事前条件や事後条件が、内部コードから明らかで
ある方がエレガントだと思う。

# あえて愚直に事前条件や事後条件を表明させることによって、
# programming by contractを強制させるって意図はわかるけど。

同意。「条件を漏れなく思いつかねばならない」ってのがだいたい危うい
ような…

事前条件・事後条件ってのもなんだか大昔の公理的意味論（Hoareだっけ？）
みたいで、形式的な証明には役に立たなさそうだし。

>>574-575
ただ、Eiffelのassertionも、無いより遥かにマシだよね。
「assertionを正しく記述できなければいけない」というのは実行不可能だが
設計者に本人が網羅した可能性をドキュメントとして残させる、
という機能には大きな意味がある。
つまり、assertion自体の間違いは排除できないが、
設計者の想定の誤りを発見するには
それを記述してもらわないと、どうしようもない。

parametric polymorphismとtype inferenceマンセーは全面的に同意。

終了？

small talkもlispも実際の開発では使われてない理由は何？
型無し言語は生産性が低いってこと？

>>578
ログ読んでから書け。

作ってる段階で静的型なんか必要無い。
でも、完成した後で実行時エラーは勘弁。
例外保護は論外。
これ以上変更する必要が無いと判断できた時点で、
ガラっと型有り言語(の効率)になって欲しいもんだが。
勝手に適切な型を付けるという、型推論の概念をもっと一般化して、
型推論だけをモジュール化できないのか。

型とbit数がいまいちはっきりしないＶＢも消えてほしい。
Anyってなんやねん。
intが未だに16bitなＶＢは消えてほしい。

>型とbit数がいまいちはっきりしないＶＢも消えてほしい。
Cも消えろ
なんで最初からビット長明示した型つけねーんだよ

VBマンセー

>>583
Perlマンセー
逝ってきまーす

longが32bitのままなら64bitCPUではintの方が長くなる。

ﾊｧ?

>>585
C の話をしているなら、それだと規格準拠でなくなるぞ。

sizeof(long)=8なPS2は逝って欲しい

>>580
*完成*しているのにエラーが出るとはこれいかに。

>>580
いつ「完成」とみるかが問題と思われ。
「書きっぱなし、後は知らねー」開発なら簡単だけど、
実際にはそうはいかないよね。

リリースした後もバージョンアップとかあるわけで、
じゃあ型無し版(開発用)と型有り版(リリース用)と
2つ同時にメンテする？って話になっちゃう。

>>580>型推論だけをモジュール化
それ、結構面白いかもしれない

>>591
型付けの弱い言語に型推論付きのソースレベルデバッガがあればOKって話？
たぶん、それは無理だよ。推論を前提にした言語設計になっていないと、無理。
SML/NJでも、推論に時間がかかりすぎる可能性はあるんだし。

不正な型のオブジェクトを与えられたときに確実に適切な例外を投げるように
UnitTestしてやって、きちんと例外処理を書くってことでどう？

>>592
そういう設計の言語を新たに作れれば良いと思ったんだよね
どうせ作るなら、今ならアスペクト指向言語

>>593は型推論がよくわかってないに1票。

>>593
明示的に型チェックを要求しなければ、動的な型付け言語として
動作するＭＬみたいなもんかな。たぶん、それは駄目だね。

単にＳｃｈｅｍｅあたりでプロトタイピングしてから、ＭＬに移植って
線になるだけだと思う。あ、でも、あれか。それってＤｙｌａｎっぽい
かも。

>>592
LackwitとかStrongtalkとかのイメージかな。
LackwitはCに対して型推論をする。例えば同じintでもそれを多相型とみなして型推論する。
理屈としては面白いと思う。
StrongtalkはSmalltalk + parametric polymorphism + type inferrenceみたいな感じ。

age

>>596

Lackwitのような物は結構研究されているよ。

例えばMicrosoftResearchがやったContext-sensitiveなflow
解析はLackwitのpolymorphic-recursiveバージョンみたいな物。

>>554
>でも、静的で強い型付けの言語で開発を行うときは、
>いかに無駄なコンパイルを避けるかが効率的な開発の肝となるよね
>（少なくとも心理的には）。

それは違うだろう。どんな言語であってもリファクタ(に限らないが)は、
ソース修正と試験実行のサイクルが速ければそれでいいんだから。
Delphiみたいに馬鹿みたいな速いコンパイルが理想かと。

もとよりXPは「今の」技術を駆使して開発を楽にするための手法。
ソース共有やバージョン管理だって、CVSみたいな、昔から見ればとんでもない
ディスクとネットワークの「無駄」を許容する環境が前提なわけで。
つまり少なくとも今時の計算機を使うってことね。
コンパイルを躊躇してしまうようなコンパイル遅すぎるマシン(や言語処理系)でXPに参加しちゃ駄目。

>>570
> >>565 普通はメタメソッド(meta method)と呼ばれる。

特異メソッドはちっともメタじゃないんだから、
あれをメタメソッドなどと呼ぶやつがもしいるなら、そいつこそドキュソだ。
たとえば「メソッドのためのメソッド」みたいなものがメタメソッドと呼ばれるべきだ。
そんなもの有るのかどうか知らぬが、もし有るならば。

>少なくともclassを変数型として使うのは変な話だ。
>実装上の型階層への依存と制約を増やしてしまう弊害が大きすぎると思う。

いえてる。それを胡麻化すためにBridge Pattern使ってみたりね。
GoFのデザパタの幾つかは、残念ながら「今主流のいくつかの言語」の
欠点を補うことに終始(奉仕)してるに過ぎないものだ。
そういう方向の柔軟性が欲しいなら、手書きなんかさせず、そもそも
それをサポートした言語を使え!と怒鳴りたい。時間の無駄。

>>575
>同意。「条件を漏れなく思いつかねばならない」ってのがだいたい危うい
ような…

おお!すばらしい!そのとおりだ!UnitTestも同じ限界をかかえているねえ。

>>599
>それは違うだろう。どんな言語であってもリファクタ(に限らないが)は、
>ソース修正と試験実行のサイクルが速ければそれでいいんだから。
>Delphiみたいに馬鹿みたいな速いコンパイルが理想かと。

それは真理だねえ。型チェックに限らず、コンピュータが形式的にチェック
できるバグ対策は、作業の邪魔にならないくらい早いならそれに越したこと
はないもんね。俺もVisualAge for Javaを使ったとき、ソースをセーブす
る瞬間にsyntaxをチェックしてくれるのはすごいありがたいと思った。一
瞬だからね。

統合開発環境でインクリメンタルなコンパイル。ソース保存時にsyntaxチェッ
ク。バックグラウンドで型チェック、最適化。そういう環境はたしかに良
さそう。

# でも、結局は意味論に向かいそうな...。

>バックグラウンドで型チェック

動的分散コンパイルなるものも処理系によっては有るそうですね。
今暇なマシンにコンパイル作業を振るという対称型マルチプロセス。

VisualCみたいな(わら)重い処理系にはなおのこと搭載して欲しい機能だ。
MSにとっても、ライセンスを更にたくさん売りつける良い口実になる
んだから、やればいいのに何故やらぬ?技術が足りぬのか?(わら

unixだとどうでしょうね。
「今暇かどうか」を妥当に評価する手段がある(あったっけ?????)ならば、
あとはrshで飛ばせばいいだけだから、自作できそう。

>ソースをセーブする瞬間にsyntaxをチェックしてくれる

ところでそれ、syntaxエラーだったらどうなるんでしょうか?
やっぱりセーブ「が」中断されるんでしょうか?
だったら、まちがっていてもとにかくセーブしたい!ときは困るかも。
あと30秒で電源やネットが落ちる!なんてときとか(わら

（わら
ｳｻﾞ

> unixだとどうでしょうね。
> 「今暇かどうか」を妥当に評価する手段がある(あったっけ?????)ならば、
> あとはrshで飛ばせばいいだけだから、自作できそう。

口だけのおまえには一生かかっても無理だな

まあおまえら素人は「dish 分散」で
検索でもしてなさいってこった。

>604
検索した。
http://www.chem.nagoya-u.ac.jp/matto/dish/READMEJ.html
がヒットした。
ページの下のほうの名前を見てぶっ飛んだ。

>>601
>>ソースをセーブする瞬間にsyntaxをチェックしてくれる
>ところでそれ、syntaxエラーだったらどうなるんでしょうか?
>やっぱりセーブ「が」中断されるんでしょうか?

エラーのあるままセーブされますが、エラーがあるというマークが
つきます。エラーがあるというマークのついているソースはコンパ
イルできないので、せっせとマークを消すことになります。

っていうか実用的な言語はＣ＆Ｃ＋＋のみ。他は逝ってよし。

CやC++はよく言えば細かいところまで人間が制御「できる」けど、
悪く言えば細かいところまで人間が制御「しなければならない」よな。
コンパイラによる最適化についても、どういう最適化がおこなわれるか、
意識する必要あるし。
詳細な結果が想像できるというところが、ある種の分野では
「実用的」とみなされるのは否定しない。
でも、そうでない分野も多いし。

サーバサイドスクリプティングみたいな、仕様変更が頻繁かつ
メモリリークが許されない分野ではC&C++はまったく非実用的
だと思います。

>>599
っつーかさ、結局パターンってのはなくなるべきものなんだよね。
実装で頻出してかつ有用なパターンってのは
本来は言語仕様か標準ライブラリでサポートされるべきで、
いちいち実装するのはアホらしいよ。
パターンってのは、言語屋さんが取り組むべき課題を
抽出するための方便なんじゃないかと思う。

>>609
簡単に実装できてサルでもすぐ理解できるものなら
おっしゃるとおりだが。
まぬけな新人には理解できねー概念もあるじゃん。

>>609
> 本来は言語仕様か標準ライブラリでサポートされるべきで、
> いちいち実装するのはアホらしいよ。

言語が、より強力にサポートして欲しい、
クラスライブラリは、よりパターン的になってほしい、
には、まあまあ同意だけど、

> っつーかさ、結局パターンってのはなくなるべきものなんだよね。

言語仕様やクラスライブラリのあちこちにある概念を抽出したのが、
パターンだ、ということだから、やっぱり設計には必要な概念だろ？
メタファーで理解するのは思考の基本中の基本だからな。

>>609
パターンをライブラリ化しようというのは初歩的な間違いだな。
(Observerみたいに、ライブラリ化できる例もあるが)一般には
レベルが違うものだ、という話はデザインパターンに関する
本ならたいてい最初の方に出てる。まずはGoF本でも読めば？

>>611
ちょっと言葉が足りんやった。スマソ。

もちろんパターンを抽出していく作業は続けるわけだが、
一度抽出されて普及されたパターンは言語仕様なり標準ライブラリとして実装されて
プログラマはそれをパターンとして意識しなくてすむようになるってのが理想だ
と言いたかった。

経験積んだプログラマはなかなか入手できないですね。

えっとー。。。たとえばObserverパターンって
ライブラリとして用意されてても
使いかた素人プログラマにはわからないよね。見ても全然
理解できないと思う。

>>614
それってパターンだけじゃなくて
オブジェクト指向全般に言えることだね。

>>615
そんなことないだろう。最初からJavaやRubyを学習すれば、
オブジェクトがその素人プログラマとやらになるための
欠かすことのできない基本要素だ。

Ruby!

>>617
ｺﾜｲﾖｰ

>もちろんパターンを抽出していく作業は続けるわけだが、
>一度抽出されて普及されたパターンは言語仕様なり標準ライブラリとして実装されて
>プログラマはそれをパターンとして意識しなくてすむようになるってのが理想だ
>と言いたかった。

？？？ＳＴＬもっと拡張しろってこと？？？？

>>616
最初からHaskellかMLかLispをやればオブジェクトなんぞ知らなくてよし。
OOやりたきゃCLOSやOcamlに流れればよし。型推論のある言語を使えば、型無しに
劣らない柔軟性は確保できるし、関数型言語は慣れれば激しく生産性高し。
でも、型推論機構のある言語も入出力やCとかとのインターフェースの部分で型安全やら参照透過が
必ずしも保証できないからなぁ。Haskellはmonadという魔界に入って回避してるけど。

そういえば、Satherの型システムは腐り果てたシロモンだった気がしたが。

>>620
んなこたーない。

型推論があっても、型があることには変わりはない。
ある関数がどの型において「のみ」実行できるべきかを
分析・設計フェイズで確定できるというのは幻想だね。
それができるんだったらウォーターフォール開発が有効
だってことになる。プロトタイピング→スパイラルって
方法論は、ポリモーフィズムを前提にした開発手法でしょ。

型推論が型無しに劣らない柔軟性を確保できるって話は
まったく納得できないね。つーか、関数型言語の扱う型
とOOPLの扱うクラスとでは、オブジェクトの粒度が違う
と思う。（クラスの方が大きくなる傾向にある、という
こと）

# 俺も関数型マンセーだけどさ。

>>620
Sather・・・・懐かしい。「実数型に変換できる型」とかなんかがあった気がする。
そういうの見ると「型ウゼェ」と思うかも。コンパイラが腐ってたことしか覚えてないけどね。
>>621
おっしゃるとおりですな。でも、Haskellの型多相と型クラスは下手に型のあるOOPLより強力で柔軟だし、
型無しOOPLには全然及ばないながらスパイラルに必ずしも耐えられないものとは思われないけれど。

ま、620・621にならって関数型マンセーという方向で。
#型なしなCommonLispが一番好きなんだけどね。

結局、1はSmalltalkやLispを知らずに型無しをけなしたDQNだったということでよろしいか?
いや、PerlやらRubyやらPythonやらは確かに逝って好なんだが。

Perlはともかく、どうしてRubyやPythonも？

genericsじゃないからとか。

>特異メソッドはちっともメタじゃないんだから、
>あれをメタメソッドなどと呼ぶやつがもしいるなら、そいつこそドキュソだ。
>たとえば「メソッドのためのメソッド」みたいなものがメタメソッドと呼ばれるべきだ。
>そんなもの有るのかどうか知らぬが、もし有るならば。

Ruby の特異メソッドってメタじゃないの？

Rubyの特異メソッド
ttp://www.ruby-lang.org/ja/uguide/uguide16.html
通常：派生クラスへメソッド定義を追加・変更

特異メソッド：インスタンスへメソッド定義を追加・変更

＃JAVAだと内部クラスを使う

Smalltalkもlispも素晴らしい言語だと思うけど、
正直、型が無いのが一番の欠点だと思う。

黙ってRuby使ってみろ。一時間ぐらいで使ったとかぬかすなよ（藁

言語仕様が中途半端にオタクなだけな気が。＞＞Ruby
HigherOrderなオブジェクト(手続きオブジェクトのことにあらず)渡せないし。
イテレータにまともに生成部つけたりブーリアンガードつけたりできないし、
なんか、一見凄い様に見えてじつはショボイってところが多すぎ。

>>630
＞HigherOrderなオブジェクト
ラムダ式みたいなの？

（できれば）ソース付きでリクエストすれば取り入れられる可能性もあるんじゃないかな。
今までも節操なく取り入れている。後方互換性がなくなる場合は難しいけれども。
まつもと氏が技術的学術的に非常に優れているってわけでもない。
「オブジェクト指向スクリプト言語」への落としどころが上手かったということ。

そりゃ、「日本発」で、「オブジェクト指向」で、「Perlの機能をほとんど取り入れてるのである程度使える」
言語があれば、ある種の人たちは好んで熱狂的に使用するよねえ。
確かに、商売人としての素質は凄いな。

Rubyは暗黙の型変換がないのでPerlよりバグを発見しやすい。
型無し言語でも、暗黙の型変換がなければけっこういけることがわかったよ。

Perlは文脈に応じて挙動の変化するところが「書きやすく、読みにくい」ので、
型無し言語の危険性をますます高めていると言えよう。

きょうび、オブジェクト指向っていや流行るんだからホント猿だよな。
Rubyとかなんてさ、LispでOOするのに構文糖かけたのと変わんないじゃん。
何年前の流行だよって感じだね。
というか、弱い型付けと型無しを同一視してる1とか痛すぎ。
漏れはB言語の事かと思っちまったよ。
大体、「実用性の無さ」が逝ってよしなのか「仕様、構文、意味論の醜さ」
が逝ってよしなのかどっちなんだ? CやPerlは明らかに後者だしな。
前者は・・・Basicとかのことか?

俺はSchemerだけど、仕事にはRubyを使っている。
LispやSchemeは開発環境＝実行環境だから、
配布するのに向かないんだよ。

>>635
俺はSmalltalkerだけど、
Smalltalkも開発環境=実行環境だが
特に配布に不都合は感じない。
SchemeにはSmalltalkでいうchange setみたいなの
ないのかな。
ただ単に今まで評価した式を覚えててくれたり
関数定義を(最終的な定義にまとめて)覚えててくれて、
配布する時にはそれらをファイルに吐き出してくれれば
それでけっこうイケルと思うのだが。

Schemeの場合、transcriptというファイルが生成される。
これはインタプリタにどんな入力が与えられたかをファイル化したものだけど、
まあ、いけなくはないね。

問題は非標準のライブラリを配布する手間だわね。
処理系それ自体のインストールは、インストーラを配布すればそれで終わりだけど、
ライブラリはそう単純ではないからな。

ああ、ライブラリ間の依存関係とかの問題ね。
Smalltalkは最近では一部の処理系で
ライブラリに依存関係を定義できるようになったよ。

いっその事、RPMとかdebみたいなの使ってみたらどうよ？

納品先はWindowsであることがほとんどなのですが（藁

いや、面倒くさがらなければいいだけの話ではあるんだ。すまん。

exe/dllにして配布すりゃいいじゃん

640はSchemeがどういう言語だか知ってるの？

>>641
知ってますが何か？
exe/dllにして配布がそんなに特殊なこと？

Schema で作ったシステムを、exe/dll化するソフトを、教えて下さい。

失礼しました、
>>643 Schema → Scheme でした.

自分で調べれば？

>>645 Lisp Schemeスレには、SIOD (SCM,Guileの祖先)しか載っていなかった。
　でも、SIOD (Scheme In One Day) は、
　　・Cのスタック上に Scheme スタックを載せて高速化を図っている
　　・結果として、continuation とか実現していない
　だったと思う。

　これ以外に、exe作成できるものってないでしょうか？

微妙に関数言語板になりつつあるような・・・ Scheme萌え。
あ、でもGHCがもっと良質のコードを吐くようになりさえすれば迷わず
Haskellで開発するんだけどなぁ。
どっちもアルゴリズムの実装が信じられん程早くできる良い言語。
strongly typedかどうかは是是非非でしょ。他人の書いたSchemeコードは
得てして意味不明。いや、漏れの能力が低いだけなんだが。

>>646
トランスレートするとか。継続まで再現されるのか微妙だけど。
配布だけが目的ならschemeごと適当なアーカイバでまとめて１つのEXEにする。

>>648 Scheme2C でしょうか？今度使ってみます。
　　　Schemeは、10年程前に SCM や XScheme で遊んでいたんですけれども、
　　　現在メジャーな処理系は何なのでしょうか？

>>647 GHCの吐くコードって、どうゆう感じなのでしょうか？ (C or ByteCode ?)

＃継続があると、「Actor」っぽくて萌えるんですけれども、
＃　　　　　　　コンパイラーを作りにくかった気がする。
＃現在ならば、threadへ対応させれば良い気もするが。

ま、いずれにせよdll化は難しそうだな。

質問！ VisualC++でコンパイルできるCのコードを吐いてくれる
Schemeの処理系ってあるの？

cygwinが必須なexeなんて、配布に向かなすぎる。

scheme の exe/dll化について、質問したものです。

[Lisp Scheme Part3] スレ先頭のリンク

　　プログラミング言語Scheme : ttp://www.sci.toyama-u.ac.jp/~iwao/Scheme/scheme.html

に、Scheme実装系のリストが載っていたので、そこから探してみる事にします。

どうもありがとうございました。

age

出ます ディレクトリ

>649
GHCはCで吐いてGCCを呼ぶんだったかな。
吐かれるCコードは人間が見るもんじゃない代物。
効率を気にしたコーディングをすればかなり速くはなるんだが、MLより遅い。
ま、得られる結果は内部で呼んでるGCCにもオプション渡して
スタティックリンクとかもできるから配布で困ると言うことは無いね。
それでも、優秀なSchemeインタプリタの方が高速だと思うが。

>656
一応ネイティヴコードも吐けますよね。遅いらしいけど。
あと -O2 -fvia-C -O2-for-C 使えばそれなりに速いのかと思ってたんですが
やっぱ遅いのですかね?

GHQ

俺、Ruby好きだよ。
というか、Rubyの欠点って、
1) ドキュメントやライブラリの不足
2) インストール手順の不統一
という、Perl/Pythonと比較したところにあると思う。
型が弱いからRubyはダメとかヌカしている奴は、
どういうデバッグで苦しんだか書いてみろと言いたい。
Rubyでデバッグに苦労したことないよ。
少なくともPerlなんかより、ずっとデバッグ簡単。
UnitTestもできるしな。
現状、Rubyよりもデバッグしやすい言語ってEmacs Lispくらいなんじゃないの？

Rubyが駄目なのは言語仕様が中途半端だから。
というか、10年前の流行にSyntactic Sugarかけただけ。
しかも、速度遅いし。型情報は速度向上にも使えるのでRubyののろさは
ある意味で本質的。Rubyでのプログラミングは全然楽しくない。というか、OOP
そのものが楽しくない。Schemeやってるとマスかくより楽しい。
Haskellでコーディングするとイキそうな位に楽しい。(遅いけど)

>>660
なんだ、オナニーか。

型無し言語だからデバッグに苦しんだ経験って俺もないな。
むしろ型キャストとかでハマる方が多い。

>>662
Perlでは苦しんだ。文脈依存の、暗黙的な、特殊な挙動が多いから。

>>663
それは「形無し言語だから」とは関係無いだしょ、ま、解ってて言ってそうだけど。

>>662
型キャストでハマるってことは、型の間違いをいち早くコンパイラ
に指摘されててデバッグ作業にいち早く入れているということでは？
もし型が無かったら実行時に型の間違いが現れて大いにデバッグに
苦しんでるということだと思うけど。

>>665
実行時というか、コード入力している段階でデバグを
同時進行できるのが利点なんじゃない？
（段階を踏む必要が無いって意味）
例えばlisp/schemeは暗黙の型キャストなんかは無いけど、
必要なデバグのテンプレートなんかその場で簡単に作れるから、
開発サイクルがとても早い。
目的、手段に簡単にアクセスできるって感じがいい。
完成品をいち早く見れる出力の代替能力が高いからなんだけど。

型なし言語は処理系を作る段階で
テスト用ソースを書いていてドツボにはまる、と書いてみるテスト。

>>667いみわからん

>>668
コード生成部のバグとりがかなり死ねるような、と思ってみた。

>>659
UnitTestもできるしな、ってのは視野狭窄な話だな。UnitTestできない言語なんぞあるのか(笑)
UnitTest用のﾌﾚｰﾑﾜｰｸがまだ用意されていない言語ならあるかもしれないけど、よほどマイナーじゃないとね。

バリアントあげ！

Perlって本当に糞言語だよな。sage!

Rubyさいこー

Ruby以外の言語は糞言語。これ決定

自作自演Rubyあげー

Ruby!

Perlは、はっきりいって糞だよ。Rubyほどじゃないけど

Rubyは最高の言語！

つかperl使うと馬鹿になるYO!! Rubyほどじゃないけど

でもインタプリタってどれも糞なんじゃないの？Rubyほどじゃないけど

あらゆる言語は糞言語。Rubyほどじゃないけど

COBOLとかの終わってる系は嫌だね。Rubyほどじゃないけど

>>669
正解。かなり死ねる。っていうか実際死んだ。
お前の腕が悪いだけだ！、と言われたら反論できないけど(ｗ

>>683
お前の腕が悪いだけだ！

>>679 つか、変数に型がある言語では、
　　　ソースコード上の変数追っかけていけば、データの流れが追いやすいけれど、
　　　値のみに型がある言語では、実行時のデータの流れを想像する必要があるから疲れる...
　　　俺の型推論神経が退化してくる...

思いついた！

デフォルトだと型無しだけどモード設定みたいなので
型有りになる言語ってどーよ。

たとえて言うならVBに変数定義強制＆＆バリアント型使用不可＆＆
subとfunctionの引数と帰り値の型指定強制するモードを付ける感じ。

とりあえず型無しでコード書いて落ち着いてきたら型有り
（型無しになってる部分を発見するとエラー出す）モードにして
細かいところをつめていくの。

これなら型無し言語と型有り言語の良い所を併せ持つ感じに
なると思うんだけど。

どうよ。

>>686
形無し指定した変数のからんでるところで、同じようなことになると思われ。

>>687
たとえばどんな例が考えられますか？

>0x7c3
医院でないの？現にInterDevとかではnew ActiveXObjectした直後（JScriptの話ね)
とか関数の戻り値なら型情報を考慮してくれるし、それをもっと適応範囲を広くして
便利にしたらMSが買収してくれるよ（藁

>>686
数年前の話しだけど、JavaScriptがいちいち型を気にしなくて良いから楽だなぁ、
などとうかつにも考えてしまっていたとき、C/C++にany型を導入するというアイディア
をもったことがあったよ。このとき、単純にany型を導入するんではなく(そんなの
なら別におもしろくも珍しくもなんともない)、段階的にany型を解消することで
プログラムが型の扱いに関して成長していくというもの。君の考えといっしょ。

思考実験の結果、かなり強力な型推論機構が必要だと考えた。
また、その強力な型推論機構C/C++の型のシステムに融合させるのは
完全には無理で、なんらかのランタイムデバッグサポートが必要。

any型を引数にもつ関数は、過去に呼び出されたときの(もしわかるならば)実際の型が
何であったか記録しておき、その型とそのスーパータイプ以外で呼び出された
ときには通知する、といったデバッグサポートがあると便利だろう。その情報は
後にany型の型を制限するようなコードを追加するときに利用する。そして
ある程度開発が進んで型情報のデータがたまったら、それをもとに型を固定してしまう。

デバッグを終えプログラムをリリースしてしばらくしてから、こんなエラーが
でましたけど…、という報告が入り、急きょデバッグすることになる。
まず、その異常な型が発生する状況を再現するのに苦労する。
なんとかデバッグできるようになっても、型の融合に苦労する。
テンプレートみたいなのでうまくお茶を濁せればラッキーで、
結局any型はいつまでも残る。ちっとも段階的に解消しない。

「段階的に〜」というところは結局any型を導入しただけで終わり、
今後の愁いをなくすためにany型はany型として残すようになって、
そのままリリースして終わるだろうなぁ、というところに落ち着いた記憶がある。

つーか、ほれ、変数が宣言なしに使用できて、
最初に代入したときに型がフィックスされて、
異なる型の値を代入しようとしたり、
代入する前の未定義状態のまま値を評価しようとしたりすると例外を投げる、
みたいなのでけっこう十分に実用的だと思うんだよな。
まあ、そうすると実行時型チェックが必要になるから、遅くなると
言えば遅くなるね。でも、そういうときには静的に変数宣言すれば、
型チェックされないみたいな言語仕様にもできるでしょ。
Objective-Cでそういうテクニックが使えるよな。

>>691
>代入する前の未定義状態
こんな状態作らなければよいじゃん。そもそも、
>変数が宣言なしに使用できて、
これにメリット無い。

＞>変数が宣言なしに使用できて、
＞これにメリット無い。
禿同。
Pythonみたいに、最初の代入が宣言として扱われるのはいいとして、
ＰＨＰや昔のＢＡＳＩＣみたいに、最初に参照されたときにデフォルトに
初期化されるのは、デメリットだけだね。

長文失礼。

>>690
僕は趣味で書くコードをRubyでとりあえず書いて後から
ANSI-Cで書きなおすって事をやったりするんですけど、
その時に「同じ言語で書けたら少しは楽になるかなぁ。」
とか思ったり、異論は有ると思いますが
型無しはプロトタイプ作るのに便利だけど遅かったり予想外の事が起きやすい。
型有りはコードを書き始めてから動くまで時間がかかるけど、ちゃんと作れば早いしエラーも起きにくい。
ということで、双方の良いところを併せれば良い言語が
出来るんじゃないか？　と思って>>686を思いついたんです。

でも、実際に仕事なんかで使うとなるとやっぱり
＞今後の愁いをなくすためにany型はany型として残すようになって、
＞そのままリリースして終わるだろうなぁ、というところに落ち着いた記憶がある。
と、こういうことが起こりそうですよね。

#現実は甘くない、と。


>>693
禿同。

変数は宣言必須のほうが良いと思います。
まぁ、最初は警告出すだけにしといて型有りにしたら
エラーにするってのも有りだと思いますけど。

#宣言してない変数って使ってることすら忘れそうだし。


##趣味プログラマ暦10年ちょっとの俺では経験が足りないか。ｳﾂｰ

宣言必須、初期化必須にしても、それは本質じゃないんだよな。
未定義（初期化されていない）の変数が参照されるってことは、
ロジックのどこかに問題があることなんで、エラーが出るべき
なんだ。初期化されているからといって、それが意味のある値
とは限らない。「とりあえず」の値に過ぎない（プログラム開
始時には意味のある値を決められない）変数ってあるわけです
よ。

# たとえばparserにtokenを渡すscannerを書くとして、入力
# を受け取る前の現在のtokenは未定義であるべきでしょう？
# 未定義であることを示す特殊な値を定義することもできます
# が、正当な使い方であるかぎり、入力を受け取る前の
# scannerに対してtokenを要求するのはおかしいわけですか
# ら、例外が投げられるべきです。そして、それはscanner側
# の問題ではなく、scannerにtokenを要求する側（この場合
# はparser）の問題でしょう。

宣言必須にすることのデメリットは他にもあって、基本的に変
数の型を宣言することは、冗長な作業ですよね。たとえば型推
論の機能があれば、ある変数に複数の型が代入されていること
をコンパイル時に検出してエラーを出すことはできるわけです
から、わざわざ手作業で型宣言させる必要はないと思います。

# ないしはソースコードを静的に型チェックするチェッカーを
# ユーティリティとして用意し、デバッグ中にこれを使用する
# のでもかまわないと思いますけれど。

>>695は話の流れを理解できないアホ。

>>694までの流れで言うと「初期化」は、明示的な、プログラムとして意味のある初期値の代入と思われ。

また、型推論で２種類の型がバインドされる可能性が見つかったとして、
その２つのうち「どちらかが必ず正しい」とｊは限らないわけで。

それから、strong typedな言語で、型宣言しておけば、自動的な型変換が期待できる場面で、
わざわざ明示的な型変換を書くのは冗長な作業だと…

>>695
パーサがスキャナに、最初に「次のトークンをくれろ」っていう構造は、間違っていると？
つまり、
「まず、最初のトークンをとりだしてちょ」ってしてから
「次のトークンをくれろ」を繰り返せ、と？？

>>698
いいえ。最初から「次のトークンをくれ」で良いんです。
でも、トークンの値は入力を評価するまでは決定しないですよね。

698>>699
う〜ん、スキャナとパーサに限って言うと、パーサから「次をくれ」って言われて初めて、
スキャナがトークンの取りだしをはじめるのが一般的だとおもうからなぁ。
あんまり良い例ではないのかも。

>>700
いや、だからさ、最初に「次をくれ」って言われるまでは、
トークンの取り出しは始まらないだろ？　取り出してないん
だから、取り出した値の格納先は未定義だよね？

っつーかさ、
それで「まだトークンがないから」例外投げるなんて...
普通はブロックするだろ。

>>701
だからさ、取り出しが始まったら未定義じゃなくなるんだから、
未定義なものを参照するやつが居ないじゃん。
ちみ、自分で
＞入力を受け取る前の
＞# scannerに対してtokenを要求するのはおかしいわけですか
＞# ら、例外が投げられるべきです。
って書いたの忘れてる？

これはどうですか？
http://fa.puresilk.ac/idol/
http://fa.puresilk.ac/idol/nozoki.html

>>701は、字句解析と構文解析の区別がついていないと思われる也
で、変数の宣言を必要としないのは、デメリットの方が大きそう。
ということで、

１、型を変数と同時に宣言する、このときany型のような宣言が出来る。
２、型は宣言しない、特に型を強くしたい変数のみ、型を宣言しとく。
３、型は最初の代入で決まる、以降は型チェックが実行時に行われる。
４、宣言は３と同様、実行前に型推論でチェックされる。

などいろいろありそですが、話、もとにもどりそうですか？

>>703
だから宣言するときに初期化できないでしょ、という意味なんですが。

>>705
テスト段階は3、コンパイルすると4ってのがいいです。

!!!!!!!!!!!!!!!!!!!!!
>>704はブラクラ(正確には違うが)
!!!!!!!!!!!!!!!!!!!!!

>>706
なんか、毎回主張が違ってるようですが。

ageageage

なんかアホが一人いたみたいね。
具体的に言うと>>700のことなんだけどさ

宣言ウザいっていう意見はさ、
宣言のあるなしじゃなくて
宣言の自由度と、宣言の結果の変数のスコープについて
考えるべきだと思うんだよね。
実際、C++の
「for(int i=0;i<10;i++){}」
っていうコードはかなり便利だし、
それ覚えて後でpure cいじるとすげえうっとうしく感じるもの。

>712
C99 may make you happy!

>>711
おやおや、今度はアホよばわりですか？
いいかげん宣言と初期化の分離を認めたらどうですか？

あげてみよう！

型あり派の方々は参照透過性の問題についてどう考えていますか？
僕は型にこだわらない方ですが、関数型言語じゃない言語を使って
るときでも、初期化以外の代入を避けたりしてますけど。

参照透過性と、型あり/型なしの関係って、とっても薄いんでは内科医？

いやさあ、型チェックのおかげで検出できるバグってどの程度のものか、
とか思うわけよ。
参照透過性を確保する方がバグをなくすのに貢献するというのが俺の実
感なんだけど、みんなはどうかなあ、とか。
というか、参照透過性を確保するようにコードを書くと、型の問題が小
さくなりません？　とか思うんですが。

age.

>718
>参照透過性を確保するようにコードを書くと
Cでサンプル書いてみてよ。

手続き型で参照透過性を保とうとするっていうのは
出来るだけ特定の状態に依存しないようにするっていうことで
それがバグの発生を減らすことになるんでしょ。

でも
int a = 3;
a + 10; // ここでの値
a = 4;
a + 10; // と、ここでの値
が同じでないっていうのは(これだけでも)参照透過性が失われてるような感じだし
やっぱ手続き型で参照透過性云々っていうのは違和感がある。

あと、型あり/型なしとは関係ないような…。

>>717>>721
関係無いに１票。

あと、参照透過性を確保する書き方と、
参照透過性を保証した言語との、近そうで
とっても遠い関係に気がついてない人が
いるに、自分で１票。

// Cによる山椒投下サンプル
#include <stdio.h>
#include <malloc.h>

int *swap2(int arr[])
{
　*ret = malloc(sizeof(int[2]));
　ret[0] = arr[1];
　ret[1] = arr[0];
　return ret;
}

int main()
{
　int arr[2] = { 1, 2 };
　int *rev = swap2(arr);
　printf("%d,%d", rev[0], rev[1]);
　return 0;
}

こんなんでquicksortやったら凄いことになりそうだな...

>>723
代入の代わりに新しい変数作ってたら…

>代入の代わりに新しい変数作ってたら…
計算の過程が全て残って楽しいかも(藁

>>723-725
まー普通は、
・動的エクステントが必要か、静的エクステントで充分か検討して、
・後者ならばスタック上に変数をアロケートする (alloca(3)参照)
んじゃないかな？ (戻り値のサイズを呼び出し側で指定するのは面倒だけど)

>>716
参照透過性 と 型あり/型なし
プログラムの静的解析に貢献するって点が共通点？
んでも、型ありで参照透過性なしだったら、静的解析しにくいでしょ。

すると、>>723 は何をしたいのか、いまいちよくわからん。

まぁー>>718は、純粋関数言語派としては、至極まっとうな意見かと。

でも、モナー度のＣ言語的解釈をするのが先決かと。

バグがどこに潜むのか、ってのが問題でしょ。

静的な型システムがバグの検出に役立つってのは、
関数の戻り値を型の異なる変数に代入しようとしたりするのを
コンパイラが検出できるってことだよね？

ある変数に対する代入が1回しか行われないなら、
その変数に格納される値の型は一意に決定できるわけでしょ。
でもって、あらゆる関数の戻り値の型が一意だとしたら、
変数の型を宣言することは冗長だよね。

型なし言語でも自衛することはできるって話です。

# もちろん必要があって様々な型をとる変数を使うのは
# いいんですよ。そこが急所だってこともわかってるだ
# ろうし。

>>728
> その変数に格納される値の型は一意に決定できるわけでしょ。
多相型(parametric polymorphism, inclusion polymorphism, ad-hoc polymorphism)
どの多相型も、静的型付で代入が1回のみであっても一意に型が決まらない。

> # もちろん必要があって様々な型をとる変数を使うのは
> # いいんですよ。そこが急所だってこともわかってるだ
> # ろうし。
動的型付にしろ、静的型付+多相型にしろ、
それは急所ではなく、長所であり要所となる。

>>729
参照透過性が確保されているなら、ある式の型は静的に決定できるよ。
多相型をサポートする関数であっても、関数に与える引数の
型が静的に決定できれば、戻り値の型も静的に決定できるでしょ。

急所っていうのはHot Spotの訳語のつもりで使ったんだ。
要所と言い換えてもいいです。混乱させてスマソ。

>>730
「要所」については了解。
折れは多相型や動的型付は欠陥ではなく、逆に武器になるということだけ言いたかった。

型を決定できるかどうかについては、例えば、こんな場合はどう思う？
1. parametric polymorphism
　id x = x
　ここで、「=」の右側に出てくる「x」の型は？

2. inclusion polymorphism
　Shape something() {
　 if (rand() > 0.5)
　 return Point(0, 0)
　 else
　 return Rectangle(0, 0, 0, 0)
　}
　さあ、この関数sample()の返値の型は？答えはShape。
　では、この関数から返されるオブジェクトの型は？
　また、以下の場合、
　Shape something() {
　 Shape s;
　 if (rand() > 0.5)
　 s = Point(0, 0)
　 else
　 s = Rectangle(0, 0, 0, 0)
　 return s;
　}
　変数sが指すオブジェクトの型は？

3. ad-hoc polymorphism
　加算演算子「+」に文字列演算子「+」がオーバーロードされているとして、
　a ++ b
　の型は？
　aやbがinclusion polymorphismの２番目の例に出たような形で決定されていたら？

補足と訂正。
1.の関数idは、id 1 = 1, id 'abc' = 'abc'となるような関数。
2.では、PointとRectangleはShapeのサブクラスとして読んでくれ。
3.の
> 加算演算子「+」に文字列演算子「+」がオーバーロードされているとして、
> a ++ b
> の型は？
は、
> 加算演算子「+」に文字列連結演算子「+」がオーバーロードされているとして、
> a + b
> の型は？
に置き換えてくれ。スマソ。

>>728
変数の型を一意に決めるのは、変数宣言のときだけではなく、
初回の代入のときでもいいし、
すべての代入をリストアップして、合う型を調べてもいい。
型あり言語では、代入の度に変数の型が変わるようにはしないので、
代入が１回だけじゃないと型が決まらないわけではない。

1については意味がわかりません。右辺のxはそれ以前に値が
決まっているのではないの？
2のような関数は参照透過性を確保しているとは言えないでしょ。
3については、この文脈だけではわからないけれど、前後のコード
から型を決定できると思いますが。

(defun foo (n) (if (= n 0) "zero" n))

この関数は参照透過性が確保されている関数という認識でいいんだよね？

2では２つ関数を定義したけど、
１つ目は代入は一切なし。
２つ目は２つ代入文があるけど、どちらか一方しか実行されない。
つまり１回しか代入しない。
したがって参照の透明性は確保されているよ。

rand() がまずいかと…

>>737
そうね、rand()はまずいね。スマソ。
じゃ、引数に適当な整数を取って、それが０か非０かで分岐するってことで。
つまり>>735と同じ問題に帰着する。（735は動的型付、731は静的型付という違いはあるが）

実行コンテキストにおいて具体的な実パラメータが確定しなければ
関数の実体における仮パラメータを用いた式の型を確定させることはできないっしょ？

あ、ひょっとして実行コンテキストが確定して、今まさにその式を評価しているという時の話？

わざわざ静的な型決定ができなくなるような書き方をする場合に、
参照透過性を云々するのって奇妙な気がするんだけど。
MLにおける多相のようにすれば、静的に型決定できるわけで。

>>739
そのMLにおける多相ってのが>>731の1. parametric polymorphismなんだけど…
つまり型変数を使って任意の型の値を扱えるようにしたりとか（parametric polymorphism)
subtypeを使って型階層の部分木の任意の型の値を扱えるようにしたりとか(inclusion polymorphism)
演算子（または関数）オーバーロードや暗黙的型変換を使って複数の型の値を扱えるようにしたりとか(ad-hoc polymorphism)
参照の透明性があっても、ある変数が指す値（オブジェクト）の型は一意に制限されることはなく、
多様な値を取ることが出来る、ってこと。

だから静的に型決定できるようにコーディングして、
参照透過性を確保することはデバッグしやすさに寄与
するでしょ。731は何がいいたいの？

>>741
静的に型決定できることと参照透明性は直接関係ない。
すなわち参照透明性を保障しても型は一意に決定できない。
また、型が一意に決定できることはデバッグしやすさに寄与しない。
MLの多相型などは型を一意に決定しないことで再利用性を確保し、
多相型に基づく型推論によってデバッグを支援している。

>>742
まあ、そうなんだけど、静的に型を決定できるようにコーディング
することはできるし、また、参照透過性を確保するようにコーディ
ングすることもできる。そのようなコーディングをすることがデバッ
グしやすさに貢献すると俺は考えているんだよ。

「型が一意に決定できることはデバッグしやすさに寄与しない」
ってのはどういう根拠によるの？
動的に型が決定する言語の場合、実行時にメソッドディスパッチ
するまで、そのメソッドの正当性を決定できないでしょ。それが
動的に型を決定する言語のメリットかつデメリットな部分だよね？
意識してメリットを享受している場合は良いけれど、無意識にデ
メリットをかぶるのは困るわけ。
それで、僕は、僕なりに動的に型を決定する言語においても、型
を静的に決定できるようなコーディングスタイルを励行すべきだ、
と考えているのだがね。参照透過性についても同様です。

>>743
> 静的に型を決定できるようにコーディングすることはできるし、
これは確かに可能ではあるよ。でもさ、これをやっちゃうと行き着く先はどうなるかというと、
「関数（メッセージ式）の返り値の型が一意に決定できるようにするためには、
関数（メッセージ式）の型が一意に決定できていなければならない。」
これが何を意味するかというと、
オブジェクト指向言語では、継承を放棄しなければならないということになる。いいの？
そこまで極論しなくても、メッセージ式の返り値の型を一意に決定できるようにするには
メソッドを定義するときには既存のメソッド名とは別の名前をつける必要があるよね。
それって、オブジェクト指向とは逆行するものだと思うよ。
例えば適当なSmalltalkの処理系、とりあえずSqueakでもいいや、
「at:」という名前のメソッドを列挙すると46個あったりするけど、
これはat:という名前から46個のメソッドが有り得てしまうという「混沌」かな？
それとも、46個の異なるメソッドを１つの名前に統一する「秩序」かな？
返り値が何だか全然わからないという点では「混沌」かもね。
でも、その「混沌」を排除しようとすると、「秩序」を破壊してしまって、
「さらなる混沌」が待っているよ。

> 「型が一意に決定できることはデバッグしやすさに寄与しない」
> ってのはどういう根拠によるの？
「１つのバグの潰しやすさ」を「デバッグのしやすさ」とするのなら
多少は寄与する部分もあるかもね。しかし、
「１つのプログラム中のバグの数の減らしやすさ」を「デバッグのしやすさ」と捉えれば
関数（メソッド）の型を一意に決定することは逆効果だよ。
関数の型を一意に決定することは再利用を妨げることになり、
結果的にバグが混入する可能性を高めることにしかならない。

sage忘れた。スマソ。

で、長くなっちゃったけど、
デバッグしやすいコーディングスタイルを模索することは素晴らしいことだと思うし、
無用な破壊的代入を減らすことはよいことだと思う。
しかし、それを「型を一意に決定する」に繋げるためには、
あまりにも大きな代償を払わなければならないし、
あるいはその代償を払わずに「型が一意に決定されている」という
誤った幻想を持つことも危険だよ。

＞こまで極論しなくても、メッセージ式の返り値の型を一意に決定できるようにするには
＞メソッドを定義するときには既存のメソッド名とは別の名前をつける必要があるよね。
＞それって、オブジェクト指向とは逆行するものだと思うよ。
＞例えば適当なSmalltalkの処理系、とりあえずSqueakでもいいや、
＞「at:」という名前のメソッドを列挙すると46個あったりするけど、
＞これはat:という名前から46個のメソッドが有り得てしまうという「混沌」かな？

総称は本来静的な考え方でしょ。同名の関数（メソッド）がいくつあっても
コンパイラや解釈系がどんな型へのメッセージかを一意に決定できて、別のものになる。
ソースコードのレベルで多相を実現しているに過ぎない。静的型の技術を用いている。

＞「１つのプログラム中のバグの数の減らしやすさ」を「デバッグのしやすさ」と捉えれば
＞関数（メソッド）の型を一意に決定することは逆効果だよ。
＞関数の型を一意に決定することは再利用を妨げることになり、
＞結果的にバグが混入する可能性を高めることにしかならない。

再設計とかリファクタリングの話をしているの？「型を一意に決定する」って
「オブジェクト指向な開発スタイルなのに、全部最初に矛盾なく決めてからやる」
ってことじゃないですよ。

すいません、過去レス読んだら、議論の最中に>>747みたいな蒸し返しレスを
入れちゃうパターンが延々と続いてましたね。これからは気を付けます。

731が言っているのはあれでしょ、総称的な関数とか、
戻り値が多様な型を持つ関数が見通しの良いコードに
貢献するってことでしょ。それは認めるよ。
でもさ、総称的な関数は、引数から戻り値を決定でき
るわけでしょ。たいていの場合は戻り値の型は容易に
推測できるよね？　容易に推測できない＝慎重に使わ
ないと危険な総称的関数など、誰も使いたがらないだ
ろうし。

>>749
> でもさ、総称的な関数は、引数から戻り値を決定できるわけでしょ。
じゃあ、引数の型はどうやって決定する？
その引数の値を作った関数適用（メッセージ送信）の引数の型から？
じゃあ、そのまた引数の型は？
ってなことが延々と続くなり。

どっかでリテラルコンスタントにあたって型が決定できたとしても、
今度は>>731の2. inclusion polymorphismの例のようなコードはどうする？
あるいはAbstract Factoryなんかもいい例かもしんない。
ちなみに>>731は静的型付けしている場合の例だよ。
動的型付け言語では、もっとエキセントリックな事が極自然に行われる。

>>747
> 同名の関数（メソッド）がいくつあっても
> コンパイラや解釈系がどんな型へのメッセージかを一意に決定できて、別のものになる。
？？？
メソッド選択の話？
変数の型ではなくオブジェクトの型から決定しているところからしても、
いかにも動的型的だと思うのだが…
静的型の処理系であっても、いわゆるvirtualなメソッド探索なら
すごく動的言語的じゃない？

型あり言語が総称を使った場合に戻り値の型が容易に推測できるのは、
戻り値の型を明示しているから。
template<class T> T min(T a, T b) { return (a < b)? a : b; }

引数a、bと戻り値の型がTであり、同じ型だということを示している。
型なし言語の場合、明示しないから、戻り値の型は容易には推測できない。