動的言語で大規模開発
■ このスレッドは過去ログ倉庫に格納されています
>>671 > 大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク > Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、 > コンポーネント間の結合に用いるオブジェクトに対しては id型 という動的型付けを用いる > 結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている 動的型付け言語じゃなくても達成出来てることを言われてもなw だいたい発展し続けると言っても、再起動してるじゃん。 なぜ動的型付け言語ならではの理由が あんたの言っていることには一つのないんだよね。 >>677 マイナー言語のショボいVCS使ってないで さっさとgit覚えてください なんでも理由があるべきという思い込みはよくない 実力だけでなく運で決まることもたくさんある >>681 Smalltalkを使っている人間はgitを理解できないと決めつける時点で 発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、 古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。 >>673 > Smalltalkは見当違いの問題を解いている Smalltalkはもう過去の遺物だし、問題はすでに解き終わっている。 あとはSmalltalkがどう解いたかを調べて理解するだけでいいと思うよ。 そこから使えそうなアイデアだけを引っ張ってきてちょっと見栄えをよくすれば、 運が良ければイノベーションや新しいトレンドも生み出せる(した人もいる)。 古くはWIMPなGUIしかり、MVCやコレクションなどのフレームワークしかり、 XPやTDDなどアジャイルな開発手法しかり、近年であればトレイトやクラスボックスしかり。 向いている方向が見当違いだというのは同意するけど、それはたまたま今は ファイルシステムに密着したUNIXライクなOS+C言語マシンで成り立つ世界だからで そこから外れた物の見方はいっさい価値なしと切り捨ててしまうのは少しもったいない。 少し、だけどね。土方には目の前に解決しなきゃならない問題や、学ばなくちゃいけない ついて行かなきゃいけないトレンドや技術がいっぱいあるから、 食いつないでいくためにはまずそっちを優先すべきだし。 >>678 原論文を理解できなかったなら正直にそう書けばいいのにw >>673 メインフレームを笑っていたUnix厨が メインフレーム由来の仮想化技術をあたかも最新技術のように持て囃す、 あんたが好きな「価値」ってのはその程度のものだ 必死に追いかければ、その先に青い鳥がいるかもなあw Dockerはunixの世界においても枯れた既存技術の寄せ集めだし、 最新技術だから持て囃されてるんじゃないよ 標準化の動きが急速に進んでて、クラウドサービスにベンダーロックインされる危険が極小になる所が肝 あるクラウドサービスで動かしてた仮装イメージを、別のサービスに即座に引っ越せるようになる メインフレームみたいに極限までロックインさせる話とは根本的に違う やっぱり分かってないと言わざるを得ない ベンダーロックインを静的型にたとえると 短いソースをコンパイルするために多くのヘッダーをincludeすることを強制される ヘッダーと本体が分かれていない言語では全部必要 >>688 じゃあRubyもPythonもだめだな。 ブラウザで動くJavaScriptは大丈夫か? include相当の構文がないもんなw >>684 > には目の前に解決しなきゃならない問題や、学ばなくちゃいけない > ついて行かなきゃいけないトレンドや技術がいっぱいあるから、 プロなら当たり前のことなんじゃねーの? プロには目の前に解決しなきゃならない問題や、学ばなくちゃいけない ついて行かなきゃいけないトレンドや技術がいっぱいあるから、 うん、違和感ない >>689 モジュールの依存関係は大したことはない 型の依存関係は基底クラスやprivateメンバーの型まで伝播する そのおかげで、矛盾するもの。つまり 明らかに動かないコードを検出することが可能になっている。 動的型付け言語では、動かして該当コードに たどり着かないとわからないバグを 動かすことなく見つけることが可能になってる。 これこそ、大規模開発で必要なことの一つなんだ。 大規模炎上の主な原因はバグではなく設計ミスではないのか 静的型の方がアカデミック方面での発展も凄いので 確かに学ぶことは多いと思うよ >>693 大規模炎上の話なんかしていないw まず、スコープが小さいほど、変更が与える影響は少ない。 プライベートメソッドなら、クラスの外は関係ないし、 関数内の修正は、引数と戻り値さえ同じなら どう修正しても問題ない。 修正の影響範囲が大きいのはスコープが多い時なんだ。 例えばクラスメソッド引数が変更された時、 その他の"すべての"ファイルから参照しているコードを突き止めないといけない。 基底クラスが変更になった時、その全ての派生クラスへの影響を考えないといけない。 そこに静的型付け言語のメリットが生きてくる。 動的型付け言語だと、クラスを変更した時、そのクラスの利用者全てを確認するのは難しい。 なぜなら変数に依存関係が明示されていないから。 静的型付け言語だと、変数に型を明示するから、変更による影響を瞬時に知ることができる。 これこそ大規模開発で必要なことなんだよ。 うっかり基底クラスを変更したら 継承も知らないのかと疑われそうで嫌だな モジュール間の依存は小さくするというのは ソフトウェアの開発者の常識だが、 なぜ小さくするのかというとモジュール間の依存が大きいと 修正する時に発生する影響範囲が大きくなって修正が大変だからなんだ。 だからモジュール間の依存は小さくするべきだが、 モジュールを連携してシステムが動く以上0にはできない。 例えば、obj.foo() というコードがあったとき、そこには objはfooメソッドを持っていなければならないという依存情報が生まれる。 この依存情報を動的型付け言語では、実行時までチェックしない。 静的型付け言語ではobjの型を明示することで、 実行前にfooメソッドが有ることを確認できる。 影響範囲を確認することが大変なモジュール間の依存を 明確にすることで、不具合の発見を容易にし 修正のコストを減らすのが、静的型付け言語の特徴なんだ。 インタフェースみたいにメソッドの実装を強制したいです どうしますかおしえて したら良いんじゃない? できない言語を使ってるの? >>687 超マイナーなVCSや低性能のODBに 自分からロックインされに行く技術オンチのSmalltalkerには 遠い世界の話だな >>699 変数の初期化 (null以外) を強制したいとは言わないところが甘い 厳しいのか甘いのかはっきりしない機械は駄目だ そういうのは人間の方が向いている >>702 > 超マイナーなVCSや低性能のODBに > 自分からロックインされに行く ありがたい話じゃないか。 そこまでしてSmalltalkから将来出てくるであろう新しい何かを育ててくれるんだから。 トレイトしかりクラスボックスしかり。 >>702 Smalltalkでは何十年も昔から常識だったことが 新技術として他の言語や環境でも使えるようになったら 「こんな便利な技術は技術オンチのSmalltalkerには理解できないだろう」 とか言いながらありがたく使いなさいよ、技術乞食さんw >>704 traitはSmalltalk由来のじゃなくて Haskellの型クラス由来のヤツが残りそう やっぱり作ってる連中の知的レベルが段違いだしね? え? なに? 俺の言語が起源だとかいう話をしてんの? 起源なんかどうでもよくて、その技術を "今" 有効活用することのほうが大事だろ。 起源はベータ版。今その技術を取り入れた言語というのは ベータ版を評価して、より優れた方法で取り入れてるってことなんだよ。 つまり、同じ機能であっても、起源よりも 後から取り入れた言語のほうが優れている。 初号機のほうが優れているっていうのは漫画の中の話だけだよ。 現実には、二号機、三号機の方が優れている。 >>706 traitsとかホントは知らないんだろ? implicit parameterと区別が付かないとかないわー >>708 この論文は読んだ上で言ってるの? あ、Martin OderskyはScalaの作者ね http://ropas.snu.ac.kr/ ~bruno/papers/TypeClasses.pdf >>707 パクる元がなければ改良もクソもないんだから アイデアのゆりかご的存在は生かさず殺さずにしておく方がいい って話なんだが。どうして優劣の話になるかな >>707 初号機には二号機をスルーして三号機に移行する作戦があるから 二号機はどうでもよい >>709 Scalaだからinterfaceの代わりにtraitを使っただけで、 型クラスとは関係ないだろう。 >>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. このペーパー、プレゼントします 最初の方だけ読みました! >>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. >>715 どこにって、implicitを使うために中で何度でも出てくるよ? こういう研究の流れを受けてか、後発のRustのtraitは 最初からHaskellのType Classそっくりになっているんですってよ >>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, 始めに実装したというのは凄いかもしれないけど、 その凄いっていうのは、始めに実装したことであって その機能がすごいってことじゃないんだよな。 後発のほうがもっとその機能を強化している。 そして始めに実装した言語は互換性を保つために 機能強化できずにずっと続けないといけない。 >>719 それははじめに機能ありきで、それをただ実装した場合の話だろう。 試行錯誤して生まれるには、それをインキュベートする環境が必要でって話なんだが 計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を説明するのは難しい。 >>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: 宇宙服みたいな言語とモビルスーツみたいな言語があるけど どうせ結局両方使うんだよな >>721 何そのパズルみたいな抜粋。 どうこねくり回したところでScalaのtraitに限っては その出自はミックスインみたいなもので、型クラスそのものではないよ。 >>723 ついに反論しきれなくなって、traitとtype classは無関係から そのものでは無いまで意見が後退しちゃったねw 自分もtype classそのものなんて一度も言ってないので、もうそれで良いよ A君「絵を描くのは好きだけど、仕事と両立するのは難しいなぁ」 ニート「一日中ヒマだから絵を描き放題だぜ」 A君「ついに絵を描く仕事に就いたぞ。好きなことして食べていける」 ニート「もう20年前から好きなことだけやれてたわ〜。遅れてんな〜やれやれ」 >>724 わっかんないやつだなぁ。 traitが型クラス由来なら、なぜtraitを使わないで型クラスの例が書けるのさ。 http://www.scala-lang.org/old/node/114 説明してミソ >>727 Rubyではblockを使わずにlambdaが書けるから blockはクロージャ由来じゃないってことだね >>730 いや、お前が頭悪い (理由は省略、いう必要もないから) RubyのブロックってCLUのイテレーター由来じゃなかったっけ? ずいぶん前にMatzがそんなようなことを言っていた記憶が クロージャとラムダ式の区別がついていない人ってよくいるよね >>733 それお前じゃね? 一応言っておくと、わかってると自称する お前が説明してみろって意味だよ。 さあ728さん、クロージャとラムダの同一性の説明どーぞ! >>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使わずにこれでおk 動的言語には型名を考えるコストがない ある物の名前がラムダかクロージャか議論するのに何時間かかるか考えてみろ >>738 動的言語でも型名はあるんじゃ。もし言語がサポートしてなくても何かつけそう。 インタフェース継承で派生クラスの名前は必須ではない これは静的でも成り立つ 更に突き詰めると必要なのはメンバの名前のみなのでインタフェースの名前も不要 Smalltalkは実装継承にこだわっているので名前は必要かもしれんが他の動的言語は違う >>741 > 実装継承にこだわっているので名前は必要 なぜ実装継承にこだわると名前が必要になるのか教えてほしい。 >>738 何言ってんだ? 型がなくてどうやってオブジェクトをnewするんだよ?w new 型名 って書くだろが。 動的型付け言語にないのは型じゃなくて、 変数(関数の引数含む)に型が書いてないから いろんな型が入れられてしまうって話だろ。 ローカル変数ならともかく、関数の引数、 つまり外部モジュールとのインターフェース部分にまで 型を書かないから、複数のモジュールを連携して作るような 大規模(中規模? いやいやサンプル以上の規模)になればなるほど、 大きくなっていく影響範囲を把握するのが大変になるって話だよ。 変数に型がないから、影響範囲がわからない、 もしくは限定的になり、人間の負担が大きくなる。 >>741 > インタフェース継承で派生クラスの名前は必須ではない そりゃそうだよ。問題にしているのは人間が大変かどうかの話なんだから。 技術者はよく、技術的に可能かどうかで答えるだけで 制限時間内に終えられるかどうかを答えなくて困る。 ミスをしない人間がいて、タイプミスもせず、ードの全てを覚えていて、 仕様の変更もしない。もしくは理想的な変更しか起こらず、時間の制限もない。 そういうありえない世界でなら何の問題もないんだよ。 現実には何万行、何十万行というコードを知っている人が 会社をやめて、新しく入ってきた人が期限内に修正しなければならない。 いいかい? 問題は可能か不可能かじゃないんだ。 コードの全てを把握していない人が、どちらの方が短い時間で コードを把握できて、ミスをせずに修正できるかって話なんだ。 それがわかっていれば、この関数の引数は、どんなものが入ってくる可能性があって (むしろ入ってこないものが断定できて)広大なコードの海で、どこから使われているか 目視、もしくはIDEなどのツールを使って100%の信頼性で調べれる方がいいってわかるだろう? 実装に名前をつけて保存するからだろ インタフェースは保存しなくてよい 下手すると名前の長さが中身より長くなるから >>745 > 下手すると名前の長さが中身より長くなるから まあ、まず無いが、仮に名前の長さが中身より長くなるからといって どんなデメリットが有るというのかね? >>680 >動的型付け言語じゃなくても達成出来てることを言われてもなw >>671 で > Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、 と書いたように、静的型付けの C++ だけでは COM を使わなければ コンポーネントの動的結合ができない それに対して Objective-C は一般的な動的リンクライブラリにメタデータを加えて ファイルを構成するだけで動的結合できるフレームワークを実現できる 動的型付けな Objective-C では同じ事を実現するのに、COM は不要 >だいたい発展し続けると言っても、再起動してるじゃん。 カーネルやデバイスドライバを更新した場合には OS の再起動は必要だ ただし、ここで議論の対象としているのはライブラリやフレームワークとして提供される コンポーネントの部分だよ OSX/iOS では単に規定のフォルダへフレームワークをコピーするだけ Windows の COM のようにレジストリへ GUID を登録するといった面倒な仕掛けは不要 > なぜ動的型付け言語ならではの理由が > あんたの言っていることには一つのないんだよね。 静的型付け言語だけではコンポーネントの動的結合ができない(COM が必須) モジュールの静的リンクだけでいい小規模の開発であれば静的型付け言語でもかまわないが、 コンポーネントを組み合わせる大規模なシステム開発では動的型付けの柔軟性が利点になる この言語の差が OS という大規模開発における Windows の失敗と OSX/iOS の成功に影響した(>>671 ) > と書いたように、静的型付けの C++ だけでは COM を使わなければ > コンポーネントの動的結合ができない 別にDLLでもできるけど? そもそもCOMがあるのは特定の言語に依存しないための 仕様を作ることが目的であって 同じ言語であれば、DLLでできるんだよ。 もうしょっぱなからだめじゃんw Linuxは静的型付け言語のC言語で〜 拡張子soの動的リンクライブラリが〜 まともに?明するのも面倒くさいw Smalltalkの場合、名前のないクラスは名前のあるクラスと同じ数だけ存在する。だから>>741 は正しくない。 ちなみにサブクラスを定義するためにはクラスインスタンスにメッセージを送信する。インスタンスを生成するのもクラスインスタンスにメッセージを送信することで行う。その意味でも、クラスに名前は必須ではない。 >>749 DLL だけでは柔軟なコンポーネント結合が実現できなかったから、 Microsoft は COM(Component Object Model) という技術を開発した 言語に依存しないバイナリ互換性も COM の特徴であるけれど、 仮に C++ に閉じた開発であっても COM は必要になる こんな話は COM を知っていれば常識 >>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 >>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 等には)存在しない特徴 問題 yieldを用いると内部イテレータ風の書き方で外部イテレータを作ることができる このイテレータの名称として適切なのは 「外部イテレータ」「内部イテレータ」のどちらか答えよ Pythonでも普通にyieldで 「内部イテレータ風の書き方で外部イテレータを実装する」 ことができる。 Smalltalkにも(ちょっと無理矢理っぽいが)yieldの実装がある。 Smalltalkで>>755 のCLUとRubyを再現するとこんな感じか。 | fromTo | fromTo := [:first :last | Generator on: [:g | | n | n := first. [n <= last] whileTrue: [ g yield: n. n := n + 1 ] ]]. (fromTo value: 1 value: 3) do: [:x | Transcript showln: x] http://ideone.com/5UU1qM visitメソッドのレシーバと引数のどっちがVisitorか迷うことがある どうしてRubyを推したい人は 他言語に元からある機能をなかったことに したがるのだろうか? >>760 それはMatzやその取り巻きが悪いんだよ。 まるでRubyが初めてであるようにもとれる言い方で 信者をミスリードし続けてきた立派な成果だ。 旧Mac信者がジョブズの印象操作で育成された経緯に似ている。 printf("%sには%sがあるから\n", "ruby", "yield"); 誰でも言いそうなコピペを改変してるだけだよね 正しい情報ではなくコピペしやすい情報が拡散する >>755 では「1 から 3 の範囲を」と書いたけど、具体的なコードを忘れていた CLU では、>>755 で定義したイテレータ from_to を以下のように利用する for i:int in int$from_to(1, 3) do .... end Ruby では、>>755 で定義したイテレータ from_to を以下のように利用する from_to(1, 3) do |i| .... end >>757 > Pythonでも普通にyieldで 失礼、Python にも yield 文があった ざっと調べてみたけど、どちらかというと(Ruby よりも) Python のほうが CLU のイテレータを忠実に実装しているようだ >>760 ,761 Ruby では >>754 のリンク先文書で Matz が 「イテレータの定義の仕方は驚くほど Ruby に似ています。 真似したんだから当然です。 元々 Ruby のブロックは CLU のイテレータに似たものを実現するためにデザインされたからです」 と書いているように、(おそらく)最初からイテレータが存在していました 少なくとも Ruby 1.4 を元にして1999年に出版された書籍「オブジェクト指向スクリプト言語Ruby」では、 節「2.18.4 yield」で(>>755 のコードのような)イテレータ定義方法が詳しく解説されている それに対して Python にyield文が追加されたのは2001年、おそらく Pytthon 2.x の時代ではないのかな? ・PEP 255 - PEP 255 -- Simple Generators | Python.org https://www.python.org/dev/peps/pep-0255/ もし最初から、あるいは Python 1.x の時代から存在しているなら、ソースを提示してくれ ソースが提示できないのなら、>>760 は > どうしてPythonを推したい人は > 後から追加された機能を元からあったことに > したがるのだろうか? と訂正したほうがいいだろね >>764 755がこんな書き方するから、「いや、他の言語にもあるだろ」と突っ込まれてるんじゃないか? > 内部イテレータは CLU で生まれ Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴 >>764 のPEP255を見ると、CLUには言及されているけどRubyは出てこないんだな これは確かにRuby使いには腹立たしいかもなぁ まあRoR以前のRubyはマイナーだったから仕方ないんだけど >>766 なんだ、る厨のマッチポンプか。つまらん。 > Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴 まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。 さすが る厨だ。Matz ゆずりのミスリードはお手の物というわけか。 内部イテレータ風の記法が大規模開発でどう役立つか そういう話なら興味深いが、このスレは直ぐ「ウチこそが元祖」の話になるな…… >>767 Python にジェネレータが導入された時期(2001年)からすれば Ruby の成功を見てyield文を追加したんだろうけど、 さすがに「Ruby の真似をしました」とは書けないから CLU にしたんだろね >>769 > まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。 え、CLU 以降に登場したメジャーな言語で yield 文によるイテレータを備えた言語があったの? 自分は知らないから、教えて欲しいなぁー 少なくとも、時期的には Ruby が再発見するまで Python にはyield文は存在していなかったよね(>>764 ) 存在していたなら、>>764 でも書いたように、ソースの提示をヨロシクね! >>768 いや、(今のところ)ソースを提示できていないから、 「Pythonを推したい人は後から追加された機能を、さも元からあった(>>760 )」かのように ウソをついていたみたいだね どうしてPython使いはウソツキばかりなの? 嘘でもなんでも、議論に勝ちさえすればいいと思っているのかなあ.... 2001年にRubyが成功してたとか、何のジョークですか RoRは2004年ですよ CLUとかPythonのyieldはジェネレータだけど、Rubyのは違くね? Rubyにジェネレータ入ったのって1.9だろ? Rubyのyieldは見た目が似てるだけでCLUのとは別物 正当に継承してるのはPythonの方でした、というオチ? >>771 当時のSatherはRubyよりは有名だっただろうね海外では >>772 2001年に O'Reilly から "Ruby in a Nutshell" が出版され世界メジャーデビューを果たしている ・Ruby in a Nutshell - O'Reilly Media http://shop.oreilly.com/product/9780596002145.do Ruby on Rails フィーバーが起きたのは2004年だけど、 すでに2001年には日本だけのガラパゴス言語から脱して 十分に世界でも知られる存在になっていた 当然、世界レベルで "Python vs Ruby" の論争は起きただろうし、 Ruby にはあるけど Python には欠けていると指摘されたのが「洗練されたイテレータ」で、 あわてて追加したのが2001年の PEP 255 (>>764 )だったんじゃないかと思われ.... >>773 外部イテレータ、いわゆるジェネレータは Ruby 1.8 にも標準ライブラリで提供されていた 1.9 では、これが組込みライブラリとして再実装されただけ で、「Python では元からyield文があった(>>760 )」という主張のソースはまだかなぁーー??? やっぱりPython使いはウソツキばかりなのかね >>776 > November 2001 PEP255の後じゃん >>755 は内部イテレーターがCLU発祥でRubyがその初継承だと言いたいの? それとも、yield&コルーチン的な仕組みでイテレーターを生成できるのが そうだと言いたいの? どっち? きっと、あれだろう。 「yieldを使うなどしてRubyのようにCLUからイテレーターをコピーしたのはRubyが最初」 とかいうガッチガチの縛り付き起源論。 「〜は既にあったんじゃ?」とか指摘するたびに 「〜は○○がRubyのそれと違う」とか縛りがどんどん増えていくタイプの。 >>770 木構造で格納した値を順番に取り出すとか? うーんピンとこない ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる