- 動的言語で大規模開発
748 ：デフォルトの名無しさん[sage]：2014/12/05(金) 21:28:30.39 ID:5SBzstV5 - >>680
>動的型付け言語じゃなくても達成出来てることを言われてもなｗ
>>671 で
> Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、
と書いたように、静的型付けの C++ だけでは COM を使わなければ
コンポーネントの動的結合ができない
それに対して Objective-C は一般的な動的リンクライブラリにメタデータを加えて
ファイルを構成するだけで動的結合できるフレームワークを実現できる
動的型付けな Objective-C では同じ事を実現するのに、COM は不要
>だいたい発展し続けると言っても、再起動してるじゃん。
カーネルやデバイスドライバを更新した場合には OS の再起動は必要だ
ただし、ここで議論の対象としているのはライブラリやフレームワークとして提供される
コンポーネントの部分だよ
OSX/iOS では単に規定のフォルダへフレームワークをコピーするだけ
Windows の COM のようにレジストリへ GUID を登録するといった面倒な仕掛けは不要
> なぜ動的型付け言語ならではの理由が
> あんたの言っていることには一つのないんだよね。
静的型付け言語だけではコンポーネントの動的結合ができない(COM が必須)
モジュールの静的リンクだけでいい小規模の開発であれば静的型付け言語でもかまわないが、
コンポーネントを組み合わせる大規模なシステム開発では動的型付けの柔軟性が利点になる
この言語の差が OS という大規模開発における Windows の失敗と OSX/iOS の成功に影響した(>>671)
|
- 動的言語で大規模開発
753 ：デフォルトの名無しさん[sage]：2014/12/05(金) 22:08:26.02 ID:5SBzstV5 - >>749
DLL だけでは柔軟なコンポーネント結合が実現できなかったから、
Microsoft は COM(Component Object Model) という技術を開発した
言語に依存しないバイナリ互換性も COM の特徴であるけれど、
仮に C++ に閉じた開発であっても COM は必要になる
こんな話は COM を知っていれば常識
|
- 動的言語で大規模開発
754 ：デフォルトの名無しさん[sage]：2014/12/05(金) 22:40:22.11 ID:5SBzstV5 - >>732
これかな
・Rubyist Magazine - Rubyist のための他言語探訪 【第 2 回】 CLU
http://magazine.rubyist.net/?0009-Legwork
>>737
> いや。Rubyのブロック自体はLISPのlambda由来かと。
だね
Ruby は LISP をベースにして設計された
Ruby のブロックも LISP のクロージャ(ラムダ式)に由来する
・Lisp から Ruby への設計ステップ | プログラマーズ雑記帳
http://yohshiy.blog.fc2.com/blog-entry-250.html
|
- 動的言語で大規模開発
755 ：デフォルトの名無しさん[sage]：2014/12/05(金) 23:20:42.11 ID:5SBzstV5 - >>737
> 今のブロック付きメソッド呼び出し（昔はイテレータと呼んでいた）が
> CLUのイテレータから発想を得た…というだけで。
ここは違うと思うな
どちらかといえば Ruby が CLU から強い影響を受けたのは、
要素を返すのに yield 構文を用いる、いわゆる「内部イテレータ」だと思う
たとえば >>737 の 1 から 3 の範囲を CLU では以下のイテレータで表現する
from_to = iter(first:int, last:int) yields(int)
n:int := first
while n <= last
yield(n)
n := n + 1
end
end from_to
これを Ruby では以下のように書ける
def from_to(first, last)
n = first
while n <= last
yield n
n += 1
end
end
yield というイテレータ向けに専用の構文を用いる内部イテレータは、汎用的な外部イテレータ、
いわゆるジェネレータよりも反復処理の抽象化を簡潔に表現できる
内部イテレータは CLU で生まれ Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴
|