X

動的言語で大規模開発

■ このスレッドは過去ログ倉庫に格納されています
0001uy
垢版 |
2012/07/24(火) 09:10:42.04
たててみた
0650デフォルトの名無しさん
垢版 |
2014/12/01(月) 00:36:07.76ID:2BTgZC4D
>>645
そのゴミから色々なものが生まれた。
50年後には、そのゴミから新しいOSが生まれるかもよ。
0651デフォルトの名無しさん
垢版 |
2014/12/01(月) 00:39:00.66ID:JhMfQ7kZ
>>648
外部にツールが存在することと、
ある言語が Soft Typing で設計されている話は関係ないよ
Python の言語処理系(インタプリタ)だけで
明示的な型宣言が無くとも実行前に型検査できるなら
話は別だけどね

というか、Soft Typing という用語の意味を
間違って理解しているんじゃね？
0652デフォルトの名無しさん
垢版 |
2014/12/01(月) 00:42:41.17ID:v1/AC0CB
>>651
ある言語がSoft typingで設計されてるかなんて開発においてどうでも良すぎる
型推論に基づく実用的なツールがあるかどうかが重要
0653デフォルトの名無しさん
垢版 |
2014/12/01(月) 00:50:53.90ID:JhMfQ7kZ
いかん、アンカを間違えてた
エスパーしてくれてるみたいだけど、念の為、訂正しとく

・>>646 内のアンカ >>640 は間違いで、>>639 が正しい
・>>649 内のアンカ >>674 は間違いで、>>647 が正しい
0654デフォルトの名無しさん
垢版 |
2014/12/01(月) 04:58:08.58ID:CuP+pzia
>>559
かっこいいとかそういう基準で判断してるわけじゃないから。契約とか内容次第だから勝手なイメージだろ。
0655デフォルトの名無しさん
垢版 |
2014/12/01(月) 06:42:19.33ID:Weh8bUwF
645はクラスを名前空間だと思い込んでいる初心者
早く補助輪を取れるといいね
0657デフォルトの名無しさん
垢版 |
2014/12/02(火) 12:19:36.12ID:KrePR2s0
昔Basicはプログラマとしてのセンスを破壊すると言われたが、
今回Smalltalkも破壊することが判明したな
0659デフォルトの名無しさん
垢版 |
2014/12/02(火) 14:29:13.80ID:XRdoM1I9
“Smalltalkのデバッガがどのくらい強力かと言うと、
任意の時点で任意のプロセスをインタラプトし
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続できるレベル。

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

https://twitter.com/abee2/status/539355671729152000
0662デフォルトの名無しさん
垢版 |
2014/12/02(火) 19:49:38.18ID:OQmm7jB2
なんで役に立たないかというと

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

最初からやり直したほうが早い。
0664デフォルトの名無しさん
垢版 |
2014/12/02(火) 22:38:50.95ID:OQmm7jB2
人間はミスするとう前提の話をしてるんだが？
スキルや能力とは関係ない。

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

ということで静的型付け言語はそうなってるって話なんだよ。
0665デフォルトの名無しさん
垢版 |
2014/12/02(火) 22:48:09.93ID:DpCZ+4Qy
>>664
静的型言語（の特に機能を限定した言語）がスキルの期待できない土方向け
という意見には反対しない。
0666デフォルトの名無しさん
垢版 |
2014/12/02(火) 22:52:44.71ID:OQmm7jB2
一体何の機能が制限されているというのか？
タイプ数が少し増えるというのならわかる。
制限されているという機能の名前を聞いたことがないし、
どうでも良い機能のために、動的型付け言語を使うという話しか聞かない


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

デメリットはほんの少しタイプ量が増えるだけ
0667デフォルトの名無しさん
垢版 |
2014/12/02(火) 22:57:12.61ID:ySWWhxWC
修正したコードが実機の上、しかもファイルじゃなくてメモリ上にしかないとか
よく考えなくても怖いことなんだけどな。
0670デフォルトの名無しさん
垢版 |
2014/12/02(火) 23:23:32.69ID:DpCZ+4Qy
>>667
> しかもファイルじゃなくてメモリ上にしかないとか

って、まともなSmalltalk処理系ならチェンジファイル機構くらいはあるだろjk
0671デフォルトの名無しさん
垢版 |
2014/12/02(火) 23:41:57.12ID:f9ZuLJgk
>>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 の台頭を許した
0673デフォルトの名無しさん
垢版 |
2014/12/03(水) 00:24:16.86ID:B6A3kVmE
>>659
なぜDockerみたいな技術が持て囃され、こういう機能がスルーされるのか
Smalltalkerには永遠に理解できないんだろうな

Smalltalkは見当違いの問題を解いているんだよ
言語の中だけでリスタートできても意味がないんだ
価値がないから真似もされない
0675デフォルトの名無しさん
垢版 |
2014/12/03(水) 01:03:45.51ID:cgD8+cJC
>>673
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

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

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

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

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

Smalltalkにはそうした意味での「オペレーティングシステム」は
無い。
0676デフォルトの名無しさん
垢版 |
2014/12/03(水) 01:07:46.87ID:9SD5P0Ri
この言語は危ないという前提があった方が、本当に危なくなった時に逃げやすいね
言語を信用しすぎると逃げ遅れる
0677デフォルトの名無しさん
垢版 |
2014/12/03(水) 05:01:07.21ID:Fu5jXwDM
>>667
大抵のSmalltalk処理系はソース編集をジャーナリングしているのだが？
普通の開発環境でいえば、
テキストエディタで編集するごとに自動的にcommitしているようなもの。
PVSやMonticelloを使えばもっと高機能かつ安全だ。

むしろ、commitを自分でやらないと編集履歴が残らない
普通の開発環境のほうがよく考えなくても怖いことなんだけどな。
0679デフォルトの名無しさん
垢版 |
2014/12/03(水) 09:09:27.83ID:RRftfJUJ
>>677
もう少し分かりやすくいおう。

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

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

そこまでセットアップする手間を省けるだけなのだ。
0680デフォルトの名無しさん
垢版 |
2014/12/03(水) 09:13:57.48ID:RRftfJUJ
>>671

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

動的型付け言語じゃなくても達成出来てることを言われてもなｗ
だいたい発展し続けると言っても、再起動してるじゃん。
なぜ動的型付け言語ならではの理由が
あんたの言っていることには一つのないんだよね。
0682デフォルトの名無しさん
垢版 |
2014/12/03(水) 10:48:31.33ID:9SD5P0Ri
なんでも理由があるべきという思い込みはよくない
実力だけでなく運で決まることもたくさんある
0683デフォルトの名無しさん
垢版 |
2014/12/03(水) 11:22:27.25ID:zGKDhFQQ
>>681
Smalltalkを使っている人間はgitを理解できないと決めつける時点で
発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、
古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。
0684デフォルトの名無しさん
垢版 |
2014/12/03(水) 12:24:53.21ID:zGKDhFQQ
>>673
> Smalltalkは見当違いの問題を解いている

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

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

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

少し、だけどね。土方には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
食いつないでいくためにはまずそっちを優先すべきだし。
0686デフォルトの名無しさん
垢版 |
2014/12/03(水) 14:23:59.81ID:Fu5jXwDM
>>673
メインフレームを笑っていたUnix厨が
メインフレーム由来の仮想化技術をあたかも最新技術のように持て囃す、
あんたが好きな「価値」ってのはその程度のものだ
必死に追いかければ、その先に青い鳥がいるかもなあw
0687デフォルトの名無しさん
垢版 |
2014/12/03(水) 20:48:36.10ID:nRr7XZh4
Dockerはunixの世界においても枯れた既存技術の寄せ集めだし、
最新技術だから持て囃されてるんじゃないよ

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

メインフレームみたいに極限までロックインさせる話とは根本的に違う
やっぱり分かってないと言わざるを得ない
0688デフォルトの名無しさん
垢版 |
2014/12/03(水) 21:23:44.95ID:o4Xb4UE8
ベンダーロックインを静的型にたとえると

短いソースをコンパイルするために多くのヘッダーをincludeすることを強制される
ヘッダーと本体が分かれていない言語では全部必要
0689デフォルトの名無しさん
垢版 |
2014/12/03(水) 21:45:16.01ID:RRftfJUJ
>>688
じゃあRubyもPythonもだめだな。

ブラウザで動くJavaScriptは大丈夫か？
include相当の構文がないもんなｗ
0690デフォルトの名無しさん
垢版 |
2014/12/03(水) 21:49:32.75ID:RRftfJUJ
>>684
> には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
> ついて行かなきゃいけないトレンドや技術がいっぱいあるから、

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


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

うん、違和感ない
0691デフォルトの名無しさん
垢版 |
2014/12/03(水) 22:07:22.24ID:o4Xb4UE8
>>689
モジュールの依存関係は大したことはない
型の依存関係は基底クラスやprivateメンバーの型まで伝播する
0692デフォルトの名無しさん
垢版 |
2014/12/03(水) 22:22:38.66ID:RRftfJUJ
そのおかげで、矛盾するもの。つまり
明らかに動かないコードを検出することが可能になっている。

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

これこそ、大規模開発で必要なことの一つなんだ。
0694デフォルトの名無しさん
垢版 |
2014/12/03(水) 22:26:49.02ID:B6A3kVmE
静的型の方がアカデミック方面での発展も凄いので
確かに学ぶことは多いと思うよ
0696デフォルトの名無しさん
垢版 |
2014/12/03(水) 22:36:19.29ID:RRftfJUJ
>>693
大規模炎上の話なんかしていないｗ

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

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

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

これこそ大規模開発で必要なことなんだよ。
0697デフォルトの名無しさん
垢版 |
2014/12/03(水) 22:43:05.49ID:o4Xb4UE8
うっかり基底クラスを変更したら
継承も知らないのかと疑われそうで嫌だな
0698デフォルトの名無しさん
垢版 |
2014/12/03(水) 22:44:57.73ID:RRftfJUJ
モジュール間の依存は小さくするというのは
ソフトウェアの開発者の常識だが、
なぜ小さくするのかというとモジュール間の依存が大きいと
修正する時に発生する影響範囲が大きくなって修正が大変だからなんだ。

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

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

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

影響範囲を確認することが大変なモジュール間の依存を
明確にすることで、不具合の発見を容易にし
修正のコストを減らすのが、静的型付け言語の特徴なんだ。
0699デフォルトの名無しさん
垢版 |
2014/12/04(木) 01:15:00.87ID:jHjIGczB
インタフェースみたいにメソッドの実装を強制したいです
どうしますかおしえて
0702デフォルトの名無しさん
垢版 |
2014/12/04(木) 09:42:52.10ID:rp/BpD2j
>>687
超マイナーなVCSや低性能のODBに
自分からロックインされに行く技術オンチのSmalltalkerには
遠い世界の話だな
0703デフォルトの名無しさん
垢版 |
2014/12/04(木) 10:26:14.06ID:5ZEJ+Feh
>>699
変数の初期化 (null以外) を強制したいとは言わないところが甘い
厳しいのか甘いのかはっきりしない機械は駄目だ
そういうのは人間の方が向いている
0704デフォルトの名無しさん
垢版 |
2014/12/04(木) 12:32:36.38ID:TqunBxc9
>>702
> 超マイナーなVCSや低性能のODBに
> 自分からロックインされに行く

ありがたい話じゃないか。
そこまでしてSmalltalkから将来出てくるであろう新しい何かを育ててくれるんだから。
トレイトしかりクラスボックスしかり。
0705デフォルトの名無しさん
垢版 |
2014/12/04(木) 19:31:17.50ID:mwV5k8HO
>>702
Smalltalkでは何十年も昔から常識だったことが
新技術として他の言語や環境でも使えるようになったら
「こんな便利な技術は技術オンチのSmalltalkerには理解できないだろう」
とか言いながらありがたく使いなさいよ、技術乞食さんw
0706デフォルトの名無しさん
垢版 |
2014/12/04(木) 20:15:36.06ID:rp/BpD2j
>>704
traitはSmalltalk由来のじゃなくて
Haskellの型クラス由来のヤツが残りそう

やっぱり作ってる連中の知的レベルが段違いだしね？
0707デフォルトの名無しさん
垢版 |
2014/12/04(木) 21:21:32.12ID:tYdcY83W
え？ なに？ 俺の言語が起源だとかいう話をしてんの？

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

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

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

初号機のほうが優れているっていうのは漫画の中の話だけだよ。
現実には、二号機、三号機の方が優れている。
0710デフォルトの名無しさん
垢版 |
2014/12/04(木) 21:48:59.20ID:RpORv8ek
>>707
パクる元がなければ改良もクソもないんだから
アイデアのゆりかご的存在は生かさず殺さずにしておく方がいい
って話なんだが。どうして優劣の話になるかな
0713デフォルトの名無しさん
垢版 |
2014/12/04(木) 22:05:12.01ID:8pz5p6Zv
>>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.
0715デフォルトの名無しさん
垢版 |
2014/12/04(木) 22:16:14.84ID:RpORv8ek
>>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.
0717デフォルトの名無しさん
垢版 |
2014/12/04(木) 22:24:26.97ID:8pz5p6Zv
こういう研究の流れを受けてか、後発のRustのtraitは
最初からHaskellのType Classそっくりになっているんですってよ
0718デフォルトの名無しさん
垢版 |
2014/12/04(木) 22:29:19.94ID:RpORv8ek
>>716
>>712

In this definition, the role of ord T is to provide the comparison
function for elements of type T. The Ord[T] interface, expressed
as a trait in Scala,
0719デフォルトの名無しさん
垢版 |
2014/12/04(木) 22:30:05.46ID:tYdcY83W
始めに実装したというのは凄いかもしれないけど、
その凄いっていうのは、始めに実装したことであって
その機能がすごいってことじゃないんだよな。
後発のほうがもっとその機能を強化している。

そして始めに実装した言語は互換性を保つために
機能強化できずにずっと続けないといけない。
0720デフォルトの名無しさん
垢版 |
2014/12/04(木) 22:45:30.93ID:RpORv8ek
>>719
それははじめに機能ありきで、それをただ実装した場合の話だろう。
試行錯誤して生まれるには、それをインキュベートする環境が必要でって話なんだが
計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を説明するのは難しい。
0721デフォルトの名無しさん
垢版 |
2014/12/04(木) 22:52:15.50ID:8pz5p6Zv
>>718

> The trait Ord[T] is an example of a concept interface.

> Concept interfaces for the type classes Show and Read presented in Section 2.1 are:
0722デフォルトの名無しさん
垢版 |
2014/12/04(木) 23:00:58.08ID:5ZEJ+Feh
宇宙服みたいな言語とモビルスーツみたいな言語があるけど
どうせ結局両方使うんだよな
0723デフォルトの名無しさん
垢版 |
2014/12/04(木) 23:08:55.47ID:RpORv8ek
>>721
何そのパズルみたいな抜粋。
どうこねくり回したところでScalaのtraitに限っては
その出自はミックスインみたいなもので、型クラスそのものではないよ。
0724デフォルトの名無しさん
垢版 |
2014/12/04(木) 23:11:32.11ID:8pz5p6Zv
>>723
ついに反論しきれなくなって、traitとtype classは無関係から
そのものでは無いまで意見が後退しちゃったねw
自分もtype classそのものなんて一度も言ってないので、もうそれで良いよ
0726デフォルトの名無しさん
垢版 |
2014/12/04(木) 23:24:08.54ID:BoUkojKR
A君「絵を描くのは好きだけど、仕事と両立するのは難しいなぁ」
ニート「一日中ヒマだから絵を描き放題だぜ」

A君「ついに絵を描く仕事に就いたぞ。好きなことして食べていける」
ニート「もう20年前から好きなことだけやれてたわ〜。遅れてんな〜やれやれ」
0732デフォルトの名無しさん
垢版 |
2014/12/05(金) 09:04:37.51ID:t8jCTeme
RubyのブロックってCLUのイテレーター由来じゃなかったっけ？
ずいぶん前にMatzがそんなようなことを言っていた記憶が
0734デフォルトの名無しさん
垢版 |
2014/12/05(金) 09:16:51.57ID:+TXyzC2W
>>733
それお前じゃね？

一応言っておくと、わかってると自称する
お前が説明してみろって意味だよ。
0737デフォルトの名無しさん
垢版 |
2014/12/05(金) 12:26:12.88ID:51P5EYrc
>>732
いや。Rubyのブロック自体はLISPのlambda由来かと。
今のブロック付きメソッド呼び出し（昔はイテレータと呼んでいた）が
CLUのイテレータから発想を得た…というだけで。

もっとも個人的には（着想はともかく最終的には）
Smalltalkのブロックを引数にとるメソッド呼び出しの見た目だけパクったものだと思うけどね。

▼CLUのイテレータ
start_up = proc ()
　po : stream := stream$primary_output()
　xs : array[int] := array[int]$[1,2,3]
　for x : int in xs!elements do
　　po!putl(x!unparse)
　end
end start_up

▼初期のRubyのイテレータ
do [1,2,3].each using x; print(x, "\n") end

▼現行のRubyのblock付きメソッド呼び出し（旧呼称はイテレータ）
[1,2,3].each{ |x| puts x }

▼Smalltalkのブロックを引数にとるメソッド呼び出し
#(1 2 3) do: [:x | x logCr ]

▼LISPのループ（lambdaの出番はない^^;）
(loop for x in '(1 2 3) do (print x))

▼Schemeのlambda
(for-each (lambda (x) (print x)) '(1 2 3))
(for-each print '(1 2 3)) ;;←実際はlambda使わずにこれでおｋ
0738デフォルトの名無しさん
垢版 |
2014/12/05(金) 12:31:26.53ID:+5KFbbdu
動的言語には型名を考えるコストがない
ある物の名前がラムダかクロージャか議論するのに何時間かかるか考えてみろ
0741デフォルトの名無しさん
垢版 |
2014/12/05(金) 16:19:55.77ID:+5KFbbdu
インタフェース継承で派生クラスの名前は必須ではない
これは静的でも成り立つ
更に突き詰めると必要なのはメンバの名前のみなのでインタフェースの名前も不要

Smalltalkは実装継承にこだわっているので名前は必要かもしれんが他の動的言語は違う
0742デフォルトの名無しさん
垢版 |
2014/12/05(金) 18:10:35.44ID:N759beub
>>741
> 実装継承にこだわっているので名前は必要

なぜ実装継承にこだわると名前が必要になるのか教えてほしい。
0743デフォルトの名無しさん
垢版 |
2014/12/05(金) 20:31:39.15ID:+TXyzC2W
>>738
何言ってんだ？
型がなくてどうやってオブジェクトをnewするんだよ？ｗ
new 型名 って書くだろが。

動的型付け言語にないのは型じゃなくて、
変数（関数の引数含む）に型が書いてないから
いろんな型が入れられてしまうって話だろ。

ローカル変数ならともかく、関数の引数、
つまり外部モジュールとのインターフェース部分にまで
型を書かないから、複数のモジュールを連携して作るような
大規模（中規模？ いやいやサンプル以上の規模）になればなるほど、
大きくなっていく影響範囲を把握するのが大変になるって話だよ。

変数に型がないから、影響範囲がわからない、
もしくは限定的になり、人間の負担が大きくなる。
0744デフォルトの名無しさん
垢版 |
2014/12/05(金) 20:46:05.48ID:+TXyzC2W
>>741
> インタフェース継承で派生クラスの名前は必須ではない

そりゃそうだよ。問題にしているのは人間が大変かどうかの話なんだから。
技術者はよく、技術的に可能かどうかで答えるだけで
制限時間内に終えられるかどうかを答えなくて困る。

ミスをしない人間がいて、タイプミスもせず、ードの全てを覚えていて、
仕様の変更もしない。もしくは理想的な変更しか起こらず、時間の制限もない。
そういうありえない世界でなら何の問題もないんだよ。

現実には何万行、何十万行というコードを知っている人が
会社をやめて、新しく入ってきた人が期限内に修正しなければならない。

いいかい？ 問題は可能か不可能かじゃないんだ。
コードの全てを把握していない人が、どちらの方が短い時間で
コードを把握できて、ミスをせずに修正できるかって話なんだ。

それがわかっていれば、この関数の引数は、どんなものが入ってくる可能性があって
（むしろ入ってこないものが断定できて）広大なコードの海で、どこから使われているか
目視、もしくはIDEなどのツールを使って100%の信頼性で調べれる方がいいってわかるだろう？
0745デフォルトの名無しさん
垢版 |
2014/12/05(金) 20:46:44.48ID:+5KFbbdu
実装に名前をつけて保存するからだろ

インタフェースは保存しなくてよい
下手すると名前の長さが中身より長くなるから
0747デフォルトの名無しさん
垢版 |
2014/12/05(金) 21:12:23.79ID:+TXyzC2W
>>745
> 下手すると名前の長さが中身より長くなるから

まあ、まず無いが、仮に名前の長さが中身より長くなるからといって
どんなデメリットが有るというのかね？
0748デフォルトの名無しさん
垢版 |
2014/12/05(金) 21:28:30.39ID: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)
0749デフォルトの名無しさん
垢版 |
2014/12/05(金) 21:30:47.47ID:+TXyzC2W
> と書いたように、静的型付けの C++ だけでは COM を使わなければ
> コンポーネントの動的結合ができない

別にDLLでもできるけど？

そもそもCOMがあるのは特定の言語に依存しないための
仕様を作ることが目的であって

同じ言語であれば、DLLでできるんだよ。

もうしょっぱなからだめじゃんｗ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況