動的言語で大規模開発

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

たててみた

**デフォルトの名無しさん** · 2014/12/09(火) 00:34:52.29

>>808
つまり Ruby が CLU のイテレータを再発見するまで、いいかえると
Python 設計者は PEP 205(>>764) 発表の2001年まで yield 文の重要性に気付かず、
世界中のPythonプログラマは冗長なジェネレータを書き続けていたことになるね

しかも PEP 205 で導入された yield文(statement) は検討が不十分であった為、
PEP 342 で yield 式(expression)へと後方互換性を放棄する構文の仕様変更に追い込まれている
・PEP 342 -- Coroutines via Enhanced Generators | Python.org
　https://www.python.org/dev/peps/pep-0342/

それに対して1999年の Ruby 1.4 (>>764)では yield はブロックの評価結果を返す式として定義されている
しかも外部イテレータは 1.8 で標準ライブラリとして、 1.9 では組み込みライブラリとして提供された
もちろん(後方互換性を喪失させた Python とは異なり)言語の構文仕様へ変更を加えることなく....

最初から内部イテレータとyield式を備え、楽々と外部イテレータにも対応した Ruby、そして
Ruby を必死で追いかけて予約語 yield の追加とyield文からyield式へと仕様が迷走した Python....
どちらが言語としての先見性に優れていたか、単純な話じゃん

**デフォルトの名無しさん** · 2014/12/09(火) 01:30:40.08

>>776-777で完全論破されてんのに
まだPythonのyield導入にRubyは無関係だって認めてないのかw

**デフォルトの名無しさん** · 2014/12/09(火) 02:00:48.32

>>811
× for x to stream do [user show: x; cr]
○ for% x from: stream do% [x print. user cr]

Smalltalk-72 と 76 がごっちゃになって記述を間違えましたので訂正します。
ちなみに % のところは実際はオープンコロンという白抜きのコロン（非ASCII文字）を使います。

**デフォルトの名無しさん** · 2014/12/09(火) 09:46:11.30

Ruby厨が過去を振り返るのに忙しいのは、
もう進歩が止まっちゃったから？
TwitterがScalaに乗り換えた件でケチが付き始めて、
今ではパクったはずのperlより遥かにシェア落としてるんだっけ？

**デフォルトの名無しさん** · 2014/12/09(火) 16:22:39.15

まさかルビ厨がPythonに言語仕様の後方互換性で喧嘩を売る現場を目撃するとは..w

**デフォルトの名無しさん** · 2014/12/09(火) 17:46:01.03

yieldが文から式に変わったことで動かなくなったコードってどんなの？
後方互換性を放棄したと言うんだから、あるはずだよね？

**デフォルトの名無しさん** · 2014/12/09(火) 21:39:51.00

>>811
>コルーチンである必要はないということですか？

ないです
当時のコルーチンは(アセンブリ言語レベルで)システムスタックを操作するか、
あるいは処理を「ぶつ切り」にした(保守しづらい)コルーチン風のプログラミングで実装するしかなかった
だからコルーチンの用途は限定され、ループ処理は while 文や for .. to 文といった伝統的な
構文で書くのが手続き型言語の一般常識になっていました
これを(ループ処理に限定されるとはいえ)イテレータという概念で
「コルーチンとは異なる視点」から抽象化したのが CLU の成果だと思っています
もし CLU とは別の視点でループ処理の抽象化に取り組んだ研究/考察であれば歓迎ですね
（ただし、関数型言語の LISP に由来し今では誰でも知っている高階関数は .... ですけど）

>例えば、まだクロージャをもたないSmalltalk-76の頃からあった
>
>stream ← #(1 2 3) asStream.
>for x to stream do [user show: x; cr]
>
>という内部イテレータとして使える外部イテレータである
>ストリームという発案

イテレータから各要素を for という構文で列挙するという発想は1977年の CLU (>>800)と似ていますね
（CLU におけるイテレータの列挙は for .. in 構文に限定された仕様でしたが、これは -76 の影響？？？）
この for は Smalltalk-76 の予約語に見えますが、(特殊な)メッセージだったのでしょうか？
また Smalltalk-80 だと do メッセージへ変更されていますけど、何か理由があったのでしょうか？
そして -76 の stream も next メッセージが実装された(外部イテレータとして)のオブジェクトだったのでしょうか？

色々と興味深いですね....

**デフォルトの名無しさん** · 2014/12/09(火) 23:30:56.22

外部イテレータとは while, for 等の伝統的構文が外から見えるという意味
例えばイベント駆動をやりたいときにプログラマが明示的にwhile文を書くようなもの
イテレータが様々なイベントをreturnすれば副作用もあるし戻り値の型も宣言できない

ほぼ全てのパラダイムを否定するので荒れやすいです

**デフォルトの名無しさん** · 2014/12/10(水) 07:35:20.61

結局Pythonのyieldの後方互換性問題って何だったの？
ルビ厨お得意のFUDですか？

**デフォルトの名無しさん** · 2014/12/10(水) 10:47:06.06

>>818
> これは -76 の影響？？？

1974年当時の Smalltalk-72 向けのブートストラップ用ソースを元にしたこのファイル
http://ftp.squeak.org/goodies/Smalltalk-72/ALLDEFS
の for の定義のコメントには「An Algol-like “for”.」とあります。-76 もこの流れで、CLU も
ALGOLライクな for を意識して拡張した構文を考えたら似たものになった、というだけだと思います。

ちなみに 1974年当時のこの -72 のソース内には先に -76 で示した
for x from stream …のようなイディオムはまだ登場していなかったようですが、
ただ stream 自体はすでにあり、外部イテレーターとして積極的に用いられていたようです。

> この for は Smalltalk-76 の予約語に見えますが、(特殊な)メッセージだったのでしょうか？

この for …は、-76 では省略されたレシーバー（コンパイラ）に対する for% x from: stream do% ...
というメッセージの送信として解釈されます（-72 のはまた別の機構。為念）。ただ内部的には for%from:do%
というメソッドがそのままコールされるわけではなく、いったん特殊形式として認識され、字句解析の後に
対応する forfromdo:args: というメソッドがコールされるしくみのようなので、通常の言語における
「予約語」の性格は強いかもしれません。

> また Smalltalk-80 だと do メッセージへ変更されていますけど、何か理由があったのでしょうか？

やはりブロック（当初はコンテキスト、後にクロージャー）の導入が契機だったと思います。
-76 ではコードブロックを [ ] で括りブロックのように見えますが、これは Ruby のブロック同様、
第一級オブジェクトではありませんでした。

> そして -76 の stream も next メッセージが実装された(外部イテレータとして)の
> オブジェクトだったのでしょうか？

そうです。繰り返しになりますが、外部イテレータとしての stream は -72 からあったので。
for%form:do% のようなイデオム（通常の言語では新しい構文のようなものでしょうか）が登場し、
内部イテレータとしても使うようになったのは、-72 の拡張版の -74 か、-76 からだと思います。

**デフォルトの名無しさん** · 2014/12/10(水) 21:59:38.00

>>821
レスありはとうございました
たいへん面白い知見と考察でした

> CLU も ALGOLライクな for を意識して拡張した構文を考えたら似たものになった

わかりました、そう考えるのが自然ですね

> 通常の言語における「予約語」の性格は強いかもしれません。

内部ではメッセージングで実行している一方で、ALGOL 風の使いやすい for 構文に見せる....
いわゆる構文糖だと思いますが、この言語設計は Ruby と似ていますね(>>809)

> やはりブロック（当初はコンテキスト、後にクロージャー）の導入が契機だったと思います。

ブロックの導入によって、メッセージングによる計算モデル単純化の究極が Smalltalk-80 になった訳ですね
これは(Smalltalk-80 に影響を受けながらも)あえて ALGOL 風の複雑な構文の導入に向かった Ruby とは異なる道筋です

> そうです。繰り返しになりますが、外部イテレータとしての stream は -72 からあったので。

了解です
そういえば、ストリームをI/O処理だけでなくモジュールを組立てる基本要素とした手続き型言語がありました
・ストリームを扱う言語Stellaによる在庫管理システムの記述
　http://ci.nii.ac.jp/naid/110002761803

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

>>822
Stella の SECONDL の例を Squeak/Pharo Smalltalk のストリームを使って書いてみました。
参考まで。

| SECONDL IN OUT |

SECONDL := [:INPUT :OUTPUT |
　| FIRSTL S1 S2 S3 |

　FIRSTL := [:INS :MAX :OTHERS |
　　| I LASTMAX |
　　(LASTMAX := INS next) ifNil: [self error: 'empty stream'].
　　[INS atEnd] whileFalse: [
　　　(I := INS next) > LASTMAX ifTrue: [I := LASTMAX flag: (LASTMAX := I)].
　　　OTHERS nextPut: I].
　　MAX nextPut: LASTMAX].

　S1 := INPUT.
　S2 := ReadWriteStream on: IntegerArray new.
　S3 := OUTPUT.

　FIRSTL value: S1 value: NullStream new value: S2.
　FIRSTL value: S2 reset value: S3 value: NullStream new
].

IN := #(54 16 1 58 93 57 84 72 32 25) asIntegerArray readStream.
OUT := ReadWriteStream on: IntegerArray new.
SECONDL value: IN value: OUT.
OUT reset next "=> 84 "

**デフォルトの名無しさん** · 2014/12/11(木) 13:25:53.28

>>823
まあ、Squeak/Pharo Smalltalkで普通に書けば、たったこれだけの処理ですけれどもね。^^;

| strm topTwo |
strm := #(54 16 1 58 93 57 84 72 32 25) readStream.
topTwo := (strm next: 2) asSortedCollection.
strm do: [:x | topTwo add: x; removeFirst].
topTwo first "=> 84 "

**名無しさん＠そうだ選挙に行こう** · 2014/12/14(日) 08:35:34.66

>>822
> Smalltalk-80 に影響を受けながら

matzが影響を受けたのはTimothy Budd独自仕様
お手製サブセットのLittle Smalltalkで、
ちゃんとしたSmalltalk（たとえば「Smalltalk-80」）ではないよ。
だからstreamみたいな基本クラスもrubyには入ってない。

**デフォルトの名無しさん** · 2016/05/01(日) 15:12:30.55

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ

The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
ｋ

**デフォルトの名無しさん** · 2018/05/23(水) 23:07:44.26

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

QZU97

**デフォルトの名無しさん** · 2018/07/04(水) 23:01:31.67

DHB

**デフォルトの名無しさん** · 2018/07/06(金) 12:36:26.96

QZU97

**デフォルトの名無しさん** · 2018/08/23(木) 06:16:30.33

>>2
動的言語で信頼できるコードが作られる前に
静的言語では全コードが完成している

**デフォルトの名無しさん** · 2019/06/19(水) 05:02:52.19

【出資】松本卓朗人工知能詐欺【注意】
https://rio2016.5ch.net/test/read.cgi/rikei/1560859403/