動的言語で大規模開発

1uy2012/07/24(火) 09:10:42.04
たててみた

2uy2012/07/24(火) 09:14:05.25
問題は解決した
結局、実行時にしか実行結果が分からないとしても
「信頼できるコード」は徐々に増えていく
それは予想以上に上手くいき始めた
俺は二度と静的言語を使う事はないだろう

3デフォルトの名無しさん2012/07/24(火) 09:15:00.16
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所

4デフォルトの名無しさん2012/07/24(火) 10:57:46.72
そのコピペ飽きた

5デフォルトの名無しさん2012/07/24(火) 11:54:29.79
イジメ自殺が社会問題となっている。新聞でもテレビでも識者と称する恥知らずたちが、おためごかしの助言を垂れ流して小銭を稼いでいる。
イジメに苦しむ少年少女よ、あんなものが何の役にも立たないことは、君たち自身が一番良く知っている。
唯一最良のイジメ対処法は報復に決まっているではないか。

実はイジメ自殺は何年かごとに社会問題となり、そのたびに真実の声が良識という名の愚論によって圧殺されてきたのだ。
十一年前にもイジメ自殺が相次ぎ「少年ジャンプ」が悲痛な叫びを特集連載した。
それをまとめた『いじめレポート』(集英社)にこんな声がある。
「徹底的に体を鍛えた。復讐(ふくしゅう)のために…。やられる前にやれ!」(A男)。
A君は拳法、柔道で「歩く凶器」となり、イジメを粉砕した。
睡眠薬自殺未遂のC子さんは、死を思う気持ちよりも「憎しみの方が強くなった」「私もガンガン殴り返す」「女でもやるときはやるんだ!」。
別の女児もこう言う。「どうしても死ぬっていうんなら、いじめた奴に復讐してからにしなよ」

学校では報復・復讐は道徳的な悪だと教える。しかし、それは嘘だ。人間が本来的に持っている復讐権を近代国家が独占したに過ぎない。
大学で法制史を学べばすぐわかる。復讐は道徳的には正しいのだ。現に、ロシヤに抑圧され続けたチェチェン人は果敢に復讐をしているではないか。

被害者が自ら死を選ぶなんてバカなことがあるか。死ぬべきは加害者の方だ。いじめられている諸君、自殺するぐらいなら復讐せよ。
死刑にはならないぞ。少年法が君たちを守ってくれるから。

呉智英

6デフォルトの名無しさん2012/07/24(火) 18:55:17.05
動的言語で大規模開発は可能

以上

7デフォルトの名無しさん2012/07/24(火) 20:04:33.83
【スポーツ】「五輪期間中はブログをやめて」JOCが東原亜希さんに要請★2
http://ikura.2ch.net/test/read.cgi/curry/1246361020/

8デフォルトの名無しさん2012/07/24(火) 20:07:03.66
あるのなら例をあげろよ。

俺が見たのはPython & Djangoで書いた社内用メーリングリストサーバ。
Webアプリで利用者がML管理。全部で1万行くらいあった。
納入業者が作ったみたい。

9デフォルトの名無しさん2012/07/24(火) 22:26:26.07
いくらでもあるのに見つけられないってバカなのか

10デフォルトの名無しさん2012/07/24(火) 22:59:20.68
1万って大規模じゃないだおr

11デフォルトの名無しさん2012/07/24(火) 23:00:34.94
もっと絞らんと、obj-cなんかも入ってきて切りがないでしょうに

12デフォルトの名無しさん2012/07/24(火) 23:18:45.95
ばーか

13デフォルトの名無しさん2012/07/24(火) 23:20:31.92
大規模開発は何を意味してるのかな
コード量かな
人数かな
人数多いとダメじゃないかな

14デフォルトの名無しさん2012/07/24(火) 23:37:16.89
人数多いのはクソプロジェクトしかないから却下。

15デフォルトの名無しさん2012/07/24(火) 23:43:45.63
win8はいつのまにか不可解なメトロを組み込むことになってしまった
動的言語じゃなくても大規模開発は難しい

16デフォルトの名無しさん2012/07/25(水) 00:57:09.50
死ね

17デフォルトの名無しさん2012/07/25(水) 01:21:12.37
1万行って去年俺一人で趣味で書いた JavaScript の量じゃねえか。
もう二度とやらんと誓ったけど。
動的言語は砂上に楼閣建ててる感がヤバイわ。GWT なり Haxe なり使えよ。

18デフォルトの名無しさん2012/07/25(水) 01:25:38.55
Browser Quest を見たパンピーどもの反応
→HTML5 スゲー!!JavaScript スゲー!! マンセーマンセーマンセー!

ソースコードまできちんと読んだ俺の反応
→これを全世界のプログラマにやれというのか(怒怒怒怒怒怒怒怒怒怒怒
 今すぐ滅べよ JavaScript(激怒

19uy2012/07/25(水) 02:43:50.85
「信頼できるコード」は徐々に増えていく
一見そう思えたが、修正しようとした時に問題が起き始めた。

影響範囲がわからない。

テストコードがあるから、実行すればおかしくなったのはわかるのだが、
それを正しくするには、どこを修正すればいいかがわからない。

時間がかかってしまう。

そしてテストコードは動いたが、今度はこれで本当に問題ないか
不安になってきた。

テストは不具合があることは教えてくれるが、
不具合がないことは教えてくれない。

果たして俺は、完璧なテストを書いているのだろうか?

20uy2012/07/25(水) 02:55:10.25
コードはインターフェースと実装の2つにわかれるんだよ。

実装の修正ってのはテストが簡単。
インターフェースが変わらないから、
実装は関数の中身を変えればいいだけ。
テストコードを変える必要はない。


だけど、インターフェースの修正ってのは、
関数の外側、呼び出し側を修正する必要があるから
影響範囲が広くなる。そしてテストコードまでも変更する必要がある。

インターフェースの修正に弱いのが
動的型付け言語なわけ。

21uy2012/07/25(水) 03:36:50.02
>>19-20
死ね


>>17
冷静に考えてみ
その1万行をかくときに
「動的言語で書かれているヘッダ」をいくつ使った?

「信頼出来るコード」は勝手に増えていく

22デフォルトの名無しさん2012/07/25(水) 03:44:41.83
uy以外の人に聞きたいが
「動的言語で書かれているヘッダ」ってなんのこと?

23デフォルトの名無しさん2012/07/25(水) 03:45:34.43
1万行って少ないな。
1000行が10ファイルしか無い。

24デフォルトの名無しさん2012/07/25(水) 06:55:17.49
LISPマシンやPrologマシンはどのくらいの規模だった?

25デフォルトの名無しさん2012/07/25(水) 08:11:19.64
>>22
それすらわからないってバカ?
C言語で書かれたライブラリをインクルードするのか
動的言語で書かれたライブラリをインクルードするのか

26デフォルトの名無しさん2012/07/25(水) 08:13:27.92
で、基本的に「自分以外」がかいたそういうヘッダってのは
「信頼できるコード」に含まれる
世界中で何百万人が使用しているものだから

結局は自分でそのレベルの安定性を持った水準の動的言語コードをかいて
「アルゴリズムライブラリ」とすれば「信頼出来るコード」は増えていく

以上


27デフォルトの名無しさん2012/07/25(水) 08:41:50.10
>>25
動的言語で書かれているヘッダですよ?
どこにライブラリって書いてあるのですか?

ヘッダとライブラリの違いがわかりませんか?

28デフォルトの名無しさん2012/07/25(水) 11:41:35.75
#include<stdio.h>知らないただのバカか

29デフォルトの名無しさん2012/07/25(水) 12:01:51.61
世の中にはヘッダライブラリというのも存在する事も知らないただのバカか

バカは死ね

30デフォルトの名無しさん2012/07/25(水) 12:02:27.66
動的リンクをしてない言語はライブラリをどのようにして使うかすら知らないバカか

バカは死ね

31デフォルトの名無しさん2012/07/25(水) 12:03:42.01
初心者とバカは死ね

32デフォルトの名無しさん2012/07/25(水) 12:07:26.36
今時の言語でヘッダをインクルードする言語なんて皆無だろ。

33デフォルトの名無しさん2012/07/25(水) 12:18:05.17
rubyやってると本当に変数あんまり使わなくなってくる
イテレータ内のみにスコープのある局所変数の型については、
100%型情報がいらない場所、型情報があるとイテレータの利点が全く生かせない
俺でも稀に型情報が必要かな?って思うのはグローバル変数や、スコープの広い変数
でもrubyではその気になればスコープの広い変数を消して、ブロック変数のみで書いていける
重要なのは変数情報じゃなくて、
メソッド群の組み合わせによって、どうアルゴリズムを作るか
よくイテレータの戻り値を、とりあえずって感じで
a=[...].map {} といった具合に受け取ることはあるが、これさえも
[...].map {}
.map {

}
と続けてかいてしまえば変数がいらない
まぁ可読性のために、変数に格納するんだけど
変数を宣言して使うしかないっていう状況から、
書かなくてもよい変数を、可読性を上げる為にわざと宣言するという考えに変わっていった

34デフォルトの名無しさん2012/07/25(水) 18:00:32.03
>>25
たった一個でいいから、実在の「動的言語で書かれているヘッダ」を示してくれ。
示してくれ。

もし良ければ、and と or と xor の定義も示してくれ。

35デフォルトの名無しさん2012/07/25(水) 21:59:50.81
>>29
だから「動的言語で書かれたヘッダ(ライブラリ)」ってなんだって話だろ。

動的言語で書かないといかんのだぞ。
あと、当たり前だが、ライブラリ=ヘッダ(ライブラリ)ではない。

36デフォルトの名無しさん2012/07/25(水) 22:02:16.10
動的言語はインターフェースの変更に弱い。

インターフェースの変更は単体テストで
見つけることが困難になる場合がある。


37uy2012/07/25(水) 23:41:23.25
バカすぎワロタ
stdio.hでも食ってろ

38デフォルトの名無しさん2012/07/25(水) 23:46:37.20
stdio.h ・・・C言語(静的型付け言語)のヘッダファイルです。これはライブラリではありません。

39uy2012/07/26(木) 00:16:15.80
バカすぎワロタ
stdio.hでも食ってろ

40デフォルトの名無しさん2012/07/26(木) 00:16:45.42
uy以外の人に聞きたいが
「動的言語で書かれているヘッダ」ってなんのこと?

41デフォルトの名無しさん2012/07/26(木) 00:17:53.75
初心者スレいけよ低脳

42uy2012/07/26(木) 00:20:16.84
バカすぎワロタ
stdio.hでも食ってろ

43uy2012/07/26(木) 00:24:29.43
初心者黙った

そのままstdio.hと添い寝してろ
初心者死ね

44uy2012/07/26(木) 00:31:36.95

初心者死ね

45デフォルトの名無しさん2012/07/26(木) 00:34:22.77
uy以外誰も答えられないってのが
答えになってる。

そう、「動的言語で書かれているヘッダ」なんてものは
存在しない。

46デフォルトの名無しさん2012/07/26(木) 08:57:34.99
そもそもヘッダってものがごくごく一部の言語にしかないので。

47uy2012/07/26(木) 10:04:04.91
あ、言っとくけど誰もマジレスしなくていいからね
長文書かれると鬱陶しい

こいつはこのまま放置していこう

48uy2012/07/26(木) 10:10:59.41
動的言語でプログラムを組むときに普通はいくつもの「ヘッダ」を使い
その「ヘッダ」は、大抵は同じ言語、つまり「動的言語でヘッダ」が書かれている
自分で実際に書いたソースコードと、その「ヘッダ」のソースコードを含めて考えれば
ちょっとしたコードだろうとそれなりの規模のコードになっている事は分かる
大規模開発が出来ないというのは、「信頼出来るコード」、「資産」を自分で作っていけないレベルの奴が言っているだったという結論がでてしまった

49uy2012/07/26(木) 10:14:59.12
「動的言語で書かれたヘッダ」をひとつも使ったことがないというのは
動的言語でプログラムを書くときに標準や外部ライブラリも含めて何一つ使ったことがないという事・・・
自分でヘッダを描く事も出来ず、
インクルード(あ、言っちゃった)構文さえ知らない

そろそろ謝ったほうがいいんじゃないのか

50uy2012/07/26(木) 10:31:38.47
初心者は死すべし
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
 何 番 煎 じ だ ?

こんな釣りスレに釣られてレスしにきちゃう分際でどうなんだそれwwwwwwwwww

51デフォルトの名無しさん2012/07/26(木) 11:24:08.18
うん、だからもう 2ch なんて捨ててヨソに行ってよ。
ね。

もう十分に恥ずかしい思いをしたでしょ?

52デフォルトの名無しさん2012/07/26(木) 11:58:59.94
import java.util.List;

これをヘッダのインクルードだと理解しているわけか?すごいな

53uy2012/07/26(木) 12:44:30.56
やっぱりjaverか・・・

54uy2012/07/26(木) 13:09:01.25
俺は勘違いしてたかもな
静的言語よりも自由が高く出来る事の多い動的言語で大規模開発が出来ないはずないわ
慣れは必要
どんどん効率上がってきてるのが分かる

55デフォルトの名無しさん2012/07/26(木) 14:42:51.05


50 :uy:2012/07/26(木) 10:31:38.47
初心者は死すべし
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
 何 番 煎 じ だ ?

こんな釣りスレに釣られてレスしにきちゃう分際でどうなんだそれwwwwwwwwww

56デフォルトの名無しさん2012/07/26(木) 15:56:44.73


50 :uy:2012/07/26(木) 10:31:38.47
初心者は死すべし
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
 何 番 煎 じ だ ?

こんな釣りスレに釣られてレスしにきちゃう分際でどうなんだそれwwwwwwwwww

57uy2012/07/26(木) 19:29:02.43
>>53

> import java.util.List;
>
> これをヘッダのインクルードだと理解しているわけか?すごいな


Rubyではincludeで読み込むファイルのことを
ヘッダファイルっていうんだよ。

知らないなら、ググって恥をかけ!

58uy2012/07/26(木) 19:30:25.70
> 21 名前:uy[sage] 投稿日:2012/07/25(水) 03:36:50.02
>
> >>17
> 冷静に考えてみ
> その1万行をかくときに
> 「動的言語で書かれているヘッダ」をいくつ使った?

これを読んで疑問になった人は多いと思う。

あえてuy以外の人に聞くが、
「動的言語で書かれているヘッダ」ってなんのこと?

59デフォルトの名無しさん2012/07/26(木) 22:24:58.39

60uy2012/07/27(金) 01:31:01.18
rubyでincludeワロタ

ruby使えないどころかrubyのソース1個も読んでない知ったかじゃねーか

61uy2012/07/27(金) 01:41:01.10
結局ヘッダーっていうのは
ファイルの先頭に書かれている情報であって
「ヘッダ」と「ヘッダーファイル(.h)」は別物
requireやimportされているファイルは「ヘッダ」または「ヘッダライブラリ」と呼ぶ
C++/Boostのhppなども「ヘッダライブラリ」に分類される

またそれとは別に動的言語でDLLを使う場合には、C言語と同じようにプロトタイプ宣言の「ヘッダ」を書く事もある
またそれは別に、中規模以上であればファイルの先頭には定数情報やら、クラス、モジュールの空宣言などをやっておく事もあるんで
これらも「ヘッダ」と呼ぶ

分かったか?ゴミ

62uy2012/07/27(金) 01:43:01.28
>>22
さっさと泣いて謝れ

63デフォルトの名無しさん2012/07/27(金) 03:22:37.53
>>61
> requireやimportされているファイルは「ヘッダ」または「ヘッダライブラリ」と呼ぶ

はあ?

64デフォルトの名無しさん2012/07/27(金) 05:04:28.09
   ッ「ペロバコナーンwwwwwwwwwwwwwwww」

65デフォルトの名無しさん2012/07/27(金) 06:27:14.26

66uy2012/07/27(金) 08:14:28.84
なんか忘れてるみたいだから書いておくね。

「動的言語で書かれているヘッダ」とは
uyこと俺が言った言葉。

21 名前:uy[sage] 投稿日:2012/07/25(水) 03:36:50.02
>>19-20
死ね


>>17
冷静に考えてみ
その1万行をかくときに
「動的言語で書かれているヘッダ」をいくつ使った?

「信頼出来るコード」は勝手に増えていく

67uy2012/07/27(金) 19:36:37.93
>>65
include(笑)


この初心者に教える必要はない

結論、
動的言語で大規模開発は出来る

「信頼出来るコード」は勝手に増えていく

68uy2012/07/27(金) 19:38:30.34
rubyのincludeは今の話しと違うだろ・・・
るりまサーチをGoogleと勘違いしている頭の悪さ

コイツは救えない

stdio.hでも食ってろカス

69uy2012/07/28(土) 08:07:31.39
さっさと謝れ

70デフォルトの名無しさん2012/07/28(土) 11:02:45.57
>>68
いやw
include 対象が「ヘッダ」だと書いたページをw
一個でもいいから探して来いよw

>57 の
> Rubyではincludeで読み込むファイルのことを
> ヘッダファイルっていうんだよ。
の話さあw

71デフォルトの名無しさん2012/07/28(土) 12:53:20.49
>>61
30年プログラム書いてるけどはじめて聞いた。
勉強になるなあ。

72デフォルトの名無しさん2012/07/28(土) 15:23:50.83
ファイルの始めに書かかれている、ライセンスや開発者名なんかはヘッダーと言えるような気もする。

73uy2012/07/28(土) 19:16:03.90
>>71
煽りぬきで30年間何やってたんだ?

>>72
そもそも「ヘッダー」というのは
例えば テキスト.txtのバイナリの先頭部分だってヘッダーと呼ぶべきものだし
ソースファイルの先頭に書かれているものは全部ヘッダーだよ
import requireしてるならそれはヘッダーライブラリ

ruby使ってても、ある程度やっていくとruby言語をrubyで拡張したRbファイル
などを最初にrequireしておく事もあるんで
それは明らかにヘッダーと呼ぶべきものだろ

無知が騒いでいる

74uy2012/07/28(土) 19:20:53.36
C言語では「.h」のヘッダーでインクルードしてdefineなど定数宣言したり
クラス、構造体の宣言だけを行うこともある

rubyファイルでそれと同じことを行うこともある
動的、静的は関係なく
ヘッダーというのは存在する
動的言語で大規模開発は可能

分かったかゴミ?

さっさと初心者は死ね

75uy2012/07/28(土) 19:23:05.62
>>70
まだincludeについて間違った見解もってんのお前?

rubyのincludeは今回の話とは別だと何度も言っている
初心者以下のゴミクズ
そんなんだから>>65 こんな的外れのURLもってくるんだよ

ゴミは死ね

76デフォルトの名無しさん2012/07/28(土) 19:24:08.49
初心者死ね

77デフォルトの名無しさん2012/07/28(土) 19:37:11.07
>>73
pgr

78デフォルトの名無しさん2012/07/28(土) 19:38:43.08
>>73
$ cat null-act.c
int main(void) {
return 0;
}

どこがヘッダですか?

79uy2012/07/28(土) 19:50:30.14
ドヤ顔で500年以上前に流行っていまはもう使われてないC言語っていうんだっけそれ
そんなもののソース出されても正直困る

歴史に埋もれて市ね

80uy2012/07/28(土) 20:01:44.24
テキストファイルの上の部分がヘッダとか
見苦しい言い訳をしているが、

それだと

> その1万行をかくときに
> 「動的言語で書かれているヘッダ」をいくつ使った?

つじつまがあわない。
ヘッダを使うとはどういうことか。

81デフォルトの名無しさん2012/07/28(土) 21:11:15.85
ゴミは死ね

82デフォルトの名無しさん2012/07/29(日) 00:41:12.87
ゴミグラマ死ね

83デフォルトの名無しさん2012/07/29(日) 01:23:55.92
死ねゴミ

84デフォルトの名無しさん2012/07/29(日) 02:26:34.65
ゴミ

85デフォルトの名無しさん2012/07/29(日) 12:16:42.75
Matz はどういうだろうね?

86デフォルトの名無しさん2012/07/29(日) 12:57:02.43
cに対する煽りが半端でつまらんな
もっとくやしく

87デフォルトの名無しさん2012/07/29(日) 17:38:17.52
動的言語における大規模開発の適性については、すでに1980年代に結論が出ている
以下は、XEROXがSmalltalk-80で開発した大規模アプリケーションの具体例
(出典: Information/April 1986)

EELS - 紙面編集システム
・EELS(Electronic Editing and Layout System)は、ニューヨークタイムス社との
 契約によりXSIS(Xerox Special Information Syatems)が開発した
 新聞の編集とデザインのためのシステムであり、新聞の紙面向けの
 この種のシステムとしては世界初。このシステムは、紙面の編集や表示を
 1100SIPワークステーション上で行う事を可能にした。
・前工程で組まれた活字を自動的に読み込み、編集規則に合わせて再構成したり
 会話形式でテキストを修正できる。さらに記事がレイアウトにフィットしない
 場合には、レイアウト自体も動的に調整できる。また、活字を組むための
 テキスト用のページや、各種の字体も用意されている。

ANALYST - 分析シミュレーションシステム
・ANALYSTは米国政府で行われている広範囲な情報分析向けにXSISが開発した
 システムであり、すべてがSmalltak-80で実装され1983年秋から稼働している。
・ANALYSTはグラフ、地図情報、イメージ情報(航空写真など)、テキスト、
 数値演算(スプレッドシートなど)といった各種の情報処理機能を包含しており、
 ワークステーションの中に分析者が必要とするすべての情報処理機能を
 備えているといえる。また、電子メール機能、イメージ処理機能、電子ファイル
 管理機能、IBMのような大型機へのアクセス機能などの特徴も備えている。

88uy2012/07/29(日) 18:11:52.22
今は1980年ではない。

それ以降に静的型付け言語が成熟した。

今は動的型付け言語のメリットはない。

89デフォルトの名無しさん2012/07/29(日) 19:03:44.51
Smalltalkは当時からすでに下手な静的型言語より手厚いIDEのサポートがデフォだから
動的言語の適性を示す例としては反則だろう。

90uy2012/07/29(日) 19:04:48.12
Smalltalkって今どうなったんだ?

91デフォルトの名無しさん2012/07/29(日) 20:19:48.62
本家XEROX Smalltalk-80の直系の子孫はCincom社が開発販売しているVisualWorks。
http://smalltalk.cincom.jp/main/successes/

開発途上版(Smalltalk-80 v1)から枝分かれして独自進化したのがSqueak。
http://www.squeak.org/

さらにSqueakから枝分かれしたのがPharo。
http://www.pharo-project.org/

あとは企業の古くかあるクローンとか
http://www.exept.de/en/products/smalltalkx
http://www.object-arts.com/
http://www.instantiations.com/products/vasmalltalk/

他にはファンお手製実装とかの変わり種などいろいろ。
http://smalltalk.gnu.org/
http://amber-lang.net/

92デフォルトの名無しさん2012/07/29(日) 20:49:29.32
変わり種と言えば、処理系まるごとOODBシステムと化したGemStone/Sというのもある。
http://www.gemstone.com/products/gemstone

MaglevというSmalltalkベースの高速なRuby実装にはこの処理系が使われている。
http://maglev.github.com/

93デフォルトの名無しさん2012/07/29(日) 21:01:18.67
>>89
つーかSmalltalkは、動的に型チェックしたり、
型をファーストクラスオブジェクトとして使えるけど、
コンパイル時に強い型付けもしてるからな。
静的型付けもうまく組み合わせて使える。

94uy2012/07/29(日) 21:08:13.04
Smalltalkってウェブ関連では使われてないな。

95デフォルトの名無しさん2012/07/29(日) 21:22:37.41
OO機構が組み込まれているコンパイル志向の言語で、型の弱い言語ってあるかい?

96デフォルトの名無しさん2012/07/29(日) 21:30:00.55
>>94
あまりね。
でもTwitterに買われてサービスやめちゃったけどDabbleDBとか有名どころもちらほら。
http://www.crunchbase.com/company/dabbledb

Rubyを窮屈に感じてSmalltalkに鞍替えした人がWebObjectsにインスパイアされて作った
SeasideというコンポーネントベースのWAフレームワークが人気で
いろんな処理系に移植されて比較的よく使われている。
http://www.ogis-ri.co.jp/otc/hiroba/technical/seaside/seaside2/index.html
http://smalltalk.cincom.jp/tutorials/vw7.6/seaside/seaside_intro.ssp
http://www.seaside.st/

97デフォルトの名無しさん2012/07/29(日) 21:58:33.83
>>93
> コンパイル時に強い型付けもしてるからな。
> 静的型付けもうまく組み合わせて使える。

ん? ちょっとイメージできない。具体的にはどういうこと?

関係あるか分からないけど、SmalltalkにもObjective-Cみたいにオプショナルな
型チェック機構を持ったStrongtalkという処理系がある(あった)。これも変わり種だね。
http://www.strongtalk.org/

余談だけど型チェック機構とは別に、こいつのVM高速化技術はエポックメーキングで
会社ごとSunが買い取ってJavaに応用して作られたのがHotSpot VM。Sunの厚意で
オープンソース化後、JavaScriptで使われて作られたのがNode.jsを支えるV8のエンジン。

98uy2012/07/29(日) 23:19:47.17
>>85
まづは普通に、「作れるんじゃね?」みたいな事言いまくってるよ

つうか自分の言語なんだから「無理かなぁ・・・」なんていわないだろ
たとえ自分がrubyで大規模開発をやらないとしても


99uy2012/07/29(日) 23:31:19.65
実際のところいまのrubyは名前衝突を判定する手段がないから
フリーライブラリをrequireするなら、その中身を全部知っていないと危険
requireやりまくらないとしても、設計を完璧にして、ゴミカスPGはプロジェクト内から排除した上で
開発しなければならない

ただ、そこら辺の評価をマイナスにしてみてもrubyは現時点では最高の言語
大規模開発も出来る
ほかの言語がどれだけレベルが低いことか


使いこなすには難があるんだよ
たとえばC言語であればループかくって時に
基本的にイテレータなど使わないからfor文しか選択肢はないし、
処理分けをしたいって時なども、大抵はswitch case文でやるしかない

rubyの場合は、クロージャ、ラムダ、メソッド、module特異メソッド、class特異メソッド、case、when、イテレータ
さらに、独自定義のイテレータだの、eval使ってのメタだの
このくらいは選択肢がある

選択肢が多いことはいい事だ
ただしそれは使いこなせればの話
ドカタには無理

100uy2012/07/29(日) 23:33:18.42
ruby言語以外にもrubyと同じ機能はあったりするが、

結局それをいうならC++が最強
でも結局、言語の機能が整理されて使いやすくなってなければ
機能があってもないのと同じ
 つ か え な い ん だ よ
そこにあってもな

rubyの場合は、言語の機能をひとつ残らず 使 え る よ う に 設計されてる
そこのあたり、「とりあえず実装してみた。」みたいなノリの言語とは違うと思う
情報の整理がちゃんとされてるrubyが最強

101デフォルトの名無しさん2012/07/29(日) 23:37:48.53
Rubyはせいぜい10万行が限界。
50万行越えのコードは組めたとしてもメンテなんかぜったい無理。
だいたいコード以前に20万行のテキストすらまともに扱えないんだから。

102uy2012/07/29(日) 23:55:49.89
まともな設計するなら数万行単位で、なんらかの敷居を作れよバカ
なんで1個のプロジェクトに数十万行とか詰め込みたがるわけ、バカなの死ぬの

ちなみにまともにrubyでかいてればJAVAの5分1やら10分1程度のソースコード量になってもおかしくないわけで

rubyで10万行っていうとJAVAで50〜100万行の規模と考えていいよ

103uy2012/07/29(日) 23:59:56.90
そもそも10万行超えたらダメになるような設計しかかけない分際でレスされても困るよなぁ・・・
失敗談でも語っていくか?
君はどこで躓いちゃったの?
どこで間違えたの?
初心者は死ね

104デフォルトの名無しさん2012/07/30(月) 00:06:53.12
rails10万行程度ですでにカオス状態の食べログェ…
http://d.hatena.ne.jp/kanz-labs/20110811/1313079667

105デフォルトの名無しさん2012/07/30(月) 01:03:40.99
じゃあ俺は20万行かくよ

そもそも大規模になったからって管理できませーんなんて白旗あげちゃう奴は
何の言語触ったってダメじゃねえの????
他人が綺麗に設計した大規設計の上でドカタコードしか書かない奴には、ちょっと関係の話だったりする

106デフォルトの名無しさん2012/07/30(月) 01:04:37.66
>ちょっと関係の話だったりする
関係のない話

107デフォルトの名無しさん2012/07/30(月) 01:12:40.95
よく知ってるRailsアプリが10万行クラスで破綻と聞いて、ずいぶんトーンダウンしたな。

108uy2012/07/30(月) 01:53:22.77
動的言語で10万行ってさ
一体そんなに何かいてんの?
動的言語だぞ?
動的言語なのにJAVAと同じようにそっくりそのまま書いてるのかなって疑ってしまう

109uy2012/07/30(月) 02:03:23.80
コードの大半はテストだろう。

動的言語だと、テストの量が
静的言語の数倍に膨れ上がる。

Rubyでテストをまともに書いている所は、
テストの量が膨れ上がるから
修正があった際のテストの修正で苦しんでるはずだよ。

110uy ◆DU14dte9SY 2012/07/30(月) 03:09:22.88
I am a hikikomori ,
So ,i have not participated in organization of the system.
my written message is all on my dream.

111uy2012/07/30(月) 05:10:48.69
つうかrubyのメンバ変数の@ってマジでどうにもならないのかな
俺様はOOではないのでそんな問題からは既に解放されているが、
ruby布教の観点から見ると、初心者が使えなければ意味がなく
OOでソース書くなら@つき変数は避けられない
rubyを使う奴が、JAVAと同じように書いていくなら、
@がうっとうしいという理由だけで使われない気がする
先日メンバ変数と、メンバ変数同士の演算が多く必要になってしまう処理を
ほんの気まぐれでクラスで書いたら
ちゃんと最低限のコードで書いているにもかかわらず
マジでひどい見た目になった、これは無理

112uy2012/07/30(月) 06:15:27.56
いま今後言語を乗り換えることはないと覚悟してソースかいてる
ルビーはまだ粗はあるけどルビーの今後の成長に期待した
俺様の人生効率も左右されかねないのでルビーは頑張ってほしい
規模は現在一万行程度だけど年単位でやるので勝手に大規模なものになってるだろうよ
大規模開発はできる

113デフォルトの名無しさん2012/07/30(月) 09:29:16.89
プロジェクトよりテストのコードのほうがでかくなる
本体120mbテスト600mbみたいな

114デフォルトの名無しさん2012/07/30(月) 12:30:38.93
>>98
ruby の include の対象を、ヘッダと呼ぶことについて、Matz がどう言うだろうね、って話。

動的言語で大規模開発なんて、言語だけを問題にするなら、問題ないに決まってるだろ。
問題が出るのは、実際には優秀な人数を十分に確保できないからで、一山いくらの兵隊に作業させるなら静的の方がまだマシ、というに過ぎない。
XP のプラクティスの多くは Smalltalk の実践から生まれたわけだし、当然 ruby でも同様に有効だ。

115uy2012/07/30(月) 12:47:33.25
じゃあやってみろ

116デフォルトの名無しさん2012/07/30(月) 12:58:18.64
>>104
> Railsは大規模開発適しているということでした

いやいや、あの糞遅いサイトが適している例ってどうなんだよw

117デフォルトの名無しさん2012/07/30(月) 14:08:36.23
誰だかわかんねー個人ブログ引っ張ってくる奴もゴミ

そんなブログにマジレスする奴もゴミ

118デフォルトの名無しさん2012/07/30(月) 18:03:04.44

119デフォルトの名無しさん2012/07/30(月) 18:05:59.91
>>114
ソース出してくれればいいんだよ。
「プログラミング言語Ruby」でも「たのしいRuby」でも何でもいいが、
何ページに「ヘッダ」が使われてるってね。

120デフォルトの名無しさん2012/07/31(火) 00:41:17.19
ヘッダの意味がわかってないんじゃないか

121uy2012/07/31(火) 10:19:41.99
こうして一人ずつ発狂して
uy粘着と化す

もしかして俺ってrubyにすげー迷惑かけてんの?w
バトロワスレみてるとそうなのかなぁと思い始める
実際言語なんて宗教みたいなもんだしな
rubyのいいところは言語仕様を思い切ってmatzが変えていく所でもあると思う
C#とかじゃ、「あ、これ設計間違ってたね・・・」とか後から気づいても
絶対変える事はないからな、様々なしがらみによって出来ないんだそれ

あまりrubyの仕様は変わって欲しくないが、間違っている箇所はどんどん変えたら良いと思ってる
間違いを認めずに、間違った設計のまま突き進んで周辺ライブラリ、周辺ツール、PGにそのツケを払わせるとかなったら
他のゴミカス言語と同じ

流石の俺も自分の乗っている船を沈没させようとは思ってない
ただ特に貢献しようとも思ってない
俺様の進路に偶然、rubyが落ちてた。rubyは運が良い
俺様に選ばれたrubyは運が良かったと思う
きっと数年後にはそう感じているはずさ このままいけばね

122uy2012/07/31(火) 10:28:44.35
言語って所詮、言語を色づけしてるのは使用ユーザーかなって思うよ
その言語を気に入ったユーザーがライブラリを作ったり情報を描いて
この言語は○○をやりやすい言語 ってなってる気がする
静的言語だと結構どうやっても他言語にある概念を実装できないみたいな
壁にぶち当たることはあるんだろうけど
動的言語の場合evalさえ使えば大抵は、他言語の概念は
無理やりでよければもってこれると思う

とりあえずrubyをやる前は、C++とかにある ; これが鬱陶しいだけだったが
今では括弧すら鬱陶しく感じる
メソッド呼び出しから括弧を取り外すって簡単なようで実際めっちゃ難しいよね

a , b = c , d , e

とか、さ

何がメソッドで何が引数で、もしかしたらメソッドにデフォルト引数があるとか、
あるいは
c , d , e が全部変数でも、正しく動作するわけだし
プログラミングに煩わしい括弧取り外すのは簡単なことではなかった
rubyは成功言語

123デフォルトの名無しさん2012/07/31(火) 11:27:26.69
ヘッダを include できるし、xor で and や or を作れるし、素晴らしいね!

124uy2012/07/31(火) 12:01:56.24
何でこいつはいつまでもrequireとincludeの動作を覚えないの

125uy2012/07/31(火) 12:03:08.37
あー言っちゃった・・・

126uy2012/07/31(火) 21:49:07.39
ちんこ

127uy2012/08/01(水) 00:16:52.93
死ねゴミ

128デフォルトの名無しさん2012/08/01(水) 01:49:27.03

1000 :uy ◆xVOGOO9ev6 :2012/06/23(土) 12:35:29.68
俺は動的言語の問題点をいくつあげてもwwwww
静的言語よりはマシだと確信してるわwwwwwwwwwwwwwwwww


静的言語の問題点をなぜ挙げないかって??

見放してるから、問題点を指摘さえしないってことだよwwwwwwwwwww
気づけバカwwwwwwwwwwwwwww

129デフォルトの名無しさん2012/08/03(金) 06:32:47.82
二度と話しかけんなよ

130デフォルトの名無しさん2012/08/11(土) 10:20:21.60
日本の土建屋的SIerでやっていくには、一度固めたら(=コンパイルしたら)
動作がブレない静的言語の方が向いている、と、
勝手に顧客の本番環境でスクリプトとか勝手に書き換えるダメプログラマを見てたらオモタ。
動的言語でアジャイルに〜なんて言える現場はスキルと意識が高い恵まれた職場だと思うよ。

131uy2012/08/11(土) 11:11:11.81
> 日本の土建屋的SIerでやっていくには、一度固めたら(=コンパイルしたら)
> 動作がブレない静的言語の方が向いている、と、

誰もそんな事言ってないんだがw

お前のそのアホな思いつきに従えば
再コンパイルするんだから、動作がぶれてるだろ

132デフォルトの名無しさん2012/08/11(土) 12:03:04.92
本番環境にコンパイラ入れるな

133デフォルトの名無しさん2012/08/12(日) 00:59:20.15
使い分けるもんじゃないのか

134uy2012/08/12(日) 10:00:40.69
>>130
そんな「論外」のために言語変える意味はない
そいつを解雇しろよ

135デフォルトの名無しさん2012/08/12(日) 10:57:54.02
勝手に書き換えるのは顧客のPGでしょ。

136uY ◆gXFLM6waxs 2012/08/19(日) 03:14:31.35
あーーーもうメソッド名の変更って
この作業は割りと重要だな
aliasじゃダメなんだよ
気分的に無理

137uY2012/08/20(月) 19:41:34.56
昨日プロジェクト全体ソースがついに1万行を超えた
rubyで1万行という数字の意味が分かる奴は少ない
どこもハードコーディングしてないし、同じシンボルが必要な場所ではメタしたりmoduleで分けてmix-inも行ってる

およそ2ヶ月ちょいでこんくらいいくみたいだな

大規模開発できないって言った奴でてこいよ

138デフォルトの名無しさん2012/08/20(月) 20:10:06.70
そこまで言うのなら
ソースを見せてほしい

139デフォルトの名無しさん2012/08/20(月) 20:22:35.15
何人でその期間?

140デフォルトの名無しさん2012/08/20(月) 21:17:46.18
Rubyの習得は一瞬だよ
1万行書くのに1時間かからないだろう
問題はまともなデザインのソフトを作れるかどうか
デザインセンスの方が重要

141uY ◆gXFLM6waxs 2012/08/20(月) 22:31:47.89
ごめん
やっぱ無理だ

Ruby無理

これ無理

1歩間違えたら終わってた事実に今日気づいた

ちょー危ない

rubyすごい
今再現しないバグをどうやって再現させてバグレポート送るか試行錯誤中

142uY ◆gXFLM6waxs 2012/08/20(月) 23:02:29.91
えっえっ嘘
プロジェクト本体でもバグ再現しなくなってた
もういいや
もうやだ
勝手に誰かが直してくれた

143uY ◆gXFLM6waxs 2012/08/20(月) 23:07:41.34
なんか・・・・文字化けしたメッセージがDUMPされた

144uY ◆gXFLM6waxs 2012/08/20(月) 23:45:21.01
バグコードを追うためにコード減らしていく→まだバグでる→でる→でる
→あ、でなくなった戻そう→え?バグでないし、もっと戻そう→え?バグでねーじゃんあせdrftgyふじ →最初から

俺の技術じゃトレース無理かもしれない

145uY ◆gXFLM6waxs 2012/08/21(火) 00:15:30.32
はぁ、、つかれた、、
ライブラリと完全分離した結果
ライブラリではなくrubyのバグであることが確定した
ちかれた

146デフォルトの名無しさん2012/08/21(火) 01:10:35.50
マイナー言語にはよくあること。
メジャー言語にもあるけどね。

147uY2012/08/21(火) 01:36:14.78
もうやだ

148uy2012/08/21(火) 04:41:45.26
動的言語で大規模開発やってるやつほんとにすごいよ
よくこれで出来るなアンリミテッドルールブックなんだよ
ルールがない
だから自分で定義し
使っていいものダメなものきめてかいていく
しかし道具のいくつかを使わないってことは
効率をさげるんだよ
けど全部はぜったい使えない
自分の妥協との戦い
細かいことをきにしないスキルも必要

149デフォルトの名無しさん2012/08/21(火) 09:21:42.24
a, b = [1,2,3].cycle, ["a","b"].cycle
p (1..25).map{ |i| (i%5)!=0 ? a.next : b.next }

たったこれだけで済む事を下みたいに書いてるuyなら
1万行なんてすぐだろうな。

n = i = 0
s = []
b = ["a","b"]
[1,2,3].cycle do | m |
  n += 1
  i += 1
  break if n == 21
  s << m
  if i == 4
    i = 0
    s << b.first
    b.rotate!
  end
end
p s

150uY ◆gXFLM6waxs 2012/08/21(火) 10:25:03.64
あおりにすらならないは

つうか2ヶ月で1万行だと1年で6万行だよ
しかも2ヶ月のうち、プログラミングしてた日数ってそんなに無いし
これ続けてたら素でrailsとかの規模超えると思う
変なコードは書いてないんだけどな
rubyは開発力が違いすぎるのかもしれない

151デフォルトの名無しさん2012/08/21(火) 10:30:02.52
uyがかrubyがかはしらんけど
「糞コード量産力がはんぱない」のまちがいだろ

152uy ◆gXFLM6waxs 2012/08/21(火) 11:17:54.84
どんだけ煽ってももう無理なんだよ・・・
もう完成しちゃってるんだ
設計そのものが
しかもおそらくrubyレベルの柔軟な言語じゃないと
到底作る事の出来ないシステムが・・・

絶対にお前らじゃ追いつけないと分かる

153uY2012/08/21(火) 11:23:29.19
バカには無理

154デフォルトの名無しさん2012/08/21(火) 11:38:31.45
昨日1万越えて、もう10800行ってる
増加はとまらない

155デフォルトの名無しさん2012/08/21(火) 13:37:21.15
行数多いのを大規模開発と思ってるのか。乙。

156uY2012/08/21(火) 18:54:34.84
最初から大規模って言ってるのに記憶力ねーな

根幹部分がおよそ2000行のコード
この時点から既に大規模開発である

157uY2012/08/21(火) 18:57:00.66
元々いくらでもソース詰んでいける設計だったけど
実際にこれだけの規模になると違ってくる
動的言語は色んな面できつい
ソースコード管理をしっかりやらないと死ぬ

158デフォルトの名無しさん2012/08/21(火) 19:08:04.43
関わる人が増えてくると、名前の重複、平行開発の待ちなど様々な問題が出てくる。

159uY2012/08/21(火) 20:16:47.85
ソースの中でちょっと気になった場所を安易に変更するっていうのは
やっちゃいけないのが動的言語だと思う
変数名やメソッド名を変えたら全体テストやり直しとか言ってる奴もいるけどそれと同じだ
アルゴリズムの一部を変えて、
いらないと思ってた変数を消してみたら、後ろのほうで使ってたとかがある
動的言語は開発スタイルそのものを変えないと意味が無い
静的言語と同じように使っていても効率が下がるだけ
まともに動的言語で大規模開発できる奴は紛れもなくスキル高いと確信した
普通は出来ない

160uY2012/08/21(火) 20:31:48.89
"ちょっと高い"レベルじゃないからな
優秀な技術者というのもバズワード的な優秀という意味ではなく
マジで優秀って意味の優秀
100人中1位とかいうレベル以上の優秀
バカには無理

161デフォルトの名無しさん2012/08/21(火) 22:51:24.55
> 消してみたら、使ってた

普通は消す前に確認するけどな。
コンパイラ任せで消してみるというのもチェックの方法のひとつではあるけど。

162デフォルトの名無しさん2012/08/21(火) 23:02:58.40
そもそも変数が管理しきれないほどの広いスコープでコードを書かない方が良い。

163デフォルトの名無しさん2012/08/22(水) 00:18:17.90
と言ってもほとんどのスクリプト言語のスコープは関数単位で、1度しか使わない処理も全部関数化するっていうのもねー

164デフォルトの名無しさん2012/08/22(水) 00:24:03.04
スコープは関数単位だけどスクリプト言語なら普通は使う直前に宣言できるだろ。
そしてオブジェクトは不要になったらいつでも破棄できるだろ。

165デフォルトの名無しさん2012/08/22(水) 00:45:05.58
>>163
普通は構造やオブジェクトのメソッドという意味単位で分けるものなのよ。むしろ自然と分かれる。

166デフォルトの名無しさん2012/08/22(水) 07:46:30.85
意味単位でメソッド作ってたら、再利用されないメソッドだらけになるじゃん。

167デフォルトの名無しさん2012/08/22(水) 08:17:25.53
ワロス

意味単位で分割した上で、再利用を考えてラップするんだろ?

168デフォルトの名無しさん2012/08/22(水) 10:33:50.23
こういう奴がmain1000行とかやっちゃうんだろうな。
スクリプト言語もできる奴と、スクリプト言語しかできない奴の差な気がする

169uy2012/08/22(水) 11:23:23.35
この超ハイレベルのスレに論外初心者が迷い込んだ奇跡

170uy2012/08/22(水) 11:27:10.62
とりあえずOOは静的言語でプログラムを組んでいく事を前提に作られた設計手法だから
OO以外の動的言語流の設計を編み出すか、
あるいはOOをどうにかして動的言語で運用していくか
どちらも要求されるレベルは高い

171デフォルトの名無しさん2012/08/22(水) 12:59:19.31
Rubyやgroovyは動的でOOだと思うんだが、
天才様の脳内では違うのか。

172デフォルトの名無しさん2012/08/22(水) 13:52:03.31
>>166
仕様では意味単位でクラスやメソッドが出てくるので、どれを再利用すればいいかがよくわかる。

173デフォルトの名無しさん2012/08/22(水) 14:02:19.51
>>168
1000行のmain()の修正依頼が来たらどうすんの?>>159ってそういうことだろ。

174uY2012/08/22(水) 14:15:51.29
>>171
動的言語でOOは無理
っていうか静的言語と比べて欠点のほうが多いと思う

動的言語の利点は、動的に型を変えられる事
にもかかわらず同じ数だけクラスを宣言し
同じ数だけメソッドを定義していたら意味がない
そんなことをやればrubyはメンバ変数に@がついてる分、他の言語よりも冗長だよ

ライブラリはクラスを使ってOOで書いてもいいけど
動的言語はプログラムの大半をラムダ(yield)で書くべき

175uY2012/08/22(水) 14:50:11.56
つうかrubyで俺メンバ変数ほとんど使わないプログラミングを始めてる
ライブラリになれる機能はクラス宣言
ライブラリにはなれない && たいして大きくないものは
新規にクラスを宣言せず、オブジェクトを生成してからmoduleのextendなどで変数、メソッドを追加
これでほとんどいける

176デフォルトの名無しさん2012/08/30(木) 02:16:17.91
ruby2.0がかなりすごいらしい

177デフォルトの名無しさん2012/09/09(日) 10:05:38.04
らしいって誰かの受け売り?

178デフォルトの名無しさん2012/09/09(日) 10:10:28.19
ステマ

179デフォルトの名無しさん2012/09/09(日) 12:43:43.33
ruby2.0がかなりすごいらしい

180デフォルトの名無しさん2012/09/09(日) 12:46:30.48
バズワード

181デフォルトの名無しさん2012/09/09(日) 13:04:25.31
ruby2.0はかなりすごいらしい

182uy2012/09/09(日) 13:15:02.03
互換性の無さが凄い

183デフォルトの名無しさん2012/09/09(日) 14:05:50.21
ruby2.0でついにアレがくるらしいとのこと

184デフォルトの名無しさん2012/09/09(日) 22:38:42.39
rubyの価格破壊がくるらしい

185デフォルトの名無しさん2012/09/09(日) 22:42:12.13
価値破壊は既に進行してますが (w

186デフォルトの名無しさん2012/09/10(月) 00:06:57.72
まあ頑張ってほしいけどさ便利は便利だしもう精神的にperlとかやになっちまってるし

187デフォルトの名無しさん2012/09/10(月) 00:50:17.78
perlってほんのここ数年で一気にネットの評判ガタ落ちになった気がする
rubyがここ数年でそれだけ広まったってことだと思う
もっと早くに気づくべきだったよ
rubyよりもperlが積極的に使われてたのは2008年くらいまでだろうか
気づくのが遅い遅い遅い遅い

188デフォルトの名無しさん2012/09/10(月) 06:32:50.99
>>187
phpの影響でperl減ったんじゃないか。

189デフォルトの名無しさん2012/09/10(月) 13:42:40.57
>>188
まったくもってそのとおりだったwww

190デフォルトの名無しさん2012/09/10(月) 22:32:40.37
php5割
ruby2割
perl居残り組3割

こんくらいかと思ったけど
これはサーバーサイドのみの状況だった

LLとして見るなら
ruby4割
python4割
php1割
perl居残り1割

rubyの出現でperl終わってしまった

191デフォルトの名無しさん2012/09/10(月) 23:06:18.99
なにこのrubyひいきめ。1割も無いだろ。

192デフォルトの名無しさん2012/09/11(火) 11:11:33.93
perlの1割のユーザーでperlリソースを越えたかwwwwwwwwwwwwwww

193デフォルトの名無しさん2012/09/11(火) 19:29:13.02
ルビリストつええ

194デフォルトの名無しさん2012/09/13(木) 20:49:27.18
Perlは書いたコード誰も読めないからな。滅ぶべき言語
かといってRubyもどうかね

195デフォルトの名無しさん2012/09/13(木) 23:21:46.35
rubyは可読性を優先して
リスト内包表記を実装しなかったりしてる言語
でも最悪なコードは他にいくらでもかける
使い手次第

196vy2012/09/14(金) 01:08:33.04
ダメなコード書くプログラマは良い言語使っても、
厳しいコーディング規約を課しても、
便利なIDEにフレームワークを使わせても、ダメなコードを書く。
熟達したプログラマは例えCOBOLでもHSPでも、
読み易くて変更に強い良いコードを書く。
それが世の道理だよ。

197デフォルトの名無しさん2012/09/14(金) 15:07:56.72
キリッ

198デフォルトの名無しさん2012/09/14(金) 21:41:56.59
>>195
Rubyはパーサがスパゲティ過ぎて
パーサ拡張して内包表記を入れる事が難しいだけ
入れられたら入れてるよ

199uy2012/09/14(金) 22:48:35.89
聞き捨ての知識で知ったかぶるゴミカスってへらないよな
内包表記なんてその名の通り開始括弧と閉じ括弧がついてるんだから
この程度も実装できない頭とかおめでたすぎるわwwwwwwwwwww

さっさと死ねゴミクズ

200デフォルトの名無しさん2012/09/14(金) 23:42:23.98
1.9でラムダ式の構文入れたときも
x->{} じゃなくて ->x{} なんてキモい構文で
しかも空白有る無しでバグってたRubyだからな...

201デフォルトの名無しさん2012/09/15(土) 00:37:50.39
前からmatz自身がパーサ定義一杯一杯言うとったしなあ
なんか代替見つかったんだろか

202デフォルトの名無しさん2012/09/15(土) 00:39:18.96
代案ですか?

Ruby 3.0です!

203デフォルトの名無しさん2012/09/15(土) 02:24:11.94
>>199
そういう台詞はパッチ書いてから言えよ

あ、uyはyacc知らないから無理かwww

204uy2012/09/15(土) 03:58:59.74
ップwwwwwwwwwwwww

後置きイテレータとかの実装ならまだしも
リスト内包表記程度のパーサもかけねーのかよwwwwwww
yacc関係ないwwwwww

205デフォルトの名無しさん2012/09/15(土) 04:02:23.07
CRubyはbison使ってるから関係あるよ

206デフォルトの名無しさん2012/09/15(土) 04:13:34.11
LLとかにこだわらず、パーサーくらい自分でフルで書いてみろよw
好きな言語作れるぜ

207uy2012/09/15(土) 17:05:33.28
205
またアスペがつれた
てめー話かけんなっていっただろ

208uy2012/09/15(土) 17:08:27.11
しかしアレだけ書籍でてんのにまだこんなゴミカスいたんだな
流石に成長しない板だわ

209uy2012/09/15(土) 17:35:49.76
なぜリスト内包表記が難しいと思ったのか

ドカタだとこのレベルで苦戦なのかよ

210uy2012/09/15(土) 17:41:03.52
yacc(笑)みたいなゴミしか知らない奴も大変だよね
何年間そこで知識とまってんだよwwwwwwwwwwwwwww

211デフォルトの名無しさん2012/09/15(土) 17:41:07.91
(*´・∀・)(・∀・`*)ヘー

212uy2012/09/15(土) 18:04:56.91
くやしくて声もでませんwwwwwwwwwwwwwwwwwwwwwwwwwwww

213デフォルトの名無しさん2012/09/15(土) 22:12:16.43
>>210
Rubyはゴミで作られてるんですね
まあuy君はゴミだからゴミ同士お似合いですね

214vy2012/09/15(土) 23:34:31.67
言語に拘るようじゃまだまだ二流だな。
一流は言語もツールも選ばない。
要件を満たす適切なコードを書き、必要に応じてフレームワークまで即興で作る。
既存の言語やフレームワークの優劣に拘るのは自分に自信が無いからだよ。
速い車に乗って粋がってる青二才と同じ。

215デフォルトの名無しさん2012/09/15(土) 23:37:28.67
急に自分語り始めちゃったよ
なんだこいつ

216デフォルトの名無しさん2012/09/15(土) 23:43:25.07
>>214
rubyにこだわってるやつとは別にしたのかよ。
独自フレームワークは人の入れ替わり時の教育コストがかかる。あなたのような二流、三流を使うことも考えるのが大規模開発の一流。

217uy2012/09/16(日) 00:25:00.51
また社畜開発の話だよwwwwwwwwwwwwww
なんでドカタ開発前提でしゃべる奴がいるんだろう

たったひとりでもプログラムは開発できるし
出来る奴が数人集まれば大抵のものは 作れるはずですよね・・・・・

大人数にする意味ってwwwwwwwwwwwwwww
ワイワイやってデスマだ炎上だって修羅場ごっこしたいんですか?wwwww

218デフォルトの名無しさん2012/09/16(日) 00:26:35.12
>>217
はず・・・とか根拠がないなら
口を開くな。

219デフォルトの名無しさん2012/09/16(日) 03:49:53.24
>>217
とりあえずスレタイを読むことが出来る奴でないと話にすらならないな

220デフォルトの名無しさん2012/09/16(日) 17:21:34.85
素人目には大規模開発には関数型言語とりいれた方が良さそうに見えるんだけど
ここに動的言語を採用するなんてのは、ちょっと正気の沙汰とは思えない
ググってみたら、日本IBMがsmalltalkで病院システム開発に失敗した事例でてきた
大手での採用事例さえ増えれば、javaからscalaへ移行するんじゃね?

221デフォルトの名無しさん2012/09/16(日) 17:29:22.90
>>220
素人さんへ。

関数型言語は大規模開発に適していません。

プロがそう言っています。

222デフォルトの名無しさん2012/09/16(日) 18:18:36.16
> プロがそう言っています。

ドカタのプロフェッショナルwwww

223デフォルトの名無しさん2012/09/16(日) 18:59:37.85
>>220
動的言語がダメっていうよりSmalltalkがダメ
あれは玩具

224デフォルトの名無しさん2012/09/16(日) 19:04:29.56
>>222
ドカタってプロのことだったんですねw

225デフォルトの名無しさん2012/09/16(日) 19:13:49.68
ナレーター「プロドカタの朝は早い」

226デフォルトの名無しさん2012/09/16(日) 20:55:06.22
議論に負けそうになったら、
いつもドカタの話にすり替える。

227デフォルトの名無しさん2012/09/16(日) 20:59:54.80
つまり「プロがそう言っています(キリッ」で議論に勝ちそうだったのに
ドカタの話にすり替えるなと、そう言いたいのですね

228デフォルトの名無しさん2012/09/16(日) 21:03:19.89
関数型言語は業務で使える!

と、信者が宣伝している段階。

業務で使っている! ではない所に注意なw

229デフォルトの名無しさん2012/09/16(日) 21:11:08.15
業務に使っても良いけど、
ドカタ仕事は関数型言語を使ってもドカタ仕事
底辺は底辺なりに自分の境遇に満足して、変に夢持っちゃダメ

230デフォルトの名無しさん2012/09/16(日) 21:26:13.42
よくある「あいつらは馬鹿、俺は天才。」という書き込みでした

231uy2012/09/16(日) 22:54:04.49
関数型厨の書き込みって
俺のネタ書き込みよりひどい

これが素なのだとしたらもう・・・

232デフォルトの名無しさん2012/09/16(日) 22:56:16.73
>>231
なんだネタなのか
悪かったな。死ねとか言って。

233vy2012/09/16(日) 23:22:41.11
関数型言語には関数型言語の適した分野が、
動的言語には動的言語の適した分野があるよ。
それも分からずに○○は××にも使える、とか主張するのは二流を通り越して三流だね。

234デフォルトの名無しさん2012/09/17(月) 03:53:18.86
存在がネタ

235デフォルトの名無しさん2012/09/17(月) 07:11:36.99
オブジェクト指向開発だって新日鉄SOLが研究資金を出して使い始めるまでは、
業務で実用化されてなかったもんだよ
メモリや速度が重要視されるならc/c++が使われるだろうし、
小規模案件はjsだろうし、大規模開発や業務系は関数型(scalaかf#)に収束するよ

236デフォルトの名無しさん2012/09/17(月) 07:48:31.55
収束してから出なおせやw

237デフォルトの名無しさん2012/09/17(月) 08:00:25.00
絶対とは言い切れないけど、業務系は関数型にはならないよ
副作用を隔離しなきゃダメなほど複雑なコード組んでないから
単純にデータを右から左に流すだけの簡単なお仕事

238デフォルトの名無しさん2012/09/17(月) 08:10:10.39
業務に関数型?

まあ、データを右から左に流すだけだからこそ関数型が合ってると言えなくもないけど、
わざわざ言語変更するほどのモチベーションにはなりえないだろうな。

ようやく VB6 ⇒ VB.net へ移行を開始 ... 現場はこんなもんだし。

239デフォルトの名無しさん2012/09/17(月) 08:14:02.89
後発負け組の奴らって趨勢が決まって
収束してから乗り換えるって発想なんだな
そりゃ負け組だわ

240デフォルトの名無しさん2012/09/17(月) 08:36:04.27
業務アプリに先端技術を惜しげもなく投入。
でも、できることは変わりません w

アホ面晒して楽しい? >> 239

241デフォルトの名無しさん2012/09/17(月) 08:43:11.33

242デフォルトの名無しさん2012/09/17(月) 09:24:42.46
だからわざわざ関数型なんてまだまだ使わないよって書いてるんだが…

アホ面に泥まで塗って楽しいのか? (w

243デフォルトの名無しさん2012/09/17(月) 09:57:55.02
>>239
発散してるって見抜けないの?w

244デフォルトの名無しさん2012/09/17(月) 10:48:47.58
ダメなコード書くプログラマは良い言語使っても、
厳しいコーディング規約を課しても、
便利なIDEにフレームワークを使わせても、ダメなコードを書く。

=> ダメコードはコンパイル通らない関数型言語を使うとどうなるの?

245vy2012/09/17(月) 11:10:01.77
>>244
コンパイルが通る範囲でダメなコードを書くか、
この言語は使えないよ、出来損ないだ。と言って現場から逃げます。

246デフォルトの名無しさん2012/09/17(月) 11:46:55.54
関数型って変化に対応できるの?
仕様変更の多い業務系はOOのがあってる気がするんだが。

247uy2012/09/17(月) 15:37:21.11
2chってほんとに変な情報操作が流行るよねなんだこの急激な関数型叩き
使える奴は世界のどこかにはいるって
しかしほとんどのバカはそれに憧れて効率的な開発できるフリをしてるだけ
でも大勢が使えばいつかは伸びる
ドカタ以上に人柱になってくれてる奴らなんだから大切にしろwwwww

248デフォルトの名無しさん2012/09/17(月) 17:26:33.49
>>223
お前はPharoとかSqueakとかのオモチャをちょろっと触ったくらいでSmalltalk知った気になるな。

九大の事件はSmalltalkの問題とされがちだけど、実際はIBMの問題で、
動的言語じゃなくても(IBMが自社製品をごり押しすれば)きっと起こったろうよ。
http://d.hatena.ne.jp/kwatch/20080702/1215014534

249デフォルトの名無しさん2012/09/17(月) 18:17:10.21
VB >>>>>> Smalltalk (IBMにとっては)

250デフォルトの名無しさん2012/09/17(月) 18:30:33.84
Smalltalkはビジネスユースも多かった言語だけど
うんこすぎて他言語に駆逐された
まさに「業務に使ってみたけどゴミだからそっぽ向かれた」言語

251デフォルトの名無しさん2012/09/17(月) 20:02:21.07
smalltalk?javaやMySQLなんてない時代だっけ?

252デフォルトの名無しさん2012/09/17(月) 21:02:35.51
>>246
仕様変更に強くなるようなOO固有の特徴ってあったっけ?

253デフォルトの名無しさん2012/09/17(月) 21:18:11.19
どっちかっていうと関数型の方が仕様変更に強くないか?
破壊的操作を関数化されてたりしたら目も当てられないし
追いかけたくもないぞ(よくあるけどな)

254uy2012/09/17(月) 21:21:00.75
バカか

255デフォルトの名無しさん2012/09/17(月) 21:45:30.87
>>252
私の開発手法のせいかもだけど、顧客の要求中の関数に当たると思う相互関係より、登場するオブジェクトの方が先に安定するから。

256デフォルトの名無しさん2012/09/17(月) 22:59:28.72
デザパタの達人とかだと想定外な仕様変更なんてないんだろうかね
いつもSEが想定外な仕様変更持ってきてうちのチームの綺麗なコードを台無しにしやがる
ええ無能ですみません

staticなリエントラント関数しか使いまわせてないは

257デフォルトの名無しさん2012/09/17(月) 23:41:14.03
>>256
デザパタ関係ねーよw

仕様変更だろ? 工数がかかるってことをちゃんと伝えたか?

修正っていうのは、仕様変更にとりあえず対応するまでではなく、
綺麗なコードに対応するまでが修正だ。
そこまでの工数がかかるってだけだよ。

その後は技術とは関係ないところの話だろ。
1週間かかります → 3日でやれ とか技術とは関係ない。

258uy2012/09/18(火) 00:05:09.40
デザパタの達人wwwwwwwwwwwwwwwwwwwwwwwwwwwwww
デザパタセカンドや3、4がリリースされたら意味はあるかもしれない
現時点のデザパタはゴミカスってより
当たり前すぎる設計に名前を付けただけなんで
教材にしかならない

259デフォルトの名無しさん2012/09/18(火) 00:29:36.01
よくあるのが
アジャイルという単語に踊らされたオッサンが取ってくる
最初っから仕様変更前提のプロジェクト(受託)
工数も仕様変更にかかる予定日数もどう変わるかわからないのに
予算・スケジュールは固定っていうIT土方ならではの仕事
役所関係からこの手の仕事が来たとかいう日には地獄を覚悟すべし

260デフォルトの名無しさん2012/09/18(火) 01:25:10.18
営業がJavaと言ってとってきた仕事を数週進めたら、JavaScriptの仕事だった。何度もjavaでいいんですねと確認したのになぁ。

261デフォルトの名無しさん2012/09/18(火) 02:42:32.29
>>259
あーそういうの仕事って言わないで欲しいわーあるわー
進捗報告しろとかさえ無理ゲー状態から始まる奈落へのアバンチュール

262デフォルトの名無しさん2012/09/18(火) 22:04:12.71
動的言語ってアジャイル開発には向いてそうだよね
使用変更でクラスや型をどうこうって死にそうでない?

263デフォルトの名無しさん2012/09/18(火) 22:11:07.84
>>262
棄却型プロトタイプ開発ならいいんじゃない。
型変更した時の影響が静的型付のがわかりやすい。動的だと見逃してたとこがたまたま動いてたなんてこともあったり。ハマる。

264デフォルトの名無しさん2012/09/18(火) 22:46:03.31
プロトタイプを動的型付け言語で作り
仕様が固まってきたら静的型付け言語で作り直す
これ最強

265デフォルトの名無しさん2012/09/18(火) 22:51:03.62
静的型付のスクリプト言語

266デフォルトの名無しさん2012/09/18(火) 23:01:40.91
とりあえずCommonLispで書いて
型記述を追記するなり
GCLでCのソースに変換するなりすれば
一番効率がいいんじゃねぇの
Lisper見習いだからホントに出来るかはわからんが

267デフォルトの名無しさん2012/09/18(火) 23:10:03.44
静的型付けの利点を
最適化による速度向上に置いてるか
静的型チェックによる型安全性に置いてるかで変わる

268デフォルトの名無しさん2012/09/18(火) 23:44:33.93
Cのソースに変換すればコンパイル必要になるし
型安全性も保たれるんじゃないかと

269デフォルトの名無しさん2012/09/19(水) 00:00:53.89
そんなわけないのはObjective-Cみれば分かるだろ

270デフォルトの名無しさん2012/09/19(水) 03:30:17.57
動的オブジェクトの型が全部object型とかになった
型チェックが意味のないCソースに変換されるわけだ

271uy2012/09/19(水) 08:38:37.94

>>>>lisper見習い

初心者死ね!!!

272デフォルトの名無しさん2012/10/02(火) 23:24:04.32
Microsoft、JavaScript系の新言語、TypeScriptのデベロッパー・プレビュー版を発表
http://jp.techcrunch.com/archives/20121001microsoft-previews-new-javascript-like-programming-language-typescript/

273デフォルトの名無しさん2012/10/05(金) 04:44:59.33
結局動的言語駄目じゃねーかという流れになりつつある昨今
皆様いかがお過ごしでしょうか。
ここ最近出てきた一連のJS出力言語、特にTypeScriptである意味トドメだろw

しかし反動で関数型言語にスポットライトが当たってるのは逆方向にブレすぎではないか

274デフォルトの名無しさん2012/10/05(金) 12:42:34.09
関数型は局所的に盛り上がるけどなかなか普及の兆しが見えないな。俺もちろっと遊んだ程度で放置してるし

TypeScriptはコケる

275デフォルトの名無しさん2012/10/22(月) 06:25:54.38
JSはウェブ系の場合嫌でも使うしかないからね。いまんとこ、ベターJSの中じゃ、TypeScriptは一番良いと思うね。

276デフォルトの名無しさん2012/10/22(月) 23:40:56.58
>>275
もうお使いですか。どないです?
AS房としては期待外れっす

277デフォルトの名無しさん2012/11/03(土) 16:51:07.37
>>274
金融系の一部とかパーサー書いたりの分野で使われてんだろ
学歴のない底辺には玩具で終わる代物だよ

278デフォルトの名無しさん2012/11/03(土) 16:56:19.12
f#やOcsigenなんかはもっと評価されていいはず

279デフォルトの名無しさん2012/11/03(土) 18:42:25.65
パーサはよく適用例で見かけるけど、金融系でも関数型普及してるのか
COBOLのイメージしかなかったけど確かに都合良さそうだ
まあ俺みたいな底辺土方には一生縁ねーなw

280デフォルトの名無しさん2012/11/03(土) 18:44:48.69
金融系って言ってもCOBOL使ってたとことはまったく別の分野じゃない?

281デフォルトの名無しさん2012/11/03(土) 19:30:58.86
勘定系じゃなくて、デリバティブとかのいわゆる金融工学の方でしょ。

282デフォルトの名無しさん2012/11/03(土) 23:30:00.20
あんな制御不能なものを工学と呼ぶのは工学への侮辱だな。

...ソフトウエア工学も同類か...orz

283デフォルトの名無しさん2012/11/04(日) 00:54:13.02
金融系 関数型でぐぐると美辞麗句にまみれたPDFとかがいろいろヒットするなー
門外漢にはなんのこっちゃよくわからんけど

284デフォルトの名無しさん2012/11/04(日) 18:58:55.03
>>282

285デフォルトの名無しさん2013/02/20(水) 21:20:39.01
ところで、shで書かれたconfigureとかは1万行以上あるわけだが、あれは大規模開発になるんか?

286デフォルトの名無しさん2013/02/20(水) 23:44:16.57
>>285
あなたは手で書いてるの?

287デフォルトの名無しさん2013/02/20(水) 23:57:15.20
自動生成だけど?

自動生成ならいくらでもソース量が増えるから、
別にソース量が多いからって大規模じゃないよねっていうIrony。

288デフォルトの名無しさん2013/02/21(木) 00:01:32.70
ソースを生成するソースを書けば小規模になるんじゃね

289デフォルトの名無しさん2013/02/21(木) 01:41:04.93
今調べて初めて知ったのか。

290デフォルトの名無しさん2013/02/21(木) 21:25:30.17
まじでかホント初めて知ったわ。
OSもソースを生成するツールを生成するツールを生成するツールで作成すれば100行程度に縮められるなっ!

291デフォルトの名無しさん2013/02/21(木) 21:37:45.76
>>290
そのツールチェインの最後はお前だよお前しだい。

292デフォルトの名無しさん2013/04/03(水) 22:31:12.49
>>8
1万行で大規模ワラタw

293手巣 ◆JvxT/vAhHw 2013/06/15(土) 23:51:26.86

294デフォルトの名無しさん2014/01/16(木) 15:14:04.15
9 :デフォルトの名無しさん:2014/01/11(土) 12:45:26.07
PHPが多分広く使われてるんだろうけど
Web鯖へのPHP標的とみられるアタックの回数が今年に入ってからヤバい
あらゆる種類のPHPアタックされてる
あいにくPHP鯖じゃないしPHPも動かしてないから無関係だけど

ruby鯖でほんと良かったよ

295デフォルトの名無しさん2014/01/16(木) 15:58:57.11
〜10万行小規模
100万行中規模
1000万行大規模

296デフォルトの名無しさん2014/01/16(木) 16:15:44.93
それは生産性の低いCとかの目安だろう

297デフォルトの名無しさん2014/01/16(木) 16:22:11.85
じゃあこうだ
rubyなら
〜1万行小規模
10万行中規模
100万行大規模

298デフォルトの名無しさん2014/01/16(木) 16:39:07.41
ペコーンwwwwwwwwwwwwww

299デフォルトの名無しさん2014/01/16(木) 18:22:08.59
ロバみたいな奴だな

300デフォルトの名無しさん2014/01/17(金) 02:26:52.79
場粉路「300wwwwwwwwwwwwwwwwwwwwww」

301デフォルトの名無しさん2014/02/05(水) 04:47:08.99
型安全性ない限り不可能ですわ

302デフォルトの名無しさん2014/02/05(水) 06:16:34.54
ああ、本物の動的型を知らないんだ。
型安全じゃない動的型しか使ったこと無いんだね。

303デフォルトの名無しさん2014/02/05(水) 09:43:19.39
実用性のあるやつあったっけ?
ネタみたいな言語はいらないよ

304デフォルトの名無しさん2014/02/05(水) 11:54:42.46
本物の動的型っていうのは
たとえばJavaやC++のことだよ。

型安全かつ動的。動的っていうのは
ポリモーフィズムのことを言う。
実際に使われるクラスが動的にしか決まらないから。

インターフェースは静的だけどね。
でも具象クラスが動的に決まるならば、
それは動的言語なんだよ。

305デフォルトの名無しさん2014/02/05(水) 12:09:06.82
などと意味不明なことを供述しており精神鑑定の結果を待って慎重に対応する予定です

306デフォルトの名無しさん2014/02/05(水) 12:54:50.99
>>304
なんでゴミってこんなつまんねーことしか言えないんだ

307デフォルトの名無しさん2014/02/05(水) 12:58:26.58
ほっほっほ、反論は無しw

308デフォルトの名無しさん2014/02/05(水) 13:12:01.88
>>307
死ねゴミ

309デフォルトの名無しさん2014/02/07(金) 06:53:01.21
死ねゴミ

310デフォルトの名無しさん2014/02/07(金) 16:38:35.68
ぁーーーやっぱり型推論やる感じの静的言語になるのかなぁ
色々考えたけどやっぱし無理かも
結局コンパイル時に出来る限り多くのエラー検出してくれた方が、
実行後に「気にしなきゃいけない事」が減ってくれるから
その差が理論的にどうやっても静的言語と動的言語じゃ埋まらない
それでも短いコード書く場合は動的言語のほうが良いのは事実だけど
完全に動的になってる言語ってどうも、eval上でコード動かしてるのと似たような気分になる事があるし
それでも何とかなるとしたら物量か

311デフォルトの名無しさん2014/02/07(金) 20:40:16.60
JSでとあるゲーム2,3年ぼちぼち作っててデータやView部抜きで1万行くらいをキープしてるけど
今までで一番長時間ハマったのは暗黙の型変換の挙動かな
確か正規表現で取り出した数字文字列を、==で数値と比較してる部分があって、その時点では問題なかったけど
後からそこ見て数値同士の比較かと思ってカッコつけて==を===を直してしまったんだよね

でもそれからは気をつけて、代入時に型と値の範囲を一気に確定させておく書き方を心がけるようにした
あくまで例えばだけど、文字列から少数を取り出すのなら、
m = +(str.match(/\d+\.\d+/)||[0])[0]
のような勢いで

こうやって一発で行数を減らしておくと全体の見通しがよくなって更に嵌りそうなことが減る
単行演算子とか用いると実装速度も微妙に上がるしね、asm.jsライクな記述すると

それで確かにその時は==となって欲しいケースが稀だったことや
その場所が予想外にViewに当たる場所だったこともあってかなり特定が大変だったけど、
逆に数値演算ばかりの結構複雑だと思うメインロジックでは難しい問題起こらなかったんだよね

評価関数の出来って動かしてみないと良くなったかどうかわからないってこともあるし、
エラーではなくアルゴリズム的に正しいかどうかの判断は動かしてなんぼで不満なかった
「大規模」ではなくて、「多いコード」だから動的が向いてないっていうのは違うんだろうね

例えばES6でclassシンタックスが入って大規模がよくなるっていうけど
ひたすら配列の操作をやるのだと関数型チックなので困らないし
まあ「大規模」っていうのは色んな要素が入ってると思うけど、そこをまず具体的に洗い出していったほうがいいかもね
その上でそれぞれに対して動的型でどうしていったらより良くなるか考えよう

312デフォルトの名無しさん2014/02/07(金) 22:01:54.81
==と===の違いは面倒だから使うなって、
オライリーから出ている薄い本の何処にでも書かれてるだろ

313デフォルトの名無しさん2014/02/07(金) 22:03:36.88
テストコードやCIしながら書くもんじゃないのか

314デフォルトの名無しさん2014/02/07(金) 22:04:48.68
静的言語ならバグが含まれないってのが、そもそもの幻想

315デフォルトの名無しさん2014/02/07(金) 22:13:41.93
静的言語でバグを作り出さないなら、JUnitなんて出てくるわけがない
いちいち変数定義するなら、それ無しでテストコードまで書いた方が効率良い
という発想。(テスト自体はSmalltalkからJavaへ輸入されてた気がする)

316デフォルトの名無しさん2014/02/08(土) 01:39:35.92
ウェブで言うと、昔は専用サーバは高価でシェルを使えるのは希だったから、スクリプト言語の方が動かしやすかったんだよ
プログラム自体も単純なものが多かったから、タイプセーフじゃなくても問題なかった

317デフォルトの名無しさん2014/02/08(土) 06:00:40.97
>>312
それは今回の件とは関係ない
例え最初から===にしてたとしても、前述したように稀かつゲームを進めないと出てこない問題だったから気付けなかった
むしろこういうケースがあるから==の方を使ったほうが殆どの場合でいいと思ってる
まあ、言いたいことはそういうことじゃない

今回テストは作りたて関数やバグが出たら使い捨てくらいの軽い気持ちで作るという感じだったが
よほど労力(とテストにかかる時間)をかけていたとしても発見できたかは微妙だった
今回のケースは自分はもっとメタ的に解決すべきだったと思う

例えば演算子オーバーロードができればそういったハマりやすいポイントでワーニングが出せる
それだけじゃなくて統計をとって最適化にもきっと活かせる
(例えば結果がSMIのようなJITエンジンがより最適化してくれる範囲内かどうか等)

他にもProxyとかメタ的やハックでの「動かしながらの」分析によるテストが
特に緩い動的言語での大きな開発でかなり有効なんじゃないかと自分は思ってきてる

ある程度はデバッガの役割だろうが、例えば条件付きブレークポイントみたいに
汎用的に細かいことがしたければ結局コードを書くことになるので、しかたない
でもそういったことが十分できるのならば自分は開発になんら不満、不安を感じない

また今回は流れでテストするのにデータのObservingが役に立ってる
各処理関数に全く関わる必要もないしテストも全く省けてる
目でのチェックと同時に比較的低負荷でできるのがかなり効率がいい

自分はES6,7などこれからのJSにはそういう部分に結構期待してる

318デフォルトの名無しさん2014/02/08(土) 08:08:08.34
>>312
オライリーって反面教師の本だろ。。。
死ねゴミ

319デフォルトの名無しさん2014/02/08(土) 11:30:21.22
オライリーのどの辺が反面教師なの?
あなたは国内出版社の方?

320デフォルトの名無しさん2014/02/08(土) 13:01:18.60
基本的にオライリーはゴミな上に一回本出した後で
売れ残りすぎてるから2版3版って更新されんのが遅すぎて
載ってる情報が古すぎるケースが多すぎ
あれ読んでる奴はゴミ

321デフォルトの名無しさん2014/02/08(土) 13:07:19.15
オライリーは言語によって出来が違いすぎる

322デフォルトの名無しさん2014/02/08(土) 13:07:59.08
英語版はやっぱり出来がいいよね。

323デフォルトの名無しさん2014/02/08(土) 13:19:36.72
本毎に差がありすぎるんだよな
あと翻訳者
日本人が書いてゴミなRuby本もあったな

324デフォルトの名無しさん2014/02/08(土) 13:28:19.75
書店にいって適当に本の後ろの発行日を見たらいいよ
オライリーは5年とか10年ものとか平気でおかれてる
売れてないからそうなってる
初心者チックな本でも、せいぜい1〜2年以内に出た新しい本買ったほうが絶対良い
あとはネットで調べりゃいいだけ

325デフォルトの名無しさん2014/02/08(土) 13:33:40.49
オライリーは新しくないとダメなものは向かない
新しい情報はネットで集めた方がいい
適当な他の本買うぐらいならオライリーのがマシなことが多いな

それよか、ピアソンどうなるんだ?

326デフォルトの名無しさん2014/02/08(土) 13:40:16.96
オライリーはゴミw

327デフォルトの名無しさん2014/02/08(土) 13:42:03.17
1年2年で入れ替わるくらい変化が激しい物ならそれこそ本なんて遅すぎて
いらないってなるだろうに。

328デフォルトの名無しさん2014/02/08(土) 13:56:41.14
ITってそういう分野
ハードウェア絡むような場所だけだよ
5〜10年昔の知識が通用するなんて

329デフォルトの名無しさん2014/02/08(土) 14:00:39.74
もうオライリーみたいな重厚長大な本の時代じゃないね
昔はラクダ本とかボロボロになるまで読んだけどね

330デフォルトの名無しさん2014/02/08(土) 14:21:34.64
ゴミw

331デフォルトの名無しさん2014/02/08(土) 14:23:39.19
ネットの情報は断片的に拾い読みする分には良いが
まとまった情報って本で無いとねえ。

って言うのは古いかw

332デフォルトの名無しさん2014/02/08(土) 14:31:47.88
リファレンスとかは完全に ネット > 本 になった

333デフォルトの名無しさん2014/02/08(土) 14:57:45.25
では、ハズレの本を出さない出版社を発表しちゃってください。

334デフォルトの名無しさん2014/02/08(土) 15:21:13.00
>>328
OSやコンパイラの基礎的な知識がここ5〜10年ほどで全部置き換わったとでも?
何か新しいツールやライブラリなんかも利用期間が長ければ長いほど後方互換を
考えて思想的な部分を変えることが出来なくなってるよ?

基礎的な知識がない人、表面だけなぞってる人は全く変わって通用しなくなると
感じてんるんだろうけど、そんなことは無いんだけどね。

335デフォルトの名無しさん2014/02/08(土) 15:24:34.62
つ電子書籍

すっかりぐだぐだのイメージが広まりつつあるがw

336デフォルトの名無しさん2014/02/08(土) 15:26:17.39
ここ15年くらい何も進歩してない
モバイルへのシフトが見えるくらい

337デフォルトの名無しさん2014/02/08(土) 15:34:56.49
結局は、ノイマン型のコンピュータが登場して以来何も進歩してないんだよ

338デフォルトの名無しさん2014/02/08(土) 15:55:37.52
話でかくなりすぎw

339デフォルトの名無しさん2014/02/08(土) 16:36:22.62
プログラミング言語だけ見ても、PHPでもRubyでもC#でもJavaでもこの10年で大きく変わってる
ライブラリやミドルウェアはもっと変わってる
これだけラピッドリリースが当たり前の時代、オライリーは本棚に並べて自己満足するぐらいの価値しかない

340デフォルトの名無しさん2014/02/08(土) 17:06:39.19
>>339

>>334 の下2行

341デフォルトの名無しさん2014/02/08(土) 17:08:41.77
Ajax でブラウザとJSの地位が大幅に向上したというのは進歩かもしれない
それ以外は驚くほど何も変わってない

342デフォルトの名無しさん2014/02/08(土) 21:58:29.94
JSに関してはかなり変わってきてると思う
00年代後半くらいに出た本はまだコーディングルールもままならなかったJSに対して
JSの安全で多言語との相異があまりない部分だけを使うという、かなり厳しい立場なものが多い
そしてそれ以降にでた本もそれを踏襲しているから同じ
ES3まではクラスベースの皮をすっぽり被ったプロトタイプベース言語だったからしかたがない
ゲッターすらも定義できないような未熟な言語だったのは確か

でもES5,ES6ときて例えばブロック文中の関数宣言の振る舞いの問題とか、
根底の不安定さがかなり解消されてきてる
そしてES6ではクラスシンタックスが入ったり、ミキシン等のサポートや、
プライベートっぽくもできるSymbolの導入、また何と言っても今までは
クラスベースの皮に隠れてたプロトタイプが表面にでたお陰でかなり変わってる
Promiseとか、関数型の方向性も強化されてきていて、
マルチパラダイム言語としてかなり磨きがかかって底上げされている
他にもモジュールやブロックスコープとか、書ききれない

コーディングルールの面でも、最近ではgoodpartsを書いたグーグル内、
例えばV8グループ内でもセミコロンフリーのソースがコミットされたりもしている
JSに関しては、何がいいのかは(ブラウザ間の差もあるし)その時その時で考えていくべき
JSも成熟してきて、JSerも成熟してきてるから、無闇矢鱈に縛る必要がなくなってきている

343デフォルトの名無しさん2014/02/09(日) 00:23:11.54
>>333
Wikiにまとめられる情報を精査して紙媒体の本にするのが良いんだろうけど、
著作権的な問題で出来ないんだろうなと思う

344デフォルトの名無しさん2014/02/09(日) 04:44:50.85
>>334
10年前の本でも読んでると良いよ

ゴミはゴミなんだからそれで良いな

345デフォルトの名無しさん2014/02/09(日) 10:36:31.60
> 10年前の本でも読んでると良いよ

2004年の本ですか? そりゃ読むでしょうよw

346デフォルトの名無しさん2014/02/09(日) 12:19:57.73
10年前のApacheの本とかBindとかSendmailとか

347デフォルトの名無しさん2014/02/09(日) 21:59:17.96
JavaScriptは約5年の間にES3→ES6で仕様書は3倍になったし、
もっと言えばHTML5との絡みで世界が日に日に拡大してるから仕方ないね。
そのとき常識でも、半年経つと状況がガラッと変わった照りするからね。

例えば今はアニメーションはライブラリの手を借りないと困難だって認識だろうけど、
確か今年の6月くらいににAnimationsAPIが勧告されるからね。
まあフラグONにすればもう一部は使えるんだけど、そもそも存在を知る人も少なそう。

もうちょい先の話だとServiceWorkerとかね。
スクリプト言語はAPIあってのものだから大変だね。

348デフォルトの名無しさん2014/02/10(月) 09:34:39.88
情報が古いと分かってる本読んでも得るもの何もないからな
信頼できない本読んで間違って覚えてそれで良いと勘違いしてる状況のほうが厄介な問題起こりそう

ゴミ

349デフォルトの名無しさん2014/02/10(月) 14:01:59.53
過去の仕様が根こそぎ変化するわけじゃないんだから、
古くなってる部分だけ調べりゃ良いだろ

350デフォルトの名無しさん2014/02/10(月) 14:43:51.08
古いものの方が
肥大した無駄機能もなく
本質的な部分に絞りこまれていることが多い

ただし破壊的変更を繰り返してフラフラしている駄ツールには当てはまらないかもしれない

351デフォルトの名無しさん2014/02/10(月) 14:48:45.54
古い本を読んでる最中に古い情報(間違った情報)と新しい情報(正しい情報)の区別をどうやってつけるんだか
ゴミかよ

352デフォルトの名無しさん2014/02/10(月) 14:49:39.61
ゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミwwwwwwwwwwwwwwwwwwwwwwwwwwww

353デフォルトの名無しさん2014/02/10(月) 16:10:40.42
問題が生じてから調べりゃ良いだろ

354デフォルトの名無しさん2014/02/10(月) 16:35:30.36
損害被ってから調べるわけか

新しい本がないならまだしも
新しい本があるにもかかわらず古いほう読んで間違った知識身に付けたがるゴミってペチパー以上に理解できない存在だな
死ねゴミ

355デフォルトの名無しさん2014/02/10(月) 17:21:58.51
学んだことが数年で間違った知識と化すのならばその技術・ツールそのものが害なのだ

356デフォルトの名無しさん2014/02/10(月) 18:40:07.47
IT分野に来ないほうが良いな

357デフォルトの名無しさん2014/02/10(月) 18:45:28.28
RubyやRailsが顕著だけど、それ以外のプロダクトも互換性は早く捨ててイノベーションする動きになってる

358デフォルトの名無しさん2014/02/10(月) 21:34:55.60
互換性と情報の古くなりやすさは違う気がする
JavaScriptなんて顕著な例だし
むしろ古い情報が中途半端に有効なことが問題を大きくしてる

まあ、本っていうのはやっぱ向いてる分野が限られてると思う。

359デフォルトの名無しさん2014/02/10(月) 23:11:20.52
言語機能もライブラリも互換性ぶったぎってるから、本の通りに書いても全く動かない
依存関係があるから、部分的に古いライブラリ使おうと思っても一筋縄じゃ行かない
そんなの自力で解決出来る知識あるなら、そもそも本なんか不要

360デフォルトの名無しさん2014/02/11(火) 01:14:27.60
誰が
何のために
変えているのか?

361デフォルトの名無しさん2014/02/11(火) 07:53:46.12
コンパイルエラーなんかでて、動かないならまだ良いけど
「動くけど動作が違います^^;」

っていうのが最もヤバい
ruby1.8→1.9のヤバさは想像を絶する
Ostruct、クラス変数、シャドウイング使いまくってた人たちってどうなったの

362デフォルトの名無しさん2014/02/11(火) 07:57:41.43
中途半端に途中まで正しく動くなんてまさに無能な働き者
仕事をしないならしないで良いのに、
ちょっとした期待をさせるからそれに頼ってみるとやはり失敗するという
船乗りとか、登山家が、余計な足手まといは連れて行かないのと同じ
プロだけで行くなら良いのに素人が一緒に来るとプロまで道連れになるんだ

人間レベルで
「動くけど動作が違います^^;」
は、困る

363デフォルトの名無しさん2014/02/11(火) 09:06:04.31
育成しろ
おまえの役目だぞ

364デフォルトの名無しさん2014/02/11(火) 10:10:44.65
>>325,349
死ねゴミw

365デフォルトの名無しさん2014/09/19(金) 11:11:48.63ID:uUn/9tg4
サーバサイドではNode.jsからJavaやGoへの切り替えが進み
クライアントサイドではTypeScriptを導入した連中が喜びの声を上げている、
もちろんSwiftもある

JavaScriptもPythonも型アノーテーション導入を検討しているし、Rubyもこれだ

https://twitter.com/miyohide/status/512768555385769986
> Matz「最近の言語(ScalaやGoやDartなど)はみんな静的な型を持っていて、
> ちょっとそれは悔しいので、Rubyでも導入を考えたい。」

情勢から見て、もはや静的型の勝利、動的型はやはり駄目だったよということで決着がついただろう。

とりわけ動的型の経験しかなかったウェブ屋やTDD厨がちょっと頭おかしかった。
動的型はゼロ年代の一時的な熱狂だったということで終わるのではないか。
冷静に考えてとにかくメリットがねーもん。まるっきり。

Real World Academia: Unit testing isn't enough. You need static typing too.
http://evanfarrer.blogspot.jp/2012/06/unit-testing-isnt-enough-you-need.html
> 「ユニットテストだけでは不十分だ。静的型も必要だ」

ってことすな。

366デフォルトの名無しさん2014/09/19(金) 13:53:26.63ID:Xfkvubm0
この業界は一時的な熱狂が多すぎるよね

367デフォルトの名無しさん2014/09/19(金) 16:44:39.68ID:3WQN+no2
>>365
>サーバサイドではNode.jsからJavaやGoへの切り替えが進み

一行目からもう信憑性ゼロじゃないかw

368デフォルトの名無しさん2014/09/20(土) 09:47:56.33ID:b8OT/FfJ
型チェックというのも、テストの全てではないが
テストの一部なんだよ。

それが原因のバグもあるわけなんだから。

たとえそれが一瞬で修正できることだとしても
その為に別の作業中にバグ見つけて
割り込みで修正するとか思考の流れを途切れさせることはよくある話。

369デフォルトの名無しさん2014/09/30(火) 07:23:04.54ID:2CeH2hLD
>>366
幸か不幸か、ソフトウェアというのは一時的な熱狂だけで「動くもの」を作れてしまう分野だからだろうね

370デフォルトの名無しさん2014/10/11(土) 23:13:05.47ID:bgxomZ9f
Rubyで開発やってるけど、
unitテストの設計と項目作成だけで
3人で三週間かかって、マジで倒れそうだわ

来週からテストだけど、かなり辞めたい気分

371デフォルトの名無しさん2014/10/12(日) 07:22:26.20ID:5ixfa8wz
>>370
大変なとこだけやって辞めてくれるとか有り難いな。
まあ、設計がちゃんとできていればの話だけど。

372デフォルトの名無しさん2014/10/12(日) 07:29:16.53ID:jjrAIsW+
大変な所=メンテナンスだから、
今後ずっと大変な状態が続くよ、

Rubyをやめるのが一番の早道だな。

373デフォルトの名無しさん2014/10/12(日) 07:36:17.74ID:gqs4tO4e
テストすらロクにしない>>372はどんな言語で書いてもバグだらけw

374デフォルトの名無しさん2014/10/12(日) 09:08:57.89ID:5ixfa8wz
>>372
メンテが大変なのは自動テストがない場合だろ。
なぜ他の言語だとメンテが楽なの?

375デフォルトの名無しさん2014/10/12(日) 10:05:01.80ID:DxGoFyW9
>>371
UNITテストやるのもかなり大変だろ

テストの途中でメソッドが増えたり減ったりしてそのたびにテスト項目修正して
ログから障害の原因が分からない場合はログを修正して
RUNITのアサートも修正して、テスト項目も修正し無いと行けないし、、

考えただけでだるいわ

376デフォルトの名無しさん2014/10/12(日) 13:06:01.13ID:5ixfa8wz
>>375
それは仕様変更だろ。
TDDなら、メソッドの変更の前にテストの変更が来るし。

377デフォルトの名無しさん2014/10/12(日) 17:09:28.84ID:gqs4tO4e
>>375
ルビーの勉強がんばってください、入門者さんw

378デフォルトの名無しさん2014/10/16(木) 00:02:19.53ID:Ju1r+RJJ
動物言語に見えた

379デフォルトの名無しさん2014/10/16(木) 07:57:26.33ID:Sk/7zxTc
面倒なのは全部ほかにまわせば確かに楽になるかもな

380デフォルトの名無しさん2014/10/18(土) 12:19:07.94ID:xyIEV5M1
巷に出回る仕事術の基本

381デフォルトの名無しさん2014/11/24(月) 00:10:36.26ID:NFvfX/bb
動的言語ってリファレンスが読みにくくね?
みんなどうしてんの?

382デフォルトの名無しさん2014/11/24(月) 00:12:03.59ID:LP7Sk3Ho
暗記

383デフォルトの名無しさん2014/11/24(月) 00:16:50.33ID:PX1MFVrm
そんなん言語によるだろ

384デフォルトの名無しさん2014/11/24(月) 09:52:02.93ID:bceL07z7
>>381
具体的にどの言語のリファレンスが読みにくいと?

385デフォルトの名無しさん2014/11/24(月) 10:02:48.56ID:XLIBB3hZ
pythonしか知らんが、pythonはかなりドキュメント類がしっかりしてると思うけどな。

ただまあ、マイナー言語、ライブラリは動的静的カンケーなく、結局ソースを読むことにはなると思う。

386デフォルトの名無しさん2014/11/24(月) 10:33:25.11ID:vb0rebZq
定番アプリのソースで似たようなことしてるものを探して真似る
うっかりソースを読んで入り込むとあとで変更された時にヤラれる

387デフォルトの名無しさん2014/11/24(月) 15:01:36.25ID:kcRDK3+j
PHPとPythonのドキュメントはしっかりしてるけど
RubyとSmalltalkのはゴミだったな

388デフォルトの名無しさん2014/11/24(月) 17:34:32.45ID:XLIBB3hZ
smalltalkはブラウザ開いて
オブジェクトと対話しながらプログラミングしていくスタイルだから
アレで良いのだ

と、多くのスモールトーカー様は思ってる

389デフォルトの名無しさん2014/11/24(月) 18:25:46.58ID:2QNpXJ+6
動的言語ではないがJavaのAPIドキュメントがしっかりしすぎてる。

390デフォルトの名無しさん2014/11/24(月) 18:41:49.16ID:atmNtLqz
Smalltalkのドキュメントって何のことだろう?

391デフォルトの名無しさん2014/11/24(月) 19:12:45.95ID:NFvfX/bb
pythonのopencvとかnumpyのリファレンス見てみたんだけど
なんの型を入れるとなんの型が帰ってくるのか明確に書いてないからサンプル見ないと分かんない

392デフォルトの名無しさん2014/11/24(月) 19:35:00.93ID:vb0rebZq
その辺はネーミングセンスでカバーするという思想だろうけど
Cライブラリのラッパーとかだと全く通用しなくなるな

393デフォルトの名無しさん2014/11/24(月) 20:12:08.30ID:2QNpXJ+6
>>391
ipythonで?して書いてなかったらソース読んでる。

394デフォルトの名無しさん2014/11/24(月) 20:25:30.45ID:PX1MFVrm
vimでKを押してdocumentがなかったら
\dを押して定義元のソースコードにジャンプしてる

395デフォルトの名無しさん2014/11/25(火) 00:06:15.89ID:pX8dGPkN
下みたいコードのエラーを実行前に検出できるlint系ツールが存在する
Pythonを動的言語で括って良いものだろうか


def foo(x):
    def f(g):
        return g() + x
    return f

def bar():
    foo(1)(lambda: 'abc')

396デフォルトの名無しさん2014/11/25(火) 05:48:58.67ID:0npMaebU
最近追ってなかったけど
pythonは型アノテーション導入の話題もあるのな。

397デフォルトの名無しさん2014/11/25(火) 20:38:28.15ID:NsP7IFUt
やっぱ大規模開発には静的型があった方が
良いんだろうな

398デフォルトの名無しさん2014/11/25(火) 23:51:15.09ID:n1duvf0w
>>397
typoですら動かすまで見つけれないのは地味にストレスだからな。

399デフォルトの名無しさん2014/11/26(水) 04:22:00.60ID:zFnj+88g
>>398
何十年前の常識だよそれ
今時typoすら実行前に発見できない処理系のほうが珍しい

400デフォルトの名無しさん2014/11/26(水) 05:14:33.37ID:iOq+FlWm
>>399
動的言語は、typoを実行前に発見できないほうが多いよ。
発見できないパターンはこれ

obj.f00 (fooの間違い)

オブジェクトのメソッドのメソッド名を間違えた時
ほぼ全ての動的言語は、実行するまでtypoを発見できない。

なぜなら後で動的にメソッドを追加するかもしれないから
実行するまでわからない。

401デフォルトの名無しさん2014/11/26(水) 05:24:10.98ID:iOq+FlWm
動的言語だとtypoがわかると言っても
ローカル変数程度なんだよね。

そんな近くにある目で見てもすぐわかるようなものより
ファイルをまたいだりしている遠くにあるコードの
typoを知りたいんだが。

402デフォルトの名無しさん2014/11/26(水) 08:52:45.01ID:IUNEYOWi
>>400

>なぜなら後で動的にメソッドを追加するかもしれないから
>実行するまでわからない。

そういうケースにワーニングを出してくれるだけで十分ありがたい

403デフォルトの名無しさん2014/11/26(水) 10:27:57.07ID:lFXPwW0W
>>400
その理屈はなんかおかしいぞ。

後で動的にメソッドが追加されるかもしれないから
typoかどうか実行時まで*処理系側では*判断できない
というだけの話。

書いている人間様はそれがtypoかどうかは容易に判断できる(気づきさえすれば)。
だから、パーズ・コンパイル時に単に未定義だと文字通りワーニングを出せばいい話で、
実際そういう機能を持つ処理系やIDEは1980年代のSmalltalkから普通にある。

typoでたまたま他の既存のメソッド名とかぶってしまった場合に、
型でtypoかどうか判断可能という主張ならまだわかる。
その場合でも、型まで一致していたら静的型言語でもお手上げだ。

404デフォルトの名無しさん2014/11/26(水) 10:37:02.67ID:IUNEYOWi
typoっつーか、メソッド名を補完してたら
ウッカリ同じprefixの別のメソッド呼んじゃってた事はあるよ

でも、その間違ったメソッドが引数の型や数、戻り値の型まで一致してたことは一度も無かった

405デフォルトの名無しさん2014/11/26(水) 12:07:39.14ID:lFXPwW0W
>>404
補完なら、ふつう型が一致してなかったらそもそも候補に出てこないし、
まして「呼んじゃって」(つまりコンパイルが通って実行される)なんてことは
ウッカリだろうが何だろうが基本ないことだと思うけど?

406デフォルトの名無しさん2014/11/26(水) 12:29:05.12ID:jMc4tHhg
>>405
動的言語は型が一致しないメソッドも候補に出てくるIDEばっかじゃんSmalltalkも含めて
それにコンパイルも通るよ静的型じゃ無いんだから

407デフォルトの名無しさん2014/11/26(水) 12:35:38.39ID:lFXPwW0W
>>406
>>405は静的型言語の話をしているんだが?
それとも>>404は動的型言語の話なのか?
ならなんで「引数の型や数、戻り値の型まで一致」とか出てくるんだ?

408デフォルトの名無しさん2014/11/26(水) 12:59:25.21ID:jMc4tHhg
>>407
>ならなんで「引数の型や数、戻り値の型まで一致」とか出てくるんだ?

動的言語でも値に型はあるから

409デフォルトの名無しさん2014/11/26(水) 17:49:47.93ID:jGVOTHDh
rubyのto_sとか?

410デフォルトの名無しさん2014/11/26(水) 20:45:29.26ID:zFnj+88g
>>408
へー、どの動的型付言語が言語仕様で「型」という概念が定義されているんだい?

411デフォルトの名無しさん2014/11/26(水) 20:48:18.16ID:zFnj+88g
動的型付言語を使っていて型が違うのにとか型で補完できればとか言ってる人は動的型付言語の初心者。
動的型付言語を単に型宣言しない静的型付言語として使っているだけ。

412デフォルトの名無しさん2014/11/26(水) 22:06:07.76ID:jGVOTHDh
初心者

413デフォルトの名無しさん2014/11/26(水) 22:45:02.52ID:A6eFHCKj
>>411
まあ初心者なら Soft typing という用語を知らなくても
しかたないだろうな

414デフォルトの名無しさん2014/11/26(水) 22:49:59.27ID:HWidBYzd
>>410
a = 1
a = "a"
a = true

一行目のaの値は数値型で二行目で文字型に変り三行目でBoolean型に
なるってことで型が無いように見えて値にはちゃんと型があると言いたいんでしょ?

415デフォルトの名無しさん2014/11/26(水) 22:52:09.61ID:HWidBYzd
柔軟だがバグの元にはなりそうだ

416デフォルトの名無しさん2014/11/26(水) 23:01:03.31ID:gCulqy1V
重要なのは値に型があることではなくて変数に型があること。
変数に型があるからこそ、その変数の型のメソッドは何かがわかる。

417デフォルトの名無しさん2014/11/26(水) 23:03:26.44ID:gCulqy1V
変数はコードに書く。コードに書くということは
静的にわかる。(変数に型がある場合)

値に型があっても、実行時にならないとわからない。
変数に入る値はいろんな型がありえるから
値に型があるだけじゃ、typoを発見することは出来ない。

いい加減「値に型がある」を反論の材料にするのはやめてくれ。
反論になってないから

418デフォルトの名無しさん2014/11/26(水) 23:10:00.48ID:b8NKrcQ+
変数posがあってこれが座標を表わしてるものだとしたら
list型で(x y)だったり構造体でxとyのフィールドを持ってたりy*w+xの整数だったり
色んな表現が出来るから柔軟という利点があってプロトタイプに向いてるってことじゃないの

419デフォルトの名無しさん2014/11/27(木) 00:00:17.23ID:qRi3TEum
>>411
動的型言語の玄人になると、値の型と無関係な(CallするとRuntime Errorになる)メソッドが
大量に候補に出てくるような補完や、typoすら発見できないようなチェッカーに
慣らされてるから疑問にすら思わなくなるってこと?

420デフォルトの名無しさん2014/11/27(木) 00:39:38.24ID:dibuY+0s
>>418
一人で把握できる範囲でプロトタイプのようなある程度使い捨てを前提に作れる
ならそれほど問題はないが、スレタイにあるように大規模開発≒複数人開発だと
静的言語に比べて動的言語だとtypoみたいな簡単なミスでも見つけづらいよねと
いうような話だと思う。 ちょろっとしたものを作るだけなら変数は全てオブジェクト
ですっていうように抽象化されている方が楽だけど、大規模開発だとそれじゃ
ダメだよねっていう話。

421デフォルトの名無しさん2014/11/27(木) 00:43:32.22ID:pDjxUsPd
>>419
大量ったってさらに数文字足せばかなり絞り込めるし
typoだって前にも書いてあるとおり
未定義のワーニングで十分に思うんだが
いったい何が不満なんだ?

422デフォルトの名無しさん2014/11/27(木) 07:05:04.04ID:zJRTpdHD
そりゃ未定義がワーニングだからだろ。
ワークニング出たよ。
さて、そのワーニングは無視していいのかよくないのか?

typoしてワーニングが出た。あぁ、いつものワーニングかでスルー
結局ワーニングがあてにならないものになってるだろ。

423デフォルトの名無しさん2014/11/27(木) 07:17:33.51ID:pDjxUsPd
>>422
いや、普段使いがSmalltalkなもんで、そんなことはない。
未定義のワーニングはtypoだった場合の候補も挙げてくれるから
実際にtypoだったらそこから選ぶだけだし。^^;

424デフォルトの名無しさん2014/11/27(木) 07:36:00.70ID:0IKZEJch
SmalltalkのIDEの補完は精度が低過ぎて使えないゴミだから
プログラマは補完に頼らず自分でタイプするから
>>404みたいな問題もないんだよね

425デフォルトの名無しさん2014/11/27(木) 08:44:42.11ID:29V21Kp8
>>424
そうだね。なんかこんなようなメソッド名(Smalltalkではセレクタと呼ぶ)だったなぁ…と
うろ覚えで適当に入れとくとコンパイラがあとでいちいち教えてくれるから、はいはいって直してく感じ。

補完が便利だなぁと感じるのは長いメソッド名の場合かな。
適当にだとしてもタイプするのが単純に面倒なのでその労力を省くことができるので。

426デフォルトの名無しさん2014/11/27(木) 09:51:34.08ID:79rV4D1o
Python「低レベルな争いだな…」

427デフォルトの名無しさん2014/11/27(木) 10:14:33.17ID:29V21Kp8
>>426
ごめん。
PythonにはSmalltalkのそれを凌駕する最強のIDEがそろっているのかもしれないが、
その前にまず言語として隔靴掻痒感が否めなくて使っているとめまいがするのでパス。

428デフォルトの名無しさん2014/11/27(木) 17:17:05.92ID:3JRXUen2
Smalltark 厨 vs Pythonee

429デフォルトの名無しさん2014/11/27(木) 19:38:58.94ID:29V21Kp8
>>428
Unknown variable: Smalltark please correct, or cancel:
define new class
declare global
------------------------------------------------------
Smalltalk
SmalltalkImageTest
SmalltalkEditor
SmalltalkImage
SmallLandColorTheme
SmallInteger
SmallIntegerTest
SMAccount
SMCategory
SMPackageInstallationTask
------------------------------------------------------
cancel

430デフォルトの名無しさん2014/11/27(木) 20:07:16.47ID:p4BAxWMe
Python「ただのテキストエディタで出来そう…」

431デフォルトの名無しさん2014/11/27(木) 20:39:01.35ID:9Juu1ps5
そんなにイデの力が欲しいか

432デフォルトの名無しさん2014/11/28(金) 00:34:41.35ID:O/dyue/E
>>378
ゴロニャーン♪

433デフォルトの名無しさん2014/11/28(金) 09:07:58.51ID:8rVeLSla
>>419
動的型に慣れたら、大量に候補が出るような命名はしないし(凝集度)
typoすら発見できないようなチェッカーなんて使わずにマトモなチェッカーを使う。
あたりまえだろ?

434デフォルトの名無しさん2014/11/28(金) 09:09:59.36ID:8rVeLSla
>>422
なるほど、warningメッセージなんて読まない達人プログラマなんですね、
すごいなあw

435デフォルトの名無しさん2014/11/28(金) 09:13:52.73ID:8rVeLSla
ここまでの流れだと結論は
静的言語は初心者向け
静的言語使いは初心者

436デフォルトの名無しさん2014/11/28(金) 09:59:17.09ID:F5n5vmOV
処理系作ってる連中に学が無いから、型推論できるチェッカーひとつ作れない
で、仕方なく運用(命名規則)で回避ですか

駄目システムに苦しめられてるユーザと同じ図じゃん

なお、大規模開発ではどんな命名規則でもメソッド名が増えるため破綻する模様

437デフォルトの名無しさん2014/11/28(金) 11:02:52.12ID:MpXGAzGF
手元のSmalltalk環境には4万強のメソッドがあって
先にも言われているように、型推論付きとかそんな高尚な補完もないけど
使いたいメソッドが出てこなくて困ったことなんかないぞ。

438デフォルトの名無しさん2014/11/28(金) 17:18:45.17ID:8rVeLSla
>>436
まともな人がちゃんと作れば君のような目にはあわずにすむということじゃないかなあw

439デフォルトの名無しさん2014/11/28(金) 17:21:26.03ID:8rVeLSla
>>436
例えばどんなメソッド名の場合に型推論できないと見つからないんだい?
おもしろそうだから答えてみてよw

440デフォルトの名無しさん2014/11/28(金) 20:56:18.69ID:avPnRbje
>>437
Smalltalkで何作ってるの?
そっちが気になる絶滅危惧言語なんだが

441デフォルトの名無しさん2014/11/28(金) 21:02:53.61ID:pWSxBDFH
>>438
まともな人は遥か昔Smalltalkから逃げ出したし、現在進行形でRubyからも続々と逃げ出してるよね

442デフォルトの名無しさん2014/11/28(金) 23:32:57.83ID:5WZv/pSY
>>440
いろいろやるけど、主にWebアプリだな。

443デフォルトの名無しさん2014/11/29(土) 02:10:12.49ID:TbFyYdBX
>>437
> 使いたいメソッドが出てこなくて困ったことなんかないぞ。

コードを動かさないでだせる?
つまりアプリは動いておらずテキストエディタで書いている時。

コードを動かさないと出せないっていうのがダメなんだよね。
いろんな処理、例えば10分ぐらい処理してやっと実行される関数があったとする。

その関数の中にある条件分岐で真になるときのコード補完はできるだろうけど、
次に偽になる時のコード補完をしようと思ったら10分間待たないといけなくなる。

コードを動かさないでコード補完ができれば、待ち時間なしで
コード補完が出来るわけさ。

444デフォルトの名無しさん2014/11/29(土) 02:28:50.06ID:1aIidqiX
>>443
ごめん。要求仕様^^;がちょっとよくわからなかった。
PythonとかJavaとか>>443がよく知っている言語でいいから、
あと処理の重さは30秒くらいの適当な長さのsleepとかの代替で
どういうコードか書いてみてもらってもいい?

445デフォルトの名無しさん2014/11/29(土) 02:54:05.37ID:SuGYzpy/
>>443
オブジェクトが数値のときは数値関係のメソッドだけ補完に出せとか、そういう条件はあるの?

446デフォルトの名無しさん2014/11/29(土) 04:14:00.96ID:TbFyYdBX
>>444
じゃあJavaScriptで。

// ※aはMyClass型専用
// ただしJavaScriptは動的言語であり、aがMyClassという情報はどこにもない
function foo(a) {
 a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示されて欲しい
}

これがJavaなら
void foo(MyClass a) {
 a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示される
}
これと同じことをJavaScriptでやってほしい。

>>445
そりゃあるでしょw

4474462014/11/29(土) 04:16:18.02ID:TbFyYdBX
当たり前だけど、a. の行にブレークポイントを置いて、
そこまで実行してからa.を出すのはなし。

その行のブレークポイントまで実行しないといけないから
時間がかかる。

448デフォルトの名無しさん2014/11/29(土) 08:00:05.38ID:fWl7Yvk9
>>446
なるほど
メソッド名を1文字も入力できないほど脳が不自由な人なんですね
かわいそうに

449デフォルトの名無しさん2014/11/29(土) 08:16:34.87ID:SO1yCwH9
>>446
MyClassのメソッド一覧ってどれぐらいのサイズ?

Smalltalkのように充実した標準ライブラリを持つ言語だと
Objectクラスだけでメソッドが488個あるから
MyClassのメソッド一覧は少なくとも500個ぐらいになって
aのクラスを特定する意味はあまりないな。

Smalltalkほどクラスライブラリが充実してないプアな言語だと
クラスを特定できるとうれしいかもしれないけど。

450デフォルトの名無しさん2014/11/29(土) 09:19:45.30ID:SuGYzpy/
補完候補が単純なalphabetical orderじゃなくて
使用頻度順を学習して上から並べてくれるやつもあるので
その反論はナンセンスじゃね?
MyClassとObjectでは使われるメソッドの頻度が違うから

451デフォルトの名無しさん2014/11/29(土) 09:23:05.48ID:1aIidqiX
>>446
ちょっと待ってよ。そういう話なの?

俺の理解では、
- 静的型言語は変数を型で縛っているから補完がやりやすい。
- 動的型言語で静的に同レベルを実現するのは理論的に不可能。

ということは議論され尽くされてるわけだから暗黙の了解としてよくて、
- だけど動的型言語でも型推論をしてある程度絞って出せるのはあるよね。
- Smalltalkにはそういうスマートな機能はないけど、あんまり困ったことないよ。

という流れがあったところに>>443 で、
- 実行はせず、テキストエディタで編集中のコードで問題なくメソッドは出せるのか?

ときたから、意図がよくわからないのでコードを示してくれと頼んだら、
- 実行をして a をを確定してからその情報を元にして補完をするのはナシで、
 静的型言語と同じように a の関連のメソッドだけしぼって出してみろ!

という要求だったので非常に驚いている。←イマココ

452デフォルトの名無しさん2014/11/29(土) 09:26:19.46ID:SuGYzpy/
標準ライブラリの大きさとObjectに数百個程度のメソッドがあることの
関係も良くわからない

標準ライブラリに少なくとも数百個もメソッドがあるんだぜスゲーってこと?

453デフォルトの名無しさん2014/11/29(土) 09:40:43.18ID:e6ORUEwd
>>449
> MyClassのメソッド一覧は少なくとも500個ぐらいになって
そんなもん、クラス直接のメソッドと
継承元のメソッドぐらい分けて表示するに決まってるだろ・・・。

454デフォルトの名無しさん2014/11/29(土) 09:50:35.80ID:SuGYzpy/
でも>>446をよく見たら、こんなお題だったのか

> function foo(a) {
> a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示されて欲しい
> }

これは静的型付言語で型推論があっても補完は無理だw

455デフォルトの名無しさん2014/11/29(土) 10:17:11.39ID:e6ORUEwd
これなら型補完できるよ。これが静的言語でしょ?

> これがJavaなら
> void foo(MyClass a) {
>  a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示される
> }

456デフォルトの名無しさん2014/11/29(土) 10:31:13.38ID:SO1yCwH9
>>453
へー、継承元のメソッドを分けて表示すれば解決する程度の貧弱なクラスライブラリが前提なんだー(鼻ホジホジ

457デフォルトの名無しさん2014/11/29(土) 10:34:40.20ID:7EP7sx63
>>442
商用で?
Smalltalkの処理系は?

458デフォルトの名無しさん2014/11/29(土) 10:35:24.90ID:SO1yCwH9
静的言語でやっているコーディングとかIDEの使い方をそのまま動的言語に持ち込んで「これができない」「あれができない」と喚きだす初心者を眺めるスレw

459デフォルトの名無しさん2014/11/29(土) 10:36:42.17ID:SO1yCwH9
>>457
そういう話はSmalltalkスレでどうぞ

Smalltalk総合 Squeak Pharo
http://peace.2ch.net/test/read.cgi/tech/1360991429/

460デフォルトの名無しさん2014/11/29(土) 10:39:51.40ID:e6ORUEwd
>>456
お前バカだろw
Objectにメソッドが多すぎて邪魔って話をしてるんだが。

461デフォルトの名無しさん2014/11/29(土) 10:40:48.12ID:e6ORUEwd
>>458
まあそうだね。あれができないこれができない。
たしかにそうだ。実際に出来ないもの。

で、そ、そんなのいらないんだから!
と言い返すw

462デフォルトの名無しさん2014/11/29(土) 10:57:41.26ID:MSvzZpAh
技術的には型推論と補完を両立できるかどうか考えればいいと思うけど
ここで悪足掻きしてるやつは技術より心理にこだわっているふしがある
補完よいよねというマインドをつくることしか考えてない

463デフォルトの名無しさん2014/11/29(土) 11:10:26.37ID:x5tELjcp
普通にいいだろw.
補完ができれば、それを応用して
さらにいろんなことができるようになるわけだし

464デフォルトの名無しさん2014/11/29(土) 11:16:43.56ID:SO1yCwH9
>>462
補完うんぬんは「静的型いいよね」というマインドのための道具でしかないでしょw

465デフォルトの名無しさん2014/11/29(土) 11:17:30.03ID:7EP7sx63
>>459
そんなこと言ったらこのスレが成り立たないだろ。
独立言語スレはSmalltalkだけじゃないぞ。

動的言語に貴賎はない、、、はず。

466デフォルトの名無しさん2014/11/29(土) 11:17:56.66ID:MSvzZpAh
>>463
補完するスタイルと補完しないスタイルの二種類があれば
一種類よりも多くのことができる

467デフォルトの名無しさん2014/11/29(土) 11:44:56.39ID:SuGYzpy/
補完するときにメソッド名を選択すると、引数や戻り値の型やドキュメントが
出てくれるのは凄く嬉しい

あと同じ機能を使うと、メソッドにカーソル当てたらドキュメントを出せるようになるから
コード読むのが捗りまくる

468デフォルトの名無しさん2014/11/29(土) 11:56:50.41ID:x5tELjcp
出来るできないで考えるからわからない。
どちらが楽にできるかどうかで考えよう。

そしてただ単に楽にできるかで考えるのもダメ一体何が楽ができるか。
つまり、書くのが楽か、読むのが楽か。

どちらを重視すべきかというと、書くよりも読むことが楽になるようにするべき。
なぜならプログラミングの作業の多くは書こに書いたコードを読んで修正することだから。

そういう時に、この変数は○○型であると書いてある方がいいわけだよ。
コメントに書くこともできるがそれだと実際のコードとコメントが
一致していない可能性がある。

コメントを書くよりも、コードでそれを表現するべき。
そうすれば人間もコンパイラも理解できる。

静的型がいいのは、そういう読むときの開発効率の高さにある。

469デフォルトの名無しさん2014/11/29(土) 11:59:47.15ID:x5tELjcp
なお、コード補完は、書くことを楽にしてくれる、
つまりタイピングを補助するものだと勘違いしている人が多いが、
実際は読むことを楽にしてくれている。

つまり、このオブジェクトにはどんなメソッドがあって、
そのメソッドがどんな機能、引数、戻り値を提供しているか
ということを確かめるために、ドキュメントやコードを
読むことを楽にしてくれる。

だから適切な補完が重要になる。
多すぎることもなく少なすぎることもなく
間違えることもない補完が重要。

470デフォルトの名無しさん2014/11/29(土) 12:11:58.32ID:nAAws2G7
>>446
ご説ごもっとも。
だから、こんな可哀想な動的大好き人間は放っておいて
静的型言語まんせースレに行って幸せを満喫してください。

>>462
型推論で静的解析が可能だとして
動的型として失うものはないのだろうか。
そういう議論なら有意義だと思う。

471デフォルトの名無しさん2014/11/29(土) 12:30:14.99ID:v2v5Wnkr
それ以前にさ、動的型付きとして
失ってほしくない機能って何さ?
失っても対して問題ない機能ばかりだと思うだが。

472デフォルトの名無しさん2014/11/29(土) 12:44:23.44ID:A4nuaoXO
標準ライブラリや他人の作ったライブラリの全てを記憶できる変態でも無い限り
コード補完によってドキュメントを含め表示して選択出来るってのは生産する
上ではかなりのアドバンテージなんだけどね。 大昔のクソなIDEや最近のでも
動的言語に対応しているのはクソなIDEしかないから、そういう技術の進歩を
知らない原始人には理解できないことなんだよ。

473デフォルトの名無しさん2014/11/29(土) 12:49:43.77ID:v2v5Wnkr
動的型付きにすることで失われていることのほうが多いと思う。
それで、動的型付きにしてまで守ろうとしているものってなに?

474デフォルトの名無しさん2014/11/29(土) 13:13:21.80ID:MSvzZpAh
ドキュメントについては仕様書が欲しいか具体例が欲しいかによる
ただちに必要ではないことまで書かれているのが仕様書
ある時点で必要だったことしか書かれていないのが具体例

具体例から仕様を想像できるような変態は全てを記憶ではなく推理している

475デフォルトの名無しさん2014/11/29(土) 13:24:38.99ID:U5ivpV2C
スタートダッシュと試行錯誤じゃないの
軌道に乗ったら捨てて作りなおせばいいのよ

476デフォルトの名無しさん2014/11/29(土) 13:24:42.22ID:7EP7sx63
>>472
コード補完で出てくるドキュメントなんて知ってるメソッドなら役に立つが
知らないメソッドをそれだけでなんとかしようなんて無理だがや

477デフォルトの名無しさん2014/11/29(土) 13:54:58.03ID:A4nuaoXO
>>476
javaならソースに書かれているjavadocが出る。いわゆるAPIリファレンスと
言われるものが表示される。visual stadioだとmsdnに書いてあるのが出る。
APIリファレンスが役に立たないとか言っちゃうような無能はプログラムを
書くのを辞めたほうがいい。

javadocが出たことによって他の言語でもソースに埋め込んだコメントを
別ドキュメントに言語の標準かそれに近いレベルで提供されることが多く
なった。ただ別ツールを使ってまでドキュメントを出力するようなところは
殆ど無かったけど、IDEで自分や他人の書いたドキュメントまで手元で
参照できるようになったことで、どのレベルでコメントを書けばよいうかと
いうことに気づけた人はそれなりにいるかと思う。

書かないと煩く言われるから書くというのから、自分で書いたコードでも
元のコードを見なくても分かるように書くというのに変われた人は多いと
思います。最低でも自分で書いたコードを自分の為にというのがやり
やすくなった。

478デフォルトの名無しさん2014/11/29(土) 14:00:18.54ID:A4nuaoXO
そういえばvisual studioだとサンプルコードを検索ダウンロード出来る機能まで
付いたんだっけかな。

479デフォルトの名無しさん2014/11/29(土) 14:06:58.21ID:7EP7sx63
>>477
javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
サマリーだけじゃ役に立たんがね。

IDEで出るのはあくまでも補助的なもんで、ちゃんとしたAPIのドキュメントは
msdn見ないと駄目だろ。APIの注意書きとかサンプルコードとかはIDEでは出ないだぎゃー

最近のVisual Studioは、msdnの全文が出るんけ?
底辺土方なんで最新版は知らんのじゃ〜

480デフォルトの名無しさん2014/11/29(土) 14:07:50.21ID:7EP7sx63
>>478
マジか?
随分と進歩したもんじゃの

481デフォルトの名無しさん2014/11/29(土) 14:13:44.81ID:v2v5Wnkr
>>479
> javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
> サマリーだけじゃ役に立たんがね。

サマリーでも役に立つと思うし、リンクになってるから
ヘルプ調べるのも速くなるんだが?

482デフォルトの名無しさん2014/11/29(土) 14:25:05.29ID:7EP7sx63
>>481
そういうIDEのヘルプ機能よりもGoogle先生のが役に立つ
Google先生とIDEのインテリセンスが無いとプログラムの生産性が著しく落ちるw

483デフォルトの名無しさん2014/11/29(土) 14:33:59.73ID:A4nuaoXO
>>479
ttp://docs.oracle.com/javase/8/docs/api/index.html
どのレベルも何も↑の各クラス、メソッドのがそのまま出るんだが。
これは英語だが、日本語訳のがある場合はそっちを使うことが出来る。
で、ここに書かれていなくて他に書かれているというドキュメントは存在しない
わけで、ググってどこにも無ければこれに頼るしか無い。 このリファレンスが
分からない役に立たないっていうやつは少なくてもjavaはやらないほうがいい。

484デフォルトの名無しさん2014/11/29(土) 14:36:32.05ID:v2v5Wnkr
>>482
初心者に多いね。一次ソースを見ないで、
個人のブログとかみるやつ。
英語読めないからとかなのかな。

485デフォルトの名無しさん2014/11/29(土) 14:37:24.55ID:v2v5Wnkr
で、そんな話はいいとして、動的型付け言語が
動的型付けにしてまで守ろうとしているものって何よ?

486デフォルトの名無しさん2014/11/29(土) 14:38:14.93ID:Tl+PW+FS
動的言語でも変数aをMyClass型と教えればメソッド一覧は出せるだろ

487デフォルトの名無しさん2014/11/29(土) 14:39:37.78ID:v2v5Wnkr
>>486
それで、aがMyClassだっていうのは、
人間がいちいち教えてあげるの?

aが絶対MyClassだっていうのなら
それをコードに書いておけばいいのに・・・。

488デフォルトの名無しさん2014/11/29(土) 14:40:07.50ID:SO1yCwH9
その問い自体が静的目線だってのw
視野が狭いなあw

489デフォルトの名無しさん2014/11/29(土) 14:40:46.54ID:Tl+PW+FS
いちいち変数を宣言して型を指定するのとかわらないと思う

490デフォルトの名無しさん2014/11/29(土) 14:42:05.95ID:v2v5Wnkr
その都度、MyClass型って教えないといけない手間がかかるのと
コードに仕様として書いておけるのの違いだね

491デフォルトの名無しさん2014/11/29(土) 14:42:13.42ID:SO1yCwH9
補完候補を500に絞り込むためだけに、aがMyClassのインスタンスでないと動かないような腐れコードにするわけか
ご苦労さまなこってw

こりゃ世の中からクソコードがなくならないわけだw

492デフォルトの名無しさん2014/11/29(土) 14:43:48.06ID:v2v5Wnkr
> 補完候補を500に絞り込むためだけに
補完候補を500ってなんのこと?
動的型付けだと、その500を全て覚えてるの?
意味がわからないね。

493デフォルトの名無しさん2014/11/29(土) 14:45:30.32ID:TZOpdCpR
型を書かなくても a = MyClass() や、さらにいえば
foo(MyClass()) のようなコードがあるだけでも>>446は補完できる様になる

494デフォルトの名無しさん2014/11/29(土) 14:46:28.99ID:v2v5Wnkr
逆に言えば、そういうコードがなければ
補完できないという意味である。

例えば関数の引数。これは補完できない。

495デフォルトの名無しさん2014/11/29(土) 14:48:16.54ID:Tl+PW+FS
補完ってそこまで重要か
動的言語支持者の揚げ足をとるためには必要かもしれないけど
単語単位補完で十分通用してる

496デフォルトの名無しさん2014/11/29(土) 14:49:08.68ID:v2v5Wnkr
型を書かなかったら a = MyClass() と a =YourClass()の両方があったら
補完がめちゃくちゃになる。
foo(MyClass()) と foo(YourClass()) のようなコードがあると
>>446の補完は使い物にならなくなる。

497デフォルトの名無しさん2014/11/29(土) 14:51:15.51ID:v2v5Wnkr
>>495
> 補完ってそこまで重要か

重要ですよ。

開発効率がぜんぜん違う。

・タイプ数の省略
・うろ覚え(引数の順番程度)でヘルプを引くことの省略
・ヘルプを開く場合でもその手間の省略
・コードのミスを実行せずに知ることが出来る
・リファクタリング時に自動で安全にできることが多くなる。

これらはいらないんだ!って言うかもしれないが、
それは開発効率が大きく高まることを否定する言葉じゃないからね。

498デフォルトの名無しさん2014/11/29(土) 14:54:43.83ID:TZOpdCpR
>>494
引数に型が書いてなくても、実際に関数を使ってるコードがあれば
引数に入れられた値から型推論できるよねって話なんだけど

499デフォルトの名無しさん2014/11/29(土) 14:55:43.43ID:rjWp6DMr
単語単位補完って、単にタイプ数を
少し省略することしかできないからね。
しかも補完した結果が間違っていることがある。

動的型付けにおける補完の効果って
その程度しかできないし、その程度のことしか知らないから
静的型付け言語でもその程度のことだと思ってる人が多いんだよ。

ぜんぜん違う。静的型付け言語であれば補完は
タイプ数削減以上に大きく開発効率を上げることが出来る。

明らかに開発効率を上げると証明された。
動的型付けで開発効率を上げることは出来るのか?
動的型付けにしてまで守ろうとしているものはなんなのか?

500デフォルトの名無しさん2014/11/29(土) 15:00:38.05ID:rjWp6DMr
>>498
いや、だからなければ型推論できないでしょ。
「実際に関数を使ってるコード」の方が間違っていたら
補完も間違うわけよ。foo(MyClass())って使わないといけない時に
foo(YourClass())って書いてしまったら、補完もそれに合わされてしまう。

それにさ、人間の問題はどうなるのさ?

function foo(a) {} ってコードをいきなりみせられて
aは何型でしょう? ってクイズ?(笑)

リーダブルコードってわかるかな?
ライタブルコードってはいわないんだよ。

重要なのは読む時。読む時に必要な情報が欠けてる。
もしくは間違ってる。そんな信用出来ない状態では開発効率は大きく下がるよね。

で、動的型付け言語は開発効率下がると証明されたが
あがる理由は何かあるのか?

501デフォルトの名無しさん2014/11/29(土) 15:11:36.58ID:TZOpdCpR
>>500
それは void foo(YourClass a) って間違えても同じだよね

それにクイズってなんの話?IDEがあればドキュメント見れるでしょ?

502デフォルトの名無しさん2014/11/29(土) 15:14:22.47ID:Tl+PW+FS
動的言語の方がコード量が減るから大規模になりにくい
短期記憶に入りやすいから効率も上がる
静的に見て機械的に処理しやすいのは静的片付け言語だけど

503デフォルトの名無しさん2014/11/29(土) 15:14:41.06ID:HSRgXQQV
> それは void foo(YourClass a) って間違えても同じだよね

定義は一箇所。

使う場所は沢山。

一個でも間違えたらどちらが正しいかわからなくなる。

504デフォルトの名無しさん2014/11/29(土) 15:16:15.20ID:HSRgXQQV
>>502
> 動的言語の方がコード量が減るから大規模になりにくい

重要なのは、タイプ量ではなくて読む量なんだよ。

動的言語のコード量が減るってようするに、
コードを理解するための情報が減るから
コードが読めなくなる。

少なければいいってもんじゃないんだよ。

505デフォルトの名無しさん2014/11/29(土) 15:17:16.14ID:Tl+PW+FS
少なければいいよ
機械がコードを読み書きするんじゃなくて人がするんだから

506デフォルトの名無しさん2014/11/29(土) 15:18:12.01ID:TZOpdCpR
>>503
型検査でエラーになるから分かるでしょ

エラーにならないならMyClassとYourClassは型レベルで互換性あるってことだし

507デフォルトの名無しさん2014/11/29(土) 15:20:19.64ID:HSRgXQQV
動的型付け言語では、コードを理解するための情報(定義)が減って、
実行するコード自体の量は静的型付けでも動的型付けでも変わらない。

たとえて言うならば、
文章の枠外にある注釈を書いているのが静的型付け言語で
同じ文章でありながら、枠外の注釈を取り除いたのが動的型付け言語

注釈があればいきなり変数が出てきても、これは○型だってわかるが、
注釈がなければ、この変数に値入れてるのどこだよ。
この関数を使ってるのはどこだよと

注目して呼んでいる所以外の情報を探してこなければいけない。

508デフォルトの名無しさん2014/11/29(土) 15:22:35.61ID:MSvzZpAh
>>503
これは面白い
頻度が少ない方に権威があるという不思議なルール

509デフォルトの名無しさん2014/11/29(土) 15:24:39.97ID:HSRgXQQV
>>506
無理だよ。

例えばMyClassにhogeというメソッドがあって、YourClassには無いとする。

これをfoo(MyClass()) と foo(YourClass())に渡した所でエラーにならない。
fooの中でhogeを呼び出しているから、YourClassを渡している所が間違いだ!と
思いきや、

動的にYourClassにhogeメソッドを追加するかもしれないから
エラーとは言い切れない。

つまりエラーと出る箇所はすべて、エラーではないかもしれない。

510デフォルトの名無しさん2014/11/29(土) 15:26:57.07ID:HSRgXQQV
>>508
そりゃそうだろw

たった一回気をつけてかいたものと何十回も書いたもの、
どちらが間違えやすいかなんて考えるまでもない。

511デフォルトの名無しさん2014/11/29(土) 15:37:19.95ID:TZOpdCpR
>>509
動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ
さらにmethod_missingが定義されてる時はワーニングを出さないという工夫もできる

512デフォルトの名無しさん2014/11/29(土) 15:44:49.77ID:TZOpdCpR
動的にメソッドを追加するケースは少ない => 補完や型検査は動的言語でも有効
動的にメソッドを追加するケースが多い => 動的言語って凄く便利だね

513デフォルトの名無しさん2014/11/29(土) 15:49:50.99ID:HSRgXQQV
>>511
> 動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ

俺がいいたいのはそれだよ。動的にメソッド追加されるケースは多くないのに
そのために多くのメリットを捨てるだけの意味が動的型付け言語にあるのかってこと。

514デフォルトの名無しさん2014/11/29(土) 15:58:27.80ID:SO1yCwH9
>>497
>・タイプ数の省略

つまりタイプ数を省略するために
オブジェクトが持つメソッド数が僅かしかないような
ゴミみたいなライブラリを使わされるのはいやだなあ

>・うろ覚え(引数の順番程度)でヘルプを引くことの省略

補完以外にもいろいろな手段があるが?

>・ヘルプを開く場合でもその手間の省略

補完以外にもいろいろな手段があるが?

>・コードのミスを実行せずに知ることが出来る

実行すればわかることを、いちいち型として書いた上に
コードに余計な制約をつけるなんて愚の骨頂だろw

>・リファクタリング時に自動で安全にできることが多くなる。

くだらない。リファクタリングが始まったのは動的言語からだし、
リファクタリングをIDEの機能に統合したのも動的言語から。
で、補完を使うことで、可能なリファクタリングが増えるなんて初耳なんだが?

やはり静的脳で動的言語を見て「あれが欠けてる」「これが欠けてる」と言っているだけだねw
まずは自分の視野の狭さをなんとかしたら?

515デフォルトの名無しさん2014/11/29(土) 16:02:07.42ID:SO1yCwH9
補完君の要約
「ぼくがジャバでプログラムを書くのと同じやり方ができない動的言語なんて使えない」

516デフォルトの名無しさん2014/11/29(土) 16:55:08.72ID:SO1yCwH9
補完君の最大の勘違いは、
動的言語はa.と入力して出てくるメソッド名を絞り込めない
と思い込んでいること。

実際には、動的言語ではa.と入力して出てくる膨大なメソッド名の
どれでも正当なプログラムを構成し得る。
だからその膨大な候補リストは既に十分絞り込まれたもの。

ただ、静的脳の小さな容量では言語のポテンシャルが高すぎて
マトモに使いこなせない。かわいそうに。

517デフォルトの名無しさん2014/11/29(土) 20:03:41.93ID:o/hS6qzS
補完必須派に訊きたいんだけど
コンパイル時ダックタイピングともいわれる構造部分型
http://igeta.cocolog-nifty.com/blog/2008/05/subtyping.html
をサポートする静的型言語のときは、どういう候補を出すのが正解?

これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。

518デフォルトの名無しさん2014/11/29(土) 21:05:19.38ID:7EP7sx63
>>484
オレオレOOなヤツに多いね。
自分の足りないオツムと一次ソースだけでプログラミングするやつw

個人ブログとかStackOverflowから良いコードがあればパクるのが良いねえ。
もちろん後から一次ソースで確認はする。
オレ様のゆるいオツムでは思いつかないようなクールなコードが世の中には沢山あるぞw

519デフォルトの名無しさん2014/11/29(土) 22:22:32.23ID:fN3BW3ns
>>514
リファクタリングでできることは
静的型付け言語の方がとっくに多くなってるんだよ。

始まったのは動的型付けからって
単に懐古厨なだけだろ。昔はなってw

最新のリファクタリング技術がどうなっているかを知ると驚くぞ。
http://nanananande.helpfulness.jp/wp-content/uploads/sites/2/2014/06/3164/1b000175b814e923b2ddeebcadbf4154-159x300.png

それに対して動的型付けの話って
昔の話しか出てないだろ。

520デフォルトの名無しさん2014/11/29(土) 22:25:49.85ID:fN3BW3ns
>>516
> 補完君の最大の勘違いは、
> 動的言語はa.と入力して出てくるメソッド名を絞り込めない
> と思い込んでいること。

なにマッチ・ポンプしてるんだよw

静的型付け言語では最初から絞り込めるよな?

で、動的型つけ言語は500もメソッドが出る。(ドヤっ)
そんなにたくさん候補が出たら大変だろ!(ドヤっ)

って言っておいて、今度は、

動的型つけ言語でも絞り込める時もある(ドヤっ)

ですかw

うん、大変だね。静的型付け言語では最初から絞り込めるよ?

521デフォルトの名無しさん2014/11/29(土) 22:48:51.18ID:SuGYzpy/
>>520は勘違いしているよ

>>516が言っているのは、数値オブジェクトに対して
文字列のメソッドを呼び出して実行時エラーになっても、
それは言語仕様上は正当なプログラムであるということだよ

もちろん言語仕様上正当であることは、バグじゃないことを意味しないけどね
オブジェクトの型に無関係なメソッド呼び出しは大抵バグだろう

522デフォルトの名無しさん2014/11/30(日) 00:47:09.72ID:mFsly3WX
>>517
>これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。

なぜ構造的部分型が補完の指標になりえるのか、
その理由というか関連性が説明してごらん
単なる思いつきじゃねえの?

少なくとも >>517 のリンク先blog記事では
「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
と主張しているけど、こんな奇妙な話は聞いたことが無い
しかも記事のネタになったソース(学術的文献)が書かれていないし、
英語版 Wikipedia の Subtyping のページでも
duck tying との関連性に対する文章に対して "citation needed" と指摘されている
おまけに記者は構造的部分型付けをサポートする言語(OCaml)を使った事が
一度も無いと正直に告白している

このblog記事はあくまで記者が型システムを勉強する過程で書き残したノートであって、
この記事を引用して >>517 が何を言いたいのか、自分には意味不明だね

なお、動的型付け言語に(形式的な型推論を基礎とした)静的型付けを導入した概念は
Soft Typing と呼ばれている
動的型付け言語の補完を検討する指標となる可能性があるのは、
どちらかといえば Soft Typing ではないかと思うね

5235222014/11/30(日) 00:49:19.68ID:mFsly3WX
細かいけど訂正

X: その理由というか関連性が説明してごらん
O: その理由というか関連性を説明してごらん

524デフォルトの名無しさん2014/11/30(日) 00:51:32.07ID:uxHSis3U
ガアガアとなく人間は
アヒルである。

ダックタイピング

525デフォルトの名無しさん2014/11/30(日) 01:04:21.57ID:360iudbJ
>>519
昔の時点ですでに相当できてたって話もあるぞ。

http://web.archive.org/web/20090130061934/http://www.refactory.com/RefactoringBrowser/Refactorings.html

526デフォルトの名無しさん2014/11/30(日) 01:17:26.21ID:uxHSis3U
>>525
同じぐらい"昔"である2009年の記事出していい?Eclipse+Javaの世界の話
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/

527デフォルトの名無しさん2014/11/30(日) 09:02:17.22ID:360iudbJ
>>526
すまん2001年の登場当初のを貼るつもりだった。

http://web.archive.org/web/20010514165503/http://www.refactory.com/RefactoringBrowser/Refactorings.html

528デフォルトの名無しさん2014/11/30(日) 09:53:30.32ID:uRzHHhxu
520を読むと516が言う通り補完君は動的型がまるでわかってないことが明白だ

529デフォルトの名無しさん2014/11/30(日) 10:04:13.86ID:uRzHHhxu
補完君はキーを2,3文字入力するのをケチるために
引数がMyClassのインスタンスでなければ動かないゴミメソッドにして
どうだ静的型すごいとか言い出す初心者でしょ

530デフォルトの名無しさん2014/11/30(日) 10:27:25.19ID:uRzHHhxu
静的型は自転車の補助輪
初心者を卒業したら外そうね

531デフォルトの名無しさん2014/11/30(日) 10:46:49.86ID:/BRxH/wW
>>529
もうちょっと汎用的なメソッドを定義する場合、MyClassみたいな具象型よりも
Interfaceや型クラスを指定することが多いね
それで必要なだけの汎用性と静的型を両立できる

532デフォルトの名無しさん2014/11/30(日) 10:59:52.11ID:c9Q+Jt/4
大規模開発で人に作らせる立場だと、プログラマに静的言語という拘束具をつけた方が楽なんだよ。チームメンバの能力によって品質が変わってはいけないし。
人を指導する立場に立ってみると分かる。

533デフォルトの名無しさん2014/11/30(日) 11:21:16.72ID:rR9TrKjV
でも静的型を嫌がってたらGoogleとかでは働けないわけじゃん?
お前らどんな底辺企業で働いてるの?
それともニート?

534デフォルトの名無しさん2014/11/30(日) 12:03:38.55ID:360iudbJ
>>522
structural subtyping と duck typing の対比なんていくらでも目にするだろう。

535デフォルトの名無しさん2014/11/30(日) 13:49:35.58ID:kUIpsKvT
>>527
じゃあ同じように2001年という "大昔" の話をするね。
http://www.ibm.com/developerworks/library/eclipse/l-eclipse.html
Refactoring with Eclipse
Erich Gamma is the team lead for Java tools for Eclipse.
Gamma was one of the Gang of Four known for creating
the book Design Patterns: Elements of Reusable Object Oriented Software.
He also created JUnit with Kent Beck (see Resources).
Refactoring is recognized as another valuable practice in object oriented programming but,
until recently, only few tools had support for it. At OOPSLA 200,
Eclipse developers demonstrated the Refactoring support in Eclipse.
They stressed that refactoring should not alter a program's behavior.

536デフォルトの名無しさん2014/11/30(日) 13:52:53.51ID:kUIpsKvT
>>532
> プログラマに静的言語という拘束具をつけた方が楽なんだよ

どういう点が拘束具なの?

間違える行動ができない。という意味での拘束?
それはいいことじゃんw

537デフォルトの名無しさん2014/11/30(日) 14:03:15.99ID:+4cKqP8L
>>530
シートベルトだよ
離陸と着陸の時以外は外しても困らんかも知れんけど

538デフォルトの名無しさん2014/11/30(日) 14:13:11.05ID:kUIpsKvT
別に何も拘束されてないけどなw

単にコードが読みやすくなるだけ。
人とコンパイラにとって可読性が高いコードになる。

可読性が高いから理解しやすく、理解した情報を使って
バグが少なく開発のサポートができるようになるわけ

539デフォルトの名無しさん2014/11/30(日) 15:35:01.93ID:/BRxH/wW
REPLとかで「このオブジェクトって何ができるんだっけ?」って調べるのは
動的言語では典型的な開発手法で、恩恵に預かってる開発者は多いと思うけど
静的型の補完も一緒だよ
単純にタイプ数をちょっと減らすとか、そういう話じゃない

540デフォルトの名無しさん2014/11/30(日) 15:37:46.89ID:qocW+y5a
何のメソッド使うか分かってるんならヘボい補完でも十分じゃね?

541デフォルトの名無しさん2014/11/30(日) 15:58:11.94ID:rR9TrKjV
全部把握できる程度のチープなライブラリを使って
一人で小さなプログラムを開発するなら
ヘボい補完でも十分じゃね?

542デフォルトの名無しさん2014/11/30(日) 16:11:04.82ID:UnYKruMf
>>540
Cくらいならともかく、ライブラリは肥大化の一方なわけで有限の記憶力を
ライブラリの引数や戻り値を完璧に覚えるより別の方に振り分けたいと思う
人も少なくないんですよ。

543デフォルトの名無しさん2014/11/30(日) 16:19:35.18ID:360iudbJ
>>535
わかった。では1999年ではどうだ?

Remove Class
Rename Class
Remove Instance Variable
Rename Instance Variable
Abstract Instance Variable
Create Accessors for Instance Variable
Remove Class Variable
Rename Class Variable
Abstract Class Variable
Create Accessors for Class Variable
Remove Method
Rename Method
Add Parameter to Method
Remove Parameter from Method
Rename Temporary
Inline Temporary
Convert Temporary to Instance Variable
Extract Code as Temporary
Extract Code as Method
Convert Superclass to Sibling
Inline Call
Push Up/Down Method
Push Up/Down Instance Variable
Push Up/Down Class Variable
Move Method to Component
Convert Instance Variable to ValueHolder
Protect Instance Variable
Move Temporary to Inner Scope
http://twiki.cin.ufpe.br/twiki/pub/SPG/WeeklySeminar/PracticalAnalysisForRefactoringDonRoberts1999.pdf

544デフォルトの名無しさん2014/11/30(日) 16:33:33.88ID:/BRxH/wW
>>543
静的型と動的型で同じ「Rename method」というリファクタリング機能をサポートしていると言っても、
動的型のそれは http.connect のメソッド名を変更したら
無関係な db.connect のメソッド名も変わってしまうような代物だろう

545デフォルトの名無しさん2014/11/30(日) 16:45:52.62ID:ZfpKb0dS
>>544
それは人間が頑張ればいいだけの話だろ。
手抜きするな。努力しろ。

546デフォルトの名無しさん2014/11/30(日) 16:52:19.04ID:+4cKqP8L
動的言語における効率とは「問題の棚上げ・先送り」と表裏一体であり
問題の発見・防止が重視される大規模開発とは真逆の志向である

547デフォルトの名無しさん2014/11/30(日) 16:54:52.49ID:360iudbJ
>>544
そんなことをする馬鹿にはリファクタリングツールの使用はお勧めできない。

548デフォルトの名無しさん2014/11/30(日) 16:58:31.17ID:rR9TrKjV
>>547
一番のバカは使い物ならないツールを作ってる動的言語の連中だな

549デフォルトの名無しさん2014/11/30(日) 17:02:44.20ID:UnYKruMf
>>545
人間が頑張らなくてもいいようにツールは進歩しているのですが?
頑張らなくなって良くなった分、他にリソースを回すとか考えられないんだろうな。

550デフォルトの名無しさん2014/11/30(日) 17:04:54.56ID:qFjB73Ro
コンピュータにやらせるなんてアホ
脳が腐る。
人間がシコシコ変換するることで
ボケが防止される

551デフォルトの名無しさん2014/11/30(日) 17:10:09.29ID:7WEYW95R
>>546
そうなんだよね。結局問題を先送りしてるだけ。

だいたいさ、コードの中でこの変数(httpとか)は
connectを呼び出しているって書いているから
この変数はconnectを持っている型だって決まってるわけだよね。

動的型付けであっても、型は決まってる。

だからそのことをコードに書いておけばいいわけよ。
それが変数の型宣言というもの。

型宣言しておけば、コードとその型に矛盾が起きるような修正が
発生した時、それをすぐにコンピュータが検出できる。
検出した問題を人間がみた時にも、すぐにその原因がわかりやすい。

どうせコードでは型は特定の型じゃないと動かないんだから
その型であるって明示しておけばもっと便利になる。

動的型付けでは不可能なレベルの完璧な補完っていうのも
その高度なコード解析能力の一端にすぎないんだよ。

552デフォルトの名無しさん2014/11/30(日) 17:23:36.91ID:360iudbJ
>>548
くやしいのうwwwくやしいのうwww

>>551
否定はしないけれど、視点の違いとか「ものは言いよう」という側面もあるな。

「真のソフトウェア工学が開発されるまでの次善の策は、
 あらゆる要素について極端に遅延結合な動的システムを使って開発する事だ。」
http://metatoys.org/oxymoron/oxymoron.html

553デフォルトの名無しさん2014/11/30(日) 17:25:33.97ID:tVFfE2xZ
まあ中規模くらいなら動的言語の気楽さ>静的言語の堅牢性だけど
大規模になって全体のコードを把握できなくなると気楽さ<堅牢性になるよね

554デフォルトの名無しさん2014/11/30(日) 17:37:33.47ID:7WEYW95R
>>552
動的と動的型付きは違うからね。

そもそもコードが「静的に型付きされているのと同様」に
特定の型じゃないと動かないように書かれているわけで。

555デフォルトの名無しさん2014/11/30(日) 17:40:58.65ID:7WEYW95R
>>552
その頃言われていた「遅延結合」っていうのは、
遅延ではない結合、つまり特定の型以外には結合しないという意味で
それを解決したのが、継承やインターフェースでしょう。

継承やインターフェースは、指定した型+その型を継承したもの
(もしくはインターフェースを持っているもの)に
動的に結合しているわけで、遅延結合になっている。

556デフォルトの名無しさん2014/11/30(日) 17:41:53.12ID:guVElZZq
静的言語だとテスト工数が減るとか、動的言語だとテスト工数が増えるとかあるの?

557デフォルトの名無しさん2014/11/30(日) 17:47:36.29ID:7WEYW95R
>>556
コンパイルエラーをミスと考えるかバグと考えるかで話が違う。

テストはバグを見つけるもの。
だから普通はコンパイルエラーによるミスは
テストで見つけるものではない。

だから本当の意味でのテストの量は同じだが、問題はミス。

静的型付け言語ならミスは、ミスとしてテストの前段階で弾くことができるが、
動的型付け言語だと、テストの段階で弾くことになる。
(しかも静的型付け言語ならミスは修正箇所をコンピュータが示すから素早く解決できるが、
動的型付け言語だとバグを探すのと同じ作業をしないといけなくなる)

そういう点で、動的型付け言語ではテストでやるべきことが
増えるのでテスト工数が増えることになる。

558デフォルトの名無しさん2014/11/30(日) 18:12:40.43ID:c9Q+Jt/4
>>536
制約だな。

559デフォルトの名無しさん2014/11/30(日) 18:24:06.55ID:7WEYW95R
>>558
それを言うなら、契約って言ったほうがかっこいいな。

契約プログラミングといえば、EiffelとD言語ぐらいだけど、
型っていうのもある意味契約だからね。

この引数は、○型であるという事前条件
この関数は、○型を返すという事後条件

560デフォルトの名無しさん2014/11/30(日) 18:24:17.69ID:uRzHHhxu
なんだ
このスレの静的厨は静的型が制約だということも理解せずに喚いてたのか
初心者としても筋が悪いな

561デフォルトの名無しさん2014/11/30(日) 18:25:23.77ID:tHR3Cg3X
ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの?
template<typename T> void f(T func)
みたいないわゆるダックタイピング

562デフォルトの名無しさん2014/11/30(日) 18:26:57.46ID:mFsly3WX
>>534
Static Typing vs. Dynamic Typing という対比はよく見かける
しかし structural subtyping vs. duck typing という対比は知らないね
もし「いくらでも目にする」のなら、ソース(学術的文献)を示せばいい
簡単な事だろ?

ましてや
> 「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
>「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
なんて奇妙な主張は聞いたことが無い

blog記事を批判するつもりはないが、そんな個人メモを元にして
「動的型言語の補完がどうあるべきかの指標になる(>>533)」と主張するのは
馬鹿だってこと

563デフォルトの名無しさん2014/11/30(日) 18:31:27.03ID:7WEYW95R
>>561
> ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの?

┃ template<typename T>┃ void f(T func)
↑ ここからここまでが、型 ↑

HOGE_T void f(T func)

置き換えるならこんなふうに捉えてる。

> みたいないわゆるダックタイピング

それをダックタイピングとは言わない。

564デフォルトの名無しさん2014/11/30(日) 18:36:30.75ID:uRzHHhxu
そもそもduck typing自体まともな定義はない

565デフォルトの名無しさん2014/11/30(日) 18:44:16.77ID:/BRxH/wW
function foo(a) {
    a.bar()
}

bar() を呼び出せるなら何でも foo の引数に入れられるのが
ダックタイピングというのはどうだろうか
このスレだけでも

566デフォルトの名無しさん2014/11/30(日) 19:22:49.09ID:7WEYW95R
> bar() を呼び出せるなら何でも foo の引数に入れられるのが

それってさfoo関数の引数 aはbarメソッドを
持った型ではなければならないってことだよね?

コードに書くならば

function foo(/* fooメソッドを持った型 */ a) {
a.bar()
}

567デフォルトの名無しさん2014/11/30(日) 19:26:23.25ID:7WEYW95R
間違えたw

function foo(/* barメソッドを持った型 */ a) {
a.bar()
}

そして、大概は一つのメソッドだけ使うことはないから、

function foo(/* barとbazメソッドを持った型 */ a) {
a.bar()
a.baz()
}

あぁ!もう面倒くさい。

// Hogeインターフェース = barとbazメソッドを持っていること

function foo(Hoge a) {
a.bar()
a.baz()
}

わかりやすい。Hogeってみるだけで barとbazを持っていることがわかるし
もし持っていないものをaに入れるコードを書いたらコンパイルエラーが出る

568デフォルトの名無しさん2014/11/30(日) 19:32:01.35ID:/BRxH/wW
>>566
ただし、継承関係や共通のインターフェースを持たなくても
bar() を呼び出せるなら foo に入れられなくてはならない

569デフォルトの名無しさん2014/11/30(日) 19:47:43.07ID:7WEYW95R
http.connectを呼び出す関数に、
db.connectというメソッドを持ったオブジェクトを
入れても期待通りに動くことはまず無い。

二つの無関係なオブジェクトが同名のメソッドを持っていて
呼び出せるからといって、それはバグにしかならない。

メソッドに名前空間がないような形で使う動的型付け言語では
このような問題が起きる。

静的型付け言語ではインターフェースという型を定義することで、
同名であっても本質的に違うものは、違うものとして扱うことが出来る

570デフォルトの名無しさん2014/11/30(日) 19:53:09.38ID:VpMFGcKd
どんな御託を並べても
インターフェースがduck typingは無いわw

571デフォルトの名無しさん2014/11/30(日) 19:56:23.78ID:7WEYW95R
インターフェースがduck typingなどとは
ひとことも言ってない。

duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルでしか無い。
アヒルだ、空を飛べ。人間は飛べません。はいバグです。

実際には鳴くメソッドがあればアヒルである
ということになって更に意味がわからない。

もちろん、アヒルである条件をインターフェースとして定義しているならば
そのインターフェースを備えているものは、アヒルでいいですがね。

メソッド一つが有るか無いかきめんなよ。

572デフォルトの名無しさん2014/11/30(日) 19:57:27.20ID:7WEYW95R
訂正

duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルにはならない

573デフォルトの名無しさん2014/11/30(日) 19:59:03.44ID:360iudbJ
>>562
ググるとかしたことないのかね。

574デフォルトの名無しさん2014/11/30(日) 20:01:50.38ID:7WEYW95R
したことある人が、リンクを見つけてきて
ここに書けばいいと思いますが、

それを要求することは酷なことですね。
だってググっても見つからないのだから。

575デフォルトの名無しさん2014/11/30(日) 20:04:43.51ID:7WEYW95R
ダックタイピングの説明として
「アヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
という言葉があるが、

それを、
アヒルのように歩くとアヒルのように鳴くという
アヒルインターフェースを実装しているものはアヒルである。
というふうに読み替えると

これは実は静的型付け言語の説明だなとわかるはずである。

576デフォルトの名無しさん2014/11/30(日) 20:09:27.69ID:VpMFGcKd
>>569
mysql.connect と postgresql.connect は置き換え可能だけど?

577デフォルトの名無しさん2014/11/30(日) 20:11:34.14ID:VpMFGcKd

578デフォルトの名無しさん2014/11/30(日) 20:15:01.73ID:7WEYW95R
>>576
両方が同じデータベースインターフェースを
サポートしているならばそうだろうね。

現実的な話をするならば、mysql.connect を
使うコードは、実際にはmysql.connect だけを
使うことはなく、複数のメソッドを使う。

だから、その複数のメソッドというものを
定義しないといけない。

そしてその定義したものがインターフェースであり
そのインターフェースを使いますよと宣言するのが
型宣言なのである。

そうすればある型がデータベースインターフェースを
定義していることを保証する型宣言だけあれば、
全てのメソッドを安心して使うことが出来る。

このオブジェクトはconnectメソッドは持ってるけど、
disconnectメソッドを持っていないかもしれない
なんてことはなくなるのである。

579デフォルトの名無しさん2014/11/30(日) 20:16:45.31ID:nRiDRl39
足し算と掛け算のある型なら複素数でも行列でも良いとかいうパターンは有るな

580デフォルトの名無しさん2014/11/30(日) 20:21:32.59ID:7WEYW95R
足し算をaddメソッドだとして、
addメソッドさえあればなんでも使えるかというと

(addメソッドでググって一番目にでてきた)
> Addメソッドとはエクセルのシートに表とグラフを同時に表示するメソッドです。

に対してもうまく動くことはおそらくないだろう。

つまり名前が一緒でも、正しく動くとは限らんのさ。
だから名前と意味が一緒であることを保証するために
名前をつけたものが型なのである。

581デフォルトの名無しさん2014/11/30(日) 20:24:10.20ID:T2KLr1TM
>>575
アヒルのインスタンスを実行時にその振る舞いから分類するところがポイントなのであって
アヒルというクラスに対してコンパイル時に分類するのはダックタイピングじゃないよ

というわけでダックタイピングはインターフェースや構造的部分型とは全く別

582デフォルトの名無しさん2014/11/30(日) 20:25:36.35ID:VpMFGcKd
>>580
Excelのaddメソッドは戻り値の型が違うだろ

583デフォルトの名無しさん2014/11/30(日) 20:25:53.73ID:T2KLr1TM
>>580
だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ

584デフォルトの名無しさん2014/11/30(日) 20:26:04.76ID:7WEYW95R
アヒルのインスタンスを実行時にその振る舞いから分類というけれど、
コード自体は、実行時に分類してないんだよ。

コードは、アヒルであること、を前提として書いてる。
実行前にコードで分類しているのに、
なぜ実行時に分類しないといけないのか。

型は動的に変わるが、コードは静的なのである。

585デフォルトの名無しさん2014/11/30(日) 20:28:54.03ID:7WEYW95R
>>583
> だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ

だから大規模では無理なんだよ。

大規模=大多数の人間が係る。場合によっては全く知らない人が作った
ライブラリを使うこともあるしな。


そんなんで、すべて意味を揃えるなんてことは不可能
いくつもの意味を持つ英単語なんてざらにある

単語の意味を揃えるのは不可能。というのが大前提

586デフォルトの名無しさん2014/11/30(日) 20:29:37.63ID:T2KLr1TM
>>584
コードも動的だから「動的」なんだよ
それとも、単なる動的型付けの話をしている?

587デフォルトの名無しさん2014/11/30(日) 20:30:01.03ID:/BRxH/wW
>>581
Interfaceも構造的部分型も実行時に動的に分岐する
そうでなければポリモーフィズムとは言わない

さらに言えば、構造的部分型は「アヒルというクラス」に対して分類してるわけでもない

588デフォルトの名無しさん2014/11/30(日) 20:31:08.34ID:T2KLr1TM
>>585
とはいえ
Objectクラスだけで500近いメソッド数をもっているにもかかわらず
不特定多数の開発者からのコードを集めたSmalltalkシステムは
ちゃんと動いているわけだが

589デフォルトの名無しさん2014/11/30(日) 20:33:46.05ID:SVLUkCya
>>588
SmalltalkでObjectに500もメソッドなんてねーよw

あったとしたら、アンチパターン ゴッドクラス
(設計の一部分(クラス)に、過剰に機能を集中させること)に
適合してしまうわw

590デフォルトの名無しさん2014/11/30(日) 20:34:01.13ID:T2KLr1TM
>>587
分岐(メソッド探索)の話などしていない

どの式がどのインターフェースを実装しているのかを実行時に検査してるのか?
どの式がどの型の部分型かを実行時に検査しているのか?
へー、それ、なんていう言語だい?

591デフォルトの名無しさん2014/11/30(日) 20:36:14.22ID:TE77vkUw
>>589
わかりやすい静的脳だな
Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw

592デフォルトの名無しさん2014/11/30(日) 20:36:20.46ID:VpMFGcKd
>>585
大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
同じ意味の機能に同じインターフェースを持たせるのは不可能

インターフェース方式は、ある数値計算ライブラリと別の行列演算ライブラリを混ぜて使う場合などで問題になる

593デフォルトの名無しさん2014/11/30(日) 20:40:02.67ID:/BRxH/wW
>>590
実行時にvalidationするのがダックタイピングというなら
構造的部分型は確かに違うな


"If it walks like a duck and quacks like a duck, it must be a duck"

という文章からそのような意味を読み取るのは無理だが

594デフォルトの名無しさん2014/11/30(日) 20:40:22.76ID:SVLUkCya
>>591
> Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw

最悪だな。JavaScriptでprototypejsっていうのがあったけど、
名前が標準のメソッドとobjectに追加したメソッド名が
被って大変な目にあっていた。

それ移行Objectにメソッドを追加するのは
ダメなやり方だって広く知られるようになったね。

595デフォルトの名無しさん2014/11/30(日) 20:40:39.28ID:360iudbJ
>>570
いや。duck typing とは言わないけれど、Smalltalk の動的型と
同様の柔軟性を持たせつつ型安全を目指したのがインターフェイス。
(Eiffel流のクラスの継承をサブタイプに使うと型安全でないという流れで)
http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf

596デフォルトの名無しさん2014/11/30(日) 20:43:21.18ID:/BRxH/wW
>>592
Haskellの型クラス、Rustのトレイト等が
それらの問題点を解決している

597デフォルトの名無しさん2014/11/30(日) 20:45:52.98ID:TE77vkUw
>>593
If it walks like a duckというのは、実際のitの振る舞いのことを指しているのだから実行時のことだと考えるのが自然だと思うが?
If it will walk like a duckならばコンパイルだろうけどな。

598デフォルトの名無しさん2014/11/30(日) 20:47:16.39ID:TE77vkUw
>>594
>名前が標準のメソッドとobjectに追加したメソッド名が
>被って大変な目にあっていた。

初心者だな
当分補助輪をつけることをお勧めするw

599デフォルトの名無しさん2014/11/30(日) 20:48:14.19ID:360iudbJ
>>589
Squeak Smalltlk(Squeak4.5)で調べたけど
いろんな意味で残念ながら^^; 500近くはあるな。Object allSelectors size "=> 486 "

600デフォルトの名無しさん2014/11/30(日) 20:51:13.03ID:TE77vkUw
>>592
>大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
>同じ意味の機能に同じインターフェースを持たせるのは不可能

そういう初心者は補助輪(静的型)を使えばいいよw

ちなみに動的言語の環境では
様々なライブラリでどういうメソッド名がつけられているか検索する仕組みと
指定したメソッド名のメソッドを検索する仕組みが
遥か80年代から用意されていたりするけどなw

601デフォルトの名無しさん2014/11/30(日) 20:53:54.80ID:TE77vkUw
>>599
動的言語では全オブジェクト共通の語彙が重要だから当然そうなる

602デフォルトの名無しさん2014/11/30(日) 20:56:59.55ID:360iudbJ
>>555
とりあえず、アラン・ケイが書いていることを読もうや。
そもそも「その頃は」って思い込み激しすぎるだろう。
これ書かれたの1999年〜2000年頃だし。

603デフォルトの名無しさん2014/11/30(日) 21:05:38.46ID:/BRxH/wW
>>597
静的型でも振る舞うのは実行時だろ
チェック自体はコンパイル時だが

で、どこに実行時にチェックすると書いてある?

604デフォルトの名無しさん2014/11/30(日) 21:09:31.70ID:360iudbJ
>>601
とはいえ、Squeak のカオス化に嫌気してフォークされた Pharo は
だいぶ減らして 374 だし(3.0調べ)、VisualWorks はもとより 303(7.10調べ)だけどね。

605デフォルトの名無しさん2014/11/30(日) 21:10:47.94ID:VpMFGcKd
>>601
補完がうんこ過ぎるからそんなカオスになってんだろ
クラスの名前空間としての機能が死んでる

606デフォルトの名無しさん2014/11/30(日) 21:13:30.42ID:VpMFGcKd
>>600
静的型(ていうかJava)のインターフェースの話だよ
動的なら名前合わせときゃ良いんだから問題ならん

607デフォルトの名無しさん2014/11/30(日) 21:15:20.91ID:guVElZZq
>>599
Pharo 3.0 は、374

608デフォルトの名無しさん2014/11/30(日) 21:17:02.28ID:guVElZZq
>604 で既出だった orz

609デフォルトの名無しさん2014/11/30(日) 21:30:34.30ID:360iudbJ
>>608
乙^^

ちなみにファンお手製で変わり種のGNU Smalltalkだとわずか123。
http://ideone.com/D9lo8c

610デフォルトの名無しさん2014/11/30(日) 21:50:46.91ID:mFsly3WX
>>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

611デフォルトの名無しさん2014/11/30(日) 22:04:51.19ID:SVLUkCya
オブジェクト指向プログラミングをするのが目的ではない。
巨大なシステムをより早くより安全に開発するのが目的なのだ。

612デフォルトの名無しさん2014/11/30(日) 22:11:54.90ID:rR9TrKjV
オブジェクト指向上の欠陥とやらが何か知らんが、
そのお陰で実用レベルの型推論(補完や型検査)が出来てるなら面白いな

613デフォルトの名無しさん2014/11/30(日) 22:22:44.40ID:SVLUkCya
人間が間違わずに全てのコードを脳に記憶して
タイプミスすらしないことを前提にするならば、
コードにわざわざ記憶の断片(つまり型情報)を書く必要はないよ。

それができないから、型情報を書いたほうが
わずかの手間だけで、そのあとずっと楽ができるわけで。

614デフォルトの名無しさん2014/11/30(日) 22:32:19.86ID:360iudbJ
>>570
すまん。こっちだった。
Interfaces for Strongly-Typed Object-Oriented Programming
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf

615デフォルトの名無しさん2014/11/30(日) 22:48:40.83ID:mFsly3WX
>>612
>オブジェクト指向上の欠陥とやらが何か知らんが、

有名な Python のself地獄だよ
キーワード「python self地獄」で検索すればGoogle先生が教えてくれる
Python しか知らなければself地獄が気にならないかもしれないけど、
Smalltalk や Ruby を知っている人からすれば、無知は幸せだなぁと見る
これの基礎が「継承の意味論における差異」になる

なお単に意味論の違いだから、self地獄と引き換えに
実用的な型推論(補完や型検査)が手に入るわけではない
両者の間に直接的な関連性は無い(言い換えるとスレチな話題)

616デフォルトの名無しさん2014/11/30(日) 22:53:53.26ID:rR9TrKjV
>>615
self地獄はGuidoが変人なだけで意味論なんて高尚な理由じゃねーだろ
self省略できるようにパーサ弄れない意味論的理由は何だよ
それこそ関係ねーよ

617デフォルトの名無しさん2014/11/30(日) 22:55:23.26ID:360iudbJ
>>610
> Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ

Ruby の super は Smalltalk とは違うよ?

618デフォルトの名無しさん2014/11/30(日) 22:55:36.39ID:/BRxH/wW
>>615
> 両者の間に直接的な関連性は無い(言い換えるとスレチな話題)

スレの主題に沿っているのは補完や型チェックの方だけど

619デフォルトの名無しさん2014/11/30(日) 22:57:41.96ID:mFsly3WX
>>614
この論文内では duck typing という用語は一度も使われていないし、
タイトルに Strongly-Typed と書かれているように静的型付け言語に関する内容だ

で、いったいどこから duck typing を連想したの?

620デフォルトの名無しさん2014/11/30(日) 23:00:20.47ID:360iudbJ
典型的なアスペか。

621デフォルトの名無しさん2014/11/30(日) 23:01:15.62ID:mFsly3WX
>>618
>スレの主題に沿っているのは補完や型チェックの方だけど

まったくそのとおり
だから >>610 では

> まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね

と書いた

622デフォルトの名無しさん2014/11/30(日) 23:09:04.67ID:rR9TrKjV
>>619
1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ
abstract斜め読みしただけだがSmalltalkには言及されてんぞ

623デフォルトの名無しさん2014/11/30(日) 23:09:46.51ID:tHR3Cg3X
あれ?int型の+とstring型の+に対するオーバーロードみたいな話になってる?
無知なら口だすなと言われそうなので黙っておきます…

624デフォルトの名無しさん2014/11/30(日) 23:22:20.73ID:/BRxH/wW
>>621
そうか。じゃあスレ違いの話は止めないと荒らしになってしまうな

625デフォルトの名無しさん2014/11/30(日) 23:27:42.56ID:mFsly3WX
>>616
Python のオブジェクト指向は Modula-3 を参考にしているけど、
Modula-3 のオブジェクト指向は Simula を参考にしている
そして疑似変数 self の概念は Simula には存在せず、
Simula を参考にした Smalltalk で生まれた
だから、Modula-3 や Python に疑似変数 self は存在せず、
これを模倣するにはメソッド引数で明示的に __self__ を
渡さなければならない訳

あと疑似変数 self の値は実行時に決まるから、
もし Python で __self__ を省略できるようにするためには、
構文論(syntax)の変更すなわちパーザの改造だけではダメで、
意味論(semantics)も変更しなければならない

こうした背景も知らずに「変人だから」という理由で決めつけるのは、
Guido氏に失礼だと思うよ

626デフォルトの名無しさん2014/11/30(日) 23:31:44.94ID:guVElZZq
もう、超優秀なIDEがあって動的構造取り入れた c# 最強って事で良いんじゃないの?

627デフォルトの名無しさん2014/11/30(日) 23:42:47.38ID:UnYKruMf
>>626
MSが他の処理系を駆逐する勢いでLinux版頑張ったら近い将来にそうなるかも。
種だけ蒔いて後知らねっていう可能性も高いけど。

628デフォルトの名無しさん2014/11/30(日) 23:43:33.56ID:mFsly3WX
>>622
> 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ

そうだろ、だから驚いて >>619 では

>>で、いったいどこから duck typing を連想したの?

と書いた

論文を引用するのはいいけど、この論文をどう解釈して duck typing に結びつけたのか、
説明が無ければ意味が分からんという話だよ


>abstract斜め読みしただけだがSmalltalkには言及されてんぞ

Smalltalk の柔軟な継承を強い型付け(=静的型付け)なOO言語に取り込むために
インターフェイスを用いる、という文脈でね
動的型付けを濫用するというニュアンスを持つ duck typing とは何の関係も無い

この論文、型システムと言語設計に興味がある人にはとても有益だから、
斜め読みと言わずじっくり読んでみたほうがいいと思うな

629デフォルトの名無しさん2014/11/30(日) 23:44:44.78ID:/BRxH/wW
>>616
http://neopythonic.blogspot.jp/2008/10/why-explicit-self-has-to-stay.html

・ただの関数を、後からクラスにメソッドとして後付けできること(そのとき暗黙のselfの扱い)
・decoratorがあるから(動的にstatic methodやclass methodに変更できる)

というのが理由だそうだ

630デフォルトの名無しさん2014/11/30(日) 23:49:11.15ID:guVElZZq
>>627
Roslyn凄そうだが、どんだけのヤツが付いていけるんだろ。

631デフォルトの名無しさん2014/11/30(日) 23:50:00.23ID:nRiDRl39
>>626
動的構造ってなんだっけ
実行時型情報ならC++にもあるけど
むしろ実行時型情報がない言語の方が良いんだろ
ほぼ全部関数型言語だけど

632デフォルトの名無しさん2014/11/30(日) 23:52:00.50ID:mFsly3WX
>>629
Smalltalk や Ruby なら、暗黙のselfがあっても
後からクラスにメソッドを後付けできるのにね....

633デフォルトの名無しさん2014/11/30(日) 23:53:34.74ID:/BRxH/wW
言語だけでいうならRustに期待しているんだが……

634デフォルトの名無しさん2014/11/30(日) 23:57:11.19ID:SVLUkCya
>>682
> 後からクラスにメソッドを後付けできるのにね....

それは静的型付け言語のメリットをなくしてまで
やるべき重要な事なのか?

635デフォルトの名無しさん2014/11/30(日) 23:58:47.30ID:mFsly3WX
>>634
おいおい、Python は動的型付け言語だよ

636デフォルトの名無しさん2014/11/30(日) 23:59:07.80ID:rR9TrKjV
>>632
その代わりに関数が無くてProcオブジェクトとかいう
キモい代用品を使わされるゴミでしょRubyって

637デフォルトの名無しさん2014/11/30(日) 23:59:36.82ID:UnYKruMf
>>633
そこでまた振り出しに戻るのだが、ちょこちょこって遊ぶならどの言語でも
いいのだが、ガッツリ使おうとするとツールもしっかりしてないとねというのに
戻るわけです。

638デフォルトの名無しさん2014/11/30(日) 23:59:39.73ID:guVElZZq
>>631
dynamic型

639デフォルトの名無しさん2014/12/01(月) 00:02:55.46ID:v1/AC0CB
>>635
実用レベルで型推論出来る言語と
出来ないゴミを一緒にすんなよ
PythonはSoft typingが実用化されてんの

640デフォルトの名無しさん2014/12/01(月) 00:04:29.77ID:JhMfQ7kZ
>>636
いや、Procオブジェクトを明示的にコーディングするのは稀だ
クロージャの無い Python とは違って、
Ruby だと普通は do |x| ... end や { |x| .... } で書ける

641デフォルトの名無しさん2014/12/01(月) 00:08:40.28ID:v1/AC0CB
>>640
お前クロージャスレでフルボッコにされた奴か
ここでもフルボッコじゃねーかw

642デフォルトの名無しさん2014/12/01(月) 00:11:50.96ID:WHPunuUw
>>637
スレタイでいうところの大規模開発なら特にそうだな
残念ながら言語の優先順位は低いと言わざるを得ない

643デフォルトの名無しさん2014/12/01(月) 00:13:16.83ID:2BTgZC4D
結局は、静的言語が動的言語の要素を取り入れて進化し、両方の境界が曖昧になるんだよ。

644デフォルトの名無しさん2014/12/01(月) 00:15:06.71ID:JhMfQ7kZ
>>641
逆だろw
クロージャを使えば簡潔に書けるのに、結局 Python ではコードが書けずに終わった
で、しまいに火病を発症してわめきちらしただけ、それがフルボッコなのか?www

今からでもいいから Python でコード書いてみな

645デフォルトの名無しさん2014/12/01(月) 00:18:09.70ID:v1/AC0CB
>>643
そしてObjectに500個もメソッドを突っ込んで悦に入ってるゴミは
サーベルタイガーのように進化から取り残される、と

646デフォルトの名無しさん2014/12/01(月) 00:20:09.36ID:JhMfQ7kZ
>>640
ほう、Python で Soft Typing が実用化されたとは初耳だ
ググってみると2003年に提案はあったものの、
その後に実装されたという情報は見つけられなかった

本当に実用化されているの?
また嘘でも何でも議論に勝ちさえばいいという発想じゃないのかなあ....

647デフォルトの名無しさん2014/12/01(月) 00:21:49.35ID:v1/AC0CB
>>644
え?お前が勝手なクロージャの定義を持ち出して、
出展となる文献を出せと言われても出せず逃げただけじゃん

で、文献は?

648デフォルトの名無しさん2014/12/01(月) 00:28:35.48ID:v1/AC0CB

649デフォルトの名無しさん2014/12/01(月) 00:29:56.57ID:JhMfQ7kZ
>>674
クロージャの話題は完全にスレ違いだから、
続きを希望するなら当該スレへ移動してくれ
文献もそこで出すよ

650デフォルトの名無しさん2014/12/01(月) 00:36:07.76ID:2BTgZC4D
>>645
そのゴミから色々なものが生まれた。
50年後には、そのゴミから新しいOSが生まれるかもよ。

651デフォルトの名無しさん2014/12/01(月) 00:39:00.66ID:JhMfQ7kZ
>>648
外部にツールが存在することと、
ある言語が Soft Typing で設計されている話は関係ないよ
Python の言語処理系(インタプリタ)だけで
明示的な型宣言が無くとも実行前に型検査できるなら
話は別だけどね

というか、Soft Typing という用語の意味を
間違って理解しているんじゃね?

652デフォルトの名無しさん2014/12/01(月) 00:42:41.17ID:v1/AC0CB
>>651
ある言語がSoft typingで設計されてるかなんて開発においてどうでも良すぎる
型推論に基づく実用的なツールがあるかどうかが重要

653デフォルトの名無しさん2014/12/01(月) 00:50:53.90ID:JhMfQ7kZ
いかん、アンカを間違えてた
エスパーしてくれてるみたいだけど、念の為、訂正しとく

>>646 内のアンカ >>640 は間違いで、>>639 が正しい
>>649 内のアンカ >>674 は間違いで、>>647 が正しい

654デフォルトの名無しさん2014/12/01(月) 04:58:08.58ID:CuP+pzia
>>559
かっこいいとかそういう基準で判断してるわけじゃないから。契約とか内容次第だから勝手なイメージだろ。

655デフォルトの名無しさん2014/12/01(月) 06:42:19.33ID:Weh8bUwF
645はクラスを名前空間だと思い込んでいる初心者
早く補助輪を取れるといいね

656デフォルトの名無しさん2014/12/01(月) 09:10:41.83ID:B1S4sCHX
そんなつまらない事にしかレスできないから
馬鹿にされるんだよw

657デフォルトの名無しさん2014/12/02(火) 12:19:36.12ID:KrePR2s0
昔Basicはプログラマとしてのセンスを破壊すると言われたが、
今回Smalltalkも破壊することが判明したな

658デフォルトの名無しさん2014/12/02(火) 13:56:12.38ID:3rN5XUau
2ちゃんねるは人間としての品格を破壊する

659デフォルトの名無しさん2014/12/02(火) 14:29:13.80ID:XRdoM1I9
“Smalltalkのデバッガがどのくらい強力かと言うと、
任意の時点で任意のプロセスをインタラプトし
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続できるレベル。

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

https://twitter.com/abee2/status/539355671729152000

660デフォルトの名無しさん2014/12/02(火) 16:22:17.31ID:+stn5l+y
10年とか先にarmのcpuが流行ってるとは思わなかったでしょ

661デフォルトの名無しさん2014/12/02(火) 19:47:59.90ID:OQmm7jB2
>>659
凄いけど役に立たないなw

662デフォルトの名無しさん2014/12/02(火) 19:49:38.18ID:OQmm7jB2
なんで役に立たないかというと

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

最初からやり直したほうが早い。

663デフォルトの名無しさん2014/12/02(火) 22:07:07.23ID:DpCZ+4Qy
>>662
ま、結局どんな凄い機能も、
使う人間のスキルと能力が足りなきゃゴミ以下って話だね。

664デフォルトの名無しさん2014/12/02(火) 22:38:50.95ID:OQmm7jB2
人間はミスするとう前提の話をしてるんだが?
スキルや能力とは関係ない。

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

ということで静的型付け言語はそうなってるって話なんだよ。

665デフォルトの名無しさん2014/12/02(火) 22:48:09.93ID:DpCZ+4Qy
>>664
静的型言語(の特に機能を限定した言語)がスキルの期待できない土方向け
という意見には反対しない。

666デフォルトの名無しさん2014/12/02(火) 22:52:44.71ID:OQmm7jB2
一体何の機能が制限されているというのか?
タイプ数が少し増えるというのならわかる。
制限されているという機能の名前を聞いたことがないし、
どうでも良い機能のために、動的型付け言語を使うという話しか聞かない


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

デメリットはほんの少しタイプ量が増えるだけ

667デフォルトの名無しさん2014/12/02(火) 22:57:12.61ID:ySWWhxWC
修正したコードが実機の上、しかもファイルじゃなくてメモリ上にしかないとか
よく考えなくても怖いことなんだけどな。

668デフォルトの名無しさん2014/12/02(火) 22:58:05.38ID:AvSKqXZA
>>664
人間はミスするけど爆発しないよ
機械は爆発する
大規模なら大爆発

669デフォルトの名無しさん2014/12/02(火) 23:01:26.70ID:DpCZ+4Qy
>>667
よく考えてたら、VCSにチェックインするとか想像できそうなものだけど。

670デフォルトの名無しさん2014/12/02(火) 23:23:32.69ID:DpCZ+4Qy
>>667
> しかもファイルじゃなくてメモリ上にしかないとか

って、まともなSmalltalk処理系ならチェンジファイル機構くらいはあるだろjk

671デフォルトの名無しさん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 の台頭を許した

672デフォルトの名無しさん2014/12/02(火) 23:43:16.07ID:DpCZ+4Qy
Smalltalkをちょっとかじってみたい人のための、チュートリアルまとめ
http://qiita.com/sumim/items/6bed17961bd57daf88a3

アンチな人にも。

673デフォルトの名無しさん2014/12/03(水) 00:24:16.86ID:B6A3kVmE
>>659
なぜDockerみたいな技術が持て囃され、こういう機能がスルーされるのか
Smalltalkerには永遠に理解できないんだろうな

Smalltalkは見当違いの問題を解いているんだよ
言語の中だけでリスタートできても意味がないんだ
価値がないから真似もされない

674デフォルトの名無しさん2014/12/03(水) 01:01:00.52ID:/c7/jI5U
道具に使われてる人たちが・・・

675デフォルトの名無しさん2014/12/03(水) 01:03:45.51ID:cgD8+cJC
>>673
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

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

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

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

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

Smalltalkにはそうした意味での「オペレーティングシステム」は
無い。

676デフォルトの名無しさん2014/12/03(水) 01:07:46.87ID:9SD5P0Ri
この言語は危ないという前提があった方が、本当に危なくなった時に逃げやすいね
言語を信用しすぎると逃げ遅れる

677デフォルトの名無しさん2014/12/03(水) 05:01:07.21ID:Fu5jXwDM
>>667
大抵のSmalltalk処理系はソース編集をジャーナリングしているのだが?
普通の開発環境でいえば、
テキストエディタで編集するごとに自動的にcommitしているようなもの。
PVSやMonticelloを使えばもっと高機能かつ安全だ。

むしろ、commitを自分でやらないと編集履歴が残らない
普通の開発環境のほうがよく考えなくても怖いことなんだけどな。

678デフォルトの名無しさん2014/12/03(水) 09:01:37.48ID:XWw3OxN9
>>675
OSの上でOSゴッコしてるだけのSmalltalkが笑わせてくれる

679デフォルトの名無しさん2014/12/03(水) 09:09:27.83ID:RRftfJUJ
>>677
もう少し分かりやすくいおう。

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

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

そこまでセットアップする手間を省けるだけなのだ。

680デフォルトの名無しさん2014/12/03(水) 09:13:57.48ID:RRftfJUJ
>>671

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

動的型付け言語じゃなくても達成出来てることを言われてもなw
だいたい発展し続けると言っても、再起動してるじゃん。
なぜ動的型付け言語ならではの理由が
あんたの言っていることには一つのないんだよね。

681デフォルトの名無しさん2014/12/03(水) 09:21:29.91ID:XWw3OxN9
>>677
マイナー言語のショボいVCS使ってないで
さっさとgit覚えてください

682デフォルトの名無しさん2014/12/03(水) 10:48:31.33ID:9SD5P0Ri
なんでも理由があるべきという思い込みはよくない
実力だけでなく運で決まることもたくさんある

683デフォルトの名無しさん2014/12/03(水) 11:22:27.25ID:zGKDhFQQ
>>681
Smalltalkを使っている人間はgitを理解できないと決めつける時点で
発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、
古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。

684デフォルトの名無しさん2014/12/03(水) 12:24:53.21ID:zGKDhFQQ
>>673
> Smalltalkは見当違いの問題を解いている

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

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

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

少し、だけどね。土方には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
食いつないでいくためにはまずそっちを優先すべきだし。

685デフォルトの名無しさん2014/12/03(水) 14:17:36.95ID:Fu5jXwDM
>>678
原論文を理解できなかったなら正直にそう書けばいいのにw

686デフォルトの名無しさん2014/12/03(水) 14:23:59.81ID:Fu5jXwDM
>>673
メインフレームを笑っていたUnix厨が
メインフレーム由来の仮想化技術をあたかも最新技術のように持て囃す、
あんたが好きな「価値」ってのはその程度のものだ
必死に追いかければ、その先に青い鳥がいるかもなあw

687デフォルトの名無しさん2014/12/03(水) 20:48:36.10ID:nRr7XZh4
Dockerはunixの世界においても枯れた既存技術の寄せ集めだし、
最新技術だから持て囃されてるんじゃないよ

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

メインフレームみたいに極限までロックインさせる話とは根本的に違う
やっぱり分かってないと言わざるを得ない

688デフォルトの名無しさん2014/12/03(水) 21:23:44.95ID:o4Xb4UE8
ベンダーロックインを静的型にたとえると

短いソースをコンパイルするために多くのヘッダーをincludeすることを強制される
ヘッダーと本体が分かれていない言語では全部必要

689デフォルトの名無しさん2014/12/03(水) 21:45:16.01ID:RRftfJUJ
>>688
じゃあRubyもPythonもだめだな。

ブラウザで動くJavaScriptは大丈夫か?
include相当の構文がないもんなw

690デフォルトの名無しさん2014/12/03(水) 21:49:32.75ID:RRftfJUJ
>>684
> には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
> ついて行かなきゃいけないトレンドや技術がいっぱいあるから、

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


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

うん、違和感ない

691デフォルトの名無しさん2014/12/03(水) 22:07:22.24ID:o4Xb4UE8
>>689
モジュールの依存関係は大したことはない
型の依存関係は基底クラスやprivateメンバーの型まで伝播する

692デフォルトの名無しさん2014/12/03(水) 22:22:38.66ID:RRftfJUJ
そのおかげで、矛盾するもの。つまり
明らかに動かないコードを検出することが可能になっている。

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

これこそ、大規模開発で必要なことの一つなんだ。

693デフォルトの名無しさん2014/12/03(水) 22:25:08.05ID:o4Xb4UE8
大規模炎上の主な原因はバグではなく設計ミスではないのか

694デフォルトの名無しさん2014/12/03(水) 22:26:49.02ID:B6A3kVmE
静的型の方がアカデミック方面での発展も凄いので
確かに学ぶことは多いと思うよ

695デフォルトの名無しさん2014/12/03(水) 22:31:22.32ID:0xDgvp4s
>>693
違う、営業的に決められた納期だな

696デフォルトの名無しさん2014/12/03(水) 22:36:19.29ID:RRftfJUJ
>>693
大規模炎上の話なんかしていないw

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

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

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

これこそ大規模開発で必要なことなんだよ。

697デフォルトの名無しさん2014/12/03(水) 22:43:05.49ID:o4Xb4UE8
うっかり基底クラスを変更したら
継承も知らないのかと疑われそうで嫌だな

698デフォルトの名無しさん2014/12/03(水) 22:44:57.73ID:RRftfJUJ
モジュール間の依存は小さくするというのは
ソフトウェアの開発者の常識だが、
なぜ小さくするのかというとモジュール間の依存が大きいと
修正する時に発生する影響範囲が大きくなって修正が大変だからなんだ。

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

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

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

影響範囲を確認することが大変なモジュール間の依存を
明確にすることで、不具合の発見を容易にし
修正のコストを減らすのが、静的型付け言語の特徴なんだ。

699デフォルトの名無しさん2014/12/04(木) 01:15:00.87ID:jHjIGczB
インタフェースみたいにメソッドの実装を強制したいです
どうしますかおしえて

700デフォルトの名無しさん2014/12/04(木) 02:09:44.10ID:8pz5p6Zv
したら良いんじゃない?
できない言語を使ってるの?

701デフォルトの名無しさん2014/12/04(木) 08:48:23.43ID:1fNTZGeK
>>699
実装しなかったら開発者をクビにする

702デフォルトの名無しさん2014/12/04(木) 09:42:52.10ID:rp/BpD2j
>>687
超マイナーなVCSや低性能のODBに
自分からロックインされに行く技術オンチのSmalltalkerには
遠い世界の話だな

703デフォルトの名無しさん2014/12/04(木) 10:26:14.06ID:5ZEJ+Feh
>>699
変数の初期化 (null以外) を強制したいとは言わないところが甘い
厳しいのか甘いのかはっきりしない機械は駄目だ
そういうのは人間の方が向いている

704デフォルトの名無しさん2014/12/04(木) 12:32:36.38ID:TqunBxc9
>>702
> 超マイナーなVCSや低性能のODBに
> 自分からロックインされに行く

ありがたい話じゃないか。
そこまでしてSmalltalkから将来出てくるであろう新しい何かを育ててくれるんだから。
トレイトしかりクラスボックスしかり。

705デフォルトの名無しさん2014/12/04(木) 19:31:17.50ID:mwV5k8HO
>>702
Smalltalkでは何十年も昔から常識だったことが
新技術として他の言語や環境でも使えるようになったら
「こんな便利な技術は技術オンチのSmalltalkerには理解できないだろう」
とか言いながらありがたく使いなさいよ、技術乞食さんw

706デフォルトの名無しさん2014/12/04(木) 20:15:36.06ID:rp/BpD2j
>>704
traitはSmalltalk由来のじゃなくて
Haskellの型クラス由来のヤツが残りそう

やっぱり作ってる連中の知的レベルが段違いだしね?

707デフォルトの名無しさん2014/12/04(木) 21:21:32.12ID:tYdcY83W
え? なに? 俺の言語が起源だとかいう話をしてんの?

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

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

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

初号機のほうが優れているっていうのは漫画の中の話だけだよ。
現実には、二号機、三号機の方が優れている。

708デフォルトの名無しさん2014/12/04(木) 21:36:40.87ID:RpORv8ek
>>706
traitsとかホントは知らないんだろ?
implicit parameterと区別が付かないとかないわー

709デフォルトの名無しさん2014/12/04(木) 21:47:04.11ID:8pz5p6Zv
>>708
この論文は読んだ上で言ってるの?
あ、Martin OderskyはScalaの作者ね

http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf

710デフォルトの名無しさん2014/12/04(木) 21:48:59.20ID:RpORv8ek
>>707
パクる元がなければ改良もクソもないんだから
アイデアのゆりかご的存在は生かさず殺さずにしておく方がいい
って話なんだが。どうして優劣の話になるかな

711デフォルトの名無しさん2014/12/04(木) 21:50:19.83ID:5ZEJ+Feh
>>707
初号機には二号機をスルーして三号機に移行する作戦があるから
二号機はどうでもよい

712デフォルトの名無しさん2014/12/04(木) 21:54:36.04ID:RpORv8ek
>>709
Scalaだからinterfaceの代わりにtraitを使っただけで、
型クラスとは関係ないだろう。

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

714デフォルトの名無しさん2014/12/04(木) 22:11:18.04ID:tYdcY83W
このペーパー、プレゼントします

最初の方だけ読みました!

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

716デフォルトの名無しさん2014/12/04(木) 22:20:18.91ID:8pz5p6Zv
>>715
どこにって、implicitを使うために中で何度でも出てくるよ?

717デフォルトの名無しさん2014/12/04(木) 22:24:26.97ID:8pz5p6Zv
こういう研究の流れを受けてか、後発のRustのtraitは
最初からHaskellのType Classそっくりになっているんですってよ

718デフォルトの名無しさん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,

719デフォルトの名無しさん2014/12/04(木) 22:30:05.46ID:tYdcY83W
始めに実装したというのは凄いかもしれないけど、
その凄いっていうのは、始めに実装したことであって
その機能がすごいってことじゃないんだよな。
後発のほうがもっとその機能を強化している。

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

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

721デフォルトの名無しさん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:

722デフォルトの名無しさん2014/12/04(木) 23:00:58.08ID:5ZEJ+Feh
宇宙服みたいな言語とモビルスーツみたいな言語があるけど
どうせ結局両方使うんだよな

723デフォルトの名無しさん2014/12/04(木) 23:08:55.47ID:RpORv8ek
>>721
何そのパズルみたいな抜粋。
どうこねくり回したところでScalaのtraitに限っては
その出自はミックスインみたいなもので、型クラスそのものではないよ。

724デフォルトの名無しさん2014/12/04(木) 23:11:32.11ID:8pz5p6Zv
>>723
ついに反論しきれなくなって、traitとtype classは無関係から
そのものでは無いまで意見が後退しちゃったねw
自分もtype classそのものなんて一度も言ってないので、もうそれで良いよ

725デフォルトの名無しさん2014/12/04(木) 23:13:27.66ID:BoUkojKR
>>722
両方を備えたc++ですね分かります

726デフォルトの名無しさん2014/12/04(木) 23:24:08.54ID:BoUkojKR
A君「絵を描くのは好きだけど、仕事と両立するのは難しいなぁ」
ニート「一日中ヒマだから絵を描き放題だぜ」

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

727デフォルトの名無しさん2014/12/04(木) 23:40:50.93ID:RpORv8ek
>>724
わっかんないやつだなぁ。
traitが型クラス由来なら、なぜtraitを使わないで型クラスの例が書けるのさ。
http://www.scala-lang.org/old/node/114

説明してミソ

728デフォルトの名無しさん2014/12/05(金) 00:15:41.66ID:RG1/KShi
>>727
Rubyではblockを使わずにlambdaが書けるから
blockはクロージャ由来じゃないってことだね

729デフォルトの名無しさん2014/12/05(金) 00:20:26.42ID:lYb7FfYs
C++のclassはstructでも書けるな

730デフォルトの名無しさん2014/12/05(金) 02:25:30.08ID:3qncuvNa
>>728
おまえ頭わるいな

731デフォルトの名無しさん2014/12/05(金) 07:42:45.52ID:ViNbqhcv
>>730
いや、お前が頭悪い
(理由は省略、いう必要もないから)

732デフォルトの名無しさん2014/12/05(金) 09:04:37.51ID:t8jCTeme
RubyのブロックってCLUのイテレーター由来じゃなかったっけ?
ずいぶん前にMatzがそんなようなことを言っていた記憶が

733デフォルトの名無しさん2014/12/05(金) 09:13:02.76ID:A1Nk4WQY
クロージャとラムダ式の区別がついていない人ってよくいるよね

734デフォルトの名無しさん2014/12/05(金) 09:16:51.57ID:+TXyzC2W
>>733
それお前じゃね?

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

735デフォルトの名無しさん2014/12/05(金) 10:11:29.20ID:sLA7oQpI
Pythonにクロージャは無い(キリッ

736デフォルトの名無しさん2014/12/05(金) 11:25:40.15ID:viBzu9Eo
さあ728さん、クロージャとラムダの同一性の説明どーぞ!

737デフォルトの名無しさん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使わずにこれでおk

738デフォルトの名無しさん2014/12/05(金) 12:31:26.53ID:+5KFbbdu
動的言語には型名を考えるコストがない
ある物の名前がラムダかクロージャか議論するのに何時間かかるか考えてみろ

739デフォルトの名無しさん2014/12/05(金) 13:25:22.71ID:eWvM3tpo
>>738
動的言語でも型名はあるんじゃ。もし言語がサポートしてなくても何かつけそう。

740デフォルトの名無しさん2014/12/05(金) 13:38:18.27ID:AoGRS1Po
>>738
唯一神クラスですか?

741デフォルトの名無しさん2014/12/05(金) 16:19:55.77ID:+5KFbbdu
インタフェース継承で派生クラスの名前は必須ではない
これは静的でも成り立つ
更に突き詰めると必要なのはメンバの名前のみなのでインタフェースの名前も不要

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

742デフォルトの名無しさん2014/12/05(金) 18:10:35.44ID:N759beub
>>741
> 実装継承にこだわっているので名前は必要

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

743デフォルトの名無しさん2014/12/05(金) 20:31:39.15ID:+TXyzC2W
>>738
何言ってんだ?
型がなくてどうやってオブジェクトをnewするんだよ?w
new 型名 って書くだろが。

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

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

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

744デフォルトの名無しさん2014/12/05(金) 20:46:05.48ID:+TXyzC2W
>>741
> インタフェース継承で派生クラスの名前は必須ではない

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

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

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

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

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

745デフォルトの名無しさん2014/12/05(金) 20:46:44.48ID:+5KFbbdu
実装に名前をつけて保存するからだろ

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

746デフォルトの名無しさん2014/12/05(金) 20:50:24.12ID:+5KFbbdu

747デフォルトの名無しさん2014/12/05(金) 21:12:23.79ID:+TXyzC2W
>>745
> 下手すると名前の長さが中身より長くなるから

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

748デフォルトの名無しさん2014/12/05(金) 21:28:30.39ID:5SBzstV5
>>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)

749デフォルトの名無しさん2014/12/05(金) 21:30:47.47ID:+TXyzC2W
> と書いたように、静的型付けの C++ だけでは COM を使わなければ
> コンポーネントの動的結合ができない

別にDLLでもできるけど?

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

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

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

750デフォルトの名無しさん2014/12/05(金) 21:32:11.34ID:+TXyzC2W
2分で論破はやり過ぎだと反省しているw

751デフォルトの名無しさん2014/12/05(金) 21:35:46.33ID:+TXyzC2W
Linuxは静的型付け言語のC言語で〜
拡張子soの動的リンクライブラリが〜

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

752デフォルトの名無しさん2014/12/05(金) 22:06:36.60ID:viBzu9Eo
Smalltalkの場合、名前のないクラスは名前のあるクラスと同じ数だけ存在する。だから>>741は正しくない。
ちなみにサブクラスを定義するためにはクラスインスタンスにメッセージを送信する。インスタンスを生成するのもクラスインスタンスにメッセージを送信することで行う。その意味でも、クラスに名前は必須ではない。

753デフォルトの名無しさん2014/12/05(金) 22:08:26.02ID:5SBzstV5
>>749
DLL だけでは柔軟なコンポーネント結合が実現できなかったから、
Microsoft は COM(Component Object Model) という技術を開発した
言語に依存しないバイナリ互換性も COM の特徴であるけれど、
仮に C++ に閉じた開発であっても COM は必要になる

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

754デフォルトの名無しさん2014/12/05(金) 22:40:22.11ID:5SBzstV5
>>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

755デフォルトの名無しさん2014/12/05(金) 23:20:42.11ID:5SBzstV5
>>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 等には)存在しない特徴

756デフォルトの名無しさん2014/12/05(金) 23:41:12.21ID:+5KFbbdu
問題
yieldを用いると内部イテレータ風の書き方で外部イテレータを作ることができる
このイテレータの名称として適切なのは
「外部イテレータ」「内部イテレータ」のどちらか答えよ

757デフォルトの名無しさん2014/12/06(土) 04:27:17.30ID:VJF2Er6M
Pythonでも普通にyieldで
「内部イテレータ風の書き方で外部イテレータを実装する」
ことができる。
Smalltalkにも(ちょっと無理矢理っぽいが)yieldの実装がある。

758デフォルトの名無しさん2014/12/06(土) 09:50:46.00ID:75gyZyE4
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

759デフォルトの名無しさん2014/12/06(土) 10:16:45.25ID:awxYdbKb
visitメソッドのレシーバと引数のどっちがVisitorか迷うことがある

760デフォルトの名無しさん2014/12/06(土) 11:43:34.93ID:VJF2Er6M
どうしてRubyを推したい人は
他言語に元からある機能をなかったことに
したがるのだろうか?

761デフォルトの名無しさん2014/12/06(土) 11:53:26.46ID:75gyZyE4
>>760
それはMatzやその取り巻きが悪いんだよ。
まるでRubyが初めてであるようにもとれる言い方で
信者をミスリードし続けてきた立派な成果だ。
旧Mac信者がジョブズの印象操作で育成された経緯に似ている。

762デフォルトの名無しさん2014/12/06(土) 12:39:03.22ID:awxYdbKb
printf("%sには%sがあるから\n", "ruby", "yield");

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

7637552014/12/06(土) 16:06:50.42ID:viXCL8M/
>>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 のイテレータを忠実に実装しているようだ

764デフォルトの名無しさん2014/12/06(土) 16:45:53.73ID:viXCL8M/
>>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を推したい人は
 > 後から追加された機能を元からあったことに
 > したがるのだろうか?
と訂正したほうがいいだろね

765デフォルトの名無しさん2014/12/06(土) 16:55:53.06ID:tymH4H6t
る厨、渾身の反撃

766デフォルトの名無しさん2014/12/06(土) 18:06:07.33ID:dOSwxHPK
>>764

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

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

767デフォルトの名無しさん2014/12/06(土) 18:10:44.25ID:dOSwxHPK
>>764のPEP255を見ると、CLUには言及されているけどRubyは出てこないんだな
これは確かにRuby使いには腹立たしいかもなぁ
まあRoR以前のRubyはマイナーだったから仕方ないんだけど

768デフォルトの名無しさん2014/12/06(土) 18:17:10.96ID:tymH4H6t
>>766
なんだ、る厨のマッチポンプか。つまらん。

769デフォルトの名無しさん2014/12/06(土) 18:21:50.32ID:tymH4H6t
> Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴

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

770デフォルトの名無しさん2014/12/06(土) 18:37:35.84ID:dOSwxHPK
内部イテレータ風の記法が大規模開発でどう役立つか

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

771デフォルトの名無しさん2014/12/06(土) 18:41:59.78ID:viXCL8M/
>>767
Python にジェネレータが導入された時期(2001年)からすれば
Ruby の成功を見てyield文を追加したんだろうけど、
さすがに「Ruby の真似をしました」とは書けないから CLU にしたんだろね


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

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

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


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

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

772デフォルトの名無しさん2014/12/06(土) 18:56:12.98ID:dOSwxHPK
2001年にRubyが成功してたとか、何のジョークですか
RoRは2004年ですよ

773デフォルトの名無しさん2014/12/06(土) 19:13:11.97ID:Ee/H8Kvv
CLUとかPythonのyieldはジェネレータだけど、Rubyのは違くね?
Rubyにジェネレータ入ったのって1.9だろ?

774デフォルトの名無しさん2014/12/06(土) 19:22:45.98ID:dOSwxHPK
Rubyのyieldは見た目が似てるだけでCLUのとは別物
正当に継承してるのはPythonの方でした、というオチ?

775デフォルトの名無しさん2014/12/06(土) 19:30:05.03ID:Ee/H8Kvv
>>771
当時のSatherはRubyよりは有名だっただろうね海外では

776デフォルトの名無しさん2014/12/06(土) 20:16:53.72ID:viXCL8M/
>>772
2001年に O'Reilly から "Ruby in a Nutshell" が出版され世界メジャーデビューを果たしている
・Ruby in a Nutshell&#xA0;-&#xA0;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使いはウソツキばかりなのかね

777デフォルトの名無しさん2014/12/06(土) 20:40:35.48ID:dOSwxHPK
>>776
> November 2001

PEP255の後じゃん

778デフォルトの名無しさん2014/12/06(土) 21:59:22.89ID:7vCPkvQk
>>755は内部イテレーターがCLU発祥でRubyがその初継承だと言いたいの?
それとも、yield&コルーチン的な仕組みでイテレーターを生成できるのが
そうだと言いたいの? どっち?

779デフォルトの名無しさん2014/12/06(土) 22:26:02.16ID:tymH4H6t
きっと、あれだろう。
「yieldを使うなどしてRubyのようにCLUからイテレーターをコピーしたのはRubyが最初」
とかいうガッチガチの縛り付き起源論。

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

780デフォルトの名無しさん2014/12/06(土) 23:01:36.75ID:q7blqefO
>>770
木構造で格納した値を順番に取り出すとか?
うーんピンとこない

781デフォルトの名無しさん2014/12/07(日) 00:03:15.33ID:zkEhiByJ
結局、最新の技術を取り入れた静的型付け言語が
最も優れた言語になるのかな。

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

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

783デフォルトの名無しさん2014/12/07(日) 00:14:16.44ID:dQg0RQig
>>781
だろうね。

動的型付け言語はいわば実験台。
どこで出来たものに型を取り付けることで
完全体になる。

784デフォルトの名無しさん2014/12/07(日) 00:45:01.66ID:svj68kfn
>>782
> 内部イテレーターがCLU発祥
だとすれば
Smalltalkの#do:はこの場合どういう扱いになるの?
あれも内部イテレーターだろう。

785デフォルトの名無しさん2014/12/07(日) 00:49:15.39ID:3Elo+9Qw
嘘はよくないけど逃げるのはよいよね
間違いを認めるとかはどうでもよい

786デフォルトの名無しさん2014/12/07(日) 01:50:41.36ID:hGORpEWm
>>784
Smalltalk のアレも内部イテレータだね

反復(iteration)をコルーチンとして抽象化する最初の発想は、CLU と Smalltalk の共通の祖である Simula 67 で生まれ、
それはジェネレータと呼ばれていた
そして、その発想はどちらの言語にも継承されたけど、静的型付けな手続き型言語である CLU と
動的型付けなオブジェクト指向言語である Smalltalk とでは、実現方法が異なった

CLU は iter 宣言と yield 文という抽象化向けの構文を導入し、反復処理の表現(プログラミング)を洗練させた
また反復の概念を整理/形式化し、それにイテレータという名称を与えたのは CLU の功績
だからイテレータの始祖は CLU であると、一般には認知されている

それに対してブロック(=クロージャ)を持つ Smalltalk は、(CLU のように苦労することなく)反復処理を抽象化できた
実際、Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない
結果として Smalltalk のコミュニティの中でジェネレータは反復処理のプログラミング技法、
いわゆるイディオムとしては認知されていたけど、それが学術的に議論されることは無かった
(実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた)
こうした、ある新しく登場した概念が実は Smalltalk の世界だとありふれたイディオムでしかなかったという現象は、
(たとえばデザインパターンのように)しばしば見かけられる

787デフォルトの名無しさん2014/12/07(日) 02:03:23.69ID:hGORpEWm
>>785
結局、逃げたってことなのね
それならそれで、いいんじゃないかな
では、これでスレ違いなイテレータの話題は終わりにしよう

反復処理を抽象化するイテレータは大規模開発にとって重要だと思うけど、
CLU と Smalltalk の例(>>786)のように
静的型付け/動的型付けのどちらにも共通する概念だから、
スレの主旨からは外れていると思う

788デフォルトの名無しさん2014/12/07(日) 08:12:25.48ID:vPGA0H7X
Rubyコミュニティによるイテレータの歴史歪曲については
少なくともRubyが再発見したおかげで内部イテレータが再評価されたわけではない(>>777)し、
>>755には他にも事実誤認があるのだからいくら言葉尻で言い訳しても墓穴が大きくなるだけ

789デフォルトの名無しさん2014/12/07(日) 08:23:27.33ID:NlsKlGNA
ルビーより後に実装されたのはみんなルビーの真似w

790デフォルトの名無しさん2014/12/07(日) 09:49:05.54ID:3Elo+9Qw
歴史歪曲を考える暇があったら、副作用の順序を間違える事案について考えよう

791デフォルトの名無しさん2014/12/07(日) 09:51:11.11ID:bfkTF4nN
ここの住民には無理

792デフォルトの名無しさん2014/12/07(日) 09:56:13.58ID:NlsKlGNA
>>776-777の流れが全てを物語っているw

793デフォルトの名無しさん2014/12/07(日) 13:22:05.08ID:6EqZg1tl
>>786
> Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない

next は分かるのですが、first を定義する必要があるというのは初耳です。
そのようなプロトコルが規定されているのは何というSmalltalk処理系ですか?
あるいはそのように記述された文献をお示しいただければさいわいです。

あと、Smalltalkの外部イテレーター(内部イテレーターとしても使用できる)としては
Streamが有名ですが、これとおっしゃっておられる「Smalltalkのジェネレーター」との
関係を教えてください。

> 実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた

寡聞にして知りませんでした。
たとえば具体的にどんな文書でそのような用語が使われていたか教えていただけると助かります。

794デフォルトの名無しさん2014/12/07(日) 13:42:54.66ID:acBjRoXT
> Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない

一つ疑問があるんだけどさ、firstとnextをジェネレータとは
違う用途で使ったオブジェクトはどうなるの?
正しく動かないと思うけど。

そうすると、firstとnextはジェネレータで使うための名前ですって
予約語みたいな扱いになっているということ?

795デフォルトの名無しさん2014/12/07(日) 14:10:40.21ID:3Elo+9Qw
>>794
お前はなぜ正しく動かないと分かったのか
分かったのに分からないふりをする動機は何か
この動機を打ち消すことができれば生産性が上がるんじゃないか

796デフォルトの名無しさん2014/12/07(日) 14:18:07.50ID:acBjRoXT
>>795
何を言ってるのさ?
純粋に疑問になっただけ

例えばfirstという名前で、初期化処理
secondという名前で、2番目の処理、
thirdという名前で3番目の処理
みたいなことをしているオブジェクトがあったとしたら
当然ジェネレータとしては使えない。

だからfirstという関数名はジェネレータのfirstの
仕様を守らないといけないというルールがあるのか?って話なんだが。

797デフォルトの名無しさん2014/12/07(日) 18:16:20.48ID:hGORpEWm
>>793
>next は分かるのですが、first を定義する必要があるというのは初耳です。
>そのようなプロトコルが規定されているのは何というSmalltalk処理系ですか?
>あるいはそのように記述された文献をお示しいただければさいわいです。

1986年に書かれた "The Generator Paradigm in Smalltalk" という文書です
題名でググるとPDFで見つけられます


>あと、Smalltalkの外部イテレーター(内部イテレーターとしても使用できる)としては
>Streamが有名ですが、これとおっしゃっておられる「Smalltalkのジェネレーター」との
>関係を教えてください。

単に ReadStream クラスが Smalltalk の作法(慣習)に沿って設計されたのだと思いますが、
それを裏付けるソース(文献)は知りませんし、それ以上の関係も知りません


>> 実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた
>
>寡聞にして知りませんでした。
>たとえば具体的にどんな文書でそのような用語が使われていたか教えていただけると助かります。

上記の文献では、ジェネレータという用語が使われています


イテレータという用語は1974年に発表されたCLUの論文によって世に知られるようになりました
自分の知る範囲で、Smalltalk とイテレータとの関連が議論されたのは1995年出版のデザパタ本(GoF)が最初だと思います
少なくともブルーブックの名で知られている Smalltalk のバイブル "Smalltalk-80: The Language and Its Implementation"
では、イテレータという用語は使われていません
もしも CLU 以前の時代に Smalltalk とイテレータを扱った文献が存在していたなら、ぜひ教えてほしいですね

798デフォルトの名無しさん2014/12/07(日) 19:37:57.79ID:eR9x6pgx
>>797
なるほどティモシー・バットの実装・主張でしたか。
Smalltalkの常識が役に立たないわけです。^^;

本家Smalltalk(の、ごく初期の実装であるSmalltalk-72)からある
Streamと彼の言うジェネレータとの関係は、
彼のかなり風変わりなSmalltalk実装であるLittle Smalltalkに
ついて書かれた書籍にその記述が見つけられました。

http://sdmeta.gforge.inria.fr/FreeBooks/LittleSmalltalk/ALittleSmalltalk.pdf

In the Smalltalk-80 language (Goldberg83), the concept of
streams is in many ways similar to the idea of generators.
For the most part, streams use a slightly different interface,
namely the pair of messages reset (which initializes the
generator but does not return any value) and next (which is
used for both the first and all succeeding elements). The
message do: is adapted from the streams of (Goldberg83). An
article by Deutsch (Byte 81) discusses in more detail many
aspects of generators in the Smalltalk 80 system.

ありがとうございます。

あと老婆心ながら、パッドがSmalltalkについて書くときは、
暗黙のうちに彼独自仕様のLittle Smalltalkを前提にしている
ことがあるので、そこから得た知識をSmalltalkに一般化したり、
あるいは狭義には本家PARC謹製実装を指す「Smalltalk-80」という
呼称でそれを語るのは、聞き手に無用の混乱を招くので
今後は避けられた方がよいと思います。

799デフォルトの名無しさん2014/12/07(日) 20:20:51.08ID:hGORpEWm
>>798
結論としては、今のところ挙っているソース(文献)を前提とすれば:
・オリジナルの Smalltalk コミュニティでは概念としてのイテレータは存在していなかった
・ただしコレクションやストリームの実装で用いられた Smalltalk の作法(慣習)は、
 デザパタ本(GoF)によって内部イテレータとして分類された
ということですかね

800デフォルトの名無しさん2014/12/07(日) 21:29:04.46ID:eR9x6pgx
>>799
> もしも CLU 以前の時代に Smalltalk とイテレータを扱った文献が存在していたなら、ぜひ教えてほしい

もとより、リスコフが件のループ処理の抽象化にイテレータと名付けて発表したのは1977年のこの文献
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.656&rep=rep1&type=pdf
だと思うのですが、そうすると同様のことを目指す類似の仕組みがあったとして、それを
「イテレータ」と呼称するには少なくとも1977年以降でなければ困難だと思うのですが、これは
1977年以前に実装され、活用されていたという事実を示せばいいという解釈でよろしいですか?

それとも、「イテレータ」という言葉を使っていないとダメという縛りでしょうか?

801デフォルトの名無しさん2014/12/07(日) 23:41:25.71ID:hGORpEWm
>>800
自分もその文献を参照して CLU がイテレータで生まれたと判断しました
だから、時期としてはそれ以前ということですね

またイテレータという名称にこだわる必要はありませんが、
first と next という作法で実現できる外部イテレータは
C++/Java だけでなくC言語でも実装できる一般的なプログラミング技法ですから、
CLU の内部イテレータからは外れるでしょう
またループ処理の抽象化はイテレータだけでなく LISP を始祖とする関数型言語の
map 関数がありますが、これをイテレータと呼ぶのは無理があるでしょう

CLU の内部イテレータは、当時のクロージャを持たない手続き型言語へ
コルーチンの仕掛けを洗練された形で組み込んだことに意義があると思います
もし CLU 以外にも、当時の手続き型言語の中でループ処理の抽象化に
取り組んだ研究があったなら、興味深いですね

802デフォルトの名無しさん2014/12/08(月) 08:33:17.02ID:voJSmgM1
>>801
つまり、
コルーチンを使っていなければ内部イテレータとは呼べない
という縛りですね?

803デフォルトの名無しさん2014/12/08(月) 09:55:18.35ID:kmGTZboH
外部イテレータは存在意義が分かるんだけど、
内部イテレータの存在意義が分からない
高階関数があれば全く不要じゃないの?こんなもんに予約語使うRubyは馬鹿なんじゃないの?

804デフォルトの名無しさん2014/12/08(月) 10:47:05.59ID:7TNBMlk3
結局、Rubyコミュニティ内でも、

> Rubyのイテレータは用途的にはCLUのイテレータよりも
> Smalltalkのブロック (を受け取るメソッド)に似ている
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/13374

という結論になっているんだね。

805デフォルトの名無しさん2014/12/08(月) 11:52:53.80ID:hyn7lotS
LispやSmalltalkは低級言語に似てないからダメ
同じ理由で高階関数もダメだろうと高を括っていたんじゃないか
ところが現実はC++でも高階関数を使いこなせるレベルになりつつある

806デフォルトの名無しさん2014/12/08(月) 19:51:47.86ID:Ag3PuK/D
言語の仕様の変更が柔軟なのは動的型付け言語なんだよな。
型のことを考える必要がないぶん、アイデアをすぐに実装できる。

だけど、そのアイデアそのものは静的型付け言語でも実装可能。
型を考える分だけ時間がかかるだけ。

動的型付け言語の機能はほぼ全て静的型付け言語で実装できるし、
型安全になりさらにいい形で実装される。

8078012014/12/08(月) 21:41:44.49ID:9AWpAGuY
まず >>801 の日本語が変だったので訂正
X: 自分もその文献を参照して CLU がイテレータで生まれたと判断しました
O: 自分もその文献を参照してイテレータが CLU で生まれたと判断しました


>>802
いや、CLU はコルーチンを使っていないし、そんな縛りはありませんよ
ループ処理を生産者/消費者に分割するプログラミング技法としてコルーチンが
CLU 以前から知られていましたけど、保守のしづらいコードになりがちでした
そのコルーチンを使わずにループ処理を抽象化したのが CLU のイテレータです


>>803
> こんなもんに予約語使うRubyは馬鹿なんじゃないの?

だとしたら、ジェネレータ(外部イテレータ)が重要な言語の構成要素であり、
なおかつ高階関数もすでに備えていたにもかかわらず、
後からわざわざ予約語 yield を追加した Python の PEP 205(>>764) は
Ruby 以下の大馬鹿ってことですね

自分としては、ジェネレータを(まるで内部イテレータのように)簡潔に定義できるようにすることを
意図した PEP 205 の判断は適切であったと思っていますけど、
まあ、仕様追加を容認/批判するのは人それぞれなんでしょうね....

808デフォルトの名無しさん2014/12/08(月) 21:47:10.82ID:NhV7D2A0
外部イテレータを内部イテレータかのように記述できるPythonのyieldには価値がある
だからJavascript(ES6)などにも採用されている

一方、Rubyの内部イテレータには価値が無い
単純な話じゃん

8098012014/12/08(月) 22:43:49.37ID:9AWpAGuY
>>804
>>754 で書いたように Ruby は LISP をベースに設計され、
ブロックも LISP のクロージャに由来します
だから、同じブロックを使う Smalltalk と意味が似るのは不思議じゃないですね

実際 >>755 のイテレータ定義は、yield を使わなくとも Smalltalk の value メッセージに
相当するメソッド Proc#call へと単純に置き換えることができます
 def from_to(first, last, &block)
   n = first
   while n <= last
     block.call n
     n += 1
   end
 end

Ruby と CLU の関連性に関しては、(あくまで私見ですが) LISP を心臓部(意味)として、
(S式ではなく)Perl に代表される手続き型言語のプログラマに受け入れられる表層の皮(構文)で
包んだ時に、手続き型言語である CLU のイテレータという概念を参考にしたのだと思います
だから外観は CLU のイテレータのように見えるけど、その実装は LISP/Smalltak と類似するという
結果になるのでしょう

8108012014/12/08(月) 23:29:50.99ID:9AWpAGuY
>>805
元々の質問者(>>800, ID:eR9x6pgx)の方が Smalltalk に詳しそうなので、
1997年の CLU および Smalltalk-80 以前における初期の Smalltalk の
(後にGoF本で内部イテレータと呼ばれることになる)ループ処理設計の誕生話を期待していました
自分は Smalltalk にはそれほど詳しくないんで、それ辺りの歴史を披露してもらえたら嬉しかったですね

あるいは1970年代に Scheme で生まれた継続(コンティニュエーション)の概念や、
並行ループ処理をプロセス構造で表現する CSP や実装言語である Occam あたりかもしれないと
想像していました
これら現在ではイテレータには分類されていないけど実はループ処理の抽象化に関連していた
過去の埋もれた知見が得られるか、つまり何かを再発見できるかと期待していたんですが、
結局、想定されていたのは良く知られた(=ありふれた)高階関数だったのですかねぇ.....

まずは彼からのレスを待つことにします

811デフォルトの名無しさん2014/12/08(月) 23:59:43.81ID:wXlNa9C1
>>807
> CLU はコルーチンを使っていないし、そんな縛りはありません

おっしゃりたいことがちょっとよく分かりません。

> 801
> CLU の内部イテレータは、―
> コルーチンの仕掛けを洗練された形で組み込んだことに意義がある

これは、コルーチン“的な”仕掛け、という意味で、
コルーチンである必要はないということですか?

例えば、まだクロージャをもたないSmalltalk-76の頃からあった

stream ← #(1 2 3) asStream.
for x to stream do [user show: x; cr]

という内部イテレータとして使える外部イテレータである
ストリームという発案が

> C++/Java だけでなくC言語でも実装できる
> 一般的なプログラミング技法

とか

> 保守のしづらいコードになりがち

というよくわからない難癖で排除される理由も理解しかねます。
てっきり、コルーチンでないからダメなのかと思ったのですが?

812デフォルトの名無しさん2014/12/09(火) 00:34:52.29ID:7jn1Y2FE
>>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....
どちらが言語としての先見性に優れていたか、単純な話じゃん

813デフォルトの名無しさん2014/12/09(火) 01:30:40.08ID:5nnX6sRe
>>776-777で完全論破されてんのに
まだPythonのyield導入にRubyは無関係だって認めてないのかw

814デフォルトの名無しさん2014/12/09(火) 02:00:48.32ID:WiqIx9bM
>>811
× for x to stream do [user show: x; cr]
○ for% x from: stream do% [x print. user cr]

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

815デフォルトの名無しさん2014/12/09(火) 09:46:11.30ID:RdsPil5f
Ruby厨が過去を振り返るのに忙しいのは、
もう進歩が止まっちゃったから?
TwitterがScalaに乗り換えた件でケチが付き始めて、
今ではパクったはずのperlより遥かにシェア落としてるんだっけ?

816デフォルトの名無しさん2014/12/09(火) 16:22:39.15ID:j4N/cP02
まさかルビ厨がPythonに言語仕様の後方互換性で喧嘩を売る現場を目撃するとは..w

817デフォルトの名無しさん2014/12/09(火) 17:46:01.03ID:64I0Ciqv
yieldが文から式に変わったことで動かなくなったコードってどんなの?
後方互換性を放棄したと言うんだから、あるはずだよね?

818デフォルトの名無しさん2014/12/09(火) 21:39:51.00ID:7jn1Y2FE
>>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 メッセージが実装された(外部イテレータとして)のオブジェクトだったのでしょうか?

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

819デフォルトの名無しさん2014/12/09(火) 23:30:56.22ID:4fop6YGQ
外部イテレータとは while, for 等の伝統的構文が外から見えるという意味
例えばイベント駆動をやりたいときにプログラマが明示的にwhile文を書くようなもの
イテレータが様々なイベントをreturnすれば副作用もあるし戻り値の型も宣言できない

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

820デフォルトの名無しさん2014/12/10(水) 07:35:20.61ID:8efWXp1v
結局Pythonのyieldの後方互換性問題って何だったの?
ルビ厨お得意のFUDですか?

821デフォルトの名無しさん2014/12/10(水) 10:47:06.06ID:UPnzY5Pb
>>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 からだと思います。

822デフォルトの名無しさん2014/12/10(水) 21:59:38.00ID:veDvxwge
>>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

823デフォルトの名無しさん2014/12/11(木) 11:19:57.50ID:QX1K4VF2
>>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 "

824デフォルトの名無しさん2014/12/11(木) 13:25:53.28ID:QX1K4VF2
>>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 "

825名無しさん@そうだ選挙に行こう2014/12/14(日) 08:35:34.66ID:Im2X3v/S
>>822
> Smalltalk-80 に影響を受けながら

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

826デフォルトの名無しさん2016/05/01(日) 15:12:30.55ID:tKi6j9CT
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

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

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

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


The Covenant Project
概要

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

目的

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

特徴

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

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

新着レスの表示
レスを投稿する