動的言語で大規模開発

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

たててみた

**デフォルトの名無しさん** · 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.

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

>>715
どこにって、implicitを使うために中で何度でも出てくるよ？

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

こういう研究の流れを受けてか、後発のRustのtraitは
最初からHaskellのType Classそっくりになっているんですってよ

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

>>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,

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

始めに実装したというのは凄いかもしれないけど、
その凄いっていうのは、始めに実装したことであって
その機能がすごいってことじゃないんだよな。
後発のほうがもっとその機能を強化している。

そして始めに実装した言語は互換性を保つために
機能強化できずにずっと続けないといけない。

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

>>719
それははじめに機能ありきで、それをただ実装した場合の話だろう。
試行錯誤して生まれるには、それをインキュベートする環境が必要でって話なんだが
計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を説明するのは難しい。

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

>>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:

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

宇宙服みたいな言語とモビルスーツみたいな言語があるけど
どうせ結局両方使うんだよな

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

>>721
何そのパズルみたいな抜粋。
どうこねくり回したところでScalaのtraitに限っては
その出自はミックスインみたいなもので、型クラスそのものではないよ。

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

>>723
ついに反論しきれなくなって、traitとtype classは無関係から
そのものでは無いまで意見が後退しちゃったねw
自分もtype classそのものなんて一度も言ってないので、もうそれで良いよ

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

>>722
両方を備えたc++ですね分かります

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

A君「絵を描くのは好きだけど、仕事と両立するのは難しいなぁ」
ニート「一日中ヒマだから絵を描き放題だぜ」

A君「ついに絵を描く仕事に就いたぞ。好きなことして食べていける」
ニート「もう20年前から好きなことだけやれてたわ～。遅れてんな～やれやれ」

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

>>724
わっかんないやつだなぁ。
traitが型クラス由来なら、なぜtraitを使わないで型クラスの例が書けるのさ。
http://www.scala-lang.org/old/node/114

説明してミソ

**デフォルトの名無しさん** · 2014/12/05(金) 00:15:41.66

>>727
Rubyではblockを使わずにlambdaが書けるから
blockはクロージャ由来じゃないってことだね

**デフォルトの名無しさん** · 2014/12/05(金) 00:20:26.42

C++のclassはstructでも書けるな

**デフォルトの名無しさん** · 2014/12/05(金) 02:25:30.08

>>728
おまえ頭わるいな

**デフォルトの名無しさん** · 2014/12/05(金) 07:42:45.52

>>730
いや、お前が頭悪い
（理由は省略、いう必要もないから）

**デフォルトの名無しさん** · 2014/12/05(金) 09:04:37.51

RubyのブロックってCLUのイテレーター由来じゃなかったっけ？
ずいぶん前にMatzがそんなようなことを言っていた記憶が

**デフォルトの名無しさん** · 2014/12/05(金) 09:13:02.76

クロージャとラムダ式の区別がついていない人ってよくいるよね

**デフォルトの名無しさん** · 2014/12/05(金) 09:16:51.57

>>733
それお前じゃね？

一応言っておくと、わかってると自称する
お前が説明してみろって意味だよ。

**デフォルトの名無しさん** · 2014/12/05(金) 10:11:29.20

Pythonにクロージャは無い（キリッ

**デフォルトの名無しさん** · 2014/12/05(金) 11:25:40.15

さあ728さん、クロージャとラムダの同一性の説明どーぞ！

**デフォルトの名無しさん** · 2014/12/05(金) 12:26:12.88

>>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使わずにこれでおｋ

**デフォルトの名無しさん** · 2014/12/05(金) 12:31:26.53

動的言語には型名を考えるコストがない
ある物の名前がラムダかクロージャか議論するのに何時間かかるか考えてみろ

**デフォルトの名無しさん** · 2014/12/05(金) 13:25:22.71

>>738
動的言語でも型名はあるんじゃ。もし言語がサポートしてなくても何かつけそう。

**デフォルトの名無しさん** · 2014/12/05(金) 13:38:18.27

>>738
唯一神クラスですか？

**デフォルトの名無しさん** · 2014/12/05(金) 16:19:55.77

インタフェース継承で派生クラスの名前は必須ではない
これは静的でも成り立つ
更に突き詰めると必要なのはメンバの名前のみなのでインタフェースの名前も不要

Smalltalkは実装継承にこだわっているので名前は必要かもしれんが他の動的言語は違う

**デフォルトの名無しさん** · 2014/12/05(金) 18:10:35.44

>>741
> 実装継承にこだわっているので名前は必要

なぜ実装継承にこだわると名前が必要になるのか教えてほしい。

**デフォルトの名無しさん** · 2014/12/05(金) 20:31:39.15

>>738
何言ってんだ？
型がなくてどうやってオブジェクトをnewするんだよ？ｗ
new 型名って書くだろが。

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

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

変数に型がないから、影響範囲がわからない、
もしくは限定的になり、人間の負担が大きくなる。

**デフォルトの名無しさん** · 2014/12/05(金) 20:46:05.48

>>741
> インタフェース継承で派生クラスの名前は必須ではない

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

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

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

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

それがわかっていれば、この関数の引数は、どんなものが入ってくる可能性があって
（むしろ入ってこないものが断定できて）広大なコードの海で、どこから使われているか
目視、もしくはIDEなどのツールを使って100%の信頼性で調べれる方がいいってわかるだろう？

**デフォルトの名無しさん** · 2014/12/05(金) 20:46:44.48

実装に名前をつけて保存するからだろ

インタフェースは保存しなくてよい
下手すると名前の長さが中身より長くなるから

**デフォルトの名無しさん** · 2014/12/05(金) 20:50:24.12

>>742
>>745

**デフォルトの名無しさん** · 2014/12/05(金) 21:12:23.79

>>745
> 下手すると名前の長さが中身より長くなるから

まあ、まず無いが、仮に名前の長さが中身より長くなるからといって
どんなデメリットが有るというのかね？

**デフォルトの名無しさん** · 2014/12/05(金) 21:28:30.39

>>680
>動的型付け言語じゃなくても達成出来てることを言われてもなｗ

>>671 で
> Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、
と書いたように、静的型付けの C++ だけでは COM を使わなければ
コンポーネントの動的結合ができない
それに対して Objective-C は一般的な動的リンクライブラリにメタデータを加えて
ファイルを構成するだけで動的結合できるフレームワークを実現できる
動的型付けな Objective-C では同じ事を実現するのに、COM は不要

>だいたい発展し続けると言っても、再起動してるじゃん。

カーネルやデバイスドライバを更新した場合には OS の再起動は必要だ
ただし、ここで議論の対象としているのはライブラリやフレームワークとして提供される
コンポーネントの部分だよ
OSX/iOS では単に規定のフォルダへフレームワークをコピーするだけ
Windows の COM のようにレジストリへ GUID を登録するといった面倒な仕掛けは不要

> なぜ動的型付け言語ならではの理由が
> あんたの言っていることには一つのないんだよね。

静的型付け言語だけではコンポーネントの動的結合ができない(COM が必須)
モジュールの静的リンクだけでいい小規模の開発であれば静的型付け言語でもかまわないが、
コンポーネントを組み合わせる大規模なシステム開発では動的型付けの柔軟性が利点になる
この言語の差が OS という大規模開発における Windows の失敗と OSX/iOS の成功に影響した(>>671)

**デフォルトの名無しさん** · 2014/12/05(金) 21:30:47.47

> と書いたように、静的型付けの C++ だけでは COM を使わなければ
> コンポーネントの動的結合ができない

別にDLLでもできるけど？

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

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

もうしょっぱなからだめじゃんｗ

**デフォルトの名無しさん** · 2014/12/05(金) 21:32:11.34

2分で論破はやり過ぎだと反省しているｗ

**デフォルトの名無しさん** · 2014/12/05(金) 21:35:46.33

Linuxは静的型付け言語のC言語で～
拡張子soの動的リンクライブラリが～

まともに?明するのも面倒くさいｗ

**デフォルトの名無しさん** · 2014/12/05(金) 22:06:36.60

Smalltalkの場合、名前のないクラスは名前のあるクラスと同じ数だけ存在する。だから>>741は正しくない。
ちなみにサブクラスを定義するためにはクラスインスタンスにメッセージを送信する。インスタンスを生成するのもクラスインスタンスにメッセージを送信することで行う。その意味でも、クラスに名前は必須ではない。

**デフォルトの名無しさん** · 2014/12/05(金) 22:08:26.02

>>749
DLL だけでは柔軟なコンポーネント結合が実現できなかったから、
Microsoft は COM(Component Object Model) という技術を開発した
言語に依存しないバイナリ互換性も COM の特徴であるけれど、
仮に C++ に閉じた開発であっても COM は必要になる

こんな話は COM を知っていれば常識

**デフォルトの名無しさん** · 2014/12/05(金) 22:40:22.11

>>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

**デフォルトの名無しさん** · 2014/12/05(金) 23:20:42.11

>>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 等には)存在しない特徴

**デフォルトの名無しさん** · 2014/12/05(金) 23:41:12.21

問題
yieldを用いると内部イテレータ風の書き方で外部イテレータを作ることができる
このイテレータの名称として適切なのは
「外部イテレータ」「内部イテレータ」のどちらか答えよ

**デフォルトの名無しさん** · 2014/12/06(土) 04:27:17.30

Pythonでも普通にyieldで
「内部イテレータ風の書き方で外部イテレータを実装する」
ことができる。
Smalltalkにも(ちょっと無理矢理っぽいが)yieldの実装がある。

**デフォルトの名無しさん** · 2014/12/06(土) 09:50:46.00

**デフォルトの名無しさん** · 2014/12/06(土) 10:16:45.25

visitメソッドのレシーバと引数のどっちがVisitorか迷うことがある

**デフォルトの名無しさん** · 2014/12/06(土) 11:43:34.93

どうしてRubyを推したい人は
他言語に元からある機能をなかったことに
したがるのだろうか？

**デフォルトの名無しさん** · 2014/12/06(土) 11:53:26.46

>>760
それはMatzやその取り巻きが悪いんだよ。
まるでRubyが初めてであるようにもとれる言い方で
信者をミスリードし続けてきた立派な成果だ。
旧Mac信者がジョブズの印象操作で育成された経緯に似ている。

**デフォルトの名無しさん** · 2014/12/06(土) 12:39:03.22

printf("%sには%sがあるから\n", "ruby", "yield");

誰でも言いそうなコピペを改変してるだけだよね
正しい情報ではなくコピペしやすい情報が拡散する

**755** · 2014/12/06(土) 16:06:50.42

>>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 のイテレータを忠実に実装しているようだ

**デフォルトの名無しさん** · 2014/12/06(土) 16:45:53.73

>>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を推したい人は
　> 後から追加された機能を元からあったことに
　> したがるのだろうか？
と訂正したほうがいいだろね

**デフォルトの名無しさん** · 2014/12/06(土) 16:55:53.06

る厨、渾身の反撃

**デフォルトの名無しさん** · 2014/12/06(土) 18:06:07.33

>>764

755がこんな書き方するから、「いや、他の言語にもあるだろ」と突っ込まれてるんじゃないか？

> 内部イテレータは CLU で生まれ Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴

**デフォルトの名無しさん** · 2014/12/06(土) 18:10:44.25

>>764のPEP255を見ると、CLUには言及されているけどRubyは出てこないんだな
これは確かにRuby使いには腹立たしいかもなぁ
まあRoR以前のRubyはマイナーだったから仕方ないんだけど

**デフォルトの名無しさん** · 2014/12/06(土) 18:17:10.96

>>766
なんだ、る厨のマッチポンプか。つまらん。

**デフォルトの名無しさん** · 2014/12/06(土) 18:21:50.32

> Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴

まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。
さすがる厨だ。Matz ゆずりのミスリードはお手の物というわけか。

**デフォルトの名無しさん** · 2014/12/06(土) 18:37:35.84

内部イテレータ風の記法が大規模開発でどう役立つか

そういう話なら興味深いが、このスレは直ぐ「ウチこそが元祖」の話になるな……

**デフォルトの名無しさん** · 2014/12/06(土) 18:41:59.78

>>767
Python にジェネレータが導入された時期(2001年)からすれば
Ruby の成功を見てyield文を追加したんだろうけど、
さすがに「Ruby の真似をしました」とは書けないから CLU にしたんだろね

>>769
> まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。

え、CLU 以降に登場したメジャーな言語で yield 文によるイテレータを備えた言語があったの？
自分は知らないから、教えて欲しいなぁー

少なくとも、時期的には Ruby が再発見するまで Python にはyield文は存在していなかったよね(>>764)
存在していたなら、>>764 でも書いたように、ソースの提示をヨロシクね！

>>768
いや、(今のところ)ソースを提示できていないから、
「Pythonを推したい人は後から追加された機能を、さも元からあった(>>760)」かのように
ウソをついていたみたいだね

どうしてPython使いはウソツキばかりなの？
嘘でもなんでも、議論に勝ちさえすればいいと思っているのかなあ....

**デフォルトの名無しさん** · 2014/12/06(土) 18:56:12.98

2001年にRubyが成功してたとか、何のジョークですか
RoRは2004年ですよ

**デフォルトの名無しさん** · 2014/12/06(土) 19:13:11.97

CLUとかPythonのyieldはジェネレータだけど、Rubyのは違くね？
Rubyにジェネレータ入ったのって1.9だろ？

**デフォルトの名無しさん** · 2014/12/06(土) 19:22:45.98

Rubyのyieldは見た目が似てるだけでCLUのとは別物
正当に継承してるのはPythonの方でした、というオチ？

**デフォルトの名無しさん** · 2014/12/06(土) 19:30:05.03

>>771
当時のSatherはRubyよりは有名だっただろうね海外では

**デフォルトの名無しさん** · 2014/12/06(土) 20:16:53.72

>>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使いはウソツキばかりなのかね

**デフォルトの名無しさん** · 2014/12/06(土) 20:40:35.48

>>776
> November 2001

PEP255の後じゃん

**デフォルトの名無しさん** · 2014/12/06(土) 21:59:22.89

>>755は内部イテレーターがCLU発祥でRubyがその初継承だと言いたいの？
それとも、yield＆コルーチン的な仕組みでイテレーターを生成できるのが
そうだと言いたいの？　どっち？

**デフォルトの名無しさん** · 2014/12/06(土) 22:26:02.16

きっと、あれだろう。
「yieldを使うなどしてRubyのようにCLUからイテレーターをコピーしたのはRubyが最初」
とかいうガッチガチの縛り付き起源論。

「～は既にあったんじゃ？」とか指摘するたびに
「～は○○がRubyのそれと違う」とか縛りがどんどん増えていくタイプの。

**デフォルトの名無しさん** · 2014/12/06(土) 23:01:36.75

>>770
木構造で格納した値を順番に取り出すとか？
うーんピンとこない

**デフォルトの名無しさん** · 2014/12/07(日) 00:03:15.33

結局、最新の技術を取り入れた静的型付け言語が
最も優れた言語になるのかな。

**755** · 2014/12/07(日) 00:07:58.15

>>755
どちらかといえば前者だな
ただし、たとえば Sather(>>755) や分散トランザクション言語の Argus があるから
初継承ではないね

まあいずれにしてもソースを出せないのだから、
「Python では元からyield文があった」と主張した >>760 はウソツキってことだ(>>764)
ナゼPython使いってのは、息を吐くようにウソをつき、
朝日新聞のようにいつまでたっても間違いを認めようとしないんだろね？
人は神様じゃないから誰でも間違えるもので、
それに気付いたなら(>>736 下段のように)とっとと間違いを認めればいいのになぁ....