動的言語で大規模開発

uy · 2012/07/24(火) 09:10:42.04

たててみた

**デフォルトの名無しさん** · 2014/11/30(日) 22:53:53.26

>>615
self地獄はGuidoが変人なだけで意味論なんて高尚な理由じゃねーだろ
self省略できるようにパーサ弄れない意味論的理由は何だよ
それこそ関係ねーよ

**デフォルトの名無しさん** · 2014/11/30(日) 22:55:23.26

>>610
> Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ

Ruby の super は Smalltalk とは違うよ？

**デフォルトの名無しさん** · 2014/11/30(日) 22:55:36.39

>>615
> 両者の間に直接的な関連性は無い（言い換えるとスレチな話題）

スレの主題に沿っているのは補完や型チェックの方だけど

**デフォルトの名無しさん** · 2014/11/30(日) 22:57:41.96

>>614
この論文内では duck typing という用語は一度も使われていないし、
タイトルに Strongly-Typed と書かれているように静的型付け言語に関する内容だ

で、いったいどこから duck typing を連想したの？

**デフォルトの名無しさん** · 2014/11/30(日) 23:00:20.47

典型的なアスペか。

**デフォルトの名無しさん** · 2014/11/30(日) 23:01:15.62

>>618
>スレの主題に沿っているのは補完や型チェックの方だけど

まったくそのとおり
だから >>610 では

> まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね

と書いた

**デフォルトの名無しさん** · 2014/11/30(日) 23:09:04.67

>>619
1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ
abstract斜め読みしただけだがSmalltalkには言及されてんぞ

**デフォルトの名無しさん** · 2014/11/30(日) 23:09:46.51

あれ？int型の+とstring型の+に対するオーバーロードみたいな話になってる？
無知なら口だすなと言われそうなので黙っておきます…

**デフォルトの名無しさん** · 2014/11/30(日) 23:22:20.73

>>621
そうか。じゃあスレ違いの話は止めないと荒らしになってしまうな

**デフォルトの名無しさん** · 2014/11/30(日) 23:27:42.56

>>616
Python のオブジェクト指向は Modula-3 を参考にしているけど、
Modula-3 のオブジェクト指向は Simula を参考にしている
そして疑似変数 self の概念は Simula には存在せず、
Simula を参考にした Smalltalk で生まれた
だから、Modula-3 や Python に疑似変数 self は存在せず、
これを模倣するにはメソッド引数で明示的に __self__ を
渡さなければならない訳

あと疑似変数 self の値は実行時に決まるから、
もし Python で __self__ を省略できるようにするためには、
構文論(syntax)の変更すなわちパーザの改造だけではダメで、
意味論(semantics)も変更しなければならない

こうした背景も知らずに「変人だから」という理由で決めつけるのは、
Guido氏に失礼だと思うよ

**デフォルトの名無しさん** · 2014/11/30(日) 23:31:44.94

もう、超優秀なIDEがあって動的構造取り入れた c# 最強って事で良いんじゃないの？

**デフォルトの名無しさん** · 2014/11/30(日) 23:42:47.38

>>626
MSが他の処理系を駆逐する勢いでLinux版頑張ったら近い将来にそうなるかも。
種だけ蒔いて後知らねっていう可能性も高いけど。

**デフォルトの名無しさん** · 2014/11/30(日) 23:43:33.56

>>622
> 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ

そうだろ、だから驚いて >>619 では

>>で、いったいどこから duck typing を連想したの？

と書いた

論文を引用するのはいいけど、この論文をどう解釈して duck typing に結びつけたのか、
説明が無ければ意味が分からんという話だよ

>abstract斜め読みしただけだがSmalltalkには言及されてんぞ

Smalltalk の柔軟な継承を強い型付け(=静的型付け)なOO言語に取り込むために
インターフェイスを用いる、という文脈でね
動的型付けを濫用するというニュアンスを持つ duck typing とは何の関係も無い

この論文、型システムと言語設計に興味がある人にはとても有益だから、
斜め読みと言わずじっくり読んでみたほうがいいと思うな

**デフォルトの名無しさん** · 2014/11/30(日) 23:44:44.78

>>616
http://neopythonic.blogspot.jp/2008/10/why-explicit-self-has-to-stay.html

・ただの関数を、後からクラスにメソッドとして後付けできること（そのとき暗黙のselfの扱い）
・decoratorがあるから（動的にstatic methodやclass methodに変更できる）

というのが理由だそうだ

**デフォルトの名無しさん** · 2014/11/30(日) 23:49:11.15

>>627
Roslyn凄そうだが、どんだけのヤツが付いていけるんだろ。

**デフォルトの名無しさん** · 2014/11/30(日) 23:50:00.23

>>626
動的構造ってなんだっけ
実行時型情報ならC++にもあるけど
むしろ実行時型情報がない言語の方が良いんだろ
ほぼ全部関数型言語だけど

**デフォルトの名無しさん** · 2014/11/30(日) 23:52:00.50

>>629
Smalltalk や Ruby なら、暗黙のselfがあっても
後からクラスにメソッドを後付けできるのにね....

**デフォルトの名無しさん** · 2014/11/30(日) 23:53:34.74

言語だけでいうならRustに期待しているんだが……

**デフォルトの名無しさん** · 2014/11/30(日) 23:57:11.19

>>682
> 後からクラスにメソッドを後付けできるのにね....

それは静的型付け言語のメリットをなくしてまで
やるべき重要な事なのか？

**デフォルトの名無しさん** · 2014/11/30(日) 23:58:47.30

>>634
おいおい、Python は動的型付け言語だよ

**デフォルトの名無しさん** · 2014/11/30(日) 23:59:07.80

>>632
その代わりに関数が無くてProcオブジェクトとかいう
キモい代用品を使わされるゴミでしょRubyって

**デフォルトの名無しさん** · 2014/11/30(日) 23:59:36.82

>>633
そこでまた振り出しに戻るのだが、ちょこちょこって遊ぶならどの言語でも
いいのだが、ガッツリ使おうとするとツールもしっかりしてないとねというのに
戻るわけです。

**デフォルトの名無しさん** · 2014/11/30(日) 23:59:39.73

>>631
dynamic型

**デフォルトの名無しさん** · 2014/12/01(月) 00:02:55.46

>>635
実用レベルで型推論出来る言語と
出来ないゴミを一緒にすんなよ
PythonはSoft typingが実用化されてんの

**デフォルトの名無しさん** · 2014/12/01(月) 00:04:29.77

>>636
いや、Procオブジェクトを明示的にコーディングするのは稀だ
クロージャの無い Python とは違って、
Ruby だと普通は do |x| ... end や { |x| .... } で書ける

**デフォルトの名無しさん** · 2014/12/01(月) 00:08:40.28

>>640
お前クロージャスレでフルボッコにされた奴か
ここでもフルボッコじゃねーかw

**デフォルトの名無しさん** · 2014/12/01(月) 00:11:50.96

>>637
スレタイでいうところの大規模開発なら特にそうだな
残念ながら言語の優先順位は低いと言わざるを得ない

**デフォルトの名無しさん** · 2014/12/01(月) 00:13:16.83

結局は、静的言語が動的言語の要素を取り入れて進化し、両方の境界が曖昧になるんだよ。

**デフォルトの名無しさん** · 2014/12/01(月) 00:15:06.71

>>641
逆だろw
クロージャを使えば簡潔に書けるのに、結局 Python ではコードが書けずに終わった
で、しまいに火病を発症してわめきちらしただけ、それがフルボッコなのか？www

今からでもいいから Python でコード書いてみな

**デフォルトの名無しさん** · 2014/12/01(月) 00:18:09.70

>>643
そしてObjectに500個もメソッドを突っ込んで悦に入ってるゴミは
サーベルタイガーのように進化から取り残される、と

**デフォルトの名無しさん** · 2014/12/01(月) 00:20:09.36

>>640
ほう、Python で Soft Typing が実用化されたとは初耳だ
ググってみると2003年に提案はあったものの、
その後に実装されたという情報は見つけられなかった

本当に実用化されているの？
また嘘でも何でも議論に勝ちさえばいいという発想じゃないのかなあ....

**デフォルトの名無しさん** · 2014/12/01(月) 00:21:49.35

>>644
え？お前が勝手なクロージャの定義を持ち出して、
出展となる文献を出せと言われても出せず逃げただけじゃん

で、文献は？

**デフォルトの名無しさん** · 2014/12/01(月) 00:28:35.48

>>646
>>395

**デフォルトの名無しさん** · 2014/12/01(月) 00:29:56.57

>>674
クロージャの話題は完全にスレ違いだから、
続きを希望するなら当該スレへ移動してくれ
文献もそこで出すよ

**デフォルトの名無しさん** · 2014/12/01(月) 00:36:07.76

>>645
そのゴミから色々なものが生まれた。
50年後には、そのゴミから新しいOSが生まれるかもよ。

**デフォルトの名無しさん** · 2014/12/01(月) 00:39:00.66

>>648
外部にツールが存在することと、
ある言語が Soft Typing で設計されている話は関係ないよ
Python の言語処理系(インタプリタ)だけで
明示的な型宣言が無くとも実行前に型検査できるなら
話は別だけどね

というか、Soft Typing という用語の意味を
間違って理解しているんじゃね？

**デフォルトの名無しさん** · 2014/12/01(月) 00:42:41.17

>>651
ある言語がSoft typingで設計されてるかなんて開発においてどうでも良すぎる
型推論に基づく実用的なツールがあるかどうかが重要

**デフォルトの名無しさん** · 2014/12/01(月) 00:50:53.90

いかん、アンカを間違えてた
エスパーしてくれてるみたいだけど、念の為、訂正しとく

・>>646 内のアンカ >>640 は間違いで、>>639 が正しい
・>>649 内のアンカ >>674 は間違いで、>>647 が正しい

**デフォルトの名無しさん** · 2014/12/01(月) 04:58:08.58

>>559
かっこいいとかそういう基準で判断してるわけじゃないから。契約とか内容次第だから勝手なイメージだろ。

**デフォルトの名無しさん** · 2014/12/01(月) 06:42:19.33

645はクラスを名前空間だと思い込んでいる初心者
早く補助輪を取れるといいね

**デフォルトの名無しさん** · 2014/12/01(月) 09:10:41.83

そんなつまらない事にしかレスできないから
馬鹿にされるんだよｗ

**デフォルトの名無しさん** · 2014/12/02(火) 12:19:36.12

昔Basicはプログラマとしてのセンスを破壊すると言われたが、
今回Smalltalkも破壊することが判明したな

**デフォルトの名無しさん** · 2014/12/02(火) 13:56:12.38

２ちゃんねるは人間としての品格を破壊する

**デフォルトの名無しさん** · 2014/12/02(火) 14:29:13.80

“Smalltalkのデバッガがどのくらい強力かと言うと、
任意の時点で任意のプロセスをインタラプトし
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続できるレベル。

デバッガは何枚でも開けられるし、作業の途中でやめたくなったら、
スナップショットを撮って終了し、再開すればその直前から続けられる。
たとえ、それが他のコンピューターでも(直接下回りを触っていない限り、
プラットフォームやOSが違っていても可)、それが10年後でも。”

https://twitter.com/abee2/status/539355671729152000

**デフォルトの名無しさん** · 2014/12/02(火) 16:22:17.31

10年とか先にarmのcpuが流行ってるとは思わなかったでしょ

**デフォルトの名無しさん** · 2014/12/02(火) 19:47:59.90

>>659
凄いけど役に立たないなｗ

**デフォルトの名無しさん** · 2014/12/02(火) 19:49:38.18

なんで役に立たないかというと

実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続したらバグで変な状態になった。
また止めて変な状態を直して、正しい所に移動させて続けることも可能だけど

最初からやり直したほうが早い。

**デフォルトの名無しさん** · 2014/12/02(火) 22:07:07.23

>>662
ま、結局どんな凄い機能も、
使う人間のスキルと能力が足りなきゃゴミ以下って話だね。

**デフォルトの名無しさん** · 2014/12/02(火) 22:38:50.95

人間はミスするとう前提の話をしてるんだが？
スキルや能力とは関係ない。

ミスしないようなすごい人しか使えない道具ではなく、
ミスしてもすぐにリカバリできる仕組みを作るほうが重要。

ということで静的型付け言語はそうなってるって話なんだよ。

**デフォルトの名無しさん** · 2014/12/02(火) 22:48:09.93

>>664
静的型言語（の特に機能を限定した言語）がスキルの期待できない土方向け
という意見には反対しない。

**デフォルトの名無しさん** · 2014/12/02(火) 22:52:44.71

一体何の機能が制限されているというのか？
タイプ数が少し増えるというのならわかる。
制限されているという機能の名前を聞いたことがないし、
どうでも良い機能のために、動的型付け言語を使うという話しか聞かない

静的型付け言語で出来ないことはないし、（たとえば、C言語は静的型付け言語）
多くのことが動的型付け言語よりも便利に行える。

デメリットはほんの少しタイプ量が増えるだけ

**デフォルトの名無しさん** · 2014/12/02(火) 22:57:12.61

修正したコードが実機の上、しかもファイルじゃなくてメモリ上にしかないとか
よく考えなくても怖いことなんだけどな。

**デフォルトの名無しさん** · 2014/12/02(火) 22:58:05.38

>>664
人間はミスするけど爆発しないよ
機械は爆発する
大規模なら大爆発

**デフォルトの名無しさん** · 2014/12/02(火) 23:01:26.70

>>667
よく考えてたら、VCSにチェックインするとか想像できそうなものだけど。

**デフォルトの名無しさん** · 2014/12/02(火) 23:23:32.69

>>667
> しかもファイルじゃなくてメモリ上にしかないとか

って、まともなSmalltalk処理系ならチェンジファイル機構くらいはあるだろjk

**デフォルトの名無しさん** · 2014/12/02(火) 23:41:57.12

>>666
動的型付けの利点はコンポーネント間を柔軟に結合できること
大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク
Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、
コンポーネント間の結合に用いるオブジェクトに対しては id型という動的型付けを用いる
結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている

対して、静的型付けな C++ と MFC ライブラリを採用した Windows は開発に行き詰まる
Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、
COM は高度で優れた技術ではあるものの、あまりに一般のプログラマには難解すぎて普及しなかった
（一般のプログラマが普通に使えるのは OLE Automation と呼ばれるクライアント側APIのみ）
このため Microsoft は C++ や MFC を放棄して C# と .Net へ全面移行せざるをえなかった
結果として開発チームは大混乱に陥って Windows Vista の大失敗に始まる開発の大幅な停滞をまねき、
Apple の台頭を許した

**デフォルトの名無しさん** · 2014/12/02(火) 23:43:16.07

Smalltalkをちょっとかじってみたい人のための、チュートリアルまとめ
http://qiita.com/sumim/items/6bed17961bd57daf88a3

アンチな人にも。

**デフォルトの名無しさん** · 2014/12/03(水) 00:24:16.86

>>659
なぜDockerみたいな技術が持て囃され、こういう機能がスルーされるのか
Smalltalkerには永遠に理解できないんだろうな

Smalltalkは見当違いの問題を解いているんだよ
言語の中だけでリスタートできても意味がないんだ
価値がないから真似もされない

**デフォルトの名無しさん** · 2014/12/03(水) 01:01:00.52

道具に使われてる人たちが・・・

**デフォルトの名無しさん** · 2014/12/03(水) 01:03:45.51

>>673
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を
説明するのは難しい。

ユーザーがアクセスできる部品のすべてはユーザーが
観察し操作するのに適した方法で自らを表現できなければ
ならない

オペレーティングシステムがこの原則を破っているようで
あることはちょっと注目すべきだろう。

オペレーティングシステムは言語におさまりきらないものを
集めたもので、これは存在すべきでない

Smalltalkにはそうした意味での「オペレーティングシステム」は
無い。

**デフォルトの名無しさん** · 2014/12/03(水) 01:07:46.87

この言語は危ないという前提があった方が、本当に危なくなった時に逃げやすいね
言語を信用しすぎると逃げ遅れる

**デフォルトの名無しさん** · 2014/12/03(水) 05:01:07.21

>>667
大抵のSmalltalk処理系はソース編集をジャーナリングしているのだが？
普通の開発環境でいえば、
テキストエディタで編集するごとに自動的にcommitしているようなもの。
PVSやMonticelloを使えばもっと高機能かつ安全だ。

むしろ、commitを自分でやらないと編集履歴が残らない
普通の開発環境のほうがよく考えなくても怖いことなんだけどな。

**デフォルトの名無しさん** · 2014/12/03(水) 09:01:37.48

>>675
OSの上でOSゴッコしてるだけのSmalltalkが笑わせてくれる

**デフォルトの名無しさん** · 2014/12/03(水) 09:09:27.83

>>677
もう少し分かりやすくいおう。

SmalltalkはVCSが言語に統合されている。

VCSが言語に統合されていない言語では、
自分で統合するかIDEの力を借りる。

そこまでセットアップする手間を省けるだけなのだ。

**デフォルトの名無しさん** · 2014/12/03(水) 09:13:57.48

>>671

> 大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク
> Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、
> コンポーネント間の結合に用いるオブジェクトに対しては id型という動的型付けを用いる
> 結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている

動的型付け言語じゃなくても達成出来てることを言われてもなｗ
だいたい発展し続けると言っても、再起動してるじゃん。
なぜ動的型付け言語ならではの理由が
あんたの言っていることには一つのないんだよね。

**デフォルトの名無しさん** · 2014/12/03(水) 09:21:29.91

>>677
マイナー言語のショボいVCS使ってないで
さっさとgit覚えてください

**デフォルトの名無しさん** · 2014/12/03(水) 10:48:31.33

なんでも理由があるべきという思い込みはよくない
実力だけでなく運で決まることもたくさんある

**デフォルトの名無しさん** · 2014/12/03(水) 11:22:27.25

>>681
Smalltalkを使っている人間はgitを理解できないと決めつける時点で
発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、
古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。

**デフォルトの名無しさん** · 2014/12/03(水) 12:24:53.21

>>673
> Smalltalkは見当違いの問題を解いている

Smalltalkはもう過去の遺物だし、問題はすでに解き終わっている。
あとはSmalltalkがどう解いたかを調べて理解するだけでいいと思うよ。
そこから使えそうなアイデアだけを引っ張ってきてちょっと見栄えをよくすれば、
運が良ければイノベーションや新しいトレンドも生み出せる（した人もいる）。

古くはWIMPなGUIしかり、MVCやコレクションなどのフレームワークしかり、
XPやTDDなどアジャイルな開発手法しかり、近年であればトレイトやクラスボックスしかり。

向いている方向が見当違いだというのは同意するけど、それはたまたま今は
ファイルシステムに密着したUNIXライクなOS＋C言語マシンで成り立つ世界だからで
そこから外れた物の見方はいっさい価値なしと切り捨ててしまうのは少しもったいない。

少し、だけどね。土方には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
食いつないでいくためにはまずそっちを優先すべきだし。

**デフォルトの名無しさん** · 2014/12/03(水) 14:17:36.95

>>678
原論文を理解できなかったなら正直にそう書けばいいのにw

**デフォルトの名無しさん** · 2014/12/03(水) 14:23:59.81

>>673
メインフレームを笑っていたUnix厨が
メインフレーム由来の仮想化技術をあたかも最新技術のように持て囃す、
あんたが好きな「価値」ってのはその程度のものだ
必死に追いかければ、その先に青い鳥がいるかもなあw

**デフォルトの名無しさん** · 2014/12/03(水) 20:48:36.10

Dockerはunixの世界においても枯れた既存技術の寄せ集めだし、
最新技術だから持て囃されてるんじゃないよ

標準化の動きが急速に進んでて、クラウドサービスにベンダーロックインされる危険が極小になる所が肝
あるクラウドサービスで動かしてた仮装イメージを、別のサービスに即座に引っ越せるようになる

メインフレームみたいに極限までロックインさせる話とは根本的に違う
やっぱり分かってないと言わざるを得ない

**デフォルトの名無しさん** · 2014/12/03(水) 21:23:44.95

ベンダーロックインを静的型にたとえると

短いソースをコンパイルするために多くのヘッダーをincludeすることを強制される
ヘッダーと本体が分かれていない言語では全部必要

**デフォルトの名無しさん** · 2014/12/03(水) 21:45:16.01

>>688
じゃあRubyもPythonもだめだな。

ブラウザで動くJavaScriptは大丈夫か？
include相当の構文がないもんなｗ

**デフォルトの名無しさん** · 2014/12/03(水) 21:49:32.75

>>684
> には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
> ついて行かなきゃいけないトレンドや技術がいっぱいあるから、

プロなら当たり前のことなんじゃねーの？

プロには目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、

うん、違和感ない

**デフォルトの名無しさん** · 2014/12/03(水) 22:07:22.24

>>689
モジュールの依存関係は大したことはない
型の依存関係は基底クラスやprivateメンバーの型まで伝播する

**デフォルトの名無しさん** · 2014/12/03(水) 22:22:38.66

そのおかげで、矛盾するもの。つまり
明らかに動かないコードを検出することが可能になっている。

動的型付け言語では、動かして該当コードに
たどり着かないとわからないバグを
動かすことなく見つけることが可能になってる。

これこそ、大規模開発で必要なことの一つなんだ。

**デフォルトの名無しさん** · 2014/12/03(水) 22:25:08.05

大規模炎上の主な原因はバグではなく設計ミスではないのか

**デフォルトの名無しさん** · 2014/12/03(水) 22:26:49.02

静的型の方がアカデミック方面での発展も凄いので
確かに学ぶことは多いと思うよ

**デフォルトの名無しさん** · 2014/12/03(水) 22:31:22.32

>>693
違う、営業的に決められた納期だな

**デフォルトの名無しさん** · 2014/12/03(水) 22:36:19.29

>>693
大規模炎上の話なんかしていないｗ

まず、スコープが小さいほど、変更が与える影響は少ない。
プライベートメソッドなら、クラスの外は関係ないし、
関数内の修正は、引数と戻り値さえ同じなら
どう修正しても問題ない。

修正の影響範囲が大きいのはスコープが多い時なんだ。
例えばクラスメソッド引数が変更された時、
その他の"すべての"ファイルから参照しているコードを突き止めないといけない。
基底クラスが変更になった時、その全ての派生クラスへの影響を考えないといけない。

そこに静的型付け言語のメリットが生きてくる。
動的型付け言語だと、クラスを変更した時、そのクラスの利用者全てを確認するのは難しい。
なぜなら変数に依存関係が明示されていないから。
静的型付け言語だと、変数に型を明示するから、変更による影響を瞬時に知ることができる。

これこそ大規模開発で必要なことなんだよ。

**デフォルトの名無しさん** · 2014/12/03(水) 22:43:05.49

うっかり基底クラスを変更したら
継承も知らないのかと疑われそうで嫌だな

**デフォルトの名無しさん** · 2014/12/03(水) 22:44:57.73

モジュール間の依存は小さくするというのは
ソフトウェアの開発者の常識だが、
なぜ小さくするのかというとモジュール間の依存が大きいと
修正する時に発生する影響範囲が大きくなって修正が大変だからなんだ。

だからモジュール間の依存は小さくするべきだが、
モジュールを連携してシステムが動く以上0にはできない。

例えば、obj.foo() というコードがあったとき、そこには
objはfooメソッドを持っていなければならないという依存情報が生まれる。

この依存情報を動的型付け言語では、実行時までチェックしない。
静的型付け言語ではobjの型を明示することで、
実行前にfooメソッドが有ることを確認できる。

影響範囲を確認することが大変なモジュール間の依存を
明確にすることで、不具合の発見を容易にし
修正のコストを減らすのが、静的型付け言語の特徴なんだ。

**デフォルトの名無しさん** · 2014/12/04(木) 01:15:00.87

インタフェースみたいにメソッドの実装を強制したいです
どうしますかおしえて

**デフォルトの名無しさん** · 2014/12/04(木) 02:09:44.10

したら良いんじゃない？
できない言語を使ってるの？

**デフォルトの名無しさん** · 2014/12/04(木) 08:48:23.43

>>699
実装しなかったら開発者をクビにする

**デフォルトの名無しさん** · 2014/12/04(木) 09:42:52.10

>>687
超マイナーなVCSや低性能のODBに
自分からロックインされに行く技術オンチのSmalltalkerには
遠い世界の話だな

**デフォルトの名無しさん** · 2014/12/04(木) 10:26:14.06

>>699
変数の初期化 (null以外) を強制したいとは言わないところが甘い
厳しいのか甘いのかはっきりしない機械は駄目だ
そういうのは人間の方が向いている

**デフォルトの名無しさん** · 2014/12/04(木) 12:32:36.38

>>702
> 超マイナーなVCSや低性能のODBに
> 自分からロックインされに行く

ありがたい話じゃないか。
そこまでしてSmalltalkから将来出てくるであろう新しい何かを育ててくれるんだから。
トレイトしかりクラスボックスしかり。

**デフォルトの名無しさん** · 2014/12/04(木) 19:31:17.50

>>702
Smalltalkでは何十年も昔から常識だったことが
新技術として他の言語や環境でも使えるようになったら
「こんな便利な技術は技術オンチのSmalltalkerには理解できないだろう」
とか言いながらありがたく使いなさいよ、技術乞食さんw

**デフォルトの名無しさん** · 2014/12/04(木) 20:15:36.06

>>704
traitはSmalltalk由来のじゃなくて
Haskellの型クラス由来のヤツが残りそう

やっぱり作ってる連中の知的レベルが段違いだしね？

**デフォルトの名無しさん** · 2014/12/04(木) 21:21:32.12

え？なに？俺の言語が起源だとかいう話をしてんの？

起源なんかどうでもよくて、その技術を
"今" 有効活用することのほうが大事だろ。

起源はベータ版。今その技術を取り入れた言語というのは
ベータ版を評価して、より優れた方法で取り入れてるってことなんだよ。

つまり、同じ機能であっても、起源よりも
後から取り入れた言語のほうが優れている。

初号機のほうが優れているっていうのは漫画の中の話だけだよ。
現実には、二号機、三号機の方が優れている。

**デフォルトの名無しさん** · 2014/12/04(木) 21:36:40.87

>>706
traitsとかホントは知らないんだろ？
implicit parameterと区別が付かないとかないわー

**デフォルトの名無しさん** · 2014/12/04(木) 21:47:04.11

>>708
この論文は読んだ上で言ってるの？
あ、Martin OderskyはScalaの作者ね

http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf

**デフォルトの名無しさん** · 2014/12/04(木) 21:48:59.20

>>707
パクる元がなければ改良もクソもないんだから
アイデアのゆりかご的存在は生かさず殺さずにしておく方がいい
って話なんだが。どうして優劣の話になるかな

**デフォルトの名無しさん** · 2014/12/04(木) 21:50:19.83

>>707
初号機には二号機をスルーして三号機に移行する作戦があるから
二号機はどうでもよい

**デフォルトの名無しさん** · 2014/12/04(木) 21:54:36.04

>>709
Scalaだからinterfaceの代わりにtraitを使っただけで、
型クラスとは関係ないだろう。

**デフォルトの名無しさん** · 2014/12/04(木) 22:05:12.01

>>712
最初の方だけでも読んでみようとは思わないの？

> This paper presents a lightweight approach to type classes in object-oriented (OO) languages
> with generics using CONCEPT pattern and implicits (a type-directed implicit parameter passing mechanism).
> This paper also shows how Scala's type system conspires with implicits to enable, and even surpass,
> many common extensions of the Haskell type class system, making Scala ideally suited for generic programming in the large.

**デフォルトの名無しさん** · 2014/12/04(木) 22:11:18.04

このペーパー、プレゼントします

最初の方だけ読みました！

**デフォルトの名無しさん** · 2014/12/04(木) 22:16:14.84

>>713
だからそれのどこにtraitが出てくるのさ。

Scalaのtraitsの出自について言及はこっちでしょ。
http://www.bytelabs.org/pub/tpl/slides/sm@lausanne/expressionProblem.pdf

Traits in SCALA[23] are abstract classes without state or
parameterized constructors; another way to characterize them
would be as JAVA-like interfaces that may also contain
inner classes and concrete implementations for some
methods. Unlike the original trait proposal[29], traits in Scala
are not different from classes. In the example above
and all examples that follow one could have also used
abstract class instead of trait.