動的言語で大規模開発

1 ：uy：2012/07/24(火) 09:10:42.04 .net

たててみた

2 ：uy：2012/07/24(火) 09:14:05.25 .net

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

3 ：デフォルトの名無しさん：2012/07/24(火) 09:15:00.16 .net

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

4 ：デフォルトの名無しさん：2012/07/24(火) 10:57:46.72 .net

そのコピペ飽きた

5 ：デフォルトの名無しさん：2012/07/24(火) 11:54:29.79 .net

イジメ自殺が社会問題となっている。新聞でもテレビでも識者と称する恥知らずたちが、おためごかしの助言を垂れ流して小銭を稼いでいる。
イジメに苦しむ少年少女よ、あんなものが何の役にも立たないことは、君たち自身が一番良く知っている。
唯一最良のイジメ対処法は報復に決まっているではないか。

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

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

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

呉智英

6 ：デフォルトの名無しさん：2012/07/24(火) 18:55:17.05 .net

動的言語で大規模開発は可能

以上

7 ：デフォルトの名無しさん：2012/07/24(火) 20:04:33.83 .net

【スポーツ】「五輪期間中はブログをやめて」ＪＯＣが東原亜希さんに要請★２
http://ikura.2ch.net/test/read.cgi/curry/1246361020/

8 ：デフォルトの名無しさん：2012/07/24(火) 20:07:03.66 .net

あるのなら例をあげろよ。

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

9 ：デフォルトの名無しさん：2012/07/24(火) 22:26:26.07 .net

いくらでもあるのに見つけられないってバカなのか

10 ：デフォルトの名無しさん：2012/07/24(火) 22:59:20.68 .net

１万って大規模じゃないだおｒ

11 ：デフォルトの名無しさん：2012/07/24(火) 23:00:34.94 .net

もっと絞らんと、obj-cなんかも入ってきて切りがないでしょうに

12 ：デフォルトの名無しさん：2012/07/24(火) 23:18:45.95 .net

ばーか

13 ：デフォルトの名無しさん：2012/07/24(火) 23:20:31.92 .net

大規模開発は何を意味してるのかな
コード量かな
人数かな
人数多いとダメじゃないかな

14 ：デフォルトの名無しさん：2012/07/24(火) 23:37:16.89 .net

人数多いのはクソプロジェクトしかないから却下。

15 ：デフォルトの名無しさん：2012/07/24(火) 23:43:45.63 .net

win8はいつのまにか不可解なメトロを組み込むことになってしまった
動的言語じゃなくても大規模開発は難しい

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

死ね

17 ：デフォルトの名無しさん：2012/07/25(水) 01:21:12.37 .net

1万行って去年俺一人で趣味で書いた JavaScript の量じゃねえか。
もう二度とやらんと誓ったけど。
動的言語は砂上に楼閣建ててる感がヤバイわ。GWT なり Haxe なり使えよ。

18 ：デフォルトの名無しさん：2012/07/25(水) 01:25:38.55 .net

Browser Quest を見たパンピーどもの反応
→HTML5 スゲー！！JavaScript スゲー！！ マンセーマンセーマンセー！

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

19 ：uy：2012/07/25(水) 02:43:50.85 .net

「信頼できるコード」は徐々に増えていく
一見そう思えたが、修正しようとした時に問題が起き始めた。

影響範囲がわからない。

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

時間がかかってしまう。

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

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

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

20 ：uy：2012/07/25(水) 02:55:10.25 .net

コードはインターフェースと実装の2つにわかれるんだよ。

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


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

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

21 ：uy：2012/07/25(水) 03:36:50.02 .net

>>19-20
死ね


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

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

22 ：デフォルトの名無しさん：2012/07/25(水) 03:44:41.83 .net

uy以外の人に聞きたいが
「動的言語で書かれているヘッダ」ってなんのこと？

23 ：デフォルトの名無しさん：2012/07/25(水) 03:45:34.43 .net

１万行って少ないな。
1000行が10ファイルしか無い。

24 ：デフォルトの名無しさん：2012/07/25(水) 06:55:17.49 .net

LISPマシンやPrologマシンはどのくらいの規模だった？

25 ：デフォルトの名無しさん：2012/07/25(水) 08:11:19.64 .net

>>22
それすらわからないってバカ？
C言語で書かれたライブラリをインクルードするのか
動的言語で書かれたライブラリをインクルードするのか

26 ：デフォルトの名無しさん：2012/07/25(水) 08:13:27.92 .net

で、基本的に「自分以外」がかいたそういうヘッダってのは
「信頼できるコード」に含まれる
世界中で何百万人が使用しているものだから

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

以上

27 ：デフォルトの名無しさん：2012/07/25(水) 08:41:50.10 .net

>>25
動的言語で書かれているヘッダですよ？
どこにライブラリって書いてあるのですか？

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

28 ：デフォルトの名無しさん：2012/07/25(水) 11:41:35.75 .net

#include<stdio.h>知らないただのバカか

29 ：デフォルトの名無しさん：2012/07/25(水) 12:01:51.61 .net

世の中にはヘッダライブラリというのも存在する事も知らないただのバカか

バカは死ね

30 ：デフォルトの名無しさん：2012/07/25(水) 12:02:27.66 .net

動的リンクをしてない言語はライブラリをどのようにして使うかすら知らないバカか

バカは死ね

31 ：デフォルトの名無しさん：2012/07/25(水) 12:03:42.01 .net

初心者とバカは死ね

32 ：デフォルトの名無しさん：2012/07/25(水) 12:07:26.36 .net

今時の言語でヘッダをインクルードする言語なんて皆無だろ。

33 ：デフォルトの名無しさん：2012/07/25(水) 12:18:05.17 .net

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

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

34 ：デフォルトの名無しさん：2012/07/25(水) 18:00:32.03 .net

>>25
たった一個でいいから、実在の「動的言語で書かれているヘッダ」を示してくれ。
示してくれ。

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

35 ：デフォルトの名無しさん：2012/07/25(水) 21:59:50.81 .net

>>29
だから「動的言語で書かれたヘッダ（ライブラリ）」ってなんだって話だろ。

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

36 ：デフォルトの名無しさん：2012/07/25(水) 22:02:16.10 .net

動的言語はインターフェースの変更に弱い。

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

37 ：uy：2012/07/25(水) 23:41:23.25 .net

バカすぎワロタ
stdio.hでも食ってろ

38 ：デフォルトの名無しさん：2012/07/25(水) 23:46:37.20 .net

stdio.h ・・・C言語（静的型付け言語）のヘッダファイルです。これはライブラリではありません。

39 ：uy：2012/07/26(木) 00:16:15.80 .net

バカすぎワロタ
stdio.hでも食ってろ

40 ：デフォルトの名無しさん：2012/07/26(木) 00:16:45.42 .net

uy以外の人に聞きたいが
「動的言語で書かれているヘッダ」ってなんのこと？

41 ：デフォルトの名無しさん：2012/07/26(木) 00:17:53.75 .net

初心者スレいけよ低脳

42 ：uy：2012/07/26(木) 00:20:16.84 .net

バカすぎワロタ
stdio.hでも食ってろ

43 ：uy：2012/07/26(木) 00:24:29.43 .net

初心者黙った

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

44 ：uy：2012/07/26(木) 00:31:36.95 .net

初心者死ね

45 ：デフォルトの名無しさん：2012/07/26(木) 00:34:22.77 .net

uy以外誰も答えられないってのが
答えになってる。

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

46 ：デフォルトの名無しさん：2012/07/26(木) 08:57:34.99 .net

そもそもヘッダってものがごくごく一部の言語にしかないので。

47 ：uy：2012/07/26(木) 10:04:04.91 .net

あ、言っとくけど誰もマジレスしなくていいからね
長文書かれると鬱陶しい

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

48 ：uy：2012/07/26(木) 10:10:59.41 .net

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

49 ：uy：2012/07/26(木) 10:14:59.12 .net

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

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

50 ：uy：2012/07/26(木) 10:31:38.47 .net

初心者は死すべし
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
　何　番　煎　じ　だ　？

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

51 ：デフォルトの名無しさん：2012/07/26(木) 11:24:08.18 .net

うん、だからもう 2ch なんて捨ててヨソに行ってよ。
ね。

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

52 ：デフォルトの名無しさん：2012/07/26(木) 11:58:59.94 .net

import java.util.List;

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

53 ：uy：2012/07/26(木) 12:44:30.56 .net

やっぱりjaverか･･･

54 ：uy：2012/07/26(木) 13:09:01.25 .net

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

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

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

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

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

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

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

57 ：uy：2012/07/26(木) 19:29:02.43 .net

>>53

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


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

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

58 ：uy：2012/07/26(木) 19:30:25.70 .net

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

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

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

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

http://doc.ruby-lang.org/ja/1.9.2/method/Module/i/include.html

60 ：uy：2012/07/27(金) 01:31:01.18 .net

rubyでincludeワロタ

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

61 ：uy：2012/07/27(金) 01:41:01.10 .net

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

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

分かったか？ゴミ

62 ：uy：2012/07/27(金) 01:43:01.28 .net

>>22
さっさと泣いて謝れ

63 ：デフォルトの名無しさん：2012/07/27(金) 03:22:37.53 .net

>>61
> requireやimportされているファイルは「ヘッダ」または「ヘッダライブラリ」と呼ぶ

はあ？

64 ：デフォルトの名無しさん：2012/07/27(金) 05:04:28.09 .net

　　　ッ「ペロバコナーンｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」

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

>57
http://doc.ruby-lang.org/ja/search/query:include/
http://doc.ruby-lang.org/ja/1.9.3/function/include_class_new.html
http://doc.ruby-lang.org/ja/1.9.3/method/Module/i/include.html
http://doc.ruby-lang.org/ja/search/query:%E3%83%98%E3%83%83%E3%83%80/

おまえこそググれよ。

>61
恥の上塗り。
笑いものになることに快感を覚えているのではなかろうか。

66 ：uy：2012/07/27(金) 08:14:28.84 .net

なんか忘れてるみたいだから書いておくね。

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

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


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

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

67 ：uy：2012/07/27(金) 19:36:37.93 .net

>>65
include（笑）


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

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

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

68 ：uy：2012/07/27(金) 19:38:30.34 .net

rubyのincludeは今の話しと違うだろ･･･
るりまサーチをGoogleと勘違いしている頭の悪さ

コイツは救えない

stdio.hでも食ってろカス

69 ：uy：2012/07/28(土) 08:07:31.39 .net

さっさと謝れ

70 ：デフォルトの名無しさん：2012/07/28(土) 11:02:45.57 .net

>>68
いやｗ
include 対象が「ヘッダ」だと書いたページをｗ
一個でもいいから探して来いよｗ

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

71 ：デフォルトの名無しさん：2012/07/28(土) 12:53:20.49 .net

>>61
30年プログラム書いてるけどはじめて聞いた。
勉強になるなあ。

72 ：デフォルトの名無しさん：2012/07/28(土) 15:23:50.83 .net

ファイルの始めに書かかれている、ライセンスや開発者名なんかはヘッダーと言えるような気もする。

73 ：uy：2012/07/28(土) 19:16:03.90 .net

>>71
煽りぬきで30年間何やってたんだ？

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

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

無知が騒いでいる

74 ：uy：2012/07/28(土) 19:20:53.36 .net

C言語では「.h」のヘッダーでインクルードしてdefineなど定数宣言したり
クラス、構造体の宣言だけを行うこともある

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

分かったかゴミ？

さっさと初心者は死ね

75 ：uy：2012/07/28(土) 19:23:05.62 .net

>>70
まだincludeについて間違った見解もってんのお前？

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

ゴミは死ね

76 ：デフォルトの名無しさん：2012/07/28(土) 19:24:08.49 .net

初心者死ね

77 ：デフォルトの名無しさん：2012/07/28(土) 19:37:11.07 .net

>>73
pgr

78 ：デフォルトの名無しさん：2012/07/28(土) 19:38:43.08 .net

>>73
$ cat null-act.c
int main(void) {
return 0;
}

どこがヘッダですか?

79 ：uy：2012/07/28(土) 19:50:30.14 .net

ドヤ顔で500年以上前に流行っていまはもう使われてないC言語っていうんだっけそれ
そんなもののソース出されても正直困る

歴史に埋もれて市ね

80 ：uy：2012/07/28(土) 20:01:44.24 .net

テキストファイルの上の部分がヘッダとか
見苦しい言い訳をしているが、

それだと

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

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

81 ：デフォルトの名無しさん：2012/07/28(土) 21:11:15.85 .net

ゴミは死ね

82 ：デフォルトの名無しさん：2012/07/29(日) 00:41:12.87 .net

ゴミグラマ死ね

83 ：デフォルトの名無しさん：2012/07/29(日) 01:23:55.92 .net

死ねゴミ

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

ゴミ

85 ：デフォルトの名無しさん：2012/07/29(日) 12:16:42.75 .net

Matz はどういうだろうね？

86 ：デフォルトの名無しさん：2012/07/29(日) 12:57:02.43 .net

cに対する煽りが半端でつまらんな
もっとくやしく

87 ：デフォルトの名無しさん：2012/07/29(日) 17:38:17.52 .net

動的言語における大規模開発の適性については、すでに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のような大型機へのアクセス機能などの特徴も備えている。

88 ：uy：2012/07/29(日) 18:11:52.22 .net

今は1980年ではない。

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

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

89 ：デフォルトの名無しさん：2012/07/29(日) 19:03:44.51 .net

Smalltalkは当時からすでに下手な静的型言語より手厚いIDEのサポートがデフォだから
動的言語の適性を示す例としては反則だろう。

90 ：uy：2012/07/29(日) 19:04:48.12 .net

Smalltalkって今どうなったんだ？

91 ：デフォルトの名無しさん：2012/07/29(日) 20:19:48.62 .net

本家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 .net

変わり種と言えば、処理系まるごとOODBシステムと化したGemStone/Sというのもある。
http://www.gemstone.com/products/gemstone

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

93 ：デフォルトの名無しさん：2012/07/29(日) 21:01:18.67 .net

>>89
つーかSmalltalkは、動的に型チェックしたり、
型をファーストクラスオブジェクトとして使えるけど、
コンパイル時に強い型付けもしてるからな。
静的型付けもうまく組み合わせて使える。

94 ：uy：2012/07/29(日) 21:08:13.04 .net

Smalltalkってウェブ関連では使われてないな。

95 ：デフォルトの名無しさん：2012/07/29(日) 21:22:37.41 .net

OO機構が組み込まれているコンパイル志向の言語で、型の弱い言語ってあるかい?

96 ：デフォルトの名無しさん：2012/07/29(日) 21:30:00.55 .net

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

>>93
> コンパイル時に強い型付けもしてるからな。
> 静的型付けもうまく組み合わせて使える。

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

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

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

98 ：uy：2012/07/29(日) 23:19:47.17 .net

>>85
まづは普通に、「作れるんじゃね？」みたいな事言いまくってるよ

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

99 ：uy：2012/07/29(日) 23:31:19.65 .net

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

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


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

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

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

100 ：uy：2012/07/29(日) 23:33:18.42 .net

ruby言語以外にもrubyと同じ機能はあったりするが、

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

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

101 ：デフォルトの名無しさん：2012/07/29(日) 23:37:48.53 .net

Rubyはせいぜい10万行が限界。
50万行越えのコードは組めたとしてもメンテなんかぜったい無理。
だいたいコード以前に20万行のテキストすらまともに扱えないんだから。

102 ：uy：2012/07/29(日) 23:55:49.89 .net

まともな設計するなら数万行単位で、なんらかの敷居を作れよバカ
なんで1個のプロジェクトに数十万行とか詰め込みたがるわけ、バカなの死ぬの

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

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

103 ：uy：2012/07/29(日) 23:59:56.90 .net

そもそも10万行超えたらダメになるような設計しかかけない分際でレスされても困るよなぁ･･･
失敗談でも語っていくか？
君はどこで躓いちゃったの？
どこで間違えたの？
初心者は死ね

104 ：デフォルトの名無しさん：2012/07/30(月) 00:06:53.12 .net

rails10万行程度ですでにカオス状態の食べログェ…
http://d.hatena.ne.jp/kanz-labs/20110811/1313079667

105 ：デフォルトの名無しさん：2012/07/30(月) 01:03:40.99 .net

じゃあ俺は20万行かくよ

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

106 ：デフォルトの名無しさん：2012/07/30(月) 01:04:37.66 .net

＞ちょっと関係の話だったりする
関係のない話

107 ：デフォルトの名無しさん：2012/07/30(月) 01:12:40.95 .net

よく知ってるRailsアプリが10万行クラスで破綻と聞いて、ずいぶんトーンダウンしたな。

108 ：uy：2012/07/30(月) 01:53:22.77 .net

動的言語で10万行ってさ
一体そんなに何かいてんの？
動的言語だぞ？
動的言語なのにJAVAと同じようにそっくりそのまま書いてるのかなって疑ってしまう

109 ：uy：2012/07/30(月) 02:03:23.80 .net

コードの大半はテストだろう。

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

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

110 ：uy ◆DU14dte9SY ：2012/07/30(月) 03:09:22.88 .net

I am a hikikomori ,
So ,i have not participated in organization of the system.
my written message is all on my dream.

111 ：uy：2012/07/30(月) 05:10:48.69 .net

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

112 ：uy：2012/07/30(月) 06:15:27.56 .net

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

113 ：デフォルトの名無しさん：2012/07/30(月) 09:29:16.89 .net

プロジェクトよりテストのコードのほうがでかくなる
本体120mbテスト600mbみたいな

114 ：デフォルトの名無しさん：2012/07/30(月) 12:30:38.93 .net

>>98
ruby の include の対象を、ヘッダと呼ぶことについて、Matz がどう言うだろうね、って話。

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

115 ：uy：2012/07/30(月) 12:47:33.25 .net

じゃあやってみろ

116 ：デフォルトの名無しさん：2012/07/30(月) 12:58:18.64 .net

>>104
> Railsは大規模開発適しているということでした

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

117 ：デフォルトの名無しさん：2012/07/30(月) 14:08:36.23 .net

誰だかわかんねー個人ブログ引っ張ってくる奴もゴミ

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

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

http://twitter.com/Medicalware/status/229506991196876800

119 ：デフォルトの名無しさん：2012/07/30(月) 18:05:59.91 .net

>>114
ソース出してくれればいいんだよ。
「プログラミング言語Ruby」でも「たのしいRuby」でも何でもいいが、
何ページに「ヘッダ」が使われてるってね。

120 ：デフォルトの名無しさん：2012/07/31(火) 00:41:17.19 .net

ヘッダの意味がわかってないんじゃないか

121 ：uy：2012/07/31(火) 10:19:41.99 .net

こうして一人ずつ発狂して
uy粘着と化す

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

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

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

122 ：uy：2012/07/31(火) 10:28:44.35 .net

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

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

a , b = c , d , e

とか、さ

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

123 ：デフォルトの名無しさん：2012/07/31(火) 11:27:26.69 .net

ヘッダを include できるし、xor で and や or を作れるし、素晴らしいね！

124 ：uy：2012/07/31(火) 12:01:56.24 .net

何でこいつはいつまでもrequireとincludeの動作を覚えないの

125 ：uy：2012/07/31(火) 12:03:08.37 .net

あー言っちゃった･･･

126 ：uy：2012/07/31(火) 21:49:07.39 .net

ちんこ

127 ：uy：2012/08/01(水) 00:16:52.93 .net

死ねゴミ

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

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


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

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

129 ：デフォルトの名無しさん：2012/08/03(金) 06:32:47.82 .net

二度と話しかけんなよ

130 ：デフォルトの名無しさん：2012/08/11(土) 10:20:21.60 .net

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

131 ：uy：2012/08/11(土) 11:11:11.81 .net

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

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

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

132 ：デフォルトの名無しさん：2012/08/11(土) 12:03:04.92 .net

本番環境にコンパイラ入れるな

133 ：デフォルトの名無しさん：2012/08/12(日) 00:59:20.15 .net

使い分けるもんじゃないのか

134 ：uy：2012/08/12(日) 10:00:40.69 .net

>>130
そんな「論外」のために言語変える意味はない
そいつを解雇しろよ

135 ：デフォルトの名無しさん：2012/08/12(日) 10:57:54.02 .net

勝手に書き換えるのは顧客のPGでしょ。

136 ：uY ◆gXFLM6waxs ：2012/08/19(日) 03:14:31.35 .net

あーーーもうメソッド名の変更って
この作業は割りと重要だな
aliasじゃダメなんだよ
気分的に無理

137 ：uY：2012/08/20(月) 19:41:34.56 .net

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

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

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

138 ：デフォルトの名無しさん：2012/08/20(月) 20:10:06.70 .net

そこまで言うのなら
ソースを見せてほしい

139 ：デフォルトの名無しさん：2012/08/20(月) 20:22:35.15 .net

何人でその期間?

140 ：デフォルトの名無しさん：2012/08/20(月) 21:17:46.18 .net

Rubyの習得は一瞬だよ
１万行書くのに１時間かからないだろう
問題はまともなデザインのソフトを作れるかどうか
デザインセンスの方が重要

141 ：uY ◆gXFLM6waxs ：2012/08/20(月) 22:31:47.89 .net

ごめん
やっぱ無理だ

Ruby無理

これ無理

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

ちょー危ない

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

142 ：uY ◆gXFLM6waxs ：2012/08/20(月) 23:02:29.91 .net

えっえっ嘘
プロジェクト本体でもバグ再現しなくなってた
もういいや
もうやだ
勝手に誰かが直してくれた

143 ：uY ◆gXFLM6waxs ：2012/08/20(月) 23:07:41.34 .net

なんか････文字化けしたメッセージがDUMPされた

144 ：uY ◆gXFLM6waxs ：2012/08/20(月) 23:45:21.01 .net

バグコードを追うためにコード減らしていく→まだバグでる→でる→でる
→あ、でなくなった戻そう→え？バグでないし、もっと戻そう→え？バグでねーじゃんあせｄｒｆｔｇｙふじ　→最初から

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

145 ：uY ◆gXFLM6waxs ：2012/08/21(火) 00:15:30.32 .net

はぁ、、つかれた、、
ライブラリと完全分離した結果
ライブラリではなくrubyのバグであることが確定した
ちかれた

146 ：デフォルトの名無しさん：2012/08/21(火) 01:10:35.50 .net

マイナー言語にはよくあること。
メジャー言語にもあるけどね。

147 ：uY：2012/08/21(火) 01:36:14.78 .net

もうやだ

148 ：uy：2012/08/21(火) 04:41:45.26 .net

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

149 ：デフォルトの名無しさん：2012/08/21(火) 09:21:42.24 .net

a, b = [1,2,3].cycle, ["a","b"].cycle
p (1..25).map{ |i| (i%5)!=0 ? a.next : b.next }

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

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

150 ：uY ◆gXFLM6waxs ：2012/08/21(火) 10:25:03.64 .net

あおりにすらならないは

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

151 ：デフォルトの名無しさん：2012/08/21(火) 10:30:02.52 .net

uyがかrubyがかはしらんけど
「糞コード量産力がはんぱない」のまちがいだろ

152 ：uy ◆gXFLM6waxs ：2012/08/21(火) 11:17:54.84 .net

どんだけ煽ってももう無理なんだよ･･･
もう完成しちゃってるんだ
設計そのものが
しかもおそらくrubyレベルの柔軟な言語じゃないと
到底作る事の出来ないシステムが･･･

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

153 ：uY：2012/08/21(火) 11:23:29.19 .net

バカには無理

154 ：デフォルトの名無しさん：2012/08/21(火) 11:38:31.45 .net

昨日1万越えて、もう10800行ってる
増加はとまらない

155 ：デフォルトの名無しさん：2012/08/21(火) 13:37:21.15 .net

行数多いのを大規模開発と思ってるのか。乙。

156 ：uY：2012/08/21(火) 18:54:34.84 .net

最初から大規模って言ってるのに記憶力ねーな

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

157 ：uY：2012/08/21(火) 18:57:00.66 .net

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

158 ：デフォルトの名無しさん：2012/08/21(火) 19:08:04.43 .net

関わる人が増えてくると、名前の重複、平行開発の待ちなど様々な問題が出てくる。

159 ：uY：2012/08/21(火) 20:16:47.85 .net

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

160 ：uY：2012/08/21(火) 20:31:48.89 .net

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

161 ：デフォルトの名無しさん：2012/08/21(火) 22:51:24.55 .net

> 消してみたら、使ってた

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

162 ：デフォルトの名無しさん：2012/08/21(火) 23:02:58.40 .net

そもそも変数が管理しきれないほどの広いスコープでコードを書かない方が良い。

163 ：デフォルトの名無しさん：2012/08/22(水) 00:18:17.90 .net

と言ってもほとんどのスクリプト言語のスコープは関数単位で、1度しか使わない処理も全部関数化するっていうのもねー

164 ：デフォルトの名無しさん：2012/08/22(水) 00:24:03.04 .net

スコープは関数単位だけどスクリプト言語なら普通は使う直前に宣言できるだろ。
そしてオブジェクトは不要になったらいつでも破棄できるだろ。

165 ：デフォルトの名無しさん：2012/08/22(水) 00:45:05.58 .net

>>163
普通は構造やオブジェクトのメソッドという意味単位で分けるものなのよ。むしろ自然と分かれる。

166 ：デフォルトの名無しさん：2012/08/22(水) 07:46:30.85 .net

意味単位でメソッド作ってたら、再利用されないメソッドだらけになるじゃん。

167 ：デフォルトの名無しさん：2012/08/22(水) 08:17:25.53 .net

ﾜﾛｽ

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

168 ：デフォルトの名無しさん：2012/08/22(水) 10:33:50.23 .net

こういう奴がmain1000行とかやっちゃうんだろうな。
スクリプト言語もできる奴と、スクリプト言語しかできない奴の差な気がする

169 ：uy：2012/08/22(水) 11:23:23.35 .net

この超ハイレベルのスレに論外初心者が迷い込んだ奇跡

170 ：uy：2012/08/22(水) 11:27:10.62 .net

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

171 ：デフォルトの名無しさん：2012/08/22(水) 12:59:19.31 .net

Rubyやgroovyは動的でOOだと思うんだが、
天才様の脳内では違うのか。

172 ：デフォルトの名無しさん：2012/08/22(水) 13:52:03.31 .net

>>166
仕様では意味単位でクラスやメソッドが出てくるので、どれを再利用すればいいかがよくわかる。

173 ：デフォルトの名無しさん：2012/08/22(水) 14:02:19.51 .net

>>168
1000行のmain()の修正依頼が来たらどうすんの？>>159ってそういうことだろ。

174 ：uY：2012/08/22(水) 14:15:51.29 .net

>>171
動的言語でOOは無理
っていうか静的言語と比べて欠点のほうが多いと思う

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

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

175 ：uY：2012/08/22(水) 14:50:11.56 .net

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

176 ：デフォルトの名無しさん：2012/08/30(木) 02:16:17.91 .net

ruby2.0がかなりすごいらしい

177 ：デフォルトの名無しさん：2012/09/09(日) 10:05:38.04 .net

らしいって誰かの受け売り？

178 ：デフォルトの名無しさん：2012/09/09(日) 10:10:28.19 .net

ステマ

179 ：デフォルトの名無しさん：2012/09/09(日) 12:43:43.33 .net

ruby2.0がかなりすごいらしい

180 ：デフォルトの名無しさん：2012/09/09(日) 12:46:30.48 .net

バズワード

181 ：デフォルトの名無しさん：2012/09/09(日) 13:04:25.31 .net

ruby2.0はかなりすごいらしい

182 ：uy：2012/09/09(日) 13:15:02.03 .net

互換性の無さが凄い

183 ：デフォルトの名無しさん：2012/09/09(日) 14:05:50.21 .net

ruby2.0でついにアレがくるらしいとのこと

184 ：デフォルトの名無しさん：2012/09/09(日) 22:38:42.39 .net

rubyの価格破壊がくるらしい

185 ：デフォルトの名無しさん：2012/09/09(日) 22:42:12.13 .net

価値破壊は既に進行してますが (w

186 ：デフォルトの名無しさん：2012/09/10(月) 00:06:57.72 .net

まあ頑張ってほしいけどさ便利は便利だしもう精神的にperlとかやになっちまってるし

187 ：デフォルトの名無しさん：2012/09/10(月) 00:50:17.78 .net

perlってほんのここ数年で一気にネットの評判ガタ落ちになった気がする
rubyがここ数年でそれだけ広まったってことだと思う
もっと早くに気づくべきだったよ
rubyよりもperlが積極的に使われてたのは2008年くらいまでだろうか
気づくのが遅い遅い遅い遅い

188 ：デフォルトの名無しさん：2012/09/10(月) 06:32:50.99 .net

>>187
phpの影響でperl減ったんじゃないか。

189 ：デフォルトの名無しさん：2012/09/10(月) 13:42:40.57 .net

>>188
まったくもってそのとおりだったｗｗｗ

190 ：デフォルトの名無しさん：2012/09/10(月) 22:32:40.37 .net

php５割
ruby２割
perl居残り組３割

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

LLとして見るなら
ruby４割
python４割
php１割
perl居残り１割

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

191 ：デフォルトの名無しさん：2012/09/10(月) 23:06:18.99 .net

なにこのrubyひいきめ。1割も無いだろ。

192 ：デフォルトの名無しさん：2012/09/11(火) 11:11:33.93 .net

perlの１割のユーザーでperlリソースを越えたかｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

193 ：デフォルトの名無しさん：2012/09/11(火) 19:29:13.02 .net

ルビリストつええ

194 ：デフォルトの名無しさん：2012/09/13(木) 20:49:27.18 .net

Perlは書いたコード誰も読めないからな。滅ぶべき言語
かといってRubyもどうかね

195 ：デフォルトの名無しさん：2012/09/13(木) 23:21:46.35 .net

rubyは可読性を優先して
リスト内包表記を実装しなかったりしてる言語
でも最悪なコードは他にいくらでもかける
使い手次第

196 ：vy：2012/09/14(金) 01:08:33.04 .net

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

197 ：デフォルトの名無しさん：2012/09/14(金) 15:07:56.72 .net

キリッ

198 ：デフォルトの名無しさん：2012/09/14(金) 21:41:56.59 .net

>>195
Rubyはパーサがスパゲティ過ぎて
パーサ拡張して内包表記を入れる事が難しいだけ
入れられたら入れてるよ

199 ：uy：2012/09/14(金) 22:48:35.89 .net

聞き捨ての知識で知ったかぶるゴミカスってへらないよな
内包表記なんてその名の通り開始括弧と閉じ括弧がついてるんだから
この程度も実装できない頭とかおめでたすぎるわｗｗｗｗｗｗｗｗｗｗｗ

さっさと死ねゴミクズ

200 ：デフォルトの名無しさん：2012/09/14(金) 23:42:23.98 .net

1.9でラムダ式の構文入れたときも
x->{} じゃなくて ->x{} なんてキモい構文で
しかも空白有る無しでバグってたRubyだからな...

201 ：デフォルトの名無しさん：2012/09/15(土) 00:37:50.39 .net

前からmatz自身がパーサ定義一杯一杯言うとったしなあ
なんか代替見つかったんだろか

202 ：デフォルトの名無しさん：2012/09/15(土) 00:39:18.96 .net

代案ですか？

Ruby 3.0です！

203 ：デフォルトの名無しさん：2012/09/15(土) 02:24:11.94 .net

>>199
そういう台詞はパッチ書いてから言えよ

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

204 ：uy：2012/09/15(土) 03:58:59.74 .net

ップｗｗｗｗｗｗｗｗｗｗｗｗｗ

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

205 ：デフォルトの名無しさん：2012/09/15(土) 04:02:23.07 .net

CRubyはbison使ってるから関係あるよ

206 ：デフォルトの名無しさん：2012/09/15(土) 04:13:34.11 .net

LLとかにこだわらず、パーサーくらい自分でフルで書いてみろよｗ
好きな言語作れるぜ

207 ：uy：2012/09/15(土) 17:05:33.28 .net

205
またアスペがつれた
てめー話かけんなっていっただろ

208 ：uy：2012/09/15(土) 17:08:27.11 .net

しかしアレだけ書籍でてんのにまだこんなゴミカスいたんだな
流石に成長しない板だわ

209 ：uy：2012/09/15(土) 17:35:49.76 .net

なぜリスト内包表記が難しいと思ったのか

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

210 ：uy：2012/09/15(土) 17:41:03.52 .net

yacc(笑)みたいなゴミしか知らない奴も大変だよね
何年間そこで知識とまってんだよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

211 ：デフォルトの名無しさん：2012/09/15(土) 17:41:07.91 .net

(*´･∀･)(･∀･｀*)ﾍｰ

212 ：uy：2012/09/15(土) 18:04:56.91 .net

くやしくて声もでませんｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

213 ：デフォルトの名無しさん：2012/09/15(土) 22:12:16.43 .net

>>210
Rubyはゴミで作られてるんですね
まあuy君はゴミだからゴミ同士お似合いですね

214 ：vy：2012/09/15(土) 23:34:31.67 .net

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

215 ：デフォルトの名無しさん：2012/09/15(土) 23:37:28.67 .net

急に自分語り始めちゃったよ
なんだこいつ

216 ：デフォルトの名無しさん：2012/09/15(土) 23:43:25.07 .net

>>214
rubyにこだわってるやつとは別にしたのかよ。
独自フレームワークは人の入れ替わり時の教育コストがかかる。あなたのような二流、三流を使うことも考えるのが大規模開発の一流。

217 ：uy：2012/09/16(日) 00:25:00.51 .net

また社畜開発の話だよｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
なんでドカタ開発前提でしゃべる奴がいるんだろう

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

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

218 ：デフォルトの名無しさん：2012/09/16(日) 00:26:35.12 .net

>>217
はず・・・とか根拠がないなら
口を開くな。

219 ：デフォルトの名無しさん：2012/09/16(日) 03:49:53.24 .net

>>217
とりあえずスレタイを読むことが出来る奴でないと話にすらならないな

220 ：デフォルトの名無しさん：2012/09/16(日) 17:21:34.85 .net

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

221 ：デフォルトの名無しさん：2012/09/16(日) 17:29:22.90 .net

>>220
素人さんへ。

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

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

222 ：デフォルトの名無しさん：2012/09/16(日) 18:18:36.16 .net

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

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

223 ：デフォルトの名無しさん：2012/09/16(日) 18:59:37.85 .net

>>220
動的言語がダメっていうよりSmalltalkがダメ
あれは玩具

224 ：デフォルトの名無しさん：2012/09/16(日) 19:04:29.56 .net

>>222
ドカタってプロのことだったんですねｗ

225 ：デフォルトの名無しさん：2012/09/16(日) 19:13:49.68 .net

ナレーター「プロドカタの朝は早い」

226 ：デフォルトの名無しさん：2012/09/16(日) 20:55:06.22 .net

議論に負けそうになったら、
いつもドカタの話にすり替える。

227 ：デフォルトの名無しさん：2012/09/16(日) 20:59:54.80 .net

つまり「プロがそう言っています(ｷﾘｯ」で議論に勝ちそうだったのに
ドカタの話にすり替えるなと、そう言いたいのですね

228 ：デフォルトの名無しさん：2012/09/16(日) 21:03:19.89 .net

関数型言語は業務で使える！

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

業務で使っている！ ではない所に注意なｗ

229 ：デフォルトの名無しさん：2012/09/16(日) 21:11:08.15 .net

業務に使っても良いけど、
ドカタ仕事は関数型言語を使ってもドカタ仕事
底辺は底辺なりに自分の境遇に満足して、変に夢持っちゃダメ

230 ：デフォルトの名無しさん：2012/09/16(日) 21:26:13.42 .net

よくある「あいつらは馬鹿、俺は天才。」という書き込みでした

231 ：uy：2012/09/16(日) 22:54:04.49 .net

関数型厨の書き込みって
俺のネタ書き込みよりひどい

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

232 ：デフォルトの名無しさん：2012/09/16(日) 22:56:16.73 .net

>>231
なんだネタなのか
悪かったな。死ねとか言って。

233 ：vy：2012/09/16(日) 23:22:41.11 .net

関数型言語には関数型言語の適した分野が、
動的言語には動的言語の適した分野があるよ。
それも分からずに○○は××にも使える、とか主張するのは二流を通り越して三流だね。

234 ：デフォルトの名無しさん：2012/09/17(月) 03:53:18.86 .net

存在がネタ

235 ：デフォルトの名無しさん：2012/09/17(月) 07:11:36.99 .net

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

236 ：デフォルトの名無しさん：2012/09/17(月) 07:48:31.55 .net

収束してから出なおせやｗ

237 ：デフォルトの名無しさん：2012/09/17(月) 08:00:25.00 .net

絶対とは言い切れないけど、業務系は関数型にはならないよ
副作用を隔離しなきゃダメなほど複雑なコード組んでないから
単純にデータを右から左に流すだけの簡単なお仕事

238 ：デフォルトの名無しさん：2012/09/17(月) 08:10:10.39 .net

業務に関数型？

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

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

239 ：デフォルトの名無しさん：2012/09/17(月) 08:14:02.89 .net

後発負け組の奴らって趨勢が決まって
収束してから乗り換えるって発想なんだな
そりゃ負け組だわ

240 ：デフォルトの名無しさん：2012/09/17(月) 08:36:04.27 .net

業務アプリに先端技術を惜しげもなく投入。
でも、できることは変わりません w

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

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

>>240
>>229

242 ：デフォルトの名無しさん：2012/09/17(月) 09:24:42.46 .net

だからわざわざ関数型なんてまだまだ使わないよって書いてるんだが…

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

243 ：デフォルトの名無しさん：2012/09/17(月) 09:57:55.02 .net

>>239
発散してるって見抜けないの？ｗ

244 ：デフォルトの名無しさん：2012/09/17(月) 10:48:47.58 .net

ダメなコード書くプログラマは良い言語使っても、
厳しいコーディング規約を課しても、
便利なIDEにフレームワークを使わせても、ダメなコードを書く。

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

245 ：vy：2012/09/17(月) 11:10:01.77 .net

>>244
コンパイルが通る範囲でダメなコードを書くか、
この言語は使えないよ、出来損ないだ。と言って現場から逃げます。

246 ：デフォルトの名無しさん：2012/09/17(月) 11:46:55.54 .net

関数型って変化に対応できるの?
仕様変更の多い業務系はOOのがあってる気がするんだが。

247 ：uy：2012/09/17(月) 15:37:21.11 .net

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

248 ：デフォルトの名無しさん：2012/09/17(月) 17:26:33.49 .net

>>223
お前はPharoとかSqueakとかのオモチャをちょろっと触ったくらいでSmalltalk知った気になるな。

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

249 ：デフォルトの名無しさん：2012/09/17(月) 18:17:10.21 .net

VB >>>>>> Smalltalk (IBMにとっては)

250 ：デフォルトの名無しさん：2012/09/17(月) 18:30:33.84 .net

Smalltalkはビジネスユースも多かった言語だけど
うんこすぎて他言語に駆逐された
まさに「業務に使ってみたけどゴミだからそっぽ向かれた」言語

251 ：デフォルトの名無しさん：2012/09/17(月) 20:02:21.07 .net

smalltalk?javaやMySQLなんてない時代だっけ？

252 ：デフォルトの名無しさん：2012/09/17(月) 21:02:35.51 .net

>>246
仕様変更に強くなるようなOO固有の特徴ってあったっけ？

253 ：デフォルトの名無しさん：2012/09/17(月) 21:18:11.19 .net

どっちかっていうと関数型の方が仕様変更に強くないか？
破壊的操作を関数化されてたりしたら目も当てられないし
追いかけたくもないぞ(よくあるけどな)

254 ：uy：2012/09/17(月) 21:21:00.75 .net

バカか

255 ：デフォルトの名無しさん：2012/09/17(月) 21:45:30.87 .net

>>252
私の開発手法のせいかもだけど、顧客の要求中の関数に当たると思う相互関係より、登場するオブジェクトの方が先に安定するから。

256 ：デフォルトの名無しさん：2012/09/17(月) 22:59:28.72 .net

デザパタの達人とかだと想定外な仕様変更なんてないんだろうかね
いつもSEが想定外な仕様変更持ってきてうちのチームの綺麗なコードを台無しにしやがる
ええ無能ですみません

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

257 ：デフォルトの名無しさん：2012/09/17(月) 23:41:14.03 .net

>>256
デザパタ関係ねーよｗ

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

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

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

258 ：uy：2012/09/18(火) 00:05:09.40 .net

デザパタの達人ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
デザパタセカンドや３、４がリリースされたら意味はあるかもしれない
現時点のデザパタはゴミカスってより
当たり前すぎる設計に名前を付けただけなんで
教材にしかならない

259 ：デフォルトの名無しさん：2012/09/18(火) 00:29:36.01 .net

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

260 ：デフォルトの名無しさん：2012/09/18(火) 01:25:10.18 .net

営業がJavaと言ってとってきた仕事を数週進めたら、JavaScriptの仕事だった。何度もjavaでいいんですねと確認したのになぁ。

261 ：デフォルトの名無しさん：2012/09/18(火) 02:42:32.29 .net

>>259
あーそういうの仕事って言わないで欲しいわーあるわー
進捗報告しろとかさえ無理ゲー状態から始まる奈落へのアバンチュール

262 ：デフォルトの名無しさん：2012/09/18(火) 22:04:12.71 .net

動的言語ってアジャイル開発には向いてそうだよね
使用変更でクラスや型をどうこうって死にそうでない？

263 ：デフォルトの名無しさん：2012/09/18(火) 22:11:07.84 .net

>>262
棄却型プロトタイプ開発ならいいんじゃない。
型変更した時の影響が静的型付のがわかりやすい。動的だと見逃してたとこがたまたま動いてたなんてこともあったり。ハマる。

264 ：デフォルトの名無しさん：2012/09/18(火) 22:46:03.31 .net

プロトタイプを動的型付け言語で作り
仕様が固まってきたら静的型付け言語で作り直す
これ最強

265 ：デフォルトの名無しさん：2012/09/18(火) 22:51:03.62 .net

静的型付のスクリプト言語

266 ：デフォルトの名無しさん：2012/09/18(火) 23:01:40.91 .net

とりあえずCommonLispで書いて
型記述を追記するなり
GCLでCのソースに変換するなりすれば
一番効率がいいんじゃねぇの
Lisper見習いだからホントに出来るかはわからんが

267 ：デフォルトの名無しさん：2012/09/18(火) 23:10:03.44 .net

静的型付けの利点を
最適化による速度向上に置いてるか
静的型チェックによる型安全性に置いてるかで変わる

268 ：デフォルトの名無しさん：2012/09/18(火) 23:44:33.93 .net

Cのソースに変換すればコンパイル必要になるし
型安全性も保たれるんじゃないかと

269 ：デフォルトの名無しさん：2012/09/19(水) 00:00:53.89 .net

そんなわけないのはObjective-Cみれば分かるだろ

270 ：デフォルトの名無しさん：2012/09/19(水) 03:30:17.57 .net

動的オブジェクトの型が全部object型とかになった
型チェックが意味のないCソースに変換されるわけだ

271 ：uy：2012/09/19(水) 08:38:37.94 .net

>>>>lisper見習い

初心者死ね！！！

272 ：デフォルトの名無しさん：2012/10/02(火) 23:24:04.32 .net

Microsoft、JavaScript系の新言語、TypeScriptのデベロッパー・プレビュー版を発表
http://jp.techcrunch.com/archives/20121001microsoft-previews-new-javascript-like-programming-language-typescript/

273 ：デフォルトの名無しさん：2012/10/05(金) 04:44:59.33 .net

結局動的言語駄目じゃねーかという流れになりつつある昨今
皆様いかがお過ごしでしょうか。
ここ最近出てきた一連のJS出力言語、特にTypeScriptである意味トドメだろｗ

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

274 ：デフォルトの名無しさん：2012/10/05(金) 12:42:34.09 .net

関数型は局所的に盛り上がるけどなかなか普及の兆しが見えないな。俺もちろっと遊んだ程度で放置してるし

TypeScriptはコケる

275 ：デフォルトの名無しさん：2012/10/22(月) 06:25:54.38 .net

JSはウェブ系の場合嫌でも使うしかないからね。いまんとこ、ベターJSの中じゃ、TypeScriptは一番良いと思うね。

276 ：デフォルトの名無しさん：2012/10/22(月) 23:40:56.58 .net

>>275
もうお使いですか。どないです？
AS房としては期待外れっす

277 ：デフォルトの名無しさん：2012/11/03(土) 16:51:07.37 .net

>>274
金融系の一部とかパーサー書いたりの分野で使われてんだろ
学歴のない底辺には玩具で終わる代物だよ

278 ：デフォルトの名無しさん：2012/11/03(土) 16:56:19.12 .net

f#やOcsigenなんかはもっと評価されていいはず

279 ：デフォルトの名無しさん：2012/11/03(土) 18:42:25.65 .net

パーサはよく適用例で見かけるけど、金融系でも関数型普及してるのか
COBOLのイメージしかなかったけど確かに都合良さそうだ
まあ俺みたいな底辺土方には一生縁ねーなｗ

280 ：デフォルトの名無しさん：2012/11/03(土) 18:44:48.69 .net

金融系って言ってもCOBOL使ってたとことはまったく別の分野じゃない？

281 ：デフォルトの名無しさん：2012/11/03(土) 19:30:58.86 .net

勘定系じゃなくて、デリバティブとかのいわゆる金融工学の方でしょ。

282 ：デフォルトの名無しさん：2012/11/03(土) 23:30:00.20 .net

あんな制御不能なものを工学と呼ぶのは工学への侮辱だな。

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

283 ：デフォルトの名無しさん：2012/11/04(日) 00:54:13.02 .net

金融系 関数型でぐぐると美辞麗句にまみれたPDFとかがいろいろヒットするなー
門外漢にはなんのこっちゃよくわからんけど

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

>>282
♥

285 ：デフォルトの名無しさん：2013/02/20(水) 21:20:39.01 .net

ところで、shで書かれたconfigureとかは1万行以上あるわけだが、あれは大規模開発になるんか？

286 ：デフォルトの名無しさん：2013/02/20(水) 23:44:16.57 .net

>>285
あなたは手で書いてるの?

287 ：デフォルトの名無しさん：2013/02/20(水) 23:57:15.20 .net

自動生成だけど？

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

288 ：デフォルトの名無しさん：2013/02/21(木) 00:01:32.70 .net

ソースを生成するソースを書けば小規模になるんじゃね

289 ：デフォルトの名無しさん：2013/02/21(木) 01:41:04.93 .net

今調べて初めて知ったのか。

290 ：デフォルトの名無しさん：2013/02/21(木) 21:25:30.17 .net

まじでかホント初めて知ったわ。
OSもソースを生成するツールを生成するツールを生成するツールで作成すれば100行程度に縮められるなっ!

291 ：デフォルトの名無しさん：2013/02/21(木) 21:37:45.76 .net

>>290
そのツールチェインの最後はお前だよお前しだい。

292 ：デフォルトの名無しさん：2013/04/03(水) 22:31:12.49 .net

>>8
1万行で大規模ﾜﾗﾀｗ

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

あ

294 ：デフォルトの名無しさん：2014/01/16(木) 15:14:04.15 .net

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

ruby鯖でほんと良かったよ

295 ：デフォルトの名無しさん：2014/01/16(木) 15:58:57.11 .net

〜１０万行小規模
１００万行中規模
１０００万行大規模

296 ：デフォルトの名無しさん：2014/01/16(木) 16:15:44.93 .net

それは生産性の低いＣとかの目安だろう

297 ：デフォルトの名無しさん：2014/01/16(木) 16:22:11.85 .net

じゃあこうだ
rubyなら
〜１万行小規模
１０万行中規模
１００万行大規模

298 ：デフォルトの名無しさん：2014/01/16(木) 16:39:07.41 .net

ペコーンｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

299 ：デフォルトの名無しさん：2014/01/16(木) 18:22:08.59 .net

ロバみたいな奴だな

300 ：デフォルトの名無しさん：2014/01/17(金) 02:26:52.79 .net

場粉路「300ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ」

301 ：デフォルトの名無しさん：2014/02/05(水) 04:47:08.99 .net

型安全性ない限り不可能ですわ

302 ：デフォルトの名無しさん：2014/02/05(水) 06:16:34.54 .net

ああ、本物の動的型を知らないんだ。
型安全じゃない動的型しか使ったこと無いんだね。

303 ：デフォルトの名無しさん：2014/02/05(水) 09:43:19.39 .net

実用性のあるやつあったっけ？
ネタみたいな言語はいらないよ

304 ：デフォルトの名無しさん：2014/02/05(水) 11:54:42.46 .net

本物の動的型っていうのは
たとえばJavaやC++のことだよ。

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

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

305 ：デフォルトの名無しさん：2014/02/05(水) 12:09:06.82 .net

などと意味不明なことを供述しており精神鑑定の結果を待って慎重に対応する予定です

306 ：デフォルトの名無しさん：2014/02/05(水) 12:54:50.99 .net

>>304
なんでゴミってこんなつまんねーことしか言えないんだ

307 ：デフォルトの名無しさん：2014/02/05(水) 12:58:26.58 .net

ほっほっほ、反論は無しｗ

308 ：デフォルトの名無しさん：2014/02/05(水) 13:12:01.88 .net

>>307
死ねゴミ

309 ：デフォルトの名無しさん：2014/02/07(金) 06:53:01.21 .net

死ねゴミ

310 ：デフォルトの名無しさん：2014/02/07(金) 16:38:35.68 .net

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

311 ：デフォルトの名無しさん：2014/02/07(金) 20:40:16.60 .net

JSでとあるゲーム２，３年ぼちぼち作っててデータやView部抜きで１万行くらいをキープしてるけど
今までで一番長時間ハマったのは暗黙の型変換の挙動かな
確か正規表現で取り出した数字文字列を、==で数値と比較してる部分があって、その時点では問題なかったけど
後からそこ見て数値同士の比較かと思ってカッコつけて==を===を直してしまったんだよね

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

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

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

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

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

312 ：デフォルトの名無しさん：2014/02/07(金) 22:01:54.81 .net

==と===の違いは面倒だから使うなって、
オライリーから出ている薄い本の何処にでも書かれてるだろ

313 ：デフォルトの名無しさん：2014/02/07(金) 22:03:36.88 .net

テストコードやCIしながら書くもんじゃないのか

314 ：デフォルトの名無しさん：2014/02/07(金) 22:04:48.68 .net

静的言語ならバグが含まれないってのが、そもそもの幻想

315 ：デフォルトの名無しさん：2014/02/07(金) 22:13:41.93 .net

静的言語でバグを作り出さないなら、JUnitなんて出てくるわけがない
いちいち変数定義するなら、それ無しでテストコードまで書いた方が効率良い
という発想。（テスト自体はSmalltalkからJavaへ輸入されてた気がする）

316 ：デフォルトの名無しさん：2014/02/08(土) 01:39:35.92 .net

ウェブで言うと、昔は専用サーバは高価でシェルを使えるのは希だったから、スクリプト言語の方が動かしやすかったんだよ
プログラム自体も単純なものが多かったから、タイプセーフじゃなくても問題なかった

317 ：デフォルトの名無しさん：2014/02/08(土) 06:00:40.97 .net

>>312
それは今回の件とは関係ない
例え最初から===にしてたとしても、前述したように稀かつゲームを進めないと出てこない問題だったから気付けなかった
むしろこういうケースがあるから==の方を使ったほうが殆どの場合でいいと思ってる
まあ、言いたいことはそういうことじゃない

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

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

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

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

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

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

318 ：デフォルトの名無しさん：2014/02/08(土) 08:08:08.34 .net

>>312
オライリーって反面教師の本だろ。。。
死ねゴミ

319 ：デフォルトの名無しさん：2014/02/08(土) 11:30:21.22 .net

オライリーのどの辺が反面教師なの?
あなたは国内出版社の方？

320 ：デフォルトの名無しさん：2014/02/08(土) 13:01:18.60 .net

基本的にオライリーはゴミな上に一回本出した後で
売れ残りすぎてるから２版３版って更新されんのが遅すぎて
載ってる情報が古すぎるケースが多すぎ
あれ読んでる奴はゴミ

321 ：デフォルトの名無しさん：2014/02/08(土) 13:07:19.15 .net

オライリーは言語によって出来が違いすぎる

322 ：デフォルトの名無しさん：2014/02/08(土) 13:07:59.08 .net

英語版はやっぱり出来がいいよね。

323 ：デフォルトの名無しさん：2014/02/08(土) 13:19:36.72 .net

本毎に差がありすぎるんだよな
あと翻訳者
日本人が書いてゴミなRuby本もあったな

324 ：デフォルトの名無しさん：2014/02/08(土) 13:28:19.75 .net

書店にいって適当に本の後ろの発行日を見たらいいよ
オライリーは５年とか１０年ものとか平気でおかれてる
売れてないからそうなってる
初心者チックな本でも、せいぜい１〜２年以内に出た新しい本買ったほうが絶対良い
あとはネットで調べりゃいいだけ

325 ：デフォルトの名無しさん：2014/02/08(土) 13:33:40.49 .net

オライリーは新しくないとダメなものは向かない
新しい情報はネットで集めた方がいい
適当な他の本買うぐらいならオライリーのがマシなことが多いな

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

326 ：デフォルトの名無しさん：2014/02/08(土) 13:40:16.96 .net

オライリーはゴミｗ

327 ：デフォルトの名無しさん：2014/02/08(土) 13:42:03.17 .net

1年2年で入れ替わるくらい変化が激しい物ならそれこそ本なんて遅すぎて
いらないってなるだろうに。

328 ：デフォルトの名無しさん：2014/02/08(土) 13:56:41.14 .net

ITってそういう分野
ハードウェア絡むような場所だけだよ
５〜１０年昔の知識が通用するなんて

329 ：デフォルトの名無しさん：2014/02/08(土) 14:00:39.74 .net

もうオライリーみたいな重厚長大な本の時代じゃないね
昔はラクダ本とかボロボロになるまで読んだけどね

330 ：デフォルトの名無しさん：2014/02/08(土) 14:21:34.64 .net

ゴミｗ

331 ：デフォルトの名無しさん：2014/02/08(土) 14:23:39.19 .net

ネットの情報は断片的に拾い読みする分には良いが
まとまった情報って本で無いとねえ。

って言うのは古いかw

332 ：デフォルトの名無しさん：2014/02/08(土) 14:31:47.88 .net

リファレンスとかは完全に　ネット　＞　本　になった

333 ：デフォルトの名無しさん：2014/02/08(土) 14:57:45.25 .net

では、ハズレの本を出さない出版社を発表しちゃってください。

334 ：デフォルトの名無しさん：2014/02/08(土) 15:21:13.00 .net

>>328
OSやコンパイラの基礎的な知識がここ5〜10年ほどで全部置き換わったとでも？
何か新しいツールやライブラリなんかも利用期間が長ければ長いほど後方互換を
考えて思想的な部分を変えることが出来なくなってるよ？

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

335 ：デフォルトの名無しさん：2014/02/08(土) 15:24:34.62 .net

つ電子書籍

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

336 ：デフォルトの名無しさん：2014/02/08(土) 15:26:17.39 .net

ここ１５年くらい何も進歩してない
モバイルへのシフトが見えるくらい

337 ：デフォルトの名無しさん：2014/02/08(土) 15:34:56.49 .net

結局は、ノイマン型のコンピュータが登場して以来何も進歩してないんだよ

338 ：デフォルトの名無しさん：2014/02/08(土) 15:55:37.52 .net

話でかくなりすぎｗ

339 ：デフォルトの名無しさん：2014/02/08(土) 16:36:22.62 .net

プログラミング言語だけ見ても、PHPでもRubyでもC#でもJavaでもこの10年で大きく変わってる
ライブラリやミドルウェアはもっと変わってる
これだけラピッドリリースが当たり前の時代、オライリーは本棚に並べて自己満足するぐらいの価値しかない

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

>>339

>>334 の下２行

341 ：デフォルトの名無しさん：2014/02/08(土) 17:08:41.77 .net

Ajax でブラウザとJSの地位が大幅に向上したというのは進歩かもしれない
それ以外は驚くほど何も変わってない

342 ：デフォルトの名無しさん：2014/02/08(土) 21:58:29.94 .net

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

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

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

343 ：デフォルトの名無しさん：2014/02/09(日) 00:23:11.54 .net

>>333
Wikiにまとめられる情報を精査して紙媒体の本にするのが良いんだろうけど、
著作権的な問題で出来ないんだろうなと思う

344 ：デフォルトの名無しさん：2014/02/09(日) 04:44:50.85 .net

>>334
10年前の本でも読んでると良いよ

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

345 ：デフォルトの名無しさん：2014/02/09(日) 10:36:31.60 .net

> 10年前の本でも読んでると良いよ

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

346 ：デフォルトの名無しさん：2014/02/09(日) 12:19:57.73 .net

10年前のApacheの本とかBindとかSendmailとか

347 ：デフォルトの名無しさん：2014/02/09(日) 21:59:17.96 .net

JavaScriptは約５年の間にES3→ES6で仕様書は３倍になったし、
もっと言えばHTML5との絡みで世界が日に日に拡大してるから仕方ないね。
そのとき常識でも、半年経つと状況がガラッと変わった照りするからね。

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

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

348 ：デフォルトの名無しさん：2014/02/10(月) 09:34:39.88 .net

情報が古いと分かってる本読んでも得るもの何もないからな
信頼できない本読んで間違って覚えてそれで良いと勘違いしてる状況のほうが厄介な問題起こりそう

ゴミ

349 ：デフォルトの名無しさん：2014/02/10(月) 14:01:59.53 .net

過去の仕様が根こそぎ変化するわけじゃないんだから、
古くなってる部分だけ調べりゃ良いだろ

350 ：デフォルトの名無しさん：2014/02/10(月) 14:43:51.08 .net

古いものの方が
肥大した無駄機能もなく
本質的な部分に絞りこまれていることが多い

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

351 ：デフォルトの名無しさん：2014/02/10(月) 14:48:45.54 .net

古い本を読んでる最中に古い情報（間違った情報）と新しい情報（正しい情報）の区別をどうやってつけるんだか
ゴミかよ

352 ：デフォルトの名無しさん：2014/02/10(月) 14:49:39.61 .net

ゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

353 ：デフォルトの名無しさん：2014/02/10(月) 16:10:40.42 .net

問題が生じてから調べりゃ良いだろ

354 ：デフォルトの名無しさん：2014/02/10(月) 16:35:30.36 .net

損害被ってから調べるわけか

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

355 ：デフォルトの名無しさん：2014/02/10(月) 17:21:58.51 .net

学んだことが数年で間違った知識と化すのならばその技術・ツールそのものが害なのだ

356 ：デフォルトの名無しさん：2014/02/10(月) 18:40:07.47 .net

IT分野に来ないほうが良いな

357 ：デフォルトの名無しさん：2014/02/10(月) 18:45:28.28 .net

RubyやRailsが顕著だけど、それ以外のプロダクトも互換性は早く捨ててイノベーションする動きになってる

358 ：デフォルトの名無しさん：2014/02/10(月) 21:34:55.60 .net

互換性と情報の古くなりやすさは違う気がする
JavaScriptなんて顕著な例だし
むしろ古い情報が中途半端に有効なことが問題を大きくしてる

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

359 ：デフォルトの名無しさん：2014/02/10(月) 23:11:20.52 .net

言語機能もライブラリも互換性ぶったぎってるから、本の通りに書いても全く動かない
依存関係があるから、部分的に古いライブラリ使おうと思っても一筋縄じゃ行かない
そんなの自力で解決出来る知識あるなら、そもそも本なんか不要

360 ：デフォルトの名無しさん：2014/02/11(火) 01:14:27.60 .net

誰が
何のために
変えているのか？

361 ：デフォルトの名無しさん：2014/02/11(火) 07:53:46.12 .net

コンパイルエラーなんかでて、動かないならまだ良いけど
「動くけど動作が違います＾＾；」

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

362 ：デフォルトの名無しさん：2014/02/11(火) 07:57:41.43 .net

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

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

363 ：デフォルトの名無しさん：2014/02/11(火) 09:06:04.31 .net

育成しろ
おまえの役目だぞ

364 ：デフォルトの名無しさん：2014/02/11(火) 10:10:44.65 .net

>>325,349
死ねゴミｗ

365 ：デフォルトの名無しさん：2014/04/13(日) 11:02:52.35 ID:8bojafDRy

Ruby on Rails Cake PHPはやめとけ
http://tinyurl.com/pcvwp9m

366 ：デフォルトの名無しさん：2014/04/15(火) 18:52:57.72 ID:TTuLgdjjE

>>365
死ねゴミｗｗｗｗｗｗｗｗｗｗｗｗ

367 ：デフォルトの名無しさん：2014/09/19(金) 13:53:26.63 ID:Xfkvubm0.net

この業界は一時的な熱狂が多すぎるよね

368 ：デフォルトの名無しさん：2014/09/19(金) 16:44:39.68 ID:3WQN+no2.net

>>365
>サーバサイドではNode.jsからJavaやGoへの切り替えが進み

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

369 ：デフォルトの名無しさん：2014/09/20(土) 09:47:56.33 ID:b8OT/FfJ.net

型チェックというのも、テストの全てではないが
テストの一部なんだよ。

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

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

370 ：デフォルトの名無しさん：2014/09/30(火) 07:23:04.54 ID:2CeH2hLD.net

>>367
幸か不幸か、ソフトウェアというのは一時的な熱狂だけで「動くもの」を作れてしまう分野だからだろうね

371 ：デフォルトの名無しさん：2014/10/11(土) 23:13:05.47 ID:bgxomZ9f.net

Rubyで開発やってるけど、
unitテストの設計と項目作成だけで
3人で三週間かかって、マジで倒れそうだわ

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

372 ：デフォルトの名無しさん：2014/10/12(日) 07:22:26.20 ID:5ixfa8wz.net

>>371
大変なとこだけやって辞めてくれるとか有り難いな。
まあ、設計がちゃんとできていればの話だけど。

373 ：デフォルトの名無しさん：2014/10/12(日) 07:29:16.53 ID:jjrAIsW+.net

大変な所＝メンテナンスだから、
今後ずっと大変な状態が続くよ、

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

374 ：デフォルトの名無しさん：2014/10/12(日) 07:36:17.74 ID:gqs4tO4e.net

テストすらロクにしない>>373はどんな言語で書いてもバグだらけw

375 ：デフォルトの名無しさん：2014/10/12(日) 09:08:57.89 ID:5ixfa8wz.net

>>373
メンテが大変なのは自動テストがない場合だろ。
なぜ他の言語だとメンテが楽なの?

376 ：デフォルトの名無しさん：2014/10/12(日) 10:05:01.80 ID:DxGoFyW9.net

>>372
UNITテストやるのもかなり大変だろ

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

考えただけでだるいわ

377 ：デフォルトの名無しさん：2014/10/12(日) 13:06:01.13 ID:5ixfa8wz.net

>>376
それは仕様変更だろ。
TDDなら、メソッドの変更の前にテストの変更が来るし。

378 ：デフォルトの名無しさん：2014/10/12(日) 17:09:28.84 ID:gqs4tO4e.net

>>376
ルビーの勉強がんばってください、入門者さんw

379 ：デフォルトの名無しさん：2014/10/16(木) 00:02:19.53 ID:Ju1r+RJJ.net

動物言語に見えた

380 ：デフォルトの名無しさん：2014/10/16(木) 07:57:26.33 ID:Sk/7zxTc.net

面倒なのは全部ほかにまわせば確かに楽になるかもな

381 ：デフォルトの名無しさん：2014/10/18(土) 12:19:07.94 ID:xyIEV5M1.net

巷に出回る仕事術の基本

382 ：デフォルトの名無しさん：2014/11/24(月) 00:10:36.26 ID:NFvfX/bb.net

動的言語ってリファレンスが読みにくくね？
みんなどうしてんの？

383 ：デフォルトの名無しさん：2014/11/24(月) 00:12:03.59 ID:LP7Sk3Ho.net

暗記

384 ：デフォルトの名無しさん：2014/11/24(月) 00:16:50.33 ID:PX1MFVrm.net

そんなん言語によるだろ

385 ：デフォルトの名無しさん：2014/11/24(月) 09:52:02.93 ID:bceL07z7.net

>>382
具体的にどの言語のリファレンスが読みにくいと?

386 ：デフォルトの名無しさん：2014/11/24(月) 10:02:48.56 ID:XLIBB3hZ.net

pythonしか知らんが、pythonはかなりドキュメント類がしっかりしてると思うけどな。

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

387 ：デフォルトの名無しさん：2014/11/24(月) 10:33:25.11 ID:vb0rebZq.net

定番アプリのソースで似たようなことしてるものを探して真似る
うっかりソースを読んで入り込むとあとで変更された時にヤラれる

388 ：デフォルトの名無しさん：2014/11/24(月) 15:01:36.25 ID:kcRDK3+j.net

PHPとPythonのドキュメントはしっかりしてるけど
RubyとSmalltalkのはゴミだったな

389 ：デフォルトの名無しさん：2014/11/24(月) 17:34:32.45 ID:XLIBB3hZ.net

smalltalkはブラウザ開いて
オブジェクトと対話しながらプログラミングしていくスタイルだから
アレで良いのだ

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

390 ：デフォルトの名無しさん：2014/11/24(月) 18:25:46.58 ID:2QNpXJ+6.net

動的言語ではないがJavaのAPIドキュメントがしっかりしすぎてる。

391 ：デフォルトの名無しさん：2014/11/24(月) 18:41:49.16 ID:atmNtLqz.net

Smalltalkのドキュメントって何のことだろう？

392 ：デフォルトの名無しさん：2014/11/24(月) 19:12:45.95 ID:NFvfX/bb.net

pythonのopencvとかnumpyのリファレンス見てみたんだけど
なんの型を入れるとなんの型が帰ってくるのか明確に書いてないからサンプル見ないと分かんない

393 ：デフォルトの名無しさん：2014/11/24(月) 19:35:00.93 ID:vb0rebZq.net

その辺はネーミングセンスでカバーするという思想だろうけど
Ｃライブラリのラッパーとかだと全く通用しなくなるな

394 ：デフォルトの名無しさん：2014/11/24(月) 20:12:08.30 ID:2QNpXJ+6.net

>>392
ipythonで?して書いてなかったらソース読んでる。

395 ：デフォルトの名無しさん：2014/11/24(月) 20:25:30.45 ID:PX1MFVrm.net

vimでKを押してdocumentがなかったら
\dを押して定義元のソースコードにジャンプしてる

396 ：デフォルトの名無しさん：2014/11/25(火) 00:06:15.89 ID:pX8dGPkN.net

下みたいコードのエラーを実行前に検出できるlint系ツールが存在する
Pythonを動的言語で括って良いものだろうか


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

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

397 ：デフォルトの名無しさん：2014/11/25(火) 05:48:58.67 ID:0npMaebU.net

最近追ってなかったけど
pythonは型アノテーション導入の話題もあるのな。

398 ：デフォルトの名無しさん：2014/11/25(火) 20:38:28.15 ID:NsP7IFUt.net

やっぱ大規模開発には静的型があった方が
良いんだろうな

399 ：デフォルトの名無しさん：2014/11/25(火) 23:51:15.09 ID:n1duvf0w.net

>>398
typoですら動かすまで見つけれないのは地味にストレスだからな。

400 ：デフォルトの名無しさん：2014/11/26(水) 04:22:00.60 ID:zFnj+88g.net

>>399
何十年前の常識だよそれ
今時typoすら実行前に発見できない処理系のほうが珍しい

401 ：デフォルトの名無しさん：2014/11/26(水) 05:14:33.37 ID:iOq+FlWm.net

>>400
動的言語は、typoを実行前に発見できないほうが多いよ。
発見できないパターンはこれ

obj.f00 (fooの間違い)

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

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

402 ：デフォルトの名無しさん：2014/11/26(水) 05:24:10.98 ID:iOq+FlWm.net

動的言語だとtypoがわかると言っても
ローカル変数程度なんだよね。

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

403 ：デフォルトの名無しさん：2014/11/26(水) 08:52:45.01 ID:IUNEYOWi.net

>>401

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

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

404 ：デフォルトの名無しさん：2014/11/26(水) 10:27:57.07 ID:lFXPwW0W.net

>>401
その理屈はなんかおかしいぞ。

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

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

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

405 ：デフォルトの名無しさん：2014/11/26(水) 10:37:02.67 ID:IUNEYOWi.net

typoっつーか、メソッド名を補完してたら
ウッカリ同じprefixの別のメソッド呼んじゃってた事はあるよ

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

406 ：デフォルトの名無しさん：2014/11/26(水) 12:07:39.14 ID:lFXPwW0W.net

>>405
補完なら、ふつう型が一致してなかったらそもそも候補に出てこないし、
まして「呼んじゃって」（つまりコンパイルが通って実行される）なんてことは
ウッカリだろうが何だろうが基本ないことだと思うけど？

407 ：デフォルトの名無しさん：2014/11/26(水) 12:29:05.12 ID:jMc4tHhg.net

>>406
動的言語は型が一致しないメソッドも候補に出てくるIDEばっかじゃんSmalltalkも含めて
それにコンパイルも通るよ静的型じゃ無いんだから

408 ：デフォルトの名無しさん：2014/11/26(水) 12:35:38.39 ID:lFXPwW0W.net

>>407
>>406は静的型言語の話をしているんだが？
それとも>>405は動的型言語の話なのか？
ならなんで「引数の型や数、戻り値の型まで一致」とか出てくるんだ？

409 ：デフォルトの名無しさん：2014/11/26(水) 12:59:25.21 ID:jMc4tHhg.net

>>408
＞ならなんで「引数の型や数、戻り値の型まで一致」とか出てくるんだ？

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

410 ：デフォルトの名無しさん：2014/11/26(水) 17:49:47.93 ID:jGVOTHDh.net

rubyのto_sとか？

411 ：デフォルトの名無しさん：2014/11/26(水) 20:45:29.26 ID:zFnj+88g.net

>>409
へー、どの動的型付言語が言語仕様で「型」という概念が定義されているんだい？

412 ：デフォルトの名無しさん：2014/11/26(水) 20:48:18.16 ID:zFnj+88g.net

動的型付言語を使っていて型が違うのにとか型で補完できればとか言ってる人は動的型付言語の初心者。
動的型付言語を単に型宣言しない静的型付言語として使っているだけ。

413 ：デフォルトの名無しさん：2014/11/26(水) 22:06:07.76 ID:jGVOTHDh.net

初心者

414 ：デフォルトの名無しさん：2014/11/26(水) 22:45:02.52 ID:A6eFHCKj.net

>>412
まあ初心者なら Soft typing という用語を知らなくても
しかたないだろうな

415 ：デフォルトの名無しさん：2014/11/26(水) 22:49:59.27 ID:HWidBYzd.net

>>411
a = 1
a = "a"
a = true

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

416 ：デフォルトの名無しさん：2014/11/26(水) 22:52:09.61 ID:HWidBYzd.net

柔軟だがバグの元にはなりそうだ

417 ：デフォルトの名無しさん：2014/11/26(水) 23:01:03.31 ID:gCulqy1V.net

重要なのは値に型があることではなくて変数に型があること。
変数に型があるからこそ、その変数の型のメソッドは何かがわかる。

418 ：デフォルトの名無しさん：2014/11/26(水) 23:03:26.44 ID:gCulqy1V.net

変数はコードに書く。コードに書くということは
静的にわかる。（変数に型がある場合）

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

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

419 ：デフォルトの名無しさん：2014/11/26(水) 23:10:00.48 ID:b8NKrcQ+.net

変数posがあってこれが座標を表わしてるものだとしたら
list型で(x y)だったり構造体でxとyのフィールドを持ってたりy*w+xの整数だったり
色んな表現が出来るから柔軟という利点があってプロトタイプに向いてるってことじゃないの

420 ：デフォルトの名無しさん：2014/11/27(木) 00:00:17.23 ID:qRi3TEum.net

>>412
動的型言語の玄人になると、値の型と無関係な（CallするとRuntime Errorになる）メソッドが
大量に候補に出てくるような補完や、typoすら発見できないようなチェッカーに
慣らされてるから疑問にすら思わなくなるってこと？

421 ：デフォルトの名無しさん：2014/11/27(木) 00:39:38.24 ID:dibuY+0s.net

>>419
一人で把握できる範囲でプロトタイプのようなある程度使い捨てを前提に作れる
ならそれほど問題はないが、スレタイにあるように大規模開発≒複数人開発だと
静的言語に比べて動的言語だとtypoみたいな簡単なミスでも見つけづらいよねと
いうような話だと思う。 ちょろっとしたものを作るだけなら変数は全てオブジェクト
ですっていうように抽象化されている方が楽だけど、大規模開発だとそれじゃ
ダメだよねっていう話。

422 ：デフォルトの名無しさん：2014/11/27(木) 00:43:32.22 ID:pDjxUsPd.net

>>420
大量ったってさらに数文字足せばかなり絞り込めるし
typoだって前にも書いてあるとおり
未定義のワーニングで十分に思うんだが
いったい何が不満なんだ？

423 ：デフォルトの名無しさん：2014/11/27(木) 07:05:04.04 ID:zJRTpdHD.net

そりゃ未定義がワーニングだからだろ。
ワークニング出たよ。
さて、そのワーニングは無視していいのかよくないのか？

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

424 ：デフォルトの名無しさん：2014/11/27(木) 07:17:33.51 ID:pDjxUsPd.net

>>423
いや、普段使いがSmalltalkなもんで、そんなことはない。
未定義のワーニングはtypoだった場合の候補も挙げてくれるから
実際にtypoだったらそこから選ぶだけだし。^^;

425 ：デフォルトの名無しさん：2014/11/27(木) 07:36:00.70 ID:0IKZEJch.net

SmalltalkのIDEの補完は精度が低過ぎて使えないゴミだから
プログラマは補完に頼らず自分でタイプするから
>>405みたいな問題もないんだよね

426 ：デフォルトの名無しさん：2014/11/27(木) 08:44:42.11 ID:29V21Kp8.net

>>425
そうだね。なんかこんなようなメソッド名（Smalltalkではセレクタと呼ぶ）だったなぁ…と
うろ覚えで適当に入れとくとコンパイラがあとでいちいち教えてくれるから、はいはいって直してく感じ。

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

427 ：デフォルトの名無しさん：2014/11/27(木) 09:51:34.08 ID:79rV4D1o.net

Python「低レベルな争いだな…」

428 ：デフォルトの名無しさん：2014/11/27(木) 10:14:33.17 ID:29V21Kp8.net

>>427
ごめん。
PythonにはSmalltalkのそれを凌駕する最強のIDEがそろっているのかもしれないが、
その前にまず言語として隔靴掻痒感が否めなくて使っているとめまいがするのでパス。

429 ：デフォルトの名無しさん：2014/11/27(木) 17:17:05.92 ID:3JRXUen2.net

Smalltark 厨 vs Pythonee

430 ：デフォルトの名無しさん：2014/11/27(木) 19:38:58.94 ID:29V21Kp8.net

>>429
Unknown variable: Smalltark please correct, or cancel:
define new class
declare global
------------------------------------------------------
Smalltalk
SmalltalkImageTest
SmalltalkEditor
SmalltalkImage
SmallLandColorTheme
SmallInteger
SmallIntegerTest
SMAccount
SMCategory
SMPackageInstallationTask
------------------------------------------------------
cancel

431 ：デフォルトの名無しさん：2014/11/27(木) 20:07:16.47 ID:p4BAxWMe.net

Python「ただのテキストエディタで出来そう…」

432 ：デフォルトの名無しさん：2014/11/27(木) 20:39:01.35 ID:9Juu1ps5.net

そんなにイデの力が欲しいか

433 ：デフォルトの名無しさん：2014/11/28(金) 00:34:41.35 ID:O/dyue/E.net

>>379
ｺﾞﾛﾆｬｰﾝ♪

434 ：デフォルトの名無しさん：2014/11/28(金) 09:07:58.51 ID:8rVeLSla.net

>>420
動的型に慣れたら、大量に候補が出るような命名はしないし（凝集度）
typoすら発見できないようなチェッカーなんて使わずにマトモなチェッカーを使う。
あたりまえだろ？

435 ：デフォルトの名無しさん：2014/11/28(金) 09:09:59.36 ID:8rVeLSla.net

>>423
なるほど、warningメッセージなんて読まない達人プログラマなんですね、
すごいなあw

436 ：デフォルトの名無しさん：2014/11/28(金) 09:13:52.73 ID:8rVeLSla.net

ここまでの流れだと結論は
静的言語は初心者向け
静的言語使いは初心者

437 ：デフォルトの名無しさん：2014/11/28(金) 09:59:17.09 ID:F5n5vmOV.net

処理系作ってる連中に学が無いから、型推論できるチェッカーひとつ作れない
で、仕方なく運用（命名規則）で回避ですか

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

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

438 ：デフォルトの名無しさん：2014/11/28(金) 11:02:52.12 ID:MpXGAzGF.net

手元のSmalltalk環境には4万強のメソッドがあって
先にも言われているように、型推論付きとかそんな高尚な補完もないけど
使いたいメソッドが出てこなくて困ったことなんかないぞ。

439 ：デフォルトの名無しさん：2014/11/28(金) 17:18:45.17 ID:8rVeLSla.net

>>437
まともな人がちゃんと作れば君のような目にはあわずにすむということじゃないかなあw

440 ：デフォルトの名無しさん：2014/11/28(金) 17:21:26.03 ID:8rVeLSla.net

>>437
例えばどんなメソッド名の場合に型推論できないと見つからないんだい？
おもしろそうだから答えてみてよw

441 ：デフォルトの名無しさん：2014/11/28(金) 20:56:18.69 ID:avPnRbje.net

>>438
Smalltalkで何作ってるの?
そっちが気になる絶滅危惧言語なんだが

442 ：デフォルトの名無しさん：2014/11/28(金) 21:02:53.61 ID:pWSxBDFH.net

>>439
まともな人は遥か昔Smalltalkから逃げ出したし、現在進行形でRubyからも続々と逃げ出してるよね

443 ：デフォルトの名無しさん：2014/11/28(金) 23:32:57.83 ID:5WZv/pSY.net

>>441
いろいろやるけど、主にWebアプリだな。

444 ：デフォルトの名無しさん：2014/11/29(土) 02:10:12.49 ID:TbFyYdBX.net

>>438
> 使いたいメソッドが出てこなくて困ったことなんかないぞ。

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

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

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

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

445 ：デフォルトの名無しさん：2014/11/29(土) 02:28:50.06 ID:1aIidqiX.net

>>444
ごめん。要求仕様^^;がちょっとよくわからなかった。
PythonとかJavaとか>>444がよく知っている言語でいいから、
あと処理の重さは30秒くらいの適当な長さのsleepとかの代替で
どういうコードか書いてみてもらってもいい？

446 ：デフォルトの名無しさん：2014/11/29(土) 02:54:05.37 ID:SuGYzpy/.net

>>444
オブジェクトが数値のときは数値関係のメソッドだけ補完に出せとか、そういう条件はあるの？

447 ：デフォルトの名無しさん：2014/11/29(土) 04:14:00.96 ID:TbFyYdBX.net

>>445
じゃあJavaScriptで。

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

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

>>446
そりゃあるでしょｗ

448 ：446：2014/11/29(土) 04:16:18.02 ID:TbFyYdBX.net

当たり前だけど、a. の行にブレークポイントを置いて、
そこまで実行してからa.を出すのはなし。

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

449 ：デフォルトの名無しさん：2014/11/29(土) 08:00:05.38 ID:fWl7Yvk9.net

>>447
なるほど
メソッド名を1文字も入力できないほど脳が不自由な人なんですね
かわいそうに

450 ：デフォルトの名無しさん：2014/11/29(土) 08:16:34.87 ID:SO1yCwH9.net

>>447
MyClassのメソッド一覧ってどれぐらいのサイズ？

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

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

451 ：デフォルトの名無しさん：2014/11/29(土) 09:19:45.30 ID:SuGYzpy/.net

補完候補が単純なalphabetical orderじゃなくて
使用頻度順を学習して上から並べてくれるやつもあるので
その反論はナンセンスじゃね？
MyClassとObjectでは使われるメソッドの頻度が違うから

452 ：デフォルトの名無しさん：2014/11/29(土) 09:23:05.48 ID:1aIidqiX.net

>>447
ちょっと待ってよ。そういう話なの？

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

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

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

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

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

453 ：デフォルトの名無しさん：2014/11/29(土) 09:26:19.46 ID:SuGYzpy/.net

標準ライブラリの大きさとObjectに数百個程度のメソッドがあることの
関係も良くわからない

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

454 ：デフォルトの名無しさん：2014/11/29(土) 09:40:43.18 ID:e6ORUEwd.net

>>450
> MyClassのメソッド一覧は少なくとも500個ぐらいになって
そんなもん、クラス直接のメソッドと
継承元のメソッドぐらい分けて表示するに決まってるだろ・・・。

455 ：デフォルトの名無しさん：2014/11/29(土) 09:50:35.80 ID:SuGYzpy/.net

でも>>447をよく見たら、こんなお題だったのか

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

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

456 ：デフォルトの名無しさん：2014/11/29(土) 10:17:11.39 ID:e6ORUEwd.net

これなら型補完できるよ。これが静的言語でしょ？

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

457 ：デフォルトの名無しさん：2014/11/29(土) 10:31:13.38 ID:SO1yCwH9.net

>>454
へー、継承元のメソッドを分けて表示すれば解決する程度の貧弱なクラスライブラリが前提なんだー（鼻ホジホジ

458 ：デフォルトの名無しさん：2014/11/29(土) 10:34:40.20 ID:7EP7sx63.net

>>443
商用で?
Smalltalkの処理系は?

459 ：デフォルトの名無しさん：2014/11/29(土) 10:35:24.90 ID:SO1yCwH9.net

静的言語でやっているコーディングとかIDEの使い方をそのまま動的言語に持ち込んで「これができない」「あれができない」と喚きだす初心者を眺めるスレw

460 ：デフォルトの名無しさん：2014/11/29(土) 10:36:42.17 ID:SO1yCwH9.net

>>458
そういう話はSmalltalkスレでどうぞ

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

461 ：デフォルトの名無しさん：2014/11/29(土) 10:39:51.40 ID:e6ORUEwd.net

>>457
お前バカだろｗ
Objectにメソッドが多すぎて邪魔って話をしてるんだが。

462 ：デフォルトの名無しさん：2014/11/29(土) 10:40:48.12 ID:e6ORUEwd.net

>>459
まあそうだね。あれができないこれができない。
たしかにそうだ。実際に出来ないもの。

で、そ、そんなのいらないんだから！
と言い返すｗ

463 ：デフォルトの名無しさん：2014/11/29(土) 10:57:41.26 ID:MSvzZpAh.net

技術的には型推論と補完を両立できるかどうか考えればいいと思うけど
ここで悪足掻きしてるやつは技術より心理にこだわっているふしがある
補完よいよねというマインドをつくることしか考えてない

464 ：デフォルトの名無しさん：2014/11/29(土) 11:10:26.37 ID:x5tELjcp.net

普通にいいだろｗ．
補完ができれば、それを応用して
さらにいろんなことができるようになるわけだし

465 ：デフォルトの名無しさん：2014/11/29(土) 11:16:43.56 ID:SO1yCwH9.net

>>463
補完うんぬんは「静的型いいよね」というマインドのための道具でしかないでしょw

466 ：デフォルトの名無しさん：2014/11/29(土) 11:17:30.03 ID:7EP7sx63.net

>>460
そんなこと言ったらこのスレが成り立たないだろ。
独立言語スレはSmalltalkだけじゃないぞ。

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

467 ：デフォルトの名無しさん：2014/11/29(土) 11:17:56.66 ID:MSvzZpAh.net

>>464
補完するスタイルと補完しないスタイルの二種類があれば
一種類よりも多くのことができる

468 ：デフォルトの名無しさん：2014/11/29(土) 11:44:56.39 ID:SuGYzpy/.net

補完するときにメソッド名を選択すると、引数や戻り値の型やドキュメントが
出てくれるのは凄く嬉しい

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

469 ：デフォルトの名無しさん：2014/11/29(土) 11:56:50.41 ID:x5tELjcp.net

出来るできないで考えるからわからない。
どちらが楽にできるかどうかで考えよう。

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

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

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

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

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

470 ：デフォルトの名無しさん：2014/11/29(土) 11:59:47.15 ID:x5tELjcp.net

なお、コード補完は、書くことを楽にしてくれる、
つまりタイピングを補助するものだと勘違いしている人が多いが、
実際は読むことを楽にしてくれている。

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

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

471 ：デフォルトの名無しさん：2014/11/29(土) 12:11:58.32 ID:nAAws2G7.net

>>447
ご説ごもっとも。
だから、こんな可哀想な動的大好き人間は放っておいて
静的型言語まんせースレに行って幸せを満喫してください。

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

472 ：デフォルトの名無しさん：2014/11/29(土) 12:30:14.99 ID:v2v5Wnkr.net

それ以前にさ、動的型付きとして
失ってほしくない機能って何さ？
失っても対して問題ない機能ばかりだと思うだが。

473 ：デフォルトの名無しさん：2014/11/29(土) 12:44:23.44 ID:A4nuaoXO.net

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

474 ：デフォルトの名無しさん：2014/11/29(土) 12:49:43.77 ID:v2v5Wnkr.net

動的型付きにすることで失われていることのほうが多いと思う。
それで、動的型付きにしてまで守ろうとしているものってなに？

475 ：デフォルトの名無しさん：2014/11/29(土) 13:13:21.80 ID:MSvzZpAh.net

ドキュメントについては仕様書が欲しいか具体例が欲しいかによる
ただちに必要ではないことまで書かれているのが仕様書
ある時点で必要だったことしか書かれていないのが具体例

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

476 ：デフォルトの名無しさん：2014/11/29(土) 13:24:38.99 ID:U5ivpV2C.net

スタートダッシュと試行錯誤じゃないの
軌道に乗ったら捨てて作りなおせばいいのよ

477 ：デフォルトの名無しさん：2014/11/29(土) 13:24:42.22 ID:7EP7sx63.net

>>473
コード補完で出てくるドキュメントなんて知ってるメソッドなら役に立つが
知らないメソッドをそれだけでなんとかしようなんて無理だがや

478 ：デフォルトの名無しさん：2014/11/29(土) 13:54:58.03 ID:A4nuaoXO.net

>>477
javaならソースに書かれているjavadocが出る。いわゆるAPIリファレンスと
言われるものが表示される。visual stadioだとmsdnに書いてあるのが出る。
APIリファレンスが役に立たないとか言っちゃうような無能はプログラムを
書くのを辞めたほうがいい。

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

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

479 ：デフォルトの名無しさん：2014/11/29(土) 14:00:18.54 ID:A4nuaoXO.net

そういえばvisual studioだとサンプルコードを検索ダウンロード出来る機能まで
付いたんだっけかな。

480 ：デフォルトの名無しさん：2014/11/29(土) 14:06:58.21 ID:7EP7sx63.net

>>478
javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
サマリーだけじゃ役に立たんがね。

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

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

481 ：デフォルトの名無しさん：2014/11/29(土) 14:07:50.21 ID:7EP7sx63.net

>>479
マジか?
随分と進歩したもんじゃの

482 ：デフォルトの名無しさん：2014/11/29(土) 14:13:44.81 ID:v2v5Wnkr.net

>>480
> javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
> サマリーだけじゃ役に立たんがね。

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

483 ：デフォルトの名無しさん：2014/11/29(土) 14:25:05.29 ID:7EP7sx63.net

>>482
そういうIDEのヘルプ機能よりもGoogle先生のが役に立つ
Google先生とIDEのインテリセンスが無いとプログラムの生産性が著しく落ちるw

484 ：デフォルトの名無しさん：2014/11/29(土) 14:33:59.73 ID:A4nuaoXO.net

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

485 ：デフォルトの名無しさん：2014/11/29(土) 14:36:32.05 ID:v2v5Wnkr.net

>>483
初心者に多いね。一次ソースを見ないで、
個人のブログとかみるやつ。
英語読めないからとかなのかな。

486 ：デフォルトの名無しさん：2014/11/29(土) 14:37:24.55 ID:v2v5Wnkr.net

で、そんな話はいいとして、動的型付け言語が
動的型付けにしてまで守ろうとしているものって何よ？

487 ：デフォルトの名無しさん：2014/11/29(土) 14:38:14.93 ID:Tl+PW+FS.net

動的言語でも変数aをMyClass型と教えればメソッド一覧は出せるだろ

488 ：デフォルトの名無しさん：2014/11/29(土) 14:39:37.78 ID:v2v5Wnkr.net

>>487
それで、aがMyClassだっていうのは、
人間がいちいち教えてあげるの？

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

489 ：デフォルトの名無しさん：2014/11/29(土) 14:40:07.50 ID:SO1yCwH9.net

その問い自体が静的目線だってのw
視野が狭いなあw

490 ：デフォルトの名無しさん：2014/11/29(土) 14:40:46.54 ID:Tl+PW+FS.net

いちいち変数を宣言して型を指定するのとかわらないと思う

491 ：デフォルトの名無しさん：2014/11/29(土) 14:42:05.95 ID:v2v5Wnkr.net

その都度、MyClass型って教えないといけない手間がかかるのと
コードに仕様として書いておけるのの違いだね

492 ：デフォルトの名無しさん：2014/11/29(土) 14:42:13.42 ID:SO1yCwH9.net

補完候補を500に絞り込むためだけに、aがMyClassのインスタンスでないと動かないような腐れコードにするわけか
ご苦労さまなこってw

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

493 ：デフォルトの名無しさん：2014/11/29(土) 14:43:48.06 ID:v2v5Wnkr.net

> 補完候補を500に絞り込むためだけに
補完候補を500ってなんのこと？
動的型付けだと、その500を全て覚えてるの？
意味がわからないね。

494 ：デフォルトの名無しさん：2014/11/29(土) 14:45:30.32 ID:TZOpdCpR.net

型を書かなくても a = MyClass() や、さらにいえば
foo(MyClass()) のようなコードがあるだけでも>>447は補完できる様になる

495 ：デフォルトの名無しさん：2014/11/29(土) 14:46:28.99 ID:v2v5Wnkr.net

逆に言えば、そういうコードがなければ
補完できないという意味である。

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

496 ：デフォルトの名無しさん：2014/11/29(土) 14:48:16.54 ID:Tl+PW+FS.net

補完ってそこまで重要か
動的言語支持者の揚げ足をとるためには必要かもしれないけど
単語単位補完で十分通用してる

497 ：デフォルトの名無しさん：2014/11/29(土) 14:49:08.68 ID:v2v5Wnkr.net

型を書かなかったら a = MyClass() と a =YourClass()の両方があったら
補完がめちゃくちゃになる。
foo(MyClass()) と foo(YourClass()) のようなコードがあると
>>447の補完は使い物にならなくなる。

498 ：デフォルトの名無しさん：2014/11/29(土) 14:51:15.51 ID:v2v5Wnkr.net

>>496
> 補完ってそこまで重要か

重要ですよ。

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

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

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

499 ：デフォルトの名無しさん：2014/11/29(土) 14:54:43.83 ID:TZOpdCpR.net

>>495
引数に型が書いてなくても、実際に関数を使ってるコードがあれば
引数に入れられた値から型推論できるよねって話なんだけど

500 ：デフォルトの名無しさん：2014/11/29(土) 14:55:43.43 ID:rjWp6DMr.net

単語単位補完って、単にタイプ数を
少し省略することしかできないからね。
しかも補完した結果が間違っていることがある。

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

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

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

501 ：デフォルトの名無しさん：2014/11/29(土) 15:00:38.05 ID:rjWp6DMr.net

>>499
いや、だからなければ型推論できないでしょ。
「実際に関数を使ってるコード」の方が間違っていたら
補完も間違うわけよ。foo(MyClass())って使わないといけない時に
foo(YourClass())って書いてしまったら、補完もそれに合わされてしまう。

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

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

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

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

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

502 ：デフォルトの名無しさん：2014/11/29(土) 15:11:36.58 ID:TZOpdCpR.net

>>501
それは void foo(YourClass a) って間違えても同じだよね

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

503 ：デフォルトの名無しさん：2014/11/29(土) 15:14:22.47 ID:Tl+PW+FS.net

動的言語の方がコード量が減るから大規模になりにくい
短期記憶に入りやすいから効率も上がる
静的に見て機械的に処理しやすいのは静的片付け言語だけど

504 ：デフォルトの名無しさん：2014/11/29(土) 15:14:41.06 ID:HSRgXQQV.net

> それは void foo(YourClass a) って間違えても同じだよね

定義は一箇所。

使う場所は沢山。

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

505 ：デフォルトの名無しさん：2014/11/29(土) 15:16:15.20 ID:HSRgXQQV.net

>>503
> 動的言語の方がコード量が減るから大規模になりにくい

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

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

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

506 ：デフォルトの名無しさん：2014/11/29(土) 15:17:16.14 ID:Tl+PW+FS.net

少なければいいよ
機械がコードを読み書きするんじゃなくて人がするんだから

507 ：デフォルトの名無しさん：2014/11/29(土) 15:18:12.01 ID:TZOpdCpR.net

>>504
型検査でエラーになるから分かるでしょ

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

508 ：デフォルトの名無しさん：2014/11/29(土) 15:20:19.64 ID:HSRgXQQV.net

動的型付け言語では、コードを理解するための情報（定義）が減って、
実行するコード自体の量は静的型付けでも動的型付けでも変わらない。

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

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

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

509 ：デフォルトの名無しさん：2014/11/29(土) 15:22:35.61 ID:MSvzZpAh.net

>>504
これは面白い
頻度が少ない方に権威があるという不思議なルール

510 ：デフォルトの名無しさん：2014/11/29(土) 15:24:39.97 ID:HSRgXQQV.net

>>507
無理だよ。

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

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

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

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

511 ：デフォルトの名無しさん：2014/11/29(土) 15:26:57.07 ID:HSRgXQQV.net

>>509
そりゃそうだろｗ

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

512 ：デフォルトの名無しさん：2014/11/29(土) 15:37:19.95 ID:TZOpdCpR.net

>>510
動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ
さらにmethod_missingが定義されてる時はワーニングを出さないという工夫もできる

513 ：デフォルトの名無しさん：2014/11/29(土) 15:44:49.77 ID:TZOpdCpR.net

動的にメソッドを追加するケースは少ない => 補完や型検査は動的言語でも有効
動的にメソッドを追加するケースが多い => 動的言語って凄く便利だね

514 ：デフォルトの名無しさん：2014/11/29(土) 15:49:50.99 ID:HSRgXQQV.net

>>512
> 動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ

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

515 ：デフォルトの名無しさん：2014/11/29(土) 15:58:27.80 ID:SO1yCwH9.net

>>498
>・タイプ数の省略

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

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

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

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

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

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

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

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

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

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

516 ：デフォルトの名無しさん：2014/11/29(土) 16:02:07.42 ID:SO1yCwH9.net

補完君の要約
「ぼくがジャバでプログラムを書くのと同じやり方ができない動的言語なんて使えない」

517 ：デフォルトの名無しさん：2014/11/29(土) 16:55:08.72 ID:SO1yCwH9.net

補完君の最大の勘違いは、
動的言語はa.と入力して出てくるメソッド名を絞り込めない
と思い込んでいること。

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

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

518 ：デフォルトの名無しさん：2014/11/29(土) 20:03:41.93 ID:o/hS6qzS.net

補完必須派に訊きたいんだけど
コンパイル時ダックタイピングともいわれる構造部分型
http://igeta.cocolog-nifty.com/blog/2008/05/subtyping.html
をサポートする静的型言語のときは、どういう候補を出すのが正解？

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

519 ：デフォルトの名無しさん：2014/11/29(土) 21:05:19.38 ID:7EP7sx63.net

>>485
オレオレOOなヤツに多いね。
自分の足りないオツムと一次ソースだけでプログラミングするやつw

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

520 ：デフォルトの名無しさん：2014/11/29(土) 22:22:32.23 ID:fN3BW3ns.net

>>515
リファクタリングでできることは
静的型付け言語の方がとっくに多くなってるんだよ。

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

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

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

521 ：デフォルトの名無しさん：2014/11/29(土) 22:25:49.85 ID:fN3BW3ns.net

>>517
> 補完君の最大の勘違いは、
> 動的言語はa.と入力して出てくるメソッド名を絞り込めない
> と思い込んでいること。

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

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

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

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

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

ですかｗ

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

522 ：デフォルトの名無しさん：2014/11/29(土) 22:48:51.18 ID:SuGYzpy/.net

>>521は勘違いしているよ

>>517が言っているのは、数値オブジェクトに対して
文字列のメソッドを呼び出して実行時エラーになっても、
それは言語仕様上は正当なプログラムであるということだよ

もちろん言語仕様上正当であることは、バグじゃないことを意味しないけどね
オブジェクトの型に無関係なメソッド呼び出しは大抵バグだろう

523 ：デフォルトの名無しさん：2014/11/30(日) 00:47:09.72 ID:mFsly3WX.net

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

なぜ構造的部分型が補完の指標になりえるのか、
その理由というか関連性が説明してごらん
単なる思いつきじゃねえの？

少なくとも >>518 のリンク先blog記事では
「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
と主張しているけど、こんな奇妙な話は聞いたことが無い
しかも記事のネタになったソース(学術的文献)が書かれていないし、
英語版 Wikipedia の Subtyping のページでも
duck tying との関連性に対する文章に対して "citation needed" と指摘されている
おまけに記者は構造的部分型付けをサポートする言語(OCaml)を使った事が
一度も無いと正直に告白している

このblog記事はあくまで記者が型システムを勉強する過程で書き残したノートであって、
この記事を引用して >>518 が何を言いたいのか、自分には意味不明だね

なお、動的型付け言語に(形式的な型推論を基礎とした)静的型付けを導入した概念は
Soft Typing と呼ばれている
動的型付け言語の補完を検討する指標となる可能性があるのは、
どちらかといえば Soft Typing ではないかと思うね

524 ：522：2014/11/30(日) 00:49:19.68 ID:mFsly3WX.net

細かいけど訂正

X: その理由というか関連性が説明してごらん
O: その理由というか関連性を説明してごらん

525 ：デフォルトの名無しさん：2014/11/30(日) 00:51:32.07 ID:uxHSis3U.net

ガアガアとなく人間は
アヒルである。

ダックタイピング

526 ：デフォルトの名無しさん：2014/11/30(日) 01:04:21.57 ID:360iudbJ.net

>>520
昔の時点ですでに相当できてたって話もあるぞ。

http://web.archive.org/web/20090130061934/http://www.refactory.com/RefactoringBrowser/Refactorings.html

527 ：デフォルトの名無しさん：2014/11/30(日) 01:17:26.21 ID:uxHSis3U.net

>>526
同じぐらい"昔"である2009年の記事出していい？Eclipse+Javaの世界の話
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/

528 ：デフォルトの名無しさん：2014/11/30(日) 09:02:17.22 ID:360iudbJ.net

>>527
すまん2001年の登場当初のを貼るつもりだった。

http://web.archive.org/web/20010514165503/http://www.refactory.com/RefactoringBrowser/Refactorings.html

529 ：デフォルトの名無しさん：2014/11/30(日) 09:53:30.32 ID:uRzHHhxu.net

520を読むと516が言う通り補完君は動的型がまるでわかってないことが明白だ

530 ：デフォルトの名無しさん：2014/11/30(日) 10:04:13.86 ID:uRzHHhxu.net

補完君はキーを2,3文字入力するのをケチるために
引数がMyClassのインスタンスでなければ動かないゴミメソッドにして
どうだ静的型すごいとか言い出す初心者でしょ

531 ：デフォルトの名無しさん：2014/11/30(日) 10:27:25.19 ID:uRzHHhxu.net

静的型は自転車の補助輪
初心者を卒業したら外そうね

532 ：デフォルトの名無しさん：2014/11/30(日) 10:46:49.86 ID:/BRxH/wW.net

>>530
もうちょっと汎用的なメソッドを定義する場合、MyClassみたいな具象型よりも
Interfaceや型クラスを指定することが多いね
それで必要なだけの汎用性と静的型を両立できる

533 ：デフォルトの名無しさん：2014/11/30(日) 10:59:52.11 ID:c9Q+Jt/4.net

大規模開発で人に作らせる立場だと、プログラマに静的言語という拘束具をつけた方が楽なんだよ。チームメンバの能力によって品質が変わってはいけないし。
人を指導する立場に立ってみると分かる。

534 ：デフォルトの名無しさん：2014/11/30(日) 11:21:16.72 ID:rR9TrKjV.net

でも静的型を嫌がってたらGoogleとかでは働けないわけじゃん？
お前らどんな底辺企業で働いてるの？
それともニート？

535 ：デフォルトの名無しさん：2014/11/30(日) 12:03:38.55 ID:360iudbJ.net

>>523
structural subtyping と duck typing の対比なんていくらでも目にするだろう。

536 ：デフォルトの名無しさん：2014/11/30(日) 13:49:35.58 ID:kUIpsKvT.net

>>528
じゃあ同じように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.

537 ：デフォルトの名無しさん：2014/11/30(日) 13:52:53.51 ID:kUIpsKvT.net

>>533
> プログラマに静的言語という拘束具をつけた方が楽なんだよ

どういう点が拘束具なの？

間違える行動ができない。という意味での拘束？
それはいいことじゃんｗ

538 ：デフォルトの名無しさん：2014/11/30(日) 14:03:15.99 ID:+4cKqP8L.net

>>531
シートベルトだよ
離陸と着陸の時以外は外しても困らんかも知れんけど

539 ：デフォルトの名無しさん：2014/11/30(日) 14:13:11.05 ID:kUIpsKvT.net

別に何も拘束されてないけどなｗ

単にコードが読みやすくなるだけ。
人とコンパイラにとって可読性が高いコードになる。

可読性が高いから理解しやすく、理解した情報を使って
バグが少なく開発のサポートができるようになるわけ

540 ：デフォルトの名無しさん：2014/11/30(日) 15:35:01.93 ID:/BRxH/wW.net

REPLとかで「このオブジェクトって何ができるんだっけ？」って調べるのは
動的言語では典型的な開発手法で、恩恵に預かってる開発者は多いと思うけど
静的型の補完も一緒だよ
単純にタイプ数をちょっと減らすとか、そういう話じゃない

541 ：デフォルトの名無しさん：2014/11/30(日) 15:37:46.89 ID:qocW+y5a.net

何のメソッド使うか分かってるんならヘボい補完でも十分じゃね？

542 ：デフォルトの名無しさん：2014/11/30(日) 15:58:11.94 ID:rR9TrKjV.net

全部把握できる程度のチープなライブラリを使って
一人で小さなプログラムを開発するなら
ヘボい補完でも十分じゃね？

543 ：デフォルトの名無しさん：2014/11/30(日) 16:11:04.82 ID:UnYKruMf.net

>>541
Cくらいならともかく、ライブラリは肥大化の一方なわけで有限の記憶力を
ライブラリの引数や戻り値を完璧に覚えるより別の方に振り分けたいと思う
人も少なくないんですよ。

544 ：デフォルトの名無しさん：2014/11/30(日) 16:19:35.18 ID:360iudbJ.net

>>536
わかった。では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

545 ：デフォルトの名無しさん：2014/11/30(日) 16:33:33.88 ID:/BRxH/wW.net

>>544
静的型と動的型で同じ「Rename method」というリファクタリング機能をサポートしていると言っても、
動的型のそれは http.connect のメソッド名を変更したら
無関係な db.connect のメソッド名も変わってしまうような代物だろう

546 ：デフォルトの名無しさん：2014/11/30(日) 16:45:52.62 ID:ZfpKb0dS.net

>>545
それは人間が頑張ればいいだけの話だろ。
手抜きするな。努力しろ。

547 ：デフォルトの名無しさん：2014/11/30(日) 16:52:19.04 ID:+4cKqP8L.net

動的言語における効率とは「問題の棚上げ・先送り」と表裏一体であり
問題の発見・防止が重視される大規模開発とは真逆の志向である

548 ：デフォルトの名無しさん：2014/11/30(日) 16:54:52.49 ID:360iudbJ.net

>>545
そんなことをする馬鹿にはリファクタリングツールの使用はお勧めできない。

549 ：デフォルトの名無しさん：2014/11/30(日) 16:58:31.17 ID:rR9TrKjV.net

>>548
一番のバカは使い物ならないツールを作ってる動的言語の連中だな

550 ：デフォルトの名無しさん：2014/11/30(日) 17:02:44.20 ID:UnYKruMf.net

>>546
人間が頑張らなくてもいいようにツールは進歩しているのですが？
頑張らなくなって良くなった分、他にリソースを回すとか考えられないんだろうな。

551 ：デフォルトの名無しさん：2014/11/30(日) 17:04:54.56 ID:qFjB73Ro.net

コンピュータにやらせるなんてアホ
脳が腐る。
人間がシコシコ変換するることで
ボケが防止される

552 ：デフォルトの名無しさん：2014/11/30(日) 17:10:09.29 ID:7WEYW95R.net

>>547
そうなんだよね。結局問題を先送りしてるだけ。

だいたいさ、コードの中でこの変数（httpとか）は
connectを呼び出しているって書いているから
この変数はconnectを持っている型だって決まってるわけだよね。

動的型付けであっても、型は決まってる。

だからそのことをコードに書いておけばいいわけよ。
それが変数の型宣言というもの。

型宣言しておけば、コードとその型に矛盾が起きるような修正が
発生した時、それをすぐにコンピュータが検出できる。
検出した問題を人間がみた時にも、すぐにその原因がわかりやすい。

どうせコードでは型は特定の型じゃないと動かないんだから
その型であるって明示しておけばもっと便利になる。

動的型付けでは不可能なレベルの完璧な補完っていうのも
その高度なコード解析能力の一端にすぎないんだよ。

553 ：デフォルトの名無しさん：2014/11/30(日) 17:23:36.91 ID:360iudbJ.net

>>549
くやしいのうwwwくやしいのうwww

>>552
否定はしないけれど、視点の違いとか「ものは言いよう」という側面もあるな。

「真のソフトウェア工学が開発されるまでの次善の策は、
　あらゆる要素について極端に遅延結合な動的システムを使って開発する事だ。」
http://metatoys.org/oxymoron/oxymoron.html

554 ：デフォルトの名無しさん：2014/11/30(日) 17:25:33.97 ID:tVFfE2xZ.net

まあ中規模くらいなら動的言語の気楽さ>静的言語の堅牢性だけど
大規模になって全体のコードを把握できなくなると気楽さ<堅牢性になるよね

555 ：デフォルトの名無しさん：2014/11/30(日) 17:37:33.47 ID:7WEYW95R.net

>>553
動的と動的型付きは違うからね。

そもそもコードが「静的に型付きされているのと同様」に
特定の型じゃないと動かないように書かれているわけで。

556 ：デフォルトの名無しさん：2014/11/30(日) 17:40:58.65 ID:7WEYW95R.net

>>553
その頃言われていた「遅延結合」っていうのは、
遅延ではない結合、つまり特定の型以外には結合しないという意味で
それを解決したのが、継承やインターフェースでしょう。

継承やインターフェースは、指定した型＋その型を継承したもの
（もしくはインターフェースを持っているもの）に
動的に結合しているわけで、遅延結合になっている。

557 ：デフォルトの名無しさん：2014/11/30(日) 17:41:53.12 ID:guVElZZq.net

静的言語だとテスト工数が減るとか、動的言語だとテスト工数が増えるとかあるの？

558 ：デフォルトの名無しさん：2014/11/30(日) 17:47:36.29 ID:7WEYW95R.net

>>557
コンパイルエラーをミスと考えるかバグと考えるかで話が違う。

テストはバグを見つけるもの。
だから普通はコンパイルエラーによるミスは
テストで見つけるものではない。

だから本当の意味でのテストの量は同じだが、問題はミス。

静的型付け言語ならミスは、ミスとしてテストの前段階で弾くことができるが、
動的型付け言語だと、テストの段階で弾くことになる。
（しかも静的型付け言語ならミスは修正箇所をコンピュータが示すから素早く解決できるが、
動的型付け言語だとバグを探すのと同じ作業をしないといけなくなる）

そういう点で、動的型付け言語ではテストでやるべきことが
増えるのでテスト工数が増えることになる。

559 ：デフォルトの名無しさん：2014/11/30(日) 18:12:40.43 ID:c9Q+Jt/4.net

>>537
制約だな。

560 ：デフォルトの名無しさん：2014/11/30(日) 18:24:06.55 ID:7WEYW95R.net

>>559
それを言うなら、契約って言ったほうがかっこいいな。

契約プログラミングといえば、EiffelとD言語ぐらいだけど、
型っていうのもある意味契約だからね。

この引数は、○型であるという事前条件
この関数は、○型を返すという事後条件

561 ：デフォルトの名無しさん：2014/11/30(日) 18:24:17.69 ID:uRzHHhxu.net

なんだ
このスレの静的厨は静的型が制約だということも理解せずに喚いてたのか
初心者としても筋が悪いな

562 ：デフォルトの名無しさん：2014/11/30(日) 18:25:23.77 ID:tHR3Cg3X.net

ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの？
template<typename T> void f(T func)
みたいないわゆるダックタイピング

563 ：デフォルトの名無しさん：2014/11/30(日) 18:26:57.46 ID:mFsly3WX.net

>>535
Static Typing vs. Dynamic Typing という対比はよく見かける
しかし structural subtyping vs. duck typing という対比は知らないね
もし「いくらでも目にする」のなら、ソース(学術的文献)を示せばいい
簡単な事だろ？

ましてや
> 「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
>「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
なんて奇妙な主張は聞いたことが無い

blog記事を批判するつもりはないが、そんな個人メモを元にして
「動的型言語の補完がどうあるべきかの指標になる(>>534)」と主張するのは
馬鹿だってこと

564 ：デフォルトの名無しさん：2014/11/30(日) 18:31:27.03 ID:7WEYW95R.net

>>562
> ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの？

┃ template<typename T>┃ void f(T func)
↑ ここからここまでが、型 ↑

HOGE_T void f(T func)

置き換えるならこんなふうに捉えてる。

> みたいないわゆるダックタイピング

それをダックタイピングとは言わない。

565 ：デフォルトの名無しさん：2014/11/30(日) 18:36:30.75 ID:uRzHHhxu.net

そもそもduck typing自体まともな定義はない

566 ：デフォルトの名無しさん：2014/11/30(日) 18:44:16.77 ID:/BRxH/wW.net

function foo(a) {
    a.bar()
}

bar() を呼び出せるなら何でも foo の引数に入れられるのが
ダックタイピングというのはどうだろうか
このスレだけでも

567 ：デフォルトの名無しさん：2014/11/30(日) 19:22:49.09 ID:7WEYW95R.net

> bar() を呼び出せるなら何でも foo の引数に入れられるのが

それってさfoo関数の引数 aはbarメソッドを
持った型ではなければならないってことだよね？

コードに書くならば

function foo(/* fooメソッドを持った型 */ a) {
a.bar()
}

568 ：デフォルトの名無しさん：2014/11/30(日) 19:26:23.25 ID:7WEYW95R.net

間違えたｗ

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に入れるコードを書いたらコンパイルエラーが出る

569 ：デフォルトの名無しさん：2014/11/30(日) 19:32:01.35 ID:/BRxH/wW.net

>>567
ただし、継承関係や共通のインターフェースを持たなくても
bar() を呼び出せるなら foo に入れられなくてはならない

570 ：デフォルトの名無しさん：2014/11/30(日) 19:47:43.07 ID:7WEYW95R.net

http.connectを呼び出す関数に、
db.connectというメソッドを持ったオブジェクトを
入れても期待通りに動くことはまず無い。

二つの無関係なオブジェクトが同名のメソッドを持っていて
呼び出せるからといって、それはバグにしかならない。

メソッドに名前空間がないような形で使う動的型付け言語では
このような問題が起きる。

静的型付け言語ではインターフェースという型を定義することで、
同名であっても本質的に違うものは、違うものとして扱うことが出来る

571 ：デフォルトの名無しさん：2014/11/30(日) 19:53:09.38 ID:VpMFGcKd.net

どんな御託を並べても
インターフェースがduck typingは無いわw

572 ：デフォルトの名無しさん：2014/11/30(日) 19:56:23.78 ID:7WEYW95R.net

インターフェースがduck typingなどとは
ひとことも言ってない。

duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルでしか無い。
アヒルだ、空を飛べ。人間は飛べません。はいバグです。

実際には鳴くメソッドがあればアヒルである
ということになって更に意味がわからない。

もちろん、アヒルである条件をインターフェースとして定義しているならば
そのインターフェースを備えているものは、アヒルでいいですがね。

メソッド一つが有るか無いかきめんなよ。

573 ：デフォルトの名無しさん：2014/11/30(日) 19:57:27.20 ID:7WEYW95R.net

訂正

duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルにはならない

574 ：デフォルトの名無しさん：2014/11/30(日) 19:59:03.44 ID:360iudbJ.net

>>563
ググるとかしたことないのかね。

575 ：デフォルトの名無しさん：2014/11/30(日) 20:01:50.38 ID:7WEYW95R.net

したことある人が、リンクを見つけてきて
ここに書けばいいと思いますが、

それを要求することは酷なことですね。
だってググっても見つからないのだから。

576 ：デフォルトの名無しさん：2014/11/30(日) 20:04:43.51 ID:7WEYW95R.net

ダックタイピングの説明として
「アヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
という言葉があるが、

それを、
アヒルのように歩くとアヒルのように鳴くという
アヒルインターフェースを実装しているものはアヒルである。
というふうに読み替えると

これは実は静的型付け言語の説明だなとわかるはずである。

577 ：デフォルトの名無しさん：2014/11/30(日) 20:09:27.69 ID:VpMFGcKd.net

>>570
mysql.connect と postgresql.connect は置き換え可能だけど？

578 ：デフォルトの名無しさん：2014/11/30(日) 20:11:34.14 ID:VpMFGcKd.net

>>576
>>571

579 ：デフォルトの名無しさん：2014/11/30(日) 20:15:01.73 ID:7WEYW95R.net

>>577
両方が同じデータベースインターフェースを
サポートしているならばそうだろうね。

現実的な話をするならば、mysql.connect を
使うコードは、実際にはmysql.connect だけを
使うことはなく、複数のメソッドを使う。

だから、その複数のメソッドというものを
定義しないといけない。

そしてその定義したものがインターフェースであり
そのインターフェースを使いますよと宣言するのが
型宣言なのである。

そうすればある型がデータベースインターフェースを
定義していることを保証する型宣言だけあれば、
全てのメソッドを安心して使うことが出来る。

このオブジェクトはconnectメソッドは持ってるけど、
disconnectメソッドを持っていないかもしれない
なんてことはなくなるのである。

580 ：デフォルトの名無しさん：2014/11/30(日) 20:16:45.31 ID:nRiDRl39.net

足し算と掛け算のある型なら複素数でも行列でも良いとかいうパターンは有るな

581 ：デフォルトの名無しさん：2014/11/30(日) 20:21:32.59 ID:7WEYW95R.net

足し算をaddメソッドだとして、
addメソッドさえあればなんでも使えるかというと

（addメソッドでググって一番目にでてきた）
> Addメソッドとはエクセルのシートに表とグラフを同時に表示するメソッドです。

に対してもうまく動くことはおそらくないだろう。

つまり名前が一緒でも、正しく動くとは限らんのさ。
だから名前と意味が一緒であることを保証するために
名前をつけたものが型なのである。

582 ：デフォルトの名無しさん：2014/11/30(日) 20:24:10.20 ID:T2KLr1TM.net

>>576
アヒルのインスタンスを実行時にその振る舞いから分類するところがポイントなのであって
アヒルというクラスに対してコンパイル時に分類するのはダックタイピングじゃないよ

というわけでダックタイピングはインターフェースや構造的部分型とは全く別

583 ：デフォルトの名無しさん：2014/11/30(日) 20:25:36.35 ID:VpMFGcKd.net

>>581
Excelのaddメソッドは戻り値の型が違うだろ

584 ：デフォルトの名無しさん：2014/11/30(日) 20:25:53.73 ID:T2KLr1TM.net

>>581
だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ

585 ：デフォルトの名無しさん：2014/11/30(日) 20:26:04.76 ID:7WEYW95R.net

アヒルのインスタンスを実行時にその振る舞いから分類というけれど、
コード自体は、実行時に分類してないんだよ。

コードは、アヒルであること、を前提として書いてる。
実行前にコードで分類しているのに、
なぜ実行時に分類しないといけないのか。

型は動的に変わるが、コードは静的なのである。

586 ：デフォルトの名無しさん：2014/11/30(日) 20:28:54.03 ID:7WEYW95R.net

>>584
> だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ

だから大規模では無理なんだよ。

大規模＝大多数の人間が係る。場合によっては全く知らない人が作った
ライブラリを使うこともあるしな。


そんなんで、すべて意味を揃えるなんてことは不可能
いくつもの意味を持つ英単語なんてざらにある

単語の意味を揃えるのは不可能。というのが大前提

587 ：デフォルトの名無しさん：2014/11/30(日) 20:29:37.63 ID:T2KLr1TM.net

>>585
コードも動的だから「動的」なんだよ
それとも、単なる動的型付けの話をしている？

588 ：デフォルトの名無しさん：2014/11/30(日) 20:30:01.03 ID:/BRxH/wW.net

>>582
Interfaceも構造的部分型も実行時に動的に分岐する
そうでなければポリモーフィズムとは言わない

さらに言えば、構造的部分型は「アヒルというクラス」に対して分類してるわけでもない

589 ：デフォルトの名無しさん：2014/11/30(日) 20:31:08.34 ID:T2KLr1TM.net

>>586
とはいえ
Objectクラスだけで500近いメソッド数をもっているにもかかわらず
不特定多数の開発者からのコードを集めたSmalltalkシステムは
ちゃんと動いているわけだが

590 ：デフォルトの名無しさん：2014/11/30(日) 20:33:46.05 ID:SVLUkCya.net

>>589
SmalltalkでObjectに500もメソッドなんてねーよｗ

あったとしたら、アンチパターン ゴッドクラス
（設計の一部分（クラス）に、過剰に機能を集中させること）に
適合してしまうわｗ

591 ：デフォルトの名無しさん：2014/11/30(日) 20:34:01.13 ID:T2KLr1TM.net

>>588
分岐（メソッド探索）の話などしていない

どの式がどのインターフェースを実装しているのかを実行時に検査してるのか？
どの式がどの型の部分型かを実行時に検査しているのか？
へー、それ、なんていう言語だい？

592 ：デフォルトの名無しさん：2014/11/30(日) 20:36:14.22 ID:TE77vkUw.net

>>590
わかりやすい静的脳だな
Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw

593 ：デフォルトの名無しさん：2014/11/30(日) 20:36:20.46 ID:VpMFGcKd.net

>>586
大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
同じ意味の機能に同じインターフェースを持たせるのは不可能

インターフェース方式は、ある数値計算ライブラリと別の行列演算ライブラリを混ぜて使う場合などで問題になる

594 ：デフォルトの名無しさん：2014/11/30(日) 20:40:02.67 ID:/BRxH/wW.net

>>591
実行時にvalidationするのがダックタイピングというなら
構造的部分型は確かに違うな


"If it walks like a duck and quacks like a duck, it must be a duck"

という文章からそのような意味を読み取るのは無理だが

595 ：デフォルトの名無しさん：2014/11/30(日) 20:40:22.76 ID:SVLUkCya.net

>>592
> Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw

最悪だな。JavaScriptでprototypejsっていうのがあったけど、
名前が標準のメソッドとobjectに追加したメソッド名が
被って大変な目にあっていた。

それ移行Objectにメソッドを追加するのは
ダメなやり方だって広く知られるようになったね。

596 ：デフォルトの名無しさん：2014/11/30(日) 20:40:39.28 ID:360iudbJ.net

>>571
いや。duck typing とは言わないけれど、Smalltalk の動的型と
同様の柔軟性を持たせつつ型安全を目指したのがインターフェイス。
（Eiffel流のクラスの継承をサブタイプに使うと型安全でないという流れで）
http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf

597 ：デフォルトの名無しさん：2014/11/30(日) 20:43:21.18 ID:/BRxH/wW.net

>>593
Haskellの型クラス、Rustのトレイト等が
それらの問題点を解決している

598 ：デフォルトの名無しさん：2014/11/30(日) 20:45:52.98 ID:TE77vkUw.net

>>594
If it walks like a duckというのは、実際のitの振る舞いのことを指しているのだから実行時のことだと考えるのが自然だと思うが？
If it will walk like a duckならばコンパイルだろうけどな。

599 ：デフォルトの名無しさん：2014/11/30(日) 20:47:16.39 ID:TE77vkUw.net

>>595
>名前が標準のメソッドとobjectに追加したメソッド名が
>被って大変な目にあっていた。

初心者だな
当分補助輪をつけることをお勧めするw

600 ：デフォルトの名無しさん：2014/11/30(日) 20:48:14.19 ID:360iudbJ.net

>>590
Squeak Smalltlk（Squeak4.5）で調べたけど
いろんな意味で残念ながら^^; 500近くはあるな。Object allSelectors size "=> 486 "

601 ：デフォルトの名無しさん：2014/11/30(日) 20:51:13.03 ID:TE77vkUw.net

>>593
>大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
>同じ意味の機能に同じインターフェースを持たせるのは不可能

そういう初心者は補助輪（静的型）を使えばいいよw

ちなみに動的言語の環境では
様々なライブラリでどういうメソッド名がつけられているか検索する仕組みと
指定したメソッド名のメソッドを検索する仕組みが
遥か80年代から用意されていたりするけどなw

602 ：デフォルトの名無しさん：2014/11/30(日) 20:53:54.80 ID:TE77vkUw.net

>>600
動的言語では全オブジェクト共通の語彙が重要だから当然そうなる

603 ：デフォルトの名無しさん：2014/11/30(日) 20:56:59.55 ID:360iudbJ.net

>>556
とりあえず、アラン・ケイが書いていることを読もうや。
そもそも「その頃は」って思い込み激しすぎるだろう。
これ書かれたの1999年〜2000年頃だし。

604 ：デフォルトの名無しさん：2014/11/30(日) 21:05:38.46 ID:/BRxH/wW.net

>>598
静的型でも振る舞うのは実行時だろ
チェック自体はコンパイル時だが

で、どこに実行時にチェックすると書いてある？

605 ：デフォルトの名無しさん：2014/11/30(日) 21:09:31.70 ID:360iudbJ.net

>>602
とはいえ、Squeak のカオス化に嫌気してフォークされた Pharo は
だいぶ減らして 374 だし（3.0調べ）、VisualWorks はもとより 303（7.10調べ）だけどね。

606 ：デフォルトの名無しさん：2014/11/30(日) 21:10:47.94 ID:VpMFGcKd.net

>>602
補完がうんこ過ぎるからそんなカオスになってんだろ
クラスの名前空間としての機能が死んでる

607 ：デフォルトの名無しさん：2014/11/30(日) 21:13:30.42 ID:VpMFGcKd.net

>>601
静的型（ていうかJava）のインターフェースの話だよ
動的なら名前合わせときゃ良いんだから問題ならん

608 ：デフォルトの名無しさん：2014/11/30(日) 21:15:20.91 ID:guVElZZq.net

>>600
Pharo 3.0 は、374

609 ：デフォルトの名無しさん：2014/11/30(日) 21:17:02.28 ID:guVElZZq.net

>605 で既出だった orz

610 ：デフォルトの名無しさん：2014/11/30(日) 21:30:34.30 ID:360iudbJ.net

>>609
乙^^

ちなみにファンお手製で変わり種のGNU Smalltalkだとわずか123。
http://ideone.com/D9lo8c

611 ：デフォルトの名無しさん：2014/11/30(日) 21:50:46.91 ID:mFsly3WX.net

>>596
>いや。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

612 ：デフォルトの名無しさん：2014/11/30(日) 22:04:51.19 ID:SVLUkCya.net

オブジェクト指向プログラミングをするのが目的ではない。
巨大なシステムをより早くより安全に開発するのが目的なのだ。

613 ：デフォルトの名無しさん：2014/11/30(日) 22:11:54.90 ID:rR9TrKjV.net

オブジェクト指向上の欠陥とやらが何か知らんが、
そのお陰で実用レベルの型推論（補完や型検査）が出来てるなら面白いな

614 ：デフォルトの名無しさん：2014/11/30(日) 22:22:44.40 ID:SVLUkCya.net

人間が間違わずに全てのコードを脳に記憶して
タイプミスすらしないことを前提にするならば、
コードにわざわざ記憶の断片（つまり型情報）を書く必要はないよ。

それができないから、型情報を書いたほうが
わずかの手間だけで、そのあとずっと楽ができるわけで。

615 ：デフォルトの名無しさん：2014/11/30(日) 22:32:19.86 ID:360iudbJ.net

>>571
すまん。こっちだった。
Interfaces for Strongly-Typed Object-Oriented Programming
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf

616 ：デフォルトの名無しさん：2014/11/30(日) 22:48:40.83 ID:mFsly3WX.net

>>613
>オブジェクト指向上の欠陥とやらが何か知らんが、

有名な Python のself地獄だよ
キーワード「python self地獄」で検索すればGoogle先生が教えてくれる
Python しか知らなければself地獄が気にならないかもしれないけど、
Smalltalk や Ruby を知っている人からすれば、無知は幸せだなぁと見る
これの基礎が「継承の意味論における差異」になる

なお単に意味論の違いだから、self地獄と引き換えに
実用的な型推論(補完や型検査)が手に入るわけではない
両者の間に直接的な関連性は無い（言い換えるとスレチな話題）

617 ：デフォルトの名無しさん：2014/11/30(日) 22:53:53.26 ID:rR9TrKjV.net

>>616
self地獄はGuidoが変人なだけで意味論なんて高尚な理由じゃねーだろ
self省略できるようにパーサ弄れない意味論的理由は何だよ
それこそ関係ねーよ

618 ：デフォルトの名無しさん：2014/11/30(日) 22:55:23.26 ID:360iudbJ.net

>>611
> Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ

Ruby の super は Smalltalk とは違うよ？

619 ：デフォルトの名無しさん：2014/11/30(日) 22:55:36.39 ID:/BRxH/wW.net

>>616
> 両者の間に直接的な関連性は無い（言い換えるとスレチな話題）

スレの主題に沿っているのは補完や型チェックの方だけど

620 ：デフォルトの名無しさん：2014/11/30(日) 22:57:41.96 ID:mFsly3WX.net

>>615
この論文内では duck typing という用語は一度も使われていないし、
タイトルに Strongly-Typed と書かれているように静的型付け言語に関する内容だ

で、いったいどこから duck typing を連想したの？

621 ：デフォルトの名無しさん：2014/11/30(日) 23:00:20.47 ID:360iudbJ.net

典型的なアスペか。

622 ：デフォルトの名無しさん：2014/11/30(日) 23:01:15.62 ID:mFsly3WX.net

>>619
>スレの主題に沿っているのは補完や型チェックの方だけど

まったくそのとおり
だから >>611 では

> まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね

と書いた

623 ：デフォルトの名無しさん：2014/11/30(日) 23:09:04.67 ID:rR9TrKjV.net

>>620
1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ
abstract斜め読みしただけだがSmalltalkには言及されてんぞ

624 ：デフォルトの名無しさん：2014/11/30(日) 23:09:46.51 ID:tHR3Cg3X.net

あれ？int型の+とstring型の+に対するオーバーロードみたいな話になってる？
無知なら口だすなと言われそうなので黙っておきます…

625 ：デフォルトの名無しさん：2014/11/30(日) 23:22:20.73 ID:/BRxH/wW.net

>>622
そうか。じゃあスレ違いの話は止めないと荒らしになってしまうな

626 ：デフォルトの名無しさん：2014/11/30(日) 23:27:42.56 ID:mFsly3WX.net

>>617
Python のオブジェクト指向は Modula-3 を参考にしているけど、
Modula-3 のオブジェクト指向は Simula を参考にしている
そして疑似変数 self の概念は Simula には存在せず、
Simula を参考にした Smalltalk で生まれた
だから、Modula-3 や Python に疑似変数 self は存在せず、
これを模倣するにはメソッド引数で明示的に __self__ を
渡さなければならない訳

あと疑似変数 self の値は実行時に決まるから、
もし Python で __self__ を省略できるようにするためには、
構文論(syntax)の変更すなわちパーザの改造だけではダメで、
意味論(semantics)も変更しなければならない

こうした背景も知らずに「変人だから」という理由で決めつけるのは、
Guido氏に失礼だと思うよ

627 ：デフォルトの名無しさん：2014/11/30(日) 23:31:44.94 ID:guVElZZq.net

もう、超優秀なIDEがあって動的構造取り入れた c# 最強って事で良いんじゃないの？

628 ：デフォルトの名無しさん：2014/11/30(日) 23:42:47.38 ID:UnYKruMf.net

>>627
MSが他の処理系を駆逐する勢いでLinux版頑張ったら近い将来にそうなるかも。
種だけ蒔いて後知らねっていう可能性も高いけど。

629 ：デフォルトの名無しさん：2014/11/30(日) 23:43:33.56 ID:mFsly3WX.net

>>623
> 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ

そうだろ、だから驚いて >>620 では

>>で、いったいどこから duck typing を連想したの？

と書いた

論文を引用するのはいいけど、この論文をどう解釈して duck typing に結びつけたのか、
説明が無ければ意味が分からんという話だよ


>abstract斜め読みしただけだがSmalltalkには言及されてんぞ

Smalltalk の柔軟な継承を強い型付け(=静的型付け)なOO言語に取り込むために
インターフェイスを用いる、という文脈でね
動的型付けを濫用するというニュアンスを持つ duck typing とは何の関係も無い

この論文、型システムと言語設計に興味がある人にはとても有益だから、
斜め読みと言わずじっくり読んでみたほうがいいと思うな

630 ：デフォルトの名無しさん：2014/11/30(日) 23:44:44.78 ID:/BRxH/wW.net

>>617
http://neopythonic.blogspot.jp/2008/10/why-explicit-self-has-to-stay.html

・ただの関数を、後からクラスにメソッドとして後付けできること（そのとき暗黙のselfの扱い）
・decoratorがあるから（動的にstatic methodやclass methodに変更できる）

というのが理由だそうだ

631 ：デフォルトの名無しさん：2014/11/30(日) 23:49:11.15 ID:guVElZZq.net

>>628
Roslyn凄そうだが、どんだけのヤツが付いていけるんだろ。

632 ：デフォルトの名無しさん：2014/11/30(日) 23:50:00.23 ID:nRiDRl39.net

>>627
動的構造ってなんだっけ
実行時型情報ならC++にもあるけど
むしろ実行時型情報がない言語の方が良いんだろ
ほぼ全部関数型言語だけど

633 ：デフォルトの名無しさん：2014/11/30(日) 23:52:00.50 ID:mFsly3WX.net

>>630
Smalltalk や Ruby なら、暗黙のselfがあっても
後からクラスにメソッドを後付けできるのにね....

634 ：デフォルトの名無しさん：2014/11/30(日) 23:53:34.74 ID:/BRxH/wW.net

言語だけでいうならRustに期待しているんだが……

635 ：デフォルトの名無しさん：2014/11/30(日) 23:57:11.19 ID:SVLUkCya.net

>>682
> 後からクラスにメソッドを後付けできるのにね....

それは静的型付け言語のメリットをなくしてまで
やるべき重要な事なのか？

636 ：デフォルトの名無しさん：2014/11/30(日) 23:58:47.30 ID:mFsly3WX.net

>>635
おいおい、Python は動的型付け言語だよ

637 ：デフォルトの名無しさん：2014/11/30(日) 23:59:07.80 ID:rR9TrKjV.net

>>633
その代わりに関数が無くてProcオブジェクトとかいう
キモい代用品を使わされるゴミでしょRubyって

638 ：デフォルトの名無しさん：2014/11/30(日) 23:59:36.82 ID:UnYKruMf.net

>>634
そこでまた振り出しに戻るのだが、ちょこちょこって遊ぶならどの言語でも
いいのだが、ガッツリ使おうとするとツールもしっかりしてないとねというのに
戻るわけです。

639 ：デフォルトの名無しさん：2014/11/30(日) 23:59:39.73 ID:guVElZZq.net

>>632
dynamic型

640 ：デフォルトの名無しさん：2014/12/01(月) 00:02:55.46 ID:v1/AC0CB.net

>>636
実用レベルで型推論出来る言語と
出来ないゴミを一緒にすんなよ
PythonはSoft typingが実用化されてんの

641 ：デフォルトの名無しさん：2014/12/01(月) 00:04:29.77 ID:JhMfQ7kZ.net

>>637
いや、Procオブジェクトを明示的にコーディングするのは稀だ
クロージャの無い Python とは違って、
Ruby だと普通は do |x| ... end や { |x| .... } で書ける

642 ：デフォルトの名無しさん：2014/12/01(月) 00:08:40.28 ID:v1/AC0CB.net

>>641
お前クロージャスレでフルボッコにされた奴か
ここでもフルボッコじゃねーかw

643 ：デフォルトの名無しさん：2014/12/01(月) 00:11:50.96 ID:WHPunuUw.net

>>638
スレタイでいうところの大規模開発なら特にそうだな
残念ながら言語の優先順位は低いと言わざるを得ない

644 ：デフォルトの名無しさん：2014/12/01(月) 00:13:16.83 ID:2BTgZC4D.net

結局は、静的言語が動的言語の要素を取り入れて進化し、両方の境界が曖昧になるんだよ。

645 ：デフォルトの名無しさん：2014/12/01(月) 00:15:06.71 ID:JhMfQ7kZ.net

>>642
逆だろw
クロージャを使えば簡潔に書けるのに、結局 Python ではコードが書けずに終わった
で、しまいに火病を発症してわめきちらしただけ、それがフルボッコなのか？www

今からでもいいから Python でコード書いてみな

646 ：デフォルトの名無しさん：2014/12/01(月) 00:18:09.70 ID:v1/AC0CB.net

>>644
そしてObjectに500個もメソッドを突っ込んで悦に入ってるゴミは
サーベルタイガーのように進化から取り残される、と

647 ：デフォルトの名無しさん：2014/12/01(月) 00:20:09.36 ID:JhMfQ7kZ.net

>>641
ほう、Python で Soft Typing が実用化されたとは初耳だ
ググってみると2003年に提案はあったものの、
その後に実装されたという情報は見つけられなかった

本当に実用化されているの？
また嘘でも何でも議論に勝ちさえばいいという発想じゃないのかなあ....

648 ：デフォルトの名無しさん：2014/12/01(月) 00:21:49.35 ID:v1/AC0CB.net

>>645
え？お前が勝手なクロージャの定義を持ち出して、
出展となる文献を出せと言われても出せず逃げただけじゃん

で、文献は？

649 ：デフォルトの名無しさん：2014/12/01(月) 00:28:35.48 ID:v1/AC0CB.net

>>647
>>396

650 ：デフォルトの名無しさん：2014/12/01(月) 00:29:56.57 ID:JhMfQ7kZ.net

>>674
クロージャの話題は完全にスレ違いだから、
続きを希望するなら当該スレへ移動してくれ
文献もそこで出すよ

651 ：デフォルトの名無しさん：2014/12/01(月) 00:36:07.76 ID:2BTgZC4D.net

>>646
そのゴミから色々なものが生まれた。
50年後には、そのゴミから新しいOSが生まれるかもよ。

652 ：デフォルトの名無しさん：2014/12/01(月) 00:39:00.66 ID:JhMfQ7kZ.net

>>649
外部にツールが存在することと、
ある言語が Soft Typing で設計されている話は関係ないよ
Python の言語処理系(インタプリタ)だけで
明示的な型宣言が無くとも実行前に型検査できるなら
話は別だけどね

というか、Soft Typing という用語の意味を
間違って理解しているんじゃね？

653 ：デフォルトの名無しさん：2014/12/01(月) 00:42:41.17 ID:v1/AC0CB.net

>>652
ある言語がSoft typingで設計されてるかなんて開発においてどうでも良すぎる
型推論に基づく実用的なツールがあるかどうかが重要

654 ：デフォルトの名無しさん：2014/12/01(月) 00:50:53.90 ID:JhMfQ7kZ.net

いかん、アンカを間違えてた
エスパーしてくれてるみたいだけど、念の為、訂正しとく

・>>647 内のアンカ >>641 は間違いで、>>640 が正しい
・>>650 内のアンカ >>674 は間違いで、>>648 が正しい

655 ：デフォルトの名無しさん：2014/12/01(月) 04:58:08.58 ID:CuP+pzia.net

>>560
かっこいいとかそういう基準で判断してるわけじゃないから。契約とか内容次第だから勝手なイメージだろ。

656 ：デフォルトの名無しさん：2014/12/01(月) 06:42:19.33 ID:Weh8bUwF.net

645はクラスを名前空間だと思い込んでいる初心者
早く補助輪を取れるといいね

657 ：デフォルトの名無しさん：2014/12/01(月) 09:10:41.83 ID:B1S4sCHX.net

そんなつまらない事にしかレスできないから
馬鹿にされるんだよｗ

658 ：デフォルトの名無しさん：2014/12/02(火) 12:19:36.12 ID:KrePR2s0.net

昔Basicはプログラマとしてのセンスを破壊すると言われたが、
今回Smalltalkも破壊することが判明したな

659 ：デフォルトの名無しさん：2014/12/02(火) 13:56:12.38 ID:3rN5XUau.net

２ちゃんねるは人間としての品格を破壊する

660 ：デフォルトの名無しさん：2014/12/02(火) 14:29:13.80 ID:XRdoM1I9.net

“Smalltalkのデバッガがどのくらい強力かと言うと、
任意の時点で任意のプロセスをインタラプトし
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続できるレベル。

デバッガは何枚でも開けられるし、作業の途中でやめたくなったら、
スナップショットを撮って終了し、再開すればその直前から続けられる。
たとえ、それが他のコンピューターでも(直接下回りを触っていない限り、
プラットフォームやOSが違っていても可)、それが10年後でも。”

https://twitter.com/abee2/status/539355671729152000

661 ：デフォルトの名無しさん：2014/12/02(火) 16:22:17.31 ID:+stn5l+y.net

10年とか先にarmのcpuが流行ってるとは思わなかったでしょ

662 ：デフォルトの名無しさん：2014/12/02(火) 19:47:59.90 ID:OQmm7jB2.net

>>660
凄いけど役に立たないなｗ

663 ：デフォルトの名無しさん：2014/12/02(火) 19:49:38.18 ID:OQmm7jB2.net

なんで役に立たないかというと

実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続したらバグで変な状態になった。
また止めて変な状態を直して、正しい所に移動させて続けることも可能だけど

最初からやり直したほうが早い。

664 ：デフォルトの名無しさん：2014/12/02(火) 22:07:07.23 ID:DpCZ+4Qy.net

>>663
ま、結局どんな凄い機能も、
使う人間のスキルと能力が足りなきゃゴミ以下って話だね。

665 ：デフォルトの名無しさん：2014/12/02(火) 22:38:50.95 ID:OQmm7jB2.net

人間はミスするとう前提の話をしてるんだが？
スキルや能力とは関係ない。

ミスしないようなすごい人しか使えない道具ではなく、
ミスしてもすぐにリカバリできる仕組みを作るほうが重要。

ということで静的型付け言語はそうなってるって話なんだよ。

666 ：デフォルトの名無しさん：2014/12/02(火) 22:48:09.93 ID:DpCZ+4Qy.net

>>665
静的型言語（の特に機能を限定した言語）がスキルの期待できない土方向け
という意見には反対しない。

667 ：デフォルトの名無しさん：2014/12/02(火) 22:52:44.71 ID:OQmm7jB2.net

一体何の機能が制限されているというのか？
タイプ数が少し増えるというのならわかる。
制限されているという機能の名前を聞いたことがないし、
どうでも良い機能のために、動的型付け言語を使うという話しか聞かない


静的型付け言語で出来ないことはないし、（たとえば、C言語は静的型付け言語）
多くのことが動的型付け言語よりも便利に行える。

デメリットはほんの少しタイプ量が増えるだけ

668 ：デフォルトの名無しさん：2014/12/02(火) 22:57:12.61 ID:ySWWhxWC.net

修正したコードが実機の上、しかもファイルじゃなくてメモリ上にしかないとか
よく考えなくても怖いことなんだけどな。

669 ：デフォルトの名無しさん：2014/12/02(火) 22:58:05.38 ID:AvSKqXZA.net

>>665
人間はミスするけど爆発しないよ
機械は爆発する
大規模なら大爆発

670 ：デフォルトの名無しさん：2014/12/02(火) 23:01:26.70 ID:DpCZ+4Qy.net

>>668
よく考えてたら、VCSにチェックインするとか想像できそうなものだけど。

671 ：デフォルトの名無しさん：2014/12/02(火) 23:23:32.69 ID:DpCZ+4Qy.net

>>668
> しかもファイルじゃなくてメモリ上にしかないとか

って、まともなSmalltalk処理系ならチェンジファイル機構くらいはあるだろjk

672 ：デフォルトの名無しさん：2014/12/02(火) 23:41:57.12 ID:f9ZuLJgk.net

>>667
動的型付けの利点はコンポーネント間を柔軟に結合できること
大規模開発の具体例は 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 の台頭を許した

673 ：デフォルトの名無しさん：2014/12/02(火) 23:43:16.07 ID:DpCZ+4Qy.net

Smalltalkをちょっとかじってみたい人のための、チュートリアルまとめ
http://qiita.com/sumim/items/6bed17961bd57daf88a3

アンチな人にも。

674 ：デフォルトの名無しさん：2014/12/03(水) 00:24:16.86 ID:B6A3kVmE.net

>>660
なぜDockerみたいな技術が持て囃され、こういう機能がスルーされるのか
Smalltalkerには永遠に理解できないんだろうな

Smalltalkは見当違いの問題を解いているんだよ
言語の中だけでリスタートできても意味がないんだ
価値がないから真似もされない

675 ：デフォルトの名無しさん：2014/12/03(水) 01:01:00.52 ID:/c7/jI5U.net

道具に使われてる人たちが・・・

676 ：デフォルトの名無しさん：2014/12/03(水) 01:03:45.51 ID:cgD8+cJC.net

>>674
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を
説明するのは難しい。

ユーザーがアクセスできる部品のすべてはユーザーが
観察し操作するのに適した方法で自らを表現できなければ
ならない

オペレーティングシステムがこの原則を破っているようで
あることはちょっと注目すべきだろう。

オペレーティングシステムは言語におさまりきらないものを
集めたもので、これは存在すべきでない

Smalltalkにはそうした意味での「オペレーティングシステム」は
無い。

677 ：デフォルトの名無しさん：2014/12/03(水) 01:07:46.87 ID:9SD5P0Ri.net

この言語は危ないという前提があった方が、本当に危なくなった時に逃げやすいね
言語を信用しすぎると逃げ遅れる

678 ：デフォルトの名無しさん：2014/12/03(水) 05:01:07.21 ID:Fu5jXwDM.net

>>668
大抵のSmalltalk処理系はソース編集をジャーナリングしているのだが？
普通の開発環境でいえば、
テキストエディタで編集するごとに自動的にcommitしているようなもの。
PVSやMonticelloを使えばもっと高機能かつ安全だ。

むしろ、commitを自分でやらないと編集履歴が残らない
普通の開発環境のほうがよく考えなくても怖いことなんだけどな。

679 ：デフォルトの名無しさん：2014/12/03(水) 09:01:37.48 ID:XWw3OxN9.net

>>676
OSの上でOSゴッコしてるだけのSmalltalkが笑わせてくれる

680 ：デフォルトの名無しさん：2014/12/03(水) 09:09:27.83 ID:RRftfJUJ.net

>>678
もう少し分かりやすくいおう。

SmalltalkはVCSが言語に統合されている。

VCSが言語に統合されていない言語では、
自分で統合するかIDEの力を借りる。

そこまでセットアップする手間を省けるだけなのだ。

681 ：デフォルトの名無しさん：2014/12/03(水) 09:13:57.48 ID:RRftfJUJ.net

>>672

> 大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク
> Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、
> コンポーネント間の結合に用いるオブジェクトに対しては id型 という動的型付けを用いる
> 結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている

動的型付け言語じゃなくても達成出来てることを言われてもなｗ
だいたい発展し続けると言っても、再起動してるじゃん。
なぜ動的型付け言語ならではの理由が
あんたの言っていることには一つのないんだよね。

682 ：デフォルトの名無しさん：2014/12/03(水) 09:21:29.91 ID:XWw3OxN9.net

>>678
マイナー言語のショボいVCS使ってないで
さっさとgit覚えてください

683 ：デフォルトの名無しさん：2014/12/03(水) 10:48:31.33 ID:9SD5P0Ri.net

なんでも理由があるべきという思い込みはよくない
実力だけでなく運で決まることもたくさんある

684 ：デフォルトの名無しさん：2014/12/03(水) 11:22:27.25 ID:zGKDhFQQ.net

>>682
Smalltalkを使っている人間はgitを理解できないと決めつける時点で
発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、
古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。

685 ：デフォルトの名無しさん：2014/12/03(水) 12:24:53.21 ID:zGKDhFQQ.net

>>674
> Smalltalkは見当違いの問題を解いている

Smalltalkはもう過去の遺物だし、問題はすでに解き終わっている。
あとはSmalltalkがどう解いたかを調べて理解するだけでいいと思うよ。
そこから使えそうなアイデアだけを引っ張ってきてちょっと見栄えをよくすれば、
運が良ければイノベーションや新しいトレンドも生み出せる（した人もいる）。

古くはWIMPなGUIしかり、MVCやコレクションなどのフレームワークしかり、
XPやTDDなどアジャイルな開発手法しかり、近年であればトレイトやクラスボックスしかり。

向いている方向が見当違いだというのは同意するけど、それはたまたま今は
ファイルシステムに密着したUNIXライクなOS＋C言語マシンで成り立つ世界だからで
そこから外れた物の見方はいっさい価値なしと切り捨ててしまうのは少しもったいない。

少し、だけどね。土方には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
食いつないでいくためにはまずそっちを優先すべきだし。

686 ：デフォルトの名無しさん：2014/12/03(水) 14:17:36.95 ID:Fu5jXwDM.net

>>679
原論文を理解できなかったなら正直にそう書けばいいのにw

687 ：デフォルトの名無しさん：2014/12/03(水) 14:23:59.81 ID:Fu5jXwDM.net

>>674
メインフレームを笑っていたUnix厨が
メインフレーム由来の仮想化技術をあたかも最新技術のように持て囃す、
あんたが好きな「価値」ってのはその程度のものだ
必死に追いかければ、その先に青い鳥がいるかもなあw

688 ：デフォルトの名無しさん：2014/12/03(水) 20:48:36.10 ID:nRr7XZh4.net

Dockerはunixの世界においても枯れた既存技術の寄せ集めだし、
最新技術だから持て囃されてるんじゃないよ

標準化の動きが急速に進んでて、クラウドサービスにベンダーロックインされる危険が極小になる所が肝
あるクラウドサービスで動かしてた仮装イメージを、別のサービスに即座に引っ越せるようになる

メインフレームみたいに極限までロックインさせる話とは根本的に違う
やっぱり分かってないと言わざるを得ない

689 ：デフォルトの名無しさん：2014/12/03(水) 21:23:44.95 ID:o4Xb4UE8.net

ベンダーロックインを静的型にたとえると

短いソースをコンパイルするために多くのヘッダーをincludeすることを強制される
ヘッダーと本体が分かれていない言語では全部必要

690 ：デフォルトの名無しさん：2014/12/03(水) 21:45:16.01 ID:RRftfJUJ.net

>>689
じゃあRubyもPythonもだめだな。

ブラウザで動くJavaScriptは大丈夫か？
include相当の構文がないもんなｗ

691 ：デフォルトの名無しさん：2014/12/03(水) 21:49:32.75 ID:RRftfJUJ.net

>>685
> には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
> ついて行かなきゃいけないトレンドや技術がいっぱいあるから、

プロなら当たり前のことなんじゃねーの？


プロには目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、

うん、違和感ない

692 ：デフォルトの名無しさん：2014/12/03(水) 22:07:22.24 ID:o4Xb4UE8.net

>>690
モジュールの依存関係は大したことはない
型の依存関係は基底クラスやprivateメンバーの型まで伝播する

693 ：デフォルトの名無しさん：2014/12/03(水) 22:22:38.66 ID:RRftfJUJ.net

そのおかげで、矛盾するもの。つまり
明らかに動かないコードを検出することが可能になっている。

動的型付け言語では、動かして該当コードに
たどり着かないとわからないバグを
動かすことなく見つけることが可能になってる。

これこそ、大規模開発で必要なことの一つなんだ。

694 ：デフォルトの名無しさん：2014/12/03(水) 22:25:08.05 ID:o4Xb4UE8.net

大規模炎上の主な原因はバグではなく設計ミスではないのか

695 ：デフォルトの名無しさん：2014/12/03(水) 22:26:49.02 ID:B6A3kVmE.net

静的型の方がアカデミック方面での発展も凄いので
確かに学ぶことは多いと思うよ

696 ：デフォルトの名無しさん：2014/12/03(水) 22:31:22.32 ID:0xDgvp4s.net

>>694
違う、営業的に決められた納期だな

697 ：デフォルトの名無しさん：2014/12/03(水) 22:36:19.29 ID:RRftfJUJ.net

>>694
大規模炎上の話なんかしていないｗ

まず、スコープが小さいほど、変更が与える影響は少ない。
プライベートメソッドなら、クラスの外は関係ないし、
関数内の修正は、引数と戻り値さえ同じなら
どう修正しても問題ない。

修正の影響範囲が大きいのはスコープが多い時なんだ。
例えばクラスメソッド引数が変更された時、
その他の"すべての"ファイルから参照しているコードを突き止めないといけない。
基底クラスが変更になった時、その全ての派生クラスへの影響を考えないといけない。

そこに静的型付け言語のメリットが生きてくる。
動的型付け言語だと、クラスを変更した時、そのクラスの利用者全てを確認するのは難しい。
なぜなら変数に依存関係が明示されていないから。
静的型付け言語だと、変数に型を明示するから、変更による影響を瞬時に知ることができる。

これこそ大規模開発で必要なことなんだよ。

698 ：デフォルトの名無しさん：2014/12/03(水) 22:43:05.49 ID:o4Xb4UE8.net

うっかり基底クラスを変更したら
継承も知らないのかと疑われそうで嫌だな

699 ：デフォルトの名無しさん：2014/12/03(水) 22:44:57.73 ID:RRftfJUJ.net

モジュール間の依存は小さくするというのは
ソフトウェアの開発者の常識だが、
なぜ小さくするのかというとモジュール間の依存が大きいと
修正する時に発生する影響範囲が大きくなって修正が大変だからなんだ。

だからモジュール間の依存は小さくするべきだが、
モジュールを連携してシステムが動く以上0にはできない。

例えば、obj.foo() というコードがあったとき、そこには
objはfooメソッドを持っていなければならないという依存情報が生まれる。

この依存情報を動的型付け言語では、実行時までチェックしない。
静的型付け言語ではobjの型を明示することで、
実行前にfooメソッドが有ることを確認できる。

影響範囲を確認することが大変なモジュール間の依存を
明確にすることで、不具合の発見を容易にし
修正のコストを減らすのが、静的型付け言語の特徴なんだ。

700 ：デフォルトの名無しさん：2014/12/04(木) 01:15:00.87 ID:jHjIGczB.net

インタフェースみたいにメソッドの実装を強制したいです
どうしますかおしえて

701 ：デフォルトの名無しさん：2014/12/04(木) 02:09:44.10 ID:8pz5p6Zv.net

したら良いんじゃない？
できない言語を使ってるの？

702 ：デフォルトの名無しさん：2014/12/04(木) 08:48:23.43 ID:1fNTZGeK.net

>>700
実装しなかったら開発者をクビにする

703 ：デフォルトの名無しさん：2014/12/04(木) 09:42:52.10 ID:rp/BpD2j.net

>>688
超マイナーなVCSや低性能のODBに
自分からロックインされに行く技術オンチのSmalltalkerには
遠い世界の話だな

704 ：デフォルトの名無しさん：2014/12/04(木) 10:26:14.06 ID:5ZEJ+Feh.net

>>700
変数の初期化 (null以外) を強制したいとは言わないところが甘い
厳しいのか甘いのかはっきりしない機械は駄目だ
そういうのは人間の方が向いている

705 ：デフォルトの名無しさん：2014/12/04(木) 12:32:36.38 ID:TqunBxc9.net

>>703
> 超マイナーなVCSや低性能のODBに
> 自分からロックインされに行く

ありがたい話じゃないか。
そこまでしてSmalltalkから将来出てくるであろう新しい何かを育ててくれるんだから。
トレイトしかりクラスボックスしかり。

706 ：デフォルトの名無しさん：2014/12/04(木) 19:31:17.50 ID:mwV5k8HO.net

>>703
Smalltalkでは何十年も昔から常識だったことが
新技術として他の言語や環境でも使えるようになったら
「こんな便利な技術は技術オンチのSmalltalkerには理解できないだろう」
とか言いながらありがたく使いなさいよ、技術乞食さんw

707 ：デフォルトの名無しさん：2014/12/04(木) 20:15:36.06 ID:rp/BpD2j.net

>>705
traitはSmalltalk由来のじゃなくて
Haskellの型クラス由来のヤツが残りそう

やっぱり作ってる連中の知的レベルが段違いだしね？

708 ：デフォルトの名無しさん：2014/12/04(木) 21:21:32.12 ID:tYdcY83W.net

え？ なに？ 俺の言語が起源だとかいう話をしてんの？

起源なんかどうでもよくて、その技術を
"今" 有効活用することのほうが大事だろ。

起源はベータ版。今その技術を取り入れた言語というのは
ベータ版を評価して、より優れた方法で取り入れてるってことなんだよ。

つまり、同じ機能であっても、起源よりも
後から取り入れた言語のほうが優れている。

初号機のほうが優れているっていうのは漫画の中の話だけだよ。
現実には、二号機、三号機の方が優れている。

709 ：デフォルトの名無しさん：2014/12/04(木) 21:36:40.87 ID:RpORv8ek.net

>>707
traitsとかホントは知らないんだろ？
implicit parameterと区別が付かないとかないわー

710 ：デフォルトの名無しさん：2014/12/04(木) 21:47:04.11 ID:8pz5p6Zv.net

>>709
この論文は読んだ上で言ってるの？
あ、Martin OderskyはScalaの作者ね

http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf

711 ：デフォルトの名無しさん：2014/12/04(木) 21:48:59.20 ID:RpORv8ek.net

>>708
パクる元がなければ改良もクソもないんだから
アイデアのゆりかご的存在は生かさず殺さずにしておく方がいい
って話なんだが。どうして優劣の話になるかな

712 ：デフォルトの名無しさん：2014/12/04(木) 21:50:19.83 ID:5ZEJ+Feh.net

>>708
初号機には二号機をスルーして三号機に移行する作戦があるから
二号機はどうでもよい

713 ：デフォルトの名無しさん：2014/12/04(木) 21:54:36.04 ID:RpORv8ek.net

>>710
Scalaだからinterfaceの代わりにtraitを使っただけで、
型クラスとは関係ないだろう。

714 ：デフォルトの名無しさん：2014/12/04(木) 22:05:12.01 ID:8pz5p6Zv.net

>>713
最初の方だけでも読んでみようとは思わないの？

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

715 ：デフォルトの名無しさん：2014/12/04(木) 22:11:18.04 ID:tYdcY83W.net

このペーパー、プレゼントします

最初の方だけ読みました！

716 ：デフォルトの名無しさん：2014/12/04(木) 22:16:14.84 ID:RpORv8ek.net

>>714
だからそれのどこに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.

717 ：デフォルトの名無しさん：2014/12/04(木) 22:20:18.91 ID:8pz5p6Zv.net

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

718 ：デフォルトの名無しさん：2014/12/04(木) 22:24:26.97 ID:8pz5p6Zv.net

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

719 ：デフォルトの名無しさん：2014/12/04(木) 22:29:19.94 ID:RpORv8ek.net

>>717
>>713

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,

720 ：デフォルトの名無しさん：2014/12/04(木) 22:30:05.46 ID:tYdcY83W.net

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

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

721 ：デフォルトの名無しさん：2014/12/04(木) 22:45:30.93 ID:RpORv8ek.net

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

722 ：デフォルトの名無しさん：2014/12/04(木) 22:52:15.50 ID:8pz5p6Zv.net

>>719

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

723 ：デフォルトの名無しさん：2014/12/04(木) 23:00:58.08 ID:5ZEJ+Feh.net

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

724 ：デフォルトの名無しさん：2014/12/04(木) 23:08:55.47 ID:RpORv8ek.net

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

725 ：デフォルトの名無しさん：2014/12/04(木) 23:11:32.11 ID:8pz5p6Zv.net

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

726 ：デフォルトの名無しさん：2014/12/04(木) 23:13:27.66 ID:BoUkojKR.net

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

727 ：デフォルトの名無しさん：2014/12/04(木) 23:24:08.54 ID:BoUkojKR.net

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

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

728 ：デフォルトの名無しさん：2014/12/04(木) 23:40:50.93 ID:RpORv8ek.net

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

説明してミソ

729 ：デフォルトの名無しさん：2014/12/05(金) 00:15:41.66 ID:RG1/KShi.net

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

730 ：デフォルトの名無しさん：2014/12/05(金) 00:20:26.42 ID:lYb7FfYs.net

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

731 ：デフォルトの名無しさん：2014/12/05(金) 02:25:30.08 ID:3qncuvNa.net

>>729
おまえ頭わるいな

732 ：デフォルトの名無しさん：2014/12/05(金) 07:42:45.52 ID:ViNbqhcv.net

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

733 ：デフォルトの名無しさん：2014/12/05(金) 09:04:37.51 ID:t8jCTeme.net

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

734 ：デフォルトの名無しさん：2014/12/05(金) 09:13:02.76 ID:A1Nk4WQY.net

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

735 ：デフォルトの名無しさん：2014/12/05(金) 09:16:51.57 ID:+TXyzC2W.net

>>734
それお前じゃね？

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

736 ：デフォルトの名無しさん：2014/12/05(金) 10:11:29.20 ID:sLA7oQpI.net

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

737 ：デフォルトの名無しさん：2014/12/05(金) 11:25:40.15 ID:viBzu9Eo.net

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

738 ：デフォルトの名無しさん：2014/12/05(金) 12:26:12.88 ID:51P5EYrc.net

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

739 ：デフォルトの名無しさん：2014/12/05(金) 12:31:26.53 ID:+5KFbbdu.net

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

740 ：デフォルトの名無しさん：2014/12/05(金) 13:25:22.71 ID:eWvM3tpo.net

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

741 ：デフォルトの名無しさん：2014/12/05(金) 13:38:18.27 ID:AoGRS1Po.net

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

742 ：デフォルトの名無しさん：2014/12/05(金) 16:19:55.77 ID:+5KFbbdu.net

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

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

743 ：デフォルトの名無しさん：2014/12/05(金) 18:10:35.44 ID:N759beub.net

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

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

744 ：デフォルトの名無しさん：2014/12/05(金) 20:31:39.15 ID:+TXyzC2W.net

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

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

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

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

745 ：デフォルトの名無しさん：2014/12/05(金) 20:46:05.48 ID:+TXyzC2W.net

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

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

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

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

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

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

746 ：デフォルトの名無しさん：2014/12/05(金) 20:46:44.48 ID:+5KFbbdu.net

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

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

747 ：デフォルトの名無しさん：2014/12/05(金) 20:50:24.12 ID:+5KFbbdu.net

>>743
>>746

748 ：デフォルトの名無しさん：2014/12/05(金) 21:12:23.79 ID:+TXyzC2W.net

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

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

749 ：デフォルトの名無しさん：2014/12/05(金) 21:28:30.39 ID:5SBzstV5.net

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

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


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

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


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

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

750 ：デフォルトの名無しさん：2014/12/05(金) 21:30:47.47 ID:+TXyzC2W.net

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

別にDLLでもできるけど？

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

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

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

751 ：デフォルトの名無しさん：2014/12/05(金) 21:32:11.34 ID:+TXyzC2W.net

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

752 ：デフォルトの名無しさん：2014/12/05(金) 21:35:46.33 ID:+TXyzC2W.net

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

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

753 ：デフォルトの名無しさん：2014/12/05(金) 22:06:36.60 ID:viBzu9Eo.net

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

754 ：デフォルトの名無しさん：2014/12/05(金) 22:08:26.02 ID:5SBzstV5.net

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

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

755 ：デフォルトの名無しさん：2014/12/05(金) 22:40:22.11 ID:5SBzstV5.net

>>733
これかな
・Rubyist Magazine - Rubyist のための他言語探訪 【第 2 回】 CLU
　http://magazine.rubyist.net/?0009-Legwork


>>738
> いや。Rubyのブロック自体はLISPのlambda由来かと。

だね
Ruby は LISP をベースにして設計された
Ruby のブロックも LISP のクロージャ(ラムダ式)に由来する
・Lisp から Ruby への設計ステップ | プログラマーズ雑記帳
　http://yohshiy.blog.fc2.com/blog-entry-250.html

756 ：デフォルトの名無しさん：2014/12/05(金) 23:20:42.11 ID:5SBzstV5.net

>>738
> 今のブロック付きメソッド呼び出し（昔はイテレータと呼んでいた）が
> CLUのイテレータから発想を得た…というだけで。

ここは違うと思うな
どちらかといえば Ruby が CLU から強い影響を受けたのは、
要素を返すのに yield 構文を用いる、いわゆる「内部イテレータ」だと思う
たとえば >>738 の 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 等には)存在しない特徴

757 ：デフォルトの名無しさん：2014/12/05(金) 23:41:12.21 ID:+5KFbbdu.net

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

758 ：デフォルトの名無しさん：2014/12/06(土) 04:27:17.30 ID:VJF2Er6M.net

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

759 ：デフォルトの名無しさん：2014/12/06(土) 09:50:46.00 ID:75gyZyE4.net

Smalltalkで>>756の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

760 ：デフォルトの名無しさん：2014/12/06(土) 10:16:45.25 ID:awxYdbKb.net

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

761 ：デフォルトの名無しさん：2014/12/06(土) 11:43:34.93 ID:VJF2Er6M.net

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

762 ：デフォルトの名無しさん：2014/12/06(土) 11:53:26.46 ID:75gyZyE4.net

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

763 ：デフォルトの名無しさん：2014/12/06(土) 12:39:03.22 ID:awxYdbKb.net

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

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

764 ：755：2014/12/06(土) 16:06:50.42 ID:viXCL8M/.net

>>756 では「1 から 3 の範囲を」と書いたけど、具体的なコードを忘れていた

CLU では、>>756 で定義したイテレータ from_to を以下のように利用する
　for i:int in int$from_to(1, 3) do
　　　....
　end

Ruby では、>>756 で定義したイテレータ from_to を以下のように利用する
　from_to(1, 3) do |i|
　　　....
　end


>>758
> Pythonでも普通にyieldで

失礼、Python にも yield 文があった
ざっと調べてみたけど、どちらかというと(Ruby よりも) Python のほうが
CLU のイテレータを忠実に実装しているようだ

765 ：デフォルトの名無しさん：2014/12/06(土) 16:45:53.73 ID:viXCL8M/.net

>>761,761
Ruby では >>755 のリンク先文書で Matz が
「イテレータの定義の仕方は驚くほど Ruby に似ています。 真似したんだから当然です。
　元々 Ruby のブロックは CLU のイテレータに似たものを実現するためにデザインされたからです」
と書いているように、(おそらく)最初からイテレータが存在していました
少なくとも Ruby 1.4 を元にして1999年に出版された書籍「オブジェクト指向スクリプト言語Ruby」では、
節「2.18.4 yield」で(>>756 のコードのような)イテレータ定義方法が詳しく解説されている


それに対して 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 の時代から存在しているなら、ソースを提示してくれ

ソースが提示できないのなら、>>761 は
　> どうしてPythonを推したい人は
　> 後から追加された機能を元からあったことに
　> したがるのだろうか？
と訂正したほうがいいだろね

766 ：デフォルトの名無しさん：2014/12/06(土) 16:55:53.06 ID:tymH4H6t.net

る厨、渾身の反撃

767 ：デフォルトの名無しさん：2014/12/06(土) 18:06:07.33 ID:dOSwxHPK.net

>>765

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

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

768 ：デフォルトの名無しさん：2014/12/06(土) 18:10:44.25 ID:dOSwxHPK.net

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

769 ：デフォルトの名無しさん：2014/12/06(土) 18:17:10.96 ID:tymH4H6t.net

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

770 ：デフォルトの名無しさん：2014/12/06(土) 18:21:50.32 ID:tymH4H6t.net

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

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

771 ：デフォルトの名無しさん：2014/12/06(土) 18:37:35.84 ID:dOSwxHPK.net

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

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

772 ：デフォルトの名無しさん：2014/12/06(土) 18:41:59.78 ID:viXCL8M/.net

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


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

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

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


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

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

773 ：デフォルトの名無しさん：2014/12/06(土) 18:56:12.98 ID:dOSwxHPK.net

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

774 ：デフォルトの名無しさん：2014/12/06(土) 19:13:11.97 ID:Ee/H8Kvv.net

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

775 ：デフォルトの名無しさん：2014/12/06(土) 19:22:45.98 ID:dOSwxHPK.net

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

776 ：デフォルトの名無しさん：2014/12/06(土) 19:30:05.03 ID:Ee/H8Kvv.net

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

777 ：デフォルトの名無しさん：2014/12/06(土) 20:16:53.72 ID:viXCL8M/.net

>>773
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 (>>765)だったんじゃないかと思われ....


>>774
外部イテレータ、いわゆるジェネレータは Ruby 1.8 にも標準ライブラリで提供されていた
1.9 では、これが組込みライブラリとして再実装されただけ




で、「Python では元からyield文があった(>>761)」という主張のソースはまだかなぁーー？？？
やっぱりPython使いはウソツキばかりなのかね

778 ：デフォルトの名無しさん：2014/12/06(土) 20:40:35.48 ID:dOSwxHPK.net

>>777
> November 2001

PEP255の後じゃん

779 ：デフォルトの名無しさん：2014/12/06(土) 21:59:22.89 ID:7vCPkvQk.net

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

780 ：デフォルトの名無しさん：2014/12/06(土) 22:26:02.16 ID:tymH4H6t.net

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

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

781 ：デフォルトの名無しさん：2014/12/06(土) 23:01:36.75 ID:q7blqefO.net

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

782 ：デフォルトの名無しさん：2014/12/07(日) 00:03:15.33 ID:zkEhiByJ.net

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

783 ：755：2014/12/07(日) 00:07:58.15 ID:hGORpEWm.net

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

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

784 ：デフォルトの名無しさん：2014/12/07(日) 00:14:16.44 ID:dQg0RQig.net

>>782
だろうね。

動的型付け言語はいわば実験台。
どこで出来たものに型を取り付けることで
完全体になる。

785 ：デフォルトの名無しさん：2014/12/07(日) 00:45:01.66 ID:svj68kfn.net

>>783
> 内部イテレーターがCLU発祥
だとすれば
Smalltalkの#do:はこの場合どういう扱いになるの？
あれも内部イテレーターだろう。

786 ：デフォルトの名無しさん：2014/12/07(日) 00:49:15.39 ID:3Elo+9Qw.net

嘘はよくないけど逃げるのはよいよね
間違いを認めるとかはどうでもよい

787 ：デフォルトの名無しさん：2014/12/07(日) 01:50:41.36 ID:hGORpEWm.net

>>785
Smalltalk のアレも内部イテレータだね

反復(iteration)をコルーチンとして抽象化する最初の発想は、CLU と Smalltalk の共通の祖である Simula 67 で生まれ、
それはジェネレータと呼ばれていた
そして、その発想はどちらの言語にも継承されたけど、静的型付けな手続き型言語である CLU と
動的型付けなオブジェクト指向言語である Smalltalk とでは、実現方法が異なった

CLU は iter 宣言と yield 文という抽象化向けの構文を導入し、反復処理の表現(プログラミング)を洗練させた
また反復の概念を整理/形式化し、それにイテレータという名称を与えたのは CLU の功績
だからイテレータの始祖は CLU であると、一般には認知されている

それに対してブロック(=クロージャ)を持つ Smalltalk は、(CLU のように苦労することなく)反復処理を抽象化できた
実際、Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない
結果として Smalltalk のコミュニティの中でジェネレータは反復処理のプログラミング技法、
いわゆるイディオムとしては認知されていたけど、それが学術的に議論されることは無かった
（実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた）
こうした、ある新しく登場した概念が実は Smalltalk の世界だとありふれたイディオムでしかなかったという現象は、
(たとえばデザインパターンのように)しばしば見かけられる

788 ：デフォルトの名無しさん：2014/12/07(日) 02:03:23.69 ID:hGORpEWm.net

>>786
結局、逃げたってことなのね
それならそれで、いいんじゃないかな
では、これでスレ違いなイテレータの話題は終わりにしよう

反復処理を抽象化するイテレータは大規模開発にとって重要だと思うけど、
CLU と Smalltalk の例(>>787)のように
静的型付け/動的型付けのどちらにも共通する概念だから、
スレの主旨からは外れていると思う

789 ：デフォルトの名無しさん：2014/12/07(日) 08:12:25.48 ID:vPGA0H7X.net

Rubyコミュニティによるイテレータの歴史歪曲については
少なくともRubyが再発見したおかげで内部イテレータが再評価されたわけではない(>>778)し、
>>756には他にも事実誤認があるのだからいくら言葉尻で言い訳しても墓穴が大きくなるだけ

790 ：デフォルトの名無しさん：2014/12/07(日) 08:23:27.33 ID:NlsKlGNA.net

ルビーより後に実装されたのはみんなルビーの真似w

791 ：デフォルトの名無しさん：2014/12/07(日) 09:49:05.54 ID:3Elo+9Qw.net

歴史歪曲を考える暇があったら、副作用の順序を間違える事案について考えよう

792 ：デフォルトの名無しさん：2014/12/07(日) 09:51:11.11 ID:bfkTF4nN.net

ここの住民には無理

793 ：デフォルトの名無しさん：2014/12/07(日) 09:56:13.58 ID:NlsKlGNA.net

>>777-778の流れが全てを物語っているw

794 ：デフォルトの名無しさん：2014/12/07(日) 13:22:05.08 ID:6EqZg1tl.net

>>787
> Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない

next は分かるのですが、first を定義する必要があるというのは初耳です。
そのようなプロトコルが規定されているのは何というSmalltalk処理系ですか？
あるいはそのように記述された文献をお示しいただければさいわいです。

あと、Smalltalkの外部イテレーター（内部イテレーターとしても使用できる）としては
Streamが有名ですが、これとおっしゃっておられる「Smalltalkのジェネレーター」との
関係を教えてください。

> 実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた

寡聞にして知りませんでした。
たとえば具体的にどんな文書でそのような用語が使われていたか教えていただけると助かります。

795 ：デフォルトの名無しさん：2014/12/07(日) 13:42:54.66 ID:acBjRoXT.net

> Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない

一つ疑問があるんだけどさ、firstとnextをジェネレータとは
違う用途で使ったオブジェクトはどうなるの？
正しく動かないと思うけど。

そうすると、firstとnextはジェネレータで使うための名前ですって
予約語みたいな扱いになっているということ？

796 ：デフォルトの名無しさん：2014/12/07(日) 14:10:40.21 ID:3Elo+9Qw.net

>>795
お前はなぜ正しく動かないと分かったのか
分かったのに分からないふりをする動機は何か
この動機を打ち消すことができれば生産性が上がるんじゃないか

797 ：デフォルトの名無しさん：2014/12/07(日) 14:18:07.50 ID:acBjRoXT.net

>>796
何を言ってるのさ？
純粋に疑問になっただけ

例えばfirstという名前で、初期化処理
secondという名前で、2番目の処理、
thirdという名前で3番目の処理
みたいなことをしているオブジェクトがあったとしたら
当然ジェネレータとしては使えない。

だからfirstという関数名はジェネレータのfirstの
仕様を守らないといけないというルールがあるのか？って話なんだが。

798 ：デフォルトの名無しさん：2014/12/07(日) 18:16:20.48 ID:hGORpEWm.net

>>794
>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 とイテレータを扱った文献が存在していたなら、ぜひ教えてほしいですね

799 ：デフォルトの名無しさん：2014/12/07(日) 19:37:57.79 ID:eR9x6pgx.net

>>798
なるほどティモシー・バットの実装・主張でしたか。
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」という
呼称でそれを語るのは、聞き手に無用の混乱を招くので
今後は避けられた方がよいと思います。

800 ：デフォルトの名無しさん：2014/12/07(日) 20:20:51.08 ID:hGORpEWm.net

>>799
結論としては、今のところ挙っているソース(文献)を前提とすれば：
・オリジナルの Smalltalk コミュニティでは概念としてのイテレータは存在していなかった
・ただしコレクションやストリームの実装で用いられた Smalltalk の作法(慣習)は、
　デザパタ本(GoF)によって内部イテレータとして分類された
ということですかね

801 ：デフォルトの名無しさん：2014/12/07(日) 21:29:04.46 ID:eR9x6pgx.net

>>800
> もしも CLU 以前の時代に Smalltalk とイテレータを扱った文献が存在していたなら、ぜひ教えてほしい

もとより、リスコフが件のループ処理の抽象化にイテレータと名付けて発表したのは1977年のこの文献
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.656&rep=rep1&type=pdf
だと思うのですが、そうすると同様のことを目指す類似の仕組みがあったとして、それを
「イテレータ」と呼称するには少なくとも1977年以降でなければ困難だと思うのですが、これは
1977年以前に実装され、活用されていたという事実を示せばいいという解釈でよろしいですか？

それとも、「イテレータ」という言葉を使っていないとダメという縛りでしょうか？

802 ：デフォルトの名無しさん：2014/12/07(日) 23:41:25.71 ID:hGORpEWm.net

>>801
自分もその文献を参照して CLU がイテレータで生まれたと判断しました
だから、時期としてはそれ以前ということですね

またイテレータという名称にこだわる必要はありませんが、
first と next という作法で実現できる外部イテレータは
C++/Java だけでなくC言語でも実装できる一般的なプログラミング技法ですから、
CLU の内部イテレータからは外れるでしょう
またループ処理の抽象化はイテレータだけでなく LISP を始祖とする関数型言語の
map 関数がありますが、これをイテレータと呼ぶのは無理があるでしょう

CLU の内部イテレータは、当時のクロージャを持たない手続き型言語へ
コルーチンの仕掛けを洗練された形で組み込んだことに意義があると思います
もし CLU 以外にも、当時の手続き型言語の中でループ処理の抽象化に
取り組んだ研究があったなら、興味深いですね

803 ：デフォルトの名無しさん：2014/12/08(月) 08:33:17.02 ID:voJSmgM1.net

>>802
つまり、
コルーチンを使っていなければ内部イテレータとは呼べない
という縛りですね？

804 ：デフォルトの名無しさん：2014/12/08(月) 09:55:18.35 ID:kmGTZboH.net

外部イテレータは存在意義が分かるんだけど、
内部イテレータの存在意義が分からない
高階関数があれば全く不要じゃないの？こんなもんに予約語使うRubyは馬鹿なんじゃないの？

805 ：デフォルトの名無しさん：2014/12/08(月) 10:47:05.59 ID:7TNBMlk3.net

結局、Rubyコミュニティ内でも、

> Rubyのイテレータは用途的にはCLUのイテレータよりも
> Smalltalkのブロック (を受け取るメソッド)に似ている
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/13374

という結論になっているんだね。

806 ：デフォルトの名無しさん：2014/12/08(月) 11:52:53.80 ID:hyn7lotS.net

LispやSmalltalkは低級言語に似てないからダメ
同じ理由で高階関数もダメだろうと高を括っていたんじゃないか
ところが現実はC++でも高階関数を使いこなせるレベルになりつつある

807 ：デフォルトの名無しさん：2014/12/08(月) 19:51:47.86 ID:Ag3PuK/D.net

言語の仕様の変更が柔軟なのは動的型付け言語なんだよな。
型のことを考える必要がないぶん、アイデアをすぐに実装できる。

だけど、そのアイデアそのものは静的型付け言語でも実装可能。
型を考える分だけ時間がかかるだけ。

動的型付け言語の機能はほぼ全て静的型付け言語で実装できるし、
型安全になりさらにいい形で実装される。

808 ：801：2014/12/08(月) 21:41:44.49 ID:9AWpAGuY.net

まず >>802 の日本語が変だったので訂正
X: 自分もその文献を参照して CLU がイテレータで生まれたと判断しました
O: 自分もその文献を参照してイテレータが CLU で生まれたと判断しました


>>803
いや、CLU はコルーチンを使っていないし、そんな縛りはありませんよ
ループ処理を生産者/消費者に分割するプログラミング技法としてコルーチンが
CLU 以前から知られていましたけど、保守のしづらいコードになりがちでした
そのコルーチンを使わずにループ処理を抽象化したのが CLU のイテレータです


>>804
> こんなもんに予約語使うRubyは馬鹿なんじゃないの？

だとしたら、ジェネレータ(外部イテレータ)が重要な言語の構成要素であり、
なおかつ高階関数もすでに備えていたにもかかわらず、
後からわざわざ予約語 yield を追加した Python の PEP 205(>>765) は
Ruby 以下の大馬鹿ってことですね

自分としては、ジェネレータを(まるで内部イテレータのように)簡潔に定義できるようにすることを
意図した PEP 205 の判断は適切であったと思っていますけど、
まあ、仕様追加を容認/批判するのは人それぞれなんでしょうね....

809 ：デフォルトの名無しさん：2014/12/08(月) 21:47:10.82 ID:NhV7D2A0.net

外部イテレータを内部イテレータかのように記述できるPythonのyieldには価値がある
だからJavascript(ES6)などにも採用されている

一方、Rubyの内部イテレータには価値が無い
単純な話じゃん

810 ：801：2014/12/08(月) 22:43:49.37 ID:9AWpAGuY.net

>>805
>>755 で書いたように Ruby は LISP をベースに設計され、
ブロックも LISP のクロージャに由来します
だから、同じブロックを使う Smalltalk と意味が似るのは不思議じゃないですね

実際 >>756 のイテレータ定義は、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 と類似するという
結果になるのでしょう

811 ：801：2014/12/08(月) 23:29:50.99 ID:9AWpAGuY.net

>>806
元々の質問者(>>801, ID:eR9x6pgx)の方が Smalltalk に詳しそうなので、
1997年の CLU および Smalltalk-80 以前における初期の Smalltalk の
(後にGoF本で内部イテレータと呼ばれることになる)ループ処理設計の誕生話を期待していました
自分は Smalltalk にはそれほど詳しくないんで、それ辺りの歴史を披露してもらえたら嬉しかったですね

あるいは1970年代に Scheme で生まれた継続(コンティニュエーション)の概念や、
並行ループ処理をプロセス構造で表現する CSP や実装言語である Occam あたりかもしれないと
想像していました
これら現在ではイテレータには分類されていないけど実はループ処理の抽象化に関連していた
過去の埋もれた知見が得られるか、つまり何かを再発見できるかと期待していたんですが、
結局、想定されていたのは良く知られた(=ありふれた)高階関数だったのですかねぇ.....

まずは彼からのレスを待つことにします

812 ：デフォルトの名無しさん：2014/12/08(月) 23:59:43.81 ID:wXlNa9C1.net

>>808
> CLU はコルーチンを使っていないし、そんな縛りはありません

おっしゃりたいことがちょっとよく分かりません。

> 801
> CLU の内部イテレータは、―
> コルーチンの仕掛けを洗練された形で組み込んだことに意義がある

これは、コルーチン“的な”仕掛け、という意味で、
コルーチンである必要はないということですか？

例えば、まだクロージャをもたないSmalltalk-76の頃からあった

stream ← #(1 2 3) asStream.
for x to stream do [user show: x; cr]

という内部イテレータとして使える外部イテレータである
ストリームという発案が

> C++/Java だけでなくC言語でも実装できる
> 一般的なプログラミング技法

とか

> 保守のしづらいコードになりがち

というよくわからない難癖で排除される理由も理解しかねます。
てっきり、コルーチンでないからダメなのかと思ったのですが？

813 ：デフォルトの名無しさん：2014/12/09(火) 00:34:52.29 ID:7jn1Y2FE.net

>>809
つまり Ruby が CLU のイテレータを再発見するまで、いいかえると
Python 設計者は PEP 205(>>765) 発表の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 (>>765)では yield はブロックの評価結果を返す式として定義されている
しかも外部イテレータは 1.8 で標準ライブラリとして、 1.9 では組み込みライブラリとして提供された
もちろん(後方互換性を喪失させた Python とは異なり)言語の構文仕様へ変更を加えることなく....

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

814 ：デフォルトの名無しさん：2014/12/09(火) 01:30:40.08 ID:5nnX6sRe.net

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

815 ：デフォルトの名無しさん：2014/12/09(火) 02:00:48.32 ID:WiqIx9bM.net

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

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

816 ：デフォルトの名無しさん：2014/12/09(火) 09:46:11.30 ID:RdsPil5f.net

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

817 ：デフォルトの名無しさん：2014/12/09(火) 16:22:39.15 ID:j4N/cP02.net

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

818 ：デフォルトの名無しさん：2014/12/09(火) 17:46:01.03 ID:64I0Ciqv.net

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

819 ：デフォルトの名無しさん：2014/12/09(火) 21:39:51.00 ID:7jn1Y2FE.net

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

ないです
当時のコルーチンは(アセンブリ言語レベルで)システムスタックを操作するか、
あるいは処理を「ぶつ切り」にした(保守しづらい)コルーチン風のプログラミングで実装するしかなかった
だからコルーチンの用途は限定され、ループ処理は 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 (>>801)と似ていますね
（CLU におけるイテレータの列挙は for .. in 構文に限定された仕様でしたが、これは -76 の影響？？？）
この for は Smalltalk-76 の予約語に見えますが、(特殊な)メッセージだったのでしょうか？
また Smalltalk-80 だと do メッセージへ変更されていますけど、何か理由があったのでしょうか？
そして -76 の stream も next メッセージが実装された(外部イテレータとして)のオブジェクトだったのでしょうか？

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

820 ：デフォルトの名無しさん：2014/12/09(火) 23:30:56.22 ID:4fop6YGQ.net

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

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

821 ：デフォルトの名無しさん：2014/12/10(水) 07:35:20.61 ID:8efWXp1v.net

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

822 ：デフォルトの名無しさん：2014/12/10(水) 10:47:06.06 ID:UPnzY5Pb.net

>>819
> これは -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 からだと思います。

823 ：デフォルトの名無しさん：2014/12/10(水) 21:59:38.00 ID:veDvxwge.net

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

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

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


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

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


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

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


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

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

824 ：デフォルトの名無しさん：2014/12/11(木) 11:19:57.50 ID:QX1K4VF2.net

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

825 ：デフォルトの名無しさん：2014/12/11(木) 13:25:53.28 ID:QX1K4VF2.net

>>824
まあ、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 "

826 ：名無しさん＠そうだ選挙に行こう：2014/12/14(日) 08:35:34.66 ID:Im2X3v/S.net

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

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

827 ：デフォルトの名無しさん：2016/05/01(日) 15:12:30.55 ID:tKi6j9CT.net

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

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

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

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


The Covenant Project
概要

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

目的

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

特徴

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

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

828 ：デフォルトの名無しさん：2018/05/23(水) 23:07:44.26 ID:Au5e7VGg.net

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

QZU97

829 ：デフォルトの名無しさん：2018/07/04(水) 23:01:31.67 ID:gFgZc5FG.net

DHB

830 ：デフォルトの名無しさん：2018/07/06(金) 12:36:26.96 ID:uTPDH9XV.net

QZU97

831 ：デフォルトの名無しさん：2018/08/23(木) 06:16:30.33 ID:NPcuqlt3.net

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

832 ：デフォルトの名無しさん：2019/06/19(水) 05:02:52.19 ID:tVNS+22r.net

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