初心者が習うといい言語は何？？？part2

DQNですまんが、
これで何が静的保証されるの？
静的保証世界に穴があけることを言ってるように思えてしまうのだが。

>>943
>>919の
> So if you really need to do something unusual and difficult, a static type
> checker won't stop you. The other 95% of your program that doesn't need to do
> strange and magical things gets the benefit of type checking, which means you
> can concentrate your attention on the interesting part.

静的型システムでは、それ以外のところでは依然として穴がないままで、
「どうしてもあけたい」ところにだけ穴を部分的に開けられる。
と言ってるんだけど。

なにかを保証したつもりのグループを定義できて、
グループに属す属さないは面倒見てくれるよ、ってこと？
でも「なにか」が本当に保証されているかどうかは関知しない、って感じ？
それは、強い型付けならJavaのinterfaceで十分じゃないの？

>>945
それで>>923の3段落目にもどると…
JavaのInterfaceではこういうことができないと下のリンク先のページに書いてある。
おれはJavaは良く知らないから、読んで自分で判断してくれ。

> 既存のクラスに手を加えないで、
> それと同じメソッドを持つクラスを定義して同じ様に扱いたい、と言う意味なら、
> http://www.xoltar.org/misc/static_typing_eckel.html
> のNiceの例がやってることそのものだと思うんだが。

>>944　なるほど。
とすると、目指す方向性、ポリシーの違いであって、
強い型付けに穴をあけられないのが型機能としてしょぼいっつうのは、違うんじゃね？

あと動的分類は、
Human a= Human.new
Baby b= a.became(Baby.class)
Student s= b.became(Student.class)
Homeless h= s.became(Homeless)
が可能か、というのも含んでるから型だけで語るのはちょっとややこしいね。

>>945
違うような。おれが言いたいのは、
もし静的型付けのシステムで動的型付けを使うなら、
プログラムには静的型付けでできている(95%の)部分と、
動的型付けを使用するほんの少しの部分があるようになる。
ということ。

>>947
> とすると、目指す方向性、ポリシーの違いであって、
> 強い型付けに穴をあけられないのが型機能としてしょぼいっつうのは、違うんじゃね？

それはまあそうなんだけど、
「静的型付けはだめだ。なぜなら動的分類ができないからだ」
という「インテリ氏」の主張に、
「それはおかしい。プログラムの大半で静的型付けを利用できて、
    欲しい所だけで動的型付けを使うほうがいいではないか」
といってるだけだから。


> あと動的分類は、
> Human a= Human.new

これは、BabyなりStudentなりに「キャスト」されるときに何が
かわるのかはプログラマが指定しないといけないはずだから、
dynamic_class Human {
    Baby operator=() { ...}
    Student operator=() { ...}
    ...}
となるだけじゃない？
もし指定しなかったらそのまま単に「キャスト」するということにすればいいし。

>>947
あと、JavaのInterfaceの話では、Niceっていう言語は
強い静的型付けであってかつ、
> 既存のクラスに手を加えないで、
Interfaceが追加できるような型システムらしいよ、っていうことね。

>>950
一種の構文糖だね。静的にやる必要があるという本質はJavaのinterfaceと変わらないんだよね。

つうか、強い型付けだって、動的分類できるでしょ。
Human a= Human()
Baby ababy= Babyness.of(a)
で。
どうせ、弱い型付けでも赤ん坊かどうかはチェックするんだし、
HumanとBabyの関係が宣言的にならないけど、弱い型付けだって同じ。

。。。ちょっと無理あるかなぁ。。

もっといい型システムなら静的なままC++/Javaのような制限がはずせる、
という話と、
どうしても静的ではできないときなら動的な型を使えばいい、
という話が並行してるのがちょっと混乱を招いている感じ。

>>952
Baybyness.of(a)の型は？
aがHumanの派生型しかとれないんだったら動的分類とはいえないんじゃないの。

Human aがBaby ababyになってるのが味噌で、それが
動的分類じゃないと言われうるのはそうだけど、
> どうせ、弱い型付けでも赤ん坊かどうかはチェックするんだし
ってことで目を瞑ってもらえんだろうか。

>>953
後者はわかったから前者に興味あり。

須磨。ちょっと話がぶれてるが、↓。BabyとHumanの関係は宣言的だわ。
class Human{ }
class Baby extends Human { static Baby babynessOf(Human h){..} }

Human a= Human()
Baby ababy= Baby.babynessof(a)

babynessOf(Human h)は弱参照でhのテーブルを持ってて、そのBabyが既成ならそれを返す。

>>955
例えば、独立した二つのclass Aとclass Bがともに、
意味的に同じあるメソッド(例えば、足し算)をもっているとして、
どちらでも同じ様に呼び出せる(+)を定義したくなったとき。
C++ではテンプレートを使って、同じ記述で別の型用の(+)が生成されるようにする。
なぜなら、C++の型付けではこの2つの(+)を同じ様に扱うことができないから。

Haskellならtype classを利用して
class HaveAdd a where
    (+) :: a -> a -> a

instance HaveAdd A where
    a + a = ... -- a's own definition

instance HaveAdd B where
    b + b = ...

とできる。先にHaveClassとAだけコンパイルしてあっても問題なく自由に
新しくBを追加できるし、+を使う(コンパイル済)の既存の関数はBを扱える。
AやBを使う関数は
f :: (HaveAdd a) => a -> a -> c
という型を持ち、HaveAdd というtype classにしか適用できないので、安全。

動的分類のサポートとは関係なさそう。
面白そうではあるがね。

>>900
長い期間があっても、結局なにもできないでしょ。
だから、現実問題としてスキルの余りない納期に追われてる PG でも、
なるべくバグの無いものを作れる言語がいいとは言えるのでは。
答えになってないけど。スレタイとも少し違うし。。

まぁ、つまりあれだ。
A)「プログラムの大半で静的型付け、欲しい所だけ動的型」
B)「プログラムの大半を動的型付け、欲しい所だけ静的型」
C)「動的型のみ」
D)「静的型のみ」
くらいの分類でいいだろう。A) が Haskell とか ML, B) が Lisp
C) がスクリプト言語 ってところか？

お前らこれをもっと読んで理解してから書き込めよ
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/C3_3.html

>>962
そこにはSmalltalkで動的分類を表現できると言っているけどアレってクラスベースじゃ無かったか？
本当に動的分類が活用されるにはせめてプロトタイプベースじゃ無いと駄目なような気がするが。
それとも、リフレクションでどうにかなる？
Smalltaklはクラス自体もオブジェクトだから型すら動的に作れるのかな？
ようワカラン。

動的分類が話題になっているけど、多重分類が実装できる言語って何がある？
MixJuice の差分ベースモジュールが近い感じなのかなあ

>>961
HaskellがどうしてA)なんだ????

>>963
動的にクラス定義が変えられれば一応はOKでしょ。

>>964
だから、動的にオブジェクトがもつメソッドを変更できる言語ならOKでしょ。
SmalltalkとかRubyとかNewtonScriptとか。
> MixJuice の...
漏れは上の英語のページのNiceとかいうのを見てMixJuiceを連想した。

というか、インテリ氏は現場の低能さに
驚愕してどっかに逝ってしまいましたねぇ。

>>962
静的型でも、>>956が図5に合いそうと思うけど。

>>965 間違えた。ｽﾏｿ。

>>964
多重分類はHaskellのtype classでできる。

>>965
> HaskellがどうしてA)なんだ????
Data.Dynamic

>>965,>>967
どうしてAでないんだ？

このｽﾚで関数型に興味を持って Clean ｽﾚを除いたら一発で嫌になりますた。

Haskell なんでもありだなｗ
>>980次スレヨロ

多重分類を実装できる言語は名前空間の問題をどういう風に解決しているんだろう。
結果的に多重分類になるなら用意されていないと思うが、意識して作られているなら
回避する仕組みもあるように感じるのだが。

>>958は、JavaでもTigerなら↓こんな風に出来ないの？抑止ランケ度。

interface HaveAdd<T>{ T add(T t1); }
class User{ <U extends HaveAdd<U>> U hoge(U a, U b){ return a.add(b); } }
class A implements HaveAdd<A> { A add(A a){...} }

class B implements HaveAdd<B> { B add(B b){...} }

>>895
> > 型付けが強い言語の利点
> (1) エラーチェック
> コンパイル時にわかるので発見修正が速く、バグが減る。
> この有難味はプログラミングをしはじめれば、
> ものすごく注意深いわけではない人には、痛いほどわかる。
> 結果、実行時にはじめてわかる(かもしれない)のよりも効率がよい。
>
> (2) ドキュメント
> 型を見ることで関数の役割がわかり、読みやすいソースになる。
>
> (3) 設計
> 型を意識することで思考が整理され、自然とプログラムができていく。。。

こいつ馬鹿？ｗ
エラーチェックは解らないわけでもないが（それでもオーバーすぎ）
ドキュメントで型ってなぁｗ
リファレンスならまだしもドキュメントとしてなら分かりやすい変数、関数の名前付けがあれば
流れが読めるだろ。
また、リファレンスはTestプログラムが相当するしな。
設計に関しては、もうアフォかと。
モデリングの勉強し直せ。
まじ、現場がこんなヤツばかりだと思われると鬱になる。

型付けが便利だから使うって言うのは理解出来るけど、型付けが好きって言うのはどういう
感覚なんだろうか。想像もつかない。

>>973
だからそれは動的分類じゃn(ny

>>974
> ドキュメントで型ってなぁｗ
type inferenceのできる言語では常識なんだが。
土方は黙って自分の仕事だけやってろ。

>>977
アホですか？
ドキュメント性であって、ドキュメントそのものでは無いだろ。
必要な部分だけの最小なコメントだけで十分だ。

>>974
>>895は稚拙だが、馬鹿はおまえ。

>エラーチェックは解らないわけでもないが
エラーチェックこそが強い型付けの機能なのに全然分かってなくて反論になってない。

>ドキュメントで型ってなぁｗ
何が入って何が出るかってのは強力な説明足り得る。適切かつ簡潔な名前を強く補佐する。

>設計に関しては、もうアフォかと。
設計で重要なのは、クラスとそれらの関係が整然としていることだ。
変数やシグニチャでクラスがいちいち明示されるのは、
クラスの関係が強く意識されやすく、整理を助ける。

>まじ、現場がこんなヤツばかりだと思われると鬱になる。
ｗ

> ドキュメント性であって、ドキュメントそのものでは無いだろ。
脳味噌入ってんだろうか？
まじ、現場がこんなヤツばかりだと思われると鬱になる。

>>980
次スレは要らないからな。

>>979
> >ドキュメントで型ってなぁｗ
> 何が入って何が出るかってのは強力な説明足り得る。適切かつ簡潔な名前を強く補佐する。
要らない。
「何の型が入っているか」ではなく「何が入っているか」がドキュメント（性）には重要。

> 設計で重要なのは、クラスとそれらの関係が整然としていることだ。
> 変数やシグニチャでクラスがいちいち明示されるのは、
> クラスの関係が強く意識されやすく、整理を助ける。
オブジェクト同士の結びつきと型は別物。
また、モデリングの段階で言語の型を意識するのは実相の方向性を固定化してしまう。

>>980
スレ立てヨロ。
あと、まともなこと少しは言えよ。

建てますた。かなり最悪なタイミングかもｗ
http://pc2.2ch.net/test/read.cgi/tech/1077124583/

>>982
どうしようもないアホだな。あの「インテリ」氏か？
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&q=%22type+inference%22+%22type+annotation%22+documentation&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

>「何の型が入っているか」ではなく「何が入っているか」がドキュメント（性）には重要。
あのねぇ、型にも名前があるの。
型を明示すればどのようなものかを示すの。そして適切な変数名で具体的な役割を示すの。
それがなんだかわかんないで役割だけあるより、なんだか分かった方がいいに決まってんだろ？

次スレ言語にくくらなくても良かったかもな。

インテリ氏（絵に描いたようなインテリ。知能と知識は高い）と982（真性の馬鹿）の区別が付かんとは。。。

>>987
そうか？>>917なんてかなりアホさを表しているとおもうんだが。
ただの決めつけと自分の主張への固執。知識はあるが論理がない。

インテリはときとして間抜けだったりするもの。
間抜けなままきちんと説明しようとするからおもしろい。
馬鹿のは真性の低脳のせいで説明になってない。

どんどん難しくなってますよ

>>975
型ベースで考えること自体がパズルみたいで面白い。しかもごほうび付き。

>>991がHaskellerであるにmy0.2銭。