やっぱり動的型付け言語では安全なソフトは作れない

OO関連及び動的言語関連で事あるごとに争っている
静的型付け厨と動的型付け厨が、思う存分飽きるまで仲良く
罵り合う為のスレです。

スレの進行を妨げる型安全議論を見かけた場合は、
こちらへの誘導をお願いします。

関連スレ：
やっぱり動的言語では安全なソフトは作れない 4
http://hibari.2ch.net/test/read.cgi/tech/1316016777/

【OOP】オブジェクト指向総合 part3【OOA/OOD】
http://hibari.2ch.net/test/read.cgi/tech/1312982517/

-OOP限定-プログラム設計相談室
http://hibari.2ch.net/test/read.cgi/tech/1127547359/

オブジェクト設計＆デザパタ
http://hibari.2ch.net/test/read.cgi/tech/1272806908/

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

> 348 名前：デフォルトの名無しさん []： 2011/09/24(土) 17:55:27.86
> もう何度も言われてる事だろうが、静的な型付けの言語ならする必要のないテストまで動的型付けの言語はする必要がある。
>
> 359 名前：デフォルトの名無しさん [sage]： 2011/09/24(土) 23:40:41.13
> >>348
> もう何度も言われてる事だろうが、こういうことを書いて具体例を挙げられたやつを見た事が無い。
> おそらく今回も逃げるだろう。
>
> 360 名前：デフォルトの名無しさん [sage]： 2011/09/25(日) 00:44:06.19
> >>359
> 返り値の内部表現型をチェックするテストでも日々書かされまくってんじゃない

型チェックがあろうがそもそもテストしてない機能は動作保証外なんだから変わらん

> 363 名前：デフォルトの名無しさん [sage]： 2011/09/25(日) 03:38:44.11
> >>359
> Alexに言われるまでもない。
>
> http://www.artima.com/scalazine/articles/twitter_on_scala.html
>
> Alex Payne: I’d definitely want to hammer home what Steve said about typing.
> As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models.
> I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly.
> You’re checking for null values all over the place.
> There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.”
> It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.

366 名前：デフォルトの名無しさん [sage]： 2011/09/25(日) 03:50:13.66
Steve曰く、Rubyはreliableじゃない。

Steve Jenson: Another thing we really like about Scala is static typing that’s not painful.
Sometimes it would be really nice in Ruby to say things like, here’s an optional type annotation.
This is the type we really expect to see here.
And we find that really useful in Scala, to be able to specify the type information.

あったま悪そうなやつがスレたてたなぁ


こういうのを重複スレっていうんだよ　削除対象か、まぁ次スレにでも使えばいいか

アナタのような基○外のためのスレですよ

ケアレスミスだけど、影響が大きいバグを、
１．コンパイル時、あるいは気の利いたＩＤＥならソース入力時にエディタがその場で問題の箇所を漏れなく検出する
のと、
２．単体テスト等の結果が不正であることから、原因を自分で調査、場所を特定、変数の型付けが原因と自分で突き止める
のと、どっちが良いか？って話だな。

今時のIDEなら動的型言語でもスペルミスを見付けてくれるだろ。

>>10
それは不可能だよ。
定義がなければ、間違っていることはわからない。

変数宣言の有無 ≠ 型宣言の有無

スペルミス程度ならあるいは可能かもしれないけど、実行前に型の誤りを見つけるのは無理だろ＞動的

メソッドを呼び出した時の戻り値がちゃんと仕様を満たしているか把握すんのは動的型付けじゃ難しい

カバレッジ90%超えるならテストで見つかる　v.s.　カバレッジ60%超えるぐらいなのが現実

静的型付け厨が嫌うのはテスト範囲外の動作が不安で不安で仕方ないからなんだろ

じゃ問題になるのはテスト範囲外の動作で停止したらどうするのが正しいのか。

>>14
それ、現段階じゃ静的型でもほぼ不可能だし。

>>14
静的型ったって、返り値の型ぐらいしか保障されない。
整数が返り値だとして、それが期待されている「範囲内の」整数かどうかなんて
静的型はこれっぽっちも保障してくれない。

くやしかったらゼロ除算が絶対に発生しない言語でもつくってみろ。

要するに戻り値型のインターフェース仕様が無いから分かりづらいという所か

process.method(source)

ここでmethodがsource.example()を呼び出したとして、
methodが戻り値にどのメソッドを持ったオブジェクトを
返すのを期待しているかまでは、methodの実装を覗くまで
把握しづらい。
上手く回避するためには、sourceの仕様とsource.methodの仕様
それからsource.methodの戻り値オブジェクトの仕様まで文書かする必要がある。
静的言語でも親クラスで定義してあるから同様だけど。

で、テストで返り値をチェックするコードを書くと、
そのまま型のテストも兼ねることになるんだよね

ダックタイピングは別に動的型付けのメリットでは無いよな。
GoのインターフェースやG++のsignatureの様な形で静的型づけでも実現されてるし。

>>18
お前はなにを言ってるの？

>>18
静的型付けであれば、自分がオーバーライドしたメソッドが、
どんな仕様を満たさなければならないか、把握してる。

静的型付けであれば、自分が使用するオブジェクトが、
どの仕様に沿って作られたかは把握している。

コーディングミスで仕様が保証されないとかいう問題じゃなく、
どの仕様に基づいているか、定義側、使用側で合意が取れており、
合意外の記述がしづらい事が重要。

ようは、（コメントやドキュメントじゃなくて）コードの中に
アプリケーションの仕様を記述できる量が多いってことなんだよな。
静的言語っていうのは。

ばかじゃねーの
んなもん静的型付け/動的型付けなんて関係ないだろ
動的型付けだと仕様をコードに記述出来ない理由があるのか？

コードとドキュメントの両方を同期させてメンテナンスするのは
同じ事を二度書くということで、KISSの考えに反するんだよね。

>>25
よく読んでね。

出来る出来ないなんて一言も言ってない。
静的言語のほうが、”多い”って言ってるの。

それ以前に合意外のコードを簡単に書ける。

動的言語でも「変数は宣言してから使いましょう」って考えは同じだろう。

宣言はめんどくさない。宣言しないで使えたほうが記述量は減る。
どうせテストをするのだから、宣言は不要。

本当なら、動的言語擁護派ならこのように言うはず。

だけど、なぜか動的言語擁護派も変数は宣言してから使いましょうという。不思議！ｗ





まあ、結局、これと同じなんだよ。宣言してから使ったほうが間違いが減る。
それは変数に限るわけがなく、型とかインターフェースとか、
変数の宣言と同じ理由で、宣言してから使ったほうが間違いが減るんだよ。

宣言はめんどくさい

>>29
その宣言ってただのスコープ指定だろ

>>29
Python,Rubyには無いし、言語に依るんじゃないか？

何故、変数の型宣言みたいなレベルの低い話になるのだろう。

せめてオープンクラスは柔軟な変更が可能になるけど
影響範囲がグローバルになるからClassbox的な機構が必要
みたいな議論にならんものか。

Classboxって何？

クラスにパッチ当てて修正/拡張するときに、それが効く範囲を限定できる。
一種の名前空間。

実行時メタプログラミングは動的言語スレの方のねたじゃないか？
ここは型安全ネタのすれだからな

ああそうか。スレ違いだった。

>>23
> 静的型付けであれば、自分がオーバーライドしたメソッドが、
> どんな仕様を満たさなければならないか、把握してる。

バーカ、それは事前条件、事後条件、不変条件の証明をやってから言え。
型がわかるだけで「どんな仕様を満たさなければならないか、把握してる(ｷﾘﾘｯ!」とか、笑えるw

> 静的型付けであれば、自分が使用するオブジェクトが、
> どの仕様に沿って作られたかは把握している。

バーカ、それは各属性の不変条件の証明をやってから言え。
型がわかるだけで「どんな仕様を満たさなければならないか、把握してる(ｷﾘﾘｯ!」とか、笑えるw

> コーディングミスで仕様が保証されないとかいう問題じゃなく、
> どの仕様に基づいているか、定義側、使用側で合意が取れており、
> 合意外の記述がしづらい事が重要。

型がわかる程度じゃ意味ねえよ！
静的厨の言う安全性/健全性って、この程度の浅いものなの？バカなの？

別に100%のチェックをコンパイル時に求めてる訳じゃない。
100やらなきゃならないチェックのうち70%のチェックを自動化してくれるならそれで十分。

HaskellとHoareぐらいかじってから言えよ、ってJava厨の言動に思うことは多い。

Adaなんかは、全然使った事ないし知らんけど
比較的安全さと厳格さを重視して設計されてるんでしょ

http://en.wikipedia.org/wiki/Ada_(programming_language)
ここ見るといわゆるintみたいな型が無いのか、range 1..31とかmod 24とかいう形で
いちいち独自に型指定してて面白いよ、コンパイル時か実行時か知らんけど常に
境界チェックやってるんだろうな

型検査だけで70%もカバーできるわけねえだろw
静的型厨ってどこまで楽観的なんだか…

>>41
コンパイル時に検査できると思うほど馬鹿なわけ？
実行時の検査なら動的型だってできるぜ？

>>42
いや、動的型言語で組んだら全バグの70%が実行時型エラーになったのかもしれんぞwww
そんな馬鹿なプログラマには会った事無いけどw

開発中のケアミスも含めれば、
静的検査で見つかるものは多い。

>>43
そりゃ全部コンパイル時にチェックするのは無理だろうよ
ただ、関数fの引数型Numberがrange 1..12と定義されていれば、
とにかく実行時だろうがその範囲外の入力は弾かれるし、
f(13)みたいな呼び出しはコンパイル時にエラーにすることが可能なわけだべ？

それって動的型で自前でチェックするよりはなんぼか楽だし意図も明確じゃね？
関数fが取る引数がどのようなものであるか、動的型言語では意図を示す
方法がないよね？

別に静的型の型チェックでプログラミングエラーを全て無くせるなんて話は誰も
してないと思うけど

範囲付き数値型を作って使ったらどうなるんだろうな。
なんか不都合がでるんだろうか

Int<0,5> value = 5; //コンパイルエラー
Int<0,5> value = ConstInt<5>(); //代入可
Int<0,5> value = Int<2,4>( ConstInt<3>() ); //代入可
Int<0,5> value = Int<-1,4>( ConstInt<3>() ); //コンパイルエラー

int n = map["key"].readInt();
Int<0,5> value = n; //範囲外であれば実行時エラー

Int<0,3> a;
Int<0,4> b;
Int<0,5> value = a + b;//コンパイルエラー

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = a + b;//代入可

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 + 0, 2 + 2>(a + b);

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 * 0, 2 * 2>(a * b);

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 / 0, 2 / 2>(a / b);

Int<0,2> a;
Int<0,2> b;
Int<0,5> value = Int<0 % 0, 2 % 2>(a % b);

割り算はマズそうだが、そもそも0割状態になることが問題か

0に関しては-n〜nを表現しなきゃならないから
0状態だけはコンパイルエラーとなるNZInt型でも作らなきゃならんだろ

>>38 は不変条件だのなんだの書いてるが、そんなもの範囲付き型検査で済むから
本当に言いたいのは、そういう話じゃないんだろうな。sin関数が正弦を返してないとか
そんな話なんだろ。でもそれは型チェック云々の範疇じゃなくていいと思うが。

範囲付き型検査で済むというなら、実行時エラーが一切出ないように頼む

IO以外は、範囲外エラーが無くなるだけましだろ。
IOだけ妥協すんのはモナドと似たようなもんだ。

このスレの静的厨は普段はどんな言語使ってるの？Agda？Coq？
Javaとか言うなよ？

>>53
静的言語でも動的言語でも何でも使うよ。
でないと動的言語よりも静的言語のほうが
すぐれてるってわからないだろ。

で、それ聞いてどうするつもり？
Javaと答えたら、ぷぎゃーとかいって逃げる予定だったの？ｗ

>>53
俺はJavaかな

さて、どうでるかｗ

>>53
俺はJava

Java一択

Java大人気だなwww

C++,C#,Delphi

Javaに範囲付き型検査ってあったっけ？
NullPointerExceptionならあるけど。
あと配列使うと簡単に型安全じゃなく出来るとかアホとしか思えんが。

C++を母言語としてても、仕事じゃJavascriptとか使わされる事が多い。
んで実行してから何処ともなく現れる構文エラーにうんざりする。
まぁ型の問題じゃなくインタプリタ全般の問題だけど。

> 配列使うと簡単に型安全じゃなく出来るとか
ほう、具体的どういうことなのか
君が知っていることのすべてを教えてくれ。

これがコンパイルエラーにならない

Object[] x = new Integer[1];
x[0] = new String();

なんだ、馬鹿のくせに型安全って言葉を使ってみたかっただけかｗ

Object[] x = new Integer[1];
x[0] = new String();
x[0].charAt(0); //コンパイルエラー

ここでエラーが発生するから十分型安全なわけだけど

まあ、「静的な」型安全性って言わないとダメだったね。
でも、これで実行時にArrayStoreExceptionが出ても型安全だと主張するなら、
動的型言語も完全に型安全だわwww

>>66
ぬるぽに比べたら些細な問題だな

何度も言ってるけど、量の問題であって、
静的言語のほうが、見つけられることが多いのなら
抜けがあったとしても、優れているんだよ。

>>54
> 静的言語でも動的言語でも何でも使うよ。
> でないと動的言語よりも静的言語のほうが
> すぐれてるってわからないだろ。

どんな動的型言語を使ってるの？

Java固有の話しなんざどうでもいいわ

Javaはinterfaceで表現できるからって
constを導入しなかったのが失敗だったな。
const配列の場合のみ配列間のアップキャスト可能というなら
ArrayStoreExceptionは発生しなかった。

>>8
で、キチガイこんなにいんの？ｗｗｗｗｗｗｗｗ

重複スレまでこのスレ勢いってどんだけだよ


>>27
え・・・・・・なにこの初心者

初心者っていうか、何？
専門学校入って、半年目なんだけど、学校サボっちゃっててぜんぜん知識身についてないような
そんな感じの奴か

>>69
はっきり言って、誤差の範囲内。
むしろ、型エラーを取っただけでバグがなくなったと安心するバカがいる分、
静的型のほうが危険とも言える。

>>54
動的言語ったって、どうせルビーとかピーエッチピーとかでしょ？
パール？えらいでちゅねーww

>>54
「バカは効率がわからない」

>>74
型まわりは、メモリ状態によっては正常に動いてしまったりして
というか正常に動いてしまうケースの方が多かったりで、
見つけるのに結構手間どる場合があるから、コーディング時に
多少キーボードを叩く回数が増えてても、リリース後の深夜に
電話で呼び出されたり、リリース直前に謎バグで徹夜したりする確率を
下げたい人は、静的型付け、その逆に、修羅場になると寧ろ燃えて
生き生きするタイプは、動的型付けを使うと良いんじゃないかな。

> メモリ状態によっては正常に動いてしまったりして

C/C++かよw
笑わせんなバカwww

>>77
動的型言語は型安全だバカ

大体動的言語は仕事無いだろ
>>75
が言うような動的言語は仕事有るが
でも動的厨からみたら話にならないんよね！！！！ね？>>75

uyくん、君に土方（笑）とかいう意見は求めてないからね！
キリッ！！！とかいうのも結構です

>>80
いやいや、そういうのもいいから、早く使った事のある動的型言語を書いてよ。
使った事なきゃ比較できないって>>54も言ってるしね。
使った事あるんでしょ？

ま、どうせ100%逃げるだろうけどw

Rubyistですすいませんでした

わろた

>>82
Rubyでは安全なソフトは作れないと思ってるってこと？

Perlerだがそう思う

たとえばPerlだとさ、
obj->foo()とか書いても、その行を実行するまでは
foo()が定義されているかどうかチェックされないでしょ。
動的言語ってのは大抵同じだと思う。

ここでさ、これって変数の定義の話と同じだと思う人いないの？

Perlとか変数を定義しなくても使える言語あるけど、
警告オプションとか設定して、変数の定義を強制するでしょ？

それは、定義があれば、スペルミスしても分かるようにするため。
そのメリットに変数も関数も違いはないと思うんだけど。

>>86
OOPはメソッドがどこで定義されたかを隠す。
せっかく隠したのに定義はどこですかとチェックするわけがない。

C/C++だと定義と宣言があって、定義をチェックできなくても宣言をチェックできる。

> OOPはメソッドがどこで定義されたかを隠す。

それは一体どの文献に、そういうものだって書いてあるんだい？

それとも、今考えたのかい？

Perlは基本的に変数を定義して書くものだよ。そうでないように設定も出来るけど、商用レベルでそうする事はほぼ100%ない。
配列、連想配列、その他の3つしかないけど、一応型も定義出来る。
RubyやPythonよりはマシ。
Perl6になると、完全に静的型付けで書けるし。

>>88
>>87ではないけど
ダックタイピングや、遅延バインディングによるポリモーフィズムをOOつってるんなら
自動的にそうなるんじゃね
実体を（vtblなどを使って）実行時に検索するから遅延バインディングなのであって
どの実体が呼ばれるかは静的には分かるわけがないし、確定しているのなら
それはポリモーフィズムじゃない
ただし、静的型のOOPLの場合は、とにかく実体がちゃんとあることだけは保障される

ってことだよな

>>90
ぬるぽを除く

いやこれを遅延バインディングっつーのはなんか言葉がおかしかったな
まあいいかー

>>90
そのことを、
「OOPはメソッドがどこで定義されたかを隠す」と
表現している文献はあるのかと。

だいたい、いくつか候補を見つけることが出来る時点で
隠してはいないから。

>>90
Smalltalkだと簡単に解るけど？
君の言う動的OOって、perlのことなのか？

>>94
静的に分かってるわけじゃあるめぇ

>>93
遅延バインディングでロードするDLLを実行時に決定するなら
コンパイル時に全ての候補を見つける事はできない

>>82-85
動的厨涙目

Java厨必死だな

>>93
いや、型の隠蔽、実装の隠蔽、あるいはインタフェースと実装の分離と表現されるけど
普通に
GOFだってそう

>>94
実行時に実際のオブジェクトなり型なりが分からないんなら、そもそも
メソッド呼べんでしょ……
実行時には当然確定するし、分かる
静的には確定していないからポリモーフィズムなのであって

>>54
こいつみたいに、

どう見ても、是と思っていることを否とするバカっているんですよ

科学者や数学者や評論家みたいな奴が、意外性みたいなもんを狙った文章の･･･　だったら、１行目に「え？」っと思わせといても
最後まで読むと「なるほどなー」ってなる場合があるから、許せるんだけど
そうじゃない。本気で思ってる、山も谷もないオチのない文章

なんていうか･･････アレなんだよ、100%論破できる、100%これは正しい、ってわかってるんだけど、
匿名だから、こんなゴミみたいな奴を論破して矯正してもあまり意味ないから、

いちいち相手すんの疲れるよね


あまりにもバカなこといわれると、あまりにバカすぎてふらつくわ
最近じゃ小学生でもこの板出入りしているんだろうしなぁ・・・　2chはもう議論の場として終わり

>>100
jkかuyかしらんが
＞いちいち相手すんの疲れるよね
だったら、一言でいいんじゃない？１分か２分それ以上かけてコメントする
ほどでもなかろう

>>96
そういうことじゃないよ。

定義を隠すというのは、どんなものが定義されているか
実行時にならないとわからないってことだよ。

遅延バインディングとか、ポリモーフィズムとか、
それは実装がわからないだけで、定義されていることは分かるだろ。

おいおい、宣言と定義の違いすら分かってないのかよ

>>102
何を言ってるのかぐちゃぐちゃすぎて俺にはさっぱりだぜ
まあ言いたいことはなんとなく分かるけど

void parse(ILexer lexer) {...}
のような関数があるとして、この関数を書いたりコンパイルする際には
実際に渡ってくるオブジェクト（インタフェースILexerを実装した実体）が
何であるか知る必要がないし、存在する必要すら無いってことだろ

そういう意味では確かに実体の定義は隠蔽はされているんだが、
「定義を隠す」っていう言葉遣いはあんまり聞いたことが無いな
普通は「実装を隠す」という言い方をすることが多い
abstraction（抽象化）はプログラミングの鍵なので、本質的には
OOPに限った話ではない

全然流れを読んでないが例えば下のコードだと、
実装は不定と言う方が自然じゃなかろうか。

windows.Control( phisical_machine );
windows.Control( virtual_machine );

unix.Control( phisical_machine );
unix.Control( virtual_machine );

おいおい、定義を隠すと言い出したのは俺じゃなくて >>87だぜ。

>>87
> OOPはメソッドがどこで定義されたかを隠す。

変数は宣言しないで使うことは悪いというのに、
なんでメソッドは宣言しないで使おうとするの？

その違いがわからない。

変数はスコープの問題だろ。
定数や関数は、無限ループや、意図しない分岐ミスを誘発しないが
変数はそれを起こす。

>>107
静的型でのインタフェース、継承ベースのポリモーフィズムの場合は
実体がわからなくとも特定のインタフェースを備えていることは
保障されるので困らない、という考え

def add(x, y) = x + y
みたいなものを考えるとき、動的型でもx, yは暗黙に加算ができる
オブジェクトとプログラマは仮定しているが、それを保障する方法は無い
実際に+が定義されないオブジェクトをaddに渡すと、その時点で実行時エラー
この場合は単純だが、もっと複雑な内容の関数の場合は
もっとワケのわからないところで実行時エラーが起きたり、あるいは
エラーにすらならず黙って誤った結果が生じる可能がある
それが嫌なら引数チェックを自分の手で書かないといけない

継承ベースのポリモーフィズム静的型だと
IAddable add(IAddable x, IAddable y) = x + y
みたいな発想をする
xやyは整数かも知らんし浮動小数点数かもしれないがそれは問わない
とにかくIAddableというインタフェースを実装したオブジェクトであって、
加算が定義されていることは保障される
ただし、加算の「意味」が関数add()が期待しているものと同じであるかを
保障する手段はない

>>109
そのadd()は俺なら number(x) + number(y) みたいに書くかな（number()は引数を数値に変換する関数ね）

で？っていう

>>107
定義すれば宣言はしなくて良いよ
メソッドは「どこか遠くで定義されているからここでは定義しない」ってケースが多い
変数は「地産地消」

だねー

メソッドはインタフェースだけど、変数はローカルなもの

>>101
ゴミは
潰さないと、さ。

お前たちゴミも訂正しやすい書き込みだけ訂正するんじゃなくてちゃんと仕事しろよ
ゴミがゴミ管理すんのは当たり前だろ？

ゴミの勘違いを放置すんなゴミ　　放置するから、そのまま冗長して、すっげーとんでもない場所で、バカみたいなことしゃべっちゃうゴミになっちゃうんだよ････

>>109
＞動的型でもx, yは暗黙に加算ができる
＞オブジェクトとプログラマは仮定しているが
プログラマによるだろう。
JavaScriptの例だと、typeofする関数群使って、
各オブジェクトのプロパティをeveryで回したり、
数値計算では文字列は parseInt とかに通したり、
evalしたいならsandboxつくる。

これぐらいの発想は当たり前だよ。
想像で語ってる人が思いの外多いような気がする。

＞想像で語ってる人が思いの外多いような気がする。

それ、いまさらって感じ

このスレかなり素人混ざりこんでるよ
このム板の平均レベルそのものも低いが、その中でもさらに下の下の下種がきてる
正確には下の中くらいだけど

静的なら機械がチェックするところを、
動的だとプログラマ側のそういった工夫が必要なのか。

機械がやるから手間も要らないし、抜けも無いわけだ

そりゃ動的型言語は静的型検査の代りに
実行時に型システムを拡張できる自由を得たわけで、
静的型言語と同じように書いてたらデメリットしか無いだろ

昔、OOPがまだ受け入れられてなかった頃、
C上がりのプログラマがCと同じようなコードを書いて、
OOPは遅いだけでメリットが無いと言ってたが
言語/パラダイムが変わっただけで全く同じ構図だな

機械ならどれでもよかった。反省はしていない。

>>116
お前何様だ？
LLで組んでるならそれぐらいの動作を考える、と言っただけで、
プログラマとして下だ上だなんて主張はしていない。

>>118
それを言ったら極論として型安全性の高い言語が優秀になってしまうのでは…。
でも人間の言うバグがなくなるわけじゃない。

ちゃんと動くのにコンパイラが型エラーで弾いたりするけどな。
くやしかったらYコンビネータに型をつけてみろw

http://r6.ca/blog/20060919T084800Z.html

>>121
話しかけんなよ気持ち悪い

>>121
型安全性の高い言語の弱点「記述が冗長」をＩＤＥで補う、これ最強。
人間はただでさえ間違いを犯しやすいんだから、機械でチェックできるところは
機械にやらせるのがよし。

壁に向かってしゃべってろゴミｗｗｗ

>>125
逆だよ
型検査は人間に型宣言をさせずに、型推論ベースでやればいい

Rubyは今からでも静的言語に変更した方がいい。
このままではクリティカルなビジネスに使えないので
普及しない。

第2のHaskellも第3のJava（第2はC#）もいらんわ。

>>125
最近の流れだと、型安全性というと型推論を言うんじゃないかと。
C++ですら型推論の時代だし、記述量はむしろ少なくなる。

言語を変更したら人間が対応に追われるし
もし機械的に翻訳できる事を保証したらむしろ安心して古い言語を使い続ける。

言語の論争は、機械は翻訳ができないっていう無力感を前提としているから
機械の力に特別な期待を持つのは不自然だと思う。

自然言語の話と形式言語の話を混同するおとこのひとって

混同したら一敗
区別すれば一勝一敗かもしれないけど二敗かもしれない

>>131
実現する処理とその表現を混同してるねえ。
実現するだけなら機械語でも万能。
問題は表現だ。

>>131
> 機械の力に特別な期待を持つのは不自然だと思う。
単に「機械でも出来る程度のことは機械にやらせろ」ということであって
「特別な期待」うんぬんじゃないよ
人間様が一々機械語なんて記述してられないから、プログラミング言語という
形式言語を発明して、機械語への翻訳は機械にやらせることにしたわけです

>>130
簡潔に記述出来るようになる一方で、盛り込みたい概念が順番待ちしてるから、ある程度の複雑さで妥協すると思う。

>>135
どの程度なら機械でも出来るか
もし自分が機械だったらここまでは出来るって想像できる人が機械を作る
自分は機械とは違うって感覚だと、自分に出来ないことを機械に期待してしまう

安全とかいうのはランタイムエラー撲滅してからにしろって

ここで不思議なことって？lisperとhaskellerはさほど不仲ではないよ。
このスレの中では不仲みたい。
２つの言語の共通するところってプログラムを組む前の戦略を立てるときに
大変頭を使う事かな。lispは思考直結型ではあるけどhaskellは型直結から
思考をする感じ。（最初のデータ型を決めるのが大変重要だしな。そこさえ
綺麗に決まってくれば後はそんなに時間はかからんでしょ？）型推論が
あるために柔軟な言語に仕上がってると思うよ。

他の共通点は少人数で開発をしていく向けの言語かな。lispの場合型チェック
は任意だけど、ここは絶対型チェックをしたいというところならassertを組み
込むよね。これはcommon lispでもclojureでも共通してるかな。

JavaとかってIDEに代わりをやらせればいいというような意見が出る
くらいだし頭を使う必要はないわな。そうゆう意味では対極だし、
javaを使ってる人の愚痴が多いのもわからないでもないな。java依存症で
javaに愚痴が多い人はbetter javaとしてscalaを使ってるのかな？

rubyも柔軟な言語だから、考えてることを実現しやすいだけの
言語のパワーってのを持ってると思うよ。必要以上に複雑で扱いにくい
言語ってのはその制約に引っ張られて思考をそのまま実現しようとすると
問題を抱えやすいな。無駄に書かなけれいけない処理が増えればふえるほど
柔軟性は失われるから、言語の制約に縛られたくない人にとって見れば
不向きなのが多いな。

ここの人って、二分論で語るような人が多いし、会話が成り立たない場所
だけど、現実は使い分けでいいんだと思うよ。どんなことをするかってこと
でずいぶん違うだろうからな。前提を抜きにしてあれがだめだこれがだめだ
って論争って間抜けなんだと思う。

>>139
みんなわかってて暇潰ししてるだけなんですが…

極論同士のぶつかり合いじゃないと盛り上がらないだろ
別に満場一致の結論なんて求めてねえんだよハゲ

>>140
極論でしか盛り上がらないという発想そのものが底辺だと言われる所以
だと思う。気の毒ですが。

>>141
せっかくの長文が相手されなかったからって泣くことないだろw

>>142
やっぱりなんか感覚がずれてるね。おまいらの暇つぶしに付き合う気がないんでこれ以上はコメントしない。

どうでもいい長文を垂れ流す馬鹿をひとり駆逐したぞ＾＾

ひとを間抜けと呼んだ時点でてめぇも二元論だろ。

>>139
> ２つの言語の共通するところってプログラムを組む前の戦略を立てるときに
> 大変頭を使う事かな。

それは言語の問題じゃない。プログラマの問題だ。
LispだろうがHaskellだろうがドカタ産業の標準になったら、クソの山になる。

つーか、土方かどうかって
言語じゃなくて作るシステムで決まるもんだろ。

土方呼ばわりしている奴って、Rubyを使って
同じようなマスタメンテ画面が何十個もあるシステムを
作っています自信を持って言える？

言語で土方かどうかが決まると思っている奴なら
Rubyだから土方ではない！と言うはずだ。

>>147
言いたいことはわかるけど、もう少し日本語の練習をしてからまたおいで

>>148
言いたいことがわかっていて、
そのことに反論してないのなら、
それで十分だ。目的は達成した。

>>149
書き込みの内容自体はどーでもいいー

じゃあ、それはただの揚げ足取りってことだなｗ

当然、土方仕事かどうかは作るシステムで決まる。

だが、土方仕事しか経験の無いプログラマは
冗長なコピペコードをIDEで生成するのが最上の手法だと認識してる。
そういうプログラマが "IT土方" と呼ばれているだけの話。

スクリプト言語で仕事って言うと、ほぼウェブ系だよな。つまり、スクリプト言語はドカタ用言語と言って過言ではない。

>>147
JAVAは土方だよ　高確率で。

あの言語みてそう思わないならセンスが狂ってる
C++は土方ではない。　扱うのが難しいし、出来る奴が少ない。　Ｃ＋＋ＰＧ。　それは「技術屋」という

言語仕様はさておいて。
C++が出来ること。　C++で作られたプログラムのメンテが出来る事。
まさに技術を売っている感じ。

はっきりいって人の平均的スペックではC++扱えないから、JAVAやC#が生まれたってだけで、
使える奴で集まればC++でいいんだよ？

ゴミしかいねーからJAVAになる。。。　人の頭脳は、年々、子々孫々進化していて、
次の世代次の世代で、どんどん今の世代よりは頭が良い。　いずれC++復権すると思うよ
ＪＡＶＡ？Ｃ＃？　いらねーんだよｗ
人の進化の速度にも、よるけどな

>>151
短絡的だなあ…。

端的に言うとその言語が用いられる対象システムから、
開発手法を想定し、土方と呼んでいるに過ぎない。

必ずしも当てはまらないのは自明の事だし、
いちいち主張することでもない。

とりあえず、さっさと言語統一はかったほうが、いいんだけど

世界はまとまんねーのなぁ

この世に１つしか言語がなければ、多分、効率は１００倍を超えると思うよ
剣道やったことあるか？　片手で振るのと、両手で振るのとでは、威力の差が
　２　倍　で　は　な　い　　　１＋１って計算にはなっていないから、それ以上になる。
　

いみふ

>>139
このスレは、なんちゃってxxxerの隔離スレ。

haskellerはlisperなんて相手にしてないし

>>139
うーん。。。
当たってるような、当たってないような。。。
自分の感覚だと、javaやrubyはリファレンス本(またはリファレンスサイト)をちょくちょく参照しないと書けない感じで、haskellは割とリファレンス参照しなくても、自分で何時の間にか組込関数と同じモノ自作してました。みたいな、リファレンスの使用頻度が低い感じを受ける

まだ勉強中だけど、練習問題解いたりする際のリファレンスのお世話になる頻度が違う気がする

印象としては記憶力勝負のjava
発想力勝負のhaskell？

B★RS

to turn this way Baby

>>161
単に、単純な代物しか作っていないからでは> haskell

>>163
おれもそう思う
覚えたての言語に対しては大抵「この言語は発想力がモノを言うなあ」と思うものだ

>>157
てめえ剣道やったことあんのか？
両手で二倍にならねえよ、それ以下だ

>>163-164
そうかもだけど、その単純なプログラムでも、オブジェクト指向はまず「こう言う事したいけど、そう言うクラスやメソッドは無いか？」って探す所から始まる事が多い気がする

関数型でも手続き型でも、そういう関数や手続きはないか、って探すけど

>>166
関数型は部品の再利用には向いてないってこと？

>>167
簡単なのだと探すより作っちゃった方が速いけど。。。

>>168
そうじゃなくて、まだ覚えたりなんとなくでも知ってる関数が少なくても自分で作れちゃうから困る事が少ない

あと、ぶっちゃけオブジェクト指向のデザパタとか全然で、オブジェクト指向言語使ってた時はあんまり再利用出来なかったけど、関数型言語では、そんな自分でも結構コードの再利用出来てる

底辺でも再利用出来るのが関数型言語の良い所？

むしろ純粋関数型以外に、例えば「このサブルーチンを呼んでも、例外とかでない限り
標準出力に何か書き出したりしない」を保証できるような、安心して再利用できるような
言語ってないと思うんだが。

ま、その保証のおかげでprintfデバッグがやり難いんですがね
（実は方法はあるけど）

実は保証できてない面があるってことでしょ
一面的な見方では安全にならないので
なにを保証するかだけでなく、なにを保証しないかを言わないと

馬鹿なこの町並みは基底クラスの変数の状態に依存するはずだろ。
日曜大工だと探すより作っちゃった方が速い場合が多いけど。。。

>>166
OOPL脳の俺には、非OOPLのほうがむしろ数が多過ぎて覚えるのも探すのも大変なんだが…

>>174
何の数が多すぎるんだろう。。。
関数？

腹の脂肪…

>>176
必死だなｗｗｗｗ

ハスケルって馬鹿っぽいから嫌いだな
スカラおすすめ

オキャムルおぼえるぞ

>>175
一覧に並ぶ項目の数…かな
だいたいの目星を付けるのが出来ないから「うわっ」ってなる

>>180
何で？モジュールくらいあるだろ

>>181
クラス別のドキュメント場合、来る値の型や欲しい型、使いたい型は既に解ってるのだから
その型について調べればいいのよ

もちろん欲しい型や使いたい型が判らないときは大変だけど
それの労力は別にモジュール分けでも何ら変わりないし

>>182
モジュール別のドキュメントでも同じ話では？

>>183
どれと同じなのかkwsk、俺的には型が不明なまま探すのとは決定的に違うが…

>>184
いや、だって関数型言語でもListやHash、Monad等の単位でモジュールが分かれてるだろ？
何にも整理されずに関数群がモジュールに突っ込まれてると思ってるの？

>>182
型の仕様はわかっても、型の実装は実行時に値がくるまでわからない罠

>>185
Preludeは分かれてないよね

>>186
まあ、その辺まで来ると流石に好みの問題かも知れないな
俺も昔OOPLに初めて触れた頃はドキュメント読めなかった
…が、慣れた今では却って読みやすくなっちゃった

OCamlだと調べものはOcamlBrowserで済む事が多いな。
関数の型から関数名を検索することもできるし。

>>187
ルート、PreludeList、PreludeText、PreludeIOに分かれてる

>>187
ん・・・
Preludeの関数なんて、putStrとかの副作用関係の関数以外(getCharはData.Charモジュールへ移動した）どんなに下手な作り方でも4行で作れるじゃん。
作れなかったときだけ探せばいいだろ。
そもそも何を受け取って、何がほしいのか。から考え直せ。

関数型言語は元々、手続き型言語と違って数学を基にしてるから、1から作るのも再利用するのも向いてるんだよ。
(数学で再利用できないのはかなりキツイと言う文化的背景的にも)

関数型言語はまさしく算数や数学と同じだ。
初心者は算数・中学数学並みの少ない知識でも結果的には同じ意味のコードが掛けるし、知識が付けば、効率的で無駄のないコードが書ける。

ただ読みやすいコードか？ とか速いコードか？と
聞かれると必ずしも関数型言語風の書き方が
最善というわけじゃないんだよな。

元々解くべき問題の複雑さ度合いとか問題領域に応じて、複数のプログラミング言語が在る訳だ。
乱数を10^10(10の10乗)回足しこむような単純な処理なら、現在でもCが最速だろう。
ただし、こんな単純な処理でも10000^10000回とかなった途端に、ライブラリを探すか、自分で車輪を再発明する事になる。
更に問題なのは、ほとんどのアプリケーション・プログラマーが使う範囲では、複数の言語間のスピード比較は、単純な処理でしか出来ない事。
鳥とライオンとで、地上走行のスピード比較をするようなもんだ。
飛ぶことによって得られる自由度は、最初から比較対象にならない。

>>191
速いコードを書こうとするときは泥臭くなりがちだね。lispのwith-typeマクロ
みたいなのがあると、その泥臭いところは隠すことはできるけど、初心者では
手におえんわな。
TCO（末尾再帰）があるかないかで関数型言語風の書き方が強力になるのか毒に
なるのかが決まってくるかな。

どの言語でも基本的なライブラリを覚えるのは基本だと思うけどな。
この辺は語学と同じさ。英語も２０００語の壁、５０００語の壁があるのと同じ。

>>194
直行概念でまとめられる分が大きい方が楽だとは思う。

>>195
X 直行
O 直交

>>193
ループ
→再帰
→畳み込み
という風に、抽象化が進むんじゃ？

>>190
> 関数型言語は元々、手続き型言語と違って数学を基にしてるから、1から作るのも再利用するのも向いてるんだよ。

関数型初心者にありがちな迷信だねw

> 関数型言語はまさしく算数や数学と同じだ。

算数や数学よりもずっと窮屈だよ
算数や数学では書き換え規則が双方向なのに対して
関数型言語では書き換えは一方通行だから

頭のとろそうな書き込みが見つかるばかりで、
五次以上の方程式については（俺は）全く分かっていなかった。

>>198
数学の計算って何を指して言ってんの？
LKは一方向に進むけど？

5 を 1 + 4 と 2 + 3 と 3 + 2 と....の全てに書き換えた、その全てが並列に存在する宇宙を
知覚できる人なんだろう、多分。

>>198
ガウディ本ぐらいは読もうぜ。

何時も思うけど、なんで知りもしないことのアンチになれるんだろうね？
少しやり取りするだけで無知なのがハッキリ分かるし。

自分の言葉で説明できないから
○○読めとかいって逃げるだけだしｗ
ほんと無知だな。

>>204
で、>>198はどんな数学の計算規則について言ってんの？低能さん？

関数型言語は関数が一杯あってお目当ての関数が探せませーん
みたいなアホが無知でなくて何なの？w

Haskellの演算子は確かにググれないなw

メジャーなライブラリならHoogleがあるが、どっかの誰かのライブラリだと皆目わからんことがある

プログラムってのは、読みやすい解説書のように
書くべきだと思う。

関数ってのは、数学的な関数に解説書が存在するように
読みやすいものではないと思うんだ。

誤読の可能性がいっぱいある文章のように書いて、
いっぱい誤動作させるのがプログラムの目的ならそれは正しいね。

自然言語と違って書いた通りの動きしかしないので
お前の言う誤読は関係ない話だろ。

読み手の力不足で誤読するというのなら
それは関数でも同じように誤読する。

動的言語のなりたちは
シェルとかで簡単にコンピュータに
コマンド打ち込むため。
そこにちょっと欲がでて
制御構造や変数使えるようにした。
話は本来そこまでのはずだった。

つーか、関数型が読み難いって何を根拠に言ってんだ？
適当にコード貼ってみてくれよ

例を出すのならコードは現実的な長さ、
30行ぐらいのやつでお願いね。

>>211
動的言語はGCを作りやすかった
GCがないC++より、Lispの方がましだった
Javaは当初はgenericsがなくて静的言語としては微妙だった
あと、共用体に否定的なC++と部分型に否定的な関数型言語の間でブレがある

GCの作りやすさは動的静的関係ないと思うんだが

チャーチ性も知らずに「関数型言語は数学と同じ」とか、マジでバカすぎw

GCといえば デビット月だよ！伝説のMS-JVM

>>212,>>213
ここのコードがコメント空行抜きで40行くらいだし丁度良い
これと等価なコードを関数型言語で書いてみて比べたらいいさ

http://en.wikipedia.org/wiki/Strategy_pattern#Example

>>206
それは俺だ、無知だなの人と一緒にしないでくれ…
自分は自分が無知なのは充分承知してるよ。

お前たちゴミには理解できない話なんだろうけど

OOによって書きやすいプログラムのほうが
関数型によって書きやすいプログラムよりも「多い」から、OOが使われてんだよ･･･

ほんっとーに、目の前の事実から目をそむけてよく考えず逆論ばっか唱えるゴミッカスが「多い」なｗ

>>219
はぁ？？？？？
＞自分は自分が無知なのは充分承知してるよ。


だったらスレに参加すんな
　　　
　ふ　ざ　け　ん　な　　死ね　


　　知　　　識　　が　　な　　い　　な　　ら　　書　　　き　　込　　む　　な


　ゴミって自覚してんなら死ね

全体の設計とかライブラリを OOP で書いて、局所的にはできるだけ副作用のない関数っぽく書けば良いのでは？

>>218
え？Javaってこの程度のコードに何十行も必要なの？www

OOPと言われてJavaとか言い出すバカってwww

>>223-224
話はコードを貼ってから。

変数名、関数名は>>218のリンク先コードと合わせてある


let execute_strategy f a b = f a b

let context = execute_strategy (fun x y -> print_endline "called +"; x + y)
let result_a = context 3 4
let context = execute_strategy (fun x y -> print_endline "called -"; x - y)
let result_b = context 3 4
let context = execute_strategy (fun x y -> print_endline "called *"; x * y)
let result_c = context 3 4

>>226
それは違う。

Strategyってのは、予め用意しておいて
状況に応じてそれらを切り替えて使うもんだから、
まず名前を付けて、別の場所で定義したものでないといけない。

>>226は移植に加えて、無名関数に置き換えてるようなもんだから
違うものになってるよな。

>>227
なるほど一理ある。修正した


let execute_strategy f a b = f a b

let strategy_add x y = print_endline "called +"; x + y
let strategy_subtract x y =  print_endline "called -"; x - y
let strategy_multiply x y = print_endline "called *"; x * y

let context = execute_strategy strategy_add
let result_a = context 3 4
let context = execute_strategy strategy_subtract
let result_b = context 3 4
let context = execute_strategy strategy_multiply
let result_c = context 3 4

>>229もStrategyのコードの意図とは微妙に違うんだがなｗ
まあ頑張ったから逆に>>229にコードにあわせてJava側を修正したよ。

interface Strategy { int execute(int a, int b); }
class StrategyAdd implements Strategy { public int execute(int a, int b) { System.out.println("called+"); return a + b;} }
class StrategySubtract implements Strategy { public int execute(int a, int b) { System.out.println("called -); return a - b; } }
class StrategyMultiply implements Strategy { public int execute(int a, int b) { System.out.println("called *"); return a * b; } }

class StrategyExample {
　public static void main(String[] args) {
　　Strategy context;
　　context = new StrategyAdd();
　　int resultA = context.execute(3,4);
　　context = new StrategySubtract();
　　int resultB = context.execute(3,4);
　　context = new StrategyMultiply();
　　int resultC = context.execute(3,4);
　}
}

>>230
>>218はexecuteStrategyメソッド内でexecuteを呼ぶのが本質じゃないのか？
それじゃダメだろ。

>>230
あんまし行数変わらんな。

改行の位置をどうするかとか
class宣言のために決まった行数上げ底される程度か。

実際はクラスとか関数の宣言よりも
実装コードのほうがずっと長くなるんで、
相対的な差はなくなるよね。
その差もコード補完で埋まったりするし。

context内部にstrategyを保持して、executeStrategyが実行されるときに
strategyを呼び出すのがStrategyパターン。
>>230は違うものになってる。

>>231
その部分だよ。>>229が本来のStrategyのコードの意図と違うっていうのは。

executeStrategyの中でexecuteを呼ぶのが本質なのではなく、
本当はContextというオブジェクトでないといけない。

例題が悪くて、Contextというオブジェクトは状態を持ってなくて
単にexecuteを呼ぶだけのものになってしまっている。

正しくは>>229にContextオブジェクトを追加しないとJavaコードと等価とは言えない。
このContextオブジェクトはexecuteStrategyだけではなく、
他のメソッドと共に状態を表すいろんなフィールドを持っているものとして考える。

Java側のコードが
> int resultA = context.execute(3,4);
こうなっており、context.foo()などと
contextオブジェクトが持っている別のメソッド
を呼び出せるであろうことは明らか

だから
> let result_a = context 3 4
この言語はよく知らんが。
> let result_a = context.execute 3 4
のような形にしないといけない。

>>229はカリー化を使ってstrategyの保持を実現してて、execute_strategy経由で呼んでるぞ。

>>236
それはメソッド1つだけだろ。

今回の例はたまたまメソッド1つだけだからいいけど、
本来のStrategyはcontext.executeとかcontext.execute2とか
contextが持っているその他のメソッドも呼び出せるものなんだ

> let result_a = context 3 4
これだと、 予め与えられた一つのメソッド、strategy_？しか
呼び出せないcontextになっているだろう。

だからJavaコードと等価にはなってないんだよ。

>>234
関数型言語ではクロージャが状態を保持できる
オブジェクトである必要は無い

>>238
そこは問題じゃない。
contextの使い方が変わってるから
等価になってないという話。

>>237
いや、それは分かる。この例じゃオブジェクト指向の強みが活かせないのは。
でも>>229と>>230なら>>229の方がずっとオリジナルに近い。

>>240
近くても違っている以上別物。
等価なコードになっていないというだけ。

えーと、複数の関数を渡せればOK？

>>240
> いや、それは分かる。

それが分かっているのなら障害は何も無い。
等価になっていないと分かっているのなら、
あとはちゃんと等価になっているコードを書けばいいだけだと思う。

>>242
contextオブジェクトが内部にstrategyオブジェクトを所持しており、
contextオブジェクトが複数のメソッドや状態を持っていても
問題ないようになっていればOK

もう一つあった。Strategyオブジェクト自身も
複数のメソッドを持っていることも考慮すること。

渡す関数が二つとか三つとかなら、そのまま引数に渡すのが関数型言語なら一番簡潔
そしてOOPにおけるStrategyパターンでもそういう使い方が多い

> 渡す関数が二つとか三つとかなら
それはスマートじゃないね。


そもそもStrategyパターンってのは、
Contextオブジェクト（これはいろんな機能を持ったオブジェクト）を
使ってあれこれプログラミングをするときに
その内部のstrategyというオブジェクト（これもいろんな機能を持っている）を
入れ替えることでContextオブジェクトの動作を変えるもの

どちらも関数単体で分離するようなもんじゃないんだよ。

つまり、関数型言語っぽい書き方をしたら、オブジェクト指向っぽくないという理由で却下

>>247
Strategyパターンがそんな巨大なStrategyオブジェクトをやりとりするなんて初耳だぞ。
アルゴリズムを入れ替えるのが目的なのに、ひとつのオブジェクトに沢山アルゴリズムを
パッケージする理由が無い。

http://ja.wikipedia.org/wiki/Strategy_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

ここのPythonの項にも「関数が第一級オブジェクトであり、このパターンを明示的に定義する必要はない」と書いてある。

クロージャで状態保持できるのは関数型言語だけじゃないしwww

にわか関数型プログラマって、ほんと無知だなw

>>249
ちげーよ。

たくさんアルゴリズムをパッケージするんじゃなくて、
一つのアルゴリズムつーか、機能な。
一つの機能が複数のメソッドからなっている場合もあるってことだ。

>>251
> 一つの機能が複数のメソッドからなっている場合もあるってことだ。
例を挙げてくれ

>>250
誰がクロージャで状態保持できるのは関数型言語だけって言ったんだ？

>>252
class Context {
　private Strategy strategy;
　private int count = 0;

　・・・ その他のコード省略
　
　void func123() {
　　strategy.init(this.count);
　　for(int i=0; i<10; i++) {
　　　strategy.do(i);
　　}
　　strategy.finish();
　　count++;
　}
}

見ての通り、strategyはinit、do、finishの3つのメソッドで
一つの機能を提供するオブジェクト。

>>254
それを関数型で書けばOK？あとでオブジェクト指向じゃないとか言わない？

> あとでオブジェクト指向じゃないとか言わない？
言わない。


それはオブジェクト指向じゃない。

今いったｗ

>>256
そうか。じゃあいいや
というか、関数型ではそういう副作用のあるコードは書かないね

>>254
何それ？お前が勝手に作った疑似コードじゃなくて
もっと実際の例は無いのかよ？

本当に>>247の通りならいくらでも見つかるだろ。

結局、手続き型に比べて大して短くもならなければ、読みやすくも、ましてバグが少なくもならないようだ＞関数型

ソートアルゴリズムと比較関数をStrategyとして受け取って、
ソートした後に出力するというStrategyパターン


let print_sorted_list sort comp x =
  let x = sort comp x in Std.print x

let execute = print_sorted_list List.stable_sort (fun x y -> x - y)
let _ = execute [3;1;2;4]
let execute = print_sorted_list List.fast_sort (fun x y -> y - x)
let _ = execute [3;1;2;4]


オブジェクト指向で書いても、あとで関数型じゃないと文句を言ったりはしない

それ、OOPで書いても大して長くならんぜ。
ていうか、>>212は読み易さを比べようって言ってるんであって
長さ比べをしてるわけじゃねぇ。

>>260
>>213が例を出すなら現実的な長さ（30行以上）って言ってるぞ。
それとも、オブジェクト指向言語なら30行超えるとでも思ってんのか？

>>261-262
話はコードを貼ってから。

そのletがなぜ必要なのかばっかり気になってダメだな俺…

>>263
めんどくせーやつだな。
ここだけあれば十分だよな？

Collections.sort(list, new Comparator<int>() { public int compare(int v1, int v2) { return v1 - v2; }});

>>265
全然十分じゃねーよ。
バカじゃないの？

>>266
あとは自分で補間できるだろ？
一行を一行で書きなおすだけ。

>>267
それのどこがStrategyパターンなんだよ。バカすぎる。

f

関数型厨は、現実みろって感じ



どこか局所的な部分においては
OOでかくよりも１．１倍の効率が出るのかもしれない

しかし、そのプログラムをメンテするプログラマは関数型言語になんて慣れていないから
開発効率が０．１倍以上も低下するんだよ
結局全部ＯＯでやったほうがマシ　　関数型は中途半端な概念

面倒なのでストラテジは1パターンのみ（標準に一種類しかソートアルゴリズム無いし）

import java.util.*;
interface SortStrategy<T> { void sort(List<T> l,  Comparator<T> comp); }
class CollectionsSortStrategy<T> implements SortStrategy<T> {
public void sort(List<T> l, Comparator<T> comp) { Collections.sort(l, comp); }
}
class Context<T> {
private SortStrategy<T> sort;
private Comparator<T> comp;
public Context(SortStrategy<T> sort, Comparator<T> comp) { this.sort = sort; this.comp = comp; }
public void execute(List<T> l) { this.sort.sort(l, this.comp); System.out.println(l.toString()); }
}
class StrategyExample {
public static void main(String[] args) {
Context<Integer> context = new Context<Integer>(new CollectionsSortStrategy<Integer>(),
new Comparator<Integer>() { public int compare(Integer v1, Integer v2) { return v1 - v2; }});
context.execute(Arrays.asList(new Integer[] {3,1,2,4}));
}
}

わー読みやすーい
むりやり改行減らして行数少なく見せようとする努力もステキ

めんどくせーやつだな。
ここだけあれば十分だよな？

&#tab;ふ

結論: Javaは冗長

静的言語ではクロージャの連想リストは作れないの？

作れるよ。

おめこ

彼女が「おめこ」連呼しても平気とか
それのどこがStrategyパターンなんだよ。バカすぎる。

OOP使いが低能なのか
Java使いが低能なのか
あるいはその両方か

>>280
低能向けに仕様を固めた言語がJavaだからなぁ…
OOP自体はもはや「使い」なんて付けるほどじゃなく、基礎知識の域だと思う
強いて言うなら「狂信者」ってとこ？OOPさえあれば何でも出来る…と思ってる奴は確かに痛い

>>281
ほう。どの点が「低能向けの仕様」なのですかな？
その理由も一緒にお願いね。

>>282
あいたたたた

まともにプログラム書けないやつほど簡単と言いたがる

単に低脳つーたら怒るわな
一山いくらの分業を可能にしたOOPとしてプロのお給料を支えるJava
pjに一人二人クズが混ざってても計画立てて差し替えられるJava
それは素晴らしい事だよ

あまり言語自体の自由度高いと馬鹿が一人二人暴走したら目も当てられない

まだ、低能向けの仕様がどういった所で
その理由がでてないのかよ。

え？そんなに悔しかったの？www

そんな無意味な煽りはいらないから。

Javaのコードの冗長さもIDEで補完できるという意見もあるけど、
それってつまりJavaのコードの大半は自動生成できる、書くのに人間の知性が要らない
記述する必要のないコードなんだよね。
ライン工場が殆どの処理を自動化して、一部の（それも知性の要らない）作業だけ工員に
やらせるのと同じで、Java PGは自動生成されたコードの一部に単純なコードを挿入するだけ。

>>289
自動生成と補完は意味が全く違うぞ。

補完で終わらせられるような単語の「キーを入力すること」は
人間の知性がいらない、記述する必要のないコードとは言えるが。

型推論があれば必要無い型注釈や、
構造的部分型があれば必要無いインターフェース宣言の話じゃねーの
ここは型付けスレなんだし

Javaの素晴らしいところは、どんなに腕の立つPGでも
一定以上洗練されたコードを書く事は出来ないところだね。
誰が書いても芋臭い冗長なコードになる。
それゆえに引き継ぎの際に人員のスキルが問題になり難い。

型推論って型宣言のシンタックスシュガーにすぎないので
宣言文が簡単に書けるってだけで静的型付けであることに
代わりはないんだけどね。

>>292
宣言の書き方が決まってるだけで、
実装コードはどちらも大差ないよ。

>>289
お前、コード書けないでしょ
たったそれだけの文章なのに、いちいち論理を誤ってんじゃねえよw

そうそう。Javaも他の言語も全然変わらんよ
>>260と>>271を比べてみろよ
似たようなもんだろ？

>>289
俺なら、開発の中で効率化出来る部分、つまり自動化ができる部分があるのなら、
極力自動化が可能なように、いろんな部分を改善して、
人間がやる部分は自動化できない所、自動化出来る部分を機械に
やらせようと思うけどな。

Javaで自動化できる部分があるとすれば、それは言語とは関係なく
開発全体の中で自動化が出来る部分が存在するってことでしょ。

なら機械にやらせるべきだし、それを人間がやらないといけないとしたら
手間がかかっているということ。

俺が言語を作るなら、自動化できるような言語を作るな。

>>296
うん。結局、改行とか宣言とか
そういうタイピングの差レベルの違いしかないよね。

そしてそれらはコード全体を○倍にする類のものではなく、
コードに対して＋α増えるだけ。

しかもIDEサポートでその差は消えるって寸法だ。

そうそう。可読性はかなり落ちるが
どうせ一度書いたコードなんて読まないしな

可読性は落ちてないけど？

それよりも、動的言語の
変数にどんな型のオブジェクトが入っているのか、
見ただけではわからないってほうが問題。

obj と書いてあって、さあこれが一体どんな
メソッドを持っているでしょうか？ と
質問しても動的言語では答えられないだろう。

オブジェクトはメソッド内で生成しているとは限らず
メソッドの引数として渡されるかもしれない。
そうすると呼び出し元を全部洗わないと、どんな型が来るかわからない。

もしこれがString objなら一発でわかる。

>>300
メソッドの引数に型を
コメントで書いておけばいいんだよ。

ま、コメントで書くぐらいなら
コードで書いたほうがはるかにいいけどなｗ

ま、>>260は静的型だから変数の型にも答えられるけどな

そっか、ここでもまた静的型の勝利か。

つーか、JavaはScalaやC#と比べても冗長だろ……

>>304
そうなんだよね。
Javaの構文が冗長なだけで、別に静的型付けが冗長というわけではない。

せっかく色々宣言してあるのだから、それらをうまく使って
簡易にかける言語がこれからできるだろう。

型推論もその一つ、静的型付け言語の宣言をうまく利用することで
簡単に書くことができる文法。

皆スレタイを思い出せ
動的型付け言語で安全なソフトを作れるか？だろ
普通に作れる。ただしソースコードの行数が100行以下なら

100行以上でも作れる
ただしコード内へアサーションを十分に埋め込み、
十二分なテストケースを用意できるのであれば

要は、お手軽さが魅力の動的言語で、
どこまで品質保証にコスト(労力)をかけるのか？という事
作れる/作れないの二元論だけじゃ語れないんだよ

>>253
関数型言語ではクロージャが状態を保持できる(ｷﾘﾘｯ
って人ならいるねww

>>307
> 要は、お手軽さが魅力の動的言語で、

これだから静的厨は馬鹿だというのだ

このスレではJavaやC++は静的型付け(=強い型付け)の言語という分類なのかな？
どっちも静的でコーディング/テストに手間がかかる割には型検査が甘いよね
これじゃ動的厨がグダグダと文句をたれるのもしかたない....のかも

たのむから、型付けの強い/弱いと静的/動的の区別はつけろバカ

弱い静的型付けと強い動的型付けのどっちが
安全なソフトを作るのに向いてるんだろうな

>>312
日本語が違う
型付けの弱い静的言語vs強い型付けの動的言語
と言いたいんだろ？

>>313
そういう言い回しがあるんだよ
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AE%E6%AF%94%E8%BC%83

>>310
静的が、コーディング/テストに手間がかかるって
誰か証明できてたっけ？

>>315
コーディングはいちいち変数宣言が必要だから議論の余地はねえだろ
テストは静的のほうが相対的には手間がかからんはずだけど、
静的な言語なんだから、もっとしっかり処理系でコンパイル時に検査してよ！！ってのはある

静的なのにナゼNullPointerExceptionなんてのが実行時に起きるわけ？！
ゼロ除算例外やI/Oエラーならテストで確認するしかないと思うんだが

そうやな
関数型言語なのにtotalな関数じゃないとか詐欺みたいな事してるもんな
だからtotal function programmingとか

あほか、なんで関数型言語の関数が全て全射でなきゃならんのだ
全射でないから安全でないコードが書けるけど、そもそも「関数型 = 安全」の図式が幻想だ

>>316
> コーディングはいちいち変数宣言が必要だから議論の余地はねえだろ

変数宣言をしたおかげで、
使用するときは逆に楽になるだろ。
そのぶんのメリットをお忘れか？

>>316
> 静的なのにナゼNullPointerExceptionなんてのが実行時に起きるわけ？！

C++のように起きない言語もある。
お前が言ってるのは静的の欠点ではなく
Javaに「C++の参照」に近い仕様を入れろと言ってるにすぎないよ。

C++はその代わりにSegmentation faultが起きるがな

たとえば強い型付け&動的言語であるSMLで以下のようなデータ型/関数の定義があった場合、
　datatype Color = Blue | Red | Yellow

　fun signal color =
　　　case color of
　　　　Blue => "BLUE"
　　　|　Red => "RED"
　　　| Yellow => "YELLOW"
関数 signal の引数が Color型で戻り値が文字列型であることは処理系が保証する。(これは当然)
しかも「うっかり」ケースの書き漏れ(たとえばRedを忘れた...)があったとしても、
静的な型検査で「実行前に」処理系(インタプリタ/コンパイラ)が警告メッセージを出してくれる

弱い型付け&動的言語であるPython/Ruby/Perlがテストでなければ
このようなケース漏れを確認できないのは、弱い型付け言語である以上はしかたがない
でもJava/C++の処理系がコンパイル時に検査してくれないのは不満がある(ストレスが溜まる)
やっぱり「Ｊａｖａ／Ｃ＋＋は弱い型付け&静的言語」だからしかたがないのかな....

よーわからんけどぬるぽはmaybeモナドとかoption型とか呼ばれてるやつを使えばいーんでないの？
進んでる静的型付け言語はもうぬるぽは克服してるイメージがあるけどちげーのか？

そこで、俺が前々から言っている、
コンパイラで自動的に検証できることを増やすという
考えで言語を作ろうという話になる。

>>323
Haskellは副作用を一切許さない純粋関数型言語だから、
モナドを使う以前の話でヌルポは起きようがないよ

>>325
値の検証のタイミングはMaybe外すとき、ってのが分かりやすいだけじゃね？
Nothingの時にfromJustしたら実行時エラー出た気がする。
それをヌルポと言うのかは知らんけど。

それがやはりtotal functional programmingこそ必要

2chでバカを見つける方法だけど、

>>282
>>286
>>289

JAVAはすごいんだ！　ってレスしてるやつってね
こうやって、ちょっとしゃべらせると
このように段階的にボロをだしていくのｗｗｗｗ

面白いよ！　試してみ！

お前はメロンパンナでも食っとけよ

>>328
お前のおかげで思い出したわｗ

結局Javaの「低能向けの仕様」（＝優れた点）は
誰も言わなかったなｗ

机上で語っても仕方ないから、
ミッションクリティカル領域の実績豊富な言語が一番安全ということで。

結論：C言語

>>330
あれ、その認識でいらっしゃる割に俺のコメがスルーされてるような
いや別に良いけど

>>330
ガチ勢だからな、これ


まぁ、お仕事でJAVA使わされている　けど自分は優秀だと思いたい

そういう奴は、JAVAはすごいんだ！　って思い込むしかないよねぇ･････････････あはは

そんな煽りしかできないから
馬鹿にされるわけでｗ

っていうか、言語ごときで、○○使えるから俺頭いいとか、
それこそ頭悪いわｗ

>>325
ゼロ割りその他のランタイムエラーは起こりまくりだけどなw

>>334-335
必死www
いいじゃん　お前の中では332 = uy　って事にしとけよ

それで救われるんだろ？自分を煽っていたのはuyだけで、他の奴からは煽られちゃいない　uyがまちがってるんだ！そう思っておけばさ

　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|
.　　 /: : : //ヾ ; :|!: ｲ､||ll|||||::||　　　 ﾉノ　 ｲ|||||||ヾ､ |: ::|!: : ｲ: ::|/　 　な　思　が
　　 /: : ://: : :ヽｿ::ヽl |{ i||ll"ﾝ　　　 ´　　　i| l|||l"l　｀|: /|: : /'!/l 　 　 ん　う
　∠: : : ~: : : : : : : :丶ゝ-―-　　　　　 , 　ｰ=z_ｿ　　 |/ ﾊﾒ;, :: ::|.　　　だ　ん
　　 i|::ﾊ: : : : : : : : : : : ､ﾍﾍﾍﾍ　　　　 ､　　ﾍﾍﾍﾍﾍ /: : : : : ＼,|.　　　ろ　な
　　 |!l　|: : : : : : : : :､: ::＼　　　　､-―-,　　　　　　/ : : :丶;,,;,:ミヽ　　 う　 ら
　　　　　丶: :ﾊ､lヽ: :ヽ: : ::＼__　　｀~　"　　　　　 /: : ﾄ; lヽ）　　　ゝ
　　　　　　 ﾚ　｀|　｀､l｀､＞=ﾆ´　　　　　　　 ,　　_´ : :}　｀　　　／
　　　　　　　　 ,,､r"^~´"''''"t-｀r､ _　　-､　´ヽノ　＼ﾉ　　　／　　　　お ・
　　　　　　　,;'~　　_r-- ､__　　　　　~f､_>'､_　　　　　　　　 |　　で　　前 ・
　　　　　　f~　　,;"　　　　　~"t___　　　　ﾐ､ ^'t　 　 　 　 　|　　は　　ん ・
　　　　　 ,"　　,~　　　　　　　　　ヾ~'-､__　ﾐ_ξ丶　　　　　|　　な　　中 ・
　　　　　;'　　,ｲ　.. 　　　　　　　　　ヽ_　　 ヾ､0ヽ丶　　　　l　　　　　　　　　/
　　　　 （　;":: |:　:: ..　　　　　　　　　 .｀,　　 ヾ　丶 !　　　　＼＿＿＿＿／
　　　　　;;;; :: 入:: :: :: 　 　　　l｀ｰ-､　　 ）l　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

>>322みたいな「強い型付け」「弱い型付け」「動的型付け」「静的型付け」の
区別がつかないアホって、一体どうやったら学ぶ事ができるのかな？
RubyやPythonは「強い型付け」でかつ「動的型付け」なんだけどね（それを通常「強い動的型付け」という）

>>338
静的の定義を書けば？

>>339
http://ja.wikipedia.org/wiki/%E5%9E%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0

http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
「Javaはブルー・カラーの言語」
「ジェネリクスは大失敗でした。Javaの習得や理解は難しくなりましたが、それを避けることはできないのです。」
（他言語でも総称型は使われてるけど、"Javaプログラマ"には難し過ぎるってこと？）

>>341
お前がメインで使ってる言語を挙げてみろよw

いいじゃん　お前の中では強い子って事にしとけよ

動的型付けって時点でもう致命的

救われたのか？

で、こんだけＪＡＶＡはすげーんだ！すげーんだぞ！！
ってやってて、最終的な逃げ道は
「どの言語使っても同じ」
だもんなぁ・・・・・・

仕事でＪＡＶＡ使わされている時点で気づけよって話なんだけど
いまだにＪＡＶＡ使いこなしてる自分を優秀とか思ってるのだろうか
そりゃこの業界には論外素人も入ってくるから、
ちょっとでも勉強する気があれば、先輩面できるんだけども
ＪＡＶＡを後輩に得意げに鼻息荒く教えた程度で、2chで火病っちゃうくらいなら、君はＪＡＶＡをやるべきではなかった

こいつ誰と戦ってるの？

いつコンビニ業界のコトになったんだ。

>>341
言語仕様の議論で「この仕様はPGにとって複雑すぎるのでは？」という
やりとりはどの言語においても見られる。あのC++でさえ

ただJavaの場合その閾値がちょーっとばかり低いだけだw

ストーカー女神が救われたのか？

もうすぐ来るよｗｗｗ　JAVAERの必殺技！！　みててみｗｗｗ
　J　A　V　E　R　「　ど　の　言　語　使　っ　て　も　同　じ　」　
予想では>>400-450 このあたり

どの言語使っても同じだろ全くおまいらときたら

>>352
仕事中に何2chみてんだ

すみません

必死www
いいじゃん　お前の中ではカレと会話って事にしとけよ

へ？

まあいいけど

クソワロタ

今日さ、つまらないスペルミスでバグになっていて、
その修正にちょっと時間を費やしてしまったんだけどさ
バグの原因を見つけたときに思った。

動的型付け言語だとちゃんとテストコードあっても
スペルミスの原因を探すのにこんなに時間がかかるんだ。
これがもし静的型付け言語なら一発でわかるのにって。

やっぱり静的型付け言語のほうが
コーディングが楽だよ。

方向を間違えなければ、時間をかけて進むのは苦にならない

間違った方向に全力を傾けた時の絶望感に比べたら

>>359
どっちも嫌に決まってるだろ。

そこそこメジャーな言語の中じゃC#が最強だな。monoが普及すればJavaとかスクリプト言語とか無用になるな。

C#はMS言語だからね

けどスクリプト言語が無用にはならない。
可読性とか気にしないで、
ある目的達成のためだけに最も速くプログラムを作るには
スクリプト言語が必要

たとえば、どこかのサイトの画像を全てダウンロードして連番にRenameとか

Rubyであれば、純粋に記述量が少ないから
エディタ起動から60秒でかけるけど
C#になると、慣れたとしてもわからんな

>>358
メタプログラミングが常套手段の言語だと、
確かにこういう弊害あるな。

デバッグを想像しただけで泣ける。

コード自体の書き換えが多かったり、
使い捨てなら確かにスクリプトの方がいい。
というか適材適所だろ。

>>358
んー、
それは、たぶんお前の能力の低さだと思うけど

そんなレベルだと静的言語では静的言語特有の問題にぶち当たるんじゃないかね

>>358
まともなエディタも選べないカスはどの言語使ってもゴミしか書けねえってことだ。

>>358
宣言の有無と型付けの有無を区別できないカス？
Haskellでも↓はコンパイラ通るぞ
fil 0:xs = fil xs
fill 1:xs = 1+ (fil xs)
fil x:xs = 2 + (fil xs)
fil xs = 0

やっぱり２３年度国産米では安全なソフトは作れない

>>367
馬鹿に真面目に突っ込んでも無駄だよ
どうせ>>358もJava土方の作り話だし

>>364
それくらいの簡単なプログラムの需要があるのは分かるけど、Rubyみたいな多機能な言語が必要かな？
Perlはuse strictしないで使うのが正しいみたいな事言う人いるけど。

Rubyなんかだと、標準ライブラリにスペルミスが入り込んだまま長い間気付かれなかったりするし。
完璧でなくてもある程度チェックしてくれる仕組みは欲しいな

えらく広く使われてたJava製の某フレームワークにもスペルミスがあったなw

バレバレですよuyさん

>>373
uyがJavaのフレームワークのことなんて知ってるわけないじゃんw

所詮は知ったか坊やですし

>>372に言ったのではなかったがまあいいや

コンパイルエラーってバグになるんでしょうか？

明確な定義とかじゃなくて、コンパイルエラーを
感覚的にバグと捉えているかどうかを聞きたいのです。

特に動的型付け派の人に。

>>377
おれは日常的には lisp の人だが, バグと見なすよ.
lisp の場合, 宣言つけまくると, 下手な静的片付け言語より
型検査厳しい処理系もあるからかもだけど

知力 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　青村早紀
　 ↑　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
秀│　　一ノ瀬ことみ　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　裏葉　水瀬秋子
　 ｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　来ヶ谷唯湖　　　　　　　　　　　　　　　　　　　　　　　
　 │　　　　　　　　　川澄舞　　　　　　　　　　　　　　　　　　　霧島聖　　
優｜　　　　　　　　　　　　 二木佳奈多　　坂上智代　　　　相楽美佐枝　天沢郁未
　 │　　　　　　　　　　能美クドリャフカ　　西園美魚　倉田佐祐理
　 ｜ 　　　　　　　　　　　　　　遠野美凪　笹瀬川佐々美 美坂香里 　　
良｜　　　　　　　　　　　　　　　　　 　　　　　　　　長森瑞佳　　　　　　　　天野美汐
　 │　　　　　　　　　　　　　　　　　　　　　　　里村茜　川名みさき　　　古河早苗
　 ｜　　　　　　　　　　　　　　　　　　　　七瀬留美 　 　　　　　　　　　　　　　　　　　　
可┼　　　　　　　　　　　　　　　　　 藤林杏 藤林椋　　　　　　　
　 ｜　　　　　　　　　　　　 上月澪 神北小毬
　 ｜　　　　　　　　三枝葉留佳 霧島佳乃　美坂栞 　神尾晴子
落│　　　　　　　 　古河渚　 水瀬名雪　　　巳間晴香
　 │　 　　　　　　伊吹風子　名倉由依　　
　 │　　　　　　　　　神尾観鈴　　 河南子　　　　　　　　　　　　名倉友里
逝｜　　　　　　 棗鈴　　月宮あゆ　　　　　　　　　　　　　　　　　　
　 │棗鈴(退行) 椎名繭 鹿沼葉子 神奈 みちる
　 ｜　神尾観鈴(退行) 志野さいか 岡崎汐
死│　　沢渡真琴(退行)　　　　　　　　　　　　　　　　　　　　
　 ↓uy 　
　　 ←―――――――――――――――――┼―――――――――――――――――→
　　　　基地外　 　　　イタタ　　　　厨房　　　　　普通　　　　　大人　　　　君子　　　　　聖人
　　　　　　　　　　　　　　　　　　　　　　　　　情緒的成熟度

>>377
動的型スキーだけど、バグだろうね。
ただ、環境のバグかプログラムのバグか、そこが問題だ。

GCCに-Wextra -Werrorを付けてる奴ばかりなら少しは納得するw

>>379
わろた

やっぱり動的言語を使っている人って
コンパイルエラーをバグとして考えているんだね。

俺は、プログラミング＝設計であり、バグは設計上の問題。
コンパイルエラーは、コンパイル＝製造だから、製造上の問題と考える。
名前をつけるなら、歩留まりかねぇ。

この2つは全く別物あつかいなんだよ。
だから自然とこの2つを分けて考える。


製造は自動化出来るもの。設計は自動化できないもの。
単純作業（いわゆる土方作業）はなるべく自動化出来る製造に回し、
どうしても自動化できない設計を人間が行うという発想になる。
だから設計のテスト方法であるユニットテストで、製造のテストをするのはなんか違うだろってことになる。

やはり、基本的には静的型付け言語の方向で進みながら、動的型付け言語の機能を取り込むのが
プログラム言語の未来への正しい道だと思うな。

あのー、ドヤ顔してるところ申し訳ないんですが、
静的型言語派の俺もコンパイルエラーはバグだと思ってますよ、と。

>>383
例えば未定義のメソッドを呼び出そうとしてエラーになったとすると
呼び出そうとしたのが悪いのか、定義していないのが悪いのか、自動的には判定できない
どっちが悪いかを考えるのは人間の仕事

>>383
論点があいまいで読んでてイライラする文章

コンパイル通らないのはバグ以前の問題で、バグとは思ってないな。

ようわからんが俺も387と同じだな

自分の書いたコードについては>>387と同じ
他人の書いたコードのコンパイルエラーはバグと感じる

イライラするのは、決めつける言い方が多いから

変数の型を決めつける言語にイライラするのと似ている
自分で決めつけたことはイライラしない
他人が決めつけるとイライラする

>>383
>プログラミング＝設計であり、バグは設計上の問題。
>コンパイルエラーは、コンパイル＝製造だから、製造上の問題と考える。

プログラミング=設計の段階でコンパイルエラーの原因が発生するんだから
製造の問題では無いよね。そこが間違ってるので以下全部おかしい

>>391
設計は頭の中にあるんだよ（ｷﾘｯ

まあ、こういうこと。
設計は頭で考えるまでで、紙に書くのは製造の段階だよ。

実際経験を積んでいる人は、設計を考えるときに
言語のことはほとんど考えないでしょ？

プログラミング＝設計という時点で趣味グラマあるいは底辺コーダの発想
以降の内容は反論する気もうせる

>>393
お前に話しかける気も失せたんだが、武士の情けだ。

プログラミングは「設計」か「製造」か
http://techon.nikkeibp.co.jp/article/TOPCOL/20070821/137958/
> プログラミングという行為は「ソフトウエアの製造」ではなく
> 「ソフトウエアの設計」である，というのがIT分野では半ば常識です

昔はコーダーというものがあったらしいんだが、
コンパイルエラーはコーダーによるミスになるだろう。
直感的に考えて明らかにバグとは違うものだよ。

>>394
貼ってあるリンクの続き。

＞だから私は「プログラミングが製造だとするのは間違いである」と頭から信じ込んでいました。
＞でも最近，この信念がゆらいできています。

いまどきの日本の最底辺の下請けコーダーは
プログラミング言語と一対一対応するような仕様書を受け取って
それをコードに翻訳する仕事をしてるのかい？
いや、良く知らんのだが。

>>396
それは、それを書いた人の考え。

IT分野では半ば常識であることを、
趣味グラマの発想などと言ってしまった。

自分が無知であると言ったようなものじゃないか。
その時点で自滅してるんだよ。

>>397
良くない流れがあってね

下請けコーダーがやるようなことを
なぜかプログラマがやってるんだよ。

そんなのコンパイラにやらせとけと思うのだが、
とうとうコンパイルエラーをバグと考える人が出てきてしまっている。

本来下請けコーダーのやるような簡単なミスが、
なぜかプログラマのバグとして扱われ始めている。
良くない傾向。

>>394
引用の記事は、単なる雑誌記者のブログだろ。それが絶対的真理ではない。
しかも記事の後半は、著者自身が「信念のゆらぎ」を正直に告白している。

プログラミング＝設計が真実になるのは、プログラミングという行為と並行して
頭の中でモデルやアーキテクチャをイメージ(設計)できる一流のプログラマ達に限定される。
そういったプログラマであれば、いわゆる「アジャイル開発プロセス」も成功する。

この記事が書かれたのは2007年だが、あれほど騒がれたアジャイル熱も冷めているのが現実。

どっちにしろ393は馬鹿ってことだな

>>399
ずいぶん業界にお詳しいんですね

どちらかというとマ板の議論が続いているな

ところで、その設計 vs. 製造の話が、なぜ動的片付け/静的型付けの結論になるのか、
>>383を何度読み返してもさっぱり意味不明なんだが....

コードと同レベルの粒度で仕様書を書くなんて無駄
自然言語じゃなく最初からプログラミング言語で書いときゃ動くものが出来るのに

プログラム書けないSEモドキの雇用創出以外の意味あんの？

「ソフトウェアアーキテクトが知るべき97のこと」という本にも書いてあるよ。

「(31)プログラミングは製造ではなく設計だ」アイナー・ランドル
http://d.hatena.ne.jp/kent4989/20091008/p1

プログラミングは設計だという考えに反対する人もいるだろうけど、
少なくとも、プログラミングは設計だという考えを知らない人は
モグリと言われてもしょうがないよ。

>>403
静的型付け言語を使っている人はみんなそうだと思うけど、
コンパイルエラーはバグだとは思ってないんだよ。

動かないからね。単なる入力ミス。すぐに修正できる。
たいてい構文エラーや宣言してない変数を使ったり、メソッドを使ったりって
これはつまらないスペルミスであることが多い。

こんなくだらないことと思うかもしれないが、これだって修正しなければいけない以上
すぐにミスがわかったほうが良い。こんな下らないことだからこそ、修正に時間をかけてはいけないんだ。

だけど、動的言語だとどうしても動かさないとわからない。
そこで仮説を立てた。動的言語ばっかり使ってる人は、静的言語を使っている人に比べて
コンパイルエラー程度の小さなものを、バグとして認識しているのではないかと。
本質的に違うものが、混ざってしまっているのではないかと。
で、質問した所、実際にそのようなレスが返ってきた。
（>>387のように、バグ以前の問題と認識している人もいるけど）

じゃあ、バグとバグ以前のものはなにが違うを考えてみた所、
設計工程による不具合と製造工程の不具合の違いではないかと気づいたわけさ。

動的型付け言語と動的言語、静的型付け言語と静的言語が
ごっちゃになってしまったな。
全部型付けの方だから訂正しておく。

>>406
やはり下半分が意味不明だ

仮説通りだった事は何を証明してるの？

よー分からんけど少なくとも>>383はおかしいな。大体>>391と同意見。

>>406
使ってる言語はC、C#な人間だが、コンパイルエラーはバグだと思ってるよ。
言葉が気に入らなければそっちの言うバグも含めて
同列に欠陥、不具合と言いかえても良い。

ただ、管理した方が良い欠陥とそうでない欠陥があるだけ。
アクティビティを越えない欠陥は、大体管理しなくて良い。


変な線引かんで欲しい。

>>406
ていうか今どきはIDE使う人がほとんどだから、普段プログラミングしてて
コンパイルエラーなんて意識しないだろ

それにしてもイライラする文章
少し前にさ、プログラミングは設計である！ってドヤ顔するのが流行ったよね
今さらドヤ顔してる奴を見るとは思わなかった

今は上から下までドヤ顔の時代
ドヤ顔しないやつはドカタと蔑まれる時代

製造業のアナロジーでプログラミングを語るのは勝手だけど
例えは例えにすぎないわけで、それが本質みたいな言い方されてもなー

静的厨からも動的厨からも反感を買う、新しいタイプの静的厨だな

Rubyは全然好きになれない。
includeされまくってると何処で定義されてるメソッドか分からねぇし、
くだらねぇタイポも実行時に初めて分かるし。
なにが生産性だよ。

実行可能コードが生成された以降からバグが発生する。
従ってコンパイルエラーはバグとは考えていない。

>>414
Rubyという言語が嫌なんじゃなくて、IDEのサポートが貧弱なのが嫌なんでしょ？

どっちにしろ未婚独身女性の発するクヒヒは馬鹿ってことだな（業界にお詳しいんです。）

バグがなくても何かと理由をつけてソースコード熟読したい人もいる
速読や速記を自慢したい人ばかりではない

ソースコードの読み易さランキング

Haskell > Python >> Ruby >> 超えられない壁 >> C++ >= Perl >> Java

>>419
ただし小規模に限る

>>419
同じ文字数なら、断然Java>>Haskellだな。
Javaは良く出来てる。
沢山書いても、実現してる事は少ないから頭を使わなくていい。

土方でも読めるもんね、Javaすごい

>>421
文系が数式よりも記述密度が低い自然言語での説明を好むように
低能は記述密度の低いJavaを好む

いくらHaskellやPythonが仕事で使えるとしても、
お前らみたいな勘違いばかりなら確実に鬱になるな。

>>416
そうかも。みんなはどうしてるんだろ。
動的言語を静的に解析するのは難しいから
諦めて根性でカバーしてんのかな。
Lispのslimeみたいなのもないだろうし。

>>425
実行しろよ
ソフトは実行するためにあるのになぜ実行したくないんだ

>>426
実行してるよ。いちいち実行して確認が面倒って話。
分岐すると両方確かめないとだめだし。
自動テストもやってるけど、カバレッジ率上げるのしんどいし。

>>427
お前の中では面倒なんだろうけど、他の人がどう思うかはその人の自由。
自由にして生産性を上げるか、徹底的に管理して生産性を上げるかという話だな。

そんな話なの？ｗ
普通に同意できる内容だと思うけど。

>>389が感覚的に近いかなあ。
共同作業だと各自のライブラリやらソースやらのバージョンの差で、
自分の手元でコンパイルできて他の人がコンパイルできないコミットする場合あるし。

まあ静的言語でパーサ通っても安心て訳じゃないのは当然だけど、
型チェックくらいはパーサに任せたい。

パーザで型チェック

型は構文より後だろって？静的チェックさせたいと言いたかったんだよう。
ところでパースとパーズとどっちが一般的なんだ

カタカナ表記はパースが一般的
同僚のイングランド人の発音はパーズに近かった

rubyは断然読みづらい
言語内言語がひどい
勘違いして明後日に向かった典型例

ソフトはコンパイルするためにあるのになぜコンパイルしたくないんだ

コンパイルするためにあるんじゃない！実行するためにあるんだ！
っていう主張なんでしょ。

>>416
> Rubyという言語が嫌なんじゃなくて、IDEのサポートが貧弱なのが嫌なんでしょ？

IDEのサポートが貧弱なのは
Rubyという言語が原因。

>>406
ハスケルの偉いひとも「コンパイルはテスト！」って言ってたお？

そりゃ、バグが見つからならテストになりうるわな。

でも、コンパイルで見つかるのなんて、スペルミスとか
構文エラーとか、そんなのだろ？

そんなのバグのうちに入るのか？
そういやこのスレ的にはコンパイルエラーもバグという定義なんだっけ？

ならまあいいんだけど。

動的言語ではスペルミスも
致命的なバグになりかねない。

スペルミス等も考慮した、大規模開発における生産性

Haskell >> Python > C++ >> 超えられない壁 >> Ruby >> Java >= Perl

Haskellで実用的なコードを書ける人員は非常に高くつくんで
利益/コストが高くなるようには思えない

利益が出てるから、高額で雇える。

利益は言語では決まらない。

ミスは許されない。
でも、人間が失敗するのは人間だから仕方ない。

この設定なら最初から危険だろ。
これが現実だと言うかもしれないが、自然法則ではない。人工的に作られた設定。

Haskellとか数学とかって、やっぱり自然科学とは違うのかね。

なに言っちゃってんの？

あたいを変える方法はないので、クロージャ間で状態を共有する必要はない。
単に同じあたいを使うだけである。そこで、クロージャが捕捉する"環境"は、
あるスコープのすべての変数の束縛の集合で"ある"ので、私はﾏｻﾁｭｰｾｯﾂ。

結局、変数は宣言する、それも型と一緒に、って事だろ？つまり、Rubyはダメって事じゃん。

その「結局」、が何を指してるのか説明プリーズ

おまえの日本語はまるでRubyだぞw

>>431-433
多分、>>431を書いた人は、パースは単なる構文解析ステージであって、
型チェックを行うのは「意味解析」ステージだ、と言いたかったの
だと思う。

あ、はい、そのようにとらえております

>450
おまえウケるw

分類分けに関するコミュニケーションの行き違いであるところが味わい深い

スペルミスって、そんなにするかなあ。
てかRubyだとしても、ミスって困るのは代入のときだけだろ？それ以外だとエラーになるだろうし。
それって、変数の使い回しとかしない限りそうそう困らないような。
Hashにはfetchがあるからキー名のミスもそれで対処できるし。

> スペルミスって、そんなにするかなあ。
最初の一発間違えれば別だけど， 今時エディタが補完するし...

GUIだって、ラインコマンドだって、やれることは同じでしょ。後者の方が、何をやっているか見えていいでしょ。
コンピュータ・オタクたちはよく言っていた。確かに、マッピングはできる。しかし、計算的には等価ではない。なぜなら、
それは、時空の中で展開されるものだから。「計算」という概念が、狭すぎるのである。コンピュータという存在が、
どのように私たちの脳の感覚、認知の回路に働きかけるか。感覚と運動の連関を通して、さまざまなクオリア、情動を
引き起こすか。それは、「気のせい」や「趣味」のことなんかじゃなくって、「計算」なんだってば！

マック・ユーザーを、「こけ」にするコンピュータ・オタクたちがずっといた。いいよ、Linux使っても何やってても。
でも、そういうチューリング・マシンの枠内で理解できる「計算」と、異なる「計算」が、この世界にはあるんだって。
なんでそのことが理解できないかな！ iPadが出てとき、まるで遊んでいるように情報を扱えるようになった。3歳の
子どもでも遊べる。キーボードからラインコマンドを打つコンピュータと、それは、アルゴリズムでは等価かもしれない。
しかし、「経験の質」という「計算」においては、全く違うんだ！ OSで、アイコンをどのように配置するか。ハード
ウェアの曲線や、手触り、立ち上がりの時の音楽。ジョブズがやってきたことは、「趣味」の問題じゃなくて、人間の
感性における、ハードコアな「計算」なんだ。それを、「マック信者」だとか言って、「こけ」にしてきたんだよね。

Googleは、ユーザーが要求した情報以外には提示しない、という哲学で一つの「経験」を提供した。一方、世間には、
要求もしないのに余計なことをするソフトがあふれている。それは、「経験」という「計算」の領域において、やっては
いけないことなんだよ！ 結局、ジョブズは、単なるアルゴリズムの箱という意味合いを超えた「計算」の領域を、
コンピュータにずっと見て来た人だった。趣味や感性の問題じゃないんだ。そこには、緻密な計算のロジックがあるんだ。
そのことを感じた人がアップルを支持した。ジョブズは、計算の未来だった。

http://togetter.com/li/197523

言葉遊びという茂木の本質が非常によくわかるわめきだ

>>要約
オタクはCUIでの計算を好むけど、人の感性への働きかける計算も重要。

そしてGoogleが要求にだけ応じる、という感覚を提供する一方、
世間にはその感覚外の余計な事までする逸脱したソフトもある。

とにかく、ジョブズはそういう枠外の感覚の計算を考えてた人で、
それを感じた人がアップルを支持した。

>>もっと要約
考えるんじゃない。感じろ。

しょぼいPC画面やなぁ

さらに要約

アップルはお洒落(そんなアップルを支持する俺もお洒落)

アップルの威を借りるオタクが同類をコケにしてる

Windows = Java
Mac = Ruby

ああ、Ruby使ってる奴っていかにも茂木って感じするわ。
なんか自分だけ天啓を受けたような気がしてる、すっとこどっこいな感じ？
悦に入ってるけど、端から見ると普通に可読性低いよっていう。

茂木のツイートは読みづらいわりに面白くないのがなぁ。

とりあえず俺はRubyの方がWindowsっぽい気がする。
洗練されてなさっぷりが。
けなしては無い。
パッと使う分には使いやすい。

>>456
プログラマの立場から言わせてもらえば、コマンドラインアプリすら作れない奴にまともなGUIアプリは作れない

Macが使いやすかったのはOS9までの話だな。OSX以降は普通にウンコというか、もうAppleはiOSの会社でMacはオマケ。

さすがに釣りにしても無理あるというか

>>466
言えてる
ジョブズの引退ら死去までが早過ぎたから、後継者が育ってるかも疑問
iPhone3G->3GSは劇的だったけど、iPhone4->4GSはジョブスのやり口なら5を持ってきてたはず

今回の発表ですでに現CEOの底が見えた
小出し戦略での食いつなぎ
ジョブズのパターンしか見てない

精神は引き継がれてない

byどざえもんw

MBAにWindows7を入れて使うのが正解

要約
・同じでしょ
・等価ではない
・「計算」という概念が、狭すぎる
・チューリング・マシンの枠内で理解できる「計算」と、異なる「計算」が、この世界にはある
・等価かもしれない
・全く違うんだ！

脳がバグってる

ここの人たちはJavaの悪名高い検査例外についてどう思う？
特に静的型付け派の人に聞きたい。

http://thinkrelevance.com/blog/2007/05/12/static-typing-and-readable-code.html

大半をExceptionにキャストしても
1個でも強い型が残れば実質的に静的型付けの勝利
0点じゃないなら1点でいいです

>>472
考え無しに握り潰すアホは考えない前提で、
アジャイルでないプロジェクトにおいては有益。

考え無しに握り潰すアホは考えない前提なら
アジャイルでも有益

じゃなくて、
メソッドをサブタイプする度に
例外のクラスをどんどん上位の例外クラスにするという
検査例外の言語仕様のアホさの話だろ？

>>477
意味が全くわからん。
検査例外の問題点がわかってないんじゃないのか？

>>474
Exceptionにキャストしてどうやってまともな例外処理をするつもりなんだ？

困った時は動的型に頼る
ほとぼりがさめたらまた動的型を排除する

動的型 ＜ 体(コード)だけが目当てだったのね！？

実装の詳細を曝す
かといってあまりラップして一般的にしすぎるとthrows Exceptionと大差ない
そもそもその場で例外処理するべきでない場合は多い

>>478
477読んでもわからないってことは
おまえは検査例外の問題点を理解していないということだ

>>477は俺も意味が分からないな

メソッドをサブタイプする？
例外のクラスをどんどん上位の例外クラスにする言語仕様？

検査例外の問題点を考える前にJavaの入門書でも読んだほうがいいよ

>>483
よし、今からお前、
foo()というメソッドをサブタイプしてみせろ

>>485
まずはそのfooの型を示せ
話はそれからだ

つうかサブタイプも知らずに検査例外がどうこう言うほどのキチガイはそう滅多にいないな

>>486
お前が自由に決めていいよ。

チェック例外はJavaにラムダを導入するのが難しい大きな理由の一つらしいけど
ガチな関数型の世界ではその辺うまくやる手法ってあるの？

> チェック例外はJavaにラムダを導入するのが難しい大きな理由の一つ
なんで？

例えばCallable#call throws Exceptionてあるでしょ
一般的すぎて何投げるかわかんないからExceptionにするしかないんだわ
ラムダが入るとそういうのが激増するから、そのままだとチェック例外が無意味になる

>>488
引数の型がサブタイプで
返り値の型がスーパータイプで
例外の型がサブタイプなら
そのメソッドの型は元のメソッドのサブタイプだ、
という常識もわからないキチガイはホムセンでロープ買ってこい

>>492
で、「メソッドをサブタイプする」ってのは
どうなったんだ？
お前が言ったんだぞ

＄ 打ちまくってる感触はどう？

>>492
縛ってほしいのか？？

>>493
ばか死ねカス

>>489
Scalaもチェック例外無いし、どうなのかね

>>489
例外は副作用
副作用が発覚したらファンの人が幻滅する

関数型言語の中では例外を直和型で扱うのがあるけど
検査例外よかまだ筋はいいと思うわ
というか検査例外はあれを目指してたんだろうな

Either型を使えばいーさ

審議拒否

例外が副作用とか、頭おかしいんちゃう？

Haskellで型付けされた継続とか使ってみればわかるよ

Haskellで型付けされた例外を使ってみれば
例外が副作用とかプププってわかるよw

a -> Either b Nullpo
これが世界の選択か……

このスレ的にはDartはどうですか？

Googleはちょっとした研究の成果物と実用目的のものを区別しないで大袈裟に発表するからなあ
信用無くすぞ

Dartは静的に型付けできるよ

でもあまりメリットない。

型注釈構文とそれを元に警告を出すlintが標準で付いてくるだけで
動的型付け言語だよね

まあActionScript程度のパフォーマンス向上はあるかもね。
でもその程度。

結局JSになるんじゃ変わりようがないんじゃ？

CoffeeScriptの後だからもうちょっと面白いの期待したがダメだったな
っていうかCoffeeScriptに型アノテーションと名前空間ついた言語を

＄ 打ちまくってる感触はどう？

DartはDOMがJavaScript本体とさほど変わらない時点でWeb言語として終わってる

Dartは本当に真面目にやってんのか疑いたくなる有様だが、
一応Googleは動的型でも大規模アプリを開発できると
考えてるってことになるのか……？

dart、型指定できるじゃん。

ほんとに見るところのない言語だな
あくまでリサーチプロジェクトとしても目的がよくわからん
Googleが言ってるJavaScriptは中間言語だというのを実践してみたかっただけ?

>>517
静的に型チェックするけど、間違ってる可能性があっても警告出さない場合があるってさ
どうせなら型推論にしろよ誰得だよ、と思った

なるほど。静的型付けベースで
動的型付けも許容するって位置づけなのか。

Dart使うくらいならGWTだろJK

C#のdynamicキーワードはそんな感じだけどね。Dartは動的型ベースだと思う。

例えるなら、Pythonにはpylintってチェッカーがあって
簡単な型エラーを静的に見つけられるけど、それの強化版って感じ。

Dartの仕様からは「静的厨はIDEで補完できてスペルミスが見つかりゃ満足だろ？」
「動的厨は型を省略できりゃいいんだろ？」的な意図を感じるw

なるほど。静的型に絡んでるやつは変態ということで。

素人考えだけど、DartはC#で言うdynamicとautoをわければよかったのに
なんでもvarじゃ型推論されるケースとダック型になるケースが分かりにくくない？

完全な型チェックしようとすると実行開始までに時間がかかっちゃって
JavaScriptに対するディスアドバンテージが目立っちゃうのを嫌ったんじゃないかなあ

なんか動的厨房が必死だなｗ

要するに、大規模向けならstrictモードONにして
省略をなくしてミスを減らせる。

それと同時に、簡単なツールとか用にstrictモードOFFで
短く書けるってことでしょ。

本当に動的だけでいいのなら、静的型付け機能はいらなかったはず。
やっぱ、Googleも大規模では静的型付けが有効ってわかってるんだよ。

>>526
> 完全な型チェックしようとすると実行開始までに時間がかかっちゃって
JavaScriptにコンパイルすればいいから関係ない。

http://internet.watch.impress.co.jp/docs/news/20111011_482895.html

> 言語の特徴として、Dartは開発者になじみのあるクラスやインターフェイスを備えている。
> また、オプションとして型を利用できる。アプリケーションの初期開発段階では
> 型を使わずに開発を進め、後にプロジェクトが複雑化するにつれて型を利用できる――と
> いった使い方が想定されている。また、ライブラリや開発ツールも提供されるとしている。

やっぱり複雑化したら、型使ったほうがいいということか・・・

http://japan.cnet.com/news/service/35008825/

> 以下は、Dartの設計目標に関するBak氏の簡単な説明である。

> 　Dartは、1人のプログラマーによる、特に構造を意識しないプロジェクトから、
> コード内にプログラマーの意図を記述する為に定型が必要となる大規模プロジェクトまで、
> 広範囲にわたる開発作業を対象としている。Dartにはこのような広い範囲のプロジェクトを
> サポートするためのオプションが用意されている。

> つまり、プログラマーは型を定義せずにコードを記述し始めて、後で必要に応じて型を追加することができる。
> Dartは大規模なウェブアプリケーションの記述に非常に適したものになるとわれわれは考えている。


やっぱりそうか。大規模＝型か。

>>525
型推論は、単相型になるケースと多相型になるケースが分かりにくい。
let i x = x in (i i) (i i);;
let i x = x in let ii = i i in ii ii;;

わかりにくい時は型をちゃんと書けばいいわけで、
型推論は難しく考えず、たんなる型を省略した書き方をしても
型を書いたのと同じ効果があると考えればいいのではないかな。

>>530
大丈夫だ。ちゃんとコンパイラが教えてくれるし
慣れれば息をするようにeta expansionできるようになる

let i x = x in let ii x = (i i) (i i) x in ii;;

>>527
ここ読んでみろよ。マジで動的型言語にlint付けただけって
分かってガッカリするぞ
http://www.dartlang.org/articles/optional-types/

Dartには、動的言語としての強みはあるんか？
オープンクラスとか、メタプログラミングが得意とか

こういっちゃうのは早漏かもしれんけど
Googleって言語に関してはなんというかガッカリさんだな今んとこ

あるのか無いのかわからんうちから
がっかりとか言う奴は信用ならんなｗ

コンパイル時メタプログラミング（LispマクロやC++テンプレート等）は無さげ
evalも見当たらない

javascriptユーザーのうち使いこなせるプログラマはどれだけいるんだ？
費用対効果から考えて本当にそれらの機能は必要なのか？
なくてもjavascriptだけで書くよか、はるかに苦痛が和らぐから

Google「DartはJava土方にも理解出来る構文にしました」

GoogleってJava使ってるらしいけど、
Googleよりもお前のほうが土方じゃね？ｗ

静的型付けなら安全化と言うとそうでもない訳で

でもBak氏はこう言っているわけで。

> 以下は、Dartの設計目標に関するBak氏の簡単な説明である。

> つまり、プログラマーは型を定義せずにコードを記述し始めて、後で必要に応じて型を追加することができる。
> Dartは大規模なウェブアプリケーションの記述に非常に適したものになるとわれわれは考えている。

斬新な機能とか不要って事でしょう。
スクリプト言語で型が指定出来ればそれで十分だよね、っていうのがGoogleの答えだ。
俺はこれで十分だと思う。
クールな機能はいらないから、マルチプラットホームな実行環境・開発環境、バージョンアップ後も安心して使える互換性、過去バージョンも含んだバグフィックス、ドキュメント整備、そういうのを高めてほしい。
既存のスクリプト言語ってそういうのがダメじゃん。

529: デフォルトの名無しさん [sage] 2011/10/12(水) 00:25:49.74
http://japan.cnet.com/news/service/35008825/

> 以下は、Dartの設計目標に関するBak氏の簡単な説明である。

> 　Dartは、1人のプログラマーによる、特に構造を意識しないプロジェクトから、
> コード内にプログラマーの意図を記述する為に定型が必要となる大規模プロジェクトまで、
> 広範囲にわたる開発作業を対象としている。Dartにはこのような広い範囲のプロジェクトを
> サポートするためのオプションが用意されている。

> つまり、プログラマーは型を定義せずにコードを記述し始めて、後で必要に応じて型を追加することができる。
> Dartは大規模なウェブアプリケーションの記述に非常に適したものになるとわれわれは考えている。


やっぱりそうか。先端的開発＝動的型か。

dartは型推論がなければ俺は絶賛した
ぎりぎりでストライクをはずれた
このおっさんはvarを取り入れたことを後悔すると思う
それでも現状でpython ruby javascriptよりも
圧倒的に上の言語だという評価はする

静的型検査なんてオプションでいいし、不完全でもいいと判断したわけだよね、Googleは。
どうせ実行してテストするからね。

>>544
varはDynamic型（どんな値を入れても静的型チェッカーが警告を出さない型）になるだけで
型推論するとは書いてない。

型検査を遅延評価

それただの動的型

Dartが静的型付けをサポートしたんで
動的型付け厨房が焦ってるなｗ

型は記述を必須にして評価はしなくてもいい
開発ツールと可読性向上のための必須コメントというポジション
varはこれを汚した、絶対に許さない

隣家の夫婦のセックス現場を盗撮するとかの斬新な機能は不要って事でしょう。

つまり静的型付け派には「静的型検査至上主義」派と「型注釈至上主義」派がいるわけだな
後者にとってはHaskellやMLの型推論もイケてないんだろう

世にあるプログラムのほとんどがC/C++である現実

C++11にはautoが入ったよ

>>549
ぬるぽのあるJavaでも満足出来る人にとっては
Dartのなんちゃって静的型チェックでも満足なんだろうね

　　　　　　　　　 |　|　ｶﾞｶﾞｶﾞｶﾞｶﾞｯ
　　　　　　　　　 |　|
　　　　　　　　　 人
　　　　 　 　 　 < 　>_∧∩
　　　　　　　　　 人｀Д´）/ ←>>68
　　　　 　 　 　 < 　>_∧∩
　　　　　　　　　 人｀Д´）/ ←>>91
　　∧＿∧　　 < 　>_∧∩
　 （　・∀・）　　 人｀Д´）/ ←>>323
　と　　　　）　　< 　>_∧∩
　　 Ｙ　/ノ 　 　.人｀Д´）/ ←>>323
　　　 /　）　 　 < 　>_∧∩
　 ＿/し'　／／. Ｖ｀Д´）/ ←>>555
　（＿フ彡　　　　　　　/

autoがなくても限定された型の中での型推論を式テンプレート使って行うテクニックは存在したよね

C++の関数テンプレートの型推論は最初感動したわ

gcc拡張文法OKならtypeof使でもいいし

Googleが型のない言語は大規模開発に対応出来ないと断言した。
この事実は重い。

わざわざ型推論なんて面倒なものを実装しなくても、
型無し言語と動的型言語の区別もつかない相手(>>560)なら
動的型+lintでころっと騙されてくれるとGoogleは考えたんだろうね

実際、Java PGの受け皿の予定だろうから馬鹿を騙せれば十分なわけだ

小梨は圧倒的に人間的に上だという評価をユーロと米国がする

動的型付けでもいまどき型推論で最適化ぐらいはするだろう

最適化しても大して速くならないか、もしくは最適化に途方もない時間がかかるか
好きな方選べ

型を書かなくても静的型チェックできるコード解析ツールすらあるのに、
optional typing で型チェック可能とか言われてもなぁ……

実用的じゃないツールを例にだされてもなぁ……

Pythonはマジでその辺が充実してる

そのツールがJavaScriptと互換性が無くて、やむをえず劣化コピーを作ったのかな。
いくら安全でも互換性がなければただの箱。

まあ、Pythonは外人が「Pythonにも静的型チェック欲しい」って言ってたりするからな
ニーズがあるからツールも揃うんだろう
同じ事をRubyで言ったら「動的型の理念とはうんぬん……」とか怒られそうだし

>>569
あるあるw

Pythonは何でもはっきりきっちり書く文化だもんな
大規模なプロジェクトだと静的型で書いてるのと変わらんようなのが多い

Dartのoptional typingって、Pythonのtype annotationと比べて何が優れているの？

大体似たようなもんだろ

開発者は言語仕様ばかりに目を向けすぎてる
もっと開発ツールに目を向けて欲しい
auto a=f.create()
こういうのを何度も見てきたから型推論まじむかつく
そんなに二回書くのが嫌なら
int a=new(1)
とでもやって左は省略しないで欲しいものだ

型の宣言がなかったら局所的に見ても、型がわからないからめんどくさい
そういうのに限ってツールが動かないし
言語仕様の拡張で効率を上げる時代は終わったよ
これからは開発ツールで効率を上げる時代
開発ツールを作りやすい言語が生き残る

そのための型だよ

>>574
お前の環境なんて知らないよ
型推論が適切に使われてないと感じてるなら、お前のチームの
コーディング規約をなんとかしろ

ていうか、型を二回書くのが嫌なんじゃなくて、型を書くのがいやなんです
だけど静的型付けのメリットは享受したいんです
型推論マンセー

>>574
>これからは開発ツールで効率を上げる時代
>開発ツールを作りやすい言語が生き残る

つまり Smalltalk最強、ということですね
1980年代から統合化開発環境の進化は停滞しているな....

>>576
そんなのベンダ側の思惑か、そういうのに慣らされてるだけだろ
型計算できちゃうほどのバリバリ高コスト型推論派とかRTTIイラネ派が
ツール作れないという理由で隅に追いやられてる

慣らされているは思考停止、または甘え
普及か需要を得からはじめてただの愚痴から昇格可能

動的型付け言語のプロジェクトに参加させられると
猿になった気分になる

インタプリタ言語がなぜ型を導入しないか
実際に作ればわかる、型を使わないで動くものができるから
interfaceに関しても同じ、型がなくても動くから
ない方が楽に実装できる
つまりまともに設計せずに実装しながら適当に仕様を決めたら
今のメジャーなスクリプト言語の出来上がり
インタプリタにとって型は動作に必要ないコメントだが
型はプログラムに意味を与える最重要なコメントでもある
それを省略してすばらしいなんてなるわけがない
人や開発ツールのために型は強制すべきだった

>>574
テンプレートはどうするの？
template <typename T> ... T a = T::create(); ...
この T が何なのか、型がわからないからめんどくさいというのか

>>574
> int a=new(1)

動的型と静的型の区別がつくようになってから出直してこい

>>581
プリミティブ型を捨てて
int float stringなんかはinterfaceにする
interface int
class int8:int
みたいなので十分
int n=new int8(123)
シンタックスシュガーとして
int n=123
となればいいだけ
弱い型付けでキャストなしにすればダウンキャストは無視できる

俺から見て難読すぎるテンプレートライブラリは最悪のモンスターだった
可読性を落としてツールにやさしくない便利な機能よりも
#defineの方がましだった

ちなみに高速化は並列でやる時代
遅いならOpenCL使えばいい
高速化を目的としてテンプレート使ってる人は考え直すべき
時代が変わった

へー、型推論や多相型を無くすかわりに型付け弱くするのか？
明らかに安全性とは逆の方向性だなw

つーか、型注釈の有無は静的型/動的型と関係ねーだろ
馬鹿じゃないの？

安全はツールで確保
ツールを作りやすくするための型
つまり安全性を後付で拡張できる言語仕様を超えた安全性

安全性には価値があるけど静的型や動的型の区別なんてどうでもいいよ
頭が固いんじゃないの
人格否定や挑発ばかりやってるとバカになるよ

おまえをみてるとどうやらそれは正しいらしいな

自分が書き込むスレのタイトルくらいは読んだほうが良い

ツール使わずともアノテーションなりメタデータなりでいくらでも拡張可能だし
コンパイル時間を気にしなければTMPのような型計算で静的チェックは可能
そのほうがポータビリティもあるんじゃないか？
ツールで処理すべきなのはちょっと厳しい環境向けだと思うね
たとえばSTLのイテレータのトロさが問題になるケースとか

>>583
時代が変わるというなら、自然言語を早くなんとかしないと。
自然言語は野放しにしているくせに、
プログラムの構文を「最悪のモンスター」という、そういう暴言をやめさせるのが先だ。

Netbeans使っていると型を意識した補完をしてくれるんだな。
動的言語・静的言語の違いよりも、
IDEで開発するかエディタで開発するかの違いが大きいと思う。

Anders HejlsbergがC#で作ったコンポーネントをJavaScriptからシームレスに使えるというデモで
VSがコンポーネントの型情報を使ってJSで完璧なインテリセンスを実現してるのを、静的型のパワーだ
と言って笑いを取ってた

>>591
いつのデモだか知らないけど、MSのJSはずっと昔からIDispatchExだし、JSへの公開もIDispatchを必要とする。
.NetのObject型である「_Object」型もQIでIDispatchとれるし、IDispatchからITypeInfoとって補完なんていうのはクラシックVBのテクノロジ。
いまさらドヤ顔でやるようなデモじゃない気がする。

http://channel9.msdn.com/events/BUILD/BUILD2011/TOOL-816T
これかな
技術というより言語とIDEの宣伝

早くなんとかしないと。

それが技術じゃなくてなんなんだ

なんかMSの技術ってここ10年本質的に進歩してないような気がする
.Netに見るべきところがあるとすれば、部分信頼モデルくらいじゃない？

と言って独身家事無能かつ無職で笑いを取ってた

>>596
本質的に進歩した技術ってこの世に有ったっけ

「本質」だなんて無定義語は、「ぼくのかんがえたさいきょうの」と置き換えても意味は同じだな。

本質って言葉はバズワードって言葉ができる前からバズワード

本質を抽象する

もし「抽象」が無定義語でなければ
抽象するモノ (目的語) のことを本質と定義できる

Dartに比べたら>>593のasyncの方がよっぽど先進的だわ

快適にプログラミングできるなら
本質的な進歩でなくてもいい

計算可能性だったらたいていのものはみんな同じだしな

型を書くのを省略できるのは
快適なプログラミングへの第一歩

型を省いてもIDEの補完がお馬鹿さんにならないのであれば考えても良い。

（会社のPCの壁紙を見て）
早くなんとかしないと。

変数の型とオブジェクトの型が二つあるのややこしいやん
静的型付けも構造的部分型が主流になればいいのに

動的型付けはデメリットが大きすぎる

>>576
> ていうか、型を二回書くのが嫌なんじゃなくて、型を書くのがいやなんです

初めて聞く意見だな。
二回書くのが嫌だとばかり思っていたが。

所で聞きたいのだが、型を書かないで
どうやって特定の型のオブジェクトを生成するんだい？

> auto a=f.create()

これは一度も型を書いてないよね

でも、createの中で書いてるでしょ。

型は値の範囲()
型はドキュメント()
型は仕様()

パラメトリシ(笑)

>>612
createが返すのが例えばクロージャだったら？
中で型を書いてるとは限らんだろ

ソフトウェアがクロージャだけで作れるのならそれでもいいが、
クロージャ以外だと型書いてるでしょ。

つーか、クラスを定義しなくても直接オブジェクトを生成できる言語も在るじゃん

>>608
完全に同意

そこでconceptですよ

型宣言厨はJava以外の言語も触った方がいい。マジで

diamond operatorとかセンスなさすぎてもう

(笑)

簡潔なコードと冗長なコードの例
http://queue.acm.org/detail.cfm?id=2038036

IDEの補完程度では言語の差を埋められないのが良くわかる

テンプレートとかジェネリックを除けば
型書くのは苦というほどめんどくさくはないな。
メリットも大きいし、書いたほうがいい。

動的型のメリットは小さく、型推論は重い。

コボラーがCOBOLを「書くの面倒じゃないし、読みやすい」って言うのと一緒だね

> 型推論は重い。

何が重いの？コンパイル？時間計って比較したの？

（一行いくらで単価計算される土方仕事では行数が稼げるから）メリットも大きいし、（型を）書いたほうがいい。

ドカタ仕事だとロリロリなようじょの顔見れるからドカタ仕事のほうがいいよ。

>>626
動的言語の最適化時の型推論と
束縛時やマッチング時の型推論じゃまったく意味が違うからな
どっちの話してるのかよくわからんが一般に前者は軽くて後者は重いだろうな

何言ってんだろこいつ
型書かない方が文字数少なくて済んで、行数稼げるだろ

型オンリーで50行とか普通にあるよ。

強い静的型を持つ言語では型レベルプログラミングが熱い

強い動的型を持つ言語では何が熱いの？

対応するとすればrubyでmethod_missingにフックをかけて滅茶苦茶な事する手法かな
確かsmalltalkでも似たようなものがあったと思う

コンパイラをインタプリタにしちゃうんだよ

>>632
強力なチェックをかいくぐる抜け道を作ってるだけだったりして。
そんな政治的なプログラミングは嫌だ。

型は宇宙

>>636
自分が理解出来ないことイコール危険なこと、ですか？
プライドばかり高くて頭悪い人に多いタイプですね。

注釈としての型・チェック機構としての型システムという捉え方と
計算基盤としての型システムという捉え方がある

今さ、Perlで書かれた糞コードの修正をするという苦行をしてるんだけどさ
関数の引数がハッシュになっているのはまあ許すとしても、
そのハッシュのキーが文字列になってるのってなんなの？

たとえば、こんなの。ハイフンで始まっている文字列。
http://www.futomi.com/lecture/form/cgi-pm.html#s4
> print $q->header(-type=>'image/gif',
> -nph=>1,
> -status=>'402 Payment required',
> -expires=>'+3d',
> -cookie=>$cookie,
> -charset=>'utf-7',
> -attachment=>'foo.gif',
> -Cost=>'$2.00');


なんで定数にしないの？これってPerlの文化？
まさか動的型付け言語って全部こんなんじゃないよね。

キーが不定のものなら仕方ないけど、固定で決まっているようなものを
文字列で指定するのって開発効率下がってしょうがないんだけど。

興味あるだろうから先に言っておく、
俺はJava土方（笑）だから。

説得力ある答えを求む。

フィールドの頭にアンダーバー付けるようなもんで
何らかのオブジェクトのメンバというのを明示的に書いてるんだろう
結局静的型に戻ってきてるんだな
ただ頭にアンダーバー付けるようなのって静的型でもあんまりよくないスタイルだよなぁ
C++のような言語じゃ規格違反になる場合もあるし

チーフに鼻フックをかけて鬼畜眼鏡で滅茶苦茶な事するかな

>>641
頭のアンダーバーは本質的なところじゃないよ。
両方共文字列扱い。

use strictだかuse warningsだかすると、
アンダーバーがない場合は、
文字列を "" でくくらないでそのまま書くなっていう警告が出る。
アンダーバーつけてればその警告を抑制できるだけ。

header関数の中では両方共文字列として渡される。

ってか、つられてアンダーバーって書いたけど
ハイフンなｗ

>>640
固定で決まっているって、なんでわかるの
じつは固定ではない可能性を想定するほうが安全じゃないの

Perlにはキーワード引数が無いからハッシュで真似してるだけじゃね

>>645
> 固定で決まっているって、なんでわかるの
ソースコード見たから。

ソースコードにもご丁寧に、”文字列で”書いてあるよｗ

ｗｗｗｗ

キーワード引数やオプション引数そのものを批判してるのか、
上記の機能をハッシュでエミュレートしてるのを批判してるのか、
ハッシュのキーにmutableオブジェクトを使ってるのを批判してるのか、
あるいはそれ以外なのかが分からない

>>646
じゃあ、他の動的型付け言語なら大丈夫なんですかね。
ハッシュばかり使ってある糞コードながめて、
おいおい、このハッシュ、どんなキーが入ることがあるんだよって、
うんざりすることはないんですかね。

俺はプログラミングをしているのであって
コーダー的な作業に神経を使いたくないのよ。

だから本質的な作業ではないところ（コーディング）で発生するミス、
つまりスペルミスも検出できないようなコーディングスタイルは
大嫌いなんだよね。

>>649

>>650で書いたとおり

Pythonはキーワード引数がある
Rubyはキーワード引数は無くてハッシュ
PHPは知らない

Rubyオワタ＼(^o^)／

>>640
ハッシュに見えて、実は配列で渡される。
で、key,valueの組と単引数を区別するための識別に使うんじゃないかな。推測だけど。

>>650
-hogehoge => 'wowow!!',
を加えると、wowow!!っつー内容のhogehogeヘッダが追加されるよ。

>>650
公平を期するために言うと上の方にも書かれているようにこれは動的言語の問題と
いうよりも名前付き引数を持たない言語で同様のことを模倣した場合の問題だよね。

ただ憤りはよく解る。多分動的言語には無駄にハッシュリテラルを簡単に書ける
言語が多いという点がミソで、そういう言語では無駄にこの手の記述が多用される
ことが多い。jQueryみたいにこの書き方が作法になっているフレームワークも多いし。
APIリファレンスからキー文字列を忠実にコピペする必要があるのは確かに面倒。

逆に簡単に書けないJavaとかだとオブジェクト生成時のbuilderパターンみたいな
手間が必要なのも何とも。

>>640なコードをJavaで書く場合、キーワード引数やデフォルト引数が無いかわりに

q.header().with_type("image/gif").with_nph(1).with_status("402 Payment required");

のようなインターフェースを用意するのが一部で流行と聞いた

>>654
> ハッシュに見えて、実は配列で渡される。
> で、key,valueの組と単引数を区別するための識別に使うんじゃないかな。推測だけど。
うん、そういう使い方をしているものもあるのは知ってる。
ただ、それは定数にしない理由にはなっていない。

> を加えると、wowow!!っつー内容のhogehogeヘッダが追加されるよ。
それは別にそれでいいんだよ。
固定で決まっているものは定数にしとけって話だから。

>>656
そうそう。

>>655
命名規則にとらわれず、似せて書けば

> print $q->header(-type=>'image/gif',
> -nph=>1,
> -status=>'402 Payment required',
> -expires=>'+3d',
> -cookie=>$cookie,
> -charset=>'utf-7',
> -attachment=>'foo.gif',
> -Cost=>'$2.00');
これも

q.header().type("image/gif").
nph(1).
status.("402 Payment required").
expires("+3d").
cookie(cookie).
charset("utf-7").
attachment("foo.gf").
extra("Cost","$2.00").print();

こっちも大差ないでしょ？
くだらないミスで時間を取られることもない。

>プライドばかり高くて頭悪い人に多いタイプですね。
反論できなくなったら人格攻撃に走るのは
敗北を認めたことになりますよ
プライドばかり高くて頭悪い人に多いタイプですね。

>>640
PerlのCGI.pmってのは、MosaicやCERN httpdみたいに
World Wide Web(WWW)の創成期に作られたコードだから、
今時のモダンなコーディングスタイル基準で批判されるのはカワイソス
WebのCGIを手軽にスクリプティングできる唯一で画期的な存在だったのサ

当時のPerlは文字列処理に特化したシンプルな言語だったから、
明示的な直積型(Cの構造体やOOPLのクラス)に相当するデータ型は無くて、
代わりにハッシュを使って直和構造を表現するのが普通だった

今時そんな古いコード設計の保守をやるのが苦行というのは同情する
おそらく今のPHP/Railsのコードも何年かしたら同じように非難されるんだろう

>>658
なるほどね。
メソッド名を間違えても実行時にしかエラー検出できないけど、確実性は増す。

>>660
Perlでモダンなやり方だとどうなるんだ？

>>661
Javaのコードのつもりで書いたんだけどｗ
もちろんメソッド名を間違えたらコンパイルエラーでますよ。

>>658
名前付き引数がある言語なら

q.header(type = "image/gif", nph= 1, status = "402 Payment required",
　　　　 expires = "+3d", cookie = cookie, charset = "utf-7",
　　　　 attachment = "foo.gf", extra = {"Cost" => "$2.00"});

みたいなみたいな感じかな。大切なのは記法の違いじゃなくて、キー文字列を
間違えてもコンパイル時か最低でも呼び出し時にエラーではじかれること。

確かにメソッドチェインでパラメータ指定して云々、は安全なのだけれども、
実装が大きくなりがちなのが難点かな。
例えば>>658の下の書き方にしても、headerがimmutableなメソッドなので
あればheaderはqそのものではなくてその後のメソッドチェインで入力された
値を保持する専用のオブジェクトを返す必要があるよね。
そういうオブジェクトのクラスをoptionalな引数の多いメソッドごとに用意する
必要があるわけでこれはこれで面倒。

> みたいなみたいな感じかな。大切なのは記法の違いじゃなくて、キー文字列を
> 間違えてもコンパイル時か最低でも呼び出し時にエラーではじかれること。

そうそう。ハッシュと同じでメソッドも同じでコンパイル時に弾かれて欲しい。
ただし実行時は遅すぎる。
それが出来る言語なら何でもいいよ。

最初に定義する必要があるとか、そんなのは一回書けば済む話なので
面倒だとは思わない。

普通は定義されたものを”使う方”が複数回あるわけで
なんどもタイプしてると絶対ミスる。

そこでIDEやパラメータヒントツールの登場ですよ
引数部分が全部マジックナンバーでtoString可能なら
その一文だけ実行してフォーマット済み文字列を見ることも可能

でそうやって、高度な機能を追い求めると
静的型付け言語に分があるんだよな。

実行しないでも分かる＝コードを書いているときに分かる だから。

もしかしてコーディング=製造の人か

Perlでモダンに書くなら、Mooseを使う。MooseはPerl6のOOP機構をPerl5に導入するもので、静的に型を指定する事が可能になる。
ただ、Mooseは重いんで、そこまでの高機能でなくて良いなら、Smart::Argsとかの引数バリデーションモジュールを使う。この手のモジュール使うと、やっぱり型指定出来るようになる。

ただ、名前付き引数は欲しい機能だよね。Perl6にはある。

>>662
うん、Perlに置き換えたらの話。

一応Class::Structモジュールが古くから標準で入ってる。
モダンにやるならMooseだろうね。

>>641
>>643
先頭にー（ハイフン）を付けるのは、連想配列のキーが文字列であることを表すため。
Perlは関数の（）を省略出来て、連想配列のキーは文字列であっても引用符でくるまなくてもよいので、fooだと関数なのか文字列なのか分からない。
use strictは変数宣言を強制するのに使う。別の話。

俺らはプログラミングをやってるのであって
コーディングをしているわけじゃないからね。

だからこそコーディングの手間は極力減らすという考えにたどり着く。
そのための静的型付け言語。

コーディングに高度な機能を求めるのは、
コーディングが大好きだからじゃなくて
コーディングを極力無くしたいからなんだよ。
勘違いしないでよね。

ああやっぱりプログラミング=設計という考え方を盛大に勘違いしている人か

>>672-674
俺が書くのもなんだけど
40秒でレス返すってどんだけ張り付いてるんだよ

>>674
へぇ、なにか意見があるのかい？
なら言ってみたら。

>>672
コーディングの手間を減らしたいなら
名前付き引数を持ってる言語を使うべきじゃないか？
言語組み込みの機能は良くテストされてるが、
>>658のような方法は手間がかかるだけでなく
そこにバグが潜む可能性がある

>>677
良くテストされたライブラリのAPIとしては>>658の方法も十分にOK。
というか山ほどある。

コーディングの手間だけで使う言語を選べるのであればどれほど楽か。

つまり自分では名前付き引数を持つメソッドを書かず、
他所様の書いたライブラリを使うのみってこと？

> コーディングの手間だけで使う言語を選べるのであればどれほど楽か。
静的型検査の有無だけで使う言語を選べるのであればどれほど楽か。

ああやっぱり勘違いしている人か

ていうか、理論上は「変数」に型がなくても「文字列リテラル」は静的に解析できる。
リテラルは変数よりも情報が多いので、変数ばかり解析しているのは勿体ない。

>>677
> コーディングの手間を減らしたいなら
> 名前付き引数を持ってる言語を使うべきじゃないか？

そりゃそうだろうｗ
だから静的型付け言語を使うべきになるんだよ。

理論上は、というか普通のまともな処理系なら文字列リテラルも変数の名前もハッシュ値になるでしょ

メタプログラミングを実行時にばっかりに頼る傾向にあるのが間違い。
Perlのコンパイルフェーズに処理を実行できる仕組みをみなすべき。

コンパイル時メタプログラミングを採用すれば、
実行時メタプログラミングの必要性は9割減ると思っている。

弟の部屋以外に視野角固定できますよーに

動的型言語にも名前付き引数あるし…

>>658のような方法は面倒なだけだと俺も思う。
その言語に名前付き引数機能があればベストだけど、無くてもそのメソッド内で引数のハッシュをバリデーションすれば良い。
その時にPerlならParams::ValidateとかSmart::Argsとか使えば比較的簡単にバリデーションできる。

>>687
ただし、それらは実行時にならないとわからないのが問題。

実行時にならないとわからないのと
実行前にわかるのとでは、大きな差がある。

まぁこのスレは敷居が高いから底辺ｘ高さ÷2がないと無理

ようするにjson投げてるようなもんだろ

ハッシュで渡す場合省略可能な引数でなおかつその引数名をタイポで間違えたら
実行時にもエラーでなくて動かして想定と違う動きして初めて分かるとかあるんじゃ？

>>688
一度も実行されてないコードをリリースするの？

>>692
なんでいきなりそんな話になるの？

アメリカにつくのであれば、
早くても遅くても交通手段は関係ないという発想の人？

>>691
typoした瞬間に気付けよ
それは早すぎる？
でも実行時は遅すぎるんだろ
中間層は上にも下にも敵がいるから大変だぞ

だって、テストコードすら書かなくても、一度実行しさえすれば
動的型言語でも名前付き引数のエラーくらい分かるぜ？

動的型言語はコンパイル必要無いんだから、
コンパイルするかわりに実行してみりゃいいじゃん
手間一緒

>>695
だから、それはアメリカにつくのであれば（エラーが解るのであれば）
それが早くても遅くても関係ない人の発想だねって言ってるの。

>>696
何で早さに差がでると思ったの？

サンプルコードみたいな、ほんの数行のコードであれば
実行すればいいですむかもしれんが、

何千、何万、何十万とあるプロジェクトでは
実行してみるのも大変なんだよ。
だから、簡単に実行できる手段を追い求める。
実行しなくてもわかればなおよし。

根本的に作っているもののスケールが違うんだよね。

え？ユニットテストって一部だけ実行できるんだぜ？知らないの？

リグレッションテスト？なにそれおいしいの？みたいな会話でちょっと怖いぞ。

>>697
早さに差が出ると思ったのではなく
実際に早さに差が出ている。

競争してみるか？
20行ぐらいのコードを書いて、書いてる途中にわざとタイポいれて
（わざとタイポ入れるが、入れたことに気づかないふりをする）

お前は実行してから分かる方法、
俺は書きながらリアルタイムにタイポを検出してくれる方法

どちらが早く修正できるか。

さあ、ここで静的チェッカーで名前付き引数のエラーが分かる動的型言語Pythonさんの参上

>>701
Javaで20行なら動的型言語では5行くらいになるが……

>>699
> え？ユニットテストって一部だけ実行できるんだぜ？知らないの？

できないよ。

まずそれなりのスケールがあるプロジェクトではな、
ユニットテストを実行できる最小限のクラス、その中に複数のテストコードが含まれる。
数が大きければ、テストにも時間がかかる。そしてその中の一部を実行することはできない。
だいたい何個もあるのに、その中の一つを選ぶとかめんどくさすぎるｗ

そしてそれら実行した所で、エラーになったことはわかるが、
なにが原因でエラーになったかは教えてくれない。

ユニットテストを使うにしろ、その問題を解決するのは大変なんだよ。
ユニットテストよりも先に解決できるなら、そっちの方が時間がかからない。

>>703
> Javaで20行なら動的型言語では5行くらいになるが……
それもならない。

Javaだとオーバーヘッドの分、つまりクラス定義だとか
そんなコードが＋αされるが、実際関数の中身なんて大差ない。

>>704
え？お前んとこのユニットテストはモックやスタブを使ってないの？

>>706
話理解できてる？ｗ

クラスを単体でテストするという話じゃなくて
テストの一部を実行するって話だろｗ

あぁ、一つのクラスのテストに
大量にテストコードがあるという
規模を想定できないかｗ

>>707
ある特定のクラスの特定のメソッドをテストする特定のテストメソッドだけを
呼び出す事も簡単に出来るが……？

動的型付け言語だとインタプリタな言語多いからな
テストがお手軽なのは動的型付け言語という事になってしまうな

>>708
だから、発想ができる（アメリカにつく）のなら
それまでにかかる時間を無視してるとｗ

競争してみるか？
20行ぐらいのコードを書いて、書いてる途中にわざとタイポいれて
（わざとタイポ入れるが、入れたことに気づかないふりをする）

お前は実行してから分かる方法、
俺は書きながらリアルタイムにタイポを検出してくれる方法

どちらが早く修正できるか。

>>710
え？動的型言語ではIDE/エディタ禁止？

つーか、競争ってどうやんの？w

20行ぐらいのコードなら、ちょうどここ>>271にあるじゃない

静的型付けで一応の型推論がありDbCのサポートがありユニットテストが言語組み込みの
Dが最強ということでよろしいか

なんか「アメリカ、アメリカ」言ってる奴から
ほのかなウォーターフォールオンリー臭を感じる。

>>676
このスレとは関係無いけど
ネット上でよく見るプログラミング=設計という主張は普通はコーディングを含めてプログラミングと言ってるからな
「プログラミングとは設計書をコードに起こす作業であって誰でも出来る」っていう考え方への反論みたいなもんだから

>>710
おまえま>>367を百回音読しろ

動的型言語はアノテーションてんこ盛りで強いテストすればいいし
静的型言語は型計算と静的解析ツールとアサーションだな俺の場合は
型うんぬんより、用件に対してふさわしくない言語や処理系使うのが一番危険だ

動的型付け・・・小規模開発向け
静的型付け・・・大規模開発向け

テストしこしこ作ってるとき、これ静的言語に書き直したほうが早いんじゃないのと思ったら負け

つーか、女子と競争ってどうやんの？wｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>720
ここは静的型付け言語だからってテスト書かないようなプログラマの来るスレじゃないよ
テストの無いプログラムが安全なんて言えないからね

テストは書く前提で、それでも両者のどちらが安全性/生産性が高いかで論争してる

動的型付け・・・若者向け
静的型付け・・・高齢者向け

いや寄る年波には勝てずメソッド名とかも頻繁に忘れがちになったし
長いキー入力もしんどいのでIDEがより的確にメソッド名一覧を表示
したり補完したり出来る静的型の方がなんというか、優しい。

wikipediを見ると、

＞安全でない弱い静的型付け
＞宣言型の安全でない強い静的型付け

みたいな表記があるんだけど、
安全であるないとか、強い弱いとかってどういうこと？

>>723
そりゃなぁｗ

メソッドを覚えるとか、キーを入力するとか
そんなのはコーダーの仕事であって
プログラマの仕事じゃねぇからな。

コンピュータでできることを
人間が努力してやるなんて流行らないよ。

>>722
> テストは書く前提で、それでも両者のどちらが安全性/生産性が高いかで論争してる

テストは書く前提というけどさ、
そのテストは完璧であるという前提なの？

今まで人生で完璧なテストなんて見たこと無いんだけど。
（もしそんなのがあれば、バグがないソフトがあるということになる）

>>726
そういう前提を置いたつもりは無いよ
だからテストでカバーしきれない静的型検査の安全性を主張してもいいと思う
というか、俺は静的型言語の方が好きだし

でもテスト自体は書くだろと

ttp://livedoor.2.blogimg.jp/hatima/imgs/6/a/6ab0f506.jpg

> コンピュータでできることを
> 人間が努力してやるなんて流行らないよ。

だから型推論のある言語が良いってことじゃん
コンピュータが推論できるのに人間が型書くなんてアホすぎ
型情報が必要ならコンパイラにでも出力させとけ

>>729
型推論って、静的型付け言語の機能だってわかってる？

変数に型がない言語だと実行時の型を
使うだけだから推論する必要ないよね。

Haskellが最強ってことだよ言わせんな恥ずかしい

おっと型推論もない巷の諸々の動的型付け言語をDisるのはそこまでだ。

型があるのが嫌なのと、
型はあって欲しいが、書くのが面倒だってのは
全く別の話。

書くのは面倒だが、型が欲しい。　なら推論だ！
これが型推論の本質。

ま、HaskellやOCamlが使えるなら
大規模なプログラムを動的型言語で組む理由は無いな

つまりC#最強って事か。

それは無い

　　 ./　　　　　　　　　　　　,,,,;;::'''''　ヽ
　　/　　 　,,,,;;:::::::::::::::　 　 　　　__　　 ヽ
　　|　　　. 　＿＿ 　　 　　 '＜'●,　　 |
　　|.　 　'"-ゞ,●＞　.:: 　 　 　　 　 　 |
　　|　　 　　　　　　　　::: :⌒ 、 　 　　 |
　　ヽ.　　　　　　;ゝ(　,-､ ,:‐､） 　　　　 | 　
　　　l..　　　　 　　　 　 　| 　|　　 　　　| 　じゃかまっしゃ！深夜騒音
　　　|　　 　　　　　__,-'ﾆ|　 |ヽ_　　 　 | 　　クズおんなが女子刑務所行く
　　　 ヽ:　　　　 　　 ヾﾆ| 　|ン"　 　 /＿＿　　までやるで！
　　　　.ヽ:　　　　　　　　|　 l, へ　　　　　 ::::ヽ,
　　　 　l.:`. 　 　 　 　　/　／　 , ＼ 　/ヽ　　::＼
　　　　 `､::::: 　　　　 　|　　　￣￣＼/　ﾉ 　　 :::ヽ
　　　　　 |::::::　　　 　　|　 　 　 ー‐/　/　　

　









　

Java とか C++ とか， ダイナミックキャスト的な機能を
持ってるだけで静的型言語と言えなくなる気がするんだ

>>739
そうだよ。今はもう静的言語なんて存在しない。
静的型付け言語はあるけどね。

つまりgo最強ってことか

ま、Javaでデザインパターンとかすると圧倒的に冗長なので、
それで静的型付けに悪い印象をもっちゃうんだろうけど
静的型付け = Java じゃないからな

>>739
オブジェクトの型はキャストするが、メソッドの型をキャストする事はない。
型推論なら関数の型は自動的に決まるが、データコンストラクタは手で書く。
つまりデータは動的にしてアルゴリズムは静的にすればよさそうだ。

>>742
弱い静的型付け or ナンチャッテ静的型付け = Java/C++

parametric polymorphism で良かったりしない？ > データは動的にしてアルゴリズムは静的

最近、オブジェクト指向というモノについて懐疑的になりつつあるんだけど、
継承(inheritance)を含む型システムについて明解な解はあるのかな？
自分なりにあれこれ調べてるけど、MLやHaskellの型推論の基礎になっている
型システムでは、いわゆるSmalltalkから始まる
「オブジェクト指向を形式的に定義」
できていないのが現実じゃないかと思っている。

# だからOCamlのO(Object-oriented)の部分は歪んでいるし、
# JavaではNullPointerExceptionでC++ではSegmentation faultが起きる。
# かといってHaskellの純粋関数型パラダイムは(一般人には)とうてい受け入れがたい。

もし知っているヤシがいたら教えてくれ、いや教えておくんなさいまし、お願い!!
# キーワードやヒントだけでもいい、あとは自分で調べるから....

継承なんてただの型と型の間に成り立つ半順序関係だけど何か？

OCamlのOは（特に見た目的に）他の機能と浮いてるし、
モジュールがあるから殆ど使わないけど、
型システム（構造的部分型、列多相）は悪くないんじゃないの？

>>747
つうか、包含関係だな。

多重継承を許すなら、メソッドの探索順序をどうするかは考えなきゃいかん
メタクラスで探索順序をユーザ定義できるようにするか否かも

>>749
こういう言い回しのジョークがあるんだよ
有名なのはWadlerの「モナドなんてただの自己関手の圏におけるモノイド対象ですが何か？」

>>746
ヒント
class Left<a> implements Either<a,b>
class Right<b> implements Either<a,b>

>>747,749
それは理解していますけど(理解しているつもりだけど)、self.any_message という式で
selfのデータ型を推論できる型システムはあるのか？という疑問です

>>748
オリジナルのMLを引き継いだ型システムには何ら問題は無い、と見ています。
問題は後付けのOの部分で、これが「OOな関数型言語の設計」として破綻している、
言い換えると、OCamlの存在自身がOOと関数型の相性の悪さ(?)を証明している、という指摘です

>>750
単一継承ですら、形式的に定義されていないんじゃないかと(少なくとの自分の知る範囲では....)

>selfのデータ型を推論
単に型クラス、型インスタンスでできるように思えるけど

>>753
ちょっと興味があるから、どのように破綻してるのか説明して
例があると分かりやすいかも

あと単一継承の場合スーパークラスの方向へ遡って探索するだけじゃないの？

多重継承のように順序付けできないことがあるっての半順序たる所以なんだよな
十分形式化できてるじゃん

>>754
たぶん(自分を含めて)推論なんてできて当たり前だろって思うのが普通なんでしょうけど、
少なくともOCamlのOOPはメソッドを動的結合をするので、いわゆる method missing 例外が多発します。
だからそれがOCamlコミュニティでも(OCamlの)Oは敬遠されている理由のようです。(ここは推測ですが....)

自分としても、強い静的型付け言語であることを自称しているOCamlなんだから、
メソッド未定義みたいなミスは、コンパイル時に型エラーとして検出されるのが当然だと考えていました。
それが、現実には(現実のOCamlでは)型検査されない、言い換えると「型システムの破綻」という残念な現実があります。

そこから、OOと関数型の相性の悪さとか、OOPそのものへの疑念が始まっています。

>>757
どうやったらOCamlの型システムでmethod missing例外出せるの？
Objモジュール使うのは無しで

>>755
OCamlのOOPは(Smalltalkのように)メソッドを実行時に動的束縛します
でもこれって静的型付け言語としては違反じゃないの？という単純な疑問です
OOの型システムが形式に定義できているのなら、こんなことは起こりえないんじゃないかと思います

# OCamlはかじった程度なんで、初心者ゆえの誤解があるかもしれません
# もしもOCamlでOOPしても型検査は保証できるよ！という指摘があれば嬉しいです

なんでこう頭が硬いんだろうな。

100%完璧じゃないから使い物にならんとかさ。
別に完璧じゃなくても使えるだろ。よく考えてみろよ。

ちょっとぐらい、型付けがない部分があったからといって
型システムの破綻とまで大袈裟なことになるわけねーだろ。

別に俺らは、物理法則を定義する完璧な統一理論とか
目指しているわけじゃねーよ。

OCamlでOOPしても静的型検査されるよ
動的束縛だけど型が一致しないものは許されない
そこが duck typing と structural subtyping の違いだね

あと、動的に束縛するからといって、
型がないということにはならんからな。

動的に束縛された時、そこに絶対メソッドがあると保証される。
つまり変数に入れたときに、その型であることがちゃんと保証されてるなら

「動的に束縛される静的型付け言語」だ。

Class obj = getHogeHoge()

obj.foo()

例えばこれ、動的に束縛される。
つまりこれは動的言語だ。

だが、getHogeHogeはClass型、もしくはそれと互換性がある型を
返さないとコンパイルエラーになるのであれば、それは静的型付け言語だ。
（そうなっていないのであれば、動的型付け言語。）

動的に束縛されるからといって、動的型付けとは限らない。

というか、最近では静的言語なんてマイナーな分野。
現在使われてるほとんどの言語が動的言語だろう。

静的言語といえばCOBOLとかFORTRANとか古いBASICぐらいなもんだろ。

継承の関係に下限、つまりすべてのクラスを継承したものがいて
定義上そいつはあらゆるメソッドを持ってる
そのメソッドがmethod_missing例外を投げるという実装になってるだけ
型システムの上では全て上手いこといってる、ただそれが要求に沿うかってのは別問題だけども
そいつの名前は大抵NullとかBottomとか言うんだけど
で、こいつがいないとメソッドの解決が停止しないつまり存在しないメソッドを呼んだ時点で無限ループだ
そう考えると例外の方が幾分かマシじゃね？ｗ

＞なんでこう頭が硬いんだろうな。

にぎにぎ

>>762
>「動的に束縛される静的型付け言語」だ。
意味不明

>>767
型は静的に束縛されて、値(メソッド)は動的に束縛される。
JavaでもC++のvirtualでもそうだろ。

> 少なくともOCamlのOOPはメソッドを動的結合をするので、いわゆる method missing 例外が多発します。

恐ろしいデマだな……信じるやつがいたらどうするんだ

>>768
言い換えると、
「型宣言はコンパイル時に検査できるけど、値(の型)は実行時にならないと検査されない」
ということですね。
スレタイに沿って考えるに、そんなレベルで「静的型付け言語であれば安全なソフトを作れる」と主張するには
あまりに無理がありすぎじゃないかと....
いったい「動的に束縛される静的型付け言語」と「動的型付け言語」のどこに差があるのでせうか？

静的型付け言語に期待されるのは、(OOPを含めて)型エラーはコンパイル時(=実行前)にすべて検出できる、
というのが底辺プログラマの一般認識じゃないかと思っていますけど....

>>770
だから型エラーは静的に検出できるっていってるじゃん

値の型は実行時にしか決まらないけど、
その値の型はすべて静的に決まる変数型の部分型になってる
（だから型エラーは発生しない）というのが継承

あ、構造的部分型なら継承の必要は無いから、上のは
静的型OOPの性質ってことに訂正

>>770
> 静的型付け言語に期待されるのは、(OOPを含めて)型エラーはコンパイル時(=実行前)にすべて検出できる、
> というのが底辺プログラマの一般認識じゃないかと思っていますけど....

底辺プログラマってのはお前のことを指すのか？ｗ

>>770
> 「型宣言はコンパイル時に検査できるけど、値(の型)は実行時にならないと検査されない」
> ということですね。
違う。

値の型は静的に検査できる。これは単純に型が決まるという意味ではなく
”互換性がある”型に決まるという意味。

Interface i = getHogeHoge()

この場合、iの中に入る型は実行時に決まるが、
iという型と互換性がある型であることは決まる。
これもまた、静的型付け言語において、静的に型付けされた状態。

そして、型は静的に型付けされているが、
そこに値が入るのは実行時であるため動的言語。

>>764
え、c/c++とjavaは。。。

>>776
動的な静的型付け言語ですが？

C++だって仮想メンバ関数(Java的に言うとメソッド)は実際にオブジェクト(Java的に言うとインスタンス)が生成されるまでどのクラスのメンバ関数を呼ぶのか不定だしなぁ

ただしC++やJavaの静的型チェックはうんこですけどね

JavaやC#の参照型が全てnullを許容する仕様は頂けないな

CやC++に関しては、用途を考えると仕方ないんじゃないの
メモリには（少なくとも一般には）型を示すタグやラベルなんてついてないし
ただのバイト列と見做せる空間に過ぎない
メモリを直接相手にするようなプログラムを書くのに使われる言語がCなわけだから
void *, union, キャストなどでお嬢様から見ればド汚いtype punningや
絶対番地アクセスみたいなことができないようではむしろ不自由する
C++はCと違って上品ぶって型安全性を喧伝してるけど、所詮もとはCだからな

ぬるぽ

>>780
Haskellでも、リスト型は全て空リストを許容する仕様になっている。
無限リストなら空リストは不要なのに。

無限リスト専用の型を定義することは一応できるけど
車輪の再発明と言われたくないのでみんな制約の弱いデータ構造を再利用している。

>>782
＞>>780
＞無限リストなら空リストは不要なのに。

「集合」ベースだって事を忘れないように。

空リストなんかより⊥をなんとかしてくれ

空リストの先頭要素へのアクセスは
現状のようにランタイムエラーで止まるのがいいか、
無限リストに永遠に待たされるのがいいか、
選択するがいい。

空リストの先頭要素へのアクセスなんて
パターンマッチ使ってたら書くこと無いだろ

定理証明系みたいな網羅することが強制されるような類の言語ならそういえるかもしれんが
少なくともCamlやHaskellじゃそれはない

パターンマッチが網羅的じゃなかったら警告出るから、
意図的に警告を無視しなければねーよ

JavaがRuby並みにランタイムエラーが出る言語だからって
HaskellやOCamlまで一緒にすんなよw

リスト使うなら空っぽかどうかのチェックしようぜ。
空っぽを許容しないならそういうデータ型を自前で用意しようぜ。

このスレはもうこれで 終わりにしよう。
次は
動的言語 VS 静的言語 バトルロイヤル
くらいにして 見たらいいよ。 LLバトルロイヤルはあるけど
煽り屋さんにはフレームスレは必要だろうよ。:p

いや、ここは元々が隔離スレなんだけど....

ここまでの流れ、Javaer/C#reが自分の無知をさらけだして
自滅しただけだし....

ということにしたいんですねｗ

俺、リアルではIT土方と接点無いから
土方の知識レベルが分かるこのスレは面白かった

まあ、小規模なプログラムとか個人開発なら型のないスクリプト言語もいいんじゃない？Googleもそういってる事だし。

ＭＳＷＯＲＤの話はもうこれで 終わりにしよう。

>>795
そっか、2ちゃんねるで世界を知ることができたんだねｗ

まぁ素直でカワイイんじゃないかなw

うん。底辺ってどんなもんか知りたかったから
大変ためになった。ありがとうw

2chは土方の本音が見えるしな

普段コミュ障の連中だから
リアルじゃ話しかけてもきょどってて話にならん

普段こいつらゴミが何を考えて生きているのか
それはネットをみないとわからない

>>221
> 2chは土方の本音が見えるしな
ほんとだ

> 221 名前：uy[sage] 投稿日：2011/10/01(土) 18:39:59.51
> 死ね　

ttp://hibari.2ch.net/test/read.cgi/tech/1248205502/829+834
> 829 名前：デフォルトの名無しさん[] 投稿日：2011/10/02(日) 08:44:21.80
> 　 法律でＣ言語の使用利用流通教育販売製造を禁じるべき時期にあると考える。
>
> 834 名前：uy[] 投稿日：2011/10/18(火) 11:16:09.93
> 　 >>829
> 　 同意
> 　（Ｃ言語なんかを使う） ゴミグラマは死ね　　死ねゴミグラマ

タチの悪いコテハンってこのスレで引き取っておいてくれよ。
そのほうがほかは幸せだわ。

つーか、名指しされたわけでもないのに
土方と言われて反応するのってどうよ？
自覚症状あるのかよ

土方以下だという自覚もなく土方を叩くクズを野放しにするってどうよ

まだ放射能が足りないってか

電波を出す能力のこと

case res of
>>803-807 -> Nothing
_ -> undefined

煽りじゃない動的型付けへの不満

・関数、メソッドの引数が型に応じた補完を受け付けない（以下例）
def f(self, x):
    self.foobar() # これは補完できるし、
    y = T()
    y.foobar()    # こっちも補完できるけど、
    x.foobar()    # これは補完できない

・カリー化の扱いが難しい
（引数の数を間違えたときに、予想外の場所でエラーが出て酷い事になる）


個人的にタイプミス補正は型の問題じゃないと思ってる（>>367に同意）

>>809
>・関数、メソッドの引数が型に応じた補完を受け付けない（以下例）

補完はもしもメソッド定義の仮引数に型宣言ができる構文があれば実現できるんじゃないかな？
たとえば Python 3系の関数アノーテーションみたいな構文。

# ただし現状のPython 3処理系が補完機能を実装しているか否かは別の話（言語の仕様と実装は別という意味）

>・カリー化の扱いが難しい

カリー化を基本とする関数型言語であればその主張は正しいと思うけど、
非カリー化な言語ではそもそもカリー化を前提としたプログラミング技法はほとんど使われない。
もちろんCの関数ポインタやSmalltalk/ObjC/Ruby等のブロックはあるけど、これらはカリー化されていない。
だからカリー化の扱いの難しさで比較するのは不公平に感じる。

>>810
たしかに、OOPではカリー化は問題にならず、逆に関数型では補完は殆ど問題にならない
だから、ひとつ目はOOPで書くときの、ふたつ目は関数型で書くときの不満と思って欲しい

そして指摘の通り、Python3やDartみたいなアノテーション構文で補完の問題は
原理的に解決できるけど、現時点では対応してないので不満がありますよ、と

Pythonみたいなダックタイプ言語で、型アノテーションをその手の用途に活用しようと
思ったら、実際どうするんだろ

たとえば
def add(x, y): return x + y
という関数があったとして、xやyの型をどう記述するかということなんだけど
xやyはたとえばintでもfloatでもcomplexでもstrでもlistでもいいよね
ダックタイピングだからそれらは特定の型やインタフェースを継承・実装したりも
してない

Addableみたいなannotation目的のダミークラスを捏造してそれを使うのか
それともある程度幅がある場合は何も書かないのか

必要なメソッド名のリストを書くとか？（dir関数の戻り値と同じ形式）

def add(x:['__add__'], y:['__add__']):
    return x + y

なるほど
毎回そういうの書けって言われたら嫌そうだけど
目的は達成できてるね

普通に静的型付け言語使った方がいいわ

ただし「動的に束縛される静的型付け言語(>>777)」を除く

動的型付けの言語って、IDEの補完あることはあるけど、関数の引数で型情報がないのもそうだし、
リストとか配列に入れた変数は型情報が消えるとか、メンバーフィールドに入れた変数は型情報が消えるとか、やっぱ無理がある。
それに型なんて意識しないでプログラムが書かれるんで、
function foo() {
　if (flag) {
　　return 0;
　} else {
　　return 'abc';
　}
}
↑こういうのが大量にある。そうすると、f = foo();で、fの型をIDEが推測出来るわけがない。

>>817
無能なIDEは処刑するしかない。

>>817
S式やJSON考えれば分かるけど、「何でもリスト」みたいなのは動的型だと普通だわな
ただJavaなんかもGenericsが導入される前は事実上何でもリストであるObjectコンテナと
キャストが多用されていたわけで

つまりそういう場合もキャストやパターンマッチみたいに型を確定させ明示する
方法があれば補完を機能させられるんじゃね
引数アノテーションだけでは足りないってことだな

ttp://www.fujitv.co.jp/anabang/photo/message_ph.jpg

なまものはちょっと。。。

>>817
行儀良く書いてれば、それらの補完は原理的に可能ではある（MLで型推論できるのと同じで）けど
実際に補完できるIDEが在るのかどうか……
メンバの型情報を使った補完だけなら可能なIDEはあるが

>>817の f = foo() の型は <int>|<str> であると考えられるので
<int>と<str>が共通で持つメソッドを補完できれば良い

>>819
JSON自体が、データが型情報を持っていると言う意味で、動的型だし。

>>818
こういう
「できること」と「できないこと」の区別すらつかねー奴って何？


お前が処刑されろよゴミカス

>>822
よくわからんけど、補完とMLの型推論って逆向きなのでは？

+使ってる→intだな、::使ってる→リストだな、みたいに
操作から対象の型をボトムアップに推論しているというか

補完って、逆に、ある対象に対してどういう操作が可能か
知りたいというトップダウンだと思うので、まず対象の型が何であるかを
確定させないとだめなんじゃね？

同じことなんだろうか？

>>826
関数引数に対して補完が働かないのはそのとおり
でも関数の戻り値に対しては型が確定する

型にはまり毎日のように挿入されたわけだ。

>>827
んなわきゃねえ
返り値が多相だったらどう確定させんだよ？

>>829
そうだね。確かに言い過ぎたw

動的型言語に型推論を追加して補完するなら
ついでに静的型チェックもしてくれ（完璧じゃなくて良いから）

足なんて飾りですといって、足がない状態で完璧を目指している人もいる
そう考えると、完璧じゃなくていいから足がある方が良いというのは残酷だね

例えがよくわからん。

泥棒対策で例えてくれないか？

鍵なんて飾りですといって、鍵がない状態で泥棒対策を目指している人もいる
そう考えると、泥棒対策にならなくてもいいから鍵がある方が良いというのは残酷だね

オレなら鍵を使いつつ完璧を目指すが・・・。

完璧を目指す？AqdaやCoqを使ってるのかい？

>>833
鈍感なやつが安全を語るな

>>835
もしかして定理証明器に夢見ちゃってる人？

OCamlの型推論部分は自明じゃないアルゴリズムを使ってて複雑なので
Coqで書き直したいという議論もあるそうな

型推論ってなんか、技術に走り過ぎな気がする。
そんな推論の限界を追求しなくても、
２回書く所を1回ですめば良い程度のもんでいいんじゃね？

>>839にとって型推論は 酸っぱいブドウ らすい....

なんだ。反論じゃないのか

> ２回書く所を1回ですめば良い程度

Java7のダイヤモンドオペレータの型推論がそんな感じ

>>839は(技術論じゃなくて)単なる感情論だからなぁ
本人がそれで良ければそんなもんでいいんじゃね？

>>842
Javaに無い機能はいらんってことか
>>840の言う通りじゃねーか

そんなのはどうでもよくて
反論が聞きたいんだが

いわゆる「IDEなんて要らない」と同じ話だろ？
そいつにとっては事実なんだろうからそれでいいよ

IDEはいらないと言っている人に、
IDEの機能単体をどう思うかを聞くと、
いらないなんて一言も言わないんだよな。

ソースコードなんて中学で一通り書いたし。

そうだね。ソの字が一番書くの難しいよね。
ちょっと油断すると、リになったりンになったり。

自分でIDEのようなツールを作ってみればいい
エディタからプロセス呼び出して位置とファイル名を渡して
それを解析してパラメータヒントやリファレンス結果をチップ表示するだけ
それを考え出すと型がない不便さがよくわかる、型推論に殺意が沸く
そして無理難題を突きつけられるIDEに同情するようになる
俺のIDEたんをいじめるなくそ言語開発者どもめ
こういう思想に染まる人が増えても不思議ではない
プログラマはIDEなしでは生きられないのよ

>>850
別にIDE作る仕事をしてるわけじゃないから問題ない

IDEを好む -> 土方
型推論を好む -> ハッカー

C++系の言語が梯子を外しそうなのが問題なので
もともと型推論してた言語は関係ない

型推論ってむしろIDE使ってる人の方が
メリットあると思うけど。
型省略しても、コード補完できるしね。

テキストエディタを使っていれば、
単に書くのを省略出来るだけでしょ？
省略した結果、コード追わないと型がわからなくなることもあるし。

それにしてもIDEを嫌う人って普段なにを使ってるんだろうね。
メモ帳？ｗ　高機能なテキストエディタを使っているとしたら
そのテキストエディタの機能とIDEって同じものなのにね。
ただIDEの方がより正確で便利なだけであって、

>>847
確かにな。
お前が要らないとしても、お前を構成するのと同じ元素が宇宙から消えたら困るのと一緒だな。

>>853
型推論（静的に推論する）と実行時の型をみるのとでは意味が違うぞ

>>855
それって、特定のIDEが嫌いなだけで、IDEが嫌いとは言わないんじゃ
俺もXCodeやEclipseは嫌いだがVisualStudioは好きだぞ

仕事退職して風俗嬢とおまんこしまくってきた。

挑発的だな
Visialなんちゃらが一番嫌われてるの

おっとVisualなんちゃらな

MS教徒なら、IDEは理解できるが。（あれのコンソールは・・・）
コンソールがもともと充実しているOSにはIDEってあまり重要ではないわな。
むしろ、起動のかったるさのほうが敬遠される原因じゃないかな。
メモリ食いというのもあるけど、そちらは今あまり影響がないしな。
動的言語でsnippetを書く程度でIDEを立ち上げたとしたら、それは仰々しい
だろうしな。もともとREPLがある言語対応がいまいちなものが多いし、
大抵本家じゃなくて第三者がプラグインを作ってる。Javaならいいのかも
しれんが、HaskellやOcamlでもEclipseプラグインはあるけどな。
lisp系+slime+emacsの域に達してるものはない印象かな。せいぜいR+ESS+emacs
程度の完成度があれば違うかもしれんが。あまりに小さくて１行にならない程度
のsnipet程度なら
$ cat > foo.rb
で済ませてしまう人も多そうなんだがな。IDEがいらない場合ってIDEが使いにく
いん言語を使ってる人が多いと思うよ。>>847
よく知らんのだけど、IDEの補完って、slimeのファジー補完みたいなのあるの？
型が型がと言う話は出てるけど、関数の引数情報などはslimeは出てきてるよ。
だから変数の名前を慣例に乗っ取って書いてる限り型を間違えることもないん
だよ。リストや配列、ハッシュなどの情報も含まれるので。
haskellの場合はghciで:eとすればエディタが起動するけどデフォルトでvimだ
からな。replとの組み合わせで考えてると思ったらいいんだけど、いわゆる土方
さんにそれが伝わるのか？わからん。replすら知らんかもしれんし。会話の接点
すら見つけられるかどうかわからんのよ。

CUI的な使い方を好む人なら
vim+screen+repl(ipython/irb/ghciなど)というパターンじゃないかな。
clojureでも同じような使い方ができるけど。あれはjavaの文化の言語だから
新規作成はleiningenというものを使ってプロジェクトを作成させてる。
IDEが不要だという考えの一つの解決法を示してると思うよ。scalaのsbtは
詳しくは知らないけど、同じようにIDE不要の解決方法なんだろうな。leiningen
はわかりやすかったけどsbtはleiningenほどではなかったように思う。こん
なことを書くとscalaの怖い兄ちゃんたちが暴れるかもしれんが。

ファジー補完：たとえば
m-v-b と打ってタブを押せっば、multiple-value-bind と補完してくれる。

ファジー補完：たとえば
m-v-b と打ってタブを押せっば、multiple-value-bind と補完してくれる。

ファジー補完：たとえば
m-v-b と打ってタブを押せっば、multiple-value-bind と補完してくれる。
このときemacsの下には(multiple-value-bind VARLIST VALUE-FORM &BODY BODY)
とでるの。これで必要な引数の型情報がわかってしまう仕組み

三回も書くとは余程大事なんだなw

>>865
ずいぶん時代錯誤なことをいっているようにしか見えない

ハッシュ引数ってわかりますか？

とっくのとっくに言語側で解決してる問題はIDE・エディタが介入しにこなくていいよ
言語側のダメさを補うのが役割なんだから


２０１１年に未だＣ・ＪＡＶＡなんて使ってるゴミグラマーは知らん

>>867
さっさと刑務所に帰れ

名前付き引数があろうがそこにどんな名前が使えるかを教えてくれる環境がある方が便利だろう

>>861
今時のいわゆるIDEって基本的にOOPL向きに特化してるし、上の流れで
念頭に置かれているのも、おそらくそうしたもの

この手のIDEでは、変数xがあるとき、
x.
とか打ち込むと、xのメンバがずらずら一覧で出てきたりするわけ
（メソッドの引数型とかは見れてあたりまえ）
これが出来るためには当然xのクラスなり型なりが静的に確定してなきゃいけなくて、
だから上のような話になっているんだろ

どうやらそんなことも分かっていなかったようだけど、
分かった上で俺はそんなものは要らないという話なら
チラシの裏にでも書いてくれないか

>>870
ここはチラシの裏だって。もっと高級なものだと勘違いしてたのか？
謎だな。Framerスレだけに、丁寧に不要なタイプの人の事情を書いて
”やった”のにな。

口だけ将軍さんよ。

話の流れも理解せずに的外れなこと言い出したと思ったら捨てゼリフかよ
さすがREPLとかSLIMEなんて言っても今の子わかんないよねーﾌﾌﾝとかLisperなだけで
大威張りな老害は一味違うわ

eclimみたいなのもあるんだから、IDEとエディタで
補完機能その他に差があるとは一概に言えない

インスタンスから型を手繰り寄せてメンバを補完する式のやり方は
（マルチメソッドでない、Javaみたいな）OOPL向きのやりかたなので、
使ってるのがその手の言語でなければあまり意味はないし役には立たんわな

まあCとかでも構造体に関しては変数からメンバを取れるので、一応この形式の
補完は使えるけど、有用性というか使用頻度はOOPLより低くなる

あとMSVCで言うとCtrl+Space打つとその時点で可視な名前（関数とか定数とか）の
リストが出て、名前の先頭数文字打って適切なところで確定、みたいなのは一応
出来るが、これは型情報関係ない補完だ

安全という観点では
IDEがないとコンパイラを動かせないとか、言語仕様に問題があってIDEが作れないとか
どこか一箇所に問題があるだけで全体が止まってしまうような仕組みは
あまり安全とは言えないように思える。

>>868
お前も一緒にくるんだよ

http://ja.wikipedia.org/wiki/Phalanger

>>875
＞IDEがないとコンパイラを動かせない
こういう製品は見たことがないな

>>859-860
msの開発者も使ってるだけ有って使い勝手良いのに？
(mfcは糞だが)

IDEがないとコンパイルする方法が分からないプログラマはいるだろうけど、
そういう話かな？
それをIDEの所為にするのは酷い話だが。

無責任だな
まあ後で無責任になるよりは最初から無責任なほうが良いね

入力や編集に特殊な環境が必要なテキストファイル、というのは珍しいものじゃない。
たとえば日本語テキストとかw

だがプログラマならCUI使えません、というのはちょっと困るよな、最低限の
コンピュータの知識として。

>>882
同意だが、流れと何か関係あるのかと

よくわからんがとにかく責任論は100%か0%の二択で考えるとトラブルが少なくなる。
つまり動的型付け言語もある意味合理的なんだよ。

なんだそのJohn Major's Equalityみたいな

試行錯誤しながらコード書くときの
REPLの便利さは異常

Eclipse 使えばスクラップブックがあるし

キーバインドが違うとか、自分が作った開発環境が良い、というのは好みの問題
メモリが足りないとか、CUIで動かないとか言うのは環境の問題
これらを省くとすればIDEを嫌う理由はないはずなんだが。

テキストエディタ＋αがIDEであって
テキストエディタに比べて何かが
できなくなってるわけじゃないんだからさ。

IDEに反対している人ってのは、IDEを使うまでもないというだけで
IDEがダメなんて言ってないしね。


IDEばっかり使ってると、コンパイラの仕組みがわからなくなる。
こういう意見もあるか。これは教育の問題。

一般的にIDEが開発に便利な機能を提供しているように思われてる。
それは間違ってない。

でももう一歩突き進むと、IDEの機能を実装するための
情報をプログラム言語は提供している。

プログラム言語がIDEに情報を提供する
↓
IDEがその情報から機能を作り出し開発者に提供する
↓
開発者

つまり、これは、プログラム言語によってIDEが提供できる機能に差があることを意味している。
実はこのことに気づいていない人が結構いるのではないだろうか？
IDEや静的型付け言語での解決経験が少ない人ほどそんな気がする。

>>874
しかし多重ディスパッチと単一ディスパッチ、世の普及度から言うと、

>（マルチメソッドでない、Javaみたいな）OOPL向きのやりかたなので、
>使ってるのがその手の言語でなければあまり意味はないし役には立たんわな

は

>単一ディスパッチでない、Common Lispみたいな言語には不向きなやり方だけど
>使ってるのがその手の言語でなければ大いに意味があるし役に立つわな

の方がより適切なのではないかw (いや意味的には一緒なんだけれどもさ)

>>850
え？今時ファイルベースのIDEでご満悦？
頭わるそw

C++とIDEはピンチの時に自分だけ逃げるタイプ
残るのは単なるCとテキストエディタ

>>890
どのようなアシストツールが便利かは言語によるという、それだけの話だな

IDE大好きなんだ
理解出来んがMSに帰依するとそんなもんかね
タイプ減らす意味でdabbrev程度で十分かな

10年前から全く議論が進んでねぇｗ

IDEはLISPとSmalltalkで育ってひろまっていったのだが、
どっちも動的型言語だなあw

動的型言語のIDEなんて広まってないのだが

squeak

ここで話しているのはIDE全般の話ではなく、その中でもcontent assistとか
auto completeとかいった入力を補完する機能の事でしょ。

型の宣言だろうが型推測だろうが、実行前にレキシカルに型を判定できる言語と
そうでない言語で補完の打率が異なるのは仕方がない。
静的に判定できる言語では打率は基本的に100%で、適用可能な候補はもれなく
列挙されるし使えない候補は基本的に表示されない。
候補の表示にしても代入先の型を見て表示順に優先度をつけたりも出来るし。

これが動的型付けになって実行前の型判定が難しくなったり補完機能の実装が
お馬鹿になるにつれて打率が下がって欲しい候補を取りこぼしたり空気読めて
いない候補を表示したりするようになる。

>>894
IDEでなんで「MSに帰依」とか出てくるのやら
MSとか別に関係ねーだろ

言語と環境が一体になってるIDEの典型例つーとSmalltalkだろ
Java方面ではEclipseが勿論有名だし
WindowsでもWin32の初期ではBorlandのDelphiが完成度の高さでメジャーだったし
勿論AppleもXcodeとか提供してるし、Think C/Symantec CとかCodeWarriorとか
サードパーティ製も以前から色々あった

emacs+elisp

> 言語と環境が一体になってるIDEの典型例つーとSmalltalkだろ

普通IDEといえば、言語と環境ではなく
言語とテキストエディタが一体となっているもの
（連携しているもの）なんだが。

>>897
Eclipseは元々はSmalltalkだけど何か？

なぜEclipseはSmalltalkを捨てたのか。

そこに見えるのは動的型付け言語の
限界なんだろうね。

>>902
適当に書いたが、確かにIDEは環境というよりはもっと狭いなｗ
ただ、「普通は」というのなら、普通はソースレベルデバッガ、クロスリファレンサ
なんかも含んでいると思う

>>899
コンプリーションこそXeroxで生まれて広まった技術じゃないか。
当然、源流はLISPとSmalltalk。どっちも動的言語のIDEだ。
Eclipseもそうだが、静的言語のIDEはしょせん派生にすぎないことをわきまえろw

Smalltalk時代のIDEの機能が知りたいね。
たぶん今と違ってすごく貧弱なものなんだろうけど。

>>902
IDEが何の略か知らないのか？EはEditorのEじゃねえぞww

>>906
いや、はじめにIDEが使われたからといって
だからなんなんだ？

その頃のIDEと今のIDEは別物だろう。
昔のはIDEというより、ただの実行環境ではないのか？

>>904
Java厨にもいじれるようにするためだろw
恥かしいこと書かせてんじゃねえよww

>>908
開発環境のＥだよな？
実行環境ではなく。

>>910
意味がわからん。

それはJavaを採用した理由であって
Smalltalkを捨てた理由じゃないだろ。

>>907
いちいち全部挙げても仕方ないが、このスレで出てきた機能だけでも
コンプリーション
ソースの自動整形
文法でハイライト
自動コンパイル
マウスを使ったGUI
コンテキストメニューによるコピー＆ペーストおよびコード実行
ソースレベルデバッガ
はSmalltalk-80に実装されていたわけだが？

>>912
は？SmalltalkのままじゃJava厨はいじれねえだろ？

>>913
じゃあ、違いは質かな。

しかし、Smalltalkの名が出ても
IDEを否定する動的型付け言語厨ってどうなの？
裏切り者？ｗ

というかIDEを否定するLisperが一番分からん
お前が使ってるソレはIDEと何が違うのだ……

>>915
質がどう違うかも説明できねえくせにwww

静的型言語のドカタ共が方眼紙にソースを手書きしていた時代から
動的型言語のハッカー達はコンプリーションやシンタックスハイライトする統合環境を作り上げていた。
それを今頃「静的型言語にはIDEがある(ｷﾘﾘｯ」とか、知らないって恥ずかしいねw

そしてその進化は静的型付け言語を選んだ。

みろよ、今の動的型付け言語のIDE対応。
貧弱と言わざるを得ないじゃないか。

今どんだけ活用されているかが問題なのだが。
元祖を誇ったところでメシの種にもならん。

http://www002.upp.so-net.ne.jp/feedc0de/diary/nikki0106b.html
malltalk-80はブームになったけど、でも結局遅いとかリソース食うとかいろいろ問題があって、
商業的には成功しなかった。 今動かしてみると、当時としては革新的だったGUIやIDEも
今となってはむしろ見劣りがする。 なんか、小さいころ遊んだ公園に20年後訪れてみたら、
こんなに小さかったんだー、みたいな。

ハッカーは面白がる。
信者は恩に着せようとする。

Smalltalkの例からもわかるように、
本来はIDEは便利なツールとして
誰からも理解されて当たり前なのに、
なぜIDEを否定するのか。

ハッカーはIDEを使う。

Lispの環境が大昔から充実してたってのは、ソースコードが構文木そのもので
S式だけの世界なので、非常にパースしやすく扱いやすかったからかねぇ
一方Cはviとctagsでどうにかしていたって感じか

ハッカーはIDEを使う。

XamarinはMonoTouchの最新版となる「MonoTouch 5.0」を公開した。

MonoTouchはクロスコンパイラ、ライブラリ、ツール、Xcodeインテグレーション、デバッガ、デバイス経由
デバッガなどが含まれたアプリケーション開発キット。
C#などの.NET対応プログラミング言語を使ってiPadやiPhone向けアプリケーションを開発できるという特徴がある。

「MonoTouch 5.0」の最大の特徴は、リリースされたばかりのiOS 5に対応した点にある。
説明によれば、MonoTouch 5.0を利用することでiCloud経由のクラウドストレージの利用、
Twitterの活用(メッセージ、URL短縮化、写真アップロード、位置情報利用など)、AirPlayを経由したストリーミングの実施、
Bluetooth経由による外部デバイスとの通信、Newsstandの活用などを実現できるという。

MonoTouch 5.0の発表段階ではまだドラフト版とされているが、MonoTouchを使ってiOS 5の機能を利用するための
サンプルコードを解説が「Introduction to iOS 5」にまとまっている。
具体的にどのような機能が利用できるのか参考になる。

http://journal.mycom.co.jp/news/2011/10/20/017/index.html

>>920
> みろよ、今の動的型付け言語のIDE対応。
> 貧弱と言わざるを得ないじゃないか。

やっぱり使いもせずに評論家気取りのドカタか♪

JavaScriptでビシバシ補完してくれるIDEって無いかしら。

>>929
使ってやるから、最低限これぐらいは
サポートした動的型付け言語用IDEを教えてくれ。
Smalltalk以外で。

コンプリーション
ソースの自動整形
文法でハイライト
自動コンパイル
マウスを使ったGUI
コンテキストメニューによるコピー＆ペーストおよびコード実行
ソースレベルデバッガ

netbeansのrubyサポートはそこそこだったな

>>931
例えばpythonあたりなら、
emacsのpython-modeや他のいろんなコードを寄せ集めたら
その程度の機能は揃わないか？

>>933
そんなことは　　誰　　で　　も　　わかってんだよ

お前がそれを正確にここにソースのせる必要がある
「技術」というのは、その情報のありかを知っているか？すぐ探せるか？
そこにかかっている

IDEの話題でEmacsを取り上げるのは逃げ。
あいつは何でもある

少し前にemacsの本たくさんでたからなぁ
そこでちょっと手をつけたタイプの奴か

>>933
EmacsでGladeやQT DesignerみたいなUIデザイナ系の機能が実現可能なわけないし、
標準のpython.elには補完機能とかないっぽいぞ
色々入れると補完ぐらいはできるようにはなるみたいだな

ただEmacsである以上、外部にPython立ち上げてプロセス間通信という方法なわけで
emacs.pyというEmacs側の付属品の置き場をPython側のsys.pathに入れてやるだとか、
gud.elからpdb使うにしてもpdbってただのPythonスクリプトだから
pdb.pyのパスを設定したりとか、Windowsならshebang使えないから
更にもう一手間いるとか、くだらなくて無駄な手間が色々ある

色々四苦八苦して設定してようやく標準でついてくるidleで当然できてることが
できるようになるんじゃ、何が何でもEmacsでやりたいって変人以外には
メリットゼロだろ