動的言語で大規模開発
■ このスレッドは過去ログ倉庫に格納されています
アヒルのインスタンスを実行時にその振る舞いから分類というけれど、 コード自体は、実行時に分類してないんだよ。 コードは、アヒルであること、を前提として書いてる。 実行前にコードで分類しているのに、 なぜ実行時に分類しないといけないのか。 型は動的に変わるが、コードは静的なのである。 >>583 > だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ だから大規模では無理なんだよ。 大規模=大多数の人間が係る。場合によっては全く知らない人が作った ライブラリを使うこともあるしな。 そんなんで、すべて意味を揃えるなんてことは不可能 いくつもの意味を持つ英単語なんてざらにある 単語の意味を揃えるのは不可能。というのが大前提 >>584 コードも動的だから「動的」なんだよ それとも、単なる動的型付けの話をしている? >>581 Interfaceも構造的部分型も実行時に動的に分岐する そうでなければポリモーフィズムとは言わない さらに言えば、構造的部分型は「アヒルというクラス」に対して分類してるわけでもない >>585 とはいえ Objectクラスだけで500近いメソッド数をもっているにもかかわらず 不特定多数の開発者からのコードを集めたSmalltalkシステムは ちゃんと動いているわけだが >>588 SmalltalkでObjectに500もメソッドなんてねーよw あったとしたら、アンチパターン ゴッドクラス (設計の一部分(クラス)に、過剰に機能を集中させること)に 適合してしまうわw >>587 分岐(メソッド探索)の話などしていない どの式がどのインターフェースを実装しているのかを実行時に検査してるのか? どの式がどの型の部分型かを実行時に検査しているのか? へー、それ、なんていう言語だい? >>589 わかりやすい静的脳だな Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw >>585 大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で 同じ意味の機能に同じインターフェースを持たせるのは不可能 インターフェース方式は、ある数値計算ライブラリと別の行列演算ライブラリを混ぜて使う場合などで問題になる >>590 実行時にvalidationするのがダックタイピングというなら 構造的部分型は確かに違うな "If it walks like a duck and quacks like a duck, it must be a duck" という文章からそのような意味を読み取るのは無理だが >>591 > Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw 最悪だな。JavaScriptでprototypejsっていうのがあったけど、 名前が標準のメソッドとobjectに追加したメソッド名が 被って大変な目にあっていた。 それ移行Objectにメソッドを追加するのは ダメなやり方だって広く知られるようになったね。 >>570 いや。duck typing とは言わないけれど、Smalltalk の動的型と 同様の柔軟性を持たせつつ型安全を目指したのがインターフェイス。 (Eiffel流のクラスの継承をサブタイプに使うと型安全でないという流れで) http://www.cs.utexas.edu/ ~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf >>592 Haskellの型クラス、Rustのトレイト等が それらの問題点を解決している >>593 If it walks like a duckというのは、実際のitの振る舞いのことを指しているのだから実行時のことだと考えるのが自然だと思うが? If it will walk like a duckならばコンパイルだろうけどな。 >>594 >名前が標準のメソッドとobjectに追加したメソッド名が >被って大変な目にあっていた。 初心者だな 当分補助輪をつけることをお勧めするw >>589 Squeak Smalltlk(Squeak4.5)で調べたけど いろんな意味で残念ながら^^; 500近くはあるな。Object allSelectors size "=> 486 " >>592 >大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で >同じ意味の機能に同じインターフェースを持たせるのは不可能 そういう初心者は補助輪(静的型)を使えばいいよw ちなみに動的言語の環境では 様々なライブラリでどういうメソッド名がつけられているか検索する仕組みと 指定したメソッド名のメソッドを検索する仕組みが 遥か80年代から用意されていたりするけどなw >>599 動的言語では全オブジェクト共通の語彙が重要だから当然そうなる >>555 とりあえず、アラン・ケイが書いていることを読もうや。 そもそも「その頃は」って思い込み激しすぎるだろう。 これ書かれたの1999年〜2000年頃だし。 >>597 静的型でも振る舞うのは実行時だろ チェック自体はコンパイル時だが で、どこに実行時にチェックすると書いてある? >>601 とはいえ、Squeak のカオス化に嫌気してフォークされた Pharo は だいぶ減らして 374 だし(3.0調べ)、VisualWorks はもとより 303(7.10調べ)だけどね。 >>601 補完がうんこ過ぎるからそんなカオスになってんだろ クラスの名前空間としての機能が死んでる >>600 静的型(ていうかJava)のインターフェースの話だよ 動的なら名前合わせときゃ良いんだから問題ならん >>608 乙^^ ちなみにファンお手製で変わり種のGNU Smalltalkだとわずか123。 http://ideone.com/D9lo8c >>595 >いや。duck typing とは言わないけれど、 引用した論文は静的型付け言語における継承の意味論モデルに関する内容であり、 duck typing や interface とは直接的に関係してない Smalltalk における継承の意味について、Effel は Smalltalk と同じように柔軟だけど型安全ではなく、 Modula-3 や C++ は型安全だけど Smalltalk とは意味が異なる この論文では、Smalltalk と同じ継承の意味を持ちかつ安全な新しい意味論モデルを提案している まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね なお、ここで言う「継承の意味」とは、具体的には Smalltalk の疑似変数 self や super のこと たとえば Smalltalk と同じ意味論を持つ Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ それに対して、Smalltalk とは異なる意味論の Modula-3 を参考にして継承が設計された Python では self や super に相当する疑似変数は存在せず、わざわざメソッドの引数で __self__ を明示しなければならない 結果として Python は動的型付け言語であるにもかかわらず、Smalltalk や Ruby と同等レベルの柔軟な オブジェクト指向プログラミングができないという言語設計上の欠陥を抱えている この意味論モデルは、以下の論文で詳細に解説されている http://www.cs.utexas.edu/ ~wcook/papers/thesis/cook89.pdf オブジェクト指向プログラミングをするのが目的ではない。 巨大なシステムをより早くより安全に開発するのが目的なのだ。 オブジェクト指向上の欠陥とやらが何か知らんが、 そのお陰で実用レベルの型推論(補完や型検査)が出来てるなら面白いな 人間が間違わずに全てのコードを脳に記憶して タイプミスすらしないことを前提にするならば、 コードにわざわざ記憶の断片(つまり型情報)を書く必要はないよ。 それができないから、型情報を書いたほうが わずかの手間だけで、そのあとずっと楽ができるわけで。 >>570 すまん。こっちだった。 Interfaces for Strongly-Typed Object-Oriented Programming http://www.cs.utexas.edu/ ~wcook/papers/OOPSLA89/interfaces.pdf >>612 >オブジェクト指向上の欠陥とやらが何か知らんが、 有名な Python のself地獄だよ キーワード「python self地獄」で検索すればGoogle先生が教えてくれる Python しか知らなければself地獄が気にならないかもしれないけど、 Smalltalk や Ruby を知っている人からすれば、無知は幸せだなぁと見る これの基礎が「継承の意味論における差異」になる なお単に意味論の違いだから、self地獄と引き換えに 実用的な型推論(補完や型検査)が手に入るわけではない 両者の間に直接的な関連性は無い(言い換えるとスレチな話題) >>615 self地獄はGuidoが変人なだけで意味論なんて高尚な理由じゃねーだろ self省略できるようにパーサ弄れない意味論的理由は何だよ それこそ関係ねーよ >>610 > Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ Ruby の super は Smalltalk とは違うよ? >>615 > 両者の間に直接的な関連性は無い(言い換えるとスレチな話題) スレの主題に沿っているのは補完や型チェックの方だけど >>614 この論文内では duck typing という用語は一度も使われていないし、 タイトルに Strongly-Typed と書かれているように静的型付け言語に関する内容だ で、いったいどこから duck typing を連想したの? >>618 >スレの主題に沿っているのは補完や型チェックの方だけど まったくそのとおり だから >>610 では > まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね と書いた >>619 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ abstract斜め読みしただけだがSmalltalkには言及されてんぞ あれ?int型の+とstring型の+に対するオーバーロードみたいな話になってる? 無知なら口だすなと言われそうなので黙っておきます… >>621 そうか。じゃあスレ違いの話は止めないと荒らしになってしまうな >>616 Python のオブジェクト指向は Modula-3 を参考にしているけど、 Modula-3 のオブジェクト指向は Simula を参考にしている そして疑似変数 self の概念は Simula には存在せず、 Simula を参考にした Smalltalk で生まれた だから、Modula-3 や Python に疑似変数 self は存在せず、 これを模倣するにはメソッド引数で明示的に __self__ を 渡さなければならない訳 あと疑似変数 self の値は実行時に決まるから、 もし Python で __self__ を省略できるようにするためには、 構文論(syntax)の変更すなわちパーザの改造だけではダメで、 意味論(semantics)も変更しなければならない こうした背景も知らずに「変人だから」という理由で決めつけるのは、 Guido氏に失礼だと思うよ もう、超優秀なIDEがあって動的構造取り入れた c# 最強って事で良いんじゃないの? >>626 MSが他の処理系を駆逐する勢いでLinux版頑張ったら近い将来にそうなるかも。 種だけ蒔いて後知らねっていう可能性も高いけど。 >>622 > 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ そうだろ、だから驚いて >>619 では >>で、いったいどこから duck typing を連想したの? と書いた 論文を引用するのはいいけど、この論文をどう解釈して duck typing に結びつけたのか、 説明が無ければ意味が分からんという話だよ >abstract斜め読みしただけだがSmalltalkには言及されてんぞ Smalltalk の柔軟な継承を強い型付け(=静的型付け)なOO言語に取り込むために インターフェイスを用いる、という文脈でね 動的型付けを濫用するというニュアンスを持つ duck typing とは何の関係も無い この論文、型システムと言語設計に興味がある人にはとても有益だから、 斜め読みと言わずじっくり読んでみたほうがいいと思うな >>616 http://neopythonic.blogspot.jp/2008/10/why-explicit-self-has-to-stay.html ・ただの関数を、後からクラスにメソッドとして後付けできること(そのとき暗黙のselfの扱い) ・decoratorがあるから(動的にstatic methodやclass methodに変更できる) というのが理由だそうだ >>627 Roslyn凄そうだが、どんだけのヤツが付いていけるんだろ。 >>626 動的構造ってなんだっけ 実行時型情報ならC++にもあるけど むしろ実行時型情報がない言語の方が良いんだろ ほぼ全部関数型言語だけど >>629 Smalltalk や Ruby なら、暗黙のselfがあっても 後からクラスにメソッドを後付けできるのにね.... 言語だけでいうならRustに期待しているんだが…… >>682 > 後からクラスにメソッドを後付けできるのにね.... それは静的型付け言語のメリットをなくしてまで やるべき重要な事なのか? >>634 おいおい、Python は動的型付け言語だよ >>632 その代わりに関数が無くてProcオブジェクトとかいう キモい代用品を使わされるゴミでしょRubyって >>633 そこでまた振り出しに戻るのだが、ちょこちょこって遊ぶならどの言語でも いいのだが、ガッツリ使おうとするとツールもしっかりしてないとねというのに 戻るわけです。 >>635 実用レベルで型推論出来る言語と 出来ないゴミを一緒にすんなよ PythonはSoft typingが実用化されてんの >>636 いや、Procオブジェクトを明示的にコーディングするのは稀だ クロージャの無い Python とは違って、 Ruby だと普通は do |x| ... end や { |x| .... } で書ける >>640 お前クロージャスレでフルボッコにされた奴か ここでもフルボッコじゃねーかw >>637 スレタイでいうところの大規模開発なら特にそうだな 残念ながら言語の優先順位は低いと言わざるを得ない 結局は、静的言語が動的言語の要素を取り入れて進化し、両方の境界が曖昧になるんだよ。 >>641 逆だろw クロージャを使えば簡潔に書けるのに、結局 Python ではコードが書けずに終わった で、しまいに火病を発症してわめきちらしただけ、それがフルボッコなのか?www 今からでもいいから Python でコード書いてみな >>643 そしてObjectに500個もメソッドを突っ込んで悦に入ってるゴミは サーベルタイガーのように進化から取り残される、と >>640 ほう、Python で Soft Typing が実用化されたとは初耳だ ググってみると2003年に提案はあったものの、 その後に実装されたという情報は見つけられなかった 本当に実用化されているの? また嘘でも何でも議論に勝ちさえばいいという発想じゃないのかなあ.... >>644 え?お前が勝手なクロージャの定義を持ち出して、 出展となる文献を出せと言われても出せず逃げただけじゃん で、文献は? >>674 クロージャの話題は完全にスレ違いだから、 続きを希望するなら当該スレへ移動してくれ 文献もそこで出すよ >>645 そのゴミから色々なものが生まれた。 50年後には、そのゴミから新しいOSが生まれるかもよ。 >>648 外部にツールが存在することと、 ある言語が Soft Typing で設計されている話は関係ないよ Python の言語処理系(インタプリタ)だけで 明示的な型宣言が無くとも実行前に型検査できるなら 話は別だけどね というか、Soft Typing という用語の意味を 間違って理解しているんじゃね? >>651 ある言語がSoft typingで設計されてるかなんて開発においてどうでも良すぎる 型推論に基づく実用的なツールがあるかどうかが重要 いかん、アンカを間違えてた エスパーしてくれてるみたいだけど、念の為、訂正しとく ・>>646 内のアンカ >>640 は間違いで、>>639 が正しい ・>>649 内のアンカ >>674 は間違いで、>>647 が正しい >>559 かっこいいとかそういう基準で判断してるわけじゃないから。契約とか内容次第だから勝手なイメージだろ。 645はクラスを名前空間だと思い込んでいる初心者 早く補助輪を取れるといいね そんなつまらない事にしかレスできないから 馬鹿にされるんだよw 昔Basicはプログラマとしてのセンスを破壊すると言われたが、 今回Smalltalkも破壊することが判明したな “Smalltalkのデバッガがどのくらい強力かと言うと、 任意の時点で任意のプロセスをインタラプトし 実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、 その時の内部状態を観察してソースコードを修正、コンパイルした後、 そのままリジュームして処理を継続できるレベル。 デバッガは何枚でも開けられるし、作業の途中でやめたくなったら、 スナップショットを撮って終了し、再開すればその直前から続けられる。 たとえ、それが他のコンピューターでも(直接下回りを触っていない限り、 プラットフォームやOSが違っていても可)、それが10年後でも。” https://twitter.com/abee2/status/539355671729152000 10年とか先にarmのcpuが流行ってるとは思わなかったでしょ なんで役に立たないかというと 実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、 その時の内部状態を観察してソースコードを修正、コンパイルした後、 そのままリジュームして処理を継続したらバグで変な状態になった。 また止めて変な状態を直して、正しい所に移動させて続けることも可能だけど 最初からやり直したほうが早い。 >>662 ま、結局どんな凄い機能も、 使う人間のスキルと能力が足りなきゃゴミ以下って話だね。 人間はミスするとう前提の話をしてるんだが? スキルや能力とは関係ない。 ミスしないようなすごい人しか使えない道具ではなく、 ミスしてもすぐにリカバリできる仕組みを作るほうが重要。 ということで静的型付け言語はそうなってるって話なんだよ。 >>664 静的型言語(の特に機能を限定した言語)がスキルの期待できない土方向け という意見には反対しない。 一体何の機能が制限されているというのか? タイプ数が少し増えるというのならわかる。 制限されているという機能の名前を聞いたことがないし、 どうでも良い機能のために、動的型付け言語を使うという話しか聞かない 静的型付け言語で出来ないことはないし、(たとえば、C言語は静的型付け言語) 多くのことが動的型付け言語よりも便利に行える。 デメリットはほんの少しタイプ量が増えるだけ 修正したコードが実機の上、しかもファイルじゃなくてメモリ上にしかないとか よく考えなくても怖いことなんだけどな。 >>664 人間はミスするけど爆発しないよ 機械は爆発する 大規模なら大爆発 >>667 よく考えてたら、VCSにチェックインするとか想像できそうなものだけど。 >>667 > しかもファイルじゃなくてメモリ上にしかないとか って、まともなSmalltalk処理系ならチェンジファイル機構くらいはあるだろjk >>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 の台頭を許した >>659 なぜDockerみたいな技術が持て囃され、こういう機能がスルーされるのか Smalltalkerには永遠に理解できないんだろうな Smalltalkは見当違いの問題を解いているんだよ 言語の中だけでリスタートできても意味がないんだ 価値がないから真似もされない >>673 http://web.archive.org/web/20041016084842/http ://marimpod.homeip.net/chomswiki/24# 計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を 説明するのは難しい。 ユーザーがアクセスできる部品のすべてはユーザーが 観察し操作するのに適した方法で自らを表現できなければ ならない オペレーティングシステムがこの原則を破っているようで あることはちょっと注目すべきだろう。 オペレーティングシステムは言語におさまりきらないものを 集めたもので、これは存在すべきでない Smalltalkにはそうした意味での「オペレーティングシステム」は 無い。 この言語は危ないという前提があった方が、本当に危なくなった時に逃げやすいね 言語を信用しすぎると逃げ遅れる >>667 大抵のSmalltalk処理系はソース編集をジャーナリングしているのだが? 普通の開発環境でいえば、 テキストエディタで編集するごとに自動的にcommitしているようなもの。 PVSやMonticelloを使えばもっと高機能かつ安全だ。 むしろ、commitを自分でやらないと編集履歴が残らない 普通の開発環境のほうがよく考えなくても怖いことなんだけどな。 >>675 OSの上でOSゴッコしてるだけのSmalltalkが笑わせてくれる >>677 もう少し分かりやすくいおう。 SmalltalkはVCSが言語に統合されている。 VCSが言語に統合されていない言語では、 自分で統合するかIDEの力を借りる。 そこまでセットアップする手間を省けるだけなのだ。 >>671 > 大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク > Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、 > コンポーネント間の結合に用いるオブジェクトに対しては id型 という動的型付けを用いる > 結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている 動的型付け言語じゃなくても達成出来てることを言われてもなw だいたい発展し続けると言っても、再起動してるじゃん。 なぜ動的型付け言語ならではの理由が あんたの言っていることには一つのないんだよね。 >>677 マイナー言語のショボいVCS使ってないで さっさとgit覚えてください なんでも理由があるべきという思い込みはよくない 実力だけでなく運で決まることもたくさんある >>681 Smalltalkを使っている人間はgitを理解できないと決めつける時点で 発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、 古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる