探検
動的言語で大規模開発
■ このスレッドは過去ログ倉庫に格納されています
1uy
2012/07/24(火) 09:10:42.04 たててみた
2uy
2012/07/24(火) 09:14:05.25 問題は解決した
結局、実行時にしか実行結果が分からないとしても
「信頼できるコード」は徐々に増えていく
それは予想以上に上手くいき始めた
俺は二度と静的言語を使う事はないだろう
結局、実行時にしか実行結果が分からないとしても
「信頼できるコード」は徐々に増えていく
それは予想以上に上手くいき始めた
俺は二度と静的言語を使う事はないだろう
2012/07/24(火) 09:15:00.16
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
4デフォルトの名無しさん
2012/07/24(火) 10:57:46.72 そのコピペ飽きた
2012/07/24(火) 11:54:29.79
イジメ自殺が社会問題となっている。新聞でもテレビでも識者と称する恥知らずたちが、おためごかしの助言を垂れ流して小銭を稼いでいる。
イジメに苦しむ少年少女よ、あんなものが何の役にも立たないことは、君たち自身が一番良く知っている。
唯一最良のイジメ対処法は報復に決まっているではないか。
実はイジメ自殺は何年かごとに社会問題となり、そのたびに真実の声が良識という名の愚論によって圧殺されてきたのだ。
十一年前にもイジメ自殺が相次ぎ「少年ジャンプ」が悲痛な叫びを特集連載した。
それをまとめた『いじめレポート』(集英社)にこんな声がある。
「徹底的に体を鍛えた。復讐(ふくしゅう)のために…。やられる前にやれ!」(A男)。
A君は拳法、柔道で「歩く凶器」となり、イジメを粉砕した。
睡眠薬自殺未遂のC子さんは、死を思う気持ちよりも「憎しみの方が強くなった」「私もガンガン殴り返す」「女でもやるときはやるんだ!」。
別の女児もこう言う。「どうしても死ぬっていうんなら、いじめた奴に復讐してからにしなよ」
学校では報復・復讐は道徳的な悪だと教える。しかし、それは嘘だ。人間が本来的に持っている復讐権を近代国家が独占したに過ぎない。
大学で法制史を学べばすぐわかる。復讐は道徳的には正しいのだ。現に、ロシヤに抑圧され続けたチェチェン人は果敢に復讐をしているではないか。
被害者が自ら死を選ぶなんてバカなことがあるか。死ぬべきは加害者の方だ。いじめられている諸君、自殺するぐらいなら復讐せよ。
死刑にはならないぞ。少年法が君たちを守ってくれるから。
呉智英
イジメに苦しむ少年少女よ、あんなものが何の役にも立たないことは、君たち自身が一番良く知っている。
唯一最良のイジメ対処法は報復に決まっているではないか。
実はイジメ自殺は何年かごとに社会問題となり、そのたびに真実の声が良識という名の愚論によって圧殺されてきたのだ。
十一年前にもイジメ自殺が相次ぎ「少年ジャンプ」が悲痛な叫びを特集連載した。
それをまとめた『いじめレポート』(集英社)にこんな声がある。
「徹底的に体を鍛えた。復讐(ふくしゅう)のために…。やられる前にやれ!」(A男)。
A君は拳法、柔道で「歩く凶器」となり、イジメを粉砕した。
睡眠薬自殺未遂のC子さんは、死を思う気持ちよりも「憎しみの方が強くなった」「私もガンガン殴り返す」「女でもやるときはやるんだ!」。
別の女児もこう言う。「どうしても死ぬっていうんなら、いじめた奴に復讐してからにしなよ」
学校では報復・復讐は道徳的な悪だと教える。しかし、それは嘘だ。人間が本来的に持っている復讐権を近代国家が独占したに過ぎない。
大学で法制史を学べばすぐわかる。復讐は道徳的には正しいのだ。現に、ロシヤに抑圧され続けたチェチェン人は果敢に復讐をしているではないか。
被害者が自ら死を選ぶなんてバカなことがあるか。死ぬべきは加害者の方だ。いじめられている諸君、自殺するぐらいなら復讐せよ。
死刑にはならないぞ。少年法が君たちを守ってくれるから。
呉智英
6デフォルトの名無しさん
2012/07/24(火) 18:55:17.05 動的言語で大規模開発は可能
以上
以上
2012/07/24(火) 20:04:33.83
【スポーツ】「五輪期間中はブログをやめて」JOCが東原亜希さんに要請★2
http://ikura.2ch.net/test/read.cgi/curry/1246361020/
http://ikura.2ch.net/test/read.cgi/curry/1246361020/
2012/07/24(火) 20:07:03.66
あるのなら例をあげろよ。
俺が見たのはPython & Djangoで書いた社内用メーリングリストサーバ。
Webアプリで利用者がML管理。全部で1万行くらいあった。
納入業者が作ったみたい。
俺が見たのはPython & Djangoで書いた社内用メーリングリストサーバ。
Webアプリで利用者がML管理。全部で1万行くらいあった。
納入業者が作ったみたい。
9デフォルトの名無しさん
2012/07/24(火) 22:26:26.07 いくらでもあるのに見つけられないってバカなのか
10デフォルトの名無しさん
2012/07/24(火) 22:59:20.68 1万って大規模じゃないだおr
2012/07/24(火) 23:00:34.94
もっと絞らんと、obj-cなんかも入ってきて切りがないでしょうに
2012/07/24(火) 23:18:45.95
ばーか
2012/07/24(火) 23:20:31.92
大規模開発は何を意味してるのかな
コード量かな
人数かな
人数多いとダメじゃないかな
コード量かな
人数かな
人数多いとダメじゃないかな
2012/07/24(火) 23:37:16.89
人数多いのはクソプロジェクトしかないから却下。
2012/07/24(火) 23:43:45.63
win8はいつのまにか不可解なメトロを組み込むことになってしまった
動的言語じゃなくても大規模開発は難しい
動的言語じゃなくても大規模開発は難しい
2012/07/25(水) 00:57:09.50
死ね
2012/07/25(水) 01:21:12.37
1万行って去年俺一人で趣味で書いた JavaScript の量じゃねえか。
もう二度とやらんと誓ったけど。
動的言語は砂上に楼閣建ててる感がヤバイわ。GWT なり Haxe なり使えよ。
もう二度とやらんと誓ったけど。
動的言語は砂上に楼閣建ててる感がヤバイわ。GWT なり Haxe なり使えよ。
2012/07/25(水) 01:25:38.55
Browser Quest を見たパンピーどもの反応
→HTML5 スゲー!!JavaScript スゲー!! マンセーマンセーマンセー!
ソースコードまできちんと読んだ俺の反応
→これを全世界のプログラマにやれというのか(怒怒怒怒怒怒怒怒怒怒怒
今すぐ滅べよ JavaScript(激怒
→HTML5 スゲー!!JavaScript スゲー!! マンセーマンセーマンセー!
ソースコードまできちんと読んだ俺の反応
→これを全世界のプログラマにやれというのか(怒怒怒怒怒怒怒怒怒怒怒
今すぐ滅べよ JavaScript(激怒
19uy
2012/07/25(水) 02:43:50.85 「信頼できるコード」は徐々に増えていく
一見そう思えたが、修正しようとした時に問題が起き始めた。
影響範囲がわからない。
テストコードがあるから、実行すればおかしくなったのはわかるのだが、
それを正しくするには、どこを修正すればいいかがわからない。
時間がかかってしまう。
そしてテストコードは動いたが、今度はこれで本当に問題ないか
不安になってきた。
テストは不具合があることは教えてくれるが、
不具合がないことは教えてくれない。
果たして俺は、完璧なテストを書いているのだろうか?
一見そう思えたが、修正しようとした時に問題が起き始めた。
影響範囲がわからない。
テストコードがあるから、実行すればおかしくなったのはわかるのだが、
それを正しくするには、どこを修正すればいいかがわからない。
時間がかかってしまう。
そしてテストコードは動いたが、今度はこれで本当に問題ないか
不安になってきた。
テストは不具合があることは教えてくれるが、
不具合がないことは教えてくれない。
果たして俺は、完璧なテストを書いているのだろうか?
20uy
2012/07/25(水) 02:55:10.25 コードはインターフェースと実装の2つにわかれるんだよ。
実装の修正ってのはテストが簡単。
インターフェースが変わらないから、
実装は関数の中身を変えればいいだけ。
テストコードを変える必要はない。
だけど、インターフェースの修正ってのは、
関数の外側、呼び出し側を修正する必要があるから
影響範囲が広くなる。そしてテストコードまでも変更する必要がある。
インターフェースの修正に弱いのが
動的型付け言語なわけ。
実装の修正ってのはテストが簡単。
インターフェースが変わらないから、
実装は関数の中身を変えればいいだけ。
テストコードを変える必要はない。
だけど、インターフェースの修正ってのは、
関数の外側、呼び出し側を修正する必要があるから
影響範囲が広くなる。そしてテストコードまでも変更する必要がある。
インターフェースの修正に弱いのが
動的型付け言語なわけ。
21uy
2012/07/25(水) 03:36:50.022012/07/25(水) 03:44:41.83
uy以外の人に聞きたいが
「動的言語で書かれているヘッダ」ってなんのこと?
「動的言語で書かれているヘッダ」ってなんのこと?
2012/07/25(水) 03:45:34.43
1万行って少ないな。
1000行が10ファイルしか無い。
1000行が10ファイルしか無い。
2012/07/25(水) 06:55:17.49
LISPマシンやPrologマシンはどのくらいの規模だった?
2012/07/25(水) 08:11:19.64
2012/07/25(水) 08:13:27.92
で、基本的に「自分以外」がかいたそういうヘッダってのは
「信頼できるコード」に含まれる
世界中で何百万人が使用しているものだから
結局は自分でそのレベルの安定性を持った水準の動的言語コードをかいて
「アルゴリズムライブラリ」とすれば「信頼出来るコード」は増えていく
以上
「信頼できるコード」に含まれる
世界中で何百万人が使用しているものだから
結局は自分でそのレベルの安定性を持った水準の動的言語コードをかいて
「アルゴリズムライブラリ」とすれば「信頼出来るコード」は増えていく
以上
2012/07/25(水) 08:41:50.10
2012/07/25(水) 11:41:35.75
#include<stdio.h>知らないただのバカか
2012/07/25(水) 12:01:51.61
世の中にはヘッダライブラリというのも存在する事も知らないただのバカか
バカは死ね
バカは死ね
2012/07/25(水) 12:02:27.66
動的リンクをしてない言語はライブラリをどのようにして使うかすら知らないバカか
バカは死ね
バカは死ね
2012/07/25(水) 12:03:42.01
初心者とバカは死ね
2012/07/25(水) 12:07:26.36
今時の言語でヘッダをインクルードする言語なんて皆無だろ。
2012/07/25(水) 12:18:05.17
rubyやってると本当に変数あんまり使わなくなってくる
イテレータ内のみにスコープのある局所変数の型については、
100%型情報がいらない場所、型情報があるとイテレータの利点が全く生かせない
俺でも稀に型情報が必要かな?って思うのはグローバル変数や、スコープの広い変数
でもrubyではその気になればスコープの広い変数を消して、ブロック変数のみで書いていける
重要なのは変数情報じゃなくて、
メソッド群の組み合わせによって、どうアルゴリズムを作るか
よくイテレータの戻り値を、とりあえずって感じで
a=[...].map {} といった具合に受け取ることはあるが、これさえも
[...].map {}
.map {
}
と続けてかいてしまえば変数がいらない
まぁ可読性のために、変数に格納するんだけど
変数を宣言して使うしかないっていう状況から、
書かなくてもよい変数を、可読性を上げる為にわざと宣言するという考えに変わっていった
イテレータ内のみにスコープのある局所変数の型については、
100%型情報がいらない場所、型情報があるとイテレータの利点が全く生かせない
俺でも稀に型情報が必要かな?って思うのはグローバル変数や、スコープの広い変数
でもrubyではその気になればスコープの広い変数を消して、ブロック変数のみで書いていける
重要なのは変数情報じゃなくて、
メソッド群の組み合わせによって、どうアルゴリズムを作るか
よくイテレータの戻り値を、とりあえずって感じで
a=[...].map {} といった具合に受け取ることはあるが、これさえも
[...].map {}
.map {
}
と続けてかいてしまえば変数がいらない
まぁ可読性のために、変数に格納するんだけど
変数を宣言して使うしかないっていう状況から、
書かなくてもよい変数を、可読性を上げる為にわざと宣言するという考えに変わっていった
2012/07/25(水) 18:00:32.03
2012/07/25(水) 21:59:50.81
2012/07/25(水) 22:02:16.10
動的言語はインターフェースの変更に弱い。
インターフェースの変更は単体テストで
見つけることが困難になる場合がある。
インターフェースの変更は単体テストで
見つけることが困難になる場合がある。
37uy
2012/07/25(水) 23:41:23.25 バカすぎワロタ
stdio.hでも食ってろ
stdio.hでも食ってろ
2012/07/25(水) 23:46:37.20
stdio.h ・・・C言語(静的型付け言語)のヘッダファイルです。これはライブラリではありません。
39uy
2012/07/26(木) 00:16:15.80 バカすぎワロタ
stdio.hでも食ってろ
stdio.hでも食ってろ
2012/07/26(木) 00:16:45.42
uy以外の人に聞きたいが
「動的言語で書かれているヘッダ」ってなんのこと?
「動的言語で書かれているヘッダ」ってなんのこと?
2012/07/26(木) 00:17:53.75
初心者スレいけよ低脳
42uy
2012/07/26(木) 00:20:16.84 バカすぎワロタ
stdio.hでも食ってろ
stdio.hでも食ってろ
43uy
2012/07/26(木) 00:24:29.43 初心者黙った
そのままstdio.hと添い寝してろ
初心者死ね
そのままstdio.hと添い寝してろ
初心者死ね
44uy
2012/07/26(木) 00:31:36.95初心者死ね
2012/07/26(木) 00:34:22.77
uy以外誰も答えられないってのが
答えになってる。
そう、「動的言語で書かれているヘッダ」なんてものは
存在しない。
答えになってる。
そう、「動的言語で書かれているヘッダ」なんてものは
存在しない。
2012/07/26(木) 08:57:34.99
そもそもヘッダってものがごくごく一部の言語にしかないので。
47uy
2012/07/26(木) 10:04:04.91 あ、言っとくけど誰もマジレスしなくていいからね
長文書かれると鬱陶しい
こいつはこのまま放置していこう
長文書かれると鬱陶しい
こいつはこのまま放置していこう
48uy
2012/07/26(木) 10:10:59.41 動的言語でプログラムを組むときに普通はいくつもの「ヘッダ」を使い
その「ヘッダ」は、大抵は同じ言語、つまり「動的言語でヘッダ」が書かれている
自分で実際に書いたソースコードと、その「ヘッダ」のソースコードを含めて考えれば
ちょっとしたコードだろうとそれなりの規模のコードになっている事は分かる
大規模開発が出来ないというのは、「信頼出来るコード」、「資産」を自分で作っていけないレベルの奴が言っているだったという結論がでてしまった
その「ヘッダ」は、大抵は同じ言語、つまり「動的言語でヘッダ」が書かれている
自分で実際に書いたソースコードと、その「ヘッダ」のソースコードを含めて考えれば
ちょっとしたコードだろうとそれなりの規模のコードになっている事は分かる
大規模開発が出来ないというのは、「信頼出来るコード」、「資産」を自分で作っていけないレベルの奴が言っているだったという結論がでてしまった
49uy
2012/07/26(木) 10:14:59.12 「動的言語で書かれたヘッダ」をひとつも使ったことがないというのは
動的言語でプログラムを書くときに標準や外部ライブラリも含めて何一つ使ったことがないという事・・・
自分でヘッダを描く事も出来ず、
インクルード(あ、言っちゃった)構文さえ知らない
そろそろ謝ったほうがいいんじゃないのか
動的言語でプログラムを書くときに標準や外部ライブラリも含めて何一つ使ったことがないという事・・・
自分でヘッダを描く事も出来ず、
インクルード(あ、言っちゃった)構文さえ知らない
そろそろ謝ったほうがいいんじゃないのか
50uy
2012/07/26(木) 10:31:38.47 初心者は死すべし
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
何 番 煎 じ だ ?
こんな釣りスレに釣られてレスしにきちゃう分際でどうなんだそれwwwwwwwwww
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
何 番 煎 じ だ ?
こんな釣りスレに釣られてレスしにきちゃう分際でどうなんだそれwwwwwwwwww
2012/07/26(木) 11:24:08.18
うん、だからもう 2ch なんて捨ててヨソに行ってよ。
ね。
もう十分に恥ずかしい思いをしたでしょ?
ね。
もう十分に恥ずかしい思いをしたでしょ?
2012/07/26(木) 11:58:59.94
import java.util.List;
これをヘッダのインクルードだと理解しているわけか?すごいな
これをヘッダのインクルードだと理解しているわけか?すごいな
53uy
2012/07/26(木) 12:44:30.56 やっぱりjaverか・・・
54uy
2012/07/26(木) 13:09:01.25 俺は勘違いしてたかもな
静的言語よりも自由が高く出来る事の多い動的言語で大規模開発が出来ないはずないわ
慣れは必要
どんどん効率上がってきてるのが分かる
静的言語よりも自由が高く出来る事の多い動的言語で大規模開発が出来ないはずないわ
慣れは必要
どんどん効率上がってきてるのが分かる
2012/07/26(木) 14:42:51.05
50 :uy:2012/07/26(木) 10:31:38.47
初心者は死すべし
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
何 番 煎 じ だ ?
こんな釣りスレに釣られてレスしにきちゃう分際でどうなんだそれwwwwwwwwww
2012/07/26(木) 15:56:44.73
50 :uy:2012/07/26(木) 10:31:38.47
初心者は死すべし
で、こういう初心者を追い詰めて論破していくと
また色んなスレでuyに粘着やら成りすまして書き込んで荒らし始める
何 番 煎 じ だ ?
こんな釣りスレに釣られてレスしにきちゃう分際でどうなんだそれwwwwwwwwww
57uy
2012/07/26(木) 19:29:02.43 >>53
> import java.util.List;
>
> これをヘッダのインクルードだと理解しているわけか?すごいな
Rubyではincludeで読み込むファイルのことを
ヘッダファイルっていうんだよ。
知らないなら、ググって恥をかけ!
> import java.util.List;
>
> これをヘッダのインクルードだと理解しているわけか?すごいな
Rubyではincludeで読み込むファイルのことを
ヘッダファイルっていうんだよ。
知らないなら、ググって恥をかけ!
58uy
2012/07/26(木) 19:30:25.70 > 21 名前:uy[sage] 投稿日:2012/07/25(水) 03:36:50.02
>
> >>17
> 冷静に考えてみ
> その1万行をかくときに
> 「動的言語で書かれているヘッダ」をいくつ使った?
これを読んで疑問になった人は多いと思う。
あえてuy以外の人に聞くが、
「動的言語で書かれているヘッダ」ってなんのこと?
>
> >>17
> 冷静に考えてみ
> その1万行をかくときに
> 「動的言語で書かれているヘッダ」をいくつ使った?
これを読んで疑問になった人は多いと思う。
あえてuy以外の人に聞くが、
「動的言語で書かれているヘッダ」ってなんのこと?
2012/07/26(木) 22:24:58.39
60uy
2012/07/27(金) 01:31:01.18 rubyでincludeワロタ
ruby使えないどころかrubyのソース1個も読んでない知ったかじゃねーか
ruby使えないどころかrubyのソース1個も読んでない知ったかじゃねーか
61uy
2012/07/27(金) 01:41:01.10 結局ヘッダーっていうのは
ファイルの先頭に書かれている情報であって
「ヘッダ」と「ヘッダーファイル(.h)」は別物
requireやimportされているファイルは「ヘッダ」または「ヘッダライブラリ」と呼ぶ
C++/Boostのhppなども「ヘッダライブラリ」に分類される
またそれとは別に動的言語でDLLを使う場合には、C言語と同じようにプロトタイプ宣言の「ヘッダ」を書く事もある
またそれは別に、中規模以上であればファイルの先頭には定数情報やら、クラス、モジュールの空宣言などをやっておく事もあるんで
これらも「ヘッダ」と呼ぶ
分かったか?ゴミ
ファイルの先頭に書かれている情報であって
「ヘッダ」と「ヘッダーファイル(.h)」は別物
requireやimportされているファイルは「ヘッダ」または「ヘッダライブラリ」と呼ぶ
C++/Boostのhppなども「ヘッダライブラリ」に分類される
またそれとは別に動的言語でDLLを使う場合には、C言語と同じようにプロトタイプ宣言の「ヘッダ」を書く事もある
またそれは別に、中規模以上であればファイルの先頭には定数情報やら、クラス、モジュールの空宣言などをやっておく事もあるんで
これらも「ヘッダ」と呼ぶ
分かったか?ゴミ
2012/07/27(金) 03:22:37.53
2012/07/27(金) 05:04:28.09
ッ「ペロバコナーンwwwwwwwwwwwwwwww」
2012/07/27(金) 06:27:14.26
>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
恥の上塗り。
笑いものになることに快感を覚えているのではなかろうか。
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
恥の上塗り。
笑いものになることに快感を覚えているのではなかろうか。
66uy
2012/07/27(金) 08:14:28.8468uy
2012/07/27(金) 19:38:30.34 rubyのincludeは今の話しと違うだろ・・・
るりまサーチをGoogleと勘違いしている頭の悪さ
コイツは救えない
stdio.hでも食ってろカス
るりまサーチをGoogleと勘違いしている頭の悪さ
コイツは救えない
stdio.hでも食ってろカス
69uy
2012/07/28(土) 08:07:31.39 さっさと謝れ
2012/07/28(土) 11:02:45.57
>>68
いやw
include 対象が「ヘッダ」だと書いたページをw
一個でもいいから探して来いよw
>57 の
> Rubyではincludeで読み込むファイルのことを
> ヘッダファイルっていうんだよ。
の話さあw
いやw
include 対象が「ヘッダ」だと書いたページをw
一個でもいいから探して来いよw
>57 の
> Rubyではincludeで読み込むファイルのことを
> ヘッダファイルっていうんだよ。
の話さあw
2012/07/28(土) 12:53:20.49
2012/07/28(土) 15:23:50.83
ファイルの始めに書かかれている、ライセンスや開発者名なんかはヘッダーと言えるような気もする。
73uy
2012/07/28(土) 19:16:03.9074uy
2012/07/28(土) 19:20:53.36 C言語では「.h」のヘッダーでインクルードしてdefineなど定数宣言したり
クラス、構造体の宣言だけを行うこともある
rubyファイルでそれと同じことを行うこともある
動的、静的は関係なく
ヘッダーというのは存在する
動的言語で大規模開発は可能
分かったかゴミ?
さっさと初心者は死ね
クラス、構造体の宣言だけを行うこともある
rubyファイルでそれと同じことを行うこともある
動的、静的は関係なく
ヘッダーというのは存在する
動的言語で大規模開発は可能
分かったかゴミ?
さっさと初心者は死ね
75uy
2012/07/28(土) 19:23:05.622012/07/28(土) 19:24:08.49
初心者死ね
2012/07/28(土) 19:37:11.07
>>73
pgr
pgr
2012/07/28(土) 19:38:43.08
79uy
2012/07/28(土) 19:50:30.14 ドヤ顔で500年以上前に流行っていまはもう使われてないC言語っていうんだっけそれ
そんなもののソース出されても正直困る
歴史に埋もれて市ね
そんなもののソース出されても正直困る
歴史に埋もれて市ね
80uy
2012/07/28(土) 20:01:44.24 テキストファイルの上の部分がヘッダとか
見苦しい言い訳をしているが、
それだと
> その1万行をかくときに
> 「動的言語で書かれているヘッダ」をいくつ使った?
つじつまがあわない。
ヘッダを使うとはどういうことか。
見苦しい言い訳をしているが、
それだと
> その1万行をかくときに
> 「動的言語で書かれているヘッダ」をいくつ使った?
つじつまがあわない。
ヘッダを使うとはどういうことか。
2012/07/28(土) 21:11:15.85
ゴミは死ね
2012/07/29(日) 00:41:12.87
ゴミグラマ死ね
2012/07/29(日) 01:23:55.92
死ねゴミ
2012/07/29(日) 02:26:34.65
ゴミ
2012/07/29(日) 12:16:42.75
Matz はどういうだろうね?
2012/07/29(日) 12:57:02.43
cに対する煽りが半端でつまらんな
もっとくやしく
もっとくやしく
2012/07/29(日) 17:38:17.52
動的言語における大規模開発の適性については、すでに1980年代に結論が出ている
以下は、XEROXがSmalltalk-80で開発した大規模アプリケーションの具体例
(出典: Information/April 1986)
EELS - 紙面編集システム
・EELS(Electronic Editing and Layout System)は、ニューヨークタイムス社との
契約によりXSIS(Xerox Special Information Syatems)が開発した
新聞の編集とデザインのためのシステムであり、新聞の紙面向けの
この種のシステムとしては世界初。このシステムは、紙面の編集や表示を
1100SIPワークステーション上で行う事を可能にした。
・前工程で組まれた活字を自動的に読み込み、編集規則に合わせて再構成したり
会話形式でテキストを修正できる。さらに記事がレイアウトにフィットしない
場合には、レイアウト自体も動的に調整できる。また、活字を組むための
テキスト用のページや、各種の字体も用意されている。
ANALYST - 分析シミュレーションシステム
・ANALYSTは米国政府で行われている広範囲な情報分析向けにXSISが開発した
システムであり、すべてがSmalltak-80で実装され1983年秋から稼働している。
・ANALYSTはグラフ、地図情報、イメージ情報(航空写真など)、テキスト、
数値演算(スプレッドシートなど)といった各種の情報処理機能を包含しており、
ワークステーションの中に分析者が必要とするすべての情報処理機能を
備えているといえる。また、電子メール機能、イメージ処理機能、電子ファイル
管理機能、IBMのような大型機へのアクセス機能などの特徴も備えている。
以下は、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のような大型機へのアクセス機能などの特徴も備えている。
88uy
2012/07/29(日) 18:11:52.22 今は1980年ではない。
それ以降に静的型付け言語が成熟した。
今は動的型付け言語のメリットはない。
それ以降に静的型付け言語が成熟した。
今は動的型付け言語のメリットはない。
2012/07/29(日) 19:03:44.51
Smalltalkは当時からすでに下手な静的型言語より手厚いIDEのサポートがデフォだから
動的言語の適性を示す例としては反則だろう。
動的言語の適性を示す例としては反則だろう。
90uy
2012/07/29(日) 19:04:48.12 Smalltalkって今どうなったんだ?
2012/07/29(日) 20:19:48.62
本家XEROX Smalltalk-80の直系の子孫はCincom社が開発販売しているVisualWorks。
http://smalltalk.cincom.jp/main/successes/
開発途上版(Smalltalk-80 v1)から枝分かれして独自進化したのがSqueak。
http://www.squeak.org/
さらにSqueakから枝分かれしたのがPharo。
http://www.pharo-project.org/
あとは企業の古くかあるクローンとか
http://www.exept.de/en/products/smalltalkx
http://www.object-arts.com/
http://www.instantiations.com/products/vasmalltalk/
他にはファンお手製実装とかの変わり種などいろいろ。
http://smalltalk.gnu.org/
http://amber-lang.net/
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/
2012/07/29(日) 20:49:29.32
変わり種と言えば、処理系まるごとOODBシステムと化したGemStone/Sというのもある。
http://www.gemstone.com/products/gemstone
MaglevというSmalltalkベースの高速なRuby実装にはこの処理系が使われている。
http://maglev.github.com/
http://www.gemstone.com/products/gemstone
MaglevというSmalltalkベースの高速なRuby実装にはこの処理系が使われている。
http://maglev.github.com/
2012/07/29(日) 21:01:18.67
94uy
2012/07/29(日) 21:08:13.04 Smalltalkってウェブ関連では使われてないな。
2012/07/29(日) 21:22:37.41
OO機構が組み込まれているコンパイル志向の言語で、型の弱い言語ってあるかい?
2012/07/29(日) 21:30:00.55
>>94
あまりね。
でもTwitterに買われてサービスやめちゃったけどDabbleDBとか有名どころもちらほら。
http://www.crunchbase.com/company/dabbledb
Rubyを窮屈に感じてSmalltalkに鞍替えした人がWebObjectsにインスパイアされて作った
SeasideというコンポーネントベースのWAフレームワークが人気で
いろんな処理系に移植されて比較的よく使われている。
http://www.ogis-ri.co.jp/otc/hiroba/technical/seaside/seaside2/index.html
http://smalltalk.cincom.jp/tutorials/vw7.6/seaside/seaside_intro.ssp
http://www.seaside.st/
あまりね。
でも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/
2012/07/29(日) 21:58:33.83
>>93
> コンパイル時に強い型付けもしてるからな。
> 静的型付けもうまく組み合わせて使える。
ん? ちょっとイメージできない。具体的にはどういうこと?
関係あるか分からないけど、SmalltalkにもObjective-Cみたいにオプショナルな
型チェック機構を持ったStrongtalkという処理系がある(あった)。これも変わり種だね。
http://www.strongtalk.org/
余談だけど型チェック機構とは別に、こいつのVM高速化技術はエポックメーキングで
会社ごとSunが買い取ってJavaに応用して作られたのがHotSpot VM。Sunの厚意で
オープンソース化後、JavaScriptで使われて作られたのがNode.jsを支えるV8のエンジン。
> コンパイル時に強い型付けもしてるからな。
> 静的型付けもうまく組み合わせて使える。
ん? ちょっとイメージできない。具体的にはどういうこと?
関係あるか分からないけど、SmalltalkにもObjective-Cみたいにオプショナルな
型チェック機構を持ったStrongtalkという処理系がある(あった)。これも変わり種だね。
http://www.strongtalk.org/
余談だけど型チェック機構とは別に、こいつのVM高速化技術はエポックメーキングで
会社ごとSunが買い取ってJavaに応用して作られたのがHotSpot VM。Sunの厚意で
オープンソース化後、JavaScriptで使われて作られたのがNode.jsを支えるV8のエンジン。
98uy
2012/07/29(日) 23:19:47.1799uy
2012/07/29(日) 23:31:19.65 実際のところいまのrubyは名前衝突を判定する手段がないから
フリーライブラリをrequireするなら、その中身を全部知っていないと危険
requireやりまくらないとしても、設計を完璧にして、ゴミカスPGはプロジェクト内から排除した上で
開発しなければならない
ただ、そこら辺の評価をマイナスにしてみてもrubyは現時点では最高の言語
大規模開発も出来る
ほかの言語がどれだけレベルが低いことか
使いこなすには難があるんだよ
たとえばC言語であればループかくって時に
基本的にイテレータなど使わないからfor文しか選択肢はないし、
処理分けをしたいって時なども、大抵はswitch case文でやるしかない
rubyの場合は、クロージャ、ラムダ、メソッド、module特異メソッド、class特異メソッド、case、when、イテレータ
さらに、独自定義のイテレータだの、eval使ってのメタだの
このくらいは選択肢がある
選択肢が多いことはいい事だ
ただしそれは使いこなせればの話
ドカタには無理
フリーライブラリをrequireするなら、その中身を全部知っていないと危険
requireやりまくらないとしても、設計を完璧にして、ゴミカスPGはプロジェクト内から排除した上で
開発しなければならない
ただ、そこら辺の評価をマイナスにしてみてもrubyは現時点では最高の言語
大規模開発も出来る
ほかの言語がどれだけレベルが低いことか
使いこなすには難があるんだよ
たとえばC言語であればループかくって時に
基本的にイテレータなど使わないからfor文しか選択肢はないし、
処理分けをしたいって時なども、大抵はswitch case文でやるしかない
rubyの場合は、クロージャ、ラムダ、メソッド、module特異メソッド、class特異メソッド、case、when、イテレータ
さらに、独自定義のイテレータだの、eval使ってのメタだの
このくらいは選択肢がある
選択肢が多いことはいい事だ
ただしそれは使いこなせればの話
ドカタには無理
100uy
2012/07/29(日) 23:33:18.42 ruby言語以外にもrubyと同じ機能はあったりするが、
結局それをいうならC++が最強
でも結局、言語の機能が整理されて使いやすくなってなければ
機能があってもないのと同じ
つ か え な い ん だ よ
そこにあってもな
rubyの場合は、言語の機能をひとつ残らず 使 え る よ う に 設計されてる
そこのあたり、「とりあえず実装してみた。」みたいなノリの言語とは違うと思う
情報の整理がちゃんとされてるrubyが最強
結局それをいうならC++が最強
でも結局、言語の機能が整理されて使いやすくなってなければ
機能があってもないのと同じ
つ か え な い ん だ よ
そこにあってもな
rubyの場合は、言語の機能をひとつ残らず 使 え る よ う に 設計されてる
そこのあたり、「とりあえず実装してみた。」みたいなノリの言語とは違うと思う
情報の整理がちゃんとされてるrubyが最強
101デフォルトの名無しさん
2012/07/29(日) 23:37:48.53 Rubyはせいぜい10万行が限界。
50万行越えのコードは組めたとしてもメンテなんかぜったい無理。
だいたいコード以前に20万行のテキストすらまともに扱えないんだから。
50万行越えのコードは組めたとしてもメンテなんかぜったい無理。
だいたいコード以前に20万行のテキストすらまともに扱えないんだから。
102uy
2012/07/29(日) 23:55:49.89 まともな設計するなら数万行単位で、なんらかの敷居を作れよバカ
なんで1個のプロジェクトに数十万行とか詰め込みたがるわけ、バカなの死ぬの
ちなみにまともにrubyでかいてればJAVAの5分1やら10分1程度のソースコード量になってもおかしくないわけで
rubyで10万行っていうとJAVAで50〜100万行の規模と考えていいよ
なんで1個のプロジェクトに数十万行とか詰め込みたがるわけ、バカなの死ぬの
ちなみにまともにrubyでかいてればJAVAの5分1やら10分1程度のソースコード量になってもおかしくないわけで
rubyで10万行っていうとJAVAで50〜100万行の規模と考えていいよ
103uy
2012/07/29(日) 23:59:56.90 そもそも10万行超えたらダメになるような設計しかかけない分際でレスされても困るよなぁ・・・
失敗談でも語っていくか?
君はどこで躓いちゃったの?
どこで間違えたの?
初心者は死ね
失敗談でも語っていくか?
君はどこで躓いちゃったの?
どこで間違えたの?
初心者は死ね
104デフォルトの名無しさん
2012/07/30(月) 00:06:53.12 rails10万行程度ですでにカオス状態の食べログェ…
http://d.hatena.ne.jp/kanz-labs/20110811/1313079667
http://d.hatena.ne.jp/kanz-labs/20110811/1313079667
105デフォルトの名無しさん
2012/07/30(月) 01:03:40.99 じゃあ俺は20万行かくよ
そもそも大規模になったからって管理できませーんなんて白旗あげちゃう奴は
何の言語触ったってダメじゃねえの????
他人が綺麗に設計した大規設計の上でドカタコードしか書かない奴には、ちょっと関係の話だったりする
そもそも大規模になったからって管理できませーんなんて白旗あげちゃう奴は
何の言語触ったってダメじゃねえの????
他人が綺麗に設計した大規設計の上でドカタコードしか書かない奴には、ちょっと関係の話だったりする
106デフォルトの名無しさん
2012/07/30(月) 01:04:37.66 >ちょっと関係の話だったりする
関係のない話
関係のない話
107デフォルトの名無しさん
2012/07/30(月) 01:12:40.95 よく知ってるRailsアプリが10万行クラスで破綻と聞いて、ずいぶんトーンダウンしたな。
108uy
2012/07/30(月) 01:53:22.77 動的言語で10万行ってさ
一体そんなに何かいてんの?
動的言語だぞ?
動的言語なのにJAVAと同じようにそっくりそのまま書いてるのかなって疑ってしまう
一体そんなに何かいてんの?
動的言語だぞ?
動的言語なのにJAVAと同じようにそっくりそのまま書いてるのかなって疑ってしまう
109uy
2012/07/30(月) 02:03:23.80 コードの大半はテストだろう。
動的言語だと、テストの量が
静的言語の数倍に膨れ上がる。
Rubyでテストをまともに書いている所は、
テストの量が膨れ上がるから
修正があった際のテストの修正で苦しんでるはずだよ。
動的言語だと、テストの量が
静的言語の数倍に膨れ上がる。
Rubyでテストをまともに書いている所は、
テストの量が膨れ上がるから
修正があった際のテストの修正で苦しんでるはずだよ。
110uy ◆DU14dte9SY
2012/07/30(月) 03:09:22.88 I am a hikikomori ,
So ,i have not participated in organization of the system.
my written message is all on my dream.
So ,i have not participated in organization of the system.
my written message is all on my dream.
111uy
2012/07/30(月) 05:10:48.69 つうかrubyのメンバ変数の@ってマジでどうにもならないのかな
俺様はOOではないのでそんな問題からは既に解放されているが、
ruby布教の観点から見ると、初心者が使えなければ意味がなく
OOでソース書くなら@つき変数は避けられない
rubyを使う奴が、JAVAと同じように書いていくなら、
@がうっとうしいという理由だけで使われない気がする
先日メンバ変数と、メンバ変数同士の演算が多く必要になってしまう処理を
ほんの気まぐれでクラスで書いたら
ちゃんと最低限のコードで書いているにもかかわらず
マジでひどい見た目になった、これは無理
俺様はOOではないのでそんな問題からは既に解放されているが、
ruby布教の観点から見ると、初心者が使えなければ意味がなく
OOでソース書くなら@つき変数は避けられない
rubyを使う奴が、JAVAと同じように書いていくなら、
@がうっとうしいという理由だけで使われない気がする
先日メンバ変数と、メンバ変数同士の演算が多く必要になってしまう処理を
ほんの気まぐれでクラスで書いたら
ちゃんと最低限のコードで書いているにもかかわらず
マジでひどい見た目になった、これは無理
112uy
2012/07/30(月) 06:15:27.56 いま今後言語を乗り換えることはないと覚悟してソースかいてる
ルビーはまだ粗はあるけどルビーの今後の成長に期待した
俺様の人生効率も左右されかねないのでルビーは頑張ってほしい
規模は現在一万行程度だけど年単位でやるので勝手に大規模なものになってるだろうよ
大規模開発はできる
ルビーはまだ粗はあるけどルビーの今後の成長に期待した
俺様の人生効率も左右されかねないのでルビーは頑張ってほしい
規模は現在一万行程度だけど年単位でやるので勝手に大規模なものになってるだろうよ
大規模開発はできる
113デフォルトの名無しさん
2012/07/30(月) 09:29:16.89 プロジェクトよりテストのコードのほうがでかくなる
本体120mbテスト600mbみたいな
本体120mbテスト600mbみたいな
114デフォルトの名無しさん
2012/07/30(月) 12:30:38.93 >>98
ruby の include の対象を、ヘッダと呼ぶことについて、Matz がどう言うだろうね、って話。
動的言語で大規模開発なんて、言語だけを問題にするなら、問題ないに決まってるだろ。
問題が出るのは、実際には優秀な人数を十分に確保できないからで、一山いくらの兵隊に作業させるなら静的の方がまだマシ、というに過ぎない。
XP のプラクティスの多くは Smalltalk の実践から生まれたわけだし、当然 ruby でも同様に有効だ。
ruby の include の対象を、ヘッダと呼ぶことについて、Matz がどう言うだろうね、って話。
動的言語で大規模開発なんて、言語だけを問題にするなら、問題ないに決まってるだろ。
問題が出るのは、実際には優秀な人数を十分に確保できないからで、一山いくらの兵隊に作業させるなら静的の方がまだマシ、というに過ぎない。
XP のプラクティスの多くは Smalltalk の実践から生まれたわけだし、当然 ruby でも同様に有効だ。
115uy
2012/07/30(月) 12:47:33.25 じゃあやってみろ
116デフォルトの名無しさん
2012/07/30(月) 12:58:18.64117デフォルトの名無しさん
2012/07/30(月) 14:08:36.23 誰だかわかんねー個人ブログ引っ張ってくる奴もゴミ
そんなブログにマジレスする奴もゴミ
そんなブログにマジレスする奴もゴミ
118デフォルトの名無しさん
2012/07/30(月) 18:03:04.44119デフォルトの名無しさん
2012/07/30(月) 18:05:59.91120デフォルトの名無しさん
2012/07/31(火) 00:41:17.19 ヘッダの意味がわかってないんじゃないか
121uy
2012/07/31(火) 10:19:41.99 こうして一人ずつ発狂して
uy粘着と化す
もしかして俺ってrubyにすげー迷惑かけてんの?w
バトロワスレみてるとそうなのかなぁと思い始める
実際言語なんて宗教みたいなもんだしな
rubyのいいところは言語仕様を思い切ってmatzが変えていく所でもあると思う
C#とかじゃ、「あ、これ設計間違ってたね・・・」とか後から気づいても
絶対変える事はないからな、様々なしがらみによって出来ないんだそれ
あまりrubyの仕様は変わって欲しくないが、間違っている箇所はどんどん変えたら良いと思ってる
間違いを認めずに、間違った設計のまま突き進んで周辺ライブラリ、周辺ツール、PGにそのツケを払わせるとかなったら
他のゴミカス言語と同じ
流石の俺も自分の乗っている船を沈没させようとは思ってない
ただ特に貢献しようとも思ってない
俺様の進路に偶然、rubyが落ちてた。rubyは運が良い
俺様に選ばれたrubyは運が良かったと思う
きっと数年後にはそう感じているはずさ このままいけばね
uy粘着と化す
もしかして俺ってrubyにすげー迷惑かけてんの?w
バトロワスレみてるとそうなのかなぁと思い始める
実際言語なんて宗教みたいなもんだしな
rubyのいいところは言語仕様を思い切ってmatzが変えていく所でもあると思う
C#とかじゃ、「あ、これ設計間違ってたね・・・」とか後から気づいても
絶対変える事はないからな、様々なしがらみによって出来ないんだそれ
あまりrubyの仕様は変わって欲しくないが、間違っている箇所はどんどん変えたら良いと思ってる
間違いを認めずに、間違った設計のまま突き進んで周辺ライブラリ、周辺ツール、PGにそのツケを払わせるとかなったら
他のゴミカス言語と同じ
流石の俺も自分の乗っている船を沈没させようとは思ってない
ただ特に貢献しようとも思ってない
俺様の進路に偶然、rubyが落ちてた。rubyは運が良い
俺様に選ばれたrubyは運が良かったと思う
きっと数年後にはそう感じているはずさ このままいけばね
122uy
2012/07/31(火) 10:28:44.35 言語って所詮、言語を色づけしてるのは使用ユーザーかなって思うよ
その言語を気に入ったユーザーがライブラリを作ったり情報を描いて
この言語は○○をやりやすい言語 ってなってる気がする
静的言語だと結構どうやっても他言語にある概念を実装できないみたいな
壁にぶち当たることはあるんだろうけど
動的言語の場合evalさえ使えば大抵は、他言語の概念は
無理やりでよければもってこれると思う
とりあえずrubyをやる前は、C++とかにある ; これが鬱陶しいだけだったが
今では括弧すら鬱陶しく感じる
メソッド呼び出しから括弧を取り外すって簡単なようで実際めっちゃ難しいよね
a , b = c , d , e
とか、さ
何がメソッドで何が引数で、もしかしたらメソッドにデフォルト引数があるとか、
あるいは
c , d , e が全部変数でも、正しく動作するわけだし
プログラミングに煩わしい括弧取り外すのは簡単なことではなかった
rubyは成功言語
その言語を気に入ったユーザーがライブラリを作ったり情報を描いて
この言語は○○をやりやすい言語 ってなってる気がする
静的言語だと結構どうやっても他言語にある概念を実装できないみたいな
壁にぶち当たることはあるんだろうけど
動的言語の場合evalさえ使えば大抵は、他言語の概念は
無理やりでよければもってこれると思う
とりあえずrubyをやる前は、C++とかにある ; これが鬱陶しいだけだったが
今では括弧すら鬱陶しく感じる
メソッド呼び出しから括弧を取り外すって簡単なようで実際めっちゃ難しいよね
a , b = c , d , e
とか、さ
何がメソッドで何が引数で、もしかしたらメソッドにデフォルト引数があるとか、
あるいは
c , d , e が全部変数でも、正しく動作するわけだし
プログラミングに煩わしい括弧取り外すのは簡単なことではなかった
rubyは成功言語
123デフォルトの名無しさん
2012/07/31(火) 11:27:26.69 ヘッダを include できるし、xor で and や or を作れるし、素晴らしいね!
124uy
2012/07/31(火) 12:01:56.24 何でこいつはいつまでもrequireとincludeの動作を覚えないの
125uy
2012/07/31(火) 12:03:08.37 あー言っちゃった・・・
126uy
2012/07/31(火) 21:49:07.39 ちんこ
127uy
2012/08/01(水) 00:16:52.93 死ねゴミ
128デフォルトの名無しさん
2012/08/01(水) 01:49:27.031000 :uy ◆xVOGOO9ev6 :2012/06/23(土) 12:35:29.68
俺は動的言語の問題点をいくつあげてもwwwww
静的言語よりはマシだと確信してるわwwwwwwwwwwwwwwwww
静的言語の問題点をなぜ挙げないかって??
見放してるから、問題点を指摘さえしないってことだよwwwwwwwwwww
気づけバカwwwwwwwwwwwwwww
129デフォルトの名無しさん
2012/08/03(金) 06:32:47.82 二度と話しかけんなよ
130デフォルトの名無しさん
2012/08/11(土) 10:20:21.60 日本の土建屋的SIerでやっていくには、一度固めたら(=コンパイルしたら)
動作がブレない静的言語の方が向いている、と、
勝手に顧客の本番環境でスクリプトとか勝手に書き換えるダメプログラマを見てたらオモタ。
動的言語でアジャイルに〜なんて言える現場はスキルと意識が高い恵まれた職場だと思うよ。
動作がブレない静的言語の方が向いている、と、
勝手に顧客の本番環境でスクリプトとか勝手に書き換えるダメプログラマを見てたらオモタ。
動的言語でアジャイルに〜なんて言える現場はスキルと意識が高い恵まれた職場だと思うよ。
131uy
2012/08/11(土) 11:11:11.81 > 日本の土建屋的SIerでやっていくには、一度固めたら(=コンパイルしたら)
> 動作がブレない静的言語の方が向いている、と、
誰もそんな事言ってないんだがw
お前のそのアホな思いつきに従えば
再コンパイルするんだから、動作がぶれてるだろ
> 動作がブレない静的言語の方が向いている、と、
誰もそんな事言ってないんだがw
お前のそのアホな思いつきに従えば
再コンパイルするんだから、動作がぶれてるだろ
132デフォルトの名無しさん
2012/08/11(土) 12:03:04.92 本番環境にコンパイラ入れるな
133デフォルトの名無しさん
2012/08/12(日) 00:59:20.15 使い分けるもんじゃないのか
135デフォルトの名無しさん
2012/08/12(日) 10:57:54.02 勝手に書き換えるのは顧客のPGでしょ。
136uY ◆gXFLM6waxs
2012/08/19(日) 03:14:31.35 あーーーもうメソッド名の変更って
この作業は割りと重要だな
aliasじゃダメなんだよ
気分的に無理
この作業は割りと重要だな
aliasじゃダメなんだよ
気分的に無理
137uY
2012/08/20(月) 19:41:34.56 昨日プロジェクト全体ソースがついに1万行を超えた
rubyで1万行という数字の意味が分かる奴は少ない
どこもハードコーディングしてないし、同じシンボルが必要な場所ではメタしたりmoduleで分けてmix-inも行ってる
およそ2ヶ月ちょいでこんくらいいくみたいだな
大規模開発できないって言った奴でてこいよ
rubyで1万行という数字の意味が分かる奴は少ない
どこもハードコーディングしてないし、同じシンボルが必要な場所ではメタしたりmoduleで分けてmix-inも行ってる
およそ2ヶ月ちょいでこんくらいいくみたいだな
大規模開発できないって言った奴でてこいよ
138デフォルトの名無しさん
2012/08/20(月) 20:10:06.70 そこまで言うのなら
ソースを見せてほしい
ソースを見せてほしい
139デフォルトの名無しさん
2012/08/20(月) 20:22:35.15 何人でその期間?
140デフォルトの名無しさん
2012/08/20(月) 21:17:46.18 Rubyの習得は一瞬だよ
1万行書くのに1時間かからないだろう
問題はまともなデザインのソフトを作れるかどうか
デザインセンスの方が重要
1万行書くのに1時間かからないだろう
問題はまともなデザインのソフトを作れるかどうか
デザインセンスの方が重要
141uY ◆gXFLM6waxs
2012/08/20(月) 22:31:47.89 ごめん
やっぱ無理だ
Ruby無理
これ無理
1歩間違えたら終わってた事実に今日気づいた
ちょー危ない
rubyすごい
今再現しないバグをどうやって再現させてバグレポート送るか試行錯誤中
やっぱ無理だ
Ruby無理
これ無理
1歩間違えたら終わってた事実に今日気づいた
ちょー危ない
rubyすごい
今再現しないバグをどうやって再現させてバグレポート送るか試行錯誤中
142uY ◆gXFLM6waxs
2012/08/20(月) 23:02:29.91 えっえっ嘘
プロジェクト本体でもバグ再現しなくなってた
もういいや
もうやだ
勝手に誰かが直してくれた
プロジェクト本体でもバグ再現しなくなってた
もういいや
もうやだ
勝手に誰かが直してくれた
143uY ◆gXFLM6waxs
2012/08/20(月) 23:07:41.34 なんか・・・・文字化けしたメッセージがDUMPされた
144uY ◆gXFLM6waxs
2012/08/20(月) 23:45:21.01 バグコードを追うためにコード減らしていく→まだバグでる→でる→でる
→あ、でなくなった戻そう→え?バグでないし、もっと戻そう→え?バグでねーじゃんあせdrftgyふじ →最初から
俺の技術じゃトレース無理かもしれない
→あ、でなくなった戻そう→え?バグでないし、もっと戻そう→え?バグでねーじゃんあせdrftgyふじ →最初から
俺の技術じゃトレース無理かもしれない
145uY ◆gXFLM6waxs
2012/08/21(火) 00:15:30.32 はぁ、、つかれた、、
ライブラリと完全分離した結果
ライブラリではなくrubyのバグであることが確定した
ちかれた
ライブラリと完全分離した結果
ライブラリではなくrubyのバグであることが確定した
ちかれた
146デフォルトの名無しさん
2012/08/21(火) 01:10:35.50 マイナー言語にはよくあること。
メジャー言語にもあるけどね。
メジャー言語にもあるけどね。
147uY
2012/08/21(火) 01:36:14.78 もうやだ
148uy
2012/08/21(火) 04:41:45.26 動的言語で大規模開発やってるやつほんとにすごいよ
よくこれで出来るなアンリミテッドルールブックなんだよ
ルールがない
だから自分で定義し
使っていいものダメなものきめてかいていく
しかし道具のいくつかを使わないってことは
効率をさげるんだよ
けど全部はぜったい使えない
自分の妥協との戦い
細かいことをきにしないスキルも必要
よくこれで出来るなアンリミテッドルールブックなんだよ
ルールがない
だから自分で定義し
使っていいものダメなものきめてかいていく
しかし道具のいくつかを使わないってことは
効率をさげるんだよ
けど全部はぜったい使えない
自分の妥協との戦い
細かいことをきにしないスキルも必要
149デフォルトの名無しさん
2012/08/21(火) 09:21:42.24 a, b = [1,2,3].cycle, ["a","b"].cycle
p (1..25).map{ |i| (i%5)!=0 ? a.next : b.next }
たったこれだけで済む事を下みたいに書いてるuyなら
1万行なんてすぐだろうな。
n = i = 0
s = []
b = ["a","b"]
[1,2,3].cycle do | m |
n += 1
i += 1
break if n == 21
s << m
if i == 4
i = 0
s << b.first
b.rotate!
end
end
p s
p (1..25).map{ |i| (i%5)!=0 ? a.next : b.next }
たったこれだけで済む事を下みたいに書いてるuyなら
1万行なんてすぐだろうな。
n = i = 0
s = []
b = ["a","b"]
[1,2,3].cycle do | m |
n += 1
i += 1
break if n == 21
s << m
if i == 4
i = 0
s << b.first
b.rotate!
end
end
p s
150uY ◆gXFLM6waxs
2012/08/21(火) 10:25:03.64 あおりにすらならないは
つうか2ヶ月で1万行だと1年で6万行だよ
しかも2ヶ月のうち、プログラミングしてた日数ってそんなに無いし
これ続けてたら素でrailsとかの規模超えると思う
変なコードは書いてないんだけどな
rubyは開発力が違いすぎるのかもしれない
つうか2ヶ月で1万行だと1年で6万行だよ
しかも2ヶ月のうち、プログラミングしてた日数ってそんなに無いし
これ続けてたら素でrailsとかの規模超えると思う
変なコードは書いてないんだけどな
rubyは開発力が違いすぎるのかもしれない
151デフォルトの名無しさん
2012/08/21(火) 10:30:02.52 uyがかrubyがかはしらんけど
「糞コード量産力がはんぱない」のまちがいだろ
「糞コード量産力がはんぱない」のまちがいだろ
152uy ◆gXFLM6waxs
2012/08/21(火) 11:17:54.84 どんだけ煽ってももう無理なんだよ・・・
もう完成しちゃってるんだ
設計そのものが
しかもおそらくrubyレベルの柔軟な言語じゃないと
到底作る事の出来ないシステムが・・・
絶対にお前らじゃ追いつけないと分かる
もう完成しちゃってるんだ
設計そのものが
しかもおそらくrubyレベルの柔軟な言語じゃないと
到底作る事の出来ないシステムが・・・
絶対にお前らじゃ追いつけないと分かる
153uY
2012/08/21(火) 11:23:29.19 バカには無理
154デフォルトの名無しさん
2012/08/21(火) 11:38:31.45 昨日1万越えて、もう10800行ってる
増加はとまらない
増加はとまらない
155デフォルトの名無しさん
2012/08/21(火) 13:37:21.15 行数多いのを大規模開発と思ってるのか。乙。
156uY
2012/08/21(火) 18:54:34.84 最初から大規模って言ってるのに記憶力ねーな
根幹部分がおよそ2000行のコード
この時点から既に大規模開発である
根幹部分がおよそ2000行のコード
この時点から既に大規模開発である
157uY
2012/08/21(火) 18:57:00.66 元々いくらでもソース詰んでいける設計だったけど
実際にこれだけの規模になると違ってくる
動的言語は色んな面できつい
ソースコード管理をしっかりやらないと死ぬ
実際にこれだけの規模になると違ってくる
動的言語は色んな面できつい
ソースコード管理をしっかりやらないと死ぬ
158デフォルトの名無しさん
2012/08/21(火) 19:08:04.43 関わる人が増えてくると、名前の重複、平行開発の待ちなど様々な問題が出てくる。
159uY
2012/08/21(火) 20:16:47.85 ソースの中でちょっと気になった場所を安易に変更するっていうのは
やっちゃいけないのが動的言語だと思う
変数名やメソッド名を変えたら全体テストやり直しとか言ってる奴もいるけどそれと同じだ
アルゴリズムの一部を変えて、
いらないと思ってた変数を消してみたら、後ろのほうで使ってたとかがある
動的言語は開発スタイルそのものを変えないと意味が無い
静的言語と同じように使っていても効率が下がるだけ
まともに動的言語で大規模開発できる奴は紛れもなくスキル高いと確信した
普通は出来ない
やっちゃいけないのが動的言語だと思う
変数名やメソッド名を変えたら全体テストやり直しとか言ってる奴もいるけどそれと同じだ
アルゴリズムの一部を変えて、
いらないと思ってた変数を消してみたら、後ろのほうで使ってたとかがある
動的言語は開発スタイルそのものを変えないと意味が無い
静的言語と同じように使っていても効率が下がるだけ
まともに動的言語で大規模開発できる奴は紛れもなくスキル高いと確信した
普通は出来ない
160uY
2012/08/21(火) 20:31:48.89 "ちょっと高い"レベルじゃないからな
優秀な技術者というのもバズワード的な優秀という意味ではなく
マジで優秀って意味の優秀
100人中1位とかいうレベル以上の優秀
バカには無理
優秀な技術者というのもバズワード的な優秀という意味ではなく
マジで優秀って意味の優秀
100人中1位とかいうレベル以上の優秀
バカには無理
161デフォルトの名無しさん
2012/08/21(火) 22:51:24.55 > 消してみたら、使ってた
普通は消す前に確認するけどな。
コンパイラ任せで消してみるというのもチェックの方法のひとつではあるけど。
普通は消す前に確認するけどな。
コンパイラ任せで消してみるというのもチェックの方法のひとつではあるけど。
162デフォルトの名無しさん
2012/08/21(火) 23:02:58.40 そもそも変数が管理しきれないほどの広いスコープでコードを書かない方が良い。
163デフォルトの名無しさん
2012/08/22(水) 00:18:17.90 と言ってもほとんどのスクリプト言語のスコープは関数単位で、1度しか使わない処理も全部関数化するっていうのもねー
164デフォルトの名無しさん
2012/08/22(水) 00:24:03.04 スコープは関数単位だけどスクリプト言語なら普通は使う直前に宣言できるだろ。
そしてオブジェクトは不要になったらいつでも破棄できるだろ。
そしてオブジェクトは不要になったらいつでも破棄できるだろ。
165デフォルトの名無しさん
2012/08/22(水) 00:45:05.58 >>163
普通は構造やオブジェクトのメソッドという意味単位で分けるものなのよ。むしろ自然と分かれる。
普通は構造やオブジェクトのメソッドという意味単位で分けるものなのよ。むしろ自然と分かれる。
166デフォルトの名無しさん
2012/08/22(水) 07:46:30.85 意味単位でメソッド作ってたら、再利用されないメソッドだらけになるじゃん。
167デフォルトの名無しさん
2012/08/22(水) 08:17:25.53 ワロス
意味単位で分割した上で、再利用を考えてラップするんだろ?
意味単位で分割した上で、再利用を考えてラップするんだろ?
168デフォルトの名無しさん
2012/08/22(水) 10:33:50.23 こういう奴がmain1000行とかやっちゃうんだろうな。
スクリプト言語もできる奴と、スクリプト言語しかできない奴の差な気がする
スクリプト言語もできる奴と、スクリプト言語しかできない奴の差な気がする
169uy
2012/08/22(水) 11:23:23.35 この超ハイレベルのスレに論外初心者が迷い込んだ奇跡
170uy
2012/08/22(水) 11:27:10.62 とりあえずOOは静的言語でプログラムを組んでいく事を前提に作られた設計手法だから
OO以外の動的言語流の設計を編み出すか、
あるいはOOをどうにかして動的言語で運用していくか
どちらも要求されるレベルは高い
OO以外の動的言語流の設計を編み出すか、
あるいはOOをどうにかして動的言語で運用していくか
どちらも要求されるレベルは高い
171デフォルトの名無しさん
2012/08/22(水) 12:59:19.31 Rubyやgroovyは動的でOOだと思うんだが、
天才様の脳内では違うのか。
天才様の脳内では違うのか。
172デフォルトの名無しさん
2012/08/22(水) 13:52:03.31 >>166
仕様では意味単位でクラスやメソッドが出てくるので、どれを再利用すればいいかがよくわかる。
仕様では意味単位でクラスやメソッドが出てくるので、どれを再利用すればいいかがよくわかる。
173デフォルトの名無しさん
2012/08/22(水) 14:02:19.51174uY
2012/08/22(水) 14:15:51.29 >>171
動的言語でOOは無理
っていうか静的言語と比べて欠点のほうが多いと思う
動的言語の利点は、動的に型を変えられる事
にもかかわらず同じ数だけクラスを宣言し
同じ数だけメソッドを定義していたら意味がない
そんなことをやればrubyはメンバ変数に@がついてる分、他の言語よりも冗長だよ
ライブラリはクラスを使ってOOで書いてもいいけど
動的言語はプログラムの大半をラムダ(yield)で書くべき
動的言語でOOは無理
っていうか静的言語と比べて欠点のほうが多いと思う
動的言語の利点は、動的に型を変えられる事
にもかかわらず同じ数だけクラスを宣言し
同じ数だけメソッドを定義していたら意味がない
そんなことをやればrubyはメンバ変数に@がついてる分、他の言語よりも冗長だよ
ライブラリはクラスを使ってOOで書いてもいいけど
動的言語はプログラムの大半をラムダ(yield)で書くべき
175uY
2012/08/22(水) 14:50:11.56 つうかrubyで俺メンバ変数ほとんど使わないプログラミングを始めてる
ライブラリになれる機能はクラス宣言
ライブラリにはなれない && たいして大きくないものは
新規にクラスを宣言せず、オブジェクトを生成してからmoduleのextendなどで変数、メソッドを追加
これでほとんどいける
ライブラリになれる機能はクラス宣言
ライブラリにはなれない && たいして大きくないものは
新規にクラスを宣言せず、オブジェクトを生成してからmoduleのextendなどで変数、メソッドを追加
これでほとんどいける
176デフォルトの名無しさん
2012/08/30(木) 02:16:17.91 ruby2.0がかなりすごいらしい
177デフォルトの名無しさん
2012/09/09(日) 10:05:38.04 らしいって誰かの受け売り?
178デフォルトの名無しさん
2012/09/09(日) 10:10:28.19 ステマ
179デフォルトの名無しさん
2012/09/09(日) 12:43:43.33 ruby2.0がかなりすごいらしい
180デフォルトの名無しさん
2012/09/09(日) 12:46:30.48 バズワード
181デフォルトの名無しさん
2012/09/09(日) 13:04:25.31 ruby2.0はかなりすごいらしい
182uy
2012/09/09(日) 13:15:02.03 互換性の無さが凄い
183デフォルトの名無しさん
2012/09/09(日) 14:05:50.21 ruby2.0でついにアレがくるらしいとのこと
184デフォルトの名無しさん
2012/09/09(日) 22:38:42.39 rubyの価格破壊がくるらしい
185デフォルトの名無しさん
2012/09/09(日) 22:42:12.13 価値破壊は既に進行してますが (w
186デフォルトの名無しさん
2012/09/10(月) 00:06:57.72 まあ頑張ってほしいけどさ便利は便利だしもう精神的にperlとかやになっちまってるし
187デフォルトの名無しさん
2012/09/10(月) 00:50:17.78 perlってほんのここ数年で一気にネットの評判ガタ落ちになった気がする
rubyがここ数年でそれだけ広まったってことだと思う
もっと早くに気づくべきだったよ
rubyよりもperlが積極的に使われてたのは2008年くらいまでだろうか
気づくのが遅い遅い遅い遅い
rubyがここ数年でそれだけ広まったってことだと思う
もっと早くに気づくべきだったよ
rubyよりもperlが積極的に使われてたのは2008年くらいまでだろうか
気づくのが遅い遅い遅い遅い
188デフォルトの名無しさん
2012/09/10(月) 06:32:50.99 >>187
phpの影響でperl減ったんじゃないか。
phpの影響でperl減ったんじゃないか。
189デフォルトの名無しさん
2012/09/10(月) 13:42:40.57 >>188
まったくもってそのとおりだったwww
まったくもってそのとおりだったwww
190デフォルトの名無しさん
2012/09/10(月) 22:32:40.37 php5割
ruby2割
perl居残り組3割
こんくらいかと思ったけど
これはサーバーサイドのみの状況だった
LLとして見るなら
ruby4割
python4割
php1割
perl居残り1割
rubyの出現でperl終わってしまった
ruby2割
perl居残り組3割
こんくらいかと思ったけど
これはサーバーサイドのみの状況だった
LLとして見るなら
ruby4割
python4割
php1割
perl居残り1割
rubyの出現でperl終わってしまった
191デフォルトの名無しさん
2012/09/10(月) 23:06:18.99 なにこのrubyひいきめ。1割も無いだろ。
192デフォルトの名無しさん
2012/09/11(火) 11:11:33.93 perlの1割のユーザーでperlリソースを越えたかwwwwwwwwwwwwwww
193デフォルトの名無しさん
2012/09/11(火) 19:29:13.02 ルビリストつええ
194デフォルトの名無しさん
2012/09/13(木) 20:49:27.18 Perlは書いたコード誰も読めないからな。滅ぶべき言語
かといってRubyもどうかね
かといってRubyもどうかね
195デフォルトの名無しさん
2012/09/13(木) 23:21:46.35 rubyは可読性を優先して
リスト内包表記を実装しなかったりしてる言語
でも最悪なコードは他にいくらでもかける
使い手次第
リスト内包表記を実装しなかったりしてる言語
でも最悪なコードは他にいくらでもかける
使い手次第
196vy
2012/09/14(金) 01:08:33.04 ダメなコード書くプログラマは良い言語使っても、
厳しいコーディング規約を課しても、
便利なIDEにフレームワークを使わせても、ダメなコードを書く。
熟達したプログラマは例えCOBOLでもHSPでも、
読み易くて変更に強い良いコードを書く。
それが世の道理だよ。
厳しいコーディング規約を課しても、
便利なIDEにフレームワークを使わせても、ダメなコードを書く。
熟達したプログラマは例えCOBOLでもHSPでも、
読み易くて変更に強い良いコードを書く。
それが世の道理だよ。
197デフォルトの名無しさん
2012/09/14(金) 15:07:56.72 キリッ
198デフォルトの名無しさん
2012/09/14(金) 21:41:56.59199uy
2012/09/14(金) 22:48:35.89 聞き捨ての知識で知ったかぶるゴミカスってへらないよな
内包表記なんてその名の通り開始括弧と閉じ括弧がついてるんだから
この程度も実装できない頭とかおめでたすぎるわwwwwwwwwwww
さっさと死ねゴミクズ
内包表記なんてその名の通り開始括弧と閉じ括弧がついてるんだから
この程度も実装できない頭とかおめでたすぎるわwwwwwwwwwww
さっさと死ねゴミクズ
200デフォルトの名無しさん
2012/09/14(金) 23:42:23.98 1.9でラムダ式の構文入れたときも
x->{} じゃなくて ->x{} なんてキモい構文で
しかも空白有る無しでバグってたRubyだからな...
x->{} じゃなくて ->x{} なんてキモい構文で
しかも空白有る無しでバグってたRubyだからな...
201デフォルトの名無しさん
2012/09/15(土) 00:37:50.39 前からmatz自身がパーサ定義一杯一杯言うとったしなあ
なんか代替見つかったんだろか
なんか代替見つかったんだろか
202デフォルトの名無しさん
2012/09/15(土) 00:39:18.96 代案ですか?
Ruby 3.0です!
Ruby 3.0です!
203デフォルトの名無しさん
2012/09/15(土) 02:24:11.94204uy
2012/09/15(土) 03:58:59.74 ップwwwwwwwwwwwww
後置きイテレータとかの実装ならまだしも
リスト内包表記程度のパーサもかけねーのかよwwwwwww
yacc関係ないwwwwww
後置きイテレータとかの実装ならまだしも
リスト内包表記程度のパーサもかけねーのかよwwwwwww
yacc関係ないwwwwww
205デフォルトの名無しさん
2012/09/15(土) 04:02:23.07 CRubyはbison使ってるから関係あるよ
206デフォルトの名無しさん
2012/09/15(土) 04:13:34.11 LLとかにこだわらず、パーサーくらい自分でフルで書いてみろよw
好きな言語作れるぜ
好きな言語作れるぜ
207uy
2012/09/15(土) 17:05:33.28 205
またアスペがつれた
てめー話かけんなっていっただろ
またアスペがつれた
てめー話かけんなっていっただろ
208uy
2012/09/15(土) 17:08:27.11 しかしアレだけ書籍でてんのにまだこんなゴミカスいたんだな
流石に成長しない板だわ
流石に成長しない板だわ
209uy
2012/09/15(土) 17:35:49.76 なぜリスト内包表記が難しいと思ったのか
ドカタだとこのレベルで苦戦なのかよ
ドカタだとこのレベルで苦戦なのかよ
210uy
2012/09/15(土) 17:41:03.52 yacc(笑)みたいなゴミしか知らない奴も大変だよね
何年間そこで知識とまってんだよwwwwwwwwwwwwwww
何年間そこで知識とまってんだよwwwwwwwwwwwwwww
211デフォルトの名無しさん
2012/09/15(土) 17:41:07.91 (*´・∀・)(・∀・`*)ヘー
212uy
2012/09/15(土) 18:04:56.91 くやしくて声もでませんwwwwwwwwwwwwwwwwwwwwwwwwwwww
213デフォルトの名無しさん
2012/09/15(土) 22:12:16.43214vy
2012/09/15(土) 23:34:31.67 言語に拘るようじゃまだまだ二流だな。
一流は言語もツールも選ばない。
要件を満たす適切なコードを書き、必要に応じてフレームワークまで即興で作る。
既存の言語やフレームワークの優劣に拘るのは自分に自信が無いからだよ。
速い車に乗って粋がってる青二才と同じ。
一流は言語もツールも選ばない。
要件を満たす適切なコードを書き、必要に応じてフレームワークまで即興で作る。
既存の言語やフレームワークの優劣に拘るのは自分に自信が無いからだよ。
速い車に乗って粋がってる青二才と同じ。
215デフォルトの名無しさん
2012/09/15(土) 23:37:28.67 急に自分語り始めちゃったよ
なんだこいつ
なんだこいつ
216デフォルトの名無しさん
2012/09/15(土) 23:43:25.07217uy
2012/09/16(日) 00:25:00.51 また社畜開発の話だよwwwwwwwwwwwwww
なんでドカタ開発前提でしゃべる奴がいるんだろう
たったひとりでもプログラムは開発できるし
出来る奴が数人集まれば大抵のものは 作れるはずですよね・・・・・
大人数にする意味ってwwwwwwwwwwwwwww
ワイワイやってデスマだ炎上だって修羅場ごっこしたいんですか?wwwww
なんでドカタ開発前提でしゃべる奴がいるんだろう
たったひとりでもプログラムは開発できるし
出来る奴が数人集まれば大抵のものは 作れるはずですよね・・・・・
大人数にする意味ってwwwwwwwwwwwwwww
ワイワイやってデスマだ炎上だって修羅場ごっこしたいんですか?wwwww
218デフォルトの名無しさん
2012/09/16(日) 00:26:35.12219デフォルトの名無しさん
2012/09/16(日) 03:49:53.24 >>217
とりあえずスレタイを読むことが出来る奴でないと話にすらならないな
とりあえずスレタイを読むことが出来る奴でないと話にすらならないな
220デフォルトの名無しさん
2012/09/16(日) 17:21:34.85 素人目には大規模開発には関数型言語とりいれた方が良さそうに見えるんだけど
ここに動的言語を採用するなんてのは、ちょっと正気の沙汰とは思えない
ググってみたら、日本IBMがsmalltalkで病院システム開発に失敗した事例でてきた
大手での採用事例さえ増えれば、javaからscalaへ移行するんじゃね?
ここに動的言語を採用するなんてのは、ちょっと正気の沙汰とは思えない
ググってみたら、日本IBMがsmalltalkで病院システム開発に失敗した事例でてきた
大手での採用事例さえ増えれば、javaからscalaへ移行するんじゃね?
221デフォルトの名無しさん
2012/09/16(日) 17:29:22.90222デフォルトの名無しさん
2012/09/16(日) 18:18:36.16 > プロがそう言っています。
ドカタのプロフェッショナルwwww
ドカタのプロフェッショナルwwww
223デフォルトの名無しさん
2012/09/16(日) 18:59:37.85224デフォルトの名無しさん
2012/09/16(日) 19:04:29.56 >>222
ドカタってプロのことだったんですねw
ドカタってプロのことだったんですねw
225デフォルトの名無しさん
2012/09/16(日) 19:13:49.68 ナレーター「プロドカタの朝は早い」
226デフォルトの名無しさん
2012/09/16(日) 20:55:06.22 議論に負けそうになったら、
いつもドカタの話にすり替える。
いつもドカタの話にすり替える。
227デフォルトの名無しさん
2012/09/16(日) 20:59:54.80 つまり「プロがそう言っています(キリッ」で議論に勝ちそうだったのに
ドカタの話にすり替えるなと、そう言いたいのですね
ドカタの話にすり替えるなと、そう言いたいのですね
228デフォルトの名無しさん
2012/09/16(日) 21:03:19.89 関数型言語は業務で使える!
と、信者が宣伝している段階。
業務で使っている! ではない所に注意なw
と、信者が宣伝している段階。
業務で使っている! ではない所に注意なw
229デフォルトの名無しさん
2012/09/16(日) 21:11:08.15 業務に使っても良いけど、
ドカタ仕事は関数型言語を使ってもドカタ仕事
底辺は底辺なりに自分の境遇に満足して、変に夢持っちゃダメ
ドカタ仕事は関数型言語を使ってもドカタ仕事
底辺は底辺なりに自分の境遇に満足して、変に夢持っちゃダメ
230デフォルトの名無しさん
2012/09/16(日) 21:26:13.42 よくある「あいつらは馬鹿、俺は天才。」という書き込みでした
231uy
2012/09/16(日) 22:54:04.49 関数型厨の書き込みって
俺のネタ書き込みよりひどい
これが素なのだとしたらもう・・・
俺のネタ書き込みよりひどい
これが素なのだとしたらもう・・・
232デフォルトの名無しさん
2012/09/16(日) 22:56:16.73233vy
2012/09/16(日) 23:22:41.11 関数型言語には関数型言語の適した分野が、
動的言語には動的言語の適した分野があるよ。
それも分からずに○○は××にも使える、とか主張するのは二流を通り越して三流だね。
動的言語には動的言語の適した分野があるよ。
それも分からずに○○は××にも使える、とか主張するのは二流を通り越して三流だね。
234デフォルトの名無しさん
2012/09/17(月) 03:53:18.86 存在がネタ
235デフォルトの名無しさん
2012/09/17(月) 07:11:36.99 オブジェクト指向開発だって新日鉄SOLが研究資金を出して使い始めるまでは、
業務で実用化されてなかったもんだよ
メモリや速度が重要視されるならc/c++が使われるだろうし、
小規模案件はjsだろうし、大規模開発や業務系は関数型(scalaかf#)に収束するよ
業務で実用化されてなかったもんだよ
メモリや速度が重要視されるならc/c++が使われるだろうし、
小規模案件はjsだろうし、大規模開発や業務系は関数型(scalaかf#)に収束するよ
236デフォルトの名無しさん
2012/09/17(月) 07:48:31.55 収束してから出なおせやw
237デフォルトの名無しさん
2012/09/17(月) 08:00:25.00 絶対とは言い切れないけど、業務系は関数型にはならないよ
副作用を隔離しなきゃダメなほど複雑なコード組んでないから
単純にデータを右から左に流すだけの簡単なお仕事
副作用を隔離しなきゃダメなほど複雑なコード組んでないから
単純にデータを右から左に流すだけの簡単なお仕事
238デフォルトの名無しさん
2012/09/17(月) 08:10:10.39 業務に関数型?
まあ、データを右から左に流すだけだからこそ関数型が合ってると言えなくもないけど、
わざわざ言語変更するほどのモチベーションにはなりえないだろうな。
ようやく VB6 ⇒ VB.net へ移行を開始 ... 現場はこんなもんだし。
まあ、データを右から左に流すだけだからこそ関数型が合ってると言えなくもないけど、
わざわざ言語変更するほどのモチベーションにはなりえないだろうな。
ようやく VB6 ⇒ VB.net へ移行を開始 ... 現場はこんなもんだし。
239デフォルトの名無しさん
2012/09/17(月) 08:14:02.89 後発負け組の奴らって趨勢が決まって
収束してから乗り換えるって発想なんだな
そりゃ負け組だわ
収束してから乗り換えるって発想なんだな
そりゃ負け組だわ
240デフォルトの名無しさん
2012/09/17(月) 08:36:04.27 業務アプリに先端技術を惜しげもなく投入。
でも、できることは変わりません w
アホ面晒して楽しい? >> 239
でも、できることは変わりません w
アホ面晒して楽しい? >> 239
241デフォルトの名無しさん
2012/09/17(月) 08:43:11.33242デフォルトの名無しさん
2012/09/17(月) 09:24:42.46 だからわざわざ関数型なんてまだまだ使わないよって書いてるんだが…
アホ面に泥まで塗って楽しいのか? (w
アホ面に泥まで塗って楽しいのか? (w
243デフォルトの名無しさん
2012/09/17(月) 09:57:55.02 >>239
発散してるって見抜けないの?w
発散してるって見抜けないの?w
244デフォルトの名無しさん
2012/09/17(月) 10:48:47.58 ダメなコード書くプログラマは良い言語使っても、
厳しいコーディング規約を課しても、
便利なIDEにフレームワークを使わせても、ダメなコードを書く。
=> ダメコードはコンパイル通らない関数型言語を使うとどうなるの?
厳しいコーディング規約を課しても、
便利なIDEにフレームワークを使わせても、ダメなコードを書く。
=> ダメコードはコンパイル通らない関数型言語を使うとどうなるの?
246デフォルトの名無しさん
2012/09/17(月) 11:46:55.54 関数型って変化に対応できるの?
仕様変更の多い業務系はOOのがあってる気がするんだが。
仕様変更の多い業務系はOOのがあってる気がするんだが。
247uy
2012/09/17(月) 15:37:21.11 2chってほんとに変な情報操作が流行るよねなんだこの急激な関数型叩き
使える奴は世界のどこかにはいるって
しかしほとんどのバカはそれに憧れて効率的な開発できるフリをしてるだけ
でも大勢が使えばいつかは伸びる
ドカタ以上に人柱になってくれてる奴らなんだから大切にしろwwwww
使える奴は世界のどこかにはいるって
しかしほとんどのバカはそれに憧れて効率的な開発できるフリをしてるだけ
でも大勢が使えばいつかは伸びる
ドカタ以上に人柱になってくれてる奴らなんだから大切にしろwwwww
248デフォルトの名無しさん
2012/09/17(月) 17:26:33.49 >>223
お前はPharoとかSqueakとかのオモチャをちょろっと触ったくらいでSmalltalk知った気になるな。
九大の事件はSmalltalkの問題とされがちだけど、実際はIBMの問題で、
動的言語じゃなくても(IBMが自社製品をごり押しすれば)きっと起こったろうよ。
http://d.hatena.ne.jp/kwatch/20080702/1215014534
お前はPharoとかSqueakとかのオモチャをちょろっと触ったくらいでSmalltalk知った気になるな。
九大の事件はSmalltalkの問題とされがちだけど、実際はIBMの問題で、
動的言語じゃなくても(IBMが自社製品をごり押しすれば)きっと起こったろうよ。
http://d.hatena.ne.jp/kwatch/20080702/1215014534
249デフォルトの名無しさん
2012/09/17(月) 18:17:10.21 VB >>>>>> Smalltalk (IBMにとっては)
250デフォルトの名無しさん
2012/09/17(月) 18:30:33.84 Smalltalkはビジネスユースも多かった言語だけど
うんこすぎて他言語に駆逐された
まさに「業務に使ってみたけどゴミだからそっぽ向かれた」言語
うんこすぎて他言語に駆逐された
まさに「業務に使ってみたけどゴミだからそっぽ向かれた」言語
251デフォルトの名無しさん
2012/09/17(月) 20:02:21.07 smalltalk?javaやMySQLなんてない時代だっけ?
252デフォルトの名無しさん
2012/09/17(月) 21:02:35.51 >>246
仕様変更に強くなるようなOO固有の特徴ってあったっけ?
仕様変更に強くなるようなOO固有の特徴ってあったっけ?
253デフォルトの名無しさん
2012/09/17(月) 21:18:11.19 どっちかっていうと関数型の方が仕様変更に強くないか?
破壊的操作を関数化されてたりしたら目も当てられないし
追いかけたくもないぞ(よくあるけどな)
破壊的操作を関数化されてたりしたら目も当てられないし
追いかけたくもないぞ(よくあるけどな)
254uy
2012/09/17(月) 21:21:00.75 バカか
255デフォルトの名無しさん
2012/09/17(月) 21:45:30.87 >>252
私の開発手法のせいかもだけど、顧客の要求中の関数に当たると思う相互関係より、登場するオブジェクトの方が先に安定するから。
私の開発手法のせいかもだけど、顧客の要求中の関数に当たると思う相互関係より、登場するオブジェクトの方が先に安定するから。
256デフォルトの名無しさん
2012/09/17(月) 22:59:28.72 デザパタの達人とかだと想定外な仕様変更なんてないんだろうかね
いつもSEが想定外な仕様変更持ってきてうちのチームの綺麗なコードを台無しにしやがる
ええ無能ですみません
staticなリエントラント関数しか使いまわせてないは
いつもSEが想定外な仕様変更持ってきてうちのチームの綺麗なコードを台無しにしやがる
ええ無能ですみません
staticなリエントラント関数しか使いまわせてないは
257デフォルトの名無しさん
2012/09/17(月) 23:41:14.03 >>256
デザパタ関係ねーよw
仕様変更だろ? 工数がかかるってことをちゃんと伝えたか?
修正っていうのは、仕様変更にとりあえず対応するまでではなく、
綺麗なコードに対応するまでが修正だ。
そこまでの工数がかかるってだけだよ。
その後は技術とは関係ないところの話だろ。
1週間かかります → 3日でやれ とか技術とは関係ない。
デザパタ関係ねーよw
仕様変更だろ? 工数がかかるってことをちゃんと伝えたか?
修正っていうのは、仕様変更にとりあえず対応するまでではなく、
綺麗なコードに対応するまでが修正だ。
そこまでの工数がかかるってだけだよ。
その後は技術とは関係ないところの話だろ。
1週間かかります → 3日でやれ とか技術とは関係ない。
258uy
2012/09/18(火) 00:05:09.40 デザパタの達人wwwwwwwwwwwwwwwwwwwwwwwwwwwwww
デザパタセカンドや3、4がリリースされたら意味はあるかもしれない
現時点のデザパタはゴミカスってより
当たり前すぎる設計に名前を付けただけなんで
教材にしかならない
デザパタセカンドや3、4がリリースされたら意味はあるかもしれない
現時点のデザパタはゴミカスってより
当たり前すぎる設計に名前を付けただけなんで
教材にしかならない
259デフォルトの名無しさん
2012/09/18(火) 00:29:36.01 よくあるのが
アジャイルという単語に踊らされたオッサンが取ってくる
最初っから仕様変更前提のプロジェクト(受託)
工数も仕様変更にかかる予定日数もどう変わるかわからないのに
予算・スケジュールは固定っていうIT土方ならではの仕事
役所関係からこの手の仕事が来たとかいう日には地獄を覚悟すべし
アジャイルという単語に踊らされたオッサンが取ってくる
最初っから仕様変更前提のプロジェクト(受託)
工数も仕様変更にかかる予定日数もどう変わるかわからないのに
予算・スケジュールは固定っていうIT土方ならではの仕事
役所関係からこの手の仕事が来たとかいう日には地獄を覚悟すべし
260デフォルトの名無しさん
2012/09/18(火) 01:25:10.18 営業がJavaと言ってとってきた仕事を数週進めたら、JavaScriptの仕事だった。何度もjavaでいいんですねと確認したのになぁ。
261デフォルトの名無しさん
2012/09/18(火) 02:42:32.29262デフォルトの名無しさん
2012/09/18(火) 22:04:12.71 動的言語ってアジャイル開発には向いてそうだよね
使用変更でクラスや型をどうこうって死にそうでない?
使用変更でクラスや型をどうこうって死にそうでない?
263デフォルトの名無しさん
2012/09/18(火) 22:11:07.84264デフォルトの名無しさん
2012/09/18(火) 22:46:03.31 プロトタイプを動的型付け言語で作り
仕様が固まってきたら静的型付け言語で作り直す
これ最強
仕様が固まってきたら静的型付け言語で作り直す
これ最強
265デフォルトの名無しさん
2012/09/18(火) 22:51:03.62 静的型付のスクリプト言語
266デフォルトの名無しさん
2012/09/18(火) 23:01:40.91 とりあえずCommonLispで書いて
型記述を追記するなり
GCLでCのソースに変換するなりすれば
一番効率がいいんじゃねぇの
Lisper見習いだからホントに出来るかはわからんが
型記述を追記するなり
GCLでCのソースに変換するなりすれば
一番効率がいいんじゃねぇの
Lisper見習いだからホントに出来るかはわからんが
267デフォルトの名無しさん
2012/09/18(火) 23:10:03.44 静的型付けの利点を
最適化による速度向上に置いてるか
静的型チェックによる型安全性に置いてるかで変わる
最適化による速度向上に置いてるか
静的型チェックによる型安全性に置いてるかで変わる
268デフォルトの名無しさん
2012/09/18(火) 23:44:33.93 Cのソースに変換すればコンパイル必要になるし
型安全性も保たれるんじゃないかと
型安全性も保たれるんじゃないかと
269デフォルトの名無しさん
2012/09/19(水) 00:00:53.89 そんなわけないのはObjective-Cみれば分かるだろ
270デフォルトの名無しさん
2012/09/19(水) 03:30:17.57 動的オブジェクトの型が全部object型とかになった
型チェックが意味のないCソースに変換されるわけだ
型チェックが意味のないCソースに変換されるわけだ
271uy
2012/09/19(水) 08:38:37.94>>>>lisper見習い
初心者死ね!!!
272デフォルトの名無しさん
2012/10/02(火) 23:24:04.32 Microsoft、JavaScript系の新言語、TypeScriptのデベロッパー・プレビュー版を発表
http://jp.techcrunch.com/archives/20121001microsoft-previews-new-javascript-like-programming-language-typescript/
http://jp.techcrunch.com/archives/20121001microsoft-previews-new-javascript-like-programming-language-typescript/
273デフォルトの名無しさん
2012/10/05(金) 04:44:59.33 結局動的言語駄目じゃねーかという流れになりつつある昨今
皆様いかがお過ごしでしょうか。
ここ最近出てきた一連のJS出力言語、特にTypeScriptである意味トドメだろw
しかし反動で関数型言語にスポットライトが当たってるのは逆方向にブレすぎではないか
皆様いかがお過ごしでしょうか。
ここ最近出てきた一連のJS出力言語、特にTypeScriptである意味トドメだろw
しかし反動で関数型言語にスポットライトが当たってるのは逆方向にブレすぎではないか
274デフォルトの名無しさん
2012/10/05(金) 12:42:34.09 関数型は局所的に盛り上がるけどなかなか普及の兆しが見えないな。俺もちろっと遊んだ程度で放置してるし
TypeScriptはコケる
TypeScriptはコケる
275デフォルトの名無しさん
2012/10/22(月) 06:25:54.38 JSはウェブ系の場合嫌でも使うしかないからね。いまんとこ、ベターJSの中じゃ、TypeScriptは一番良いと思うね。
276デフォルトの名無しさん
2012/10/22(月) 23:40:56.58277デフォルトの名無しさん
2012/11/03(土) 16:51:07.37278デフォルトの名無しさん
2012/11/03(土) 16:56:19.12 f#やOcsigenなんかはもっと評価されていいはず
279デフォルトの名無しさん
2012/11/03(土) 18:42:25.65 パーサはよく適用例で見かけるけど、金融系でも関数型普及してるのか
COBOLのイメージしかなかったけど確かに都合良さそうだ
まあ俺みたいな底辺土方には一生縁ねーなw
COBOLのイメージしかなかったけど確かに都合良さそうだ
まあ俺みたいな底辺土方には一生縁ねーなw
280デフォルトの名無しさん
2012/11/03(土) 18:44:48.69 金融系って言ってもCOBOL使ってたとことはまったく別の分野じゃない?
281デフォルトの名無しさん
2012/11/03(土) 19:30:58.86 勘定系じゃなくて、デリバティブとかのいわゆる金融工学の方でしょ。
282デフォルトの名無しさん
2012/11/03(土) 23:30:00.20 あんな制御不能なものを工学と呼ぶのは工学への侮辱だな。
...ソフトウエア工学も同類か...orz
...ソフトウエア工学も同類か...orz
283デフォルトの名無しさん
2012/11/04(日) 00:54:13.02 金融系 関数型でぐぐると美辞麗句にまみれたPDFとかがいろいろヒットするなー
門外漢にはなんのこっちゃよくわからんけど
門外漢にはなんのこっちゃよくわからんけど
284デフォルトの名無しさん
2012/11/04(日) 18:58:55.03 >>282
♥
♥
285デフォルトの名無しさん
2013/02/20(水) 21:20:39.01 ところで、shで書かれたconfigureとかは1万行以上あるわけだが、あれは大規模開発になるんか?
286デフォルトの名無しさん
2013/02/20(水) 23:44:16.57 >>285
あなたは手で書いてるの?
あなたは手で書いてるの?
287デフォルトの名無しさん
2013/02/20(水) 23:57:15.20 自動生成だけど?
自動生成ならいくらでもソース量が増えるから、
別にソース量が多いからって大規模じゃないよねっていうIrony。
自動生成ならいくらでもソース量が増えるから、
別にソース量が多いからって大規模じゃないよねっていうIrony。
288デフォルトの名無しさん
2013/02/21(木) 00:01:32.70 ソースを生成するソースを書けば小規模になるんじゃね
289デフォルトの名無しさん
2013/02/21(木) 01:41:04.93 今調べて初めて知ったのか。
290デフォルトの名無しさん
2013/02/21(木) 21:25:30.17 まじでかホント初めて知ったわ。
OSもソースを生成するツールを生成するツールを生成するツールで作成すれば100行程度に縮められるなっ!
OSもソースを生成するツールを生成するツールを生成するツールで作成すれば100行程度に縮められるなっ!
291デフォルトの名無しさん
2013/02/21(木) 21:37:45.76 >>290
そのツールチェインの最後はお前だよお前しだい。
そのツールチェインの最後はお前だよお前しだい。
292デフォルトの名無しさん
2013/04/03(水) 22:31:12.49 >>8
1万行で大規模ワラタw
1万行で大規模ワラタw
293手巣 ◆JvxT/vAhHw
2013/06/15(土) 23:51:26.86 あ
294デフォルトの名無しさん
2014/01/16(木) 15:14:04.15 9 :デフォルトの名無しさん:2014/01/11(土) 12:45:26.07
PHPが多分広く使われてるんだろうけど
Web鯖へのPHP標的とみられるアタックの回数が今年に入ってからヤバい
あらゆる種類のPHPアタックされてる
あいにくPHP鯖じゃないしPHPも動かしてないから無関係だけど
ruby鯖でほんと良かったよ
PHPが多分広く使われてるんだろうけど
Web鯖へのPHP標的とみられるアタックの回数が今年に入ってからヤバい
あらゆる種類のPHPアタックされてる
あいにくPHP鯖じゃないしPHPも動かしてないから無関係だけど
ruby鯖でほんと良かったよ
295デフォルトの名無しさん
2014/01/16(木) 15:58:57.11 〜10万行小規模
100万行中規模
1000万行大規模
100万行中規模
1000万行大規模
296デフォルトの名無しさん
2014/01/16(木) 16:15:44.93 それは生産性の低いCとかの目安だろう
297デフォルトの名無しさん
2014/01/16(木) 16:22:11.85 じゃあこうだ
rubyなら
〜1万行小規模
10万行中規模
100万行大規模
rubyなら
〜1万行小規模
10万行中規模
100万行大規模
298デフォルトの名無しさん
2014/01/16(木) 16:39:07.41 ペコーンwwwwwwwwwwwwww
299デフォルトの名無しさん
2014/01/16(木) 18:22:08.59 ロバみたいな奴だな
300デフォルトの名無しさん
2014/01/17(金) 02:26:52.79 場粉路「300wwwwwwwwwwwwwwwwwwwwww」
301デフォルトの名無しさん
2014/02/05(水) 04:47:08.99 型安全性ない限り不可能ですわ
302デフォルトの名無しさん
2014/02/05(水) 06:16:34.54 ああ、本物の動的型を知らないんだ。
型安全じゃない動的型しか使ったこと無いんだね。
型安全じゃない動的型しか使ったこと無いんだね。
303デフォルトの名無しさん
2014/02/05(水) 09:43:19.39 実用性のあるやつあったっけ?
ネタみたいな言語はいらないよ
ネタみたいな言語はいらないよ
304デフォルトの名無しさん
2014/02/05(水) 11:54:42.46 本物の動的型っていうのは
たとえばJavaやC++のことだよ。
型安全かつ動的。動的っていうのは
ポリモーフィズムのことを言う。
実際に使われるクラスが動的にしか決まらないから。
インターフェースは静的だけどね。
でも具象クラスが動的に決まるならば、
それは動的言語なんだよ。
たとえばJavaやC++のことだよ。
型安全かつ動的。動的っていうのは
ポリモーフィズムのことを言う。
実際に使われるクラスが動的にしか決まらないから。
インターフェースは静的だけどね。
でも具象クラスが動的に決まるならば、
それは動的言語なんだよ。
305デフォルトの名無しさん
2014/02/05(水) 12:09:06.82 などと意味不明なことを供述しており精神鑑定の結果を待って慎重に対応する予定です
306デフォルトの名無しさん
2014/02/05(水) 12:54:50.99 >>304
なんでゴミってこんなつまんねーことしか言えないんだ
なんでゴミってこんなつまんねーことしか言えないんだ
307デフォルトの名無しさん
2014/02/05(水) 12:58:26.58 ほっほっほ、反論は無しw
308デフォルトの名無しさん
2014/02/05(水) 13:12:01.88 >>307
死ねゴミ
死ねゴミ
309デフォルトの名無しさん
2014/02/07(金) 06:53:01.21 死ねゴミ
310デフォルトの名無しさん
2014/02/07(金) 16:38:35.68 ぁーーーやっぱり型推論やる感じの静的言語になるのかなぁ
色々考えたけどやっぱし無理かも
結局コンパイル時に出来る限り多くのエラー検出してくれた方が、
実行後に「気にしなきゃいけない事」が減ってくれるから
その差が理論的にどうやっても静的言語と動的言語じゃ埋まらない
それでも短いコード書く場合は動的言語のほうが良いのは事実だけど
完全に動的になってる言語ってどうも、eval上でコード動かしてるのと似たような気分になる事があるし
それでも何とかなるとしたら物量か
色々考えたけどやっぱし無理かも
結局コンパイル時に出来る限り多くのエラー検出してくれた方が、
実行後に「気にしなきゃいけない事」が減ってくれるから
その差が理論的にどうやっても静的言語と動的言語じゃ埋まらない
それでも短いコード書く場合は動的言語のほうが良いのは事実だけど
完全に動的になってる言語ってどうも、eval上でコード動かしてるのと似たような気分になる事があるし
それでも何とかなるとしたら物量か
311デフォルトの名無しさん
2014/02/07(金) 20:40:16.60 JSでとあるゲーム2,3年ぼちぼち作っててデータやView部抜きで1万行くらいをキープしてるけど
今までで一番長時間ハマったのは暗黙の型変換の挙動かな
確か正規表現で取り出した数字文字列を、==で数値と比較してる部分があって、その時点では問題なかったけど
後からそこ見て数値同士の比較かと思ってカッコつけて==を===を直してしまったんだよね
でもそれからは気をつけて、代入時に型と値の範囲を一気に確定させておく書き方を心がけるようにした
あくまで例えばだけど、文字列から少数を取り出すのなら、
m = +(str.match(/\d+\.\d+/)||[0])[0]
のような勢いで
こうやって一発で行数を減らしておくと全体の見通しがよくなって更に嵌りそうなことが減る
単行演算子とか用いると実装速度も微妙に上がるしね、asm.jsライクな記述すると
それで確かにその時は==となって欲しいケースが稀だったことや
その場所が予想外にViewに当たる場所だったこともあってかなり特定が大変だったけど、
逆に数値演算ばかりの結構複雑だと思うメインロジックでは難しい問題起こらなかったんだよね
評価関数の出来って動かしてみないと良くなったかどうかわからないってこともあるし、
エラーではなくアルゴリズム的に正しいかどうかの判断は動かしてなんぼで不満なかった
「大規模」ではなくて、「多いコード」だから動的が向いてないっていうのは違うんだろうね
例えばES6でclassシンタックスが入って大規模がよくなるっていうけど
ひたすら配列の操作をやるのだと関数型チックなので困らないし
まあ「大規模」っていうのは色んな要素が入ってると思うけど、そこをまず具体的に洗い出していったほうがいいかもね
その上でそれぞれに対して動的型でどうしていったらより良くなるか考えよう
今までで一番長時間ハマったのは暗黙の型変換の挙動かな
確か正規表現で取り出した数字文字列を、==で数値と比較してる部分があって、その時点では問題なかったけど
後からそこ見て数値同士の比較かと思ってカッコつけて==を===を直してしまったんだよね
でもそれからは気をつけて、代入時に型と値の範囲を一気に確定させておく書き方を心がけるようにした
あくまで例えばだけど、文字列から少数を取り出すのなら、
m = +(str.match(/\d+\.\d+/)||[0])[0]
のような勢いで
こうやって一発で行数を減らしておくと全体の見通しがよくなって更に嵌りそうなことが減る
単行演算子とか用いると実装速度も微妙に上がるしね、asm.jsライクな記述すると
それで確かにその時は==となって欲しいケースが稀だったことや
その場所が予想外にViewに当たる場所だったこともあってかなり特定が大変だったけど、
逆に数値演算ばかりの結構複雑だと思うメインロジックでは難しい問題起こらなかったんだよね
評価関数の出来って動かしてみないと良くなったかどうかわからないってこともあるし、
エラーではなくアルゴリズム的に正しいかどうかの判断は動かしてなんぼで不満なかった
「大規模」ではなくて、「多いコード」だから動的が向いてないっていうのは違うんだろうね
例えばES6でclassシンタックスが入って大規模がよくなるっていうけど
ひたすら配列の操作をやるのだと関数型チックなので困らないし
まあ「大規模」っていうのは色んな要素が入ってると思うけど、そこをまず具体的に洗い出していったほうがいいかもね
その上でそれぞれに対して動的型でどうしていったらより良くなるか考えよう
312デフォルトの名無しさん
2014/02/07(金) 22:01:54.81 ==と===の違いは面倒だから使うなって、
オライリーから出ている薄い本の何処にでも書かれてるだろ
オライリーから出ている薄い本の何処にでも書かれてるだろ
313デフォルトの名無しさん
2014/02/07(金) 22:03:36.88 テストコードやCIしながら書くもんじゃないのか
314デフォルトの名無しさん
2014/02/07(金) 22:04:48.68 静的言語ならバグが含まれないってのが、そもそもの幻想
315デフォルトの名無しさん
2014/02/07(金) 22:13:41.93 静的言語でバグを作り出さないなら、JUnitなんて出てくるわけがない
いちいち変数定義するなら、それ無しでテストコードまで書いた方が効率良い
という発想。(テスト自体はSmalltalkからJavaへ輸入されてた気がする)
いちいち変数定義するなら、それ無しでテストコードまで書いた方が効率良い
という発想。(テスト自体はSmalltalkからJavaへ輸入されてた気がする)
316デフォルトの名無しさん
2014/02/08(土) 01:39:35.92 ウェブで言うと、昔は専用サーバは高価でシェルを使えるのは希だったから、スクリプト言語の方が動かしやすかったんだよ
プログラム自体も単純なものが多かったから、タイプセーフじゃなくても問題なかった
プログラム自体も単純なものが多かったから、タイプセーフじゃなくても問題なかった
317デフォルトの名無しさん
2014/02/08(土) 06:00:40.97 >>312
それは今回の件とは関係ない
例え最初から===にしてたとしても、前述したように稀かつゲームを進めないと出てこない問題だったから気付けなかった
むしろこういうケースがあるから==の方を使ったほうが殆どの場合でいいと思ってる
まあ、言いたいことはそういうことじゃない
今回テストは作りたて関数やバグが出たら使い捨てくらいの軽い気持ちで作るという感じだったが
よほど労力(とテストにかかる時間)をかけていたとしても発見できたかは微妙だった
今回のケースは自分はもっとメタ的に解決すべきだったと思う
例えば演算子オーバーロードができればそういったハマりやすいポイントでワーニングが出せる
それだけじゃなくて統計をとって最適化にもきっと活かせる
(例えば結果がSMIのようなJITエンジンがより最適化してくれる範囲内かどうか等)
他にもProxyとかメタ的やハックでの「動かしながらの」分析によるテストが
特に緩い動的言語での大きな開発でかなり有効なんじゃないかと自分は思ってきてる
ある程度はデバッガの役割だろうが、例えば条件付きブレークポイントみたいに
汎用的に細かいことがしたければ結局コードを書くことになるので、しかたない
でもそういったことが十分できるのならば自分は開発になんら不満、不安を感じない
また今回は流れでテストするのにデータのObservingが役に立ってる
各処理関数に全く関わる必要もないしテストも全く省けてる
目でのチェックと同時に比較的低負荷でできるのがかなり効率がいい
自分はES6,7などこれからのJSにはそういう部分に結構期待してる
それは今回の件とは関係ない
例え最初から===にしてたとしても、前述したように稀かつゲームを進めないと出てこない問題だったから気付けなかった
むしろこういうケースがあるから==の方を使ったほうが殆どの場合でいいと思ってる
まあ、言いたいことはそういうことじゃない
今回テストは作りたて関数やバグが出たら使い捨てくらいの軽い気持ちで作るという感じだったが
よほど労力(とテストにかかる時間)をかけていたとしても発見できたかは微妙だった
今回のケースは自分はもっとメタ的に解決すべきだったと思う
例えば演算子オーバーロードができればそういったハマりやすいポイントでワーニングが出せる
それだけじゃなくて統計をとって最適化にもきっと活かせる
(例えば結果がSMIのようなJITエンジンがより最適化してくれる範囲内かどうか等)
他にもProxyとかメタ的やハックでの「動かしながらの」分析によるテストが
特に緩い動的言語での大きな開発でかなり有効なんじゃないかと自分は思ってきてる
ある程度はデバッガの役割だろうが、例えば条件付きブレークポイントみたいに
汎用的に細かいことがしたければ結局コードを書くことになるので、しかたない
でもそういったことが十分できるのならば自分は開発になんら不満、不安を感じない
また今回は流れでテストするのにデータのObservingが役に立ってる
各処理関数に全く関わる必要もないしテストも全く省けてる
目でのチェックと同時に比較的低負荷でできるのがかなり効率がいい
自分はES6,7などこれからのJSにはそういう部分に結構期待してる
318デフォルトの名無しさん
2014/02/08(土) 08:08:08.34319デフォルトの名無しさん
2014/02/08(土) 11:30:21.22 オライリーのどの辺が反面教師なの?
あなたは国内出版社の方?
あなたは国内出版社の方?
320デフォルトの名無しさん
2014/02/08(土) 13:01:18.60 基本的にオライリーはゴミな上に一回本出した後で
売れ残りすぎてるから2版3版って更新されんのが遅すぎて
載ってる情報が古すぎるケースが多すぎ
あれ読んでる奴はゴミ
売れ残りすぎてるから2版3版って更新されんのが遅すぎて
載ってる情報が古すぎるケースが多すぎ
あれ読んでる奴はゴミ
321デフォルトの名無しさん
2014/02/08(土) 13:07:19.15 オライリーは言語によって出来が違いすぎる
322デフォルトの名無しさん
2014/02/08(土) 13:07:59.08 英語版はやっぱり出来がいいよね。
323デフォルトの名無しさん
2014/02/08(土) 13:19:36.72 本毎に差がありすぎるんだよな
あと翻訳者
日本人が書いてゴミなRuby本もあったな
あと翻訳者
日本人が書いてゴミなRuby本もあったな
324デフォルトの名無しさん
2014/02/08(土) 13:28:19.75 書店にいって適当に本の後ろの発行日を見たらいいよ
オライリーは5年とか10年ものとか平気でおかれてる
売れてないからそうなってる
初心者チックな本でも、せいぜい1〜2年以内に出た新しい本買ったほうが絶対良い
あとはネットで調べりゃいいだけ
オライリーは5年とか10年ものとか平気でおかれてる
売れてないからそうなってる
初心者チックな本でも、せいぜい1〜2年以内に出た新しい本買ったほうが絶対良い
あとはネットで調べりゃいいだけ
325デフォルトの名無しさん
2014/02/08(土) 13:33:40.49 オライリーは新しくないとダメなものは向かない
新しい情報はネットで集めた方がいい
適当な他の本買うぐらいならオライリーのがマシなことが多いな
それよか、ピアソンどうなるんだ?
新しい情報はネットで集めた方がいい
適当な他の本買うぐらいならオライリーのがマシなことが多いな
それよか、ピアソンどうなるんだ?
326デフォルトの名無しさん
2014/02/08(土) 13:40:16.96 オライリーはゴミw
327デフォルトの名無しさん
2014/02/08(土) 13:42:03.17 1年2年で入れ替わるくらい変化が激しい物ならそれこそ本なんて遅すぎて
いらないってなるだろうに。
いらないってなるだろうに。
328デフォルトの名無しさん
2014/02/08(土) 13:56:41.14 ITってそういう分野
ハードウェア絡むような場所だけだよ
5〜10年昔の知識が通用するなんて
ハードウェア絡むような場所だけだよ
5〜10年昔の知識が通用するなんて
329デフォルトの名無しさん
2014/02/08(土) 14:00:39.74 もうオライリーみたいな重厚長大な本の時代じゃないね
昔はラクダ本とかボロボロになるまで読んだけどね
昔はラクダ本とかボロボロになるまで読んだけどね
330デフォルトの名無しさん
2014/02/08(土) 14:21:34.64 ゴミw
331デフォルトの名無しさん
2014/02/08(土) 14:23:39.19 ネットの情報は断片的に拾い読みする分には良いが
まとまった情報って本で無いとねえ。
って言うのは古いかw
まとまった情報って本で無いとねえ。
って言うのは古いかw
332デフォルトの名無しさん
2014/02/08(土) 14:31:47.88 リファレンスとかは完全に ネット > 本 になった
333デフォルトの名無しさん
2014/02/08(土) 14:57:45.25 では、ハズレの本を出さない出版社を発表しちゃってください。
334デフォルトの名無しさん
2014/02/08(土) 15:21:13.00 >>328
OSやコンパイラの基礎的な知識がここ5〜10年ほどで全部置き換わったとでも?
何か新しいツールやライブラリなんかも利用期間が長ければ長いほど後方互換を
考えて思想的な部分を変えることが出来なくなってるよ?
基礎的な知識がない人、表面だけなぞってる人は全く変わって通用しなくなると
感じてんるんだろうけど、そんなことは無いんだけどね。
OSやコンパイラの基礎的な知識がここ5〜10年ほどで全部置き換わったとでも?
何か新しいツールやライブラリなんかも利用期間が長ければ長いほど後方互換を
考えて思想的な部分を変えることが出来なくなってるよ?
基礎的な知識がない人、表面だけなぞってる人は全く変わって通用しなくなると
感じてんるんだろうけど、そんなことは無いんだけどね。
335デフォルトの名無しさん
2014/02/08(土) 15:24:34.62 つ電子書籍
すっかりぐだぐだのイメージが広まりつつあるがw
すっかりぐだぐだのイメージが広まりつつあるがw
336デフォルトの名無しさん
2014/02/08(土) 15:26:17.39 ここ15年くらい何も進歩してない
モバイルへのシフトが見えるくらい
モバイルへのシフトが見えるくらい
337デフォルトの名無しさん
2014/02/08(土) 15:34:56.49 結局は、ノイマン型のコンピュータが登場して以来何も進歩してないんだよ
338デフォルトの名無しさん
2014/02/08(土) 15:55:37.52 話でかくなりすぎw
339デフォルトの名無しさん
2014/02/08(土) 16:36:22.62 プログラミング言語だけ見ても、PHPでもRubyでもC#でもJavaでもこの10年で大きく変わってる
ライブラリやミドルウェアはもっと変わってる
これだけラピッドリリースが当たり前の時代、オライリーは本棚に並べて自己満足するぐらいの価値しかない
ライブラリやミドルウェアはもっと変わってる
これだけラピッドリリースが当たり前の時代、オライリーは本棚に並べて自己満足するぐらいの価値しかない
340デフォルトの名無しさん
2014/02/08(土) 17:06:39.19341デフォルトの名無しさん
2014/02/08(土) 17:08:41.77 Ajax でブラウザとJSの地位が大幅に向上したというのは進歩かもしれない
それ以外は驚くほど何も変わってない
それ以外は驚くほど何も変わってない
342デフォルトの名無しさん
2014/02/08(土) 21:58:29.94 JSに関してはかなり変わってきてると思う
00年代後半くらいに出た本はまだコーディングルールもままならなかったJSに対して
JSの安全で多言語との相異があまりない部分だけを使うという、かなり厳しい立場なものが多い
そしてそれ以降にでた本もそれを踏襲しているから同じ
ES3まではクラスベースの皮をすっぽり被ったプロトタイプベース言語だったからしかたがない
ゲッターすらも定義できないような未熟な言語だったのは確か
でもES5,ES6ときて例えばブロック文中の関数宣言の振る舞いの問題とか、
根底の不安定さがかなり解消されてきてる
そしてES6ではクラスシンタックスが入ったり、ミキシン等のサポートや、
プライベートっぽくもできるSymbolの導入、また何と言っても今までは
クラスベースの皮に隠れてたプロトタイプが表面にでたお陰でかなり変わってる
Promiseとか、関数型の方向性も強化されてきていて、
マルチパラダイム言語としてかなり磨きがかかって底上げされている
他にもモジュールやブロックスコープとか、書ききれない
コーディングルールの面でも、最近ではgoodpartsを書いたグーグル内、
例えばV8グループ内でもセミコロンフリーのソースがコミットされたりもしている
JSに関しては、何がいいのかは(ブラウザ間の差もあるし)その時その時で考えていくべき
JSも成熟してきて、JSerも成熟してきてるから、無闇矢鱈に縛る必要がなくなってきている
00年代後半くらいに出た本はまだコーディングルールもままならなかったJSに対して
JSの安全で多言語との相異があまりない部分だけを使うという、かなり厳しい立場なものが多い
そしてそれ以降にでた本もそれを踏襲しているから同じ
ES3まではクラスベースの皮をすっぽり被ったプロトタイプベース言語だったからしかたがない
ゲッターすらも定義できないような未熟な言語だったのは確か
でもES5,ES6ときて例えばブロック文中の関数宣言の振る舞いの問題とか、
根底の不安定さがかなり解消されてきてる
そしてES6ではクラスシンタックスが入ったり、ミキシン等のサポートや、
プライベートっぽくもできるSymbolの導入、また何と言っても今までは
クラスベースの皮に隠れてたプロトタイプが表面にでたお陰でかなり変わってる
Promiseとか、関数型の方向性も強化されてきていて、
マルチパラダイム言語としてかなり磨きがかかって底上げされている
他にもモジュールやブロックスコープとか、書ききれない
コーディングルールの面でも、最近ではgoodpartsを書いたグーグル内、
例えばV8グループ内でもセミコロンフリーのソースがコミットされたりもしている
JSに関しては、何がいいのかは(ブラウザ間の差もあるし)その時その時で考えていくべき
JSも成熟してきて、JSerも成熟してきてるから、無闇矢鱈に縛る必要がなくなってきている
343デフォルトの名無しさん
2014/02/09(日) 00:23:11.54344デフォルトの名無しさん
2014/02/09(日) 04:44:50.85345デフォルトの名無しさん
2014/02/09(日) 10:36:31.60 > 10年前の本でも読んでると良いよ
2004年の本ですか? そりゃ読むでしょうよw
2004年の本ですか? そりゃ読むでしょうよw
346デフォルトの名無しさん
2014/02/09(日) 12:19:57.73 10年前のApacheの本とかBindとかSendmailとか
347デフォルトの名無しさん
2014/02/09(日) 21:59:17.96 JavaScriptは約5年の間にES3→ES6で仕様書は3倍になったし、
もっと言えばHTML5との絡みで世界が日に日に拡大してるから仕方ないね。
そのとき常識でも、半年経つと状況がガラッと変わった照りするからね。
例えば今はアニメーションはライブラリの手を借りないと困難だって認識だろうけど、
確か今年の6月くらいににAnimationsAPIが勧告されるからね。
まあフラグONにすればもう一部は使えるんだけど、そもそも存在を知る人も少なそう。
もうちょい先の話だとServiceWorkerとかね。
スクリプト言語はAPIあってのものだから大変だね。
もっと言えばHTML5との絡みで世界が日に日に拡大してるから仕方ないね。
そのとき常識でも、半年経つと状況がガラッと変わった照りするからね。
例えば今はアニメーションはライブラリの手を借りないと困難だって認識だろうけど、
確か今年の6月くらいににAnimationsAPIが勧告されるからね。
まあフラグONにすればもう一部は使えるんだけど、そもそも存在を知る人も少なそう。
もうちょい先の話だとServiceWorkerとかね。
スクリプト言語はAPIあってのものだから大変だね。
348デフォルトの名無しさん
2014/02/10(月) 09:34:39.88 情報が古いと分かってる本読んでも得るもの何もないからな
信頼できない本読んで間違って覚えてそれで良いと勘違いしてる状況のほうが厄介な問題起こりそう
ゴミ
信頼できない本読んで間違って覚えてそれで良いと勘違いしてる状況のほうが厄介な問題起こりそう
ゴミ
349デフォルトの名無しさん
2014/02/10(月) 14:01:59.53 過去の仕様が根こそぎ変化するわけじゃないんだから、
古くなってる部分だけ調べりゃ良いだろ
古くなってる部分だけ調べりゃ良いだろ
350デフォルトの名無しさん
2014/02/10(月) 14:43:51.08 古いものの方が
肥大した無駄機能もなく
本質的な部分に絞りこまれていることが多い
ただし破壊的変更を繰り返してフラフラしている駄ツールには当てはまらないかもしれない
肥大した無駄機能もなく
本質的な部分に絞りこまれていることが多い
ただし破壊的変更を繰り返してフラフラしている駄ツールには当てはまらないかもしれない
351デフォルトの名無しさん
2014/02/10(月) 14:48:45.54 古い本を読んでる最中に古い情報(間違った情報)と新しい情報(正しい情報)の区別をどうやってつけるんだか
ゴミかよ
ゴミかよ
352デフォルトの名無しさん
2014/02/10(月) 14:49:39.61 ゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミwwwwwwwwwwwwwwwwwwwwwwwwwwww
353デフォルトの名無しさん
2014/02/10(月) 16:10:40.42 問題が生じてから調べりゃ良いだろ
354デフォルトの名無しさん
2014/02/10(月) 16:35:30.36 損害被ってから調べるわけか
新しい本がないならまだしも
新しい本があるにもかかわらず古いほう読んで間違った知識身に付けたがるゴミってペチパー以上に理解できない存在だな
死ねゴミ
新しい本がないならまだしも
新しい本があるにもかかわらず古いほう読んで間違った知識身に付けたがるゴミってペチパー以上に理解できない存在だな
死ねゴミ
355デフォルトの名無しさん
2014/02/10(月) 17:21:58.51 学んだことが数年で間違った知識と化すのならばその技術・ツールそのものが害なのだ
356デフォルトの名無しさん
2014/02/10(月) 18:40:07.47 IT分野に来ないほうが良いな
357デフォルトの名無しさん
2014/02/10(月) 18:45:28.28 RubyやRailsが顕著だけど、それ以外のプロダクトも互換性は早く捨ててイノベーションする動きになってる
358デフォルトの名無しさん
2014/02/10(月) 21:34:55.60 互換性と情報の古くなりやすさは違う気がする
JavaScriptなんて顕著な例だし
むしろ古い情報が中途半端に有効なことが問題を大きくしてる
まあ、本っていうのはやっぱ向いてる分野が限られてると思う。
JavaScriptなんて顕著な例だし
むしろ古い情報が中途半端に有効なことが問題を大きくしてる
まあ、本っていうのはやっぱ向いてる分野が限られてると思う。
359デフォルトの名無しさん
2014/02/10(月) 23:11:20.52 言語機能もライブラリも互換性ぶったぎってるから、本の通りに書いても全く動かない
依存関係があるから、部分的に古いライブラリ使おうと思っても一筋縄じゃ行かない
そんなの自力で解決出来る知識あるなら、そもそも本なんか不要
依存関係があるから、部分的に古いライブラリ使おうと思っても一筋縄じゃ行かない
そんなの自力で解決出来る知識あるなら、そもそも本なんか不要
360デフォルトの名無しさん
2014/02/11(火) 01:14:27.60 誰が
何のために
変えているのか?
何のために
変えているのか?
361デフォルトの名無しさん
2014/02/11(火) 07:53:46.12 コンパイルエラーなんかでて、動かないならまだ良いけど
「動くけど動作が違います^^;」
っていうのが最もヤバい
ruby1.8→1.9のヤバさは想像を絶する
Ostruct、クラス変数、シャドウイング使いまくってた人たちってどうなったの
「動くけど動作が違います^^;」
っていうのが最もヤバい
ruby1.8→1.9のヤバさは想像を絶する
Ostruct、クラス変数、シャドウイング使いまくってた人たちってどうなったの
362デフォルトの名無しさん
2014/02/11(火) 07:57:41.43 中途半端に途中まで正しく動くなんてまさに無能な働き者
仕事をしないならしないで良いのに、
ちょっとした期待をさせるからそれに頼ってみるとやはり失敗するという
船乗りとか、登山家が、余計な足手まといは連れて行かないのと同じ
プロだけで行くなら良いのに素人が一緒に来るとプロまで道連れになるんだ
人間レベルで
「動くけど動作が違います^^;」
は、困る
仕事をしないならしないで良いのに、
ちょっとした期待をさせるからそれに頼ってみるとやはり失敗するという
船乗りとか、登山家が、余計な足手まといは連れて行かないのと同じ
プロだけで行くなら良いのに素人が一緒に来るとプロまで道連れになるんだ
人間レベルで
「動くけど動作が違います^^;」
は、困る
363デフォルトの名無しさん
2014/02/11(火) 09:06:04.31 育成しろ
おまえの役目だぞ
おまえの役目だぞ
364デフォルトの名無しさん
2014/02/11(火) 10:10:44.65 >>325,349
死ねゴミw
死ねゴミw
365デフォルトの名無しさん
2014/09/19(金) 11:11:48.63ID:uUn/9tg4 サーバサイドではNode.jsからJavaやGoへの切り替えが進み
クライアントサイドではTypeScriptを導入した連中が喜びの声を上げている、
もちろんSwiftもある
JavaScriptもPythonも型アノーテーション導入を検討しているし、Rubyもこれだ
https://twitter.com/miyohide/status/512768555385769986
> Matz「最近の言語(ScalaやGoやDartなど)はみんな静的な型を持っていて、
> ちょっとそれは悔しいので、Rubyでも導入を考えたい。」
情勢から見て、もはや静的型の勝利、動的型はやはり駄目だったよということで決着がついただろう。
とりわけ動的型の経験しかなかったウェブ屋やTDD厨がちょっと頭おかしかった。
動的型はゼロ年代の一時的な熱狂だったということで終わるのではないか。
冷静に考えてとにかくメリットがねーもん。まるっきり。
Real World Academia: Unit testing isn't enough. You need static typing too.
http://evanfarrer.blogspot.jp/2012/06/unit-testing-isnt-enough-you-need.html
> 「ユニットテストだけでは不十分だ。静的型も必要だ」
ってことすな。
クライアントサイドではTypeScriptを導入した連中が喜びの声を上げている、
もちろんSwiftもある
JavaScriptもPythonも型アノーテーション導入を検討しているし、Rubyもこれだ
https://twitter.com/miyohide/status/512768555385769986
> Matz「最近の言語(ScalaやGoやDartなど)はみんな静的な型を持っていて、
> ちょっとそれは悔しいので、Rubyでも導入を考えたい。」
情勢から見て、もはや静的型の勝利、動的型はやはり駄目だったよということで決着がついただろう。
とりわけ動的型の経験しかなかったウェブ屋やTDD厨がちょっと頭おかしかった。
動的型はゼロ年代の一時的な熱狂だったということで終わるのではないか。
冷静に考えてとにかくメリットがねーもん。まるっきり。
Real World Academia: Unit testing isn't enough. You need static typing too.
http://evanfarrer.blogspot.jp/2012/06/unit-testing-isnt-enough-you-need.html
> 「ユニットテストだけでは不十分だ。静的型も必要だ」
ってことすな。
366デフォルトの名無しさん
2014/09/19(金) 13:53:26.63ID:Xfkvubm0 この業界は一時的な熱狂が多すぎるよね
367デフォルトの名無しさん
2014/09/19(金) 16:44:39.68ID:3WQN+no2368デフォルトの名無しさん
2014/09/20(土) 09:47:56.33ID:b8OT/FfJ 型チェックというのも、テストの全てではないが
テストの一部なんだよ。
それが原因のバグもあるわけなんだから。
たとえそれが一瞬で修正できることだとしても
その為に別の作業中にバグ見つけて
割り込みで修正するとか思考の流れを途切れさせることはよくある話。
テストの一部なんだよ。
それが原因のバグもあるわけなんだから。
たとえそれが一瞬で修正できることだとしても
その為に別の作業中にバグ見つけて
割り込みで修正するとか思考の流れを途切れさせることはよくある話。
369デフォルトの名無しさん
2014/09/30(火) 07:23:04.54ID:2CeH2hLD >>366
幸か不幸か、ソフトウェアというのは一時的な熱狂だけで「動くもの」を作れてしまう分野だからだろうね
幸か不幸か、ソフトウェアというのは一時的な熱狂だけで「動くもの」を作れてしまう分野だからだろうね
370デフォルトの名無しさん
2014/10/11(土) 23:13:05.47ID:bgxomZ9f Rubyで開発やってるけど、
unitテストの設計と項目作成だけで
3人で三週間かかって、マジで倒れそうだわ
来週からテストだけど、かなり辞めたい気分
unitテストの設計と項目作成だけで
3人で三週間かかって、マジで倒れそうだわ
来週からテストだけど、かなり辞めたい気分
371デフォルトの名無しさん
2014/10/12(日) 07:22:26.20ID:5ixfa8wz372デフォルトの名無しさん
2014/10/12(日) 07:29:16.53ID:jjrAIsW+ 大変な所=メンテナンスだから、
今後ずっと大変な状態が続くよ、
Rubyをやめるのが一番の早道だな。
今後ずっと大変な状態が続くよ、
Rubyをやめるのが一番の早道だな。
373デフォルトの名無しさん
2014/10/12(日) 07:36:17.74ID:gqs4tO4e テストすらロクにしない>>372はどんな言語で書いてもバグだらけw
374デフォルトの名無しさん
2014/10/12(日) 09:08:57.89ID:5ixfa8wz375デフォルトの名無しさん
2014/10/12(日) 10:05:01.80ID:DxGoFyW9 >>371
UNITテストやるのもかなり大変だろ
テストの途中でメソッドが増えたり減ったりしてそのたびにテスト項目修正して
ログから障害の原因が分からない場合はログを修正して
RUNITのアサートも修正して、テスト項目も修正し無いと行けないし、、
考えただけでだるいわ
UNITテストやるのもかなり大変だろ
テストの途中でメソッドが増えたり減ったりしてそのたびにテスト項目修正して
ログから障害の原因が分からない場合はログを修正して
RUNITのアサートも修正して、テスト項目も修正し無いと行けないし、、
考えただけでだるいわ
376デフォルトの名無しさん
2014/10/12(日) 13:06:01.13ID:5ixfa8wz377デフォルトの名無しさん
2014/10/12(日) 17:09:28.84ID:gqs4tO4e >>375
ルビーの勉強がんばってください、入門者さんw
ルビーの勉強がんばってください、入門者さんw
378デフォルトの名無しさん
2014/10/16(木) 00:02:19.53ID:Ju1r+RJJ 動物言語に見えた
379デフォルトの名無しさん
2014/10/16(木) 07:57:26.33ID:Sk/7zxTc 面倒なのは全部ほかにまわせば確かに楽になるかもな
380デフォルトの名無しさん
2014/10/18(土) 12:19:07.94ID:xyIEV5M1 巷に出回る仕事術の基本
381デフォルトの名無しさん
2014/11/24(月) 00:10:36.26ID:NFvfX/bb 動的言語ってリファレンスが読みにくくね?
みんなどうしてんの?
みんなどうしてんの?
382デフォルトの名無しさん
2014/11/24(月) 00:12:03.59ID:LP7Sk3Ho 暗記
383デフォルトの名無しさん
2014/11/24(月) 00:16:50.33ID:PX1MFVrm そんなん言語によるだろ
384デフォルトの名無しさん
2014/11/24(月) 09:52:02.93ID:bceL07z7 >>381
具体的にどの言語のリファレンスが読みにくいと?
具体的にどの言語のリファレンスが読みにくいと?
385デフォルトの名無しさん
2014/11/24(月) 10:02:48.56ID:XLIBB3hZ pythonしか知らんが、pythonはかなりドキュメント類がしっかりしてると思うけどな。
ただまあ、マイナー言語、ライブラリは動的静的カンケーなく、結局ソースを読むことにはなると思う。
ただまあ、マイナー言語、ライブラリは動的静的カンケーなく、結局ソースを読むことにはなると思う。
386デフォルトの名無しさん
2014/11/24(月) 10:33:25.11ID:vb0rebZq 定番アプリのソースで似たようなことしてるものを探して真似る
うっかりソースを読んで入り込むとあとで変更された時にヤラれる
うっかりソースを読んで入り込むとあとで変更された時にヤラれる
387デフォルトの名無しさん
2014/11/24(月) 15:01:36.25ID:kcRDK3+j PHPとPythonのドキュメントはしっかりしてるけど
RubyとSmalltalkのはゴミだったな
RubyとSmalltalkのはゴミだったな
388デフォルトの名無しさん
2014/11/24(月) 17:34:32.45ID:XLIBB3hZ smalltalkはブラウザ開いて
オブジェクトと対話しながらプログラミングしていくスタイルだから
アレで良いのだ
と、多くのスモールトーカー様は思ってる
オブジェクトと対話しながらプログラミングしていくスタイルだから
アレで良いのだ
と、多くのスモールトーカー様は思ってる
389デフォルトの名無しさん
2014/11/24(月) 18:25:46.58ID:2QNpXJ+6 動的言語ではないがJavaのAPIドキュメントがしっかりしすぎてる。
390デフォルトの名無しさん
2014/11/24(月) 18:41:49.16ID:atmNtLqz Smalltalkのドキュメントって何のことだろう?
391デフォルトの名無しさん
2014/11/24(月) 19:12:45.95ID:NFvfX/bb pythonのopencvとかnumpyのリファレンス見てみたんだけど
なんの型を入れるとなんの型が帰ってくるのか明確に書いてないからサンプル見ないと分かんない
なんの型を入れるとなんの型が帰ってくるのか明確に書いてないからサンプル見ないと分かんない
392デフォルトの名無しさん
2014/11/24(月) 19:35:00.93ID:vb0rebZq その辺はネーミングセンスでカバーするという思想だろうけど
Cライブラリのラッパーとかだと全く通用しなくなるな
Cライブラリのラッパーとかだと全く通用しなくなるな
393デフォルトの名無しさん
2014/11/24(月) 20:12:08.30ID:2QNpXJ+6 >>391
ipythonで?して書いてなかったらソース読んでる。
ipythonで?して書いてなかったらソース読んでる。
394デフォルトの名無しさん
2014/11/24(月) 20:25:30.45ID:PX1MFVrm vimでKを押してdocumentがなかったら
\dを押して定義元のソースコードにジャンプしてる
\dを押して定義元のソースコードにジャンプしてる
395デフォルトの名無しさん
2014/11/25(火) 00:06:15.89ID:pX8dGPkN 下みたいコードのエラーを実行前に検出できるlint系ツールが存在する
Pythonを動的言語で括って良いものだろうか
def foo(x):
def f(g):
return g() + x
return f
def bar():
foo(1)(lambda: 'abc')
Pythonを動的言語で括って良いものだろうか
def foo(x):
def f(g):
return g() + x
return f
def bar():
foo(1)(lambda: 'abc')
396デフォルトの名無しさん
2014/11/25(火) 05:48:58.67ID:0npMaebU 最近追ってなかったけど
pythonは型アノテーション導入の話題もあるのな。
pythonは型アノテーション導入の話題もあるのな。
397デフォルトの名無しさん
2014/11/25(火) 20:38:28.15ID:NsP7IFUt やっぱ大規模開発には静的型があった方が
良いんだろうな
良いんだろうな
398デフォルトの名無しさん
2014/11/25(火) 23:51:15.09ID:n1duvf0w >>397
typoですら動かすまで見つけれないのは地味にストレスだからな。
typoですら動かすまで見つけれないのは地味にストレスだからな。
399デフォルトの名無しさん
2014/11/26(水) 04:22:00.60ID:zFnj+88g400デフォルトの名無しさん
2014/11/26(水) 05:14:33.37ID:iOq+FlWm >>399
動的言語は、typoを実行前に発見できないほうが多いよ。
発見できないパターンはこれ
obj.f00 (fooの間違い)
オブジェクトのメソッドのメソッド名を間違えた時
ほぼ全ての動的言語は、実行するまでtypoを発見できない。
なぜなら後で動的にメソッドを追加するかもしれないから
実行するまでわからない。
動的言語は、typoを実行前に発見できないほうが多いよ。
発見できないパターンはこれ
obj.f00 (fooの間違い)
オブジェクトのメソッドのメソッド名を間違えた時
ほぼ全ての動的言語は、実行するまでtypoを発見できない。
なぜなら後で動的にメソッドを追加するかもしれないから
実行するまでわからない。
401デフォルトの名無しさん
2014/11/26(水) 05:24:10.98ID:iOq+FlWm 動的言語だとtypoがわかると言っても
ローカル変数程度なんだよね。
そんな近くにある目で見てもすぐわかるようなものより
ファイルをまたいだりしている遠くにあるコードの
typoを知りたいんだが。
ローカル変数程度なんだよね。
そんな近くにある目で見てもすぐわかるようなものより
ファイルをまたいだりしている遠くにあるコードの
typoを知りたいんだが。
402デフォルトの名無しさん
2014/11/26(水) 08:52:45.01ID:IUNEYOWi403デフォルトの名無しさん
2014/11/26(水) 10:27:57.07ID:lFXPwW0W >>400
その理屈はなんかおかしいぞ。
後で動的にメソッドが追加されるかもしれないから
typoかどうか実行時まで*処理系側では*判断できない
というだけの話。
書いている人間様はそれがtypoかどうかは容易に判断できる(気づきさえすれば)。
だから、パーズ・コンパイル時に単に未定義だと文字通りワーニングを出せばいい話で、
実際そういう機能を持つ処理系やIDEは1980年代のSmalltalkから普通にある。
typoでたまたま他の既存のメソッド名とかぶってしまった場合に、
型でtypoかどうか判断可能という主張ならまだわかる。
その場合でも、型まで一致していたら静的型言語でもお手上げだ。
その理屈はなんかおかしいぞ。
後で動的にメソッドが追加されるかもしれないから
typoかどうか実行時まで*処理系側では*判断できない
というだけの話。
書いている人間様はそれがtypoかどうかは容易に判断できる(気づきさえすれば)。
だから、パーズ・コンパイル時に単に未定義だと文字通りワーニングを出せばいい話で、
実際そういう機能を持つ処理系やIDEは1980年代のSmalltalkから普通にある。
typoでたまたま他の既存のメソッド名とかぶってしまった場合に、
型でtypoかどうか判断可能という主張ならまだわかる。
その場合でも、型まで一致していたら静的型言語でもお手上げだ。
404デフォルトの名無しさん
2014/11/26(水) 10:37:02.67ID:IUNEYOWi typoっつーか、メソッド名を補完してたら
ウッカリ同じprefixの別のメソッド呼んじゃってた事はあるよ
でも、その間違ったメソッドが引数の型や数、戻り値の型まで一致してたことは一度も無かった
ウッカリ同じprefixの別のメソッド呼んじゃってた事はあるよ
でも、その間違ったメソッドが引数の型や数、戻り値の型まで一致してたことは一度も無かった
405デフォルトの名無しさん
2014/11/26(水) 12:07:39.14ID:lFXPwW0W >>404
補完なら、ふつう型が一致してなかったらそもそも候補に出てこないし、
まして「呼んじゃって」(つまりコンパイルが通って実行される)なんてことは
ウッカリだろうが何だろうが基本ないことだと思うけど?
補完なら、ふつう型が一致してなかったらそもそも候補に出てこないし、
まして「呼んじゃって」(つまりコンパイルが通って実行される)なんてことは
ウッカリだろうが何だろうが基本ないことだと思うけど?
406デフォルトの名無しさん
2014/11/26(水) 12:29:05.12ID:jMc4tHhg407デフォルトの名無しさん
2014/11/26(水) 12:35:38.39ID:lFXPwW0W408デフォルトの名無しさん
2014/11/26(水) 12:59:25.21ID:jMc4tHhg409デフォルトの名無しさん
2014/11/26(水) 17:49:47.93ID:jGVOTHDh rubyのto_sとか?
410デフォルトの名無しさん
2014/11/26(水) 20:45:29.26ID:zFnj+88g >>408
へー、どの動的型付言語が言語仕様で「型」という概念が定義されているんだい?
へー、どの動的型付言語が言語仕様で「型」という概念が定義されているんだい?
411デフォルトの名無しさん
2014/11/26(水) 20:48:18.16ID:zFnj+88g 動的型付言語を使っていて型が違うのにとか型で補完できればとか言ってる人は動的型付言語の初心者。
動的型付言語を単に型宣言しない静的型付言語として使っているだけ。
動的型付言語を単に型宣言しない静的型付言語として使っているだけ。
412デフォルトの名無しさん
2014/11/26(水) 22:06:07.76ID:jGVOTHDh 初心者
413デフォルトの名無しさん
2014/11/26(水) 22:45:02.52ID:A6eFHCKj414デフォルトの名無しさん
2014/11/26(水) 22:49:59.27ID:HWidBYzd >>410
a = 1
a = "a"
a = true
一行目のaの値は数値型で二行目で文字型に変り三行目でBoolean型に
なるってことで型が無いように見えて値にはちゃんと型があると言いたいんでしょ?
a = 1
a = "a"
a = true
一行目のaの値は数値型で二行目で文字型に変り三行目でBoolean型に
なるってことで型が無いように見えて値にはちゃんと型があると言いたいんでしょ?
415デフォルトの名無しさん
2014/11/26(水) 22:52:09.61ID:HWidBYzd 柔軟だがバグの元にはなりそうだ
416デフォルトの名無しさん
2014/11/26(水) 23:01:03.31ID:gCulqy1V 重要なのは値に型があることではなくて変数に型があること。
変数に型があるからこそ、その変数の型のメソッドは何かがわかる。
変数に型があるからこそ、その変数の型のメソッドは何かがわかる。
417デフォルトの名無しさん
2014/11/26(水) 23:03:26.44ID:gCulqy1V 変数はコードに書く。コードに書くということは
静的にわかる。(変数に型がある場合)
値に型があっても、実行時にならないとわからない。
変数に入る値はいろんな型がありえるから
値に型があるだけじゃ、typoを発見することは出来ない。
いい加減「値に型がある」を反論の材料にするのはやめてくれ。
反論になってないから
静的にわかる。(変数に型がある場合)
値に型があっても、実行時にならないとわからない。
変数に入る値はいろんな型がありえるから
値に型があるだけじゃ、typoを発見することは出来ない。
いい加減「値に型がある」を反論の材料にするのはやめてくれ。
反論になってないから
418デフォルトの名無しさん
2014/11/26(水) 23:10:00.48ID:b8NKrcQ+ 変数posがあってこれが座標を表わしてるものだとしたら
list型で(x y)だったり構造体でxとyのフィールドを持ってたりy*w+xの整数だったり
色んな表現が出来るから柔軟という利点があってプロトタイプに向いてるってことじゃないの
list型で(x y)だったり構造体でxとyのフィールドを持ってたりy*w+xの整数だったり
色んな表現が出来るから柔軟という利点があってプロトタイプに向いてるってことじゃないの
419デフォルトの名無しさん
2014/11/27(木) 00:00:17.23ID:qRi3TEum >>411
動的型言語の玄人になると、値の型と無関係な(CallするとRuntime Errorになる)メソッドが
大量に候補に出てくるような補完や、typoすら発見できないようなチェッカーに
慣らされてるから疑問にすら思わなくなるってこと?
動的型言語の玄人になると、値の型と無関係な(CallするとRuntime Errorになる)メソッドが
大量に候補に出てくるような補完や、typoすら発見できないようなチェッカーに
慣らされてるから疑問にすら思わなくなるってこと?
420デフォルトの名無しさん
2014/11/27(木) 00:39:38.24ID:dibuY+0s >>418
一人で把握できる範囲でプロトタイプのようなある程度使い捨てを前提に作れる
ならそれほど問題はないが、スレタイにあるように大規模開発≒複数人開発だと
静的言語に比べて動的言語だとtypoみたいな簡単なミスでも見つけづらいよねと
いうような話だと思う。 ちょろっとしたものを作るだけなら変数は全てオブジェクト
ですっていうように抽象化されている方が楽だけど、大規模開発だとそれじゃ
ダメだよねっていう話。
一人で把握できる範囲でプロトタイプのようなある程度使い捨てを前提に作れる
ならそれほど問題はないが、スレタイにあるように大規模開発≒複数人開発だと
静的言語に比べて動的言語だとtypoみたいな簡単なミスでも見つけづらいよねと
いうような話だと思う。 ちょろっとしたものを作るだけなら変数は全てオブジェクト
ですっていうように抽象化されている方が楽だけど、大規模開発だとそれじゃ
ダメだよねっていう話。
421デフォルトの名無しさん
2014/11/27(木) 00:43:32.22ID:pDjxUsPd422デフォルトの名無しさん
2014/11/27(木) 07:05:04.04ID:zJRTpdHD そりゃ未定義がワーニングだからだろ。
ワークニング出たよ。
さて、そのワーニングは無視していいのかよくないのか?
typoしてワーニングが出た。あぁ、いつものワーニングかでスルー
結局ワーニングがあてにならないものになってるだろ。
ワークニング出たよ。
さて、そのワーニングは無視していいのかよくないのか?
typoしてワーニングが出た。あぁ、いつものワーニングかでスルー
結局ワーニングがあてにならないものになってるだろ。
423デフォルトの名無しさん
2014/11/27(木) 07:17:33.51ID:pDjxUsPd424デフォルトの名無しさん
2014/11/27(木) 07:36:00.70ID:0IKZEJch425デフォルトの名無しさん
2014/11/27(木) 08:44:42.11ID:29V21Kp8 >>424
そうだね。なんかこんなようなメソッド名(Smalltalkではセレクタと呼ぶ)だったなぁ…と
うろ覚えで適当に入れとくとコンパイラがあとでいちいち教えてくれるから、はいはいって直してく感じ。
補完が便利だなぁと感じるのは長いメソッド名の場合かな。
適当にだとしてもタイプするのが単純に面倒なのでその労力を省くことができるので。
そうだね。なんかこんなようなメソッド名(Smalltalkではセレクタと呼ぶ)だったなぁ…と
うろ覚えで適当に入れとくとコンパイラがあとでいちいち教えてくれるから、はいはいって直してく感じ。
補完が便利だなぁと感じるのは長いメソッド名の場合かな。
適当にだとしてもタイプするのが単純に面倒なのでその労力を省くことができるので。
426デフォルトの名無しさん
2014/11/27(木) 09:51:34.08ID:79rV4D1o Python「低レベルな争いだな…」
427デフォルトの名無しさん
2014/11/27(木) 10:14:33.17ID:29V21Kp8428デフォルトの名無しさん
2014/11/27(木) 17:17:05.92ID:3JRXUen2 Smalltark 厨 vs Pythonee
429デフォルトの名無しさん
2014/11/27(木) 19:38:58.94ID:29V21Kp8 >>428
Unknown variable: Smalltark please correct, or cancel:
define new class
declare global
------------------------------------------------------
Smalltalk
SmalltalkImageTest
SmalltalkEditor
SmalltalkImage
SmallLandColorTheme
SmallInteger
SmallIntegerTest
SMAccount
SMCategory
SMPackageInstallationTask
------------------------------------------------------
cancel
Unknown variable: Smalltark please correct, or cancel:
define new class
declare global
------------------------------------------------------
Smalltalk
SmalltalkImageTest
SmalltalkEditor
SmalltalkImage
SmallLandColorTheme
SmallInteger
SmallIntegerTest
SMAccount
SMCategory
SMPackageInstallationTask
------------------------------------------------------
cancel
430デフォルトの名無しさん
2014/11/27(木) 20:07:16.47ID:p4BAxWMe Python「ただのテキストエディタで出来そう…」
431デフォルトの名無しさん
2014/11/27(木) 20:39:01.35ID:9Juu1ps5 そんなにイデの力が欲しいか
432デフォルトの名無しさん
2014/11/28(金) 00:34:41.35ID:O/dyue/E >>378
ゴロニャーン♪
ゴロニャーン♪
433デフォルトの名無しさん
2014/11/28(金) 09:07:58.51ID:8rVeLSla434デフォルトの名無しさん
2014/11/28(金) 09:09:59.36ID:8rVeLSla435デフォルトの名無しさん
2014/11/28(金) 09:13:52.73ID:8rVeLSla ここまでの流れだと結論は
静的言語は初心者向け
静的言語使いは初心者
静的言語は初心者向け
静的言語使いは初心者
436デフォルトの名無しさん
2014/11/28(金) 09:59:17.09ID:F5n5vmOV 処理系作ってる連中に学が無いから、型推論できるチェッカーひとつ作れない
で、仕方なく運用(命名規則)で回避ですか
駄目システムに苦しめられてるユーザと同じ図じゃん
なお、大規模開発ではどんな命名規則でもメソッド名が増えるため破綻する模様
で、仕方なく運用(命名規則)で回避ですか
駄目システムに苦しめられてるユーザと同じ図じゃん
なお、大規模開発ではどんな命名規則でもメソッド名が増えるため破綻する模様
437デフォルトの名無しさん
2014/11/28(金) 11:02:52.12ID:MpXGAzGF 手元のSmalltalk環境には4万強のメソッドがあって
先にも言われているように、型推論付きとかそんな高尚な補完もないけど
使いたいメソッドが出てこなくて困ったことなんかないぞ。
先にも言われているように、型推論付きとかそんな高尚な補完もないけど
使いたいメソッドが出てこなくて困ったことなんかないぞ。
438デフォルトの名無しさん
2014/11/28(金) 17:18:45.17ID:8rVeLSla >>436
まともな人がちゃんと作れば君のような目にはあわずにすむということじゃないかなあw
まともな人がちゃんと作れば君のような目にはあわずにすむということじゃないかなあw
439デフォルトの名無しさん
2014/11/28(金) 17:21:26.03ID:8rVeLSla440デフォルトの名無しさん
2014/11/28(金) 20:56:18.69ID:avPnRbje441デフォルトの名無しさん
2014/11/28(金) 21:02:53.61ID:pWSxBDFH >>438
まともな人は遥か昔Smalltalkから逃げ出したし、現在進行形でRubyからも続々と逃げ出してるよね
まともな人は遥か昔Smalltalkから逃げ出したし、現在進行形でRubyからも続々と逃げ出してるよね
442デフォルトの名無しさん
2014/11/28(金) 23:32:57.83ID:5WZv/pSY >>440
いろいろやるけど、主にWebアプリだな。
いろいろやるけど、主にWebアプリだな。
443デフォルトの名無しさん
2014/11/29(土) 02:10:12.49ID:TbFyYdBX >>437
> 使いたいメソッドが出てこなくて困ったことなんかないぞ。
コードを動かさないでだせる?
つまりアプリは動いておらずテキストエディタで書いている時。
コードを動かさないと出せないっていうのがダメなんだよね。
いろんな処理、例えば10分ぐらい処理してやっと実行される関数があったとする。
その関数の中にある条件分岐で真になるときのコード補完はできるだろうけど、
次に偽になる時のコード補完をしようと思ったら10分間待たないといけなくなる。
コードを動かさないでコード補完ができれば、待ち時間なしで
コード補完が出来るわけさ。
> 使いたいメソッドが出てこなくて困ったことなんかないぞ。
コードを動かさないでだせる?
つまりアプリは動いておらずテキストエディタで書いている時。
コードを動かさないと出せないっていうのがダメなんだよね。
いろんな処理、例えば10分ぐらい処理してやっと実行される関数があったとする。
その関数の中にある条件分岐で真になるときのコード補完はできるだろうけど、
次に偽になる時のコード補完をしようと思ったら10分間待たないといけなくなる。
コードを動かさないでコード補完ができれば、待ち時間なしで
コード補完が出来るわけさ。
444デフォルトの名無しさん
2014/11/29(土) 02:28:50.06ID:1aIidqiX445デフォルトの名無しさん
2014/11/29(土) 02:54:05.37ID:SuGYzpy/ >>443
オブジェクトが数値のときは数値関係のメソッドだけ補完に出せとか、そういう条件はあるの?
オブジェクトが数値のときは数値関係のメソッドだけ補完に出せとか、そういう条件はあるの?
446デフォルトの名無しさん
2014/11/29(土) 04:14:00.96ID:TbFyYdBX447446
2014/11/29(土) 04:16:18.02ID:TbFyYdBX 当たり前だけど、a. の行にブレークポイントを置いて、
そこまで実行してからa.を出すのはなし。
その行のブレークポイントまで実行しないといけないから
時間がかかる。
そこまで実行してからa.を出すのはなし。
その行のブレークポイントまで実行しないといけないから
時間がかかる。
448デフォルトの名無しさん
2014/11/29(土) 08:00:05.38ID:fWl7Yvk9449デフォルトの名無しさん
2014/11/29(土) 08:16:34.87ID:SO1yCwH9 >>446
MyClassのメソッド一覧ってどれぐらいのサイズ?
Smalltalkのように充実した標準ライブラリを持つ言語だと
Objectクラスだけでメソッドが488個あるから
MyClassのメソッド一覧は少なくとも500個ぐらいになって
aのクラスを特定する意味はあまりないな。
Smalltalkほどクラスライブラリが充実してないプアな言語だと
クラスを特定できるとうれしいかもしれないけど。
MyClassのメソッド一覧ってどれぐらいのサイズ?
Smalltalkのように充実した標準ライブラリを持つ言語だと
Objectクラスだけでメソッドが488個あるから
MyClassのメソッド一覧は少なくとも500個ぐらいになって
aのクラスを特定する意味はあまりないな。
Smalltalkほどクラスライブラリが充実してないプアな言語だと
クラスを特定できるとうれしいかもしれないけど。
450デフォルトの名無しさん
2014/11/29(土) 09:19:45.30ID:SuGYzpy/ 補完候補が単純なalphabetical orderじゃなくて
使用頻度順を学習して上から並べてくれるやつもあるので
その反論はナンセンスじゃね?
MyClassとObjectでは使われるメソッドの頻度が違うから
使用頻度順を学習して上から並べてくれるやつもあるので
その反論はナンセンスじゃね?
MyClassとObjectでは使われるメソッドの頻度が違うから
451デフォルトの名無しさん
2014/11/29(土) 09:23:05.48ID:1aIidqiX >>446
ちょっと待ってよ。そういう話なの?
俺の理解では、
- 静的型言語は変数を型で縛っているから補完がやりやすい。
- 動的型言語で静的に同レベルを実現するのは理論的に不可能。
ということは議論され尽くされてるわけだから暗黙の了解としてよくて、
- だけど動的型言語でも型推論をしてある程度絞って出せるのはあるよね。
- Smalltalkにはそういうスマートな機能はないけど、あんまり困ったことないよ。
という流れがあったところに>>443 で、
- 実行はせず、テキストエディタで編集中のコードで問題なくメソッドは出せるのか?
ときたから、意図がよくわからないのでコードを示してくれと頼んだら、
- 実行をして a をを確定してからその情報を元にして補完をするのはナシで、
静的型言語と同じように a の関連のメソッドだけしぼって出してみろ!
という要求だったので非常に驚いている。←イマココ
ちょっと待ってよ。そういう話なの?
俺の理解では、
- 静的型言語は変数を型で縛っているから補完がやりやすい。
- 動的型言語で静的に同レベルを実現するのは理論的に不可能。
ということは議論され尽くされてるわけだから暗黙の了解としてよくて、
- だけど動的型言語でも型推論をしてある程度絞って出せるのはあるよね。
- Smalltalkにはそういうスマートな機能はないけど、あんまり困ったことないよ。
という流れがあったところに>>443 で、
- 実行はせず、テキストエディタで編集中のコードで問題なくメソッドは出せるのか?
ときたから、意図がよくわからないのでコードを示してくれと頼んだら、
- 実行をして a をを確定してからその情報を元にして補完をするのはナシで、
静的型言語と同じように a の関連のメソッドだけしぼって出してみろ!
という要求だったので非常に驚いている。←イマココ
452デフォルトの名無しさん
2014/11/29(土) 09:26:19.46ID:SuGYzpy/ 標準ライブラリの大きさとObjectに数百個程度のメソッドがあることの
関係も良くわからない
標準ライブラリに少なくとも数百個もメソッドがあるんだぜスゲーってこと?
関係も良くわからない
標準ライブラリに少なくとも数百個もメソッドがあるんだぜスゲーってこと?
453デフォルトの名無しさん
2014/11/29(土) 09:40:43.18ID:e6ORUEwd454デフォルトの名無しさん
2014/11/29(土) 09:50:35.80ID:SuGYzpy/ でも>>446をよく見たら、こんなお題だったのか
> function foo(a) {
> a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示されて欲しい
> }
これは静的型付言語で型推論があっても補完は無理だw
> function foo(a) {
> a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示されて欲しい
> }
これは静的型付言語で型推論があっても補完は無理だw
455デフォルトの名無しさん
2014/11/29(土) 10:17:11.39ID:e6ORUEwd これなら型補完できるよ。これが静的言語でしょ?
> これがJavaなら
> void foo(MyClass a) {
> a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示される
> }
> これがJavaなら
> void foo(MyClass a) {
> a. とピリオドを入力した時点で、MyClassが持ってるメソッド一覧が表示される
> }
456デフォルトの名無しさん
2014/11/29(土) 10:31:13.38ID:SO1yCwH9 >>453
へー、継承元のメソッドを分けて表示すれば解決する程度の貧弱なクラスライブラリが前提なんだー(鼻ホジホジ
へー、継承元のメソッドを分けて表示すれば解決する程度の貧弱なクラスライブラリが前提なんだー(鼻ホジホジ
457デフォルトの名無しさん
2014/11/29(土) 10:34:40.20ID:7EP7sx63458デフォルトの名無しさん
2014/11/29(土) 10:35:24.90ID:SO1yCwH9 静的言語でやっているコーディングとかIDEの使い方をそのまま動的言語に持ち込んで「これができない」「あれができない」と喚きだす初心者を眺めるスレw
459デフォルトの名無しさん
2014/11/29(土) 10:36:42.17ID:SO1yCwH9 >>457
そういう話はSmalltalkスレでどうぞ
Smalltalk総合 Squeak Pharo
http://peace.2ch.net/test/read.cgi/tech/1360991429/
そういう話はSmalltalkスレでどうぞ
Smalltalk総合 Squeak Pharo
http://peace.2ch.net/test/read.cgi/tech/1360991429/
460デフォルトの名無しさん
2014/11/29(土) 10:39:51.40ID:e6ORUEwd461デフォルトの名無しさん
2014/11/29(土) 10:40:48.12ID:e6ORUEwd462デフォルトの名無しさん
2014/11/29(土) 10:57:41.26ID:MSvzZpAh 技術的には型推論と補完を両立できるかどうか考えればいいと思うけど
ここで悪足掻きしてるやつは技術より心理にこだわっているふしがある
補完よいよねというマインドをつくることしか考えてない
ここで悪足掻きしてるやつは技術より心理にこだわっているふしがある
補完よいよねというマインドをつくることしか考えてない
463デフォルトの名無しさん
2014/11/29(土) 11:10:26.37ID:x5tELjcp 普通にいいだろw.
補完ができれば、それを応用して
さらにいろんなことができるようになるわけだし
補完ができれば、それを応用して
さらにいろんなことができるようになるわけだし
464デフォルトの名無しさん
2014/11/29(土) 11:16:43.56ID:SO1yCwH9 >>462
補完うんぬんは「静的型いいよね」というマインドのための道具でしかないでしょw
補完うんぬんは「静的型いいよね」というマインドのための道具でしかないでしょw
465デフォルトの名無しさん
2014/11/29(土) 11:17:30.03ID:7EP7sx63466デフォルトの名無しさん
2014/11/29(土) 11:17:56.66ID:MSvzZpAh467デフォルトの名無しさん
2014/11/29(土) 11:44:56.39ID:SuGYzpy/ 補完するときにメソッド名を選択すると、引数や戻り値の型やドキュメントが
出てくれるのは凄く嬉しい
あと同じ機能を使うと、メソッドにカーソル当てたらドキュメントを出せるようになるから
コード読むのが捗りまくる
出てくれるのは凄く嬉しい
あと同じ機能を使うと、メソッドにカーソル当てたらドキュメントを出せるようになるから
コード読むのが捗りまくる
468デフォルトの名無しさん
2014/11/29(土) 11:56:50.41ID:x5tELjcp 出来るできないで考えるからわからない。
どちらが楽にできるかどうかで考えよう。
そしてただ単に楽にできるかで考えるのもダメ一体何が楽ができるか。
つまり、書くのが楽か、読むのが楽か。
どちらを重視すべきかというと、書くよりも読むことが楽になるようにするべき。
なぜならプログラミングの作業の多くは書こに書いたコードを読んで修正することだから。
そういう時に、この変数は○○型であると書いてある方がいいわけだよ。
コメントに書くこともできるがそれだと実際のコードとコメントが
一致していない可能性がある。
コメントを書くよりも、コードでそれを表現するべき。
そうすれば人間もコンパイラも理解できる。
静的型がいいのは、そういう読むときの開発効率の高さにある。
どちらが楽にできるかどうかで考えよう。
そしてただ単に楽にできるかで考えるのもダメ一体何が楽ができるか。
つまり、書くのが楽か、読むのが楽か。
どちらを重視すべきかというと、書くよりも読むことが楽になるようにするべき。
なぜならプログラミングの作業の多くは書こに書いたコードを読んで修正することだから。
そういう時に、この変数は○○型であると書いてある方がいいわけだよ。
コメントに書くこともできるがそれだと実際のコードとコメントが
一致していない可能性がある。
コメントを書くよりも、コードでそれを表現するべき。
そうすれば人間もコンパイラも理解できる。
静的型がいいのは、そういう読むときの開発効率の高さにある。
469デフォルトの名無しさん
2014/11/29(土) 11:59:47.15ID:x5tELjcp なお、コード補完は、書くことを楽にしてくれる、
つまりタイピングを補助するものだと勘違いしている人が多いが、
実際は読むことを楽にしてくれている。
つまり、このオブジェクトにはどんなメソッドがあって、
そのメソッドがどんな機能、引数、戻り値を提供しているか
ということを確かめるために、ドキュメントやコードを
読むことを楽にしてくれる。
だから適切な補完が重要になる。
多すぎることもなく少なすぎることもなく
間違えることもない補完が重要。
つまりタイピングを補助するものだと勘違いしている人が多いが、
実際は読むことを楽にしてくれている。
つまり、このオブジェクトにはどんなメソッドがあって、
そのメソッドがどんな機能、引数、戻り値を提供しているか
ということを確かめるために、ドキュメントやコードを
読むことを楽にしてくれる。
だから適切な補完が重要になる。
多すぎることもなく少なすぎることもなく
間違えることもない補完が重要。
470デフォルトの名無しさん
2014/11/29(土) 12:11:58.32ID:nAAws2G7471デフォルトの名無しさん
2014/11/29(土) 12:30:14.99ID:v2v5Wnkr それ以前にさ、動的型付きとして
失ってほしくない機能って何さ?
失っても対して問題ない機能ばかりだと思うだが。
失ってほしくない機能って何さ?
失っても対して問題ない機能ばかりだと思うだが。
472デフォルトの名無しさん
2014/11/29(土) 12:44:23.44ID:A4nuaoXO 標準ライブラリや他人の作ったライブラリの全てを記憶できる変態でも無い限り
コード補完によってドキュメントを含め表示して選択出来るってのは生産する
上ではかなりのアドバンテージなんだけどね。 大昔のクソなIDEや最近のでも
動的言語に対応しているのはクソなIDEしかないから、そういう技術の進歩を
知らない原始人には理解できないことなんだよ。
コード補完によってドキュメントを含め表示して選択出来るってのは生産する
上ではかなりのアドバンテージなんだけどね。 大昔のクソなIDEや最近のでも
動的言語に対応しているのはクソなIDEしかないから、そういう技術の進歩を
知らない原始人には理解できないことなんだよ。
473デフォルトの名無しさん
2014/11/29(土) 12:49:43.77ID:v2v5Wnkr 動的型付きにすることで失われていることのほうが多いと思う。
それで、動的型付きにしてまで守ろうとしているものってなに?
それで、動的型付きにしてまで守ろうとしているものってなに?
474デフォルトの名無しさん
2014/11/29(土) 13:13:21.80ID:MSvzZpAh ドキュメントについては仕様書が欲しいか具体例が欲しいかによる
ただちに必要ではないことまで書かれているのが仕様書
ある時点で必要だったことしか書かれていないのが具体例
具体例から仕様を想像できるような変態は全てを記憶ではなく推理している
ただちに必要ではないことまで書かれているのが仕様書
ある時点で必要だったことしか書かれていないのが具体例
具体例から仕様を想像できるような変態は全てを記憶ではなく推理している
475デフォルトの名無しさん
2014/11/29(土) 13:24:38.99ID:U5ivpV2C スタートダッシュと試行錯誤じゃないの
軌道に乗ったら捨てて作りなおせばいいのよ
軌道に乗ったら捨てて作りなおせばいいのよ
476デフォルトの名無しさん
2014/11/29(土) 13:24:42.22ID:7EP7sx63477デフォルトの名無しさん
2014/11/29(土) 13:54:58.03ID:A4nuaoXO >>476
javaならソースに書かれているjavadocが出る。いわゆるAPIリファレンスと
言われるものが表示される。visual stadioだとmsdnに書いてあるのが出る。
APIリファレンスが役に立たないとか言っちゃうような無能はプログラムを
書くのを辞めたほうがいい。
javadocが出たことによって他の言語でもソースに埋め込んだコメントを
別ドキュメントに言語の標準かそれに近いレベルで提供されることが多く
なった。ただ別ツールを使ってまでドキュメントを出力するようなところは
殆ど無かったけど、IDEで自分や他人の書いたドキュメントまで手元で
参照できるようになったことで、どのレベルでコメントを書けばよいうかと
いうことに気づけた人はそれなりにいるかと思う。
書かないと煩く言われるから書くというのから、自分で書いたコードでも
元のコードを見なくても分かるように書くというのに変われた人は多いと
思います。最低でも自分で書いたコードを自分の為にというのがやり
やすくなった。
javaならソースに書かれているjavadocが出る。いわゆるAPIリファレンスと
言われるものが表示される。visual stadioだとmsdnに書いてあるのが出る。
APIリファレンスが役に立たないとか言っちゃうような無能はプログラムを
書くのを辞めたほうがいい。
javadocが出たことによって他の言語でもソースに埋め込んだコメントを
別ドキュメントに言語の標準かそれに近いレベルで提供されることが多く
なった。ただ別ツールを使ってまでドキュメントを出力するようなところは
殆ど無かったけど、IDEで自分や他人の書いたドキュメントまで手元で
参照できるようになったことで、どのレベルでコメントを書けばよいうかと
いうことに気づけた人はそれなりにいるかと思う。
書かないと煩く言われるから書くというのから、自分で書いたコードでも
元のコードを見なくても分かるように書くというのに変われた人は多いと
思います。最低でも自分で書いたコードを自分の為にというのがやり
やすくなった。
478デフォルトの名無しさん
2014/11/29(土) 14:00:18.54ID:A4nuaoXO そういえばvisual studioだとサンプルコードを検索ダウンロード出来る機能まで
付いたんだっけかな。
付いたんだっけかな。
479デフォルトの名無しさん
2014/11/29(土) 14:06:58.21ID:7EP7sx63 >>477
javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
サマリーだけじゃ役に立たんがね。
IDEで出るのはあくまでも補助的なもんで、ちゃんとしたAPIのドキュメントは
msdn見ないと駄目だろ。APIの注意書きとかサンプルコードとかはIDEでは出ないだぎゃー
最近のVisual Studioは、msdnの全文が出るんけ?
底辺土方なんで最新版は知らんのじゃ〜
javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
サマリーだけじゃ役に立たんがね。
IDEで出るのはあくまでも補助的なもんで、ちゃんとしたAPIのドキュメントは
msdn見ないと駄目だろ。APIの注意書きとかサンプルコードとかはIDEでは出ないだぎゃー
最近のVisual Studioは、msdnの全文が出るんけ?
底辺土方なんで最新版は知らんのじゃ〜
480デフォルトの名無しさん
2014/11/29(土) 14:07:50.21ID:7EP7sx63481デフォルトの名無しさん
2014/11/29(土) 14:13:44.81ID:v2v5Wnkr >>479
> javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
> サマリーだけじゃ役に立たんがね。
サマリーでも役に立つと思うし、リンクになってるから
ヘルプ調べるのも速くなるんだが?
> javadocは、どの程度のが出るかしらんが、Visual Studioで出るような
> サマリーだけじゃ役に立たんがね。
サマリーでも役に立つと思うし、リンクになってるから
ヘルプ調べるのも速くなるんだが?
482デフォルトの名無しさん
2014/11/29(土) 14:25:05.29ID:7EP7sx63483デフォルトの名無しさん
2014/11/29(土) 14:33:59.73ID:A4nuaoXO >>479
ttp://docs.oracle.com/javase/8/docs/api/index.html
どのレベルも何も↑の各クラス、メソッドのがそのまま出るんだが。
これは英語だが、日本語訳のがある場合はそっちを使うことが出来る。
で、ここに書かれていなくて他に書かれているというドキュメントは存在しない
わけで、ググってどこにも無ければこれに頼るしか無い。 このリファレンスが
分からない役に立たないっていうやつは少なくてもjavaはやらないほうがいい。
ttp://docs.oracle.com/javase/8/docs/api/index.html
どのレベルも何も↑の各クラス、メソッドのがそのまま出るんだが。
これは英語だが、日本語訳のがある場合はそっちを使うことが出来る。
で、ここに書かれていなくて他に書かれているというドキュメントは存在しない
わけで、ググってどこにも無ければこれに頼るしか無い。 このリファレンスが
分からない役に立たないっていうやつは少なくてもjavaはやらないほうがいい。
484デフォルトの名無しさん
2014/11/29(土) 14:36:32.05ID:v2v5Wnkr485デフォルトの名無しさん
2014/11/29(土) 14:37:24.55ID:v2v5Wnkr で、そんな話はいいとして、動的型付け言語が
動的型付けにしてまで守ろうとしているものって何よ?
動的型付けにしてまで守ろうとしているものって何よ?
486デフォルトの名無しさん
2014/11/29(土) 14:38:14.93ID:Tl+PW+FS 動的言語でも変数aをMyClass型と教えればメソッド一覧は出せるだろ
487デフォルトの名無しさん
2014/11/29(土) 14:39:37.78ID:v2v5Wnkr488デフォルトの名無しさん
2014/11/29(土) 14:40:07.50ID:SO1yCwH9 その問い自体が静的目線だってのw
視野が狭いなあw
視野が狭いなあw
489デフォルトの名無しさん
2014/11/29(土) 14:40:46.54ID:Tl+PW+FS いちいち変数を宣言して型を指定するのとかわらないと思う
490デフォルトの名無しさん
2014/11/29(土) 14:42:05.95ID:v2v5Wnkr その都度、MyClass型って教えないといけない手間がかかるのと
コードに仕様として書いておけるのの違いだね
コードに仕様として書いておけるのの違いだね
491デフォルトの名無しさん
2014/11/29(土) 14:42:13.42ID:SO1yCwH9 補完候補を500に絞り込むためだけに、aがMyClassのインスタンスでないと動かないような腐れコードにするわけか
ご苦労さまなこってw
こりゃ世の中からクソコードがなくならないわけだw
ご苦労さまなこってw
こりゃ世の中からクソコードがなくならないわけだw
492デフォルトの名無しさん
2014/11/29(土) 14:43:48.06ID:v2v5Wnkr > 補完候補を500に絞り込むためだけに
補完候補を500ってなんのこと?
動的型付けだと、その500を全て覚えてるの?
意味がわからないね。
補完候補を500ってなんのこと?
動的型付けだと、その500を全て覚えてるの?
意味がわからないね。
493デフォルトの名無しさん
2014/11/29(土) 14:45:30.32ID:TZOpdCpR 型を書かなくても a = MyClass() や、さらにいえば
foo(MyClass()) のようなコードがあるだけでも>>446は補完できる様になる
foo(MyClass()) のようなコードがあるだけでも>>446は補完できる様になる
494デフォルトの名無しさん
2014/11/29(土) 14:46:28.99ID:v2v5Wnkr 逆に言えば、そういうコードがなければ
補完できないという意味である。
例えば関数の引数。これは補完できない。
補完できないという意味である。
例えば関数の引数。これは補完できない。
495デフォルトの名無しさん
2014/11/29(土) 14:48:16.54ID:Tl+PW+FS 補完ってそこまで重要か
動的言語支持者の揚げ足をとるためには必要かもしれないけど
単語単位補完で十分通用してる
動的言語支持者の揚げ足をとるためには必要かもしれないけど
単語単位補完で十分通用してる
496デフォルトの名無しさん
2014/11/29(土) 14:49:08.68ID:v2v5Wnkr 型を書かなかったら a = MyClass() と a =YourClass()の両方があったら
補完がめちゃくちゃになる。
foo(MyClass()) と foo(YourClass()) のようなコードがあると
>>446の補完は使い物にならなくなる。
補完がめちゃくちゃになる。
foo(MyClass()) と foo(YourClass()) のようなコードがあると
>>446の補完は使い物にならなくなる。
497デフォルトの名無しさん
2014/11/29(土) 14:51:15.51ID:v2v5Wnkr >>495
> 補完ってそこまで重要か
重要ですよ。
開発効率がぜんぜん違う。
・タイプ数の省略
・うろ覚え(引数の順番程度)でヘルプを引くことの省略
・ヘルプを開く場合でもその手間の省略
・コードのミスを実行せずに知ることが出来る
・リファクタリング時に自動で安全にできることが多くなる。
これらはいらないんだ!って言うかもしれないが、
それは開発効率が大きく高まることを否定する言葉じゃないからね。
> 補完ってそこまで重要か
重要ですよ。
開発効率がぜんぜん違う。
・タイプ数の省略
・うろ覚え(引数の順番程度)でヘルプを引くことの省略
・ヘルプを開く場合でもその手間の省略
・コードのミスを実行せずに知ることが出来る
・リファクタリング時に自動で安全にできることが多くなる。
これらはいらないんだ!って言うかもしれないが、
それは開発効率が大きく高まることを否定する言葉じゃないからね。
498デフォルトの名無しさん
2014/11/29(土) 14:54:43.83ID:TZOpdCpR499デフォルトの名無しさん
2014/11/29(土) 14:55:43.43ID:rjWp6DMr 単語単位補完って、単にタイプ数を
少し省略することしかできないからね。
しかも補完した結果が間違っていることがある。
動的型付けにおける補完の効果って
その程度しかできないし、その程度のことしか知らないから
静的型付け言語でもその程度のことだと思ってる人が多いんだよ。
ぜんぜん違う。静的型付け言語であれば補完は
タイプ数削減以上に大きく開発効率を上げることが出来る。
明らかに開発効率を上げると証明された。
動的型付けで開発効率を上げることは出来るのか?
動的型付けにしてまで守ろうとしているものはなんなのか?
少し省略することしかできないからね。
しかも補完した結果が間違っていることがある。
動的型付けにおける補完の効果って
その程度しかできないし、その程度のことしか知らないから
静的型付け言語でもその程度のことだと思ってる人が多いんだよ。
ぜんぜん違う。静的型付け言語であれば補完は
タイプ数削減以上に大きく開発効率を上げることが出来る。
明らかに開発効率を上げると証明された。
動的型付けで開発効率を上げることは出来るのか?
動的型付けにしてまで守ろうとしているものはなんなのか?
500デフォルトの名無しさん
2014/11/29(土) 15:00:38.05ID:rjWp6DMr >>498
いや、だからなければ型推論できないでしょ。
「実際に関数を使ってるコード」の方が間違っていたら
補完も間違うわけよ。foo(MyClass())って使わないといけない時に
foo(YourClass())って書いてしまったら、補完もそれに合わされてしまう。
それにさ、人間の問題はどうなるのさ?
function foo(a) {} ってコードをいきなりみせられて
aは何型でしょう? ってクイズ?(笑)
リーダブルコードってわかるかな?
ライタブルコードってはいわないんだよ。
重要なのは読む時。読む時に必要な情報が欠けてる。
もしくは間違ってる。そんな信用出来ない状態では開発効率は大きく下がるよね。
で、動的型付け言語は開発効率下がると証明されたが
あがる理由は何かあるのか?
いや、だからなければ型推論できないでしょ。
「実際に関数を使ってるコード」の方が間違っていたら
補完も間違うわけよ。foo(MyClass())って使わないといけない時に
foo(YourClass())って書いてしまったら、補完もそれに合わされてしまう。
それにさ、人間の問題はどうなるのさ?
function foo(a) {} ってコードをいきなりみせられて
aは何型でしょう? ってクイズ?(笑)
リーダブルコードってわかるかな?
ライタブルコードってはいわないんだよ。
重要なのは読む時。読む時に必要な情報が欠けてる。
もしくは間違ってる。そんな信用出来ない状態では開発効率は大きく下がるよね。
で、動的型付け言語は開発効率下がると証明されたが
あがる理由は何かあるのか?
501デフォルトの名無しさん
2014/11/29(土) 15:11:36.58ID:TZOpdCpR502デフォルトの名無しさん
2014/11/29(土) 15:14:22.47ID:Tl+PW+FS 動的言語の方がコード量が減るから大規模になりにくい
短期記憶に入りやすいから効率も上がる
静的に見て機械的に処理しやすいのは静的片付け言語だけど
短期記憶に入りやすいから効率も上がる
静的に見て機械的に処理しやすいのは静的片付け言語だけど
503デフォルトの名無しさん
2014/11/29(土) 15:14:41.06ID:HSRgXQQV > それは void foo(YourClass a) って間違えても同じだよね
定義は一箇所。
使う場所は沢山。
一個でも間違えたらどちらが正しいかわからなくなる。
定義は一箇所。
使う場所は沢山。
一個でも間違えたらどちらが正しいかわからなくなる。
504デフォルトの名無しさん
2014/11/29(土) 15:16:15.20ID:HSRgXQQV >>502
> 動的言語の方がコード量が減るから大規模になりにくい
重要なのは、タイプ量ではなくて読む量なんだよ。
動的言語のコード量が減るってようするに、
コードを理解するための情報が減るから
コードが読めなくなる。
少なければいいってもんじゃないんだよ。
> 動的言語の方がコード量が減るから大規模になりにくい
重要なのは、タイプ量ではなくて読む量なんだよ。
動的言語のコード量が減るってようするに、
コードを理解するための情報が減るから
コードが読めなくなる。
少なければいいってもんじゃないんだよ。
505デフォルトの名無しさん
2014/11/29(土) 15:17:16.14ID:Tl+PW+FS 少なければいいよ
機械がコードを読み書きするんじゃなくて人がするんだから
機械がコードを読み書きするんじゃなくて人がするんだから
506デフォルトの名無しさん
2014/11/29(土) 15:18:12.01ID:TZOpdCpR507デフォルトの名無しさん
2014/11/29(土) 15:20:19.64ID:HSRgXQQV 動的型付け言語では、コードを理解するための情報(定義)が減って、
実行するコード自体の量は静的型付けでも動的型付けでも変わらない。
たとえて言うならば、
文章の枠外にある注釈を書いているのが静的型付け言語で
同じ文章でありながら、枠外の注釈を取り除いたのが動的型付け言語
注釈があればいきなり変数が出てきても、これは○型だってわかるが、
注釈がなければ、この変数に値入れてるのどこだよ。
この関数を使ってるのはどこだよと
注目して呼んでいる所以外の情報を探してこなければいけない。
実行するコード自体の量は静的型付けでも動的型付けでも変わらない。
たとえて言うならば、
文章の枠外にある注釈を書いているのが静的型付け言語で
同じ文章でありながら、枠外の注釈を取り除いたのが動的型付け言語
注釈があればいきなり変数が出てきても、これは○型だってわかるが、
注釈がなければ、この変数に値入れてるのどこだよ。
この関数を使ってるのはどこだよと
注目して呼んでいる所以外の情報を探してこなければいけない。
508デフォルトの名無しさん
2014/11/29(土) 15:22:35.61ID:MSvzZpAh509デフォルトの名無しさん
2014/11/29(土) 15:24:39.97ID:HSRgXQQV >>506
無理だよ。
例えばMyClassにhogeというメソッドがあって、YourClassには無いとする。
これをfoo(MyClass()) と foo(YourClass())に渡した所でエラーにならない。
fooの中でhogeを呼び出しているから、YourClassを渡している所が間違いだ!と
思いきや、
動的にYourClassにhogeメソッドを追加するかもしれないから
エラーとは言い切れない。
つまりエラーと出る箇所はすべて、エラーではないかもしれない。
無理だよ。
例えばMyClassにhogeというメソッドがあって、YourClassには無いとする。
これをfoo(MyClass()) と foo(YourClass())に渡した所でエラーにならない。
fooの中でhogeを呼び出しているから、YourClassを渡している所が間違いだ!と
思いきや、
動的にYourClassにhogeメソッドを追加するかもしれないから
エラーとは言い切れない。
つまりエラーと出る箇所はすべて、エラーではないかもしれない。
510デフォルトの名無しさん
2014/11/29(土) 15:26:57.07ID:HSRgXQQV511デフォルトの名無しさん
2014/11/29(土) 15:37:19.95ID:TZOpdCpR512デフォルトの名無しさん
2014/11/29(土) 15:44:49.77ID:TZOpdCpR 動的にメソッドを追加するケースは少ない => 補完や型検査は動的言語でも有効
動的にメソッドを追加するケースが多い => 動的言語って凄く便利だね
動的にメソッドを追加するケースが多い => 動的言語って凄く便利だね
513デフォルトの名無しさん
2014/11/29(土) 15:49:50.99ID:HSRgXQQV >>511
> 動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ
俺がいいたいのはそれだよ。動的にメソッド追加されるケースは多くないのに
そのために多くのメリットを捨てるだけの意味が動的型付け言語にあるのかってこと。
> 動的言語の話なら、動的にメソッド追加されるケースは多くないからワーニングを出してもOKでしょ
俺がいいたいのはそれだよ。動的にメソッド追加されるケースは多くないのに
そのために多くのメリットを捨てるだけの意味が動的型付け言語にあるのかってこと。
514デフォルトの名無しさん
2014/11/29(土) 15:58:27.80ID:SO1yCwH9 >>497
>・タイプ数の省略
つまりタイプ数を省略するために
オブジェクトが持つメソッド数が僅かしかないような
ゴミみたいなライブラリを使わされるのはいやだなあ
>・うろ覚え(引数の順番程度)でヘルプを引くことの省略
補完以外にもいろいろな手段があるが?
>・ヘルプを開く場合でもその手間の省略
補完以外にもいろいろな手段があるが?
>・コードのミスを実行せずに知ることが出来る
実行すればわかることを、いちいち型として書いた上に
コードに余計な制約をつけるなんて愚の骨頂だろw
>・リファクタリング時に自動で安全にできることが多くなる。
くだらない。リファクタリングが始まったのは動的言語からだし、
リファクタリングをIDEの機能に統合したのも動的言語から。
で、補完を使うことで、可能なリファクタリングが増えるなんて初耳なんだが?
やはり静的脳で動的言語を見て「あれが欠けてる」「これが欠けてる」と言っているだけだねw
まずは自分の視野の狭さをなんとかしたら?
>・タイプ数の省略
つまりタイプ数を省略するために
オブジェクトが持つメソッド数が僅かしかないような
ゴミみたいなライブラリを使わされるのはいやだなあ
>・うろ覚え(引数の順番程度)でヘルプを引くことの省略
補完以外にもいろいろな手段があるが?
>・ヘルプを開く場合でもその手間の省略
補完以外にもいろいろな手段があるが?
>・コードのミスを実行せずに知ることが出来る
実行すればわかることを、いちいち型として書いた上に
コードに余計な制約をつけるなんて愚の骨頂だろw
>・リファクタリング時に自動で安全にできることが多くなる。
くだらない。リファクタリングが始まったのは動的言語からだし、
リファクタリングをIDEの機能に統合したのも動的言語から。
で、補完を使うことで、可能なリファクタリングが増えるなんて初耳なんだが?
やはり静的脳で動的言語を見て「あれが欠けてる」「これが欠けてる」と言っているだけだねw
まずは自分の視野の狭さをなんとかしたら?
515デフォルトの名無しさん
2014/11/29(土) 16:02:07.42ID:SO1yCwH9 補完君の要約
「ぼくがジャバでプログラムを書くのと同じやり方ができない動的言語なんて使えない」
「ぼくがジャバでプログラムを書くのと同じやり方ができない動的言語なんて使えない」
516デフォルトの名無しさん
2014/11/29(土) 16:55:08.72ID:SO1yCwH9 補完君の最大の勘違いは、
動的言語はa.と入力して出てくるメソッド名を絞り込めない
と思い込んでいること。
実際には、動的言語ではa.と入力して出てくる膨大なメソッド名の
どれでも正当なプログラムを構成し得る。
だからその膨大な候補リストは既に十分絞り込まれたもの。
ただ、静的脳の小さな容量では言語のポテンシャルが高すぎて
マトモに使いこなせない。かわいそうに。
動的言語はa.と入力して出てくるメソッド名を絞り込めない
と思い込んでいること。
実際には、動的言語ではa.と入力して出てくる膨大なメソッド名の
どれでも正当なプログラムを構成し得る。
だからその膨大な候補リストは既に十分絞り込まれたもの。
ただ、静的脳の小さな容量では言語のポテンシャルが高すぎて
マトモに使いこなせない。かわいそうに。
517デフォルトの名無しさん
2014/11/29(土) 20:03:41.93ID:o/hS6qzS 補完必須派に訊きたいんだけど
コンパイル時ダックタイピングともいわれる構造部分型
http://igeta.cocolog-nifty.com/blog/2008/05/subtyping.html
をサポートする静的型言語のときは、どういう候補を出すのが正解?
これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。
コンパイル時ダックタイピングともいわれる構造部分型
http://igeta.cocolog-nifty.com/blog/2008/05/subtyping.html
をサポートする静的型言語のときは、どういう候補を出すのが正解?
これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。
518デフォルトの名無しさん
2014/11/29(土) 21:05:19.38ID:7EP7sx63 >>484
オレオレOOなヤツに多いね。
自分の足りないオツムと一次ソースだけでプログラミングするやつw
個人ブログとかStackOverflowから良いコードがあればパクるのが良いねえ。
もちろん後から一次ソースで確認はする。
オレ様のゆるいオツムでは思いつかないようなクールなコードが世の中には沢山あるぞw
オレオレOOなヤツに多いね。
自分の足りないオツムと一次ソースだけでプログラミングするやつw
個人ブログとかStackOverflowから良いコードがあればパクるのが良いねえ。
もちろん後から一次ソースで確認はする。
オレ様のゆるいオツムでは思いつかないようなクールなコードが世の中には沢山あるぞw
519デフォルトの名無しさん
2014/11/29(土) 22:22:32.23ID:fN3BW3ns >>514
リファクタリングでできることは
静的型付け言語の方がとっくに多くなってるんだよ。
始まったのは動的型付けからって
単に懐古厨なだけだろ。昔はなってw
最新のリファクタリング技術がどうなっているかを知ると驚くぞ。
http://nanananande.helpfulness.jp/wp-content/uploads/sites/2/2014/06/3164/1b000175b814e923b2ddeebcadbf4154-159x300.png
それに対して動的型付けの話って
昔の話しか出てないだろ。
リファクタリングでできることは
静的型付け言語の方がとっくに多くなってるんだよ。
始まったのは動的型付けからって
単に懐古厨なだけだろ。昔はなってw
最新のリファクタリング技術がどうなっているかを知ると驚くぞ。
http://nanananande.helpfulness.jp/wp-content/uploads/sites/2/2014/06/3164/1b000175b814e923b2ddeebcadbf4154-159x300.png
それに対して動的型付けの話って
昔の話しか出てないだろ。
520デフォルトの名無しさん
2014/11/29(土) 22:25:49.85ID:fN3BW3ns >>516
> 補完君の最大の勘違いは、
> 動的言語はa.と入力して出てくるメソッド名を絞り込めない
> と思い込んでいること。
なにマッチ・ポンプしてるんだよw
静的型付け言語では最初から絞り込めるよな?
で、動的型つけ言語は500もメソッドが出る。(ドヤっ)
そんなにたくさん候補が出たら大変だろ!(ドヤっ)
って言っておいて、今度は、
動的型つけ言語でも絞り込める時もある(ドヤっ)
ですかw
うん、大変だね。静的型付け言語では最初から絞り込めるよ?
> 補完君の最大の勘違いは、
> 動的言語はa.と入力して出てくるメソッド名を絞り込めない
> と思い込んでいること。
なにマッチ・ポンプしてるんだよw
静的型付け言語では最初から絞り込めるよな?
で、動的型つけ言語は500もメソッドが出る。(ドヤっ)
そんなにたくさん候補が出たら大変だろ!(ドヤっ)
って言っておいて、今度は、
動的型つけ言語でも絞り込める時もある(ドヤっ)
ですかw
うん、大変だね。静的型付け言語では最初から絞り込めるよ?
521デフォルトの名無しさん
2014/11/29(土) 22:48:51.18ID:SuGYzpy/522デフォルトの名無しさん
2014/11/30(日) 00:47:09.72ID:mFsly3WX >>517
>これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。
なぜ構造的部分型が補完の指標になりえるのか、
その理由というか関連性が説明してごらん
単なる思いつきじゃねえの?
少なくとも >>517 のリンク先blog記事では
「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
と主張しているけど、こんな奇妙な話は聞いたことが無い
しかも記事のネタになったソース(学術的文献)が書かれていないし、
英語版 Wikipedia の Subtyping のページでも
duck tying との関連性に対する文章に対して "citation needed" と指摘されている
おまけに記者は構造的部分型付けをサポートする言語(OCaml)を使った事が
一度も無いと正直に告白している
このblog記事はあくまで記者が型システムを勉強する過程で書き残したノートであって、
この記事を引用して >>517 が何を言いたいのか、自分には意味不明だね
なお、動的型付け言語に(形式的な型推論を基礎とした)静的型付けを導入した概念は
Soft Typing と呼ばれている
動的型付け言語の補完を検討する指標となる可能性があるのは、
どちらかといえば Soft Typing ではないかと思うね
>これがわかると、動的型言語の補完がどうあるべきかの指標になるんでは。
なぜ構造的部分型が補完の指標になりえるのか、
その理由というか関連性が説明してごらん
単なる思いつきじゃねえの?
少なくとも >>517 のリンク先blog記事では
「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
と主張しているけど、こんな奇妙な話は聞いたことが無い
しかも記事のネタになったソース(学術的文献)が書かれていないし、
英語版 Wikipedia の Subtyping のページでも
duck tying との関連性に対する文章に対して "citation needed" と指摘されている
おまけに記者は構造的部分型付けをサポートする言語(OCaml)を使った事が
一度も無いと正直に告白している
このblog記事はあくまで記者が型システムを勉強する過程で書き残したノートであって、
この記事を引用して >>517 が何を言いたいのか、自分には意味不明だね
なお、動的型付け言語に(形式的な型推論を基礎とした)静的型付けを導入した概念は
Soft Typing と呼ばれている
動的型付け言語の補完を検討する指標となる可能性があるのは、
どちらかといえば Soft Typing ではないかと思うね
523522
2014/11/30(日) 00:49:19.68ID:mFsly3WX 細かいけど訂正
X: その理由というか関連性が説明してごらん
O: その理由というか関連性を説明してごらん
X: その理由というか関連性が説明してごらん
O: その理由というか関連性を説明してごらん
524デフォルトの名無しさん
2014/11/30(日) 00:51:32.07ID:uxHSis3U ガアガアとなく人間は
アヒルである。
ダックタイピング
アヒルである。
ダックタイピング
525デフォルトの名無しさん
2014/11/30(日) 01:04:21.57ID:360iudbJ >>519
昔の時点ですでに相当できてたって話もあるぞ。
http://web.archive.org/web/20090130061934/http://www.refactory.com/RefactoringBrowser/Refactorings.html
昔の時点ですでに相当できてたって話もあるぞ。
http://web.archive.org/web/20090130061934/http://www.refactory.com/RefactoringBrowser/Refactorings.html
526デフォルトの名無しさん
2014/11/30(日) 01:17:26.21ID:uxHSis3U >>525
同じぐらい"昔"である2009年の記事出していい?Eclipse+Javaの世界の話
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/
同じぐらい"昔"である2009年の記事出していい?Eclipse+Javaの世界の話
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/
527デフォルトの名無しさん
2014/11/30(日) 09:02:17.22ID:360iudbJ >>526
すまん2001年の登場当初のを貼るつもりだった。
http://web.archive.org/web/20010514165503/http://www.refactory.com/RefactoringBrowser/Refactorings.html
すまん2001年の登場当初のを貼るつもりだった。
http://web.archive.org/web/20010514165503/http://www.refactory.com/RefactoringBrowser/Refactorings.html
528デフォルトの名無しさん
2014/11/30(日) 09:53:30.32ID:uRzHHhxu 520を読むと516が言う通り補完君は動的型がまるでわかってないことが明白だ
529デフォルトの名無しさん
2014/11/30(日) 10:04:13.86ID:uRzHHhxu 補完君はキーを2,3文字入力するのをケチるために
引数がMyClassのインスタンスでなければ動かないゴミメソッドにして
どうだ静的型すごいとか言い出す初心者でしょ
引数がMyClassのインスタンスでなければ動かないゴミメソッドにして
どうだ静的型すごいとか言い出す初心者でしょ
530デフォルトの名無しさん
2014/11/30(日) 10:27:25.19ID:uRzHHhxu 静的型は自転車の補助輪
初心者を卒業したら外そうね
初心者を卒業したら外そうね
531デフォルトの名無しさん
2014/11/30(日) 10:46:49.86ID:/BRxH/wW532デフォルトの名無しさん
2014/11/30(日) 10:59:52.11ID:c9Q+Jt/4 大規模開発で人に作らせる立場だと、プログラマに静的言語という拘束具をつけた方が楽なんだよ。チームメンバの能力によって品質が変わってはいけないし。
人を指導する立場に立ってみると分かる。
人を指導する立場に立ってみると分かる。
533デフォルトの名無しさん
2014/11/30(日) 11:21:16.72ID:rR9TrKjV でも静的型を嫌がってたらGoogleとかでは働けないわけじゃん?
お前らどんな底辺企業で働いてるの?
それともニート?
お前らどんな底辺企業で働いてるの?
それともニート?
534デフォルトの名無しさん
2014/11/30(日) 12:03:38.55ID:360iudbJ >>522
structural subtyping と duck typing の対比なんていくらでも目にするだろう。
structural subtyping と duck typing の対比なんていくらでも目にするだろう。
535デフォルトの名無しさん
2014/11/30(日) 13:49:35.58ID:kUIpsKvT >>527
じゃあ同じように2001年という "大昔" の話をするね。
http://www.ibm.com/developerworks/library/eclipse/l-eclipse.html
Refactoring with Eclipse
Erich Gamma is the team lead for Java tools for Eclipse.
Gamma was one of the Gang of Four known for creating
the book Design Patterns: Elements of Reusable Object Oriented Software.
He also created JUnit with Kent Beck (see Resources).
Refactoring is recognized as another valuable practice in object oriented programming but,
until recently, only few tools had support for it. At OOPSLA 200,
Eclipse developers demonstrated the Refactoring support in Eclipse.
They stressed that refactoring should not alter a program's behavior.
じゃあ同じように2001年という "大昔" の話をするね。
http://www.ibm.com/developerworks/library/eclipse/l-eclipse.html
Refactoring with Eclipse
Erich Gamma is the team lead for Java tools for Eclipse.
Gamma was one of the Gang of Four known for creating
the book Design Patterns: Elements of Reusable Object Oriented Software.
He also created JUnit with Kent Beck (see Resources).
Refactoring is recognized as another valuable practice in object oriented programming but,
until recently, only few tools had support for it. At OOPSLA 200,
Eclipse developers demonstrated the Refactoring support in Eclipse.
They stressed that refactoring should not alter a program's behavior.
536デフォルトの名無しさん
2014/11/30(日) 13:52:53.51ID:kUIpsKvT537デフォルトの名無しさん
2014/11/30(日) 14:03:15.99ID:+4cKqP8L538デフォルトの名無しさん
2014/11/30(日) 14:13:11.05ID:kUIpsKvT 別に何も拘束されてないけどなw
単にコードが読みやすくなるだけ。
人とコンパイラにとって可読性が高いコードになる。
可読性が高いから理解しやすく、理解した情報を使って
バグが少なく開発のサポートができるようになるわけ
単にコードが読みやすくなるだけ。
人とコンパイラにとって可読性が高いコードになる。
可読性が高いから理解しやすく、理解した情報を使って
バグが少なく開発のサポートができるようになるわけ
539デフォルトの名無しさん
2014/11/30(日) 15:35:01.93ID:/BRxH/wW REPLとかで「このオブジェクトって何ができるんだっけ?」って調べるのは
動的言語では典型的な開発手法で、恩恵に預かってる開発者は多いと思うけど
静的型の補完も一緒だよ
単純にタイプ数をちょっと減らすとか、そういう話じゃない
動的言語では典型的な開発手法で、恩恵に預かってる開発者は多いと思うけど
静的型の補完も一緒だよ
単純にタイプ数をちょっと減らすとか、そういう話じゃない
540デフォルトの名無しさん
2014/11/30(日) 15:37:46.89ID:qocW+y5a 何のメソッド使うか分かってるんならヘボい補完でも十分じゃね?
541デフォルトの名無しさん
2014/11/30(日) 15:58:11.94ID:rR9TrKjV 全部把握できる程度のチープなライブラリを使って
一人で小さなプログラムを開発するなら
ヘボい補完でも十分じゃね?
一人で小さなプログラムを開発するなら
ヘボい補完でも十分じゃね?
542デフォルトの名無しさん
2014/11/30(日) 16:11:04.82ID:UnYKruMf543デフォルトの名無しさん
2014/11/30(日) 16:19:35.18ID:360iudbJ >>535
わかった。では1999年ではどうだ?
Remove Class
Rename Class
Remove Instance Variable
Rename Instance Variable
Abstract Instance Variable
Create Accessors for Instance Variable
Remove Class Variable
Rename Class Variable
Abstract Class Variable
Create Accessors for Class Variable
Remove Method
Rename Method
Add Parameter to Method
Remove Parameter from Method
Rename Temporary
Inline Temporary
Convert Temporary to Instance Variable
Extract Code as Temporary
Extract Code as Method
Convert Superclass to Sibling
Inline Call
Push Up/Down Method
Push Up/Down Instance Variable
Push Up/Down Class Variable
Move Method to Component
Convert Instance Variable to ValueHolder
Protect Instance Variable
Move Temporary to Inner Scope
http://twiki.cin.ufpe.br/twiki/pub/SPG/WeeklySeminar/PracticalAnalysisForRefactoringDonRoberts1999.pdf
わかった。では1999年ではどうだ?
Remove Class
Rename Class
Remove Instance Variable
Rename Instance Variable
Abstract Instance Variable
Create Accessors for Instance Variable
Remove Class Variable
Rename Class Variable
Abstract Class Variable
Create Accessors for Class Variable
Remove Method
Rename Method
Add Parameter to Method
Remove Parameter from Method
Rename Temporary
Inline Temporary
Convert Temporary to Instance Variable
Extract Code as Temporary
Extract Code as Method
Convert Superclass to Sibling
Inline Call
Push Up/Down Method
Push Up/Down Instance Variable
Push Up/Down Class Variable
Move Method to Component
Convert Instance Variable to ValueHolder
Protect Instance Variable
Move Temporary to Inner Scope
http://twiki.cin.ufpe.br/twiki/pub/SPG/WeeklySeminar/PracticalAnalysisForRefactoringDonRoberts1999.pdf
544デフォルトの名無しさん
2014/11/30(日) 16:33:33.88ID:/BRxH/wW >>543
静的型と動的型で同じ「Rename method」というリファクタリング機能をサポートしていると言っても、
動的型のそれは http.connect のメソッド名を変更したら
無関係な db.connect のメソッド名も変わってしまうような代物だろう
静的型と動的型で同じ「Rename method」というリファクタリング機能をサポートしていると言っても、
動的型のそれは http.connect のメソッド名を変更したら
無関係な db.connect のメソッド名も変わってしまうような代物だろう
545デフォルトの名無しさん
2014/11/30(日) 16:45:52.62ID:ZfpKb0dS546デフォルトの名無しさん
2014/11/30(日) 16:52:19.04ID:+4cKqP8L 動的言語における効率とは「問題の棚上げ・先送り」と表裏一体であり
問題の発見・防止が重視される大規模開発とは真逆の志向である
問題の発見・防止が重視される大規模開発とは真逆の志向である
547デフォルトの名無しさん
2014/11/30(日) 16:54:52.49ID:360iudbJ >>544
そんなことをする馬鹿にはリファクタリングツールの使用はお勧めできない。
そんなことをする馬鹿にはリファクタリングツールの使用はお勧めできない。
548デフォルトの名無しさん
2014/11/30(日) 16:58:31.17ID:rR9TrKjV >>547
一番のバカは使い物ならないツールを作ってる動的言語の連中だな
一番のバカは使い物ならないツールを作ってる動的言語の連中だな
549デフォルトの名無しさん
2014/11/30(日) 17:02:44.20ID:UnYKruMf550デフォルトの名無しさん
2014/11/30(日) 17:04:54.56ID:qFjB73Ro コンピュータにやらせるなんてアホ
脳が腐る。
人間がシコシコ変換するることで
ボケが防止される
脳が腐る。
人間がシコシコ変換するることで
ボケが防止される
551デフォルトの名無しさん
2014/11/30(日) 17:10:09.29ID:7WEYW95R >>546
そうなんだよね。結局問題を先送りしてるだけ。
だいたいさ、コードの中でこの変数(httpとか)は
connectを呼び出しているって書いているから
この変数はconnectを持っている型だって決まってるわけだよね。
動的型付けであっても、型は決まってる。
だからそのことをコードに書いておけばいいわけよ。
それが変数の型宣言というもの。
型宣言しておけば、コードとその型に矛盾が起きるような修正が
発生した時、それをすぐにコンピュータが検出できる。
検出した問題を人間がみた時にも、すぐにその原因がわかりやすい。
どうせコードでは型は特定の型じゃないと動かないんだから
その型であるって明示しておけばもっと便利になる。
動的型付けでは不可能なレベルの完璧な補完っていうのも
その高度なコード解析能力の一端にすぎないんだよ。
そうなんだよね。結局問題を先送りしてるだけ。
だいたいさ、コードの中でこの変数(httpとか)は
connectを呼び出しているって書いているから
この変数はconnectを持っている型だって決まってるわけだよね。
動的型付けであっても、型は決まってる。
だからそのことをコードに書いておけばいいわけよ。
それが変数の型宣言というもの。
型宣言しておけば、コードとその型に矛盾が起きるような修正が
発生した時、それをすぐにコンピュータが検出できる。
検出した問題を人間がみた時にも、すぐにその原因がわかりやすい。
どうせコードでは型は特定の型じゃないと動かないんだから
その型であるって明示しておけばもっと便利になる。
動的型付けでは不可能なレベルの完璧な補完っていうのも
その高度なコード解析能力の一端にすぎないんだよ。
552デフォルトの名無しさん
2014/11/30(日) 17:23:36.91ID:360iudbJ >>548
くやしいのうwwwくやしいのうwww
>>551
否定はしないけれど、視点の違いとか「ものは言いよう」という側面もあるな。
「真のソフトウェア工学が開発されるまでの次善の策は、
あらゆる要素について極端に遅延結合な動的システムを使って開発する事だ。」
http://metatoys.org/oxymoron/oxymoron.html
くやしいのうwwwくやしいのうwww
>>551
否定はしないけれど、視点の違いとか「ものは言いよう」という側面もあるな。
「真のソフトウェア工学が開発されるまでの次善の策は、
あらゆる要素について極端に遅延結合な動的システムを使って開発する事だ。」
http://metatoys.org/oxymoron/oxymoron.html
553デフォルトの名無しさん
2014/11/30(日) 17:25:33.97ID:tVFfE2xZ まあ中規模くらいなら動的言語の気楽さ>静的言語の堅牢性だけど
大規模になって全体のコードを把握できなくなると気楽さ<堅牢性になるよね
大規模になって全体のコードを把握できなくなると気楽さ<堅牢性になるよね
554デフォルトの名無しさん
2014/11/30(日) 17:37:33.47ID:7WEYW95R555デフォルトの名無しさん
2014/11/30(日) 17:40:58.65ID:7WEYW95R >>552
その頃言われていた「遅延結合」っていうのは、
遅延ではない結合、つまり特定の型以外には結合しないという意味で
それを解決したのが、継承やインターフェースでしょう。
継承やインターフェースは、指定した型+その型を継承したもの
(もしくはインターフェースを持っているもの)に
動的に結合しているわけで、遅延結合になっている。
その頃言われていた「遅延結合」っていうのは、
遅延ではない結合、つまり特定の型以外には結合しないという意味で
それを解決したのが、継承やインターフェースでしょう。
継承やインターフェースは、指定した型+その型を継承したもの
(もしくはインターフェースを持っているもの)に
動的に結合しているわけで、遅延結合になっている。
556デフォルトの名無しさん
2014/11/30(日) 17:41:53.12ID:guVElZZq 静的言語だとテスト工数が減るとか、動的言語だとテスト工数が増えるとかあるの?
557デフォルトの名無しさん
2014/11/30(日) 17:47:36.29ID:7WEYW95R >>556
コンパイルエラーをミスと考えるかバグと考えるかで話が違う。
テストはバグを見つけるもの。
だから普通はコンパイルエラーによるミスは
テストで見つけるものではない。
だから本当の意味でのテストの量は同じだが、問題はミス。
静的型付け言語ならミスは、ミスとしてテストの前段階で弾くことができるが、
動的型付け言語だと、テストの段階で弾くことになる。
(しかも静的型付け言語ならミスは修正箇所をコンピュータが示すから素早く解決できるが、
動的型付け言語だとバグを探すのと同じ作業をしないといけなくなる)
そういう点で、動的型付け言語ではテストでやるべきことが
増えるのでテスト工数が増えることになる。
コンパイルエラーをミスと考えるかバグと考えるかで話が違う。
テストはバグを見つけるもの。
だから普通はコンパイルエラーによるミスは
テストで見つけるものではない。
だから本当の意味でのテストの量は同じだが、問題はミス。
静的型付け言語ならミスは、ミスとしてテストの前段階で弾くことができるが、
動的型付け言語だと、テストの段階で弾くことになる。
(しかも静的型付け言語ならミスは修正箇所をコンピュータが示すから素早く解決できるが、
動的型付け言語だとバグを探すのと同じ作業をしないといけなくなる)
そういう点で、動的型付け言語ではテストでやるべきことが
増えるのでテスト工数が増えることになる。
558デフォルトの名無しさん
2014/11/30(日) 18:12:40.43ID:c9Q+Jt/4 >>536
制約だな。
制約だな。
559デフォルトの名無しさん
2014/11/30(日) 18:24:06.55ID:7WEYW95R >>558
それを言うなら、契約って言ったほうがかっこいいな。
契約プログラミングといえば、EiffelとD言語ぐらいだけど、
型っていうのもある意味契約だからね。
この引数は、○型であるという事前条件
この関数は、○型を返すという事後条件
それを言うなら、契約って言ったほうがかっこいいな。
契約プログラミングといえば、EiffelとD言語ぐらいだけど、
型っていうのもある意味契約だからね。
この引数は、○型であるという事前条件
この関数は、○型を返すという事後条件
560デフォルトの名無しさん
2014/11/30(日) 18:24:17.69ID:uRzHHhxu なんだ
このスレの静的厨は静的型が制約だということも理解せずに喚いてたのか
初心者としても筋が悪いな
このスレの静的厨は静的型が制約だということも理解せずに喚いてたのか
初心者としても筋が悪いな
561デフォルトの名無しさん
2014/11/30(日) 18:25:23.77ID:tHR3Cg3X ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの?
template<typename T> void f(T func)
みたいないわゆるダックタイピング
template<typename T> void f(T func)
みたいないわゆるダックタイピング
562デフォルトの名無しさん
2014/11/30(日) 18:26:57.46ID:mFsly3WX >>534
Static Typing vs. Dynamic Typing という対比はよく見かける
しかし structural subtyping vs. duck typing という対比は知らないね
もし「いくらでも目にする」のなら、ソース(学術的文献)を示せばいい
簡単な事だろ?
ましてや
> 「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
>「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
なんて奇妙な主張は聞いたことが無い
blog記事を批判するつもりはないが、そんな個人メモを元にして
「動的型言語の補完がどうあるべきかの指標になる(>>533)」と主張するのは
馬鹿だってこと
Static Typing vs. Dynamic Typing という対比はよく見かける
しかし structural subtyping vs. duck typing という対比は知らないね
もし「いくらでも目にする」のなら、ソース(学術的文献)を示せばいい
簡単な事だろ?
ましてや
> 「構造的部分型付けは公称的部分型付けとダックタイピングの間に位置する」あるいは
>「構造的部分型付けは公称的部分型付けとダックタイピングとのハイブリッドである」
なんて奇妙な主張は聞いたことが無い
blog記事を批判するつもりはないが、そんな個人メモを元にして
「動的型言語の補完がどうあるべきかの指標になる(>>533)」と主張するのは
馬鹿だってこと
563デフォルトの名無しさん
2014/11/30(日) 18:31:27.03ID:7WEYW95R >>561
> ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの?
┃ template<typename T>┃ void f(T func)
↑ ここからここまでが、型 ↑
HOGE_T void f(T func)
置き換えるならこんなふうに捉えてる。
> みたいないわゆるダックタイピング
それをダックタイピングとは言わない。
> ここの人たちにとってC++のテンプレートを引数に取る関数ってどういうふうに捉えられてるの?
┃ template<typename T>┃ void f(T func)
↑ ここからここまでが、型 ↑
HOGE_T void f(T func)
置き換えるならこんなふうに捉えてる。
> みたいないわゆるダックタイピング
それをダックタイピングとは言わない。
564デフォルトの名無しさん
2014/11/30(日) 18:36:30.75ID:uRzHHhxu そもそもduck typing自体まともな定義はない
565デフォルトの名無しさん
2014/11/30(日) 18:44:16.77ID:/BRxH/wW function foo(a) {
a.bar()
}
bar() を呼び出せるなら何でも foo の引数に入れられるのが
ダックタイピングというのはどうだろうか
このスレだけでも
a.bar()
}
bar() を呼び出せるなら何でも foo の引数に入れられるのが
ダックタイピングというのはどうだろうか
このスレだけでも
566デフォルトの名無しさん
2014/11/30(日) 19:22:49.09ID:7WEYW95R > bar() を呼び出せるなら何でも foo の引数に入れられるのが
それってさfoo関数の引数 aはbarメソッドを
持った型ではなければならないってことだよね?
コードに書くならば
function foo(/* fooメソッドを持った型 */ a) {
a.bar()
}
それってさfoo関数の引数 aはbarメソッドを
持った型ではなければならないってことだよね?
コードに書くならば
function foo(/* fooメソッドを持った型 */ a) {
a.bar()
}
567デフォルトの名無しさん
2014/11/30(日) 19:26:23.25ID:7WEYW95R 間違えたw
function foo(/* barメソッドを持った型 */ a) {
a.bar()
}
そして、大概は一つのメソッドだけ使うことはないから、
function foo(/* barとbazメソッドを持った型 */ a) {
a.bar()
a.baz()
}
あぁ!もう面倒くさい。
// Hogeインターフェース = barとbazメソッドを持っていること
function foo(Hoge a) {
a.bar()
a.baz()
}
わかりやすい。Hogeってみるだけで barとbazを持っていることがわかるし
もし持っていないものをaに入れるコードを書いたらコンパイルエラーが出る
function foo(/* barメソッドを持った型 */ a) {
a.bar()
}
そして、大概は一つのメソッドだけ使うことはないから、
function foo(/* barとbazメソッドを持った型 */ a) {
a.bar()
a.baz()
}
あぁ!もう面倒くさい。
// Hogeインターフェース = barとbazメソッドを持っていること
function foo(Hoge a) {
a.bar()
a.baz()
}
わかりやすい。Hogeってみるだけで barとbazを持っていることがわかるし
もし持っていないものをaに入れるコードを書いたらコンパイルエラーが出る
568デフォルトの名無しさん
2014/11/30(日) 19:32:01.35ID:/BRxH/wW569デフォルトの名無しさん
2014/11/30(日) 19:47:43.07ID:7WEYW95R http.connectを呼び出す関数に、
db.connectというメソッドを持ったオブジェクトを
入れても期待通りに動くことはまず無い。
二つの無関係なオブジェクトが同名のメソッドを持っていて
呼び出せるからといって、それはバグにしかならない。
メソッドに名前空間がないような形で使う動的型付け言語では
このような問題が起きる。
静的型付け言語ではインターフェースという型を定義することで、
同名であっても本質的に違うものは、違うものとして扱うことが出来る
db.connectというメソッドを持ったオブジェクトを
入れても期待通りに動くことはまず無い。
二つの無関係なオブジェクトが同名のメソッドを持っていて
呼び出せるからといって、それはバグにしかならない。
メソッドに名前空間がないような形で使う動的型付け言語では
このような問題が起きる。
静的型付け言語ではインターフェースという型を定義することで、
同名であっても本質的に違うものは、違うものとして扱うことが出来る
570デフォルトの名無しさん
2014/11/30(日) 19:53:09.38ID:VpMFGcKd どんな御託を並べても
インターフェースがduck typingは無いわw
インターフェースがduck typingは無いわw
571デフォルトの名無しさん
2014/11/30(日) 19:56:23.78ID:7WEYW95R インターフェースがduck typingなどとは
ひとことも言ってない。
duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルでしか無い。
アヒルだ、空を飛べ。人間は飛べません。はいバグです。
実際には鳴くメソッドがあればアヒルである
ということになって更に意味がわからない。
もちろん、アヒルである条件をインターフェースとして定義しているならば
そのインターフェースを備えているものは、アヒルでいいですがね。
メソッド一つが有るか無いかきめんなよ。
ひとことも言ってない。
duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルでしか無い。
アヒルだ、空を飛べ。人間は飛べません。はいバグです。
実際には鳴くメソッドがあればアヒルである
ということになって更に意味がわからない。
もちろん、アヒルである条件をインターフェースとして定義しているならば
そのインターフェースを備えているものは、アヒルでいいですがね。
メソッド一つが有るか無いかきめんなよ。
572デフォルトの名無しさん
2014/11/30(日) 19:57:27.20ID:7WEYW95R 訂正
duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルにはならない
duck typingは不要。ガアガアと鳴いたからたから
といって人間はアヒルにはならない
573デフォルトの名無しさん
2014/11/30(日) 19:59:03.44ID:360iudbJ >>562
ググるとかしたことないのかね。
ググるとかしたことないのかね。
574デフォルトの名無しさん
2014/11/30(日) 20:01:50.38ID:7WEYW95R したことある人が、リンクを見つけてきて
ここに書けばいいと思いますが、
それを要求することは酷なことですね。
だってググっても見つからないのだから。
ここに書けばいいと思いますが、
それを要求することは酷なことですね。
だってググっても見つからないのだから。
575デフォルトの名無しさん
2014/11/30(日) 20:04:43.51ID:7WEYW95R ダックタイピングの説明として
「アヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
という言葉があるが、
それを、
アヒルのように歩くとアヒルのように鳴くという
アヒルインターフェースを実装しているものはアヒルである。
というふうに読み替えると
これは実は静的型付け言語の説明だなとわかるはずである。
「アヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである」
という言葉があるが、
それを、
アヒルのように歩くとアヒルのように鳴くという
アヒルインターフェースを実装しているものはアヒルである。
というふうに読み替えると
これは実は静的型付け言語の説明だなとわかるはずである。
576デフォルトの名無しさん
2014/11/30(日) 20:09:27.69ID:VpMFGcKd >>569
mysql.connect と postgresql.connect は置き換え可能だけど?
mysql.connect と postgresql.connect は置き換え可能だけど?
577デフォルトの名無しさん
2014/11/30(日) 20:11:34.14ID:VpMFGcKd578デフォルトの名無しさん
2014/11/30(日) 20:15:01.73ID:7WEYW95R >>576
両方が同じデータベースインターフェースを
サポートしているならばそうだろうね。
現実的な話をするならば、mysql.connect を
使うコードは、実際にはmysql.connect だけを
使うことはなく、複数のメソッドを使う。
だから、その複数のメソッドというものを
定義しないといけない。
そしてその定義したものがインターフェースであり
そのインターフェースを使いますよと宣言するのが
型宣言なのである。
そうすればある型がデータベースインターフェースを
定義していることを保証する型宣言だけあれば、
全てのメソッドを安心して使うことが出来る。
このオブジェクトはconnectメソッドは持ってるけど、
disconnectメソッドを持っていないかもしれない
なんてことはなくなるのである。
両方が同じデータベースインターフェースを
サポートしているならばそうだろうね。
現実的な話をするならば、mysql.connect を
使うコードは、実際にはmysql.connect だけを
使うことはなく、複数のメソッドを使う。
だから、その複数のメソッドというものを
定義しないといけない。
そしてその定義したものがインターフェースであり
そのインターフェースを使いますよと宣言するのが
型宣言なのである。
そうすればある型がデータベースインターフェースを
定義していることを保証する型宣言だけあれば、
全てのメソッドを安心して使うことが出来る。
このオブジェクトはconnectメソッドは持ってるけど、
disconnectメソッドを持っていないかもしれない
なんてことはなくなるのである。
579デフォルトの名無しさん
2014/11/30(日) 20:16:45.31ID:nRiDRl39 足し算と掛け算のある型なら複素数でも行列でも良いとかいうパターンは有るな
580デフォルトの名無しさん
2014/11/30(日) 20:21:32.59ID:7WEYW95R 足し算をaddメソッドだとして、
addメソッドさえあればなんでも使えるかというと
(addメソッドでググって一番目にでてきた)
> Addメソッドとはエクセルのシートに表とグラフを同時に表示するメソッドです。
に対してもうまく動くことはおそらくないだろう。
つまり名前が一緒でも、正しく動くとは限らんのさ。
だから名前と意味が一緒であることを保証するために
名前をつけたものが型なのである。
addメソッドさえあればなんでも使えるかというと
(addメソッドでググって一番目にでてきた)
> Addメソッドとはエクセルのシートに表とグラフを同時に表示するメソッドです。
に対してもうまく動くことはおそらくないだろう。
つまり名前が一緒でも、正しく動くとは限らんのさ。
だから名前と意味が一緒であることを保証するために
名前をつけたものが型なのである。
581デフォルトの名無しさん
2014/11/30(日) 20:24:10.20ID:T2KLr1TM >>575
アヒルのインスタンスを実行時にその振る舞いから分類するところがポイントなのであって
アヒルというクラスに対してコンパイル時に分類するのはダックタイピングじゃないよ
というわけでダックタイピングはインターフェースや構造的部分型とは全く別
アヒルのインスタンスを実行時にその振る舞いから分類するところがポイントなのであって
アヒルというクラスに対してコンパイル時に分類するのはダックタイピングじゃないよ
というわけでダックタイピングはインターフェースや構造的部分型とは全く別
582デフォルトの名無しさん
2014/11/30(日) 20:25:36.35ID:VpMFGcKd >>580
Excelのaddメソッドは戻り値の型が違うだろ
Excelのaddメソッドは戻り値の型が違うだろ
583デフォルトの名無しさん
2014/11/30(日) 20:25:53.73ID:T2KLr1TM >>580
だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ
だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ
584デフォルトの名無しさん
2014/11/30(日) 20:26:04.76ID:7WEYW95R アヒルのインスタンスを実行時にその振る舞いから分類というけれど、
コード自体は、実行時に分類してないんだよ。
コードは、アヒルであること、を前提として書いてる。
実行前にコードで分類しているのに、
なぜ実行時に分類しないといけないのか。
型は動的に変わるが、コードは静的なのである。
コード自体は、実行時に分類してないんだよ。
コードは、アヒルであること、を前提として書いてる。
実行前にコードで分類しているのに、
なぜ実行時に分類しないといけないのか。
型は動的に変わるが、コードは静的なのである。
585デフォルトの名無しさん
2014/11/30(日) 20:28:54.03ID:7WEYW95R >>583
> だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ
だから大規模では無理なんだよ。
大規模=大多数の人間が係る。場合によっては全く知らない人が作った
ライブラリを使うこともあるしな。
そんなんで、すべて意味を揃えるなんてことは不可能
いくつもの意味を持つ英単語なんてざらにある
単語の意味を揃えるのは不可能。というのが大前提
> だから同じ「意味」に対して名前を揃えるのが動的言語でのメソッド名のつけ方だ
だから大規模では無理なんだよ。
大規模=大多数の人間が係る。場合によっては全く知らない人が作った
ライブラリを使うこともあるしな。
そんなんで、すべて意味を揃えるなんてことは不可能
いくつもの意味を持つ英単語なんてざらにある
単語の意味を揃えるのは不可能。というのが大前提
586デフォルトの名無しさん
2014/11/30(日) 20:29:37.63ID:T2KLr1TM587デフォルトの名無しさん
2014/11/30(日) 20:30:01.03ID:/BRxH/wW588デフォルトの名無しさん
2014/11/30(日) 20:31:08.34ID:T2KLr1TM589デフォルトの名無しさん
2014/11/30(日) 20:33:46.05ID:SVLUkCya >>588
SmalltalkでObjectに500もメソッドなんてねーよw
あったとしたら、アンチパターン ゴッドクラス
(設計の一部分(クラス)に、過剰に機能を集中させること)に
適合してしまうわw
SmalltalkでObjectに500もメソッドなんてねーよw
あったとしたら、アンチパターン ゴッドクラス
(設計の一部分(クラス)に、過剰に機能を集中させること)に
適合してしまうわw
590デフォルトの名無しさん
2014/11/30(日) 20:34:01.13ID:T2KLr1TM >>587
分岐(メソッド探索)の話などしていない
どの式がどのインターフェースを実装しているのかを実行時に検査してるのか?
どの式がどの型の部分型かを実行時に検査しているのか?
へー、それ、なんていう言語だい?
分岐(メソッド探索)の話などしていない
どの式がどのインターフェースを実装しているのかを実行時に検査してるのか?
どの式がどの型の部分型かを実行時に検査しているのか?
へー、それ、なんていう言語だい?
591デフォルトの名無しさん
2014/11/30(日) 20:36:14.22ID:TE77vkUw592デフォルトの名無しさん
2014/11/30(日) 20:36:20.46ID:VpMFGcKd >>585
大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
同じ意味の機能に同じインターフェースを持たせるのは不可能
インターフェース方式は、ある数値計算ライブラリと別の行列演算ライブラリを混ぜて使う場合などで問題になる
大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
同じ意味の機能に同じインターフェースを持たせるのは不可能
インターフェース方式は、ある数値計算ライブラリと別の行列演算ライブラリを混ぜて使う場合などで問題になる
593デフォルトの名無しさん
2014/11/30(日) 20:40:02.67ID:/BRxH/wW >>590
実行時にvalidationするのがダックタイピングというなら
構造的部分型は確かに違うな
"If it walks like a duck and quacks like a duck, it must be a duck"
という文章からそのような意味を読み取るのは無理だが
実行時にvalidationするのがダックタイピングというなら
構造的部分型は確かに違うな
"If it walks like a duck and quacks like a duck, it must be a duck"
という文章からそのような意味を読み取るのは無理だが
594デフォルトの名無しさん
2014/11/30(日) 20:40:22.76ID:SVLUkCya >>591
> Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw
最悪だな。JavaScriptでprototypejsっていうのがあったけど、
名前が標準のメソッドとobjectに追加したメソッド名が
被って大変な目にあっていた。
それ移行Objectにメソッドを追加するのは
ダメなやり方だって広く知られるようになったね。
> Smalltalkでは色々なパッケージがObjectクラスにメソッドを追加していくんだよw
最悪だな。JavaScriptでprototypejsっていうのがあったけど、
名前が標準のメソッドとobjectに追加したメソッド名が
被って大変な目にあっていた。
それ移行Objectにメソッドを追加するのは
ダメなやり方だって広く知られるようになったね。
595デフォルトの名無しさん
2014/11/30(日) 20:40:39.28ID:360iudbJ >>570
いや。duck typing とは言わないけれど、Smalltalk の動的型と
同様の柔軟性を持たせつつ型安全を目指したのがインターフェイス。
(Eiffel流のクラスの継承をサブタイプに使うと型安全でないという流れで)
http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf
いや。duck typing とは言わないけれど、Smalltalk の動的型と
同様の柔軟性を持たせつつ型安全を目指したのがインターフェイス。
(Eiffel流のクラスの継承をサブタイプに使うと型安全でないという流れで)
http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf
596デフォルトの名無しさん
2014/11/30(日) 20:43:21.18ID:/BRxH/wW597デフォルトの名無しさん
2014/11/30(日) 20:45:52.98ID:TE77vkUw >>593
If it walks like a duckというのは、実際のitの振る舞いのことを指しているのだから実行時のことだと考えるのが自然だと思うが?
If it will walk like a duckならばコンパイルだろうけどな。
If it walks like a duckというのは、実際のitの振る舞いのことを指しているのだから実行時のことだと考えるのが自然だと思うが?
If it will walk like a duckならばコンパイルだろうけどな。
598デフォルトの名無しさん
2014/11/30(日) 20:47:16.39ID:TE77vkUw599デフォルトの名無しさん
2014/11/30(日) 20:48:14.19ID:360iudbJ600デフォルトの名無しさん
2014/11/30(日) 20:51:13.03ID:TE77vkUw >>592
>大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
>同じ意味の機能に同じインターフェースを持たせるのは不可能
そういう初心者は補助輪(静的型)を使えばいいよw
ちなみに動的言語の環境では
様々なライブラリでどういうメソッド名がつけられているか検索する仕組みと
指定したメソッド名のメソッドを検索する仕組みが
遥か80年代から用意されていたりするけどなw
>大規模なシステムは作者が異なる様々なライブラリを使うが、違うライブラリ間で
>同じ意味の機能に同じインターフェースを持たせるのは不可能
そういう初心者は補助輪(静的型)を使えばいいよw
ちなみに動的言語の環境では
様々なライブラリでどういうメソッド名がつけられているか検索する仕組みと
指定したメソッド名のメソッドを検索する仕組みが
遥か80年代から用意されていたりするけどなw
601デフォルトの名無しさん
2014/11/30(日) 20:53:54.80ID:TE77vkUw >>599
動的言語では全オブジェクト共通の語彙が重要だから当然そうなる
動的言語では全オブジェクト共通の語彙が重要だから当然そうなる
602デフォルトの名無しさん
2014/11/30(日) 20:56:59.55ID:360iudbJ603デフォルトの名無しさん
2014/11/30(日) 21:05:38.46ID:/BRxH/wW604デフォルトの名無しさん
2014/11/30(日) 21:09:31.70ID:360iudbJ >>601
とはいえ、Squeak のカオス化に嫌気してフォークされた Pharo は
だいぶ減らして 374 だし(3.0調べ)、VisualWorks はもとより 303(7.10調べ)だけどね。
とはいえ、Squeak のカオス化に嫌気してフォークされた Pharo は
だいぶ減らして 374 だし(3.0調べ)、VisualWorks はもとより 303(7.10調べ)だけどね。
605デフォルトの名無しさん
2014/11/30(日) 21:10:47.94ID:VpMFGcKd606デフォルトの名無しさん
2014/11/30(日) 21:13:30.42ID:VpMFGcKd607デフォルトの名無しさん
2014/11/30(日) 21:15:20.91ID:guVElZZq >>599
Pharo 3.0 は、374
Pharo 3.0 は、374
608デフォルトの名無しさん
2014/11/30(日) 21:17:02.28ID:guVElZZq >604 で既出だった orz
609デフォルトの名無しさん
2014/11/30(日) 21:30:34.30ID:360iudbJ610デフォルトの名無しさん
2014/11/30(日) 21:50:46.91ID:mFsly3WX >>595
>いや。duck typing とは言わないけれど、
引用した論文は静的型付け言語における継承の意味論モデルに関する内容であり、
duck typing や interface とは直接的に関係してない
Smalltalk における継承の意味について、Effel は Smalltalk と同じように柔軟だけど型安全ではなく、
Modula-3 や C++ は型安全だけど Smalltalk とは意味が異なる
この論文では、Smalltalk と同じ継承の意味を持ちかつ安全な新しい意味論モデルを提案している
まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね
なお、ここで言う「継承の意味」とは、具体的には Smalltalk の疑似変数 self や super のこと
たとえば Smalltalk と同じ意味論を持つ Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ
それに対して、Smalltalk とは異なる意味論の Modula-3 を参考にして継承が設計された Python では
self や super に相当する疑似変数は存在せず、わざわざメソッドの引数で __self__ を明示しなければならない
結果として Python は動的型付け言語であるにもかかわらず、Smalltalk や Ruby と同等レベルの柔軟な
オブジェクト指向プログラミングができないという言語設計上の欠陥を抱えている
この意味論モデルは、以下の論文で詳細に解説されている
http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf
>いや。duck typing とは言わないけれど、
引用した論文は静的型付け言語における継承の意味論モデルに関する内容であり、
duck typing や interface とは直接的に関係してない
Smalltalk における継承の意味について、Effel は Smalltalk と同じように柔軟だけど型安全ではなく、
Modula-3 や C++ は型安全だけど Smalltalk とは意味が異なる
この論文では、Smalltalk と同じ継承の意味を持ちかつ安全な新しい意味論モデルを提案している
まったく無関係な論文を引用して、いったい何を言いたいのか意味不明だね
なお、ここで言う「継承の意味」とは、具体的には Smalltalk の疑似変数 self や super のこと
たとえば Smalltalk と同じ意味論を持つ Ruby では(Smalltalk と同様な)疑似変数 self と super を持つ
それに対して、Smalltalk とは異なる意味論の Modula-3 を参考にして継承が設計された Python では
self や super に相当する疑似変数は存在せず、わざわざメソッドの引数で __self__ を明示しなければならない
結果として Python は動的型付け言語であるにもかかわらず、Smalltalk や Ruby と同等レベルの柔軟な
オブジェクト指向プログラミングができないという言語設計上の欠陥を抱えている
この意味論モデルは、以下の論文で詳細に解説されている
http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf
611デフォルトの名無しさん
2014/11/30(日) 22:04:51.19ID:SVLUkCya オブジェクト指向プログラミングをするのが目的ではない。
巨大なシステムをより早くより安全に開発するのが目的なのだ。
巨大なシステムをより早くより安全に開発するのが目的なのだ。
612デフォルトの名無しさん
2014/11/30(日) 22:11:54.90ID:rR9TrKjV オブジェクト指向上の欠陥とやらが何か知らんが、
そのお陰で実用レベルの型推論(補完や型検査)が出来てるなら面白いな
そのお陰で実用レベルの型推論(補完や型検査)が出来てるなら面白いな
613デフォルトの名無しさん
2014/11/30(日) 22:22:44.40ID:SVLUkCya 人間が間違わずに全てのコードを脳に記憶して
タイプミスすらしないことを前提にするならば、
コードにわざわざ記憶の断片(つまり型情報)を書く必要はないよ。
それができないから、型情報を書いたほうが
わずかの手間だけで、そのあとずっと楽ができるわけで。
タイプミスすらしないことを前提にするならば、
コードにわざわざ記憶の断片(つまり型情報)を書く必要はないよ。
それができないから、型情報を書いたほうが
わずかの手間だけで、そのあとずっと楽ができるわけで。
614デフォルトの名無しさん
2014/11/30(日) 22:32:19.86ID:360iudbJ >>570
すまん。こっちだった。
Interfaces for Strongly-Typed Object-Oriented Programming
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf
すまん。こっちだった。
Interfaces for Strongly-Typed Object-Oriented Programming
http://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf
615デフォルトの名無しさん
2014/11/30(日) 22:48:40.83ID:mFsly3WX >>612
>オブジェクト指向上の欠陥とやらが何か知らんが、
有名な Python のself地獄だよ
キーワード「python self地獄」で検索すればGoogle先生が教えてくれる
Python しか知らなければself地獄が気にならないかもしれないけど、
Smalltalk や Ruby を知っている人からすれば、無知は幸せだなぁと見る
これの基礎が「継承の意味論における差異」になる
なお単に意味論の違いだから、self地獄と引き換えに
実用的な型推論(補完や型検査)が手に入るわけではない
両者の間に直接的な関連性は無い(言い換えるとスレチな話題)
>オブジェクト指向上の欠陥とやらが何か知らんが、
有名な Python のself地獄だよ
キーワード「python self地獄」で検索すればGoogle先生が教えてくれる
Python しか知らなければself地獄が気にならないかもしれないけど、
Smalltalk や Ruby を知っている人からすれば、無知は幸せだなぁと見る
これの基礎が「継承の意味論における差異」になる
なお単に意味論の違いだから、self地獄と引き換えに
実用的な型推論(補完や型検査)が手に入るわけではない
両者の間に直接的な関連性は無い(言い換えるとスレチな話題)
616デフォルトの名無しさん
2014/11/30(日) 22:53:53.26ID:rR9TrKjV617デフォルトの名無しさん
2014/11/30(日) 22:55:23.26ID:360iudbJ618デフォルトの名無しさん
2014/11/30(日) 22:55:36.39ID:/BRxH/wW619デフォルトの名無しさん
2014/11/30(日) 22:57:41.96ID:mFsly3WX >>614
この論文内では duck typing という用語は一度も使われていないし、
タイトルに Strongly-Typed と書かれているように静的型付け言語に関する内容だ
で、いったいどこから duck typing を連想したの?
この論文内では duck typing という用語は一度も使われていないし、
タイトルに Strongly-Typed と書かれているように静的型付け言語に関する内容だ
で、いったいどこから duck typing を連想したの?
620デフォルトの名無しさん
2014/11/30(日) 23:00:20.47ID:360iudbJ 典型的なアスペか。
621デフォルトの名無しさん
2014/11/30(日) 23:01:15.62ID:mFsly3WX622デフォルトの名無しさん
2014/11/30(日) 23:09:04.67ID:rR9TrKjV623デフォルトの名無しさん
2014/11/30(日) 23:09:46.51ID:tHR3Cg3X あれ?int型の+とstring型の+に対するオーバーロードみたいな話になってる?
無知なら口だすなと言われそうなので黙っておきます…
無知なら口だすなと言われそうなので黙っておきます…
624デフォルトの名無しさん
2014/11/30(日) 23:22:20.73ID:/BRxH/wW >>621
そうか。じゃあスレ違いの話は止めないと荒らしになってしまうな
そうか。じゃあスレ違いの話は止めないと荒らしになってしまうな
625デフォルトの名無しさん
2014/11/30(日) 23:27:42.56ID:mFsly3WX >>616
Python のオブジェクト指向は Modula-3 を参考にしているけど、
Modula-3 のオブジェクト指向は Simula を参考にしている
そして疑似変数 self の概念は Simula には存在せず、
Simula を参考にした Smalltalk で生まれた
だから、Modula-3 や Python に疑似変数 self は存在せず、
これを模倣するにはメソッド引数で明示的に __self__ を
渡さなければならない訳
あと疑似変数 self の値は実行時に決まるから、
もし Python で __self__ を省略できるようにするためには、
構文論(syntax)の変更すなわちパーザの改造だけではダメで、
意味論(semantics)も変更しなければならない
こうした背景も知らずに「変人だから」という理由で決めつけるのは、
Guido氏に失礼だと思うよ
Python のオブジェクト指向は Modula-3 を参考にしているけど、
Modula-3 のオブジェクト指向は Simula を参考にしている
そして疑似変数 self の概念は Simula には存在せず、
Simula を参考にした Smalltalk で生まれた
だから、Modula-3 や Python に疑似変数 self は存在せず、
これを模倣するにはメソッド引数で明示的に __self__ を
渡さなければならない訳
あと疑似変数 self の値は実行時に決まるから、
もし Python で __self__ を省略できるようにするためには、
構文論(syntax)の変更すなわちパーザの改造だけではダメで、
意味論(semantics)も変更しなければならない
こうした背景も知らずに「変人だから」という理由で決めつけるのは、
Guido氏に失礼だと思うよ
626デフォルトの名無しさん
2014/11/30(日) 23:31:44.94ID:guVElZZq もう、超優秀なIDEがあって動的構造取り入れた c# 最強って事で良いんじゃないの?
627デフォルトの名無しさん
2014/11/30(日) 23:42:47.38ID:UnYKruMf628デフォルトの名無しさん
2014/11/30(日) 23:43:33.56ID:mFsly3WX >>622
> 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ
そうだろ、だから驚いて >>619 では
>>で、いったいどこから duck typing を連想したの?
と書いた
論文を引用するのはいいけど、この論文をどう解釈して duck typing に結びつけたのか、
説明が無ければ意味が分からんという話だよ
>abstract斜め読みしただけだがSmalltalkには言及されてんぞ
Smalltalk の柔軟な継承を強い型付け(=静的型付け)なOO言語に取り込むために
インターフェイスを用いる、という文脈でね
動的型付けを濫用するというニュアンスを持つ duck typing とは何の関係も無い
この論文、型システムと言語設計に興味がある人にはとても有益だから、
斜め読みと言わずじっくり読んでみたほうがいいと思うな
> 1989年の論文にduck typingと言う用語が出てきたらそっちの方が驚くわ
そうだろ、だから驚いて >>619 では
>>で、いったいどこから duck typing を連想したの?
と書いた
論文を引用するのはいいけど、この論文をどう解釈して duck typing に結びつけたのか、
説明が無ければ意味が分からんという話だよ
>abstract斜め読みしただけだがSmalltalkには言及されてんぞ
Smalltalk の柔軟な継承を強い型付け(=静的型付け)なOO言語に取り込むために
インターフェイスを用いる、という文脈でね
動的型付けを濫用するというニュアンスを持つ duck typing とは何の関係も無い
この論文、型システムと言語設計に興味がある人にはとても有益だから、
斜め読みと言わずじっくり読んでみたほうがいいと思うな
629デフォルトの名無しさん
2014/11/30(日) 23:44:44.78ID:/BRxH/wW >>616
http://neopythonic.blogspot.jp/2008/10/why-explicit-self-has-to-stay.html
・ただの関数を、後からクラスにメソッドとして後付けできること(そのとき暗黙のselfの扱い)
・decoratorがあるから(動的にstatic methodやclass methodに変更できる)
というのが理由だそうだ
http://neopythonic.blogspot.jp/2008/10/why-explicit-self-has-to-stay.html
・ただの関数を、後からクラスにメソッドとして後付けできること(そのとき暗黙のselfの扱い)
・decoratorがあるから(動的にstatic methodやclass methodに変更できる)
というのが理由だそうだ
630デフォルトの名無しさん
2014/11/30(日) 23:49:11.15ID:guVElZZq >>627
Roslyn凄そうだが、どんだけのヤツが付いていけるんだろ。
Roslyn凄そうだが、どんだけのヤツが付いていけるんだろ。
631デフォルトの名無しさん
2014/11/30(日) 23:50:00.23ID:nRiDRl39632デフォルトの名無しさん
2014/11/30(日) 23:52:00.50ID:mFsly3WX633デフォルトの名無しさん
2014/11/30(日) 23:53:34.74ID:/BRxH/wW 言語だけでいうならRustに期待しているんだが……
634デフォルトの名無しさん
2014/11/30(日) 23:57:11.19ID:SVLUkCya635デフォルトの名無しさん
2014/11/30(日) 23:58:47.30ID:mFsly3WX >>634
おいおい、Python は動的型付け言語だよ
おいおい、Python は動的型付け言語だよ
636デフォルトの名無しさん
2014/11/30(日) 23:59:07.80ID:rR9TrKjV637デフォルトの名無しさん
2014/11/30(日) 23:59:36.82ID:UnYKruMf638デフォルトの名無しさん
2014/11/30(日) 23:59:39.73ID:guVElZZq >>631
dynamic型
dynamic型
639デフォルトの名無しさん
2014/12/01(月) 00:02:55.46ID:v1/AC0CB640デフォルトの名無しさん
2014/12/01(月) 00:04:29.77ID:JhMfQ7kZ >>636
いや、Procオブジェクトを明示的にコーディングするのは稀だ
クロージャの無い Python とは違って、
Ruby だと普通は do |x| ... end や { |x| .... } で書ける
いや、Procオブジェクトを明示的にコーディングするのは稀だ
クロージャの無い Python とは違って、
Ruby だと普通は do |x| ... end や { |x| .... } で書ける
641デフォルトの名無しさん
2014/12/01(月) 00:08:40.28ID:v1/AC0CB642デフォルトの名無しさん
2014/12/01(月) 00:11:50.96ID:WHPunuUw643デフォルトの名無しさん
2014/12/01(月) 00:13:16.83ID:2BTgZC4D 結局は、静的言語が動的言語の要素を取り入れて進化し、両方の境界が曖昧になるんだよ。
644デフォルトの名無しさん
2014/12/01(月) 00:15:06.71ID:JhMfQ7kZ >>641
逆だろw
クロージャを使えば簡潔に書けるのに、結局 Python ではコードが書けずに終わった
で、しまいに火病を発症してわめきちらしただけ、それがフルボッコなのか?www
今からでもいいから Python でコード書いてみな
逆だろw
クロージャを使えば簡潔に書けるのに、結局 Python ではコードが書けずに終わった
で、しまいに火病を発症してわめきちらしただけ、それがフルボッコなのか?www
今からでもいいから Python でコード書いてみな
645デフォルトの名無しさん
2014/12/01(月) 00:18:09.70ID:v1/AC0CB646デフォルトの名無しさん
2014/12/01(月) 00:20:09.36ID:JhMfQ7kZ >>640
ほう、Python で Soft Typing が実用化されたとは初耳だ
ググってみると2003年に提案はあったものの、
その後に実装されたという情報は見つけられなかった
本当に実用化されているの?
また嘘でも何でも議論に勝ちさえばいいという発想じゃないのかなあ....
ほう、Python で Soft Typing が実用化されたとは初耳だ
ググってみると2003年に提案はあったものの、
その後に実装されたという情報は見つけられなかった
本当に実用化されているの?
また嘘でも何でも議論に勝ちさえばいいという発想じゃないのかなあ....
647デフォルトの名無しさん
2014/12/01(月) 00:21:49.35ID:v1/AC0CB648デフォルトの名無しさん
2014/12/01(月) 00:28:35.48ID:v1/AC0CB649デフォルトの名無しさん
2014/12/01(月) 00:29:56.57ID:JhMfQ7kZ650デフォルトの名無しさん
2014/12/01(月) 00:36:07.76ID:2BTgZC4D651デフォルトの名無しさん
2014/12/01(月) 00:39:00.66ID:JhMfQ7kZ >>648
外部にツールが存在することと、
ある言語が Soft Typing で設計されている話は関係ないよ
Python の言語処理系(インタプリタ)だけで
明示的な型宣言が無くとも実行前に型検査できるなら
話は別だけどね
というか、Soft Typing という用語の意味を
間違って理解しているんじゃね?
外部にツールが存在することと、
ある言語が Soft Typing で設計されている話は関係ないよ
Python の言語処理系(インタプリタ)だけで
明示的な型宣言が無くとも実行前に型検査できるなら
話は別だけどね
というか、Soft Typing という用語の意味を
間違って理解しているんじゃね?
652デフォルトの名無しさん
2014/12/01(月) 00:42:41.17ID:v1/AC0CB653デフォルトの名無しさん
2014/12/01(月) 00:50:53.90ID:JhMfQ7kZ654デフォルトの名無しさん
2014/12/01(月) 04:58:08.58ID:CuP+pzia >>559
かっこいいとかそういう基準で判断してるわけじゃないから。契約とか内容次第だから勝手なイメージだろ。
かっこいいとかそういう基準で判断してるわけじゃないから。契約とか内容次第だから勝手なイメージだろ。
655デフォルトの名無しさん
2014/12/01(月) 06:42:19.33ID:Weh8bUwF 645はクラスを名前空間だと思い込んでいる初心者
早く補助輪を取れるといいね
早く補助輪を取れるといいね
656デフォルトの名無しさん
2014/12/01(月) 09:10:41.83ID:B1S4sCHX そんなつまらない事にしかレスできないから
馬鹿にされるんだよw
馬鹿にされるんだよw
657デフォルトの名無しさん
2014/12/02(火) 12:19:36.12ID:KrePR2s0 昔Basicはプログラマとしてのセンスを破壊すると言われたが、
今回Smalltalkも破壊することが判明したな
今回Smalltalkも破壊することが判明したな
658デフォルトの名無しさん
2014/12/02(火) 13:56:12.38ID:3rN5XUau 2ちゃんねるは人間としての品格を破壊する
659デフォルトの名無しさん
2014/12/02(火) 14:29:13.80ID:XRdoM1I9 “Smalltalkのデバッガがどのくらい強力かと言うと、
任意の時点で任意のプロセスをインタラプトし
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続できるレベル。
デバッガは何枚でも開けられるし、作業の途中でやめたくなったら、
スナップショットを撮って終了し、再開すればその直前から続けられる。
たとえ、それが他のコンピューターでも(直接下回りを触っていない限り、
プラットフォームやOSが違っていても可)、それが10年後でも。”
https://twitter.com/abee2/status/539355671729152000
任意の時点で任意のプロセスをインタラプトし
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続できるレベル。
デバッガは何枚でも開けられるし、作業の途中でやめたくなったら、
スナップショットを撮って終了し、再開すればその直前から続けられる。
たとえ、それが他のコンピューターでも(直接下回りを触っていない限り、
プラットフォームやOSが違っていても可)、それが10年後でも。”
https://twitter.com/abee2/status/539355671729152000
660デフォルトの名無しさん
2014/12/02(火) 16:22:17.31ID:+stn5l+y 10年とか先にarmのcpuが流行ってるとは思わなかったでしょ
661デフォルトの名無しさん
2014/12/02(火) 19:47:59.90ID:OQmm7jB2 >>659
凄いけど役に立たないなw
凄いけど役に立たないなw
662デフォルトの名無しさん
2014/12/02(火) 19:49:38.18ID:OQmm7jB2 なんで役に立たないかというと
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続したらバグで変な状態になった。
また止めて変な状態を直して、正しい所に移動させて続けることも可能だけど
最初からやり直したほうが早い。
実行中のメソッドコンテクストのスタックをトレースして任意の時点まで遡り、
その時の内部状態を観察してソースコードを修正、コンパイルした後、
そのままリジュームして処理を継続したらバグで変な状態になった。
また止めて変な状態を直して、正しい所に移動させて続けることも可能だけど
最初からやり直したほうが早い。
663デフォルトの名無しさん
2014/12/02(火) 22:07:07.23ID:DpCZ+4Qy664デフォルトの名無しさん
2014/12/02(火) 22:38:50.95ID:OQmm7jB2 人間はミスするとう前提の話をしてるんだが?
スキルや能力とは関係ない。
ミスしないようなすごい人しか使えない道具ではなく、
ミスしてもすぐにリカバリできる仕組みを作るほうが重要。
ということで静的型付け言語はそうなってるって話なんだよ。
スキルや能力とは関係ない。
ミスしないようなすごい人しか使えない道具ではなく、
ミスしてもすぐにリカバリできる仕組みを作るほうが重要。
ということで静的型付け言語はそうなってるって話なんだよ。
665デフォルトの名無しさん
2014/12/02(火) 22:48:09.93ID:DpCZ+4Qy666デフォルトの名無しさん
2014/12/02(火) 22:52:44.71ID:OQmm7jB2 一体何の機能が制限されているというのか?
タイプ数が少し増えるというのならわかる。
制限されているという機能の名前を聞いたことがないし、
どうでも良い機能のために、動的型付け言語を使うという話しか聞かない
静的型付け言語で出来ないことはないし、(たとえば、C言語は静的型付け言語)
多くのことが動的型付け言語よりも便利に行える。
デメリットはほんの少しタイプ量が増えるだけ
タイプ数が少し増えるというのならわかる。
制限されているという機能の名前を聞いたことがないし、
どうでも良い機能のために、動的型付け言語を使うという話しか聞かない
静的型付け言語で出来ないことはないし、(たとえば、C言語は静的型付け言語)
多くのことが動的型付け言語よりも便利に行える。
デメリットはほんの少しタイプ量が増えるだけ
667デフォルトの名無しさん
2014/12/02(火) 22:57:12.61ID:ySWWhxWC 修正したコードが実機の上、しかもファイルじゃなくてメモリ上にしかないとか
よく考えなくても怖いことなんだけどな。
よく考えなくても怖いことなんだけどな。
668デフォルトの名無しさん
2014/12/02(火) 22:58:05.38ID:AvSKqXZA669デフォルトの名無しさん
2014/12/02(火) 23:01:26.70ID:DpCZ+4Qy >>667
よく考えてたら、VCSにチェックインするとか想像できそうなものだけど。
よく考えてたら、VCSにチェックインするとか想像できそうなものだけど。
670デフォルトの名無しさん
2014/12/02(火) 23:23:32.69ID:DpCZ+4Qy671デフォルトの名無しさん
2014/12/02(火) 23:41:57.12ID:f9ZuLJgk >>666
動的型付けの利点はコンポーネント間を柔軟に結合できること
大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク
Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、
コンポーネント間の結合に用いるオブジェクトに対しては id型 という動的型付けを用いる
結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている
対して、静的型付けな C++ と MFC ライブラリを採用した Windows は開発に行き詰まる
Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、
COM は高度で優れた技術ではあるものの、あまりに一般のプログラマには難解すぎて普及しなかった
(一般のプログラマが普通に使えるのは OLE Automation と呼ばれるクライアント側APIのみ)
このため Microsoft は C++ や MFC を放棄して C# と .Net へ全面移行せざるをえなかった
結果として開発チームは大混乱に陥って Windows Vista の大失敗に始まる開発の大幅な停滞をまねき、
Apple の台頭を許した
動的型付けの利点はコンポーネント間を柔軟に結合できること
大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク
Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、
コンポーネント間の結合に用いるオブジェクトに対しては id型 という動的型付けを用いる
結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている
対して、静的型付けな C++ と MFC ライブラリを採用した Windows は開発に行き詰まる
Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、
COM は高度で優れた技術ではあるものの、あまりに一般のプログラマには難解すぎて普及しなかった
(一般のプログラマが普通に使えるのは OLE Automation と呼ばれるクライアント側APIのみ)
このため Microsoft は C++ や MFC を放棄して C# と .Net へ全面移行せざるをえなかった
結果として開発チームは大混乱に陥って Windows Vista の大失敗に始まる開発の大幅な停滞をまねき、
Apple の台頭を許した
672デフォルトの名無しさん
2014/12/02(火) 23:43:16.07ID:DpCZ+4Qy673デフォルトの名無しさん
2014/12/03(水) 00:24:16.86ID:B6A3kVmE >>659
なぜDockerみたいな技術が持て囃され、こういう機能がスルーされるのか
Smalltalkerには永遠に理解できないんだろうな
Smalltalkは見当違いの問題を解いているんだよ
言語の中だけでリスタートできても意味がないんだ
価値がないから真似もされない
なぜDockerみたいな技術が持て囃され、こういう機能がスルーされるのか
Smalltalkerには永遠に理解できないんだろうな
Smalltalkは見当違いの問題を解いているんだよ
言語の中だけでリスタートできても意味がないんだ
価値がないから真似もされない
674デフォルトの名無しさん
2014/12/03(水) 01:01:00.52ID:/c7/jI5U 道具に使われてる人たちが・・・
675デフォルトの名無しさん
2014/12/03(水) 01:03:45.51ID:cgD8+cJC >>673
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#
計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を
説明するのは難しい。
ユーザーがアクセスできる部品のすべてはユーザーが
観察し操作するのに適した方法で自らを表現できなければ
ならない
オペレーティングシステムがこの原則を破っているようで
あることはちょっと注目すべきだろう。
オペレーティングシステムは言語におさまりきらないものを
集めたもので、これは存在すべきでない
Smalltalkにはそうした意味での「オペレーティングシステム」は
無い。
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#
計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を
説明するのは難しい。
ユーザーがアクセスできる部品のすべてはユーザーが
観察し操作するのに適した方法で自らを表現できなければ
ならない
オペレーティングシステムがこの原則を破っているようで
あることはちょっと注目すべきだろう。
オペレーティングシステムは言語におさまりきらないものを
集めたもので、これは存在すべきでない
Smalltalkにはそうした意味での「オペレーティングシステム」は
無い。
676デフォルトの名無しさん
2014/12/03(水) 01:07:46.87ID:9SD5P0Ri この言語は危ないという前提があった方が、本当に危なくなった時に逃げやすいね
言語を信用しすぎると逃げ遅れる
言語を信用しすぎると逃げ遅れる
677デフォルトの名無しさん
2014/12/03(水) 05:01:07.21ID:Fu5jXwDM >>667
大抵のSmalltalk処理系はソース編集をジャーナリングしているのだが?
普通の開発環境でいえば、
テキストエディタで編集するごとに自動的にcommitしているようなもの。
PVSやMonticelloを使えばもっと高機能かつ安全だ。
むしろ、commitを自分でやらないと編集履歴が残らない
普通の開発環境のほうがよく考えなくても怖いことなんだけどな。
大抵のSmalltalk処理系はソース編集をジャーナリングしているのだが?
普通の開発環境でいえば、
テキストエディタで編集するごとに自動的にcommitしているようなもの。
PVSやMonticelloを使えばもっと高機能かつ安全だ。
むしろ、commitを自分でやらないと編集履歴が残らない
普通の開発環境のほうがよく考えなくても怖いことなんだけどな。
678デフォルトの名無しさん
2014/12/03(水) 09:01:37.48ID:XWw3OxN9 >>675
OSの上でOSゴッコしてるだけのSmalltalkが笑わせてくれる
OSの上でOSゴッコしてるだけのSmalltalkが笑わせてくれる
679デフォルトの名無しさん
2014/12/03(水) 09:09:27.83ID:RRftfJUJ >>677
もう少し分かりやすくいおう。
SmalltalkはVCSが言語に統合されている。
VCSが言語に統合されていない言語では、
自分で統合するかIDEの力を借りる。
そこまでセットアップする手間を省けるだけなのだ。
もう少し分かりやすくいおう。
SmalltalkはVCSが言語に統合されている。
VCSが言語に統合されていない言語では、
自分で統合するかIDEの力を借りる。
そこまでセットアップする手間を省けるだけなのだ。
680デフォルトの名無しさん
2014/12/03(水) 09:13:57.48ID:RRftfJUJ >>671
> 大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク
> Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、
> コンポーネント間の結合に用いるオブジェクトに対しては id型 という動的型付けを用いる
> 結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている
動的型付け言語じゃなくても達成出来てることを言われてもなw
だいたい発展し続けると言っても、再起動してるじゃん。
なぜ動的型付け言語ならではの理由が
あんたの言っていることには一つのないんだよね。
> 大規模開発の具体例は OSX/iOS で使われている Objective-C と Cocoa フレームワーク
> Objective-C はコンポーネント内部の実装には静的型付けなC言語を用いるが、
> コンポーネント間の結合に用いるオブジェクトに対しては id型 という動的型付けを用いる
> 結果として2001年の初リリース移行、多くの機能強化や改善を加えて発展を続けている
動的型付け言語じゃなくても達成出来てることを言われてもなw
だいたい発展し続けると言っても、再起動してるじゃん。
なぜ動的型付け言語ならではの理由が
あんたの言っていることには一つのないんだよね。
681デフォルトの名無しさん
2014/12/03(水) 09:21:29.91ID:XWw3OxN9682デフォルトの名無しさん
2014/12/03(水) 10:48:31.33ID:9SD5P0Ri なんでも理由があるべきという思い込みはよくない
実力だけでなく運で決まることもたくさんある
実力だけでなく運で決まることもたくさんある
683デフォルトの名無しさん
2014/12/03(水) 11:22:27.25ID:zGKDhFQQ >>681
Smalltalkを使っている人間はgitを理解できないと決めつける時点で
発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、
古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。
Smalltalkを使っている人間はgitを理解できないと決めつける時点で
発想が貧困すぎて困る。この調子じゃ、比較的最近のMonticelloはおろか、
古典的なチェンジセットすらどこまで理解した上でけなしているのかわかったもんじゃない。
684デフォルトの名無しさん
2014/12/03(水) 12:24:53.21ID:zGKDhFQQ >>673
> Smalltalkは見当違いの問題を解いている
Smalltalkはもう過去の遺物だし、問題はすでに解き終わっている。
あとはSmalltalkがどう解いたかを調べて理解するだけでいいと思うよ。
そこから使えそうなアイデアだけを引っ張ってきてちょっと見栄えをよくすれば、
運が良ければイノベーションや新しいトレンドも生み出せる(した人もいる)。
古くはWIMPなGUIしかり、MVCやコレクションなどのフレームワークしかり、
XPやTDDなどアジャイルな開発手法しかり、近年であればトレイトやクラスボックスしかり。
向いている方向が見当違いだというのは同意するけど、それはたまたま今は
ファイルシステムに密着したUNIXライクなOS+C言語マシンで成り立つ世界だからで
そこから外れた物の見方はいっさい価値なしと切り捨ててしまうのは少しもったいない。
少し、だけどね。土方には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
食いつないでいくためにはまずそっちを優先すべきだし。
> Smalltalkは見当違いの問題を解いている
Smalltalkはもう過去の遺物だし、問題はすでに解き終わっている。
あとはSmalltalkがどう解いたかを調べて理解するだけでいいと思うよ。
そこから使えそうなアイデアだけを引っ張ってきてちょっと見栄えをよくすれば、
運が良ければイノベーションや新しいトレンドも生み出せる(した人もいる)。
古くはWIMPなGUIしかり、MVCやコレクションなどのフレームワークしかり、
XPやTDDなどアジャイルな開発手法しかり、近年であればトレイトやクラスボックスしかり。
向いている方向が見当違いだというのは同意するけど、それはたまたま今は
ファイルシステムに密着したUNIXライクなOS+C言語マシンで成り立つ世界だからで
そこから外れた物の見方はいっさい価値なしと切り捨ててしまうのは少しもったいない。
少し、だけどね。土方には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
食いつないでいくためにはまずそっちを優先すべきだし。
685デフォルトの名無しさん
2014/12/03(水) 14:17:36.95ID:Fu5jXwDM >>678
原論文を理解できなかったなら正直にそう書けばいいのにw
原論文を理解できなかったなら正直にそう書けばいいのにw
686デフォルトの名無しさん
2014/12/03(水) 14:23:59.81ID:Fu5jXwDM >>673
メインフレームを笑っていたUnix厨が
メインフレーム由来の仮想化技術をあたかも最新技術のように持て囃す、
あんたが好きな「価値」ってのはその程度のものだ
必死に追いかければ、その先に青い鳥がいるかもなあw
メインフレームを笑っていたUnix厨が
メインフレーム由来の仮想化技術をあたかも最新技術のように持て囃す、
あんたが好きな「価値」ってのはその程度のものだ
必死に追いかければ、その先に青い鳥がいるかもなあw
687デフォルトの名無しさん
2014/12/03(水) 20:48:36.10ID:nRr7XZh4 Dockerはunixの世界においても枯れた既存技術の寄せ集めだし、
最新技術だから持て囃されてるんじゃないよ
標準化の動きが急速に進んでて、クラウドサービスにベンダーロックインされる危険が極小になる所が肝
あるクラウドサービスで動かしてた仮装イメージを、別のサービスに即座に引っ越せるようになる
メインフレームみたいに極限までロックインさせる話とは根本的に違う
やっぱり分かってないと言わざるを得ない
最新技術だから持て囃されてるんじゃないよ
標準化の動きが急速に進んでて、クラウドサービスにベンダーロックインされる危険が極小になる所が肝
あるクラウドサービスで動かしてた仮装イメージを、別のサービスに即座に引っ越せるようになる
メインフレームみたいに極限までロックインさせる話とは根本的に違う
やっぱり分かってないと言わざるを得ない
688デフォルトの名無しさん
2014/12/03(水) 21:23:44.95ID:o4Xb4UE8 ベンダーロックインを静的型にたとえると
短いソースをコンパイルするために多くのヘッダーをincludeすることを強制される
ヘッダーと本体が分かれていない言語では全部必要
短いソースをコンパイルするために多くのヘッダーをincludeすることを強制される
ヘッダーと本体が分かれていない言語では全部必要
689デフォルトの名無しさん
2014/12/03(水) 21:45:16.01ID:RRftfJUJ690デフォルトの名無しさん
2014/12/03(水) 21:49:32.75ID:RRftfJUJ >>684
> には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
> ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
プロなら当たり前のことなんじゃねーの?
プロには目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
うん、違和感ない
> には目の前に解決しなきゃならない問題や、学ばなくちゃいけない
> ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
プロなら当たり前のことなんじゃねーの?
プロには目の前に解決しなきゃならない問題や、学ばなくちゃいけない
ついて行かなきゃいけないトレンドや技術がいっぱいあるから、
うん、違和感ない
691デフォルトの名無しさん
2014/12/03(水) 22:07:22.24ID:o4Xb4UE8692デフォルトの名無しさん
2014/12/03(水) 22:22:38.66ID:RRftfJUJ そのおかげで、矛盾するもの。つまり
明らかに動かないコードを検出することが可能になっている。
動的型付け言語では、動かして該当コードに
たどり着かないとわからないバグを
動かすことなく見つけることが可能になってる。
これこそ、大規模開発で必要なことの一つなんだ。
明らかに動かないコードを検出することが可能になっている。
動的型付け言語では、動かして該当コードに
たどり着かないとわからないバグを
動かすことなく見つけることが可能になってる。
これこそ、大規模開発で必要なことの一つなんだ。
693デフォルトの名無しさん
2014/12/03(水) 22:25:08.05ID:o4Xb4UE8 大規模炎上の主な原因はバグではなく設計ミスではないのか
694デフォルトの名無しさん
2014/12/03(水) 22:26:49.02ID:B6A3kVmE 静的型の方がアカデミック方面での発展も凄いので
確かに学ぶことは多いと思うよ
確かに学ぶことは多いと思うよ
695デフォルトの名無しさん
2014/12/03(水) 22:31:22.32ID:0xDgvp4s >>693
違う、営業的に決められた納期だな
違う、営業的に決められた納期だな
696デフォルトの名無しさん
2014/12/03(水) 22:36:19.29ID:RRftfJUJ >>693
大規模炎上の話なんかしていないw
まず、スコープが小さいほど、変更が与える影響は少ない。
プライベートメソッドなら、クラスの外は関係ないし、
関数内の修正は、引数と戻り値さえ同じなら
どう修正しても問題ない。
修正の影響範囲が大きいのはスコープが多い時なんだ。
例えばクラスメソッド引数が変更された時、
その他の"すべての"ファイルから参照しているコードを突き止めないといけない。
基底クラスが変更になった時、その全ての派生クラスへの影響を考えないといけない。
そこに静的型付け言語のメリットが生きてくる。
動的型付け言語だと、クラスを変更した時、そのクラスの利用者全てを確認するのは難しい。
なぜなら変数に依存関係が明示されていないから。
静的型付け言語だと、変数に型を明示するから、変更による影響を瞬時に知ることができる。
これこそ大規模開発で必要なことなんだよ。
大規模炎上の話なんかしていないw
まず、スコープが小さいほど、変更が与える影響は少ない。
プライベートメソッドなら、クラスの外は関係ないし、
関数内の修正は、引数と戻り値さえ同じなら
どう修正しても問題ない。
修正の影響範囲が大きいのはスコープが多い時なんだ。
例えばクラスメソッド引数が変更された時、
その他の"すべての"ファイルから参照しているコードを突き止めないといけない。
基底クラスが変更になった時、その全ての派生クラスへの影響を考えないといけない。
そこに静的型付け言語のメリットが生きてくる。
動的型付け言語だと、クラスを変更した時、そのクラスの利用者全てを確認するのは難しい。
なぜなら変数に依存関係が明示されていないから。
静的型付け言語だと、変数に型を明示するから、変更による影響を瞬時に知ることができる。
これこそ大規模開発で必要なことなんだよ。
697デフォルトの名無しさん
2014/12/03(水) 22:43:05.49ID:o4Xb4UE8 うっかり基底クラスを変更したら
継承も知らないのかと疑われそうで嫌だな
継承も知らないのかと疑われそうで嫌だな
698デフォルトの名無しさん
2014/12/03(水) 22:44:57.73ID:RRftfJUJ モジュール間の依存は小さくするというのは
ソフトウェアの開発者の常識だが、
なぜ小さくするのかというとモジュール間の依存が大きいと
修正する時に発生する影響範囲が大きくなって修正が大変だからなんだ。
だからモジュール間の依存は小さくするべきだが、
モジュールを連携してシステムが動く以上0にはできない。
例えば、obj.foo() というコードがあったとき、そこには
objはfooメソッドを持っていなければならないという依存情報が生まれる。
この依存情報を動的型付け言語では、実行時までチェックしない。
静的型付け言語ではobjの型を明示することで、
実行前にfooメソッドが有ることを確認できる。
影響範囲を確認することが大変なモジュール間の依存を
明確にすることで、不具合の発見を容易にし
修正のコストを減らすのが、静的型付け言語の特徴なんだ。
ソフトウェアの開発者の常識だが、
なぜ小さくするのかというとモジュール間の依存が大きいと
修正する時に発生する影響範囲が大きくなって修正が大変だからなんだ。
だからモジュール間の依存は小さくするべきだが、
モジュールを連携してシステムが動く以上0にはできない。
例えば、obj.foo() というコードがあったとき、そこには
objはfooメソッドを持っていなければならないという依存情報が生まれる。
この依存情報を動的型付け言語では、実行時までチェックしない。
静的型付け言語ではobjの型を明示することで、
実行前にfooメソッドが有ることを確認できる。
影響範囲を確認することが大変なモジュール間の依存を
明確にすることで、不具合の発見を容易にし
修正のコストを減らすのが、静的型付け言語の特徴なんだ。
699デフォルトの名無しさん
2014/12/04(木) 01:15:00.87ID:jHjIGczB インタフェースみたいにメソッドの実装を強制したいです
どうしますかおしえて
どうしますかおしえて
700デフォルトの名無しさん
2014/12/04(木) 02:09:44.10ID:8pz5p6Zv したら良いんじゃない?
できない言語を使ってるの?
できない言語を使ってるの?
701デフォルトの名無しさん
2014/12/04(木) 08:48:23.43ID:1fNTZGeK >>699
実装しなかったら開発者をクビにする
実装しなかったら開発者をクビにする
702デフォルトの名無しさん
2014/12/04(木) 09:42:52.10ID:rp/BpD2j703デフォルトの名無しさん
2014/12/04(木) 10:26:14.06ID:5ZEJ+Feh704デフォルトの名無しさん
2014/12/04(木) 12:32:36.38ID:TqunBxc9 >>702
> 超マイナーなVCSや低性能のODBに
> 自分からロックインされに行く
ありがたい話じゃないか。
そこまでしてSmalltalkから将来出てくるであろう新しい何かを育ててくれるんだから。
トレイトしかりクラスボックスしかり。
> 超マイナーなVCSや低性能のODBに
> 自分からロックインされに行く
ありがたい話じゃないか。
そこまでしてSmalltalkから将来出てくるであろう新しい何かを育ててくれるんだから。
トレイトしかりクラスボックスしかり。
705デフォルトの名無しさん
2014/12/04(木) 19:31:17.50ID:mwV5k8HO >>702
Smalltalkでは何十年も昔から常識だったことが
新技術として他の言語や環境でも使えるようになったら
「こんな便利な技術は技術オンチのSmalltalkerには理解できないだろう」
とか言いながらありがたく使いなさいよ、技術乞食さんw
Smalltalkでは何十年も昔から常識だったことが
新技術として他の言語や環境でも使えるようになったら
「こんな便利な技術は技術オンチのSmalltalkerには理解できないだろう」
とか言いながらありがたく使いなさいよ、技術乞食さんw
706デフォルトの名無しさん
2014/12/04(木) 20:15:36.06ID:rp/BpD2j707デフォルトの名無しさん
2014/12/04(木) 21:21:32.12ID:tYdcY83W え? なに? 俺の言語が起源だとかいう話をしてんの?
起源なんかどうでもよくて、その技術を
"今" 有効活用することのほうが大事だろ。
起源はベータ版。今その技術を取り入れた言語というのは
ベータ版を評価して、より優れた方法で取り入れてるってことなんだよ。
つまり、同じ機能であっても、起源よりも
後から取り入れた言語のほうが優れている。
初号機のほうが優れているっていうのは漫画の中の話だけだよ。
現実には、二号機、三号機の方が優れている。
起源なんかどうでもよくて、その技術を
"今" 有効活用することのほうが大事だろ。
起源はベータ版。今その技術を取り入れた言語というのは
ベータ版を評価して、より優れた方法で取り入れてるってことなんだよ。
つまり、同じ機能であっても、起源よりも
後から取り入れた言語のほうが優れている。
初号機のほうが優れているっていうのは漫画の中の話だけだよ。
現実には、二号機、三号機の方が優れている。
708デフォルトの名無しさん
2014/12/04(木) 21:36:40.87ID:RpORv8ek709デフォルトの名無しさん
2014/12/04(木) 21:47:04.11ID:8pz5p6Zv >>708
この論文は読んだ上で言ってるの?
あ、Martin OderskyはScalaの作者ね
http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf
この論文は読んだ上で言ってるの?
あ、Martin OderskyはScalaの作者ね
http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf
710デフォルトの名無しさん
2014/12/04(木) 21:48:59.20ID:RpORv8ek711デフォルトの名無しさん
2014/12/04(木) 21:50:19.83ID:5ZEJ+Feh712デフォルトの名無しさん
2014/12/04(木) 21:54:36.04ID:RpORv8ek713デフォルトの名無しさん
2014/12/04(木) 22:05:12.01ID:8pz5p6Zv >>712
最初の方だけでも読んでみようとは思わないの?
> This paper presents a lightweight approach to type classes in object-oriented (OO) languages
> with generics using CONCEPT pattern and implicits (a type-directed implicit parameter passing mechanism).
> This paper also shows how Scala's type system conspires with implicits to enable, and even surpass,
> many common extensions of the Haskell type class system, making Scala ideally suited for generic programming in the large.
最初の方だけでも読んでみようとは思わないの?
> This paper presents a lightweight approach to type classes in object-oriented (OO) languages
> with generics using CONCEPT pattern and implicits (a type-directed implicit parameter passing mechanism).
> This paper also shows how Scala's type system conspires with implicits to enable, and even surpass,
> many common extensions of the Haskell type class system, making Scala ideally suited for generic programming in the large.
714デフォルトの名無しさん
2014/12/04(木) 22:11:18.04ID:tYdcY83W このペーパー、プレゼントします
最初の方だけ読みました!
最初の方だけ読みました!
715デフォルトの名無しさん
2014/12/04(木) 22:16:14.84ID:RpORv8ek >>713
だからそれのどこにtraitが出てくるのさ。
Scalaのtraitsの出自について言及はこっちでしょ。
http://www.bytelabs.org/pub/tpl/slides/sm@lausanne/expressionProblem.pdf
Traits in SCALA[23] are abstract classes without state or
parameterized constructors; another way to characterize them
would be as JAVA-like interfaces that may also contain
inner classes and concrete implementations for some
methods. Unlike the original trait proposal[29], traits in Scala
are not different from classes. In the example above
and all examples that follow one could have also used
abstract class instead of trait.
だからそれのどこにtraitが出てくるのさ。
Scalaのtraitsの出自について言及はこっちでしょ。
http://www.bytelabs.org/pub/tpl/slides/sm@lausanne/expressionProblem.pdf
Traits in SCALA[23] are abstract classes without state or
parameterized constructors; another way to characterize them
would be as JAVA-like interfaces that may also contain
inner classes and concrete implementations for some
methods. Unlike the original trait proposal[29], traits in Scala
are not different from classes. In the example above
and all examples that follow one could have also used
abstract class instead of trait.
716デフォルトの名無しさん
2014/12/04(木) 22:20:18.91ID:8pz5p6Zv >>715
どこにって、implicitを使うために中で何度でも出てくるよ?
どこにって、implicitを使うために中で何度でも出てくるよ?
717デフォルトの名無しさん
2014/12/04(木) 22:24:26.97ID:8pz5p6Zv こういう研究の流れを受けてか、後発のRustのtraitは
最初からHaskellのType Classそっくりになっているんですってよ
最初からHaskellのType Classそっくりになっているんですってよ
718デフォルトの名無しさん
2014/12/04(木) 22:29:19.94ID:RpORv8ek719デフォルトの名無しさん
2014/12/04(木) 22:30:05.46ID:tYdcY83W 始めに実装したというのは凄いかもしれないけど、
その凄いっていうのは、始めに実装したことであって
その機能がすごいってことじゃないんだよな。
後発のほうがもっとその機能を強化している。
そして始めに実装した言語は互換性を保つために
機能強化できずにずっと続けないといけない。
その凄いっていうのは、始めに実装したことであって
その機能がすごいってことじゃないんだよな。
後発のほうがもっとその機能を強化している。
そして始めに実装した言語は互換性を保つために
機能強化できずにずっと続けないといけない。
720デフォルトの名無しさん
2014/12/04(木) 22:45:30.93ID:RpORv8ek >>719
それははじめに機能ありきで、それをただ実装した場合の話だろう。
試行錯誤して生まれるには、それをインキュベートする環境が必要でって話なんだが
計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を説明するのは難しい。
それははじめに機能ありきで、それをただ実装した場合の話だろう。
試行錯誤して生まれるには、それをインキュベートする環境が必要でって話なんだが
計算機の言語を狭い意味でとらえる人にSmalltalkの特徴を説明するのは難しい。
721デフォルトの名無しさん
2014/12/04(木) 22:52:15.50ID:8pz5p6Zv >>718
> The trait Ord[T] is an example of a concept interface.
> Concept interfaces for the type classes Show and Read presented in Section 2.1 are:
> The trait Ord[T] is an example of a concept interface.
> Concept interfaces for the type classes Show and Read presented in Section 2.1 are:
722デフォルトの名無しさん
2014/12/04(木) 23:00:58.08ID:5ZEJ+Feh 宇宙服みたいな言語とモビルスーツみたいな言語があるけど
どうせ結局両方使うんだよな
どうせ結局両方使うんだよな
723デフォルトの名無しさん
2014/12/04(木) 23:08:55.47ID:RpORv8ek724デフォルトの名無しさん
2014/12/04(木) 23:11:32.11ID:8pz5p6Zv >>723
ついに反論しきれなくなって、traitとtype classは無関係から
そのものでは無いまで意見が後退しちゃったねw
自分もtype classそのものなんて一度も言ってないので、もうそれで良いよ
ついに反論しきれなくなって、traitとtype classは無関係から
そのものでは無いまで意見が後退しちゃったねw
自分もtype classそのものなんて一度も言ってないので、もうそれで良いよ
725デフォルトの名無しさん
2014/12/04(木) 23:13:27.66ID:BoUkojKR >>722
両方を備えたc++ですね分かります
両方を備えたc++ですね分かります
726デフォルトの名無しさん
2014/12/04(木) 23:24:08.54ID:BoUkojKR A君「絵を描くのは好きだけど、仕事と両立するのは難しいなぁ」
ニート「一日中ヒマだから絵を描き放題だぜ」
A君「ついに絵を描く仕事に就いたぞ。好きなことして食べていける」
ニート「もう20年前から好きなことだけやれてたわ〜。遅れてんな〜やれやれ」
ニート「一日中ヒマだから絵を描き放題だぜ」
A君「ついに絵を描く仕事に就いたぞ。好きなことして食べていける」
ニート「もう20年前から好きなことだけやれてたわ〜。遅れてんな〜やれやれ」
727デフォルトの名無しさん
2014/12/04(木) 23:40:50.93ID:RpORv8ek >>724
わっかんないやつだなぁ。
traitが型クラス由来なら、なぜtraitを使わないで型クラスの例が書けるのさ。
http://www.scala-lang.org/old/node/114
説明してミソ
わっかんないやつだなぁ。
traitが型クラス由来なら、なぜtraitを使わないで型クラスの例が書けるのさ。
http://www.scala-lang.org/old/node/114
説明してミソ
728デフォルトの名無しさん
2014/12/05(金) 00:15:41.66ID:RG1/KShi729デフォルトの名無しさん
2014/12/05(金) 00:20:26.42ID:lYb7FfYs C++のclassはstructでも書けるな
730デフォルトの名無しさん
2014/12/05(金) 02:25:30.08ID:3qncuvNa >>728
おまえ頭わるいな
おまえ頭わるいな
731デフォルトの名無しさん
2014/12/05(金) 07:42:45.52ID:ViNbqhcv732デフォルトの名無しさん
2014/12/05(金) 09:04:37.51ID:t8jCTeme RubyのブロックってCLUのイテレーター由来じゃなかったっけ?
ずいぶん前にMatzがそんなようなことを言っていた記憶が
ずいぶん前にMatzがそんなようなことを言っていた記憶が
733デフォルトの名無しさん
2014/12/05(金) 09:13:02.76ID:A1Nk4WQY クロージャとラムダ式の区別がついていない人ってよくいるよね
734デフォルトの名無しさん
2014/12/05(金) 09:16:51.57ID:+TXyzC2W735デフォルトの名無しさん
2014/12/05(金) 10:11:29.20ID:sLA7oQpI Pythonにクロージャは無い(キリッ
736デフォルトの名無しさん
2014/12/05(金) 11:25:40.15ID:viBzu9Eo さあ728さん、クロージャとラムダの同一性の説明どーぞ!
737デフォルトの名無しさん
2014/12/05(金) 12:26:12.88ID:51P5EYrc >>732
いや。Rubyのブロック自体はLISPのlambda由来かと。
今のブロック付きメソッド呼び出し(昔はイテレータと呼んでいた)が
CLUのイテレータから発想を得た…というだけで。
もっとも個人的には(着想はともかく最終的には)
Smalltalkのブロックを引数にとるメソッド呼び出しの見た目だけパクったものだと思うけどね。
▼CLUのイテレータ
start_up = proc ()
po : stream := stream$primary_output()
xs : array[int] := array[int]$[1,2,3]
for x : int in xs!elements do
po!putl(x!unparse)
end
end start_up
▼初期のRubyのイテレータ
do [1,2,3].each using x; print(x, "\n") end
▼現行のRubyのblock付きメソッド呼び出し(旧呼称はイテレータ)
[1,2,3].each{ |x| puts x }
▼Smalltalkのブロックを引数にとるメソッド呼び出し
#(1 2 3) do: [:x | x logCr ]
▼LISPのループ(lambdaの出番はない^^;)
(loop for x in '(1 2 3) do (print x))
▼Schemeのlambda
(for-each (lambda (x) (print x)) '(1 2 3))
(for-each print '(1 2 3)) ;;←実際はlambda使わずにこれでおk
いや。Rubyのブロック自体はLISPのlambda由来かと。
今のブロック付きメソッド呼び出し(昔はイテレータと呼んでいた)が
CLUのイテレータから発想を得た…というだけで。
もっとも個人的には(着想はともかく最終的には)
Smalltalkのブロックを引数にとるメソッド呼び出しの見た目だけパクったものだと思うけどね。
▼CLUのイテレータ
start_up = proc ()
po : stream := stream$primary_output()
xs : array[int] := array[int]$[1,2,3]
for x : int in xs!elements do
po!putl(x!unparse)
end
end start_up
▼初期のRubyのイテレータ
do [1,2,3].each using x; print(x, "\n") end
▼現行のRubyのblock付きメソッド呼び出し(旧呼称はイテレータ)
[1,2,3].each{ |x| puts x }
▼Smalltalkのブロックを引数にとるメソッド呼び出し
#(1 2 3) do: [:x | x logCr ]
▼LISPのループ(lambdaの出番はない^^;)
(loop for x in '(1 2 3) do (print x))
▼Schemeのlambda
(for-each (lambda (x) (print x)) '(1 2 3))
(for-each print '(1 2 3)) ;;←実際はlambda使わずにこれでおk
738デフォルトの名無しさん
2014/12/05(金) 12:31:26.53ID:+5KFbbdu 動的言語には型名を考えるコストがない
ある物の名前がラムダかクロージャか議論するのに何時間かかるか考えてみろ
ある物の名前がラムダかクロージャか議論するのに何時間かかるか考えてみろ
739デフォルトの名無しさん
2014/12/05(金) 13:25:22.71ID:eWvM3tpo >>738
動的言語でも型名はあるんじゃ。もし言語がサポートしてなくても何かつけそう。
動的言語でも型名はあるんじゃ。もし言語がサポートしてなくても何かつけそう。
740デフォルトの名無しさん
2014/12/05(金) 13:38:18.27ID:AoGRS1Po >>738
唯一神クラスですか?
唯一神クラスですか?
741デフォルトの名無しさん
2014/12/05(金) 16:19:55.77ID:+5KFbbdu インタフェース継承で派生クラスの名前は必須ではない
これは静的でも成り立つ
更に突き詰めると必要なのはメンバの名前のみなのでインタフェースの名前も不要
Smalltalkは実装継承にこだわっているので名前は必要かもしれんが他の動的言語は違う
これは静的でも成り立つ
更に突き詰めると必要なのはメンバの名前のみなのでインタフェースの名前も不要
Smalltalkは実装継承にこだわっているので名前は必要かもしれんが他の動的言語は違う
742デフォルトの名無しさん
2014/12/05(金) 18:10:35.44ID:N759beub743デフォルトの名無しさん
2014/12/05(金) 20:31:39.15ID:+TXyzC2W >>738
何言ってんだ?
型がなくてどうやってオブジェクトをnewするんだよ?w
new 型名 って書くだろが。
動的型付け言語にないのは型じゃなくて、
変数(関数の引数含む)に型が書いてないから
いろんな型が入れられてしまうって話だろ。
ローカル変数ならともかく、関数の引数、
つまり外部モジュールとのインターフェース部分にまで
型を書かないから、複数のモジュールを連携して作るような
大規模(中規模? いやいやサンプル以上の規模)になればなるほど、
大きくなっていく影響範囲を把握するのが大変になるって話だよ。
変数に型がないから、影響範囲がわからない、
もしくは限定的になり、人間の負担が大きくなる。
何言ってんだ?
型がなくてどうやってオブジェクトをnewするんだよ?w
new 型名 って書くだろが。
動的型付け言語にないのは型じゃなくて、
変数(関数の引数含む)に型が書いてないから
いろんな型が入れられてしまうって話だろ。
ローカル変数ならともかく、関数の引数、
つまり外部モジュールとのインターフェース部分にまで
型を書かないから、複数のモジュールを連携して作るような
大規模(中規模? いやいやサンプル以上の規模)になればなるほど、
大きくなっていく影響範囲を把握するのが大変になるって話だよ。
変数に型がないから、影響範囲がわからない、
もしくは限定的になり、人間の負担が大きくなる。
744デフォルトの名無しさん
2014/12/05(金) 20:46:05.48ID:+TXyzC2W >>741
> インタフェース継承で派生クラスの名前は必須ではない
そりゃそうだよ。問題にしているのは人間が大変かどうかの話なんだから。
技術者はよく、技術的に可能かどうかで答えるだけで
制限時間内に終えられるかどうかを答えなくて困る。
ミスをしない人間がいて、タイプミスもせず、ードの全てを覚えていて、
仕様の変更もしない。もしくは理想的な変更しか起こらず、時間の制限もない。
そういうありえない世界でなら何の問題もないんだよ。
現実には何万行、何十万行というコードを知っている人が
会社をやめて、新しく入ってきた人が期限内に修正しなければならない。
いいかい? 問題は可能か不可能かじゃないんだ。
コードの全てを把握していない人が、どちらの方が短い時間で
コードを把握できて、ミスをせずに修正できるかって話なんだ。
それがわかっていれば、この関数の引数は、どんなものが入ってくる可能性があって
(むしろ入ってこないものが断定できて)広大なコードの海で、どこから使われているか
目視、もしくはIDEなどのツールを使って100%の信頼性で調べれる方がいいってわかるだろう?
> インタフェース継承で派生クラスの名前は必須ではない
そりゃそうだよ。問題にしているのは人間が大変かどうかの話なんだから。
技術者はよく、技術的に可能かどうかで答えるだけで
制限時間内に終えられるかどうかを答えなくて困る。
ミスをしない人間がいて、タイプミスもせず、ードの全てを覚えていて、
仕様の変更もしない。もしくは理想的な変更しか起こらず、時間の制限もない。
そういうありえない世界でなら何の問題もないんだよ。
現実には何万行、何十万行というコードを知っている人が
会社をやめて、新しく入ってきた人が期限内に修正しなければならない。
いいかい? 問題は可能か不可能かじゃないんだ。
コードの全てを把握していない人が、どちらの方が短い時間で
コードを把握できて、ミスをせずに修正できるかって話なんだ。
それがわかっていれば、この関数の引数は、どんなものが入ってくる可能性があって
(むしろ入ってこないものが断定できて)広大なコードの海で、どこから使われているか
目視、もしくはIDEなどのツールを使って100%の信頼性で調べれる方がいいってわかるだろう?
745デフォルトの名無しさん
2014/12/05(金) 20:46:44.48ID:+5KFbbdu 実装に名前をつけて保存するからだろ
インタフェースは保存しなくてよい
下手すると名前の長さが中身より長くなるから
インタフェースは保存しなくてよい
下手すると名前の長さが中身より長くなるから
746デフォルトの名無しさん
2014/12/05(金) 20:50:24.12ID:+5KFbbdu747デフォルトの名無しさん
2014/12/05(金) 21:12:23.79ID:+TXyzC2W748デフォルトの名無しさん
2014/12/05(金) 21:28:30.39ID:5SBzstV5 >>680
>動的型付け言語じゃなくても達成出来てることを言われてもなw
>>671 で
> Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、
と書いたように、静的型付けの C++ だけでは COM を使わなければ
コンポーネントの動的結合ができない
それに対して Objective-C は一般的な動的リンクライブラリにメタデータを加えて
ファイルを構成するだけで動的結合できるフレームワークを実現できる
動的型付けな Objective-C では同じ事を実現するのに、COM は不要
>だいたい発展し続けると言っても、再起動してるじゃん。
カーネルやデバイスドライバを更新した場合には OS の再起動は必要だ
ただし、ここで議論の対象としているのはライブラリやフレームワークとして提供される
コンポーネントの部分だよ
OSX/iOS では単に規定のフォルダへフレームワークをコピーするだけ
Windows の COM のようにレジストリへ GUID を登録するといった面倒な仕掛けは不要
> なぜ動的型付け言語ならではの理由が
> あんたの言っていることには一つのないんだよね。
静的型付け言語だけではコンポーネントの動的結合ができない(COM が必須)
モジュールの静的リンクだけでいい小規模の開発であれば静的型付け言語でもかまわないが、
コンポーネントを組み合わせる大規模なシステム開発では動的型付けの柔軟性が利点になる
この言語の差が OS という大規模開発における Windows の失敗と OSX/iOS の成功に影響した(>>671)
>動的型付け言語じゃなくても達成出来てることを言われてもなw
>>671 で
> Windows ではコンポーネント間の結合に CORBA を基礎とした COM を開発して対応したが、
と書いたように、静的型付けの C++ だけでは COM を使わなければ
コンポーネントの動的結合ができない
それに対して Objective-C は一般的な動的リンクライブラリにメタデータを加えて
ファイルを構成するだけで動的結合できるフレームワークを実現できる
動的型付けな Objective-C では同じ事を実現するのに、COM は不要
>だいたい発展し続けると言っても、再起動してるじゃん。
カーネルやデバイスドライバを更新した場合には OS の再起動は必要だ
ただし、ここで議論の対象としているのはライブラリやフレームワークとして提供される
コンポーネントの部分だよ
OSX/iOS では単に規定のフォルダへフレームワークをコピーするだけ
Windows の COM のようにレジストリへ GUID を登録するといった面倒な仕掛けは不要
> なぜ動的型付け言語ならではの理由が
> あんたの言っていることには一つのないんだよね。
静的型付け言語だけではコンポーネントの動的結合ができない(COM が必須)
モジュールの静的リンクだけでいい小規模の開発であれば静的型付け言語でもかまわないが、
コンポーネントを組み合わせる大規模なシステム開発では動的型付けの柔軟性が利点になる
この言語の差が OS という大規模開発における Windows の失敗と OSX/iOS の成功に影響した(>>671)
749デフォルトの名無しさん
2014/12/05(金) 21:30:47.47ID:+TXyzC2W > と書いたように、静的型付けの C++ だけでは COM を使わなければ
> コンポーネントの動的結合ができない
別にDLLでもできるけど?
そもそもCOMがあるのは特定の言語に依存しないための
仕様を作ることが目的であって
同じ言語であれば、DLLでできるんだよ。
もうしょっぱなからだめじゃんw
> コンポーネントの動的結合ができない
別にDLLでもできるけど?
そもそもCOMがあるのは特定の言語に依存しないための
仕様を作ることが目的であって
同じ言語であれば、DLLでできるんだよ。
もうしょっぱなからだめじゃんw
750デフォルトの名無しさん
2014/12/05(金) 21:32:11.34ID:+TXyzC2W 2分で論破はやり過ぎだと反省しているw
751デフォルトの名無しさん
2014/12/05(金) 21:35:46.33ID:+TXyzC2W Linuxは静的型付け言語のC言語で〜
拡張子soの動的リンクライブラリが〜
まともに?明するのも面倒くさいw
拡張子soの動的リンクライブラリが〜
まともに?明するのも面倒くさいw
752デフォルトの名無しさん
2014/12/05(金) 22:06:36.60ID:viBzu9Eo Smalltalkの場合、名前のないクラスは名前のあるクラスと同じ数だけ存在する。だから>>741は正しくない。
ちなみにサブクラスを定義するためにはクラスインスタンスにメッセージを送信する。インスタンスを生成するのもクラスインスタンスにメッセージを送信することで行う。その意味でも、クラスに名前は必須ではない。
ちなみにサブクラスを定義するためにはクラスインスタンスにメッセージを送信する。インスタンスを生成するのもクラスインスタンスにメッセージを送信することで行う。その意味でも、クラスに名前は必須ではない。
753デフォルトの名無しさん
2014/12/05(金) 22:08:26.02ID:5SBzstV5 >>749
DLL だけでは柔軟なコンポーネント結合が実現できなかったから、
Microsoft は COM(Component Object Model) という技術を開発した
言語に依存しないバイナリ互換性も COM の特徴であるけれど、
仮に C++ に閉じた開発であっても COM は必要になる
こんな話は COM を知っていれば常識
DLL だけでは柔軟なコンポーネント結合が実現できなかったから、
Microsoft は COM(Component Object Model) という技術を開発した
言語に依存しないバイナリ互換性も COM の特徴であるけれど、
仮に C++ に閉じた開発であっても COM は必要になる
こんな話は COM を知っていれば常識
754デフォルトの名無しさん
2014/12/05(金) 22:40:22.11ID:5SBzstV5 >>732
これかな
・Rubyist Magazine - Rubyist のための他言語探訪 【第 2 回】 CLU
http://magazine.rubyist.net/?0009-Legwork
>>737
> いや。Rubyのブロック自体はLISPのlambda由来かと。
だね
Ruby は LISP をベースにして設計された
Ruby のブロックも LISP のクロージャ(ラムダ式)に由来する
・Lisp から Ruby への設計ステップ | プログラマーズ雑記帳
http://yohshiy.blog.fc2.com/blog-entry-250.html
これかな
・Rubyist Magazine - Rubyist のための他言語探訪 【第 2 回】 CLU
http://magazine.rubyist.net/?0009-Legwork
>>737
> いや。Rubyのブロック自体はLISPのlambda由来かと。
だね
Ruby は LISP をベースにして設計された
Ruby のブロックも LISP のクロージャ(ラムダ式)に由来する
・Lisp から Ruby への設計ステップ | プログラマーズ雑記帳
http://yohshiy.blog.fc2.com/blog-entry-250.html
755デフォルトの名無しさん
2014/12/05(金) 23:20:42.11ID:5SBzstV5 >>737
> 今のブロック付きメソッド呼び出し(昔はイテレータと呼んでいた)が
> CLUのイテレータから発想を得た…というだけで。
ここは違うと思うな
どちらかといえば Ruby が CLU から強い影響を受けたのは、
要素を返すのに yield 構文を用いる、いわゆる「内部イテレータ」だと思う
たとえば >>737 の 1 から 3 の範囲を CLU では以下のイテレータで表現する
from_to = iter(first:int, last:int) yields(int)
n:int := first
while n <= last
yield(n)
n := n + 1
end
end from_to
これを Ruby では以下のように書ける
def from_to(first, last)
n = first
while n <= last
yield n
n += 1
end
end
yield というイテレータ向けに専用の構文を用いる内部イテレータは、汎用的な外部イテレータ、
いわゆるジェネレータよりも反復処理の抽象化を簡潔に表現できる
内部イテレータは CLU で生まれ Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴
> 今のブロック付きメソッド呼び出し(昔はイテレータと呼んでいた)が
> CLUのイテレータから発想を得た…というだけで。
ここは違うと思うな
どちらかといえば Ruby が CLU から強い影響を受けたのは、
要素を返すのに yield 構文を用いる、いわゆる「内部イテレータ」だと思う
たとえば >>737 の 1 から 3 の範囲を CLU では以下のイテレータで表現する
from_to = iter(first:int, last:int) yields(int)
n:int := first
while n <= last
yield(n)
n := n + 1
end
end from_to
これを Ruby では以下のように書ける
def from_to(first, last)
n = first
while n <= last
yield n
n += 1
end
end
yield というイテレータ向けに専用の構文を用いる内部イテレータは、汎用的な外部イテレータ、
いわゆるジェネレータよりも反復処理の抽象化を簡潔に表現できる
内部イテレータは CLU で生まれ Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴
756デフォルトの名無しさん
2014/12/05(金) 23:41:12.21ID:+5KFbbdu 問題
yieldを用いると内部イテレータ風の書き方で外部イテレータを作ることができる
このイテレータの名称として適切なのは
「外部イテレータ」「内部イテレータ」のどちらか答えよ
yieldを用いると内部イテレータ風の書き方で外部イテレータを作ることができる
このイテレータの名称として適切なのは
「外部イテレータ」「内部イテレータ」のどちらか答えよ
757デフォルトの名無しさん
2014/12/06(土) 04:27:17.30ID:VJF2Er6M Pythonでも普通にyieldで
「内部イテレータ風の書き方で外部イテレータを実装する」
ことができる。
Smalltalkにも(ちょっと無理矢理っぽいが)yieldの実装がある。
「内部イテレータ風の書き方で外部イテレータを実装する」
ことができる。
Smalltalkにも(ちょっと無理矢理っぽいが)yieldの実装がある。
758デフォルトの名無しさん
2014/12/06(土) 09:50:46.00ID:75gyZyE4 Smalltalkで>>755のCLUとRubyを再現するとこんな感じか。
| fromTo |
fromTo := [:first :last | Generator on: [:g |
| n |
n := first.
[n <= last] whileTrue: [
g yield: n.
n := n + 1
]
]].
(fromTo value: 1 value: 3) do: [:x | Transcript showln: x]
http://ideone.com/5UU1qM
| fromTo |
fromTo := [:first :last | Generator on: [:g |
| n |
n := first.
[n <= last] whileTrue: [
g yield: n.
n := n + 1
]
]].
(fromTo value: 1 value: 3) do: [:x | Transcript showln: x]
http://ideone.com/5UU1qM
759デフォルトの名無しさん
2014/12/06(土) 10:16:45.25ID:awxYdbKb visitメソッドのレシーバと引数のどっちがVisitorか迷うことがある
760デフォルトの名無しさん
2014/12/06(土) 11:43:34.93ID:VJF2Er6M どうしてRubyを推したい人は
他言語に元からある機能をなかったことに
したがるのだろうか?
他言語に元からある機能をなかったことに
したがるのだろうか?
761デフォルトの名無しさん
2014/12/06(土) 11:53:26.46ID:75gyZyE4 >>760
それはMatzやその取り巻きが悪いんだよ。
まるでRubyが初めてであるようにもとれる言い方で
信者をミスリードし続けてきた立派な成果だ。
旧Mac信者がジョブズの印象操作で育成された経緯に似ている。
それはMatzやその取り巻きが悪いんだよ。
まるでRubyが初めてであるようにもとれる言い方で
信者をミスリードし続けてきた立派な成果だ。
旧Mac信者がジョブズの印象操作で育成された経緯に似ている。
762デフォルトの名無しさん
2014/12/06(土) 12:39:03.22ID:awxYdbKb printf("%sには%sがあるから\n", "ruby", "yield");
誰でも言いそうなコピペを改変してるだけだよね
正しい情報ではなくコピペしやすい情報が拡散する
誰でも言いそうなコピペを改変してるだけだよね
正しい情報ではなくコピペしやすい情報が拡散する
763755
2014/12/06(土) 16:06:50.42ID:viXCL8M/ >>755 では「1 から 3 の範囲を」と書いたけど、具体的なコードを忘れていた
CLU では、>>755 で定義したイテレータ from_to を以下のように利用する
for i:int in int$from_to(1, 3) do
....
end
Ruby では、>>755 で定義したイテレータ from_to を以下のように利用する
from_to(1, 3) do |i|
....
end
>>757
> Pythonでも普通にyieldで
失礼、Python にも yield 文があった
ざっと調べてみたけど、どちらかというと(Ruby よりも) Python のほうが
CLU のイテレータを忠実に実装しているようだ
CLU では、>>755 で定義したイテレータ from_to を以下のように利用する
for i:int in int$from_to(1, 3) do
....
end
Ruby では、>>755 で定義したイテレータ from_to を以下のように利用する
from_to(1, 3) do |i|
....
end
>>757
> Pythonでも普通にyieldで
失礼、Python にも yield 文があった
ざっと調べてみたけど、どちらかというと(Ruby よりも) Python のほうが
CLU のイテレータを忠実に実装しているようだ
764デフォルトの名無しさん
2014/12/06(土) 16:45:53.73ID:viXCL8M/ >>760,761
Ruby では >>754 のリンク先文書で Matz が
「イテレータの定義の仕方は驚くほど Ruby に似ています。 真似したんだから当然です。
元々 Ruby のブロックは CLU のイテレータに似たものを実現するためにデザインされたからです」
と書いているように、(おそらく)最初からイテレータが存在していました
少なくとも Ruby 1.4 を元にして1999年に出版された書籍「オブジェクト指向スクリプト言語Ruby」では、
節「2.18.4 yield」で(>>755 のコードのような)イテレータ定義方法が詳しく解説されている
それに対して Python にyield文が追加されたのは2001年、おそらく Pytthon 2.x の時代ではないのかな?
・PEP 255 - PEP 255 -- Simple Generators | Python.org
https://www.python.org/dev/peps/pep-0255/
もし最初から、あるいは Python 1.x の時代から存在しているなら、ソースを提示してくれ
ソースが提示できないのなら、>>760 は
> どうしてPythonを推したい人は
> 後から追加された機能を元からあったことに
> したがるのだろうか?
と訂正したほうがいいだろね
Ruby では >>754 のリンク先文書で Matz が
「イテレータの定義の仕方は驚くほど Ruby に似ています。 真似したんだから当然です。
元々 Ruby のブロックは CLU のイテレータに似たものを実現するためにデザインされたからです」
と書いているように、(おそらく)最初からイテレータが存在していました
少なくとも Ruby 1.4 を元にして1999年に出版された書籍「オブジェクト指向スクリプト言語Ruby」では、
節「2.18.4 yield」で(>>755 のコードのような)イテレータ定義方法が詳しく解説されている
それに対して Python にyield文が追加されたのは2001年、おそらく Pytthon 2.x の時代ではないのかな?
・PEP 255 - PEP 255 -- Simple Generators | Python.org
https://www.python.org/dev/peps/pep-0255/
もし最初から、あるいは Python 1.x の時代から存在しているなら、ソースを提示してくれ
ソースが提示できないのなら、>>760 は
> どうしてPythonを推したい人は
> 後から追加された機能を元からあったことに
> したがるのだろうか?
と訂正したほうがいいだろね
765デフォルトの名無しさん
2014/12/06(土) 16:55:53.06ID:tymH4H6t る厨、渾身の反撃
766デフォルトの名無しさん
2014/12/06(土) 18:06:07.33ID:dOSwxHPK >>764
755がこんな書き方するから、「いや、他の言語にもあるだろ」と突っ込まれてるんじゃないか?
> 内部イテレータは CLU で生まれ Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴
755がこんな書き方するから、「いや、他の言語にもあるだろ」と突っ込まれてるんじゃないか?
> 内部イテレータは CLU で生まれ Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴
767デフォルトの名無しさん
2014/12/06(土) 18:10:44.25ID:dOSwxHPK768デフォルトの名無しさん
2014/12/06(土) 18:17:10.96ID:tymH4H6t >>766
なんだ、る厨のマッチポンプか。つまらん。
なんだ、る厨のマッチポンプか。つまらん。
769デフォルトの名無しさん
2014/12/06(土) 18:21:50.32ID:tymH4H6t > Ruby が継承した(Smalltalk/Java/C++/Python 等には)存在しない特徴
まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。
さすが る厨だ。Matz ゆずりのミスリードはお手の物というわけか。
まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。
さすが る厨だ。Matz ゆずりのミスリードはお手の物というわけか。
770デフォルトの名無しさん
2014/12/06(土) 18:37:35.84ID:dOSwxHPK 内部イテレータ風の記法が大規模開発でどう役立つか
そういう話なら興味深いが、このスレは直ぐ「ウチこそが元祖」の話になるな……
そういう話なら興味深いが、このスレは直ぐ「ウチこそが元祖」の話になるな……
771デフォルトの名無しさん
2014/12/06(土) 18:41:59.78ID:viXCL8M/ >>767
Python にジェネレータが導入された時期(2001年)からすれば
Ruby の成功を見てyield文を追加したんだろうけど、
さすがに「Ruby の真似をしました」とは書けないから CLU にしたんだろね
>>769
> まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。
え、CLU 以降に登場したメジャーな言語で yield 文によるイテレータを備えた言語があったの?
自分は知らないから、教えて欲しいなぁー
少なくとも、時期的には Ruby が再発見するまで Python にはyield文は存在していなかったよね(>>764)
存在していたなら、>>764 でも書いたように、ソースの提示をヨロシクね!
>>768
いや、(今のところ)ソースを提示できていないから、
「Pythonを推したい人は後から追加された機能を、さも元からあった(>>760)」かのように
ウソをついていたみたいだね
どうしてPython使いはウソツキばかりなの?
嘘でもなんでも、議論に勝ちさえすればいいと思っているのかなあ....
Python にジェネレータが導入された時期(2001年)からすれば
Ruby の成功を見てyield文を追加したんだろうけど、
さすがに「Ruby の真似をしました」とは書けないから CLU にしたんだろね
>>769
> まるで Ruby が再発見するまで CLU 以外の言語では存在し得ないような言い方だな。
え、CLU 以降に登場したメジャーな言語で yield 文によるイテレータを備えた言語があったの?
自分は知らないから、教えて欲しいなぁー
少なくとも、時期的には Ruby が再発見するまで Python にはyield文は存在していなかったよね(>>764)
存在していたなら、>>764 でも書いたように、ソースの提示をヨロシクね!
>>768
いや、(今のところ)ソースを提示できていないから、
「Pythonを推したい人は後から追加された機能を、さも元からあった(>>760)」かのように
ウソをついていたみたいだね
どうしてPython使いはウソツキばかりなの?
嘘でもなんでも、議論に勝ちさえすればいいと思っているのかなあ....
772デフォルトの名無しさん
2014/12/06(土) 18:56:12.98ID:dOSwxHPK 2001年にRubyが成功してたとか、何のジョークですか
RoRは2004年ですよ
RoRは2004年ですよ
773デフォルトの名無しさん
2014/12/06(土) 19:13:11.97ID:Ee/H8Kvv CLUとかPythonのyieldはジェネレータだけど、Rubyのは違くね?
Rubyにジェネレータ入ったのって1.9だろ?
Rubyにジェネレータ入ったのって1.9だろ?
774デフォルトの名無しさん
2014/12/06(土) 19:22:45.98ID:dOSwxHPK Rubyのyieldは見た目が似てるだけでCLUのとは別物
正当に継承してるのはPythonの方でした、というオチ?
正当に継承してるのはPythonの方でした、というオチ?
775デフォルトの名無しさん
2014/12/06(土) 19:30:05.03ID:Ee/H8Kvv >>771
当時のSatherはRubyよりは有名だっただろうね海外では
当時のSatherはRubyよりは有名だっただろうね海外では
776デフォルトの名無しさん
2014/12/06(土) 20:16:53.72ID:viXCL8M/ >>772
2001年に O'Reilly から "Ruby in a Nutshell" が出版され世界メジャーデビューを果たしている
・Ruby in a Nutshell - O'Reilly Media
http://shop.oreilly.com/product/9780596002145.do
Ruby on Rails フィーバーが起きたのは2004年だけど、
すでに2001年には日本だけのガラパゴス言語から脱して
十分に世界でも知られる存在になっていた
当然、世界レベルで "Python vs Ruby" の論争は起きただろうし、
Ruby にはあるけど Python には欠けていると指摘されたのが「洗練されたイテレータ」で、
あわてて追加したのが2001年の PEP 255 (>>764)だったんじゃないかと思われ....
>>773
外部イテレータ、いわゆるジェネレータは Ruby 1.8 にも標準ライブラリで提供されていた
1.9 では、これが組込みライブラリとして再実装されただけ
で、「Python では元からyield文があった(>>760)」という主張のソースはまだかなぁーー???
やっぱりPython使いはウソツキばかりなのかね
2001年に O'Reilly から "Ruby in a Nutshell" が出版され世界メジャーデビューを果たしている
・Ruby in a Nutshell - O'Reilly Media
http://shop.oreilly.com/product/9780596002145.do
Ruby on Rails フィーバーが起きたのは2004年だけど、
すでに2001年には日本だけのガラパゴス言語から脱して
十分に世界でも知られる存在になっていた
当然、世界レベルで "Python vs Ruby" の論争は起きただろうし、
Ruby にはあるけど Python には欠けていると指摘されたのが「洗練されたイテレータ」で、
あわてて追加したのが2001年の PEP 255 (>>764)だったんじゃないかと思われ....
>>773
外部イテレータ、いわゆるジェネレータは Ruby 1.8 にも標準ライブラリで提供されていた
1.9 では、これが組込みライブラリとして再実装されただけ
で、「Python では元からyield文があった(>>760)」という主張のソースはまだかなぁーー???
やっぱりPython使いはウソツキばかりなのかね
777デフォルトの名無しさん
2014/12/06(土) 20:40:35.48ID:dOSwxHPK778デフォルトの名無しさん
2014/12/06(土) 21:59:22.89ID:7vCPkvQk779デフォルトの名無しさん
2014/12/06(土) 22:26:02.16ID:tymH4H6t きっと、あれだろう。
「yieldを使うなどしてRubyのようにCLUからイテレーターをコピーしたのはRubyが最初」
とかいうガッチガチの縛り付き起源論。
「〜は既にあったんじゃ?」とか指摘するたびに
「〜は○○がRubyのそれと違う」とか縛りがどんどん増えていくタイプの。
「yieldを使うなどしてRubyのようにCLUからイテレーターをコピーしたのはRubyが最初」
とかいうガッチガチの縛り付き起源論。
「〜は既にあったんじゃ?」とか指摘するたびに
「〜は○○がRubyのそれと違う」とか縛りがどんどん増えていくタイプの。
780デフォルトの名無しさん
2014/12/06(土) 23:01:36.75ID:q7blqefO781デフォルトの名無しさん
2014/12/07(日) 00:03:15.33ID:zkEhiByJ 結局、最新の技術を取り入れた静的型付け言語が
最も優れた言語になるのかな。
最も優れた言語になるのかな。
782755
2014/12/07(日) 00:07:58.15ID:hGORpEWm783デフォルトの名無しさん
2014/12/07(日) 00:14:16.44ID:dQg0RQig784デフォルトの名無しさん
2014/12/07(日) 00:45:01.66ID:svj68kfn785デフォルトの名無しさん
2014/12/07(日) 00:49:15.39ID:3Elo+9Qw 嘘はよくないけど逃げるのはよいよね
間違いを認めるとかはどうでもよい
間違いを認めるとかはどうでもよい
786デフォルトの名無しさん
2014/12/07(日) 01:50:41.36ID:hGORpEWm >>784
Smalltalk のアレも内部イテレータだね
反復(iteration)をコルーチンとして抽象化する最初の発想は、CLU と Smalltalk の共通の祖である Simula 67 で生まれ、
それはジェネレータと呼ばれていた
そして、その発想はどちらの言語にも継承されたけど、静的型付けな手続き型言語である CLU と
動的型付けなオブジェクト指向言語である Smalltalk とでは、実現方法が異なった
CLU は iter 宣言と yield 文という抽象化向けの構文を導入し、反復処理の表現(プログラミング)を洗練させた
また反復の概念を整理/形式化し、それにイテレータという名称を与えたのは CLU の功績
だからイテレータの始祖は CLU であると、一般には認知されている
それに対してブロック(=クロージャ)を持つ Smalltalk は、(CLU のように苦労することなく)反復処理を抽象化できた
実際、Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない
結果として Smalltalk のコミュニティの中でジェネレータは反復処理のプログラミング技法、
いわゆるイディオムとしては認知されていたけど、それが学術的に議論されることは無かった
(実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた)
こうした、ある新しく登場した概念が実は Smalltalk の世界だとありふれたイディオムでしかなかったという現象は、
(たとえばデザインパターンのように)しばしば見かけられる
Smalltalk のアレも内部イテレータだね
反復(iteration)をコルーチンとして抽象化する最初の発想は、CLU と Smalltalk の共通の祖である Simula 67 で生まれ、
それはジェネレータと呼ばれていた
そして、その発想はどちらの言語にも継承されたけど、静的型付けな手続き型言語である CLU と
動的型付けなオブジェクト指向言語である Smalltalk とでは、実現方法が異なった
CLU は iter 宣言と yield 文という抽象化向けの構文を導入し、反復処理の表現(プログラミング)を洗練させた
また反復の概念を整理/形式化し、それにイテレータという名称を与えたのは CLU の功績
だからイテレータの始祖は CLU であると、一般には認知されている
それに対してブロック(=クロージャ)を持つ Smalltalk は、(CLU のように苦労することなく)反復処理を抽象化できた
実際、Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない
結果として Smalltalk のコミュニティの中でジェネレータは反復処理のプログラミング技法、
いわゆるイディオムとしては認知されていたけど、それが学術的に議論されることは無かった
(実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた)
こうした、ある新しく登場した概念が実は Smalltalk の世界だとありふれたイディオムでしかなかったという現象は、
(たとえばデザインパターンのように)しばしば見かけられる
787デフォルトの名無しさん
2014/12/07(日) 02:03:23.69ID:hGORpEWm788デフォルトの名無しさん
2014/12/07(日) 08:12:25.48ID:vPGA0H7X789デフォルトの名無しさん
2014/12/07(日) 08:23:27.33ID:NlsKlGNA ルビーより後に実装されたのはみんなルビーの真似w
790デフォルトの名無しさん
2014/12/07(日) 09:49:05.54ID:3Elo+9Qw 歴史歪曲を考える暇があったら、副作用の順序を間違える事案について考えよう
791デフォルトの名無しさん
2014/12/07(日) 09:51:11.11ID:bfkTF4nN ここの住民には無理
792デフォルトの名無しさん
2014/12/07(日) 09:56:13.58ID:NlsKlGNA >>776-777の流れが全てを物語っているw
793デフォルトの名無しさん
2014/12/07(日) 13:22:05.08ID:6EqZg1tl >>786
> Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない
next は分かるのですが、first を定義する必要があるというのは初耳です。
そのようなプロトコルが規定されているのは何というSmalltalk処理系ですか?
あるいはそのように記述された文献をお示しいただければさいわいです。
あと、Smalltalkの外部イテレーター(内部イテレーターとしても使用できる)としては
Streamが有名ですが、これとおっしゃっておられる「Smalltalkのジェネレーター」との
関係を教えてください。
> 実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた
寡聞にして知りませんでした。
たとえば具体的にどんな文書でそのような用語が使われていたか教えていただけると助かります。
> Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない
next は分かるのですが、first を定義する必要があるというのは初耳です。
そのようなプロトコルが規定されているのは何というSmalltalk処理系ですか?
あるいはそのように記述された文献をお示しいただければさいわいです。
あと、Smalltalkの外部イテレーター(内部イテレーターとしても使用できる)としては
Streamが有名ですが、これとおっしゃっておられる「Smalltalkのジェネレーター」との
関係を教えてください。
> 実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた
寡聞にして知りませんでした。
たとえば具体的にどんな文書でそのような用語が使われていたか教えていただけると助かります。
794デフォルトの名無しさん
2014/12/07(日) 13:42:54.66ID:acBjRoXT > Smalltalk-80 のジェネレータは first と next というメソッドが定義された任意のオブジェクトでしかない
一つ疑問があるんだけどさ、firstとnextをジェネレータとは
違う用途で使ったオブジェクトはどうなるの?
正しく動かないと思うけど。
そうすると、firstとnextはジェネレータで使うための名前ですって
予約語みたいな扱いになっているということ?
一つ疑問があるんだけどさ、firstとnextをジェネレータとは
違う用途で使ったオブジェクトはどうなるの?
正しく動かないと思うけど。
そうすると、firstとnextはジェネレータで使うための名前ですって
予約語みたいな扱いになっているということ?
795デフォルトの名無しさん
2014/12/07(日) 14:10:40.21ID:3Elo+9Qw796デフォルトの名無しさん
2014/12/07(日) 14:18:07.50ID:acBjRoXT >>795
何を言ってるのさ?
純粋に疑問になっただけ
例えばfirstという名前で、初期化処理
secondという名前で、2番目の処理、
thirdという名前で3番目の処理
みたいなことをしているオブジェクトがあったとしたら
当然ジェネレータとしては使えない。
だからfirstという関数名はジェネレータのfirstの
仕様を守らないといけないというルールがあるのか?って話なんだが。
何を言ってるのさ?
純粋に疑問になっただけ
例えばfirstという名前で、初期化処理
secondという名前で、2番目の処理、
thirdという名前で3番目の処理
みたいなことをしているオブジェクトがあったとしたら
当然ジェネレータとしては使えない。
だからfirstという関数名はジェネレータのfirstの
仕様を守らないといけないというルールがあるのか?って話なんだが。
797デフォルトの名無しさん
2014/12/07(日) 18:16:20.48ID:hGORpEWm >>793
>next は分かるのですが、first を定義する必要があるというのは初耳です。
>そのようなプロトコルが規定されているのは何というSmalltalk処理系ですか?
>あるいはそのように記述された文献をお示しいただければさいわいです。
1986年に書かれた "The Generator Paradigm in Smalltalk" という文書です
題名でググるとPDFで見つけられます
>あと、Smalltalkの外部イテレーター(内部イテレーターとしても使用できる)としては
>Streamが有名ですが、これとおっしゃっておられる「Smalltalkのジェネレーター」との
>関係を教えてください。
単に ReadStream クラスが Smalltalk の作法(慣習)に沿って設計されたのだと思いますが、
それを裏付けるソース(文献)は知りませんし、それ以上の関係も知りません
>> 実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた
>
>寡聞にして知りませんでした。
>たとえば具体的にどんな文書でそのような用語が使われていたか教えていただけると助かります。
上記の文献では、ジェネレータという用語が使われています
イテレータという用語は1974年に発表されたCLUの論文によって世に知られるようになりました
自分の知る範囲で、Smalltalk とイテレータとの関連が議論されたのは1995年出版のデザパタ本(GoF)が最初だと思います
少なくともブルーブックの名で知られている Smalltalk のバイブル "Smalltalk-80: The Language and Its Implementation"
では、イテレータという用語は使われていません
もしも CLU 以前の時代に Smalltalk とイテレータを扱った文献が存在していたなら、ぜひ教えてほしいですね
>next は分かるのですが、first を定義する必要があるというのは初耳です。
>そのようなプロトコルが規定されているのは何というSmalltalk処理系ですか?
>あるいはそのように記述された文献をお示しいただければさいわいです。
1986年に書かれた "The Generator Paradigm in Smalltalk" という文書です
題名でググるとPDFで見つけられます
>あと、Smalltalkの外部イテレーター(内部イテレーターとしても使用できる)としては
>Streamが有名ですが、これとおっしゃっておられる「Smalltalkのジェネレーター」との
>関係を教えてください。
単に ReadStream クラスが Smalltalk の作法(慣習)に沿って設計されたのだと思いますが、
それを裏付けるソース(文献)は知りませんし、それ以上の関係も知りません
>> 実際、当時の Smalltalk の文献ではイテレータという用語は使われず、Simula と同じジェネレータが使われた
>
>寡聞にして知りませんでした。
>たとえば具体的にどんな文書でそのような用語が使われていたか教えていただけると助かります。
上記の文献では、ジェネレータという用語が使われています
イテレータという用語は1974年に発表されたCLUの論文によって世に知られるようになりました
自分の知る範囲で、Smalltalk とイテレータとの関連が議論されたのは1995年出版のデザパタ本(GoF)が最初だと思います
少なくともブルーブックの名で知られている Smalltalk のバイブル "Smalltalk-80: The Language and Its Implementation"
では、イテレータという用語は使われていません
もしも CLU 以前の時代に Smalltalk とイテレータを扱った文献が存在していたなら、ぜひ教えてほしいですね
798デフォルトの名無しさん
2014/12/07(日) 19:37:57.79ID:eR9x6pgx >>797
なるほどティモシー・バットの実装・主張でしたか。
Smalltalkの常識が役に立たないわけです。^^;
本家Smalltalk(の、ごく初期の実装であるSmalltalk-72)からある
Streamと彼の言うジェネレータとの関係は、
彼のかなり風変わりなSmalltalk実装であるLittle Smalltalkに
ついて書かれた書籍にその記述が見つけられました。
http://sdmeta.gforge.inria.fr/FreeBooks/LittleSmalltalk/ALittleSmalltalk.pdf
In the Smalltalk-80 language (Goldberg83), the concept of
streams is in many ways similar to the idea of generators.
For the most part, streams use a slightly different interface,
namely the pair of messages reset (which initializes the
generator but does not return any value) and next (which is
used for both the first and all succeeding elements). The
message do: is adapted from the streams of (Goldberg83). An
article by Deutsch (Byte 81) discusses in more detail many
aspects of generators in the Smalltalk 80 system.
ありがとうございます。
あと老婆心ながら、パッドがSmalltalkについて書くときは、
暗黙のうちに彼独自仕様のLittle Smalltalkを前提にしている
ことがあるので、そこから得た知識をSmalltalkに一般化したり、
あるいは狭義には本家PARC謹製実装を指す「Smalltalk-80」という
呼称でそれを語るのは、聞き手に無用の混乱を招くので
今後は避けられた方がよいと思います。
なるほどティモシー・バットの実装・主張でしたか。
Smalltalkの常識が役に立たないわけです。^^;
本家Smalltalk(の、ごく初期の実装であるSmalltalk-72)からある
Streamと彼の言うジェネレータとの関係は、
彼のかなり風変わりなSmalltalk実装であるLittle Smalltalkに
ついて書かれた書籍にその記述が見つけられました。
http://sdmeta.gforge.inria.fr/FreeBooks/LittleSmalltalk/ALittleSmalltalk.pdf
In the Smalltalk-80 language (Goldberg83), the concept of
streams is in many ways similar to the idea of generators.
For the most part, streams use a slightly different interface,
namely the pair of messages reset (which initializes the
generator but does not return any value) and next (which is
used for both the first and all succeeding elements). The
message do: is adapted from the streams of (Goldberg83). An
article by Deutsch (Byte 81) discusses in more detail many
aspects of generators in the Smalltalk 80 system.
ありがとうございます。
あと老婆心ながら、パッドがSmalltalkについて書くときは、
暗黙のうちに彼独自仕様のLittle Smalltalkを前提にしている
ことがあるので、そこから得た知識をSmalltalkに一般化したり、
あるいは狭義には本家PARC謹製実装を指す「Smalltalk-80」という
呼称でそれを語るのは、聞き手に無用の混乱を招くので
今後は避けられた方がよいと思います。
799デフォルトの名無しさん
2014/12/07(日) 20:20:51.08ID:hGORpEWm >>798
結論としては、今のところ挙っているソース(文献)を前提とすれば:
・オリジナルの Smalltalk コミュニティでは概念としてのイテレータは存在していなかった
・ただしコレクションやストリームの実装で用いられた Smalltalk の作法(慣習)は、
デザパタ本(GoF)によって内部イテレータとして分類された
ということですかね
結論としては、今のところ挙っているソース(文献)を前提とすれば:
・オリジナルの Smalltalk コミュニティでは概念としてのイテレータは存在していなかった
・ただしコレクションやストリームの実装で用いられた Smalltalk の作法(慣習)は、
デザパタ本(GoF)によって内部イテレータとして分類された
ということですかね
800デフォルトの名無しさん
2014/12/07(日) 21:29:04.46ID:eR9x6pgx >>799
> もしも CLU 以前の時代に Smalltalk とイテレータを扱った文献が存在していたなら、ぜひ教えてほしい
もとより、リスコフが件のループ処理の抽象化にイテレータと名付けて発表したのは1977年のこの文献
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.656&rep=rep1&type=pdf
だと思うのですが、そうすると同様のことを目指す類似の仕組みがあったとして、それを
「イテレータ」と呼称するには少なくとも1977年以降でなければ困難だと思うのですが、これは
1977年以前に実装され、活用されていたという事実を示せばいいという解釈でよろしいですか?
それとも、「イテレータ」という言葉を使っていないとダメという縛りでしょうか?
> もしも CLU 以前の時代に Smalltalk とイテレータを扱った文献が存在していたなら、ぜひ教えてほしい
もとより、リスコフが件のループ処理の抽象化にイテレータと名付けて発表したのは1977年のこの文献
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112.656&rep=rep1&type=pdf
だと思うのですが、そうすると同様のことを目指す類似の仕組みがあったとして、それを
「イテレータ」と呼称するには少なくとも1977年以降でなければ困難だと思うのですが、これは
1977年以前に実装され、活用されていたという事実を示せばいいという解釈でよろしいですか?
それとも、「イテレータ」という言葉を使っていないとダメという縛りでしょうか?
801デフォルトの名無しさん
2014/12/07(日) 23:41:25.71ID:hGORpEWm >>800
自分もその文献を参照して CLU がイテレータで生まれたと判断しました
だから、時期としてはそれ以前ということですね
またイテレータという名称にこだわる必要はありませんが、
first と next という作法で実現できる外部イテレータは
C++/Java だけでなくC言語でも実装できる一般的なプログラミング技法ですから、
CLU の内部イテレータからは外れるでしょう
またループ処理の抽象化はイテレータだけでなく LISP を始祖とする関数型言語の
map 関数がありますが、これをイテレータと呼ぶのは無理があるでしょう
CLU の内部イテレータは、当時のクロージャを持たない手続き型言語へ
コルーチンの仕掛けを洗練された形で組み込んだことに意義があると思います
もし CLU 以外にも、当時の手続き型言語の中でループ処理の抽象化に
取り組んだ研究があったなら、興味深いですね
自分もその文献を参照して CLU がイテレータで生まれたと判断しました
だから、時期としてはそれ以前ということですね
またイテレータという名称にこだわる必要はありませんが、
first と next という作法で実現できる外部イテレータは
C++/Java だけでなくC言語でも実装できる一般的なプログラミング技法ですから、
CLU の内部イテレータからは外れるでしょう
またループ処理の抽象化はイテレータだけでなく LISP を始祖とする関数型言語の
map 関数がありますが、これをイテレータと呼ぶのは無理があるでしょう
CLU の内部イテレータは、当時のクロージャを持たない手続き型言語へ
コルーチンの仕掛けを洗練された形で組み込んだことに意義があると思います
もし CLU 以外にも、当時の手続き型言語の中でループ処理の抽象化に
取り組んだ研究があったなら、興味深いですね
802デフォルトの名無しさん
2014/12/08(月) 08:33:17.02ID:voJSmgM1803デフォルトの名無しさん
2014/12/08(月) 09:55:18.35ID:kmGTZboH 外部イテレータは存在意義が分かるんだけど、
内部イテレータの存在意義が分からない
高階関数があれば全く不要じゃないの?こんなもんに予約語使うRubyは馬鹿なんじゃないの?
内部イテレータの存在意義が分からない
高階関数があれば全く不要じゃないの?こんなもんに予約語使うRubyは馬鹿なんじゃないの?
804デフォルトの名無しさん
2014/12/08(月) 10:47:05.59ID:7TNBMlk3 結局、Rubyコミュニティ内でも、
> Rubyのイテレータは用途的にはCLUのイテレータよりも
> Smalltalkのブロック (を受け取るメソッド)に似ている
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/13374
という結論になっているんだね。
> Rubyのイテレータは用途的にはCLUのイテレータよりも
> Smalltalkのブロック (を受け取るメソッド)に似ている
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/13374
という結論になっているんだね。
805デフォルトの名無しさん
2014/12/08(月) 11:52:53.80ID:hyn7lotS LispやSmalltalkは低級言語に似てないからダメ
同じ理由で高階関数もダメだろうと高を括っていたんじゃないか
ところが現実はC++でも高階関数を使いこなせるレベルになりつつある
同じ理由で高階関数もダメだろうと高を括っていたんじゃないか
ところが現実はC++でも高階関数を使いこなせるレベルになりつつある
806デフォルトの名無しさん
2014/12/08(月) 19:51:47.86ID:Ag3PuK/D 言語の仕様の変更が柔軟なのは動的型付け言語なんだよな。
型のことを考える必要がないぶん、アイデアをすぐに実装できる。
だけど、そのアイデアそのものは静的型付け言語でも実装可能。
型を考える分だけ時間がかかるだけ。
動的型付け言語の機能はほぼ全て静的型付け言語で実装できるし、
型安全になりさらにいい形で実装される。
型のことを考える必要がないぶん、アイデアをすぐに実装できる。
だけど、そのアイデアそのものは静的型付け言語でも実装可能。
型を考える分だけ時間がかかるだけ。
動的型付け言語の機能はほぼ全て静的型付け言語で実装できるし、
型安全になりさらにいい形で実装される。
807801
2014/12/08(月) 21:41:44.49ID:9AWpAGuY まず >>801 の日本語が変だったので訂正
X: 自分もその文献を参照して CLU がイテレータで生まれたと判断しました
O: 自分もその文献を参照してイテレータが CLU で生まれたと判断しました
>>802
いや、CLU はコルーチンを使っていないし、そんな縛りはありませんよ
ループ処理を生産者/消費者に分割するプログラミング技法としてコルーチンが
CLU 以前から知られていましたけど、保守のしづらいコードになりがちでした
そのコルーチンを使わずにループ処理を抽象化したのが CLU のイテレータです
>>803
> こんなもんに予約語使うRubyは馬鹿なんじゃないの?
だとしたら、ジェネレータ(外部イテレータ)が重要な言語の構成要素であり、
なおかつ高階関数もすでに備えていたにもかかわらず、
後からわざわざ予約語 yield を追加した Python の PEP 205(>>764) は
Ruby 以下の大馬鹿ってことですね
自分としては、ジェネレータを(まるで内部イテレータのように)簡潔に定義できるようにすることを
意図した PEP 205 の判断は適切であったと思っていますけど、
まあ、仕様追加を容認/批判するのは人それぞれなんでしょうね....
X: 自分もその文献を参照して CLU がイテレータで生まれたと判断しました
O: 自分もその文献を参照してイテレータが CLU で生まれたと判断しました
>>802
いや、CLU はコルーチンを使っていないし、そんな縛りはありませんよ
ループ処理を生産者/消費者に分割するプログラミング技法としてコルーチンが
CLU 以前から知られていましたけど、保守のしづらいコードになりがちでした
そのコルーチンを使わずにループ処理を抽象化したのが CLU のイテレータです
>>803
> こんなもんに予約語使うRubyは馬鹿なんじゃないの?
だとしたら、ジェネレータ(外部イテレータ)が重要な言語の構成要素であり、
なおかつ高階関数もすでに備えていたにもかかわらず、
後からわざわざ予約語 yield を追加した Python の PEP 205(>>764) は
Ruby 以下の大馬鹿ってことですね
自分としては、ジェネレータを(まるで内部イテレータのように)簡潔に定義できるようにすることを
意図した PEP 205 の判断は適切であったと思っていますけど、
まあ、仕様追加を容認/批判するのは人それぞれなんでしょうね....
808デフォルトの名無しさん
2014/12/08(月) 21:47:10.82ID:NhV7D2A0 外部イテレータを内部イテレータかのように記述できるPythonのyieldには価値がある
だからJavascript(ES6)などにも採用されている
一方、Rubyの内部イテレータには価値が無い
単純な話じゃん
だからJavascript(ES6)などにも採用されている
一方、Rubyの内部イテレータには価値が無い
単純な話じゃん
809801
2014/12/08(月) 22:43:49.37ID:9AWpAGuY >>804
>>754 で書いたように Ruby は LISP をベースに設計され、
ブロックも LISP のクロージャに由来します
だから、同じブロックを使う Smalltalk と意味が似るのは不思議じゃないですね
実際 >>755 のイテレータ定義は、yield を使わなくとも Smalltalk の value メッセージに
相当するメソッド Proc#call へと単純に置き換えることができます
def from_to(first, last, &block)
n = first
while n <= last
block.call n
n += 1
end
end
Ruby と CLU の関連性に関しては、(あくまで私見ですが) LISP を心臓部(意味)として、
(S式ではなく)Perl に代表される手続き型言語のプログラマに受け入れられる表層の皮(構文)で
包んだ時に、手続き型言語である CLU のイテレータという概念を参考にしたのだと思います
だから外観は CLU のイテレータのように見えるけど、その実装は LISP/Smalltak と類似するという
結果になるのでしょう
>>754 で書いたように Ruby は LISP をベースに設計され、
ブロックも LISP のクロージャに由来します
だから、同じブロックを使う Smalltalk と意味が似るのは不思議じゃないですね
実際 >>755 のイテレータ定義は、yield を使わなくとも Smalltalk の value メッセージに
相当するメソッド Proc#call へと単純に置き換えることができます
def from_to(first, last, &block)
n = first
while n <= last
block.call n
n += 1
end
end
Ruby と CLU の関連性に関しては、(あくまで私見ですが) LISP を心臓部(意味)として、
(S式ではなく)Perl に代表される手続き型言語のプログラマに受け入れられる表層の皮(構文)で
包んだ時に、手続き型言語である CLU のイテレータという概念を参考にしたのだと思います
だから外観は CLU のイテレータのように見えるけど、その実装は LISP/Smalltak と類似するという
結果になるのでしょう
810801
2014/12/08(月) 23:29:50.99ID:9AWpAGuY >>805
元々の質問者(>>800, ID:eR9x6pgx)の方が Smalltalk に詳しそうなので、
1997年の CLU および Smalltalk-80 以前における初期の Smalltalk の
(後にGoF本で内部イテレータと呼ばれることになる)ループ処理設計の誕生話を期待していました
自分は Smalltalk にはそれほど詳しくないんで、それ辺りの歴史を披露してもらえたら嬉しかったですね
あるいは1970年代に Scheme で生まれた継続(コンティニュエーション)の概念や、
並行ループ処理をプロセス構造で表現する CSP や実装言語である Occam あたりかもしれないと
想像していました
これら現在ではイテレータには分類されていないけど実はループ処理の抽象化に関連していた
過去の埋もれた知見が得られるか、つまり何かを再発見できるかと期待していたんですが、
結局、想定されていたのは良く知られた(=ありふれた)高階関数だったのですかねぇ.....
まずは彼からのレスを待つことにします
元々の質問者(>>800, ID:eR9x6pgx)の方が Smalltalk に詳しそうなので、
1997年の CLU および Smalltalk-80 以前における初期の Smalltalk の
(後にGoF本で内部イテレータと呼ばれることになる)ループ処理設計の誕生話を期待していました
自分は Smalltalk にはそれほど詳しくないんで、それ辺りの歴史を披露してもらえたら嬉しかったですね
あるいは1970年代に Scheme で生まれた継続(コンティニュエーション)の概念や、
並行ループ処理をプロセス構造で表現する CSP や実装言語である Occam あたりかもしれないと
想像していました
これら現在ではイテレータには分類されていないけど実はループ処理の抽象化に関連していた
過去の埋もれた知見が得られるか、つまり何かを再発見できるかと期待していたんですが、
結局、想定されていたのは良く知られた(=ありふれた)高階関数だったのですかねぇ.....
まずは彼からのレスを待つことにします
811デフォルトの名無しさん
2014/12/08(月) 23:59:43.81ID:wXlNa9C1 >>807
> CLU はコルーチンを使っていないし、そんな縛りはありません
おっしゃりたいことがちょっとよく分かりません。
> 801
> CLU の内部イテレータは、―
> コルーチンの仕掛けを洗練された形で組み込んだことに意義がある
これは、コルーチン“的な”仕掛け、という意味で、
コルーチンである必要はないということですか?
例えば、まだクロージャをもたないSmalltalk-76の頃からあった
stream ← #(1 2 3) asStream.
for x to stream do [user show: x; cr]
という内部イテレータとして使える外部イテレータである
ストリームという発案が
> C++/Java だけでなくC言語でも実装できる
> 一般的なプログラミング技法
とか
> 保守のしづらいコードになりがち
というよくわからない難癖で排除される理由も理解しかねます。
てっきり、コルーチンでないからダメなのかと思ったのですが?
> CLU はコルーチンを使っていないし、そんな縛りはありません
おっしゃりたいことがちょっとよく分かりません。
> 801
> CLU の内部イテレータは、―
> コルーチンの仕掛けを洗練された形で組み込んだことに意義がある
これは、コルーチン“的な”仕掛け、という意味で、
コルーチンである必要はないということですか?
例えば、まだクロージャをもたないSmalltalk-76の頃からあった
stream ← #(1 2 3) asStream.
for x to stream do [user show: x; cr]
という内部イテレータとして使える外部イテレータである
ストリームという発案が
> C++/Java だけでなくC言語でも実装できる
> 一般的なプログラミング技法
とか
> 保守のしづらいコードになりがち
というよくわからない難癖で排除される理由も理解しかねます。
てっきり、コルーチンでないからダメなのかと思ったのですが?
812デフォルトの名無しさん
2014/12/09(火) 00:34:52.29ID:7jn1Y2FE >>808
つまり Ruby が CLU のイテレータを再発見するまで、いいかえると
Python 設計者は PEP 205(>>764) 発表の2001年まで yield 文の重要性に気付かず、
世界中のPythonプログラマは冗長なジェネレータを書き続けていたことになるね
しかも PEP 205 で導入された yield文(statement) は検討が不十分であった為、
PEP 342 で yield 式(expression)へと後方互換性を放棄する構文の仕様変更に追い込まれている
・PEP 342 -- Coroutines via Enhanced Generators | Python.org
https://www.python.org/dev/peps/pep-0342/
それに対して1999年の Ruby 1.4 (>>764)では yield はブロックの評価結果を返す式として定義されている
しかも外部イテレータは 1.8 で標準ライブラリとして、 1.9 では組み込みライブラリとして提供された
もちろん(後方互換性を喪失させた Python とは異なり)言語の構文仕様へ変更を加えることなく....
最初から内部イテレータとyield式を備え、楽々と外部イテレータにも対応した Ruby、そして
Ruby を必死で追いかけて予約語 yield の追加とyield文からyield式へと仕様が迷走した Python....
どちらが言語としての先見性に優れていたか、単純な話じゃん
つまり Ruby が CLU のイテレータを再発見するまで、いいかえると
Python 設計者は PEP 205(>>764) 発表の2001年まで yield 文の重要性に気付かず、
世界中のPythonプログラマは冗長なジェネレータを書き続けていたことになるね
しかも PEP 205 で導入された yield文(statement) は検討が不十分であった為、
PEP 342 で yield 式(expression)へと後方互換性を放棄する構文の仕様変更に追い込まれている
・PEP 342 -- Coroutines via Enhanced Generators | Python.org
https://www.python.org/dev/peps/pep-0342/
それに対して1999年の Ruby 1.4 (>>764)では yield はブロックの評価結果を返す式として定義されている
しかも外部イテレータは 1.8 で標準ライブラリとして、 1.9 では組み込みライブラリとして提供された
もちろん(後方互換性を喪失させた Python とは異なり)言語の構文仕様へ変更を加えることなく....
最初から内部イテレータとyield式を備え、楽々と外部イテレータにも対応した Ruby、そして
Ruby を必死で追いかけて予約語 yield の追加とyield文からyield式へと仕様が迷走した Python....
どちらが言語としての先見性に優れていたか、単純な話じゃん
813デフォルトの名無しさん
2014/12/09(火) 01:30:40.08ID:5nnX6sRe >>776-777で完全論破されてんのに
まだPythonのyield導入にRubyは無関係だって認めてないのかw
まだPythonのyield導入にRubyは無関係だって認めてないのかw
814デフォルトの名無しさん
2014/12/09(火) 02:00:48.32ID:WiqIx9bM >>811
× for x to stream do [user show: x; cr]
○ for% x from: stream do% [x print. user cr]
Smalltalk-72 と 76 がごっちゃになって記述を間違えましたので訂正します。
ちなみに % のところは実際はオープンコロンという白抜きのコロン(非ASCII文字)を使います。
× for x to stream do [user show: x; cr]
○ for% x from: stream do% [x print. user cr]
Smalltalk-72 と 76 がごっちゃになって記述を間違えましたので訂正します。
ちなみに % のところは実際はオープンコロンという白抜きのコロン(非ASCII文字)を使います。
815デフォルトの名無しさん
2014/12/09(火) 09:46:11.30ID:RdsPil5f Ruby厨が過去を振り返るのに忙しいのは、
もう進歩が止まっちゃったから?
TwitterがScalaに乗り換えた件でケチが付き始めて、
今ではパクったはずのperlより遥かにシェア落としてるんだっけ?
もう進歩が止まっちゃったから?
TwitterがScalaに乗り換えた件でケチが付き始めて、
今ではパクったはずのperlより遥かにシェア落としてるんだっけ?
816デフォルトの名無しさん
2014/12/09(火) 16:22:39.15ID:j4N/cP02 まさかルビ厨がPythonに言語仕様の後方互換性で喧嘩を売る現場を目撃するとは..w
817デフォルトの名無しさん
2014/12/09(火) 17:46:01.03ID:64I0Ciqv yieldが文から式に変わったことで動かなくなったコードってどんなの?
後方互換性を放棄したと言うんだから、あるはずだよね?
後方互換性を放棄したと言うんだから、あるはずだよね?
818デフォルトの名無しさん
2014/12/09(火) 21:39:51.00ID:7jn1Y2FE >>811
>コルーチンである必要はないということですか?
ないです
当時のコルーチンは(アセンブリ言語レベルで)システムスタックを操作するか、
あるいは処理を「ぶつ切り」にした(保守しづらい)コルーチン風のプログラミングで実装するしかなかった
だからコルーチンの用途は限定され、ループ処理は while 文や for .. to 文といった伝統的な
構文で書くのが手続き型言語の一般常識になっていました
これを(ループ処理に限定されるとはいえ)イテレータという概念で
「コルーチンとは異なる視点」から抽象化したのが CLU の成果だと思っています
もし CLU とは別の視点でループ処理の抽象化に取り組んだ研究/考察であれば歓迎ですね
(ただし、関数型言語 の LISP に由来し今では誰でも知っている高階関数は .... ですけど)
>例えば、まだクロージャをもたないSmalltalk-76の頃からあった
>
>stream ← #(1 2 3) asStream.
>for x to stream do [user show: x; cr]
>
>という内部イテレータとして使える外部イテレータである
>ストリームという発案
イテレータから各要素を for という構文で列挙するという発想は1977年の CLU (>>800)と似ていますね
(CLU におけるイテレータの列挙は for .. in 構文に限定された仕様でしたが、これは -76 の影響???)
この for は Smalltalk-76 の予約語に見えますが、(特殊な)メッセージだったのでしょうか?
また Smalltalk-80 だと do メッセージへ変更されていますけど、何か理由があったのでしょうか?
そして -76 の stream も next メッセージが実装された(外部イテレータとして)のオブジェクトだったのでしょうか?
色々と興味深いですね....
>コルーチンである必要はないということですか?
ないです
当時のコルーチンは(アセンブリ言語レベルで)システムスタックを操作するか、
あるいは処理を「ぶつ切り」にした(保守しづらい)コルーチン風のプログラミングで実装するしかなかった
だからコルーチンの用途は限定され、ループ処理は while 文や for .. to 文といった伝統的な
構文で書くのが手続き型言語の一般常識になっていました
これを(ループ処理に限定されるとはいえ)イテレータという概念で
「コルーチンとは異なる視点」から抽象化したのが CLU の成果だと思っています
もし CLU とは別の視点でループ処理の抽象化に取り組んだ研究/考察であれば歓迎ですね
(ただし、関数型言語 の LISP に由来し今では誰でも知っている高階関数は .... ですけど)
>例えば、まだクロージャをもたないSmalltalk-76の頃からあった
>
>stream ← #(1 2 3) asStream.
>for x to stream do [user show: x; cr]
>
>という内部イテレータとして使える外部イテレータである
>ストリームという発案
イテレータから各要素を for という構文で列挙するという発想は1977年の CLU (>>800)と似ていますね
(CLU におけるイテレータの列挙は for .. in 構文に限定された仕様でしたが、これは -76 の影響???)
この for は Smalltalk-76 の予約語に見えますが、(特殊な)メッセージだったのでしょうか?
また Smalltalk-80 だと do メッセージへ変更されていますけど、何か理由があったのでしょうか?
そして -76 の stream も next メッセージが実装された(外部イテレータとして)のオブジェクトだったのでしょうか?
色々と興味深いですね....
819デフォルトの名無しさん
2014/12/09(火) 23:30:56.22ID:4fop6YGQ 外部イテレータとは while, for 等の伝統的構文が外から見えるという意味
例えばイベント駆動をやりたいときにプログラマが明示的にwhile文を書くようなもの
イテレータが様々なイベントをreturnすれば副作用もあるし戻り値の型も宣言できない
ほぼ全てのパラダイムを否定するので荒れやすいです
例えばイベント駆動をやりたいときにプログラマが明示的にwhile文を書くようなもの
イテレータが様々なイベントをreturnすれば副作用もあるし戻り値の型も宣言できない
ほぼ全てのパラダイムを否定するので荒れやすいです
820デフォルトの名無しさん
2014/12/10(水) 07:35:20.61ID:8efWXp1v 結局Pythonのyieldの後方互換性問題って何だったの?
ルビ厨お得意のFUDですか?
ルビ厨お得意のFUDですか?
821デフォルトの名無しさん
2014/12/10(水) 10:47:06.06ID:UPnzY5Pb >>818
> これは -76 の影響???
1974年当時の Smalltalk-72 向けのブートストラップ用ソースを元にしたこのファイル
http://ftp.squeak.org/goodies/Smalltalk-72/ALLDEFS
の for の定義のコメントには「An Algol-like “for”.」とあります。-76 もこの流れで、CLU も
ALGOLライクな for を意識して拡張した構文を考えたら似たものになった、というだけだと思います。
ちなみに 1974年当時のこの -72 のソース内には先に -76 で示した
for x from stream …のようなイディオムはまだ登場していなかったようですが、
ただ stream 自体はすでにあり、外部イテレーターとして積極的に用いられていたようです。
> この for は Smalltalk-76 の予約語に見えますが、(特殊な)メッセージだったのでしょうか?
この for …は、-76 では省略されたレシーバー(コンパイラ)に対する for% x from: stream do% ...
というメッセージの送信として解釈されます(-72 のはまた別の機構。為念)。ただ内部的には for%from:do%
というメソッドがそのままコールされるわけではなく、いったん特殊形式として認識され、字句解析の後に
対応する forfromdo:args: というメソッドがコールされるしくみのようなので、通常の言語における
「予約語」の性格は強いかもしれません。
> また Smalltalk-80 だと do メッセージへ変更されていますけど、何か理由があったのでしょうか?
やはりブロック(当初はコンテキスト、後にクロージャー)の導入が契機だったと思います。
-76 ではコードブロックを [ ] で括りブロックのように見えますが、これは Ruby のブロック同様、
第一級オブジェクトではありませんでした。
> そして -76 の stream も next メッセージが実装された(外部イテレータとして)の
> オブジェクトだったのでしょうか?
そうです。繰り返しになりますが、外部イテレータとしての stream は -72 からあったので。
for%form:do% のようなイデオム(通常の言語では新しい構文のようなものでしょうか)が登場し、
内部イテレータとしても使うようになったのは、-72 の拡張版の -74 か、-76 からだと思います。
> これは -76 の影響???
1974年当時の Smalltalk-72 向けのブートストラップ用ソースを元にしたこのファイル
http://ftp.squeak.org/goodies/Smalltalk-72/ALLDEFS
の for の定義のコメントには「An Algol-like “for”.」とあります。-76 もこの流れで、CLU も
ALGOLライクな for を意識して拡張した構文を考えたら似たものになった、というだけだと思います。
ちなみに 1974年当時のこの -72 のソース内には先に -76 で示した
for x from stream …のようなイディオムはまだ登場していなかったようですが、
ただ stream 自体はすでにあり、外部イテレーターとして積極的に用いられていたようです。
> この for は Smalltalk-76 の予約語に見えますが、(特殊な)メッセージだったのでしょうか?
この for …は、-76 では省略されたレシーバー(コンパイラ)に対する for% x from: stream do% ...
というメッセージの送信として解釈されます(-72 のはまた別の機構。為念)。ただ内部的には for%from:do%
というメソッドがそのままコールされるわけではなく、いったん特殊形式として認識され、字句解析の後に
対応する forfromdo:args: というメソッドがコールされるしくみのようなので、通常の言語における
「予約語」の性格は強いかもしれません。
> また Smalltalk-80 だと do メッセージへ変更されていますけど、何か理由があったのでしょうか?
やはりブロック(当初はコンテキスト、後にクロージャー)の導入が契機だったと思います。
-76 ではコードブロックを [ ] で括りブロックのように見えますが、これは Ruby のブロック同様、
第一級オブジェクトではありませんでした。
> そして -76 の stream も next メッセージが実装された(外部イテレータとして)の
> オブジェクトだったのでしょうか?
そうです。繰り返しになりますが、外部イテレータとしての stream は -72 からあったので。
for%form:do% のようなイデオム(通常の言語では新しい構文のようなものでしょうか)が登場し、
内部イテレータとしても使うようになったのは、-72 の拡張版の -74 か、-76 からだと思います。
822デフォルトの名無しさん
2014/12/10(水) 21:59:38.00ID:veDvxwge >>821
レスありはとうございました
たいへん面白い知見と考察でした
> CLU も ALGOLライクな for を意識して拡張した構文を考えたら似たものになった
わかりました、そう考えるのが自然ですね
> 通常の言語における「予約語」の性格は強いかもしれません。
内部ではメッセージングで実行している一方で、ALGOL 風の使いやすい for 構文に見せる....
いわゆる構文糖だと思いますが、この言語設計は Ruby と似ていますね(>>809)
> やはりブロック(当初はコンテキスト、後にクロージャー)の導入が契機だったと思います。
ブロックの導入によって、メッセージングによる計算モデル単純化の究極が Smalltalk-80 になった訳ですね
これは(Smalltalk-80 に影響を受けながらも)あえて ALGOL 風の複雑な構文の導入に向かった Ruby とは異なる道筋です
> そうです。繰り返しになりますが、外部イテレータとしての stream は -72 からあったので。
了解です
そういえば、ストリームをI/O処理だけでなくモジュールを組立てる基本要素とした手続き型言語がありました
・ストリームを扱う言語Stellaによる在庫管理システムの記述
http://ci.nii.ac.jp/naid/110002761803
レスありはとうございました
たいへん面白い知見と考察でした
> CLU も ALGOLライクな for を意識して拡張した構文を考えたら似たものになった
わかりました、そう考えるのが自然ですね
> 通常の言語における「予約語」の性格は強いかもしれません。
内部ではメッセージングで実行している一方で、ALGOL 風の使いやすい for 構文に見せる....
いわゆる構文糖だと思いますが、この言語設計は Ruby と似ていますね(>>809)
> やはりブロック(当初はコンテキスト、後にクロージャー)の導入が契機だったと思います。
ブロックの導入によって、メッセージングによる計算モデル単純化の究極が Smalltalk-80 になった訳ですね
これは(Smalltalk-80 に影響を受けながらも)あえて ALGOL 風の複雑な構文の導入に向かった Ruby とは異なる道筋です
> そうです。繰り返しになりますが、外部イテレータとしての stream は -72 からあったので。
了解です
そういえば、ストリームをI/O処理だけでなくモジュールを組立てる基本要素とした手続き型言語がありました
・ストリームを扱う言語Stellaによる在庫管理システムの記述
http://ci.nii.ac.jp/naid/110002761803
823デフォルトの名無しさん
2014/12/11(木) 11:19:57.50ID:QX1K4VF2 >>822
Stella の SECONDL の例を Squeak/Pharo Smalltalk のストリームを使って書いてみました。
参考まで。
| SECONDL IN OUT |
SECONDL := [:INPUT :OUTPUT |
| FIRSTL S1 S2 S3 |
FIRSTL := [:INS :MAX :OTHERS |
| I LASTMAX |
(LASTMAX := INS next) ifNil: [self error: 'empty stream'].
[INS atEnd] whileFalse: [
(I := INS next) > LASTMAX ifTrue: [I := LASTMAX flag: (LASTMAX := I)].
OTHERS nextPut: I].
MAX nextPut: LASTMAX].
S1 := INPUT.
S2 := ReadWriteStream on: IntegerArray new.
S3 := OUTPUT.
FIRSTL value: S1 value: NullStream new value: S2.
FIRSTL value: S2 reset value: S3 value: NullStream new
].
IN := #(54 16 1 58 93 57 84 72 32 25) asIntegerArray readStream.
OUT := ReadWriteStream on: IntegerArray new.
SECONDL value: IN value: OUT.
OUT reset next "=> 84 "
Stella の SECONDL の例を Squeak/Pharo Smalltalk のストリームを使って書いてみました。
参考まで。
| SECONDL IN OUT |
SECONDL := [:INPUT :OUTPUT |
| FIRSTL S1 S2 S3 |
FIRSTL := [:INS :MAX :OTHERS |
| I LASTMAX |
(LASTMAX := INS next) ifNil: [self error: 'empty stream'].
[INS atEnd] whileFalse: [
(I := INS next) > LASTMAX ifTrue: [I := LASTMAX flag: (LASTMAX := I)].
OTHERS nextPut: I].
MAX nextPut: LASTMAX].
S1 := INPUT.
S2 := ReadWriteStream on: IntegerArray new.
S3 := OUTPUT.
FIRSTL value: S1 value: NullStream new value: S2.
FIRSTL value: S2 reset value: S3 value: NullStream new
].
IN := #(54 16 1 58 93 57 84 72 32 25) asIntegerArray readStream.
OUT := ReadWriteStream on: IntegerArray new.
SECONDL value: IN value: OUT.
OUT reset next "=> 84 "
824デフォルトの名無しさん
2014/12/11(木) 13:25:53.28ID:QX1K4VF2 >>823
まあ、Squeak/Pharo Smalltalkで普通に書けば、たったこれだけの処理ですけれどもね。^^;
| strm topTwo |
strm := #(54 16 1 58 93 57 84 72 32 25) readStream.
topTwo := (strm next: 2) asSortedCollection.
strm do: [:x | topTwo add: x; removeFirst].
topTwo first "=> 84 "
まあ、Squeak/Pharo Smalltalkで普通に書けば、たったこれだけの処理ですけれどもね。^^;
| strm topTwo |
strm := #(54 16 1 58 93 57 84 72 32 25) readStream.
topTwo := (strm next: 2) asSortedCollection.
strm do: [:x | topTwo add: x; removeFirst].
topTwo first "=> 84 "
2014/12/14(日) 08:35:34.66ID:Im2X3v/S
>>822
> Smalltalk-80 に影響を受けながら
matzが影響を受けたのはTimothy Budd独自仕様
お手製サブセットのLittle Smalltalkで、
ちゃんとしたSmalltalk(たとえば「Smalltalk-80」)ではないよ。
だからstreamみたいな基本クラスもrubyには入ってない。
> Smalltalk-80 に影響を受けながら
matzが影響を受けたのはTimothy Budd独自仕様
お手製サブセットのLittle Smalltalkで、
ちゃんとしたSmalltalk(たとえば「Smalltalk-80」)ではないよ。
だからstreamみたいな基本クラスもrubyには入ってない。
826デフォルトの名無しさん
2016/05/01(日) 15:12:30.55ID:tKi6j9CT 匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?
Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
k
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?
Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
k
827デフォルトの名無しさん
2018/05/23(水) 23:07:44.26ID:Au5e7VGg 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
QZU97
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
QZU97
828デフォルトの名無しさん
2018/07/04(水) 23:01:31.67ID:gFgZc5FG DHB
829デフォルトの名無しさん
2018/07/06(金) 12:36:26.96ID:uTPDH9XV QZU97
830デフォルトの名無しさん
2018/08/23(木) 06:16:30.33ID:NPcuqlt3831デフォルトの名無しさん
2019/06/19(水) 05:02:52.19ID:tVNS+22r 【出資】松本卓朗 人工知能詐欺【注意】
https://rio2016.5ch.net/test/read.cgi/rikei/1560859403/
https://rio2016.5ch.net/test/read.cgi/rikei/1560859403/
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【STARTO ENTERTAINMENT】SUPER EIGHTの横山裕、フジ『ドッキリGP』ロケで全治2ヶ月の重傷 [Ailuropoda melanoleuca★]
- 【食】「シャウエッセンは焼くべからず」暗黙のルールを破り売上高過去最高…日本ハム社員たちが「夜味」にかけた情熱 [ぐれ★]
- 【おこめ券】物価高対策の“おこめ券”全米販は1枚477円で販売へ 鈴木農水大臣「国民の皆様に活用いただきやすいよう工夫いただいた」★2 [ぐれ★]
- 【話題】好きな鍋は?! 「寄せ鍋」「キムチ鍋」「水炊き」「もつ鍋」「豆乳鍋」「ちゃんこ鍋」「ごま坦々鍋」「トマト鍋」 [ひぃぃ★]
- 「もうキモくてキモくて…」29歳女性が語る“おぢアタック”の実態。「俺ならイケるかも」年下女性を狙う勘違い中年男性に共通点が★6 [Hitzeschleier★]
- 高市首相の答弁書に「台湾有事答えない」と明記 存立危機発言当時 ★5 [蚤の市★]
- SBI新生銀行「預金が1兆円集まったら預金金利を4%にします。1超超えたらエントリー締め切るよ?」 [784715804]
- ムミィ🥺いる❓🏡
- 鈴木農水大臣「物価高対策でお米券1枚477円で販売します☺」 [931948549]
- 兎田ぺこら、とんでもない方法でさくらみこの存在を消してしまう──── [268244553]
- Pornhub「米国内で最もシコられたキャラはチュンリー、2B、そして…」 [347751896]
- 人生で初めてキャラメルラテ飲んだ
