プログラミング言語 Scala 6冊目

1 ：デフォルトの名無しさん：2011/06/07(火) 12:21:04.30

The Scala Programming Language
http://www.scala-lang.org/

リンク集
http://sites.google.com/site/scalatohoku/%E5%8B%89%E5%BC%B7%E4%BC%9A%E8%B3%87%E6%96%99

前スレ
プログラミング言語 Scala 5冊目
http://hibari.2ch.net/test/read.cgi/tech/1294487102/

2 ：デフォルトの名無しさん：2011/06/07(火) 12:21:38.32

・Scalaの紹介文（さわり）
Scalaは簡潔かつ優雅で型安全な方法でよくあるプログラミングパターンを表現できるように
設計された汎用プログラミング言語です。
Scalaはオブジェクト指向と関数型言語の特徴をスムーズに統合しておりJavaやその他の言語を扱う
プログラマをより生産的にすることができます。（以下略）
ttp://www.scala-lang.org/node/25

・Scalaに関する書籍（英語）
ttp://www.scala-lang.org/node/959
リファレンスマニュアルや草稿のPDFなども充実しているのでそちらも参照してください。
日本語の資料には、チュートリアルの訳やIBM dW、IT Proの連載記事、各々で開かれた勉強会の資料などがあります。

3 ：デフォルトの名無しさん：2011/06/08(水) 02:25:29.41

前スレのスレ違い話題引っ張って悪いけど、今のCとC++って互換性低いぞ…

4 ：デフォルトの名無しさん：2011/06/08(水) 05:21:14.41

は？

5 ：デフォルトの名無しさん：2011/06/08(水) 08:05:05.03

なんでAkka 1.1で永続化消えたの？

6 ：デフォルトの名無しさん：2011/06/08(水) 10:24:19.11

GoogleがC++, Java, Scala, Goのベンチマークを取りましたとさ。
ttp://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php

7 ：デフォルトの名無しさん：2011/06/08(水) 12:23:27.66

全スレの LLVM Scala の話題より
https://days2011.scala-lang.org/sites/days2011/files/ws3-2-scalallvm.pdf

LLVMってどれくらい実用性があるの？？
マニアが面白がって遊んでる程度？

8 ：デフォルトの名無しさん：2011/06/08(水) 12:35:39.83

>>6
> GoogleがC++, Java, Scala, Goのベンチマークを取りましたとさ。
> ttp://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php

あれ？これみると、Scalaってかなり早いってこと？

C++ > Scala > Java > Go > C++デバッグ情報付

なの？
( Javaは、GCとかの最適化の具合で、もっと遅い場合もあり。)
ベンチマークのより詳しい情報はこちら：
https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

もちろん、
C++ > Scala >>>> PerlやRuby
なのは、言うまでもないけど,
Java(やJVM)が遅いってイメージがあったのは、GCとかの最適化具合が原因だったのかな？

9 ：デフォルトの名無しさん：2011/06/08(水) 13:24:21.19

Javaが遅いっていつの話よ

10 ：デフォルトの名無しさん：2011/06/08(水) 13:51:21.48

Netscape Navigatorで「Javaを起動しています」に待たされた人たちが作った伝説が
ずーっと一人歩きしてただけ。

11 ：デフォルトの名無しさん：2011/06/08(水) 14:29:54.57

今でもJVMの起動にイライラさせられてますけど？

12 ：デフォルトの名無しさん：2011/06/08(水) 15:05:20.73

PC買い替えた方がいいんじゃね？

13 ：デフォルトの名無しさん：2011/06/08(水) 23:26:07.28

ベンチマークの話をしてるのに、JVMの起動がどうとか言いだす男の人って

14 ：デフォルトの名無しさん：2011/06/08(水) 23:58:44.69

>>7
Apple 製品でよく使われているイメージ
Mac にも標準で含まれているし、OpenGL の最適化や
iPhone SDK, MacRuby などで採用しているらしい

あとは Google の NaCl も LLVM なんだっけか

15 ：デフォルトの名無しさん：2011/06/09(木) 00:13:16.28

スーパーなコンパイラっていうのがあるらしい

16 ：デフォルトの名無しさん：2011/06/09(木) 00:26:38.64

>>14

なるほど。
.Netの対応を強化するよりかは、LLVMにも対応した方が、幸せになる人がおおそうだ。

だけど、Ordersky先生には、言語そのもの、とりあえず、Scala3.0 の開発に没頭してほしいけど。

https://days2011.scala-lang.org/sites/days2011/files/ws3-2-scalallvm.pdf
これみると、メキシコの大学の人がScala のLLVM対応を研究しているのか。

17 ：デフォルトの名無しさん：2011/06/09(木) 00:33:32.85

>>16
しかしフレームワークとしての素性や周辺ツールとの親和性は置いといて
生成するx86バイナリの質だけみるとICCには及ばないし、gccやhotspotと
比べても微妙なところっぽい

18 ：デフォルトの名無しさん：2011/06/09(木) 01:01:41.65

LLVMはJVMを除いたVM系ではダントツに速い、
ただしgcc等に比べるとまだまともな最適化は行われてない。
その上llvm-gccはお亡くなりになってしまった。

19 ：デフォルトの名無しさん：2011/06/09(木) 06:47:36.69

お亡くなりになったというか、もう必要なくなっただけでしょ。

20 ：デフォルトの名無しさん：2011/06/10(金) 00:22:54.95

「スカラ」って、ラテン語で「階段」って意味なんだね。
それであのロゴマークか。

21 ：デフォルトの名無しさん：2011/06/10(金) 15:37:36.36

『オープンソース徹底活用 Scala実践プログラミング』が6/16(木)に出版されます
http://d.hatena.ne.jp/kmizushima/20110608/1307547649
プログラミング・言語の新刊
http://www.shuwasystem.co.jp/category/html/pro.html

初のScala応用本として期待しているのですが、
発売1週間前なのに新刊ページにまだリンクがありません。
秀和システムは発売前の目次公開はしてないようですね。

22 ：デフォルトの名無しさん：2011/06/10(金) 16:45:23.27

コップ本以来ようやくまともに読める本が出そうだな

23 ：デフォルトの名無しさん：2011/06/10(金) 22:35:44.03

おお～来週か。買うぜ
キンドルで読めると幸せなんだがなあ・・・

24 ：デフォルトの名無しさん：2011/06/10(金) 23:03:40.04

Scalaではじめるプログラミング
―「Java」「.NET」のソフト資産を生かして開発を効率化! (I/O BOOKS)

赤間世紀 (著)

というのも6月発売だが、、、、
中身をみなくても、中身が想像できちゃうのがなんとも。。

25 ：デフォルトの名無しさん：2011/06/10(金) 23:06:45.87

俺もiPadで見たいんだが。そういうのは秀和はやらないだろうか。

26 ：デフォルトの名無しさん：2011/06/10(金) 23:24:29.80

>>21

・概要編
1章 Scalaの概要
2章文法・構文・言語としてサポートする機能
3章関数型プログラミング
4章他言語との比較、関連

・実践編
5章開発環境
6章 Webフレームワークを利用してアプリケーションを作成してみる
7章デザインパターンとScala
8章現場でのScala
9章 Javaとの連携
10章特徴的なライブラリ
・付録：標準API簡易リファレンス

だって。
こういう実践的な本がでることで、現場への採用がすすむと良いなあ。

27 ：デフォルトの名無しさん：2011/06/10(金) 23:52:59.37

まだAmazonない

28 ：デフォルトの名無しさん：2011/06/11(土) 09:29:52.90

どっちかっていうとF#が持つ表現力と美しさ
が業務開発で魅力的だろうね。
Scalaは採用されないと思うね

29 ：デフォルトの名無しさん：2011/06/11(土) 11:15:23.19

>>28
美しさならHaskellやSchemeが一番だろ。
美しいだけでは業務開発で使われない。ScalaはベターJavaとして業務開発では
ますます注目されるんじゃないかな。
Javaがずっと主要言語であり続けることはないだろうし。

30 ：デフォルトの名無しさん：2011/06/11(土) 12:20:25.70

>>29
> Javaがずっと主要言語であり続けることはないだろうし。

いや、FORTRAN, COBOL, C並に長生きすることはもう間違いない。

31 ：デフォルトの名無しさん：2011/06/11(土) 12:29:33.98

Javaは、JVMにとってのCとして生き続ける。

32 ：デフォルトの名無しさん：2011/06/11(土) 13:46:17.61

でもJavaって自由度あんまし高くないから、基盤として使い勝手良くない気がするんだけどな…
(ex.Friendクラスが無い)
安全性が高いのはいい事だと思うけど。

33 ：デフォルトの名無しさん：2011/06/11(土) 13:46:54.48

馬鹿も生きていくためには必要なんですね

34 ：デフォルトの名無しさん：2011/06/11(土) 14:18:27.01

>>30, 31
確かにjavaが無くなることはないと思う。しかし主要言語ではなくなるだろう。
新しいプログラマがいつでも使い続けるような言語でもない。

35 ：デフォルトの名無しさん：2011/06/11(土) 15:10:57.52

そうなるには最低でも１０年はかかるかと。

36 ：デフォルトの名無しさん：2011/06/11(土) 15:18:35.60

>>35
oracleの出方によっちゃ10年ももたない気がする

37 ：デフォルトの名無しさん：2011/06/11(土) 15:43:26.42

とりあえず代わりがないんだもん
Monoがブームにでもなれば別だが

38 ：デフォルトの名無しさん：2011/06/11(土) 21:22:26.95

http://www.infoq.com/jp/news/2011/05/Mono-II

39 ：デフォルトの名無しさん：2011/06/11(土) 22:34:45.43

ここがヘンだよScala言語
ttp://d.hatena.ne.jp/kaminami/20110611/p1

40 ：デフォルトの名無しさん：2011/06/11(土) 22:50:40.52

http://d.hatena.ne.jp/kaminami/20110611/p1

正論過ぎて何も言えない

41 ：デフォルトの名無しさん：2011/06/11(土) 22:51:39.76

これでもScala使うの？
http://d.hatena.ne.jp/kaminami/20110611/p1

42 ：デフォルトの名無しさん：2011/06/11(土) 22:59:09.27

>>38
monoのコア開発者の移籍先のXamarinも、Unity3Dと同じスマートフォン開発中心に進めてるから、
.net4.0でしばらくペンディングかなあ

43 ：デフォルトの名無しさん：2011/06/11(土) 23:05:09.21

>>39-41
3回も貼らんでええがな…。

いや面白かった。
確かにあるなー、そういうの。
まだScalaそんなに扱ってないから(他言語もそんなに知らないし)そういう所に意識が回らなかったけど、
あるある。
いくつかは今後改善出来る所だと思うから、そういう所はどんどん出てくるといいよね。

44 ：デフォルトの名無しさん：2011/06/11(土) 23:56:47.31

>>39
>forのネスト
>for(i <- 0 to 10; j <- 0 to 10; k <- 0 to 10) {
>ループが一つなのか、三つなのか、ぱっと見で分からない。必要だったのか？

これは三次元ループが一つでしょう。
for文をif文とgoto文に置き換えずにそのままの形で理解すべきであるように
これも三重の一次元ループに置き換えずに理解すべきだと思います。

45 ：デフォルトの名無しさん：2011/06/12(日) 00:13:04.08

http://www.infoq.com/jp/news/2011/02/lift-jruby

私は Scala が好きです。Scala は私のお気に入りのプログラミング言語なのです。
これまで数多くの開発組織で，Scala に関する話をしてきました。
しかしその後の Scala の普及状況を見たとき，私はこの言語が Ruby や，
あるいは Python の採用レベルにさえも達しそうもないことに気付いたのです。

46 ：デフォルトの名無しさん：2011/06/12(日) 00:15:47.86

Perl や Tcl は普及してるな
csh も大抵の環境で使える

47 ：デフォルトの名無しさん：2011/06/12(日) 00:20:12.21

F#は普及するね

48 ：デフォルトの名無しさん：2011/06/12(日) 01:55:10.12

>>39
読んで損した。浅い。

49 ：デフォルトの名無しさん：2011/06/12(日) 02:21:31.47

見てみたら、もう先に水島氏がガッツリ反論してるから言うことない

50 ：デフォルトの名無しさん：2011/06/12(日) 02:27:25.63

そうね。
指摘されてから、知ってるけどあえて書いてるって…

51 ：デフォルトの名無しさん：2011/06/12(日) 02:33:53.83

しかしいつも思うんだが
ミズシマさんはネット上のコミュニケーションが上手ではないですねえ…

52 ：デフォルトの名無しさん：2011/06/12(日) 02:40:01.11

たしかに。
絡まれた方は誰一人有益な議論だったとは思ってないんじゃないかと。
matzさんしかりkなんとかさんしかり。

53 ：デフォルトの名無しさん：2011/06/12(日) 02:40:57.87

forの誤解は結構多いのかな
Haskellのdoをforと呼ぶというのはなるほどと思ったのだが

まあ、forの中の構文が特殊というのは当たってるな
というかLispのloopをはじめ、内包表記にありがちなことなんだが

54 ：デフォルトの名無しさん：2011/06/12(日) 02:42:42.49

ええ？いい人じゃん、面識はないけどさ
あんなに真面目に議論する人なかなかいないと思うよ

55 ：デフォルトの名無しさん：2011/06/12(日) 02:56:53.63

自分のわかっていることでも、あそこまで書けないよね、面倒で。

56 ：デフォルトの名無しさん：2011/06/12(日) 03:01:53.07

俺なら2chのどこかにRubyistってほんとに頭の悪いクズが多いなって書いて終わりだわｗ

57 ：デフォルトの名無しさん：2011/06/12(日) 03:06:22.84

Rubistじゃないんだね。Rubyist Magazineとか。

58 ：デフォルトの名無しさん：2011/06/12(日) 03:12:15.36

>>54
議論が目指してる方向についての認識が双方で一致してるんならね。
自分があんな絡まれ方したらもっと早いタイミングでブチ切れてるわ。
過去の人たちもそうだけど、よくあんな紳士的な態度で付き合ってるよな。

59 ：デフォルトの名無しさん：2011/06/12(日) 03:15:34.26

そういう人は最初からコメント閉じてるんじゃないの?
何を期待してコメント書き込めるようにしてるの?

60 ：デフォルトの名無しさん：2011/06/12(日) 03:30:19.88

>>56
そっちの方が双方の時間を浪費しないぶんましだが、
Smalltalkって思いきり書いてるぞ…

61 ：デフォルトの名無しさん：2011/06/12(日) 03:30:26.61

確かに大人な人間ならいつかのmatzとか今回のkaminamiみたいな
明らかにScalaに悪意のある人間には何を言っても無駄だとわかるから何も言わない
でもそこでちゃんと言うほうがえらいじゃん

最近のTwitterのScala TLとか気持ち悪いわ
Scalaが複雑かどうかとかさ
普及のためには関数型のアピールやめろとかさ
バカに媚び売る必要なんてないよ
頭の悪いやつはどんどん置いていけ

62 ： ◆CgacaMDhSQ ：2011/06/12(日) 04:33:51.10

あえてこのスレにも書きます。今回の件に関しては反論の仕方が挑発的であり、大人げ無かったとは
自覚しています。それについては、批判されても仕方無いでしょう(実際、Twitterで、自分の言葉の
選び方に関して批判的なTweetがありますし)。それ以上の部分はここで書いても陰口
と取られかねないでしょうから、そこはTwitterなりブログなりで、隠さずに書きます。

63 ：デフォルトの名無しさん：2011/06/12(日) 04:41:56.39

自分にとって今まで勉強してきた言語のなかでScalaは圧倒的に覚えにくい。
何でだろう？
省略してよかったり良くなかったり規則性が見つけにくいとかかな？
タプルとか優先順位なのかグルーピングなのか...

64 ：デフォルトの名無しさん：2011/06/12(日) 04:52:06.28

今までどんな言語を学習してきたんだよ

65 ：デフォルトの名無しさん：2011/06/12(日) 06:19:45.84

>>39
「Twitter上でも」と書いてあったので調べました。

http://twitter.com/#!/kaminami/status/77679564867907584
>Scalaってのは「覚えるのが好き」な人のためのものだとつくづく。
>特別なメソッド、節操のない糖衣構文、暗黙のなんちゃら。
>「Scalaは、むずかしすぎて使えない!」から、
>JavaやC#に取って代わることはないだろう。

http://twitter.com/#!/kmizu/status/78123820237586433
>@kaminami ScalaがJavaやC#にとって変わるかどうかはともかく、
>Scalaが単純に「覚えるのが好き」な人のための言語だというのは異論があります。
>少なくとも、「Scalaは、むずかしすぎて使えない！」なら
>今のC#もまともに使えないかと。 #scala

http://twitter.com/#!/katzchang/status/79142581451243521
>@kaminami 横槍で失礼しますが、議論の目的はなんでしょうか？
>Scalaの言語仕様が複雑であるかどうかの議論ですか？
>それともScalaはプログラミング言語初学者向きかどうかの議論ですか？

http://twitter.com/#!/yukihiro_matz/status/79619048706551808
>我々が「言語が複雑すぎる」と発言するとき、
>ほとんどの人は「文法の複雑さ」ではなく、
>「認識しづらさ」とか「覚えにくさ」とかを問題にしていると思う。
>で、議論の最中、数人だけは本当に
>「言語(ルール)の複雑さ」について語るので大いに食い違う。
>正しく表現しない私たちが悪いんだけどさ。

katzchang氏とyukihiro_matz氏のtweetが鋭いですね。
Scala学習中のkaminami氏の中途半端な認識自体が
Scalaが覚えにくい言語である事の証明ではないでしょうか。
kmizu氏の反論は木を見て森を見ずになっていると思います。

66 ：デフォルトの名無しさん：2011/06/12(日) 06:35:51.90

学習中の人間の認識なんて中途半端なもんだろう
それをもって「覚えにくい言語である証明」って言うのは飛躍じゃないか?
その線でいくなら(できるだけ公平な基準で)他の言語の学習曲線と
Scalaの学習曲線を比較しなきゃ

67 ：デフォルトの名無しさん：2011/06/12(日) 06:51:58.07

自分が理解できないから言語が難しいという論法はもういいよ

68 ：デフォルトの名無しさん：2011/06/12(日) 07:14:32.44

どなたか教えて欲しいのだけど、
これからscala始めるのにコップ本でも
2.9との差異に困ったりしない？
それとも2.9対応本が出るまで待つべき？

69 ：デフォルトの名無しさん：2011/06/12(日) 07:21:02.82

2.9は並列コレクション以外は2.8と大して変わってないから気にしなくていいよ
まあコップ本は2.7なんだけど
2.7と2.8はコレクションライブラリが総取っ替えのレベルで変わってるからなあ
でも言語の基本的な部分はあまり変わってないからコップ本は今でも十分に参考になる

70 ：デフォルトの名無しさん：2011/06/12(日) 09:37:49.45

今でもScalaを一番効率良く学ぶ方法はコップ本をキッチリ読むことだと思う

71 ：デフォルトの名無しさん：2011/06/12(日) 10:05:51.62

>>70
久々にコップ本で技術書をキッチリ読んだ俺に言わせると、他の方法は必要だと思うよ。。

72 ：デフォルトの名無しさん：2011/06/12(日) 10:10:20.35

>>44
「どう動作するか」と、「何を記述したいか」の違いだねぇ。

もちろん、プログラマとしては前者も理解しておくべきだが、
後者の方が簡潔で本質的な記述ができるのも事実。

73 ：デフォルトの名無しさん：2011/06/12(日) 10:11:59.32

そうかな、でも一番効率はいいと思うんだよねー
ここがへんだよの人も読んだのがコップ本ならもうちょっとましなエントリ書けたと思うし

74 ：デフォルトの名無しさん：2011/06/12(日) 10:15:31.18

ほとんどの本が並列計算まで扱ってるから難しくて当たり前。

75 ：デフォルトの名無しさん：2011/06/12(日) 10:20:09.97

>>73
何のかんので、読破にすごい時間かかったからなぁ。
一見さんを引っ張り込むには、言語のエッセンスを端的に伝えられる、もっと薄い本が必要。
その意味で関数脳本は悪くなかった。

76 ：デフォルトの名無しさん：2011/06/12(日) 10:25:28.09

インスタンス生成の記法として、newとobjectのapplyが混在しているのは見通しが悪い、
というのはああそうかもな、という感じはする。
まぁでも、「objectのapplyメソッドを使うとこんなことができます」という説明の問題か。

77 ：デフォルトの名無しさん：2011/06/12(日) 10:28:03.05

あと、ラムダ式のプレースホルダの問題については同意見だなぁ。
"ACBED".sortWith(_1 > _2) みたいな書き方はできるようにして欲しい。

78 ：デフォルトの名無しさん：2011/06/12(日) 10:34:43.62

C++の式テンプレートか
あれは最初から意図したものじゃなくて、
仕様作成後に発見されたというのが凄すぎる。
よくあんな仕様作れたな。

79 ：デフォルトの名無しさん：2011/06/12(日) 10:46:49.72

水島さんのコメントまで辿り着いた。

まぁ、内容はともかく、キレちゃだめだよ。
自分が入れ込んでる言語をハンパな知識で貶されて気分が悪いのは分かるけど、
それをScalaに何の思い入れもない人間が見たら、ということは考えた方がいい。
（あと、水島さんにだけ言ってるんじゃないよ、と一応）

80 ：デフォルトの名無しさん：2011/06/12(日) 10:54:00.11

批判するってことは、少なくともその言語に対して関心を持っているわけだから、
うまいこと誤解を解きほぐせば、支持者に変わってくれる可能性もあるわけだ。

Javaに異なるパラダイムを持ち込んでいるのがScalaなのだから、
誤解が生まれる事自体は受け入れるしかない。
そこを橋渡しできるドキュメントや人間がいるか、こそが問題。

まぁ、うまいことやろうぜ、ということです。皆さん。

81 ：デフォルトの名無しさん：2011/06/12(日) 11:05:53.28

Scalaはライブラリも含めて面白い言語だし、いい設計も随分あると思うが、
普及してくれるといいとかそういう気持ちは全くないな、俺は。
>>79の言うような書き込みもしたことはないが。

82 ： ◆CgacaMDhSQ ：2011/06/12(日) 11:06:23.39

主観的な意見ですが、Scalaの学習曲線自体はさほど急ではないと思います。
ただ、教え方というか、現状Web上にあるScalaチュートリアルとかがイマイチ
学習向けじゃなくて、それで小難しく感じられているというのはあると思います。

実際の所、Better Javaの部分だけ取り出してScalaを教えるのなら、Javaを
教えるのと比べて、staticって何よ、とか、プリミティブと参照型の違い、参照型で
値の比較に==使っちゃダメ、とかそういったこまごまとして事を教えなくていい分
楽な気がします。

83 ：デフォルトの名無しさん：2011/06/12(日) 11:10:08.88

結論としてScala禁止でいいんじゃないか？
日本人に理解困難な言語を輸入しても悪影響しかでないよね？

84 ： ◆CgacaMDhSQ ：2011/06/12(日) 11:14:47.55

>>79
ご忠告ありがとうございます。コメントの書き方については自覚的に挑発的に書いたので
あって、さほどキレていたわけではないです。

実際の所、ああいう書き方をしたのは、あのブログエントリがTwitterでのやり取りの
続きであると考えていたからなのですが、ブログを読む多くの人はTwitterでのやり取りは
見ていない、ということは失念していました。

85 ：デフォルトの名無しさん：2011/06/12(日) 11:15:18.97

>>82
んだ。
というわけで期待してますよー（人任せ。

86 ：デフォルトの名無しさん：2011/06/12(日) 11:15:30.78

はぁ？

てめぇが理解できないもんは他人にも理解できるはずがないとか思う超ド級のバカか？

87 ：デフォルトの名無しさん：2011/06/12(日) 11:34:33.57

そもそもの問題はJava依存した言語だってこと
これを改めない限り１つの言語として認知されない

88 ：デフォルトの名無しさん：2011/06/12(日) 11:38:10.50

ほとんどの言語処理系がCやC++に依存しているが?
一部の言語処理系では他言語は古い世代でのブートストラップにしか利用してないが。

89 ：デフォルトの名無しさん：2011/06/12(日) 11:41:11.05

いや違うな、Javaに媚売った仕様が反感買ってるのか

90 ：デフォルトの名無しさん：2011/06/12(日) 11:46:21.42

>>89
主語は明確にしよう。

何度も言われてるが、JVM言語である以上の限界はあるわな。
その分、ライブラリとか開発環境とか、メリットも大きいわけだが。
まぁ、今の言語の大半が、X86処理系の限界に縛られているのとそう変わらん。

91 ：デフォルトの名無しさん：2011/06/12(日) 12:02:31.30

>>87
そもそもの問題は
そんな話してないのに、そっちに話持っていこうとすることだろ…

92 ：デフォルトの名無しさん：2011/06/12(日) 12:12:35.32

結局Javaを知らないと書けないから複雑、マルチパラダイムだから複雑
これはいいんだよ、完全に事実だから
だからJavaと関数型を勉強してから来いよ
LLしか知らないようなやつがいきなり理解できるわけねーんだよ

93 ：デフォルトの名無しさん：2011/06/12(日) 12:44:38.86

Rubyは勉強しないといけないなぁ、とは思っている。
プログラマとして上を目指すなら、色々な言語を知っておいて損はない。

それと、初心者に門戸を広げるというのはまた話が別だけどね。

94 ：デフォルトの名無しさん：2011/06/12(日) 12:50:02.02

勉強したくないからRubyやってるんだろ

95 ：デフォルトの名無しさん：2011/06/12(日) 12:52:46.73

いやまてまてRubyはRubyで色々勉強しなきゃいかんし

というか抗争を煽ろうとしてる人間がスレに混じってるようで嫌だな

96 ：デフォルトの名無しさん：2011/06/12(日) 12:55:32.07

>>93
僕と契約して、Ozを勉強してよ
http://www.mozart-oz.org/home/doc/tutorial/index.html

日本語翻訳は任せた
ていうか誰か完訳して…
CTMCPで使われてるのにまだチュートリアル日本語版が無いとか
日本の情報工学マジ…

97 ：デフォルトの名無しさん：2011/06/12(日) 12:57:32.95

最近の言語バトル的盛り上がりはいいねー。
ガンガンdisられてこそ伸びるだろう

98 ：デフォルトの名無しさん：2011/06/12(日) 13:04:14.34

プログラミング言語に愛を持っていて、まともな指摘のあるdisならね…。
歴史の浅い学問でまだ発展途上なんだから、
現在存在する全ての言語は後に置き換えられるべき通過点に過ぎないと考えるべき。
どうのつるぎみたいな。

99 ：デフォルトの名無しさん：2011/06/12(日) 13:08:12.37

>>96
CTMCPは衝撃だった
マルチパラダイムであっても核言語を整理すれば
あそこまで簡潔になるんだなあと

じゃあScalaはっていう話になるが、どうしても複雑だという印象を拭えない
Ozとの違いでいくと、静的型付けって所が影響してるのかなあ？

100 ：デフォルトの名無しさん：2011/06/12(日) 13:09:20.03

歴史の浅い学問でまだ発展途上？

101 ：デフォルトの名無しさん：2011/06/12(日) 13:09:31.95

Scalaがまずすべきことは >>39 みたいな人を追い出すことだと思う。
C#みたいに(またはVB.NETみたいに)
LINQすら読めないのにC#得意ですと言いだす人間ばっかりの言語なんていやだ。

102 ：デフォルトの名無しさん：2011/06/12(日) 13:23:35.55

排他的になってもライブラリや対応環境は増えないけどな。

103 ：デフォルトの名無しさん：2011/06/12(日) 13:27:42.69

I/Oライブラリ無い時点で終わってる

104 ：デフォルトの名無しさん：2011/06/12(日) 13:29:32.80

別に追い出せとは思わないが
入ってくる気がないからああいうこと書くんだろうし

105 ：デフォルトの名無しさん：2011/06/12(日) 13:33:36.81

Scalaについてどう思う？

好き 1%
嫌い 1%
なにそれ？ 98%

みみちい争いは空しい

106 ：デフォルトの名無しさん：2011/06/12(日) 13:40:16.50

>>88
例外発生時にJavaのエクセプション出す依存っぷりは、
同列に語れないレベル。

107 ：デフォルトの名無しさん：2011/06/12(日) 13:40:44.89

Scalaの知名度って低いよな
この間クラスの女子に「Scalaって知ってる？」って聞いたら
「は？誰おまえ？」って言われたよ
一般的にはその程度の知名度

108 ：デフォルトの名無しさん：2011/06/12(日) 13:51:26.16

>>88
ScalaがVMをきちんと開発しないかぎり
永遠に同列にならない

109 ：デフォルトの名無しさん：2011/06/12(日) 13:53:05.92

神は言っている
グダグダ言ってないで手を動かせと

110 ：デフォルトの名無しさん：2011/06/12(日) 13:54:27.52

>>96
つーかOzってCTMCPを読むための言語ってイメージだが
それならCTMCPを読めばええやんって話だから誰も翻訳しないんじゃね

111 ：デフォルトの名無しさん：2011/06/12(日) 13:55:17.18

なんでVMを自前で持つ必要があるんだ
意味わからん

112 ：デフォルトの名無しさん：2011/06/12(日) 14:01:06.73

Haskellみたいに他と激しく違いすぎる言語だと、VM（抽象機械と言ってるけど）も
専用に設計されたものだったりするが。

113 ：デフォルトの名無しさん：2011/06/12(日) 14:24:39.40

>>112
そしてライブラリが無くて普及しない地獄が始まる。

114 ：デフォルトの名無しさん：2011/06/12(日) 15:00:04.28

>>110
Scheme(SICP)は沢山入門文書があるのにね…。
原文読めよって話になるんだろうけど、それを嫌がる人にもCTMCPに触れてもらいたいのよ。

800P超える本に手を出す人が英語読むの億劫、ってのもレアケースかもだけど、
日本語文書で概要掴んで好きな所だけつまみ食いをもっと気軽に出来るようにしてほしいなって思って。
技術英単語にもっと明るくて時間があるなら、俺がやってもいいけどさ

115 ：デフォルトの名無しさん：2011/06/12(日) 15:45:33.42

Sっcala菅

116 ：デフォルトの名無しさん：2011/06/12(日) 16:59:13.29

>>107
Scalaについてどう思う？

好き 0%
嫌い 0%
は？誰おまえ？ 100%

117 ：デフォルトの名無しさん：2011/06/12(日) 17:00:37.03

>>97
あの程度でdisだとかFUDだとか、被害妄想も甚だしい

118 ：デフォルトの名無しさん：2011/06/12(日) 17:04:49.64

FUDにもなってないわ
書いてる本人が自分で間違いに気づいてないんだから

119 ：デフォルトの名無しさん：2011/06/12(日) 18:19:47.59

少なくとも、初学者へ正確な知識を体系的に伝えるためのドキュメントが
まだまだ未整備なのは事実だし、それは何とかしないといけない。

「お前の意見は間違いだ」といっても、間違った理解をする人間の方が多いなら、
それが言語に対する評価になってしまうわけで。

120 ：デフォルトの名無しさん：2011/06/12(日) 19:13:53.68

紛らわしい言語仕様が原因なのか？

121 ：デフォルトの名無しさん：2011/06/12(日) 19:28:38.07

なめられてんだよ
Haskellならそんな難癖つけてくるやつはいない
Scalaなら俺にもできそう → うわイミフ → 言語が複雑すぎるから悪い
この流れ

122 ：デフォルトの名無しさん：2011/06/12(日) 19:40:31.51

ところで、秀和の
Scala実践プログラミング
http://www.amazon.co.jp/Scala実践プログラミング/dp/479802998X
が書店によってはフラゲ出来てしまう様ですが、
お前らにおかれましてはゲットされましたか？

123 ：デフォルトの名無しさん：2011/06/12(日) 19:41:57.29

地方だが、帰りに書店に寄ってみるか

124 ：デフォルトの名無しさん：2011/06/12(日) 20:09:27.76

ないな

125 ：デフォルトの名無しさん：2011/06/12(日) 21:35:38.27

C,C++,Delphi,Ruby,Java,JavaScript,VisualBasic,FamilyBasic,PockeconBasic,MASM,PICASM,VHDL,SystemC,SystemVerilog,
Matlab,Scilab,R,Maxima,BSH,CSH

とかいろいろな言語やってきた(やらされてきた)が、言語disっている暇なんてないぞ。
言語そのものに対する不満とか、言い始めたらきりがない。

職場のコーディングルールに従わなければいけない縛りの方が理不尽だ。
言語のバージョンが上がっても、職場では何世代も前のバージョンしか使えないとか。

Scalaをすべての人に使わせようと思ったら、コーディングルールで縛りを設けるべきだな。
C、C++とかは一時期「変数名はシステムハンガリアン以外認めない！」みたいな時期があったけど、
Scalaにもそういう時期は必要だな。「プレースホルダー使うときはコメントで説明がないとNG」、みたいな。

個人的には、Scalaはまだ発展途上なところが楽しみな言語である。
どんどん要望だそうぜ！

126 ：デフォルトの名無しさん：2011/06/12(日) 21:39:30.90

微妙な言語ばっかだな、おい

127 ：デフォルトの名無しさん：2011/06/12(日) 21:40:24.56

>>125
> PockeconBasic

disってんじゃんYO！

128 ：デフォルトの名無しさん：2011/06/12(日) 21:41:51.22

いくつか言語を知ると、今度は言語に必要な要件とか、どんな条件を満たすセットで定義できるんだろうとか、そっちに興味行かないかい？

自分はProgramming Language Pragmaticsを読んでるところ。って、Scalaの話じゃないなw

129 ：デフォルトの名無しさん：2011/06/12(日) 21:46:23.24

>>126
ハードウェア屋の人には多そうな取り合わせじゃね？

130 ：デフォルトの名無しさん：2011/06/12(日) 22:00:42.82

Java SE 7 - Project Coinの整数リテラル区切り文字をScalaにも
http://d.hatena.ne.jp/yuroyoro/20110510/1305026957

これって、将来対応してくれるとうれしいなあ。

パッチまであるのだから、2.9.0.2くらいで入れてもらえるとうれしい。

131 ：デフォルトの名無しさん：2011/06/12(日) 22:08:06.60

＞某所の
まぁ、そんくらいにしといた方がいいよ。
批判者をコテンパンに論破しても、別にScalaの普及には繋がらないんだしさ。
筆頭の論客は、どっしり構えるくらいでいた方がいい。

132 ：デフォルトの名無しさん：2011/06/12(日) 22:42:29.95

「モナドは象だ(Monads are Elephants)」日本語訳
http://dl.dropbox.com/u/261418/monads_are_elephants/index.html

モナドの実例はHaskellが定番でしたが、Scalaもメジャーになりましたね。

モナドはメタファーではない
http://eed3si9n.com/ja/monads-are-not-metaphors
>モナドの概念を初めて学ぼうとする者は、ブリトー、宇宙服、象、砂漠のベドウィン
>(訳注: アラブ系遊牧民) の共通項を探す努力をするハメになっている。

こちらは比喩と長文が苦手な人向きです。

133 ：デフォルトの名無しさん：2011/06/12(日) 23:53:28.22

>>131
おそらく自分の事かと思いますが、ご忠告、痛みいります。おっしゃる通り、論破しても無益ですし、
むなしいだけですね。というのを、反論書いてから実感しました。これからは、議論の方に時間を割くより、
Scala日本語情報サイトのコンテンツ充実の方に時間を割いて行こうと思います。

134 ：デフォルトの名無しさん：2011/06/13(月) 00:54:22.11

またやってんのかｗ

>>118
http://twitter.com/yuroyoro/status/79550622436831232
http://twitter.com/kmizu/status/79557535316717570

135 ：デフォルトの名無しさん：2011/06/13(月) 00:59:30.39

>>133
いや、あれが無益かどうかは読み手によるんじゃ。
少なくとも自分にとってはScalaへの理解について、曖昧にしてあった部分が少しわかったし。

136 ：デフォルトの名無しさん：2011/06/13(月) 06:56:07.01

>>133
http://twitter.com/kmizu/status/79974504956297217
こうゆう発想は子供っぽいからもうやめとけ。

137 ：デフォルトの名無しさん：2011/06/13(月) 07:13:17.36

他言語との対比があるんなら見たいかも

138 ：デフォルトの名無しさん：2011/06/13(月) 07:20:51.29

エバンジェリストなんだったらその自覚をもった対応をしたほうがいいよ。
scalaコミュってまだ未成熟で子供と言う印象を与える原因になってるから。
誰を見本にしろというのはあまりいいたくないけど、schemeやlisp方面での
shiroさんから態度を学んでいったらいいんじゃないか？と思うよ。

scalaが他の関数言語より難しくなりやすいのってJavaの人々を取り込もうと
する仕様にあるように思うよ。オブジェクト指向と関数言語というのを
合わせようとする発想はいいんだけど、それがかえって難しくしているところ
がある。せめてCLOSやRのようなゆるいオブジェクト指向の仕様なら第三者か
ら見てわかりにくい概念が山ほど出てくるというのは少しは避けられたかも
ね。もとが複雑な言語を拡張して自由度を増やそうとした場合更に複雑な仕様になるのは自明の理なんだから、scalaが難しいということで怪気炎を上げる
ような行動は褒められたものではないよ。それより>>131さんの忠告を心から
理解することが大切じゃなかろうかね？

139 ：デフォルトの名無しさん：2011/06/13(月) 07:26:40.17

http://twitter.com/yuroyoro/status/79837880901582848

主観的な評価だ、kmizuには伝わらん、って相手言ってんじゃん
お前らが突撃しといてその言い草かよ…
Scalaのイメージ悪くなるからマジ止めてくれ

140 ：デフォルトの名無しさん：2011/06/13(月) 07:50:16.69

Java に対する Scala の立ち位置って COBOL に対する PL/1 に似ている。

141 ：131：2011/06/13(月) 08:08:46.95

>>138
まぁ、きつい言い方をするとそういう事になるね。

「易しい」「難しい」「使いやすい」「使いにくい」なんてのは、
技術的に白黒つけられる類の議論ではないのだから、どうしても不毛になりがち。
それよりは、分かりやすい日本語ドキュメントを整備して、
「よく理解できる」という声を増やす事に注力した方が、結果的には実利にも適っている。

ともあれ、これからの仕事にも期待しているのでがんばって下さい。

142 ：デフォルトの名無しさん：2011/06/13(月) 08:12:45.42

正直、松本が「最悪手」って言ってるものはrubyの日常だろって思う。

143 ：デフォルトの名無しさん：2011/06/13(月) 09:03:01.85

基地外乙

144 ：デフォルトの名無しさん：2011/06/13(月) 10:42:19.02

>>142 matzが最悪手なんて言ってたっけ？ググってもよくわからん。

145 ：デフォルトの名無しさん：2011/06/13(月) 12:20:36.59

技術の話より政治の話のほうが盛り上がるな

146 ：デフォルトの名無しさん：2011/06/13(月) 12:26:19.48

いやいや今回の水島氏を攻めてるやつは何様なの？
shiroみたいになれって？
自分のこと棚に上げて口だけなら何とでも言えるわな
向こうが屁理屈を並べたら理屈できっちり返さなきゃいかんだろ
それもできない連中はしょぼいコミュニティだと思うよ

プログラムを書くにはプログラミング言語の仕様を熟知しないといけないということをわかってないやつが多すぎる
今回の話についていけないようなやつはJavaやC#の仕様をちゃんとわかって書いてるのかね
細部を突ついたら似たような話になると思うけど

147 ：デフォルトの名無しさん：2011/06/13(月) 12:35:48.93

>>146
率直に言って、仕様を熟知している人というのはごく一部ですよ。
それを踏まえて、いろんなことを言う人がいる。
shiroさんの名前を出したのは、彼もいろんな事で反論や説明は
良くしているけど、その立ち回りは大変上手だよ。だから見本になるだろう
といってる。
今回のことを見てて大変まずいのは、反論をするにしても一見丁寧に対応し
てるように見えつつも、技術的なことも書きながら、相手をなじるような記
述が度々見られる点かな。これでは、議論をする人も適当にあしらってさっ
さと関わらないという行動をとるだろう。つまり、論者としては二流ってこ
とさ。

ちょっと考えれば分かるだろうけど、相手にしてみればこれほどめんどく
さいと思うことはないよ。それに加えて、やや粘着な傾向も見られる点が
きがかりだね。

148 ：デフォルトの名無しさん：2011/06/13(月) 12:39:38.51

具体的に言うと
>、kaminamiさんは、Scalaにおける基本ルールを中途半端にしか理解されて
いません。そのせいで、特例で無い事も特例としてとらえてしまっているの
でしょう(中には的を射た指摘もありますが)。以下、一つ一つ説明していき
ます。

とあるけど、上手な論者ならば、中途半端に理解されていないというところ
をオブラートに包むか、具体的な説明で暗にそれを示すかといったストレー
トにやらない方法をとるもんだ。言い回しを少し注意するだけでもずいぶん
違うと思うよ。

かなりきつい記述も含めたけど、このほうがこの人にはいいのかなと思って
書いてるけど、こうゆう書き方も反発はくらいやすいのは理解してる。133さん
がいってるようにきついですよ。

149 ：デフォルトの名無しさん：2011/06/13(月) 12:54:01.21

気質っつーのはどうにもならんもんだし、うるさがたタイプ（たとえばRuby界隈だと
mput氏）みたいな存在もそれはそれで有用ではある。

まぁ問題は懐かしのJavaHouseみたいに、その言語自体に対する評価において、
人に対する印象が先行しちゃう、ということだけど、それで言語に対する評価を
誤る奴なんてのは所詮そういうレベル、という見方もある。

hyuki氏やMatz氏のようにふるまえ、ってのを誰にも要求するのは無茶ってもんだと
俺は思うけどね。

150 ：デフォルトの名無しさん：2011/06/13(月) 12:56:08.37

shiroに比べて2流って、ジョブズみたいな経営者になれ的な戯言にしか見えんわ
そりゃ処理系を作ってる日本の第一人者という言葉の重みがあれば、
説得力はまるで違うと思うよ
それと同じ次元で比較してるお前は何様なんだよって話だよ

matzと今回のkaminamiに共通するのは、動的オブジェクト指向言語の信奉者であり、
静的型や関数型に対して理解する気がない、
それなのに主観的な次元で良し悪しを論じているということ
Scala固有の話ではなく、静的型や関数型に対する偏見がまず先にある
要するに不毛だとわかってる宗教戦争を仕掛けてるのは向こう
まずは向こうが攻められるべき

151 ：デフォルトの名無しさん：2011/06/13(月) 13:23:19.49

foreachがあればfor式はいらないとか言ってるのがウケたけど
コップ本は１章割いてforの説明してるけど他で勉強するとこの程度の理解になっちゃうのかな

152 ：デフォルトの名無しさん：2011/06/13(月) 13:29:54.22

責めるとか責められるとかどうでもいいよ。
Scala勉強したいな、って思った人が勉強しやすい環境を提供してあげるのが最優先じゃないかな？
それが出来た段階でScalaを知らない人に訴求していく。

「あいつは分かってない！俺が論破してやる！」これじゃ何も得るものが無いよ。

153 ：デフォルトの名無しさん：2011/06/13(月) 13:35:58.26

Schemeは有名だけど仕事に本気で導入を考えているやつは少ないだろ。
だいたいが好きで使ってるようなやつだけだ。
Scalaはよくも悪くも、いろんなやつから注目されつつあるっていうだけ
なんじゃないかな。水島氏はそういう相手でもまじめに対応しててまぁ
がんばりやさんだと思うよ。

154 ：デフォルトの名無しさん：2011/06/13(月) 13:50:40.03

Scalaにも
PerlのCPANみたいなのがあるといいなぁ。
Rubyのgemみたいなのがあるといいなぁ。

とプロフェッショナルな人達は思わないのかな　^^;

155 ：ゆるよろ：2011/06/13(月) 14:01:55.47

maven-repositoryがあるけど分散してるし
mavenは滅びてもいいけど、maven-repositoryが滅びると現実的には困るんだが

perlやrubyやpythonや他の言語にある、「ここで調べれば欲しいもの出てくる」的な
セントラルリポジトリは、Javaのころから憧れていた理想郷

156 ：デフォルトの名無しさん：2011/06/13(月) 15:03:16.84

>>146
お前どういうtweetから始まったか見てねーだろ。

157 ：デフォルトの名無しさん：2011/06/13(月) 15:07:35.25

>>155
CPANが「理想郷」だって?
「夢の島」と言うのならまだ分かるが。

158 ：デフォルトの名無しさん：2011/06/13(月) 15:30:05.75

まずは各々がブログなりなんなりで、
「Scalaでファイルの入出力」とかレベルの記事を書いていくのが簡単で良いんじゃない？
それらを纏めるのは後からでも出来るんだし。
情報が分散して云々で何も進まないよりは生産的だと思う。

159 ：デフォルトの名無しさん：2011/06/13(月) 15:35:23.65

オダスキー文書やAkkaのドキュメント訳してくれたほうがありがたい

160 ：デフォルトの名無しさん：2011/06/13(月) 15:36:57.72

ぷセーフ

161 ：デフォルトの名無しさん：2011/06/13(月) 19:23:25.65

>>150(=146?)
反論はありがたいけど、まずはお茶でも飲んで落ち着いたほうがいいんじゃないか？あまりにも狭くなってる印象がある。

この状態なら他言語やっていてScalaに興味を持ったとしてもやりたがらない
事になりかねないぞ。実際にgoogleで"Scala 怖い"でリアルタイム検索してみ
てはどう？潜在的に何倍になってるかわからないが。b.hatenaのコメントも
よく読んだほうがいい。それが今回の騒ぎでScalaってどんな言語なのか？と
いう印象を持たれたかよく分かるだろうよ。

すぐに、二分化しちゃう思考って、考える能力を衰えさせるものだ。あまり、
敵味方みたいな発想にならないようにしたほうがいいと思うね。
そもそも、Scalaの感想を書かれたからといって、関数型への冒涜みたいな
捉え方はどうかと思うよ。

162 ：デフォルトの名無しさん：2011/06/13(月) 19:26:21.21

すぐそういう反応をしたがるはてなブクマーみたいな層を相手に右往左往するのもどうかと思うが

163 ：≠161：2011/06/13(月) 19:30:34.76

>>162
「あいつらは愚かだから無視して良い」というのも二元論的思考だけどね。
今回のことが決定的だとは思わないけど、あまり何回もこういう事が起こるのはよろしくないと思うよ。

164 ：デフォルトの名無しさん：2011/06/13(月) 19:48:39.29

だからそういう空気読めみたいなことが気持ち悪いって言ってんの
これでScala怖いなんて言っている連中はプログラミングをなめてる
これだけ材料を与えられてるのに話の真偽を見極められずに、
態度とか口調とかで物事を判断しようとする連中がエンジニアなのかと思うと泣けてくるね

165 ：デフォルトの名無しさん：2011/06/13(月) 19:49:52.23

http://ufcpp.wordpress.com/2011/06/12/%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%E7%B0%A1%E5%8D%98%E3%81%95%E3%82%80%E3%81%9A%E3%81%8B%E3%81%97%E3%81%95/

「手続き的にどう動作するか、を想像し易いのが良い言語だ」という発想が根強い現環境において、
新しい発想を掲げている言語（の一つ）がScalaなわけだ。

ただ、ここで間違ってはいけないのは、「理論的背景をシンプルに実現しているから良い言語」なのではなく、
「やりたいことを容易に実現できるから良い言語」なのだ、ということだと思う。
（ちなみに、個人的には、ここに「やりたいことを頑健に記述できる」も追加したい）

「文法が簡単か否か」という論争は、結局のところ前者のフィールドで争うことに他ならない。
個人的には、Yコンビネータを巡る話を真っ先に想起する（あれ、全然分からんｗ）。

だから、「Scalaは簡単で素晴らしい言語だ」という時には、強力なコレクション処理とか、
Optionの話とか、そういう観点から語るべきなんじゃないか。
そういう観点が無ければ、implicitなんて「抜け道」を許容する最悪な仕様でしかないわけだし。

ま、結論は「>>158に賛成」ということなんだけどね。

166 ：デフォルトの名無しさん：2011/06/13(月) 19:58:02.71

理論的背景で語ることが世の中に蔓延している風潮なら、
主観で語ることが重要だと言うことはアンチテーゼになるが
プログラミング言語を巡るほとんどの言説が感覚的なのに、
主観が重要だとあらためて言う意味はあんの？

167 ：デフォルトの名無しさん：2011/06/13(月) 19:58:51.28

>>164
俺も含めて、大半の人間は、個別の論争の是非を精査してるほど暇ではないんだよ。

もっと抽象的な言い方をするなら、自分以外の人間に、何かに対して自分と同じだけの
コミットメントを要求するのは良い態度とは言えない。
特に、ネット上の発言は、何かに対して責任を負って為されるものではない以上、なおさらね。

一人一人の人間が、何かに興味を持っていたり、持っていなかったりすることは
当然のことなのだから受け入れるべきだし、
それこそが相手の人格を尊重するということだ、と俺は思うよ。

168 ：デフォルトの名無しさん：2011/06/13(月) 20:07:19.03

>>166
当たり前だけど、そのプログラマのマインドセットと一致しない記述体系を強制しても不幸になるだけだからな。
で、新しいマインドセットを広めたいと思ってる我々の側としては、彼にそのメリットを「布教」するところから始めなけりゃならない。

そこで「悔い改めよ！」とか言って説伏させようとしても、周りから眺めてるだけの第三者にしてみれば「何あの人怖い」になるのは
避けられない。

つまり、うまくやろうぜ、ってことですよ。
我々の目的は、抗争での勝利ではなく、ハッピーなプログラミングライフでしょ？

169 ：デフォルトの名無しさん：2011/06/13(月) 20:09:22.11

>>164
松本さんが最悪手だと発言してる真意もたぶん理解できないのではないか？
たぶん、松本＝極悪のボスキャラという捉え方なのだろうよ？

コミュニケーションの問題を書いてるんだけど。異文化の人たちと会話を
成り立たそうとすれば、どんなことがあっても誤解などは当然あるよ。
それでも、話し合いが成り立つ人たちとそうではない人たちが世の中に
いるけど、後者にはならずに、考え方が違っても信頼関係が生まれる工
夫をした話し合いをしろよって事。殺伐として、対外的に強硬な態度を
とるのがよしとするコミュニティにするのが理想ならばそうすればよいが
その代償は高くつくことは覚悟したほうがいいよ。

要するにコミュニケーションにも頭を使えってこと。

170 ：デフォルトの名無しさん：2011/06/13(月) 20:29:58.42

言語の中身と関係なく水島氏の口調が怖いから
Scala使わないと考える程度の連中に対しては
無視するのが正しいコミュニケーションだと思うけど

matzの静的型ディスは前科があるから言ってることなので
ボスキャラというか、言語開発者なのによく自分から宗教戦争起こすなと思っただけで

あと、これは半分冗談だけど、別に今回の件が最悪手だとは思わない
『Scala実践プログラミング』のいい宣伝になってんじゃないの
kaminami氏に献本すればいいと思う
受け取るかどうかは知らんけどｗ

171 ：デフォルトの名無しさん：2011/06/13(月) 20:42:32.80

>>170が、日本のScalaコミュニティを、顔見知りだけの「エリート」集団にしたいと
思っているのだとしたら、俺は全く賛同できない。

このオープンソース時代に、周囲から孤立したエリートなんか目指しても、
すぐに行き詰まってしまうのは目に見えている。
「俺はエリートの一人だ、愚かな奴らとは違う」という自己満足しか残らんよ。

172 ：デフォルトの名無しさん：2011/06/13(月) 20:43:45.15

水島さんの口調が怖いと思う人は、レベルの低い技術者ということになるの？
エンジニアなら、技術的な真偽以外は気にしないとでも思ってるのかな。

173 ：デフォルトの名無しさん：2011/06/13(月) 20:45:45.53

松本は正しさで論破して打ちのめすのは逆向きマーケティングで最悪手だと言っているんだろ？
けど、俺にはRubyの方がその手のことをやっちゃう武闘派()が多いと思うんだよな。
自分の家で出来てないことを、別の家の子供に説教してる大人もどうかと思うよ。

174 ：デフォルトの名無しさん：2011/06/13(月) 20:48:28.83

>>173
他人の愚行を、自分達が真似る必要なんか無いじゃない。
俺達は、俺達だ。

175 ：デフォルトの名無しさん：2011/06/13(月) 20:55:07.23

やめて！
私のために、争いなんてやめて！！

技術的な話題には、ほとんど食いつかないのに、
政治的な話になると、食いつきすぎです！

組み込み系にC++が導入された初期のころ、
コーディングルールに、「継承はなるべくしない。」とかあったよ。

Scalaも最初のうちは、↑こういう時期が必要だろうと思う。

176 ：デフォルトの名無しさん：2011/06/13(月) 20:55:08.81

さすがにそろそろ飽きてきたなｗ
まず大前提として、はてブも2chも言語の趨勢には
全く影響がないということが意識として共有できてない気がするがｗ
だからちょっと暴論っぽく書いてるわけだし

だいたいジョブズやストールマンみたいな奇人変人が跋扈してる世界で、
なにみみっちいこと言ってんだとしか言いようがない

まあ、程度の低い意見は無視するのが正しいというのは間違いないが、
それに対して熱り立って反論するのも別に悪いことじゃないという話
それでもう俺からは終わりにします

177 ：デフォルトの名無しさん：2011/06/13(月) 21:04:58.00

奇人変人で許されるのは彼らが天才だからであって、
そうでない凡人は他人とわざわざ波風立てないようにコミュニーケション力をつけろってことだな。

178 ：デフォルトの名無しさん：2011/06/13(月) 21:19:42.70

そういう話はマ板でやれよ。
レス皆無のほうがまだまし。

179 ：デフォルトの名無しさん：2011/06/13(月) 21:21:27.73

あーうざいうざい

誰がどーしたあーだこーだって
お前らはてな民(笑)かよ

きもちわりい
まじきもちわりい

誰がどうしたって？
知らねえよそんな奴www

あーきもいきもい
芸能ニュースにかじりつくババァを見てるみたいだ

180 ：デフォルトの名無しさん：2011/06/13(月) 21:24:27.70

今日のscalaスレは、ム板のスレのなかで断トツ一位できもちわるい

181 ：デフォルトの名無しさん：2011/06/13(月) 21:26:39.93

ゆろよろさん流石っす

182 ：デフォルトの名無しさん：2011/06/13(月) 21:38:18.36

みんなLiftの作者が書いたScala本はスルーなの？あんまり話題に上がらないみたいだけど...
俺は今それで勉強してる。

183 ：デフォルトの名無しさん：2011/06/13(月) 21:40:59.64

SS本のこと？いい本だと思うよ。

184 ：デフォルトの名無しさん：2011/06/13(月) 21:47:18.74

誰か新刊買えたやついる？

185 ：デフォルトの名無しさん：2011/06/13(月) 21:51:17.01

今度はmatz vs kmizuかよ

186 ：デフォルトの名無しさん：2011/06/13(月) 21:57:11.07

SS本は応用寄りだから最初の一冊には向いてないかも

187 ：デフォルトの名無しさん：2011/06/13(月) 22:03:26.60

俺はwebフレームワーク系全く興味ないから読んでない。
Liftにも全く触れてない。

188 ：デフォルトの名無しさん：2011/06/13(月) 22:04:54.17

そうしてる間にLiftにオワコンの気配が…

189 ：デフォルトの名無しさん：2011/06/13(月) 22:24:43.10

Tomcat でJavaの資産と共存できるかどうかしか興味ない

190 ：デフォルトの名無しさん：2011/06/13(月) 22:26:04.20

>>183
Scalaプログラミング入門っていう本だ
http://beebee2see.appspot.com/i/azuYyYSKBAw.jpg

191 ：デフォルトの名無しさん：2011/06/13(月) 22:30:25.66

>>189
ハゲ同

192 ：デフォルトの名無しさん：2011/06/13(月) 22:31:11.15

liftは最近斜め上の方向へいってるからなぁ

193 ：デフォルトの名無しさん：2011/06/13(月) 22:32:26.34

3者とも本売るために相撲みたいな八百長やってるだけだぞ
裏じゃ3人仲良しこよしだぞ？

194 ：(1) ◆CgacaMDhSQ ：2011/06/13(月) 22:43:31.23

>>136
>>138
丁寧な忠告、ありがとうございます。実際の所、元々私は単なるScala好きであり、
Scalaエバンジェリスト(笑)という状態だったのですが、本当にScalaエヴァンジェリスト
であろうとするなら、おっしゃるとおり、態度を改めるべきだと思います。shiroさんは
技術的にも凄いだけでなく、やわらかい言い方で、人を説得するのが非常に上手な
ので、その点は見習いたいですね。

ちょっと長くなるので、複数レスに分割します。

195 ：デフォルトの名無しさん：2011/06/13(月) 22:48:58.24

モナドは象()だって、for文の解説でもあったのね。
初めてよんだ。(翻訳ありがとう)

196 ：(2) ◆CgacaMDhSQ ：2011/06/13(月) 22:50:03.55

> もとが複雑な言語を拡張して自由度を増やそうとした場合更に複雑な仕様になるのは自明の理なんだから、scalaが難しいということで怪気炎を上げる
>ような行動は褒められたものではないよ。

端的に言って、これは間違いです。まず、ScalaはJavaのad hocな仕様をいくつも削っています。たとえば、プリミティブ型、static, break, continue,などなど。
その上で、関数型とオブジェクト指向を統合するために必要な仕様がScalaに付け加えられました。ですから、更に複雑になるのは自明の理ではありません。
これは、別に論破したいわけではなくて、Scalaはそういう言語ではないよ、という話です。

> それより>>131さんの忠告を心から理解することが大切じゃなかろうかね？

心に刻んでおきます。

197 ：デフォルトの名無しさん：2011/06/13(月) 23:40:20.28

関数型を統合なんて言い方はおかしいよ。
関数型言語で特徴的だった機能の一部を取り込んでいるだけ。

198 ：デフォルトの名無しさん：2011/06/13(月) 23:46:03.21

なんか良く分からいけど、
Blogとか2chで、ちまちま言い争いするよりかは、
まとめサイトの記述を充実してくれた方がうれしいなあ。

たとえば、「記号が分かりにくい」みたいなのは、次のようなページみたら即解決だなあ。
http://www.ne.jp/asahi/hishidama/home/tech/scala/index.html

「Scala 日本語情報サイト」期待してます。

199 ：デフォルトの名無しさん：2011/06/13(月) 23:54:12.01

あんまり問題起こすなら
削除依頼出すよ？

200 ：デフォルトの名無しさん：2011/06/14(火) 00:31:27.00

F#のSeq
C#のyield for
みたいな機能ってScalaにありますか？

201 ：デフォルトの名無しさん：2011/06/14(火) 00:38:17.54

>>196
横レスですが、あなたはずれています。
>>65のまつもとさんのtweetが食い違いを明確に指摘しているのに
どうして「言語(ルール)の複雑さ」の話を続けるのでしょうか。

JavaやC++がオブジェクト指向という新しい概念が増えたために
それ以前の手続き型言語より覚えにくくなったように、
Scalaが関数型の概念という新しい概念が増えたために
Javaより覚えにくくなりました。
ad hocな仕様が削られて暗記量が減った事による覚えやすさは
新しい概念の理解が必要な事による覚えにくさと釣り合いません。
ですからScalaを覚えようとする人にとって
ScalaがJavaより複雑で難しい言語なのは自明の理です。

202 ：デフォルトの名無しさん：2011/06/14(火) 01:19:14.74

関数型が加わっているから複雑になるのは自明って、
それこそそんな自明な話は誰もしてないんじゃね

203 ：デフォルトの名無しさん：2011/06/14(火) 01:32:16.59

>>69 >>70 >>71
遅ればせながらありが㌧
とりあえずコップ本でscalaと恋愛してみるお

204 ：デフォルトの名無しさん：2011/06/14(火) 02:03:54.48

>>202
新しい概念を使って「構文要素をシンプルに」しているんだから、
手続き的なパラダイムにのみ親しんでいる者の視点から見れば「複雑」に見えるってことでしょ。

「プリミティブ型、static, break, continue」みたいなのは、それが以下にad hocな仕様であろうと、
広く知られている既存のC/C++的な概念に含まれてるから、学習コストはゼロで済む。
しかし、関数型パラダイムは、たとえそれがシンプルな記述を実現するものであっても、学習コストを払う必要がある。

楽園に辿り着くには、乗り越えなければならない壁があるわけで、それを無視した議論をしてもあまり意味はない。
だからこそ、関数脳本みたいな「新しいパラダイムへの導入」を目的とした書籍の役割が重要になる。

＃今度の新しい本も、Scalaプログラマとしてのレベルアップという意味ではとても期待してるけどね。

205 ：デフォルトの名無しさん：2011/06/14(火) 02:16:50.90

だからこいつらごちゃごちゃ言ってるけど
結局単に関数型がわからないだけだろってのは
俺も最初からそう思ってるけど
とか書いてたら「Scalaはオブジェクト指向言語です」か
真面目だなあ

206 ：デフォルトの名無しさん：2011/06/14(火) 02:20:40.67

>>198
そのページ、超役立つよね。
口論する暇があったら、こういう仕事をするべき。

207 ：デフォルトの名無しさん：2011/06/14(火) 02:20:45.39

>>193
炎上マーケティングという奴ですね。流行りの。

208 ：デフォルトの名無しさん：2011/06/14(火) 02:39:01.64

「オブジェクト指向プログラミングとは何か」論争みたいなもので、Smalltalk由来の
メッセージパラダイムを実現している言語が真のオブジェクト指向言語だ云々、
みたいな話に、実利的な意味があまりないのと似ている。

俺達は、要件をよりシンプルでかつメンテナンスしやすい方法でコードに落とすために、
オブジェクト指向のパラダイムを活用しているわけで、理論的な美しさや構文要素の
完成度みたいなものために使っているわけではない。

例えば、時々Javaのinterfaceを「盲腸的な仕様」だと看做す議論がなされることがあるが、
「インタフェースを決める」という作業の重要性を考えれば、
構文要素の追加を遥かに上回るメリットを持った仕様であることは、容易に理解できるだろう。

俺達は、『手続き・分岐・ループの三要素のみで理解できる言語が「シンプル」で
「実用的」な言語だ』という世の中の趨勢に対して、布教活動をしなければならないわけだ。
それをやるためには、「関数型のパラダイムで記述すると、あの面倒な記述が、
これだけシンプルでメンテしやすいものに変わるんだよ」というところを地道に見せていくしかない、と俺は思う。

209 ：デフォルトの名無しさん：2011/06/14(火) 02:42:16.57

>>179
一般的にはあんたはそのはてな民に分類されてると思うよ？

ところでこのスレで赤間世紀
http://www.amazon.co.jp/dp/4777516083
の評価出た？過去の経験からすると読む価値無しと見てるんだが、一応。

210 ：デフォルトの名無しさん：2011/06/14(火) 02:47:42.68

赤間世紀って一冊も読んだことないけど、とんでもない量の本書いてるな

211 ：デフォルトの名無しさん：2011/06/14(火) 03:00:43.28

確かに。何冊あるんだよｗ。

212 ：デフォルトの名無しさん：2011/06/14(火) 03:16:00.67

>>208
真のオブジェクト指向言語が何かというのは非常に重要な話だと思うよ
個別の言語を越えたパラダイムの世界があって、
優れた言語というのはまずそのパラダイムを過不足なく実装していなくちゃいけない
言語の流行り廃りに比べて、パラダイムというのは長いスパンの寿命を持っているし、
有用性、弱点も広く知られている
これに沿うことは目先の主観的な判断より上回るメリットが得られる

matzが口ではどう言っても、Rubyなんかは真のオブジェクト指向にめちゃくちゃ拘ってるでしょ
彼の静的型嫌いは本質的に動的でないと真のオブジェクト指向とは言えないという
原理主義的な背景があると思う

個人的な感想だけど、その点において、Scalaは
オブジェクト指向としても、関数型言語としても筋がいい
Javaの機能拡張で、かつ、プリミティブがないから静的型オブジェクト指向としては問題ない
関数型言語としては、型推論がHindley-Milner式ではないから違和感を感じる人はいると思うけど
機能としては一通りある

パラダイムを知っている人間なら、Scalaの機能が
どのパラダイムの機能なのかピンとくるようにできている
それを何もわかってないやつがごちゃごちゃとまあ(以下略)

213 ：デフォルトの名無しさん：2011/06/14(火) 03:20:40.30

>>209
書籍情報 - Scalaではじめるプログラミング
http://www.kohgakusha.co.jp/books/detail/978-4-7775-1608-7
赤間世紀の書籍
http://www.amazon.co.jp/%E8%B5%A4%E9%96%93-%E4%B8%96%E7%B4%80/e/B004L9W4Z0/

目次の底の浅さと筆者のこれまでの粗製濫造ぶりからおそらく外れ本ですね。
類書がないテーマなら粗製濫造本にも需要があるでしょうけど、
Scala入門書は良書が複数あるからこの本はスルーしてよいと思います。

214 ：デフォルトの名無しさん：2011/06/14(火) 03:31:59.53

>>212
パラダイムを知っている人間なら、Scalaの機能が
どのパラダイムの機能なのかピンとくるようにできている

ってのを、例えば何がどれとか、教えて欲しいです、先生

215 ：デフォルトの名無しさん：2011/06/14(火) 04:01:04.16

まずはそのパラダイムの常識的な用語を使ってるってことだよ
高階関数の名前が関数型でよく使われるものになっているとか

あとこのパラダイムなら当然この機能があるだろうというのがある
たとえば関数型言語においてはパターンマッチが非常に重要だけど、
知らない人間にとってはなんでそんなに重要なのかわからないかもしれない

他には、case classが代数的データ型であるとか、forがモナドであるとか、
ああOption型はMaybeのことね、とか概念を先に知っていればすぐに理解できる
まあ、この辺は知らないと難しいというのもわかる

たとえばいまどきのオブジェクト指向言語でカプセル化のための
アクセス制御がなかったらびっくりするけど、
オブジェクト指向を知らない人間には複雑に見えるかもしれない
それで「protectedって何だよ。複雑すぎるだろ、この言語」とか
言われたらイライラするだろ

216 ：デフォルトの名無しさん：2011/06/14(火) 07:24:25.98

>>212
大筋では反対ではないけど、あるパラダイムに沿った言語設計が良しとされるのは、
そのパラダイムの有用性が既に証明されているからであって、パラダイムの理論的背景
そのものが「良い」からではない、というところは間違っちゃならないと思うよ。

結局のところ、一口に「真の」といっても色々と流派があって、それぞれメリットとデメリットが
ある状況だったりするわけだし。

217 ：デフォルトの名無しさん：2011/06/14(火) 09:22:23.78

F#のSeq
C#のyield for
みたいな機能ってScalaにありますか？

218 ：デフォルトの名無しさん：2011/06/14(火) 16:21:37.59

forとIteratorを組み合わせるとそれっぽいんじゃないかと…
for(x <- Iterator.range(0, 10)) yield (x, x * x)
一回しかyieldできないからちょっと違う？

219 ：デフォルトの名無しさん：2011/06/14(火) 17:23:47.43

どちらかというとActorとIteratorじゃないの？

220 ：デフォルトの名無しさん：2011/06/14(火) 20:53:31.29

１つ質問なんだけど雑魚SmallTalker論破するけど
赤間本批判しない理由なんなの？結局、権威には逆らえないか
本を売るための売名という認識で正しい？

221 ：デフォルトの名無しさん：2011/06/14(火) 20:59:14.08

>>220
板違いだからマ板でやれ

222 ：デフォルトの名無しさん：2011/06/14(火) 21:09:56.42

権威とかの前に誰も読まんだろｗ

223 ：デフォルトの名無しさん：2011/06/14(火) 21:12:38.33

いくら糞でも読んでないものを批判するのはちょっとｗ

224 ：デフォルトの名無しさん：2011/06/14(火) 21:16:09.79

>>220
『やさしいScala入門平明な例と演習問題で学ぶ』の感想というかダメだし
http://d.hatena.ne.jp/kmizushima/20100222/1266771623
『やさしいScala入門平明な例と演習問題で学ぶ』の重箱の隅をつつく
http://d.hatena.ne.jp/kmizushima/20100222/1266824371

あなたが相手の過去記事検索すらしないで自分の妄想だけを根拠に
あいつは市販本は批判しない卑怯者だと決めつける痛い人である、
という認識で正しいと思います。

225 ：デフォルトの名無しさん：2011/06/14(火) 21:18:41.07

Scala本出すぎだよね
たぶん世界で一番出てる国なんじゃないの

226 ： ◆CgacaMDhSQ ：2011/06/14(火) 21:19:13.24

>>217
C#のyieldみたいなのは、Scalaだと限定継続、というちょっと小難しいライブラリを使えば
実現できます。ただ、一度ライブラリ作ってしまえば後は使いまわせるので、そういう標準ライブラリを
Scalaチームの人が作ってくれれば、限定継続を知らなくても良いかと思います。

>>220
本を売るための売名、という指摘はちょっと意図をつかみかねます。あと、赤間氏の
本はそもそも購入していないですし、赤間氏の本には特に権威はないかと思われます。

227 ：デフォルトの名無しさん：2011/06/14(火) 21:41:27.69

>>224
今回のも前フリってこと？

228 ：デフォルトの名無しさん：2011/06/14(火) 21:46:27.47

>>225
まえにはHaskellの本がまとめてでた時期もあるから、一種のはやりなんでしょう。実際に有利な風も吹いてる(twitterなど)もあるからね。日本の中って
右に習えが普通になってるから、どこか大手が積極的に使い出すと、右も左も
Scalaとなることはありえるよね。選択する人たちがプログラムを作る人とは
限らないし。Javaで糞コードに悩まされる人は多いけど、
同じ事は起こるんだろうね。

みなさん殺伐なのが好きみたいね。いっそのことscala-house.jpなんて
作ってみてはどうか？

229 ：デフォルトの名無しさん：2011/06/14(火) 21:49:58.86

いちいち殺伐とかうぜーな
2chをなんだと思ってんだ

230 ：デフォルトの名無しさん：2011/06/14(火) 21:52:19.82

clojureの本はあんまり出てないのは何故なんだろう？

231 ：デフォルトの名無しさん：2011/06/14(火) 21:55:20.29

>>220

お前、いったい誰とケンカしてるの？

雑魚Smalltalkerなんて誰も興味ないし、
赤間本は、このスレで批判されまくりだろ。

赤間博士は情報数学の教授って感じの人で、いろんな言語の入門書を出版しているが、
どんな言語を題材にしても同じような本になるというのが、ある意味すごい人である。

ちなみに、このスレで一番最初に赤間博士の本を発売日前に批判したのはオレだ。
批判しただけでは悪いので買ってみたが、やはり情報数学の初学者向けの本って感じがした。

232 ：デフォルトの名無しさん：2011/06/14(火) 22:01:52.90

Scala勉強会って全国いろんなところで催されているね。

Scala勉強会 in 渋谷
ttp://www.scala-users.org/shibuya/index.php?title=メインページ
Scala勉強会＠東北
ttp://sites.google.com/site/scalatohoku/
Scala勉強会＠岡山
ttp://cappuccino.jp/scala-ja/?Scala%CA%D9%B6%AF%B2%F1%A1%F7%B2%AC%BB%B3-1
天領倉敷Scala
ttp://tenryo-kurashiki-scala.appspot.com/
名古屋Scala勉強会
ttps://groups.google.com/forum/#!forum/nagoyascala
Scala勉強会＠関西
ttp://cappuccino.jp/scala-ja/?Scala%CA%D9%B6%AF%B2%F1%A1%F7%B4%D8%C0%BE-1
Scala勉強会 in 札幌
ttp://www.atmarkit.co.jp/event/calendar/detail.php?event_id=11216
Scala＠福岡
ttps://groups.google.com/forum/?hl=ja#!topic/scala-be/yY2ggf5K5Bk

233 ：デフォルトの名無しさん：2011/06/14(火) 22:04:23.60

>>230
Clojureはまだ全体的な人数が少ないところも影響してる。ここでは
Scalaとの比較は書かないが、日本のJavaの人たちから見れば先入観的にも
Scalaのほうが好きなんだろう。海外の方に目を向けると両方共プログラム
を作ってる人は多いみたいだね。planet(Clojure/Scala)ともに同じ人の
記事が出ていることはある。
それにScala以上にClojureは若い言語だよ。今年で４歳だ

234 ：デフォルトの名無しさん：2011/06/14(火) 22:07:25.85

明らかな釣りは流せよｗ

235 ：デフォルトの名無しさん：2011/06/14(火) 22:25:50.87

単に人気がなくて売れないからでしょ

236 ：デフォルトの名無しさん：2011/06/14(火) 22:42:47.15

Clojureは、オライリーから英語版の書籍が夏に出るところ。
S式慣れ親しんでる(教え込まれてる)のは、CS系の人間ばかりなので
非CS系IT技術者が多い日本では、あまり興味もたれないとおもう。
海外でも、最近はML系が多いしね。

237 ：デフォルトの名無しさん：2011/06/14(火) 22:43:26.13

Scalaって関数言語の韓国だな。

238 ：デフォルトの名無しさん：2011/06/14(火) 22:46:14.84

クライアントサーバー？？

239 ：デフォルトの名無しさん：2011/06/14(火) 22:46:57.50

Scala=AKB48

240 ：デフォルトの名無しさん：2011/06/14(火) 22:51:54.24

ちなみに、最強の俺流言語はCLなので、若くて俺流極めたい人には、Clojureはメインにならんらしい。

海外でClojure好きの会社は、
Relevance, BankSimple, BackType, FlightCasterといったところ。
あとはCascalog(Hadoopデータマイニング)使ってるデータマイニングエンジニア

241 ：デフォルトの名無しさん：2011/06/14(火) 22:52:57.61

和洋折衷なら日本だな。

242 ：デフォルトの名無しさん：2011/06/14(火) 22:58:15.89

ScalaDays2011のレポート
http://el.jibun.atmarkit.co.jp/kaigaiengineer/2011/06/scala-days-2011-4018.html

を見ると、
VMwareやAmazon.comも、Scalaを使い始めた？

243 ：デフォルトの名無しさん：2011/06/14(火) 23:21:35.31

http://www.indeed.com/jobtrends?q=SML,Haskell,Groovy,Scala,Clojure
Clojureは海外でも純粋関数言語ぐらい普及した所で伸び悩んでいます。
Scalaは順調に普及し続けています。
Groovyの普及はScalaより2年先行しています。

http://www.indeed.com/jobtrends?q=SML,Haskell,Groovy,Scala,Clojure,Ruby
Rubyの普及はGroovyより5年先行しています。
Scalaは大手の支援がなくてもRubyの普及ペースは達成しそうですが、
もっと爆発的に普及して名実とともに次世代Javaになって欲しいですね。

244 ：デフォルトの名無しさん：2011/06/14(火) 23:33:34.71

>>243
http://www.indeed.com/jobtrends?q=SML%2CHaskell%2CGroovy%2CScala%2CClojure&relative=1
リレイティブも見たほうがいいんじゃない？

245 ：デフォルトの名無しさん：2011/06/14(火) 23:49:32.73

Groovyこんなに普及してるのか？なんか、日本では実感ないな。
Java FXより少し上程度かと思ってた。

246 ：デフォルトの名無しさん：2011/06/15(水) 00:25:40.96

Webフレームワークで結構使われてる。
Javaライブラリのプロトタイピングにも便利だし。

247 ：デフォルトの名無しさん：2011/06/15(水) 00:36:15.03

つーか、tomcat でいいじゃん…

248 ：デフォルトの名無しさん：2011/06/15(水) 00:39:19.47

えっ

249 ：デフォルトの名無しさん：2011/06/15(水) 00:52:17.66

おっおっおっ

250 ：デフォルトの名無しさん：2011/06/15(水) 01:27:53.71

Groovyっててっきり滅んだもんだと思ってた

251 ：デフォルトの名無しさん：2011/06/15(水) 01:50:07.26

GroovyってCI周りで使われている印象あるけど、そんなに人口いなそうな気もする。Scalaも狙えるDSLっぽい設定やテスト、スクリプトとかだよね。
http://www.slideshare.net/kohsuke/jenkins-groovy

252 ：デフォルトの名無しさん：2011/06/15(水) 01:58:16.03

http://groovy.codehaus.org/Using+Testing+Frameworks+with+Groovy
ここらへんか

Web上の出現率を表す？TIOBEだと、
Javaが1位、Scalaが50位以内で、Groovyが100位以内、Clojureは圏外

253 ：デフォルトの名無しさん：2011/06/15(水) 02:10:50.40

おお、50位以内に復活したか

254 ：デフォルトの名無しさん：2011/06/15(水) 12:42:14.76

clojure ,パズルといてるみたいで面白いけどねー。
byflowくらいしかclojureでつくられたとこ知らん。

255 ：デフォルトの名無しさん：2011/06/15(水) 13:15:49.16

GroovyやClojureなどの動的な言語は安全性を重んじるJavaの文化にあわないんじゃないか。
それらはJavaが嫌いな人が使っているだけで、ポストJavaという感じがしない。

256 ：デフォルトの名無しさん：2011/06/15(水) 13:55:12.63

せやな

257 ：デフォルトの名無しさん：2011/06/15(水) 20:54:21.45

ところで
プリミティブ型、static, break, continue
が有って困る事って何？

ちなみにヘタレプログラマはどんな機能があろうがなかろうがヘタレ。

258 ：デフォルトの名無しさん：2011/06/15(水) 21:02:59.76

Scalaって、Javaのライブラリ使えるのはメリットだけど、
逆に、Javaのライブラリ使えるから、
Scala用のライブラリをわざわざ作らない＆公開しない傾向にある気がする。

弱点なような。

259 ：デフォルトの名無しさん：2011/06/15(水) 23:16:05.01

>>257
言語としての一貫性の話じゃないかな。

>>258
Java用のだと、やはりScalaの作法とズレてるから、作り直しの需要はあるっちゃある。

260 ：デフォルトの名無しさん：2011/06/16(木) 00:36:46.09

実践本売ってないな

261 ：デフォルトの名無しさん：2011/06/16(木) 01:01:07.05

今日ぢゃないの？

262 ：デフォルトの名無しさん：2011/06/16(木) 01:43:18.01

金曜の勉強会の行きがけにでも買うつもり。

263 ：デフォルトの名無しさん：2011/06/16(木) 17:38:07.56

装丁ダサいな
駄目本オーラがすごい
中身はまだ読んでない

264 ：ゆるよろ：2011/06/16(木) 17:55:26.30

すいません

265 ：デフォルトの名無しさん：2011/06/16(木) 18:55:59.57

明日頃にはこのスレでもタイポの指摘がでてくるかな。#shuwa_scala

266 ：ゆるよろ：2011/06/16(木) 19:30:30.57

typoしてｺﾞﾒﾝﾅｻｲ

267 ：デフォルトの名無しさん：2011/06/16(木) 20:16:14.26

Wikipediaの例ひどい
再帰的じゃない構造に再帰呼び出しさせて何の意味が

268 ：デフォルトの名無しさん：2011/06/16(木) 20:49:40.26

帰納的に定義されているから再帰を使って書くというふうにやりたいんだけど
末尾再帰にしようと思うとそうならない場合が多いね
このへん軽くジレンマというか、再帰の例を作る難しさという感じ

269 ：デフォルトの名無しさん：2011/06/16(木) 21:03:41.97

本屋に並んでたよー
買わなかったけど

270 ：デフォルトの名無しさん：2011/06/16(木) 21:15:19.09

Amazonの謎の登録はなんなの
これ、Amazonで売れる系の本でしょ？

271 ：デフォルトの名無しさん：2011/06/16(木) 23:31:50.23

>>267
別に対象が再帰的な構造じゃないループを再帰で書いていいと思うが？
文字列は再帰的な構造とまったく言えないわけでもないし。

ただ、
・コード構造が繰り返し版と対象になってないので対比がしにくい
・単純すぎてScala的でない。再帰のwikipedia項目に任せればいい単純すぎる例。
ってところが問題だろう。繰り返し版に合わせるとすると、

　 def hasA(i:Int, s:String):Boolean = {
　 if(i < s.length) {
　 if(s(i) == 'a') return true
return hasA(i + 1, s)
}
return false;
　 }

か。

272 ：デフォルトの名無しさん：2011/06/17(金) 02:01:15.90

まだ買ってないからわからんけど
わざわざreturn書いたりelse使ってないのは意味あるの？

273 ： ◆CgacaMDhSQ ：2011/06/17(金) 02:41:30.26

>>272
赤間氏の本の話でしょうか？

274 ：デフォルトの名無しさん：2011/06/17(金) 02:56:03.00

WikipediaのScalaの項目のくだらない話だから気にしなくていい

275 ：デフォルトの名無しさん：2011/06/17(金) 08:57:20.38

例の本発売日前から予約してたのに入荷しねーメールが届いたのでキャンセルなう。
オモシロかったら教えてくれ。本屋にでも探しに行くから。

276 ：デフォルトの名無しさん：2011/06/17(金) 09:09:10.91

再帰的な構造に対する再帰ならむしろ末尾再帰にならない（ことが多い）。
たとえば2分木の左の枝に対してまず再帰したら、そのあと右の枝に対しても
再帰するわけで、末尾再帰には普通はならない（末尾再帰にしようとするなら
継続渡しとかになる）。

きれいに末尾再帰になるのは、単方向リストの処理とか、単純なループ状の
繰返しを再帰にするような場合。

277 ：デフォルトの名無しさん：2011/06/17(金) 10:03:31.30

>>276
> たとえば2分木の左の枝に対してまず再帰したら

末尾じゃないのに末尾再帰になるわけないだろw

278 ：デフォルトの名無しさん：2011/06/17(金) 10:11:09.42

>>277
再帰は通常末尾じゃない、
っていう話じゃないの？

279 ：デフォルトの名無しさん：2011/06/17(金) 11:21:32.07

Scala関係ないな。

280 ：デフォルトの名無しさん：2011/06/17(金) 12:58:42.69

関係あるけどScalaに限定された話じゃないな

281 ：デフォルトの名無しさん：2011/06/17(金) 18:55:55.91

Scalaは末尾再帰じゃないと最適化してくれないんじゃなかったっけ

282 ：デフォルトの名無しさん：2011/06/17(金) 18:58:13.03

それは違う。
末尾再帰に「末尾再帰の最適化」という技法がある、というだけで、
末尾再帰じゃなきゃダメ、というものではない。

283 ：デフォルトの名無しさん：2011/06/17(金) 19:08:34.48

というかJVMはtail jumpサポートしてないから、
tail jumpする処理系作りたければ独自スタック管理。
効率目指してtail jump導入してもかえって遅い。

284 ：デフォルトの名無しさん：2011/06/17(金) 21:19:40.57

赤間本良質過ぎて感動した。

285 ：デフォルトの名無しさん：2011/06/17(金) 21:28:00.96

一方ロシアはループを使った

286 ：デフォルトの名無しさん：2011/06/17(金) 21:35:22.28

Scalaのmapとかもループ使ってるしね

287 ：デフォルトの名無しさん：2011/06/17(金) 21:39:05.89

tail jumpなんて言葉聞いたこと無いぞと思ってググったら発見
http://twitter.com/functional2ch
ここの書き込みを転載しているBot

288 ：デフォルトの名無しさん：2011/06/17(金) 21:44:34.24

そのBot、検索の邪魔になるから消えてほしい

289 ：デフォルトの名無しさん：2011/06/17(金) 22:35:28.67

俺も検索してみたら、一つ目が、
> FAIRY TAIL - JUMP大好きっ娘です！
orz

290 ：デフォルトの名無しさん：2011/06/17(金) 22:49:33.74

tail-recursive jumpと
tail jumpは違うの？

291 ：デフォルトの名無しさん：2011/06/17(金) 22:56:21.48

tail call/tail jumpは再帰に制限されない。
return f()の形の呼び出しは行きっぱなし。
戻ってきても返値をバケツリレーするだけだし。

ただJVMではclass verifierにおいて、stack増減もチェック対象なので、
tail callを入れるのはかなり大掛かりな改造になる。
LLVMは既に入ってる。

292 ：デフォルトの名無しさん：2011/06/18(土) 12:14:27.08

まったりScala実践プログラミング読んでるにょ。
コップ本読んだけど、一応基礎部分も通読しとくかー、と思って読んでるんだけど…。

P26,P27のfor文の例、間違ってね？
P27のScalaコードは、Javaと同じ結果を期待するのなら
val xs = List(0,2,4,6,8)
val ys = List(1,3,5,7,9)
for(x <- xs; y <- ys; if x > 3; if y > 4) yield x + ":" + y
という記述にして(二つめのifでxとy間違ってない？)、
結果も
List(4:5, 4:7, 4:9, 6:5, 6:7, 6:9, 8:5, 8:7, 8:9)
になるんじゃないのこれ？

あと、P25について細かい事なんだけど、
for( n <- 0 to 10 if n % 2 == 0;if n % 4 ==0 ) {print( n + "' "}
って、一つめのifの条件、すごく意味ないよね…。
なんで互いに素である2と3とかにしなかったの？

…うーん、これは…なんか不安になってきたぞ。
やはり秀和クオリティは伊達じゃなかったか…？

293 ：デフォルトの名無しさん：2011/06/18(土) 12:25:50.58

>>292
読んでるにょ(笑)

にょ(笑)

ばかじゃね

294 ：デフォルトの名無しさん：2011/06/18(土) 12:27:57.71

読んでるにゅ

295 ：デフォルトの名無しさん：2011/06/18(土) 12:45:38.00

フヒヒ、サーセンｗｗｗ
ｷﾓｵﾀなんでつｗｗｗ

P34にも2つスペルミス発見…。
val str = new String("aaa")"
fref? fret?

P28のチェック例外のが採用されなかった理由は一言理由について言及すべきだよね。
P33の高階関数の初歩の説明で
def int2EvenOrOddString(f:(Int)=>Boolean, n:Int)={
　if(f(n)) "偶数" else "奇数"
}
ってのは関数のネーミングがちょっと良くないよね…。(というか、返す値を"真","偽"ぐらいにすべきじゃね？)

うおおおおおおおぉぉぉぉぉぉぉぉ………！！！！！！！

296 ：デフォルトの名無しさん：2011/06/18(土) 12:46:48.51

ああ、興奮してて俺もミススペルしたぜ。

でもこれ、まともに校正されてないでしょ…。

297 ：デフォルトの名無しさん：2011/06/18(土) 13:32:04.71

あれ、sbtってもうみんな0.10に移行してんの？

298 ：デフォルトの名無しさん：2011/06/18(土) 14:23:36.05

移行しようとしてんだけど、プロジェクト定義のフォーマットがだいぶ変わって、
しかもその対応がよくわからんから移行できないでいる。
定義のエントリの間に空行入れないと文句言うし、
かと言って依存するライブラリの List のエントリでは空行入れるとダメだったり。
DefaultWebProject も plugin になってからうまく動かないし。

299 ：(1) ◆CgacaMDhSQ ：2011/06/18(土) 16:15:36.19

>>292
まず、1件目はバグです。これは全く申し訳ないしか言いようがありません。

> for( n <- 0 to 10 if n % 2 == 0;if n % 4 ==0 ) {print( n + "' "}

については、共著による弊害というかなんというか…。意味が無いというのは
ご指摘の通りです。

> やはり秀和クオリティは伊達じゃなかったか…？

その辺りは、一通り読んで判断していただければ。実際の所、共著の弊害として、
章・節ごとに内容・品質にばらつきがあります。本の末尾に執筆分担があるので、
その辺りを参考にしていただければと思います。

300 ：(2) ◆CgacaMDhSQ ：2011/06/18(土) 16:16:29.83

>>295

> P28のチェック例外のが採用されなかった理由は一言理由について言及すべきだよね。

その辺りについては、あえて言及すべきだったかどうかは、微妙なところです。

> def int2EvenOrOddString(f:(Int)=>Boolean, n:Int)={
>　 if(f(n)) "偶数" else "奇数"
> }

これはその通りですね。よろしくないネーミングです。

>>296
校正はされてます。ただ、校正の方法に問題があったのは確かです。その点については申し訳ない、としかいえません。

301 ：デフォルトの名無しさん：2011/06/18(土) 19:12:56.84

空の場合もあるIteratorから先頭の一要素を取り出したいときって
iterA.toTraversable.headOption
がベストかな？

>>298
同じく

302 ：デフォルトの名無しさん：2011/06/18(土) 20:07:03.70

> iterA.toTraversable.headOption

IteratorをtoTraversableすると、実際はStreamになってるみたいだが、
そのちょっとした無駄なオブジェクトが生成されることを気にしなければ、短くかけるしそれでいいんじゃないのかな

303 ：デフォルトの名無しさん：2011/06/18(土) 20:14:13.51

Streamってリソース無駄遣いで問題有りすぎるだろ

304 ：デフォルトの名無しさん：2011/06/18(土) 20:43:01.14

ite.find(true)
なんてどうだろ

305 ：302：2011/06/18(土) 21:18:31.10

http://bit.ly/kQhsgz

>>303
リソース無駄遣いというのがどういう意味で言ってるのか知らないが、
Iteratorのコードは上記の様になっていて、
Stream.consは2番目の引数は遅延評価されるから、どんなにIteratorのサイズが大きくても、
Streamを生成する時間がO(n)になるわけではなく、定数時間しかかからないはず。
という意味で「ちょっとした無駄なオブジェクト」と言ったんだが。

それさえもったいないなら、IteratorのhasNextを直で呼んで調べる的な方法になる

＞＞304
コンパイル通らないよ？

306 ：デフォルトの名無しさん：2011/06/18(土) 21:31:24.62

意図を汲んでやれよ

307 ：デフォルトの名無しさん：2011/06/18(土) 21:31:27.25

>>302
ソース読んでなかった…

Iteratorのみで書くなら>>304もいいですね
scala> "hoge".iterator.find(_ => true)
res0: Option[Char] = Some(h)

308 ：デフォルトの名無しさん：2011/06/19(日) 00:56:27.58

>>299
レスありがとうございます。

うん、でもこの1件目のバグはかなりアウトやでぇ…。
「開発とデバグ終わりました。エビデンス取りました。」
で、エビデンスが間違った結果出してたのに納品したレベル…。

とりあえず通読する予定です。
何かおかしいと思ったらまた書くわ。

＞秀和クオリティ
翔泳社・オームなんかと比べると、あま～い仕事してる気がするよ…。
罵倒した所でいい仕事が出来るようになるかっていうと違うんだけど、
「これ目通してないだろ？」っていうレベルのものが頻出するとちょっとね…。
版を改めずに刷で改められないかな？

ごめんね、文句ばっかりで。
俺も一人前のScala戦士として前線に立てるように頑張るから…。

309 ：デフォルトの名無しさん：2011/06/19(日) 01:27:47.48

>>299
ぶっちゃけすぎだろ。
共著者にバカがいるってことかよ…

310 ：デフォルトの名無しさん：2011/06/19(日) 01:43:02.62

>>309
しーっ！

311 ：デフォルトの名無しさん：2011/06/19(日) 09:35:17.19

>>309
オレにもそう読めた。
著者の一人が書く事じゃないよな。

312 ：(2) ◆CgacaMDhSQ ：2011/06/19(日) 10:58:28.10

>>309
>>311
いや、そういう意図ではありません。
共著であり、チェック体制に若干問題があったために(これは、もちろん詳細はかけません)、そういう部分が残ってしまった、
という反省です。内部の事情についてはさすがに書かないようにしています。書き方がまずかったです。末尾に各執筆者の
担当箇所一覧があるとはいえ、基本的に書籍の間違いについての責任は、共著者の共同責任だと考えています。

313 ：(3) ◆CgacaMDhSQ ：2011/06/19(日) 11:09:16.42

ちょっとあらためて。

・共著だから自分の担当箇所以外についてのミスの責任は自分には無い、とは考えていない。
・ただし、チェック体制に若干問題があったので、書籍としての品質については、担当者ごとにばらつきがあります。
・私の担当箇所以外でミスがあったことについて、その著者がどうとかそういう憶測はやめていただけると助かります。これは自分の書き方がまずかったですが。
・ミスの指摘には可能な範囲でお答えします

314 ：(4) ◆CgacaMDhSQ ：2011/06/19(日) 11:15:08.99

>>308
1件目については、これはほんと平謝りするしかないです。改めて製本版を
通読しましたが、これ以降、このレベルの間違いは無かったので、大丈夫かと思います。

＞「これ目通してないだろ？」っていうレベルのものが頻出するとちょっとね…。
＞版を改めずに刷で改められないかな？

その辺りは検討してみます。ただ、少なくとも正誤表には皆様のご指摘は可能な限り反映します。

315 ：(4) ◆CgacaMDhSQ ：2011/06/19(日) 11:20:49.79

あと、これはお願いなのですが、ミスの指摘だけでなく、内容についての感想も書いていただけると助かります。
ミスは確かに問題ですが、それ以上に重要なのはコンテンツだと思うので。

316 ：デフォルトの名無しさん：2011/06/19(日) 12:37:04.27

誤解されることをつい書いちゃう様な気の利かない人だから
共著担当関係なくそういうクオリティになるんだろ

317 ：デフォルトの名無しさん：2011/06/19(日) 14:32:10.56

つか2chに書き込むのは控えた方がいいと思うがな。

318 ：デフォルトの名無しさん：2011/06/19(日) 15:01:14.10

>>317
Scala初代スレを立てた人に「2chを控えた方が」はいまさら過ぎると思います。

319 ：デフォルトの名無しさん：2011/06/19(日) 15:16:51.49

2chの方が別人のふりして書き込めるから便利だと思うの。

320 ：デフォルトの名無しさん：2011/06/19(日) 15:55:06.32

プログラムは嘘か本当かすぐに自分のPCで確認できるから2chで十分

321 ：デフォルトの名無しさん：2011/06/19(日) 18:40:02.34

>>318
Scalaスレを立てた人は◆CgacaMDhSQ じゃないよ。ソースは以下の講演
ttp://www.nicovideo.jp/watch/sm2902315

322 ： ◆CgacaMDhSQ ：2011/06/19(日) 19:34:04.71

>>317
やっぱそうですかね。2chユーザであっても本を買ってくれたお客さんだから
指摘には対応したいな、とか思ってしまうのですけど、それで誤解を
招く発言しちゃうようなら、2chで発言しない方がいいですね…
アドバイス通り、しばらく2chはROMに徹しておきます。

323 ：デフォルトの名無しさん：2011/06/19(日) 20:00:48.03

お疲れさま。
余裕があるならROMらずに発言して善導してもらいたいけどね。

＞2chユーザであっても
なめんなよ、と言えよう。
ここもコミュニティの一つとして扱った方がいいと思うよ…。
あなたが出てくる必要なないかもだけど、低く見てるのが透けて見えちゃう発言は良くないと思われ。

P58の上の方のソース記述部分の補助コンストラクタって、
new HttpURL(host,port,path)じゃなくて
new HttpURL(host, path)なんじゃねーの？

あとP144のコードの例なんだけどさ
|n = 1;
|println(n); //1
|m = n;
|n = n + 1;
|println(m); //2になる言語があるか？
って書いてて、その後に
＞中にはそのような「変態的動作」を行う言語もきっとあるでしょう
とか書いてるけどさ、…これは論理変数がdisられてるのかな…？

324 ：デフォルトの名無しさん：2011/06/19(日) 20:07:18.06

ごめん
名無しのくせに態度でかかった。
反省してる…

325 ：デフォルトの名無しさん：2011/06/19(日) 20:21:34.13

やっきどーげざっ！
やっきどーげざっ！

326 ：デフォルトの名無しさん：2011/06/19(日) 20:37:35.31

>>321
大変失礼しました。
その動画も見たのに記憶が改竄されていました。
初代スレを立てたのは石田さんですね。
初代スレが立ったころ水島さんはScalaを理解済みです。

http://web.archive.org/web/20070709180014/http://www2.coins.tsukuba.ac.jp/~i021216/diary/
水島さんがScalaの記事を書き始める。(2007/06)
http://d.hatena.ne.jp/syttru/20080305/1204733669
石田さんがScalaに興味を持つ。
http://pc12.2ch.net/test/read.cgi/tech/1205156417/
石田さんがScala初代スレを立てる。 (2008/03/10)
http://d.hatena.ne.jp/syttru/20080314/1205341962#c
水島さんが石田さんにScala文法を解説する。

327 ：デフォルトの名無しさん：2011/06/19(日) 20:59:10.91

俺と同じ性格っぽいから、言及されてると返答しないではいられない、
みたいな気持ちは分かるけど、一覧性の意味でも、その辺は自分の
サイトでまとめて書いた方がいいんじゃないかな。

どうせ、ここを見てる連中ならサイトの方も見てるだろうしｗ

328 ：デフォルトの名無しさん：2011/06/19(日) 22:04:13.90

日本のscalaコミュニティは育ちそうにもないなｗ

329 ：デフォルトの名無しさん：2011/06/19(日) 22:41:52.80

>>323
Prologならn=n+1がfailするから無問題

330 ：デフォルトの名無しさん：2011/06/19(日) 22:52:32.23

>>323
C++でmがリファレンス型だと2になるな。

ただ宣言と定義を同時にしないといけなくて、
参照先の変更は不可能だから、字面上はそうならないが。
int& m = n; となる。

331 ：デフォルトの名無しさん：2011/06/19(日) 23:46:46.35

scalaの暗黙の型変換で実現できそうな気がする

332 ：デフォルトの名無しさん：2011/06/19(日) 23:52:55.71

Scala難しいから一般向けじゃないよね

333 ：デフォルトの名無しさん：2011/06/20(月) 00:40:07.44

>>323
なんかうざい

334 ：デフォルトの名無しさん：2011/06/22(水) 20:36:35.24

…これはウザい発言がdisられてるのかな…？

335 ：デフォルトの名無しさん：2011/06/22(水) 23:42:47.82

沈黙の型変換

336 ：デフォルトの名無しさん：2011/06/23(木) 23:23:13.73

Javaのころは、
なにがなんでも、Setter、Getterメソッド書けって言われました。

でも、Scalaでは、Setter,Getterは書かないよね。

どうして？

なぜ、Javaでは、クラスのフィールドに直接アクセスするのが悪とされてたの？

337 ：デフォルトの名無しさん：2011/06/23(木) 23:27:52.51

書かなくても定義されるとか？

338 ：デフォルトの名無しさん：2011/06/23(木) 23:53:07.49

Javaでも

class MyClass{
int a;
}

MyClass m = new MyClass();
x = m.a ;
m.a = y;

というように、書かなくてもget,setできるけど、どうちがうの？

339 ：デフォルトの名無しさん：2011/06/24(金) 00:03:20.57

なんかのフレームワークだか、公式のドキュメントだったか、ツールの関係だった気がする

340 ：デフォルトの名無しさん：2011/06/24(金) 00:06:22.19

>>338
EffectiveJavaを買って読んでみよう！

341 ：デフォルトの名無しさん：2011/06/24(金) 00:17:06.18

>>336
自分で書かなくていいってだけで
外部に公開される変数を宣言したら自動でsetter/getterが定義されてる
直接変数に代入してるように見えるのはsetter呼び出しのシンタックスシュガー

class MyClass {
var a: Int = _
}

val m = new MyClass()
val x = m.a
m.a = y

上のように書いたら実際は下のように展開される

class MyClass {
private[this] var aa: Int = _
def a = aa
def a_=(value: Int) { aa = value }
}

val m = new MyClass()
val x = m.a
m.a_=(y)

342 ：デフォルトの名無しさん：2011/06/24(金) 00:34:34.55

>>341

ありがとうさぎ。

でも、それって、Javaでも同じじゃないの？
Javaも自分で書かなくても、setter/getter できるでしょ。

>338の

x = m.a ;
m.a = y;

みたいなのは、自動でsetter/getterが定義されているのと違うの？
もちろん、
・Javaでは、自動setter/getter 定義しているわけでない。
・Scalaでは、自動setter/getter 定義されていて、シンタックスシュガーで、そうかける。
というのは良く言われていることだけれども、
両者の違いって、なんなの？

Scalaの自動setter/getter って Javaのpublicフィールドに直接アクセスするのと比べて
何がうれしいの？

343 ：デフォルトの名無しさん：2011/06/24(金) 00:50:13.30

C#の自動プロパティでも、確かに楽ですむけど
なら結局これってpublicフィールドとどう違うんだよ
という議論があったね。

344 ：デフォルトの名無しさん：2011/06/24(金) 01:03:29.59

>>342
じゃあ仮に、後になってaは0より大きい数値でなければいけないとなったとする

class MyClass {
private[this] var aa: Int = _
def a = aa
def a_=(value: Int) {
require(value > 0)
aa = value
}
}

と修正するだけでOK。呼び出し側は修正の必要がない。
Javaでpublicフィールドに直接アクセスしてた場合、メソッド呼び出しに書き換える必要がある

345 ：デフォルトの名無しさん：2011/06/24(金) 01:10:27.38

>344
IDE使えよ。

346 ：デフォルトの名無しさん：2011/06/24(金) 01:18:51.62

修正しなくていいってことはコンパイルし直さなくていいってことだろ

347 ：デフォルトの名無しさん：2011/06/24(金) 01:19:40.66

フィールドをメソッドにかえたら呼び出し側はリコンパイルが必要
最初からメソッドにしとけば中身が変わっても呼び出し側はリコンパイルが不要になる
なのでScalaの見た目はフィールドだけど実際はメソッドって方が変化に強いはず
ちなみにC#のフィールドもプロパティにかえたら呼び出し側はリコンパイルが必要

348 ：デフォルトの名無しさん：2011/06/24(金) 07:53:42.52

>>342
Effective Java読めつってんだろ

349 ：デフォルトの名無しさん：2011/06/24(金) 08:34:17.10

Dire Wolf DigitalでScalaプログラマ募集してるね RT @functionaljobs: Full-time: Java / Scala Developer at Dire Wolf Digital (Denver, CO) http://bit.ly/lUvtfx

350 ：デフォルトの名無しさん：2011/06/24(金) 20:02:43.25

スカラってやっぱり冗長だなと思った。もっと簡潔に書けるんかな？
scalaでプログラムは組んだことがないんでよく知らん。だけど、無
限ストリームを使って、他の言語でよく取り入れられてるフィボナッチを
作ってみた。でも型宣言が足を引っ張ってる感じがある。
この手のストリームを作るときにはかえって足かせになってるのかもな。

scala> def ite (f:(Tuple2[Int,Int])=>Tuple2[Int,Int],t:Tuple2[Int,Int]):Stream[Tuple2[Int,Int]]=Stream.cons(t,ite(f,f(t)))
ite: (f: ((Int, Int)) => (Int, Int), t: (Int, Int))Stream[(Int, Int)]

scala> def fib (t:Tuple2[Int,Int]):Tuple2[Int,Int]=(t._2,t._2+t._1)
foo: (t: (Int, Int))(Int, Int)

scala> ite(foo,(0,1)) take 10 print
(0,1), (1,1), (1,2), (2,3), (3,5), (5,8), (8,13), (13,21), (21,34), (34,55), empty

mapを使って第一要素だけ取り出したら完了だけど、scalaのmapはまだ知らんので
こうやって見てると、一応関数型言語の心は少しは持ってるとは思う。

351 ：デフォルトの名無しさん：2011/06/24(金) 20:07:33.81

こうやって作ってみると、haskellの影響はかなり感じるけど、haskellほど
洗練されてないという印象も持ったな。

352 ：デフォルトの名無しさん：2011/06/24(金) 20:24:46.55

scala> Stream.iterate((0,1)){case (a,b) => (b,a+b)}.take(10).toList
res0: List[(Int, Int)] = List((0,1), (1,1), (1,2), (2,3), (3,5), (5,8), (8,13), (13,21), (21,34), (34,55))

scala> Stream.iterate((0,1)){case (a,b) => (b,a+b)}.map(_._1).take(10).toList
res1: List[Int] = List(0, 1, 1, 2, 3, 5, 8, 13, 21, 34)

こんなのも
def fibFrom(a: Int, b: Int): Stream[Int] = a #:: fibFrom(b, a + b)

参考URL
http://eed3si9n.github.com/scala-collections-doc-ja/

353 ：デフォルトの名無しさん：2011/06/24(金) 20:26:09.36

ちなみにTuple2[Int,Int]は(Int,Int)って書いてもいいんよ

354 ：デフォルトの名無しさん：2011/06/24(金) 20:27:31.81

こっちだわ
http://eed3si9n.github.com/scala-collections-doc-ja/collections_14.html

355 ：デフォルトの名無しさん：2011/06/24(金) 20:41:50.49

http://lmgtfy.com/?q=scala+fibonacci

356 ：デフォルトの名無しさん：2011/06/24(金) 21:03:03.15

Haskell様がやって来たときには全力でスルーして耐え忍ぶ
OCaml野郎がやってきたときにはここぞとばかりに反撃にでる

357 ：デフォルトの名無しさん：2011/06/24(金) 21:11:18.73

>>352-355
さんきゅう
やはりもっと簡潔にかけるね。

358 ：デフォルトの名無しさん：2011/06/24(金) 21:13:18.80

ちなみにiteってのはiterateを意識してますねん。
だから、タプルからタプルを返す関数ならなんでもおｋです。
>>352をみると::でそれを実現してんねんな。

359 ：デフォルトの名無しさん：2011/06/24(金) 22:03:49.53

iteを短く書くにはこうすりゃいいよ
def ite[A](f: A => A, start: A): Stream[A] = Stream.cons(start,ite(f,f(start)))

Stream.iterateの再発明になったけど

360 ：デフォルトの名無しさん：2011/06/25(土) 01:48:08.20

>>359
ありがと。皆さんのアドバイスに色々勉強になりました。
Stream.iterateってあるんですね。どうせあるんだろうなとは思ってたんですよ
（なければないでまずいような関数ですしね。）

361 ：デフォルトの名無しさん：2011/06/25(土) 01:52:50.34

lazy val fs:Stream[Int] = 0 #:: fs.scanLeft(_+_)

362 ：デフォルトの名無しさん：2011/06/25(土) 01:53:59.22

間違えた
lazy val fs:Stream[Int] = 0 #:: fs.scanLeft(1)(_+_)

363 ：デフォルトの名無しさん：2011/06/25(土) 04:58:57.94

みんな凄いな...
全く分からん

364 ：デフォルトの名無しさん：2011/06/26(日) 08:57:38.91

代数データ型が貧弱すぎる。もっと色々な代数データ型をデフォルトで用意すべき。
そうでないと相変わらず set, seq, map, タプルとかから作り上げることになる。
いろんなGraphの代数データ型とかデフォルトで用意しろー＞おだ

365 ：デフォルトの名無しさん：2011/06/26(日) 14:04:45.31

そんな使用者層の偏ったデータ型追加してったらきりがないだろうな
自分勝手なクレーマーの典型例を見た

366 ：sage：2011/06/26(日) 14:26:36.37

>>364

そんなに必要だと思って自信があるなら、自分でライブラリ作って、
それを本家にマージしてくれって言うくらいのことやってみればいいんじゃないの?

367 ：デフォルトの名無しさん：2011/06/26(日) 20:01:05.05

基礎がなかなか身につかん！

// 何かの関数
def func () = {
　　println("in the func()")
　　"executing func()"
}

// 名前渡しされる関数
def hoge(f: => String) = {
　　println("in the hoge()");
　　f
}

実行すると↓
scala> hoge(func)
in the hoge()
in the func()
res33: String = executing func()

hoge関数の引数のところは、「Stringを返す関数をfという名前で受け取る」
っていう認識であってる？

あと、
def piyo(f:Int => String) = f(10)
っていうのも名前渡しになるんだよね？
この場合はの引数の意味は「Intを引数に取って、Stringを返す関数を、fという名前で受け取る」
ということ？

368 ：デフォルトの名無しさん：2011/06/26(日) 23:25:27.23

>>367
それはどちらも値渡しだと思う

369 ：デフォルトの名無しさん：2011/06/27(月) 00:11:11.97

>>367
名前渡しは、引数に渡した式を評価せずにそのまま関数に渡し、
関数内で参照するたびに式を評価するという方式。

引数の式がその場では評価されず、
hoge()内でfが参照された時点で評価されるため、
以下のような結果になる。

scala> hoge({println("in the arg");"executing arg"})
in the hoge()
in the arg
res0: String = executing arg

しかし、piyo()では引数を評価せずに渡しているわけではなく、
あくまで評価した結果の関数を渡しているだけなので、
名前渡しではない。
(違いが分かりやすいようにpiyo()を改変している)

scala> def piyo(f:Int=>String) = {println("in the piyo()");f(10)}
piyo: (f: (Int) => String)String

scala> piyo({println("in the arg");_.toString})
in the arg
in the piyo()
res1: String = 10

370 ：デフォルトの名無しさん：2011/06/27(月) 00:40:41.67

>>367
>hoge関数の引数のところは、「Stringを返す関数をfという名前で受け取る」
>っていう認識であってる？

f は引数を取らないので関数ではない。(内部的には関数で実装されているかもしれないが)
hoge() 内の f の後ろに () を追加するとエラーになることからも、関数でないことは明らか。
あくまで参照するたびに式が評価される特殊な String だと考えるのが無難だと思う。

371 ：デフォルトの名無しさん：2011/06/27(月) 01:21:33.68

>>367
> 　　f

returnが省略されているからややこしいのかもしれないが、
単に引数fを返り値にしているだけだぞ。
ただ名前渡しだから、その時点で評価されるというだけ。

372 ：デフォルトの名無しさん：2011/06/27(月) 03:24:46.34

>>367
名前渡しは実装上では
Function0のシンタックスシュガー

def hoge(f: Function0[String]) = {
println("in the hoge()");
f()
}

hoge( new Function0[String] {
override def apply() = func()
})

のように展開される

373 ：デフォルトの名無しさん：2011/06/27(月) 11:28:55.91

thunkっていう昔からの実装方法だな。
ただ自由変数とか細部まで、実装方法で操作的に把握しようとすると、
結局ややこしいので、名前渡しをちゃんと理解するのがいい。

374 ：367：2011/06/27(月) 14:58:24.82

みんな色々ありがとう！
教えてもらったことを咀嚼してるけど正直まだよく分かっていない。ごめん。
取り合えず今読んでる本を最後までちゃんと読み切ってみることにした。
そうすれば過程で感覚的に分かることもあるだろうし、それをさらに深めていく。

375 ：デフォルトの名無しさん：2011/07/02(土) 00:35:08.03

名前渡しを実装方法でもって理解しようとすると、 >>373 が書いてるように、
かえってややこしくなるだけなので、概念を理解するのが良いと思う。実際にややこしくなる例：

class RichAny[T](block: => T) {
　def until(cond: => Boolean) {
　　while(!cond) block
　}
}

implicit def enablePostUntil[T](block: => T): RichAny[T] = new RichAny(block)
var i = 0
{ println(i); i+= 1 } until (i > 10)

こんなもん誰もつかわねーよと言われそうだが、Streamは実際にこのテのimplicit conversion(consWrapper)使ってる。

376 ：デフォルトの名無しさん：2011/07/07(木) 07:43:43.41

隣の言語はherokuでサポートされたらしいね。

377 ：デフォルトの名無しさん：2011/07/08(金) 04:27:05.25

もうすぐ、Java7がリリースされるけど、
Windows環境では、OracleのVM を使った方が速いのかな？

378 ：デフォルトの名無しさん：2011/07/08(金) 08:26:57.61

IBMが提供するVMの付加価値として速度面での改良が挙げられているが、どうだろうね

ttp://www.ibm.com/developerworks/jp/java/library/j-java7.html?ca=drs-jp

起動が早いってのはfscやsbt使わない人には嬉しいかも

379 ：デフォルトの名無しさん：2011/07/08(金) 09:20:54.92

JRockit使うってのは？

380 ：デフォルトの名無しさん：2011/07/10(日) 09:48:58.85

Java7は、JRockitも付いてくるみたいね

381 ：デフォルトの名無しさん：2011/07/10(日) 10:32:02.94

HotSpotとJRokitの統合ってどこまでできてるんだっけか？

382 ：デフォルトの名無しさん：2011/07/10(日) 10:50:47.20

JRokitって有償版のみ提供なの？

383 ：デフォルトの名無しさん：2011/07/10(日) 11:15:39.91

>>380
今度のJava SE(まだ6)から付いてくる。
>>381
別のJVM実装として付いてくる。
>>382
報道を読む限り全てに付いてくる。
有償のみ付いてくるのはJRockitの開発運用系ツール。

続きは別のスレか板でやってね。

384 ：デフォルトの名無しさん：2011/07/10(日) 14:45:53.32

あれ、xsbtってもうstableになったの？

385 ：デフォルトの名無しさん：2011/07/10(日) 23:06:12.12

0.10でstableになったよ

386 ：367：2011/07/11(月) 04:43:18.80

Scala用のwebフレームワークってLiftとPlayの2つがメジャー？

387 ：デフォルトの名無しさん：2011/07/11(月) 05:30:03.38

あとScalatraと、最近なんか話題になってたよな、Unfilteredだっけ
どんなもんか知らんけど

388 ：デフォルトの名無しさん：2011/07/11(月) 08:38:23.13

Liftはかなり勉強したが結局好きにはなれなかった。Playは面白いけど、ただそれだけって感じ。

389 ：デフォルトの名無しさん：2011/07/11(月) 08:40:41.45

じゃあどれつかえばいいんだよう

390 ：デフォルトの名無しさん：2011/07/11(月) 09:48:00.95

Liftが圧倒的ユーザ数なんでまずLiftで。
圧倒的と言っても相対的な事でマイナーだし。
他はもっとマイナーってこと。

391 ：デフォルトの名無しさん：2011/07/11(月) 23:07:50.07

Scalatra 派生の Bowler
Play! を許すなら grails も Scala plugin がある

392 ：デフォルトの名無しさん：2011/07/16(土) 17:23:42.60

liftは他に選択肢がないからつかってたケース多そうだけどどう？

393 ：デフォルトの名無しさん：2011/07/16(土) 21:18:39.06

Lift - scala独自
http://oss.infoscience.co.jp/scala/liftweb.net/
play scala - Rails風
http://playscalaja.appspot.com/
この二つは日本語のサイトあるんだね
Scalatra - Sinatra風
Sinatraは薄いからScalateなどと一緒に使う

394 ：デフォルトの名無しさん：2011/07/18(月) 01:49:45.54

高階関数の「中」で何かエラーが起きた時に、それを外に伝えるにはどうすればいいんだろう。

("" /: lines) { (acc, line) =>
　acc + line match {
　　case "hoge" => "hage"
　　case _ => // エラーなのでfoldLeftの外にそのことを伝えたい
　}
}

395 ：デフォルトの名無しさん：2011/07/18(月) 02:21:55.67

例外か継続を使うしかないでしょうな

396 ：デフォルトの名無しさん：2011/07/18(月) 14:37:21.23

foldLeftを使わずに自前で末尾再帰するとか

397 ：デフォルトの名無しさん：2011/07/18(月) 15:03:21.29

あらかじめforallでエラーが起こりそうかチェックしとくとか
それが無理なパターンならEither型使うとか

398 ：デフォルトの名無しさん：2011/07/18(月) 15:59:10.76

>>4
あんまりいいサイト見つからなかったけど…
http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

399 ：デフォルトの名無しさん：2011/07/18(月) 17:14:37.15

どんだけ亀やねん

400 ：デフォルトの名無しさん：2011/07/18(月) 20:58:39.83

>>394
エラーが起きた時点で、残りの計算が必要でない、無意味なら例外、
とりあえず全部計算したいなら Either だろうね

401 ：394：2011/07/19(火) 06:39:42.26

よく考えると、多重ループからの脱出問題の類似になるんだね。
だとすると、計算コストが問題にならない場面なら例外を使うことになるのかな。

Scalaってgotoやbreakはないよね。。

402 ：デフォルトの名無しさん：2011/07/19(火) 07:44:03.73

>>401
breakable

403 ：デフォルトの名無しさん：2011/07/20(水) 00:39:38.43

>>402
breakableも、内部的には例外をスローしてやってるんじゃ？

404 ：デフォルトの名無しさん：2011/07/20(水) 08:40:20.75

そうだよ
https://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_0_1/src//library/scala/util/control/Breaks.scala#L60

405 ：デフォルトの名無しさん：2011/07/20(水) 22:26:41.13

限定継続で実装したbreakを颯爽と置いていく神はまだですか？

406 ：デフォルトの名無しさん：2011/07/21(木) 00:51:32.79

このスレ的にはKotlinってどうよ

407 ：デフォルトの名無しさん：2011/07/21(木) 01:02:12.82

なにそれ、おいしいの？

408 ：デフォルトの名無しさん：2011/07/21(木) 04:00:01.18

コトリン？可愛い名前だな

409 ：デフォルトの名無しさん：2011/07/21(木) 04:07:32.84

今まさに彼の方がハッシュタグ付きで語っておられるではないか！

410 ：デフォルトの名無しさん：2011/07/21(木) 12:12:05.75

もっとメジャーになってから飛びつくことにするよ

411 ：デフォルトの名無しさん：2011/07/21(木) 17:25:15.31

Scalaに飛びついてる奴が何染みったれたこと言ってんだ

412 ：デフォルトの名無しさん：2011/07/21(木) 18:42:19.32

.net scalaのことが公式ページにでてるね。

413 ：デフォルトの名無しさん：2011/07/21(木) 21:17:24.97

使い物になるレベルだといいな、今までも一応Scalaは.netでも使えるってふれ込みだったけどアレだったし

414 ：デフォルトの名無しさん：2011/07/22(金) 08:17:14.30

>>412
でも英語たからなんて書いてあるかんからないね。

415 ：デフォルトの名無しさん：2011/07/22(金) 13:32:28.08

EclipseのプラグインでJavaみたいに使ってるクラスをショートカットで自動的にインポートしてくれる機能ってある？

416 ：デフォルトの名無しさん：2011/07/22(金) 22:19:34.44

つまるところ、Microsoftがfundしてくれるという話は真実だったというわけか。

417 ：デフォルトの名無しさん：2011/07/23(土) 00:06:13.12

限定継続のgotoも結局は例外投げるよね

418 ：デフォルトの名無しさん：2011/07/23(土) 00:34:10.43

例外投げないgotoも作れまっせ。
こっちはスタックオーバーフローするけどね…。
https://gist.github.com/1099680

419 ：デフォルトの名無しさん：2011/07/23(土) 03:27:23.21

今回のscala for .netは、ikvm使ってるみたい？
昔ながらのikvmで動的にトランスレート+scala向けの機能追加なのか？
それともilasmにコンパイル出来るのか？

420 ：デフォルトの名無しさん：2011/07/23(土) 10:07:34.22

http://www.atmarkit.co.jp/fdotnet/chushin/comparedataproc_01/comparedataproc_01_02.html
このページの内容、ホントはScalaだとStreamクラス使えばいい、って理解でいいのかな？

421 ：デフォルトの名無しさん：2011/07/23(土) 16:44:46.43

StreamかIteratorか継続使ってyield実装するかのどれかでしょうね

422 ：デフォルトの名無しさん：2011/07/23(土) 22:28:16.53

scalacに対してはfscがあって、VMの起動を省略してコンパイルを高速に行える。
だけどscalaコマンドの高速版（fs?）はないのかな？

423 ：デフォルトの名無しさん：2011/07/23(土) 23:02:11.65

Scalaって難しいと思うんだけど、
おまえらの学歴ってどんな感じなの？

生物系の学部卒の日曜プログラマには、難しいかなぁ。

424 ：デフォルトの名無しさん：2011/07/23(土) 23:30:08.58

いや、別に難しくないと思うけど。習得に使ってる本かHPが良くないんじゃ…

425 ：デフォルトの名無しさん：2011/07/23(土) 23:36:01.58

>>423
機械系の学部卒の底辺プログラマでもやってるから気にすんな。
学歴とか関係ねぇ、多分。

とか言っても情報系院卒とかいう人にはコンプレックス持っちゃってるな、自分…。
スタートラインが違いすぎて…。

426 ：デフォルトの名無しさん：2011/07/23(土) 23:36:47.42

たった6年しか差がないじゃん。

427 ：デフォルトの名無しさん：2011/07/23(土) 23:37:17.14

Fランニート

428 ：デフォルトの名無しさん：2011/07/23(土) 23:43:34.13

>>426
そう思うだろ？
でも自分、大学までPC触った事ほとんど無くて、彼らはかなりの数が小学生から触ってたりするんだぜ…。
6年の差、どころか10年以上の差があると感じてるんだぜ…。密度の濃い10年以上の差が。
しかも自分は引きこもってて多留してるから余計にコンプレックスです。

ごめんなさい最近Scala触ってないです。
実践Scalaのデザインパターンの章面白かったです。

429 ：デフォルトの名無しさん：2011/07/24(日) 00:58:50.98

Scalaはイテレータないからな
これじゃメジャーになれないよ

430 ：デフォルトの名無しさん：2011/07/24(日) 01:33:05.71

>>429
あるものを無いといってもネタにすらならないなあ

431 ：デフォルトの名無しさん：2011/07/24(日) 07:10:17.51

>>428
就職してから初めてスターエンジニアやってる人もいるんだから、
まだまだこれからだよ。

432 ：デフォルトの名無しさん：2011/07/24(日) 07:27:51.78

馬鹿同士が励まし合うスレ

433 ：デフォルトの名無しさん：2011/07/24(日) 11:24:24.96

Ceylon最強だなぁ

434 ：デフォルトの名無しさん：2011/07/24(日) 12:16:54.64

>>428
プログラミングなんて「正しい考え方」が身についてるかどうかだ。
何年やってても、スパゲッティコードを量産してドヤ顔してる奴なんていくらでもいる。

435 ：デフォルトの名無しさん：2011/07/24(日) 15:34:46.71

>>434
俺がそれだな
最近良いコードと設計って何だろうってのが本当に分からなくなってきた

436 ：デフォルトの名無しさん：2011/07/24(日) 18:58:28.57

まずはコードを短く書けばいいんだよ
最小のサイズで書かれたコードが駄目なことはほとんどない
だから言語も短く書けるものを選んだほうがいい

437 ：デフォルトの名無しさん：2011/07/24(日) 19:14:05.94

んなこたぁない。
重要なのは、見た時に意味が明瞭なこと。

長いコードが駄目なのは、見た時に意味が分からないからであって、
意味もなくワンライナーで書かれたコードもやはり有害。
特に変数名は、多少長くなってもその変数が置かれた文脈において、
意味が明確であるようにつけるべき。中途半端に省略しようとすべきではない。

438 ：デフォルトの名無しさん：2011/07/24(日) 19:28:22.73

その意味で、過度なポイントフリースタイルの利用はよくない。
関数型っぽくてカッコいいいけど、そのコード片が何をしているのか分からなくなる。
これは、複雑な正規表現が暗号みたいになってデバッグ不能になるのと似ている。

呪文を操る魔術師（ウィザード）を気取りたいなら別だけど、それは俺の見えないところでやってくれ。

439 ：デフォルトの名無しさん：2011/07/24(日) 19:32:30.64

あと、今思いついたこと。

変数名が長くなるのは、それが属しているコードブロックが扱おうとしている処理の範囲が広すぎて曖昧だから、だな。
だとすれば、変数名を短くしたいなら、そのコードブロックの位置づけを見直せばいい。

440 ：デフォルトの名無しさん：2011/07/24(日) 19:38:58.35

言語の話をするなら、既知の概念をシンプルに記述できるのが良い言語。

コレクション操作を考えてみればいい。
Javaのfor文まみれのコードと、Scalaの高階関数を使ったコード、どちらがシンプルだろうか。

これは、単純に人間がコードをタイプする量を少なくすることとは全く違う。
ネットに転がっているScalaで書かれたコードを見ると、
変数名を過剰に省略したり、ワンライナーで書いてドヤ顔しているものを散見するが、
Scalaの記述力は、そういうことをするために使うものではない。

441 ：デフォルトの名無しさん：2011/07/24(日) 19:55:19.30

scalaにfor文があるのはその方が可読性が高いから

442 ：デフォルトの名無しさん：2011/07/24(日) 20:12:21.46

くだらね

443 ：デフォルトの名無しさん：2011/07/24(日) 20:22:50.34

>>440

>ワンライナーで書いてドヤ顔

これは同意。
あれはワンライナーでどれだけ書けるかっていうゲームを楽しんでいるものだろう。
俺もそういうゲームには興味がない。

> 変数名を過剰に省略したり、

この辺は、昔と今でパラダイムシフトがあったところ。
最近は、変数名は、短ければ短いほど良いとされている。

長い変数名をつけなければいけないようなコードは、たぶん、全体設計がうまく行っていない。
この辺は、>>439 も言っていることだと思う。

変数名は長く、、っていうのは、昔の言語は、いちいちそういうのを気にする必要があったから。
変数名が短くても良いように、言語の記述力が上がってきたからね。
C言語からC++になった時、あるブロック内で完結しているローカルな変数は、
短ければ短いほど良いはずなのに、いちいち長い名前つけている人がいるねえ。。
( Ｃ言語はブロックのスコープが広くなりがちだから、長い変数名で区別する必要があった。)

＞Javaのfor文まみれのコードと、Scalaの高階関数を使ったコード、どちらがシンプルだろうか。

C言語の時代では、コレクション操作は自分で配列のインデックスを意識してfor文回すのが美しいとされてきたものだねえ。。

時代によって、良いコード・良い設計の指標は変わるものである。

444 ：440：2011/07/24(日) 21:19:53.88

>>443
> C言語の時代では、コレクション操作は自分で配列のインデックスを意識してfor文回すのが美しいとされてきたものだねえ。。

データがメモリ上でどう展開されているのか、意識したコーディングが要請されていた時代の産物だなぁ。
ソフトウェアの複雑さが上がるに伴って、下のレイヤを抽象化することが必須になったことで、変わらざるを得なくなった。

445 ：デフォルトの名無しさん：2011/07/24(日) 21:25:11.07

Cでは今でも美しい > for文回す

美しさはその言語が提供する抽象化レベルや構文の一貫性などに依存する

446 ：デフォルトの名無しさん：2011/07/24(日) 21:30:47.78

どちらにせよ、OSやデバイスドライバを書かないプログラマには関係のない話だな。

447 ：440：2011/07/24(日) 22:04:53.89

>>445
なるほど、自分がやろうとしているのが何か、によって、良いコードの定義が違うのだなあ。

ところで、>>438の言うところの、
「過度なポイントフリースタイルの利用はよくない。」っていうのは分かる気がする。
( PointfreeってＨａｓｋｅｌｌ界隈の言葉らしいけど、Ｓｃａｌａでもそう言うのか？)

クラスによるオブジェクト指向が流行った時、変なクラス設計する人が多くて萎えた。
下手にクラス使っても、関数に比べて遅くなるだけだしね。
でも、ＧｏＦのデザインパターンで手本が提示されることで、有効なクラスの使い方が皆書けるようになった。

Ｓｃａｌａも、何か指針が欲しいところだね。

448 ：デフォルトの名無しさん：2011/07/24(日) 22:12:15.72

Functional Programmingのデザインパターンというのも一応話題にはのぼってるんですね。

http://goo.gl/HEJ4V

449 ：デフォルトの名無しさん：2011/07/24(日) 22:41:42.11

コードを短く書けというと、わかりづらいから駄目とか、
Perlのワンライナーがどうのこうのと反論するやつが必ずいるよな
あえてコードを長く書いてまでわかりやすさに拘るとか、
そんなに自分の主観に自信があるのかね

大体変数名とかワンライナーとかは瑣末な話であって、
名前は統一されていればよいし、ワンライナーくらい好きに書かせてやれよ
よっぽど変態的でない限り読めないほうが悪い

まず全体でコードが最小になる設計をして、
そこからトレードオフで拡張性や速度を考慮していくというのが
筋のいい考えでしょう

最初から自分の主観のわかりやすさなんかを優先するのは信じられないね
と言うとオブジェクト指向のメタファー全盛の時代では反動的なのかな

450 ：デフォルトの名無しさん：2011/07/24(日) 23:07:16.40

>>449
チーム開発とかしたことない人間が言いそう

451 ：デフォルトの名無しさん：2011/07/24(日) 23:09:46.43

>>450
彼は自分の主観に自信があるのさ

452 ：デフォルトの名無しさん：2011/07/24(日) 23:25:31.78

関数型だって、長らくわかりづらいとか難しいとか主観的にディスられてきたのに、
よくまだ暗号とか魔術的とかそういうこと言えるよ
自分の知らないイディオムじゃないかとは思わないのかね
過渡期にありがちだから、まあ、いいけどさ

453 ：デフォルトの名無しさん：2011/07/24(日) 23:27:38.35

>>452
いきなりどうしたの？

454 ：438：2011/07/24(日) 23:28:14.59

>>447
> Pointfree

昔、偉いHaskellerの人が使ってて「ふーん」と思った。
「ああいうコーディングスタイル」をうまく表す言葉を他に知らないから、
Scalaでも使っていいんじゃないかな。

http://www.haskell.org/haskellwiki/Pointfree

455 ：デフォルトの名無しさん：2011/07/24(日) 23:34:46.09

>>449 >>452
これまで、コード行数を最小化する方向に振っていいことなんか一つも無かった、
とプログラミング歴十数年の俺が言ってみる。

それが必要なイディオムなら、名前をつけてドキュメントをきちんと整備するべき。
「みんなが知らないイディオムを駆使してる俺カッケー」って悦に入りたいだけなら、
俺には関わらない場所で一人でやってて欲しい。

456 ：デフォルトの名無しさん：2011/07/24(日) 23:47:19.81

>>455
へーそれは意外だね
よほどプログラマの腕の差がある職場なんだろうね
低レベルのほうに合わせなきゃいけないのは勘弁願いたいところだ

関数合成だって、そのうち平気でみんな書くようになるかも知れんぜ？

まあ、俺も2.8が出たときに、関数型言語なのに標準ライブラリが
こんなに読みづらいのはいかがなものかとここに書いたことあったけどねｗ

457 ：デフォルトの名無しさん：2011/07/24(日) 23:51:55.40

>>456
それなら、君のやるべきことは二つのうちのどちらかだ。

『「低レベルの奴と一緒に仕事をする気はない」と宣言して、必要な知識を持ったプログラマだけを集める』か、
『低レベルの人間でも理解できるようにドキュメントを整備する』か。

まぁ、この先もずっと一人でコードを書き続けるなら、今のままでもいいんじゃない。
俺の職場やオープンソースには来ないでくれよ、迷惑だから。

458 ：デフォルトの名無しさん：2011/07/25(月) 00:01:33.01

>>457
たぶん俺と君では職場のレベルが違うのだろう
そこらにあるオープンソースのプログラムなら十分高レベルだよ
大抵こういう仕事だと、わかりづらく圧縮されたコードに悩まされるより、
糞みたいなコードを書き直したら何分の一になったとかそういうほうが
多いもんだと思ったがそうではないようだ

まあ、俺は、良い設計がわからなくなったという>>435に
シンプルなアドバイスを書いただけだから、君との論争は本位ではない
ここで終わりにするよ

459 ：デフォルトの名無しさん：2011/07/25(月) 00:31:29.51

なんか世間はこの記事で盛り上がってるみたいだな
http://www.atmarkit.co.jp/fdotnet/chushin/comparedataproc_01/comparedataproc_01_01.html
世間というか例によってあの方だが

460 ：デフォルトの名無しさん：2011/07/25(月) 01:46:32.88

Scalaのfor式は、仕様チェックしないで記事書く人にはトラップだよな

461 ：デフォルトの名無しさん：2011/07/25(月) 06:37:22.37

昨日、kmizu氏と延々とやり取りしてたな。

462 ：デフォルトの名無しさん：2011/07/25(月) 06:41:57.99

>>458
それは大いにやればいいんだが、コミュニケーションを拒絶するようなやり方は、
やはり問題があるという、それだけのことだよ。

コードは単なるロジックの塊ではなく、設計図であり、またコミュニケーションの媒体なんだよ。
コードの意図を読み取れない人間が多いなら、他の手段で意図を補足するのが、
コミュニケーションとして良いやり方。

463 ：デフォルトの名無しさん：2011/07/25(月) 08:24:58.11

>>436のいう事をあくまで設計時の話だと解釈して、
モジュール内のコードをそれぞれ最小化できるように、モジュールを構成(設計)するって話なら、指針の一つとしてはまあいいんじゃないかな？
ここでいう最小化は可読性を損なわない範囲でってことな。どこまでやったら損なわれるかは、使ってる言語やら現場の文化やらで変わってくるけどな。

464 ：デフォルトの名無しさん：2011/07/25(月) 12:36:52.83

@m_k28

465 ：デフォルトの名無しさん：2011/07/25(月) 13:01:51.92

鬱陶しい。

466 ：デフォルトの名無しさん：2011/07/25(月) 17:24:05.22

>>463
>使ってる言語やら現場の文化やらで変わってくるけどな。

同意。

最近、統一したコーディングルールを厳密に守って記述するなんてばかばかしいってことに気付いた。

割とコーディングルールがきっちり決められているJavaでさえ、
プロジェクトごとに独自ルール設定しているものだよ。

極端な話、１ソースファイルごとにコーディングルール別々にしても、全然可読性は損なわれないし、
プロジェクト全体に対して迷惑かけることもない。

ここで、俺様が、過去10年間読んだ中で、もっとも影響を受けた読み物(2分で読める)を紹介する。

コーディングスタイルの常識をぶち壊せ
http://codezine.jp/article/detail/3055
http://codezine.jp/article/detail/3055?p=2

ということで、この論争の元である>>435 に対する答えとしては
「435が何をやるかによって良い設計の基準が変わる」、のだから自分が美しいと思うとおりに設計すればOK！
っていうことで、どうかな？

467 ：デフォルトの名無しさん：2011/07/25(月) 19:04:16.32

>>436
だったらClojureにおいで。Scalaよりずっと短く済む。
率直に言ってScalaもオブジェクト指向なんて使わずに書けるところを
増やせば簡潔に書けるようになるんじゃないかと想像してるがどうなん？
特に、Scalaに敵意を持ってるわけじゃないんで誤解されちゃ困るんだが。

468 ：デフォルトの名無しさん：2011/07/25(月) 19:08:19.28

もうちょっと補足しておくと、最初は簡潔に書いて作って、そのあと
プロファイルしながら、高速化していくってのが関数型プログラミング
のいいところだと思うんだけどね。関数にいきなり複雑な操作を加えようと
してつくろうとしたところで簡潔にはならないし、デバッグも難しくなるし
さっさと作れる関数型プログラミングの良さは出ないんだよな。

469 ：デフォルトの名無しさん：2011/07/25(月) 19:16:23.27

ClojureがScalaよりずっと短く済むだと？
それはさすがに具体例を挙げてもらわんとただでは帰さんぞ

470 ：デフォルトの名無しさん：2011/07/25(月) 19:27:04.21

>>469
常識だと思ってたんだけど、ちょっと考えれば分かるやん。
括弧と中括弧の使い方だけでも全然ちゃうのに。

一応例を示しとくけど、
http://www.bestinclass.dk/index.clj/2009/12/clojure-vs-ruby-scala-transient-newsgroups.html
https://gist.github.com/256367

471 ：デフォルトの名無しさん：2011/07/25(月) 19:29:15.56

また補足しとくけど、scalaをdisる気はないんで、これでコメントを控えときますわ。

472 ：デフォルトの名無しさん：2011/07/25(月) 19:34:26.85

括弧と中括弧の使い方というのはよくわからんし、常識だとも思わんが、その記事はちょっと読んでみるわ

473 ：デフォルトの名無しさん：2011/07/25(月) 19:44:24.22

型宣言が不要な分短くなるのは確かだろうけど、せいぜいそれくらいでは？
両方とも似たような高階関数持ってるし、サポートしてるデータ構造に
ついても、大して変わらんし。マクロをうまく活用できる人なら、確かに
「ずっと短く出来る」かもしれんが。

474 ：デフォルトの名無しさん：2011/07/25(月) 20:11:52.17

closureが他と比べて短いのはここだね。

(defn distribution [items]
(persistent!
(reduce #(let [lowcase (.toLowerCase #^String %2)]
(assoc! %1 lowcase (inc (%1 lowcase 0)))) (transient {}) items)))

(defn process-newsgroups [dir]
(let [format #(str-join \newline (map (fn [_] (str-join \tab _)) %))
data (reduce #(merge-with + %1 %2)
(pmap #(distribution (re-seq #"\w+" (slurp* %)))
(filter #(.isFile #^File %)
(file-seq (java.io.File. dir)))))]
(spit "/home/lau/Desktop/alphabetical" (format (sort data)))
(spit "/home/lau/Desktop/decending" (format (sort-by val > data)))))

しかし、最速なのはpythonなのが意外。

475 ：デフォルトの名無しさん：2011/07/25(月) 20:26:45.27

>>466
俺はこれだな
http://www.artima.com/weblogs/viewpost.jsp?thread=74230
読んだのはBest Software Writingちゅー本の中でだけど。

476 ：デフォルトの名無しさん：2011/07/25(月) 20:50:28.07

>>466
誤爆してたので
ttp://codezine.jp/article/detail/3055?p=2
switch(month){
case 1: tsuki= "一月"; koyomi= "睦月"; break;
case 2: tsuki= "二月"; koyomi= "如月"; break;
case 3: tsuki= "三月"; koyomi= "弥生"; break;
case 4: tsuki= "四月"; koyomi= "卯月"; break;
case 5: tsuki= "五月"; koyomi= "皐月"; break;
case 6: tsuki= "六月"; koyomi="水無月"; break;
case 7: tsuki= "七月"; koyomi= "文月"; break;
case 8: tsuki= "八月"; koyomi= "葉月"; break;
case 9: tsuki= "九月"; koyomi= "長月"; break;
case 10: tsuki= "十月"; koyomi="神無月"; break;
case 11: tsuki="十一月"; koyomi= "霜月"; break;
case 12: tsuki="十二月"; koyomi= "師走"; break;
default: tsuki= ""; koyomi= ""; break;
}
こんな単純な処理ならマルチステートメントなんか使わずに構造体の配列にしろよ馬鹿

477 ：デフォルトの名無しさん：2011/07/25(月) 20:51:00.12

>>474
元ブログも読んだんだけどさ。結局
１．Clojureのライブラリの関数名が(Scalaに比べて)短いので行数節約できてる
２．ClojureがScalaとかに無いライブラリ使ってるので短くなってる
３．Clojureバージョンは一時変数使わないようにしてるので短くなってる
これだけにしか見えんのだが。なんかトリッキーなマクロ使って短くしてる
かと思っただけに拍子抜け

478 ：デフォルトの名無しさん：2011/07/25(月) 20:51:35.12

>>474
> しかし、最速なのはpythonなのが意外。

pythonは軽い処理は意外と速い。
ユーザ定義データ構造少し複雑になると遅い。

http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php

479 ：デフォルトの名無しさん：2011/07/25(月) 21:19:46.18

>>477に同意
http://www.bestinclass.dk/index.clj/2009/09/scala-vs-clojure-round-2-concurrency.html
これなんかもそうなんだけど、結局ライブラリの違いでしかないんだよな
どうせ書くならマクロでどれだけ短くなるかを書いて欲しいわ
Scalaにもコンパイラプラグインはあるけど、マクロみたいに気軽に使えるものでは無いし

480 ：デフォルトの名無しさん：2011/07/25(月) 23:33:10.93

Scala と Clojure のどちらも一通りなめてみたけど、
自分も、表現力や問題の本質をシンプルに記述する、
という点では Clojure に軍配が上がるかな、という印象。

Scala は、もともと複雑になりがちな継承ペースの OO をフルサポートしつつ、表現力を高める ( 関数型的な表現も可能にする ) ために、
更に implicit などが導入されて、
どうしてもややこしくなってしまっている ( コーディング中に考慮しなければならないルール、暗黙の前提が多い ) という印象。
複数のパラダイムをサポートしつつ、
型安全を得るためにはしょうがないのかなあ。

とはいえ、 Scala を学ぶのは楽しい。

481 ：デフォルトの名無しさん：2011/07/25(月) 23:44:39.89

Scalaはいかにもインテリの作った言語って感じ

482 ：デフォルトの名無しさん：2011/07/26(火) 00:50:38.00

行数が少々多い、少ないってのはどうでもいいけど
「表現力や問題の本質をシンプルに記述する」で差があるのは気になるな
RubyやScalaもいいとこいってると思うので、どこらで差がついてるんだろ

>>470みたいな比較だとScalaにioライブラリがないのがもろに響くなw

483 ：デフォルトの名無しさん：2011/07/26(火) 01:03:28.96

>>482
S式は偉大なのさ♪

484 ：デフォルトの名無しさん：2011/07/26(火) 01:53:02.97

うぜえ

485 ：デフォルトの名無しさん：2011/07/26(火) 02:55:34.95

うぜえ

486 ：デフォルトの名無しさん：2011/07/26(火) 07:57:59.62

めずらしく幼稚な反応だ♪

487 ：デフォルトの名無しさん：2011/07/26(火) 12:36:03.67

Scalaみたいな言語は、数値科学演算の分野に合いそうな気がする。

MatlabとかScilabは文法的に限界に来ているからね。
ScilabとかはVer６で従来のMatlabライクな文法を捨てるって公言しているし、
この機会に、Scalaとか採用してほしいなあ。

ScilabとScalaって結構合うと思うんだ。
ScilabはJava(JVM)で大半書かれているし。
ScalalabとScilabが協力してくれれば、、。

488 ：デフォルトの名無しさん：2011/07/26(火) 12:57:56.92

Rとかjavascriptに近くなったりしてな。なんちゃってJavaに
なるのは喜ぶのは一部だけっしょ。

489 ：デフォルトの名無しさん：2011/07/26(火) 21:32:50.39

>>488
なんちゃってJavaが嫌ならIncanterで良いのでは？
http://incanter.org/
>Incanter is a Clojure-based, R-like platform for statistical computing and graphics.

Scalalabは型を書かせる代りに速いのが売りでしょう。
http://swik.net/scalalab
>scalalab provides the ScalaSci scripting engine,
>based on the new Scala programming language,
>that obtains scripting speed by resolving method calls at compile time (“statically typed”).
>The scripting code is extremely fast, close to Java,
>and about 20-40 times faster from equivalent Matlab .m scripts!

490 ：デフォルトの名無しさん：2011/07/26(火) 21:34:06.01

@m_k28鬱陶しい

491 ：デフォルトの名無しさん：2011/07/26(火) 22:43:58.86

>>489

まず、
Matlabって、数値計算では有名なソフトだけど、商用。
クーロン版は、３つくらいある。OctabとFreeMatとScilab。
他の２つがMatlabの完全互換を目指しているのに対して、
Scilabは独自路線を進もうとしている。
組み込み関数が異なるのはもちろん、基本文法も、ちょっと違う。

で、今のMatlab系文法はそろそろ限界にきている。
１）実行速度が遅いし、
２）ちょっと複雑なのを書こうとするとクラスとか書きたくなる。
実際、Matlabでクラスとか疑似実現している人はたまにいるけど、
仮想関数の実現がクラスの識別を文字列比較してからメソッド呼び出しみたいに
やるので、普段から遅いのが、さらに遅くなって使えない。

と、これまでは、スレ違いなんだけど、
Scilabは、一部Javaで書かれているだけあって、Javaとの連携は強いということろが重要。

JavaからScilabを呼び出したり、ScilabからJava呼びだしたりできる。

。。。。ということは、Scalaとの連携も容易にできるはず、、、、。
もっと言えば、ScalalabとScilabが連携してくれれば、やれることが無茶苦茶広がるのだが、、。

492 ：デフォルトの名無しさん：2011/07/26(火) 22:51:16.87

Rとまったく同程度の機能を持った
Scalaのライブラリ無いですか？
Rの腐った実装は使い物にならない

493 ：デフォルトの名無しさん：2011/07/26(火) 23:52:29.78

SCALAコミュって大門軍団って感じがする。
COLT使わんの？>>492

494 ：デフォルトの名無しさん：2011/07/27(水) 01:43:22.59

>>492
Rより機能が少ないJava用数学ライブラリならありますが、
パッケージ数3000以上のRとまったく同程度のライブラリは無理です。
ところでRの腐った実装とは何を指しているのですか？
実行速度？データサイズの制限？

>>493
ColtよりCommons Mathが良いのでは？
Commons Mathの方がメジャーで機能も多いです。

Commons Math
http://commons.apache.org/math/
Commons Math 2.2 API
http://commons.apache.org/math/api-2.2/
Apache Commons Math　(api-1.1の表を翻訳して詳細追加)
http://ja.wikipedia.org/wiki/Apache_Commons_Math
Colt
http://acs.lbl.gov/software/colt/
Colt 1.2.0 API
http://acs.lbl.gov/software/colt/api/

495 ：デフォルトの名無しさん：2011/07/27(水) 15:49:25.00

scalaのインストーラ滅茶苦茶遅いな

496 ：デフォルトの名無しさん：2011/07/27(水) 17:13:00.24

あれは本当に遅かった。
インストーラ実行してる間にアーカイブの方を
解凍して配置してpath通してREPL起動して遊べちゃうレベル

497 ：デフォルトの名無しさん：2011/07/27(水) 21:48:34.00

ドキュメントの展開が糞遅いんだよな。
ドキュメントなんてローカルにインストールしなくていいって人いっぱいいると思うけど、
なんでオプションになってないんだろうな。

498 ：デフォルトの名無しさん：2011/07/27(水) 21:55:28.67

一番最近のリリースでは直ってたような。

499 ：デフォルトの名無しさん：2011/07/27(水) 22:26:34.38

サーブレット用にコンパイル(Tomcatのservlet-api.jar)したらクラスファイル名にServletって付くのね。
ちょっとハマった。
@WebServletアノテーション付けたらコンパイルエラーになってまたハマりそうだったから切り上げた。

500 ：ななし。：2011/07/27(水) 23:16:12.18

カ　オ　ス　ラ　ウ　ン　ジ　ゆ　る　せ　な　ぁ　い　ー

501 ：デフォルトの名無しさん：2011/07/27(水) 23:31:52.39

板違い死ねばいいのに

502 ：デフォルトの名無しさん：2011/07/28(木) 01:29:25.05

@n_k28鬱陶しい

503 ：デフォルトの名無しさん：2011/07/29(金) 23:52:44.91

おまえらファウラーのDSL本読んだ？
まあ翻訳でるらしいし、それからでもいいかもしれんが。

504 ：デフォルトの名無しさん：2011/07/30(土) 00:08:17.05

>>503
それどんな本？ファウラーはもう害悪でしかないが？

505 ：デフォルトの名無しさん：2011/07/30(土) 05:07:23.30

ちょお
ファウラーってそんなに悪く言われるような事したっけ？

506 ：デフォルトの名無しさん：2011/07/30(土) 05:14:27.31

全然知らんけどDSLってそんな一般論で語れるようなもんなのか？
言語能力に激しく依存する気がするのだが

507 ：デフォルトの名無しさん：2011/07/30(土) 09:11:54.12

「もう害悪でしかない」なんてことを言う奴の9割はそいつが害悪。

508 ：デフォルトの名無しさん：2011/07/30(土) 12:25:41.69

Java7あればScala不要なのか

509 ：デフォルトの名無しさん：2011/07/30(土) 13:11:52.41

仮にクロージャさえあればScala要らん、という奴がいてもJava8待ちだろ。

510 ：デフォルトの名無しさん：2011/07/30(土) 13:53:59.16

Java 7 でちょっとだけ switch 文が拡張されただけで、
Scala のパターンマッチングになんて程遠い。

511 ：デフォルトの名無しさん：2011/07/30(土) 13:57:36.56

>>509
ホントかどうかはシラネども、 late 2012 まで待てば良いなら、そんなに先じゃないかと

http://en.wikipedia.org/wiki/Java_version_history#Java_SE_8

512 ：デフォルトの名無しさん：2011/07/30(土) 14:17:17.23

Java7はあんなしょぼい進化でよく出せたな
移行する意味をまるで感じないのだが

513 ：デフォルトの名無しさん：2011/07/30(土) 14:23:27.89

>>512
Oracle による政治的判断によるリリースってやつだろ。1.4 の次が 5 になったみたいに。

514 ：デフォルトの名無しさん：2011/07/30(土) 15:22:32.86

移行する意味っつったらNIO2があるだけで十分のような。

515 ：デフォルトの名無しさん：2011/07/30(土) 16:57:50.96

>>514
commons-io とか使ってればいまさらって感じもするけどな。
try が C# の using っぽく拡張されたのはちょっとうれしいけど。

516 ：デフォルトの名無しさん：2011/07/30(土) 18:06:11.18

Commons IOだけじゃパーミッションにフルに触れないし非同期IOも不完全なままだし。

517 ：デフォルトの名無しさん：2011/07/30(土) 18:52:11.26

>>516
そいやそうだった。

518 ：デフォルトの名無しさん：2011/07/31(日) 01:50:10.59

@n_k28似合ってねえよ

519 ：デフォルトの名無しさん：2011/07/31(日) 06:43:31.10

はいはい場外乱闘でも野次でも2chでやるのはやめましょうね

520 ：デフォルトの名無しさん：2011/07/31(日) 23:55:42.76

http://dev.ariel-networks.com/wp/archives/755

どうするんだろ。

521 ：デフォルトの名無しさん：2011/08/01(月) 00:17:13.44

>>520
淘汰されるんじゃね？

522 ：デフォルトの名無しさん：2011/08/01(月) 08:32:59.23

-nobootcpつけないとエラーになる件、いいかげん直してほしい

523 ：デフォルトの名無しさん：2011/08/01(月) 12:20:26.18

クロスコンパイルできるScala for .NET

http://www.infoq.com/jp/news/2011/07/Scala.NET

524 ：デフォルトの名無しさん：2011/08/01(月) 14:55:30.20

何が出来るんです？

525 ：520：2011/08/01(月) 17:12:04.67

http://dev.ariel-networks.com/wp/archives/766

actorで逐次送るときたか。

526 ：デフォルトの名無しさん：2011/08/01(月) 18:57:54.96

こいつなんもわかってねえな

527 ：デフォルトの名無しさん：2011/08/01(月) 19:18:16.91

JetBrainsが新しいJVM言語 Kotlinを導入
http://www.infoq.com/jp/news/2011/07/kotlin

＞ジェネリックは実行時でさえ型安全である。

らしいぜ？

528 ：デフォルトの名無しさん：2011/08/01(月) 20:15:51.64

翻訳系指向な言語で実行時に型安全じゃないジェネリックの方が珍しいけどな。
程度の差はあるとはいえ。

529 ：デフォルトの名無しさん：2011/08/01(月) 23:27:47.46

>>525
正解はなんなの？リンク先は絶対間違ってるのはわかるけどｗ

530 ：デフォルトの名無しさん：2011/08/02(火) 01:20:12.97

http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html#scala.collection.immutable.Stream$$Empty$
nightly buildだとSerializableになってるんだね

531 ：デフォルトの名無しさん：2011/08/02(火) 03:47:46.65

>>525
なんか不味いの？

532 ：デフォルトの名無しさん：2011/08/03(水) 15:52:38.20

本腰入れて覚えたいんだけど、今からやるならどの本が良い？

533 ：デフォルトの名無しさん：2011/08/03(水) 17:40:40.02

>>532
まずは言語仕様。Webで。
分かりにくいところ、疑問点を
書き出したあと、本屋でそれに
触れている本を購入。

534 ：デフォルトの名無しさん：2011/08/03(水) 17:57:55.86

Listのcase class,::をカリー化したいのだけど、
unapplyの返り値の型がわからない

使い型としては、::と同じ様に、
case Cons(hd)(tl) => ...
としたいんだけど

535 ：デフォルトの名無しさん：2011/08/03(水) 20:46:07.53

東京いいなぁ。地方の書店のプログラミングコーナーにscalaなんて置いてねぇぞ

536 ：デフォルトの名無しさん：2011/08/03(水) 21:03:28.37

>>534
unapplyはカリー化しても実質的に意味が無い。というのは、

case Cons(hd)(tl) => ...

みたいなのは「構文レベルで」駄目なことになってるので。ちなみに、unapplyの
返り値型は Option[(A, List[A])]。これは個別に覚えて無くても大丈夫で、
case classで自動生成されるunapplyの型は、プライマリコンストラクタ引数
列をタプルとして、それを単にOptionでラップしたものになる。

537 ：デフォルトの名無しさん：2011/08/04(木) 00:38:34.16

>>535
本を読まない言い訳ができてよかったね

538 ：デフォルトの名無しさん：2011/08/04(木) 11:02:17.42

>>535
今はamazonがあるからまだいい方だよね

539 ：534：2011/08/04(木) 11:55:55.43

>>536
ありがとうございます

構文としてダメ、ですか…
別の方法を考えてみます。

unapplyの返り値がOption[(A,List[A])]になるということは、
カリー化しないunapplyと同じ返り値型、ということになりますね
すると、case Cons(hd,tl) => ...ということですか。
すごく気持ちが悪いような…

ちなみに、case classではなくて、
Listをextendしない(sealedだからできない)、
objectとしてConsのapply,unapplyを定義しようとしていました。

def apply[A]:(A => (List[A] => List[A])) = {
hd => tl => hd::tl
}
def unapply[A] (ls :List[A]) : Option[ ??? ] ={
if (false == ls.isEmpty){
Some( ??? )
}else{None}
}

>>532と>>535は同一人物?
立ち読みできない環境ならOderskyの、
Scala本の2nd Editionを買っておけば間違いないと思うんだけど…
本腰を入れるか迷ってるならもっとライトウェイトのもいいと思う

540 ：532：2011/08/04(木) 12:07:56.48

>>535 とは別人

Scala本の2ndはProgramming in Scalaってやつかな
Webで言語仕様をちゃんと見るのはやったほうが良さそうだね

写経して感じを掴みたいのでオライリーのもいいかなあ

541 ：デフォルトの名無しさん：2011/08/04(木) 13:02:47.05

webでやるより本から入ったほうがいいと思うんだがな。
虫食い的な知識じゃなくて、網羅的に基礎を作ったほうが
後々に効いてくる。これは学習全般に言えることだよ。

542 ：デフォルトの名無しさん：2011/08/04(木) 13:33:21.31

>>541
Webにある仕様を読めよ。

543 ：デフォルトの名無しさん：2011/08/04(木) 13:47:25.13

>webで仕様書
だよ。仕様書読んで使い方わかる人は少ないけど、
一般人でも機能や定数、制限事項は分かる

544 ：デフォルトの名無しさん：2011/08/04(木) 14:01:11.99

>>542
基礎を作るならば、それが向いてないといってるの。
はじめから大風呂敷を広げるようなものだから、挫折しやすい原因になるし
どこが大切か？というところのポイントが均一化されすぎて
掴みどころがない状況になり得る。いわばでっかい海に放り出されて
およげ、筏とオールをわたすからおよげといってるようなもの。
最初は入門書でひと通りやったほうがいいんだよ。

545 ：デフォルトの名無しさん：2011/08/04(木) 14:07:18.86

プログラミング初心者、または経験者でも
異なるパラダイムのプログラミング言語を学ぶなら本が良い
それ以外ならWebのチュートリアル読んで仕様書読めば十分

546 ：デフォルトの名無しさん：2011/08/04(木) 14:20:21.61

なんでもええねん
どっちかやってみてあかんかったらもう片方やってみたらええねん

547 ：デフォルトの名無しさん：2011/08/04(木) 14:34:11.38

>>545
それは一理ある。似た言語を触ってる場合、チュート＆仕様書で十分
書けるようになるからね。

548 ：デフォルトの名無しさん：2011/08/04(木) 14:38:59.34

100%純粋な旧日本人の遺伝子で身体が構築された俺には
大陸から渡ってきて日本人に成りすましている似非日本人たる
関西人。その関西人の言語「関西語」は遺伝子的に我慢できない。
特に「大阪弁」

549 ：デフォルトの名無しさん：2011/08/04(木) 15:03:54.64

チラシの裏にでも書いてろ

550 ：デフォルトの名無しさん：2011/08/04(木) 15:33:48.58

日本列島に日本人と関西人が住んでいる。

551 ：デフォルトの名無しさん：2011/08/04(木) 15:40:35.30

>>546
わかってくれたらいいんだよ
もうそんな気持ち悪いしゃべり方はするなよ？約束だぞ？

552 ：デフォルトの名無しさん：2011/08/04(木) 16:08:08.90

関西人排除すんのがscala言語のコミュニティなんか
レイシスト集団みたいやな。
別に、東北弁やろうが九州弁やろうがかまわんやろう？

553 ：デフォルトの名無しさん：2011/08/04(木) 16:15:54.89

入門書をざっと読むのを基礎と言われても…

554 ：デフォルトの名無しさん：2011/08/04(木) 16:34:07.11

じゃあ、何が基礎だよ？

555 ：デフォルトの名無しさん：2011/08/04(木) 16:57:00.93

TAPLを読むのが基礎、とか?

556 ：デフォルトの名無しさん：2011/08/04(木) 18:30:31.08

プログラミング初心者なら入門書から入れ
Scala初心者ならWebで十分

557 ：デフォルトの名無しさん：2011/08/04(木) 18:32:46.67

>>552
気持ち悪いんだから仕方ないだろ

558 ：デフォルトの名無しさん：2011/08/04(木) 19:13:21.71

もういいよその話は
よその板でやってこい

559 ：デフォルトの名無しさん：2011/08/04(木) 19:56:33.14

>>546のせいで雰囲気悪くなっちゃったな

560 ：デフォルトの名無しさん：2011/08/04(木) 20:02:57.27

でも本格的にやるなら、定評のある本でやったほうがいいよ。
コーディングスタイルもわかるし
注意点や考え方がわかるって大切だからね。
持っておけば辞書にもなる。

561 ：デフォルトの名無しさん：2011/08/04(木) 21:12:31.67

>>560
Webでもわかるよ

562 ：デフォルトの名無しさん：2011/08/04(木) 21:25:43.33

EffectiveやGood partsレベルの本なら辞書にもなるんだがな。
入門書じゃ辞書にはならんだろ。

563 ：デフォルトの名無しさん：2011/08/04(木) 21:33:26.17

動物本かprogramming in scalaのどっちかでいいんじゃない。どちらもある程度まで読み進めば、
あとは適当にwebで調べるなりどこかで聞くなり、どうにでもなるレベルに至るはず

564 ：デフォルトの名無しさん：2011/08/04(木) 22:59:25.23

>>561
https://sites.google.com/site/scalajp/home
ここがそれを目指してるんだと思うけど、まだ途上だしなぁ。

「○○でも出来る」じゃなくて、「どちらがより容易か」が重要。
現状では、良書に当たった方が早い。

565 ：デフォルトの名無しさん：2011/08/04(木) 23:01:02.65

日本語縛りか。

566 ：デフォルトの名無しさん：2011/08/04(木) 23:01:49.67

>>564
オフィシャル見ればいいのに

567 ：デフォルトの名無しさん：2011/08/04(木) 23:04:31.57

ああ、そういうことか
日本語縛りなら本のほうがいいかもね

日本語の情報が豊富なJavaとかならともかく、英語使えないのにScalaなんかに
手を出す奴ってなに考えてるの？

568 ：デフォルトの名無しさん：2011/08/04(木) 23:10:39.88

人格否定するほどの事じゃないだろ・・・

569 ：デフォルトの名無しさん：2011/08/05(金) 00:14:27.70

>>532
> 本腰入れて覚えたいんだけど、今からやるならどの本が良い？

◆1冊目～入門編
「Scalaで学ぶ関数脳入門」

CとかJavaは多少分かるけど関数型言語なんてさっぱり、という方はまずこれを見てみよう。
もしくは、ある程度知っている人でも復習として読むのにおすすめ。
大変読みやすく書かれているので、短い時間で読むことができます。

◆2冊目～ Scala文法やライブラリの詳細

「ボクらのScala 次世代Java徹底入門」または
「Scala実践プログラミング―オープンソース徹底活用」

日本人が書いた本なので読みやすい。
和訳本にありがちな変な言い回しなどないのでサクサク読める。
Scalaの文法やライブラリを一通りざっと知ることができる。

◆3冊目～ Scalaマニアック

Scalaをマニアックにマスターするなら、次の2冊は定番中の定番なので押さえておくこと。
ただし、本の厚さとか重さもヘビー級なので手が疲れるので要注意だ。

「Scalaスケーラブルプログラミング」
日本語版は表紙の絵がコップなので通称「コップ本」と呼ばれている。

「プログラミングScala 」
最新の定番本。
バージョン2.8の情報もあるのでぜひ読もう。
～～～～～～～～～～～～～～～～
532に対してのベストアンサーは、オレ様で決まりだな。みんな不親切すぎるぜ！

570 ：デフォルトの名無しさん：2011/08/05(金) 00:19:49.59

最初から3冊目のだけで十分でしょ

571 ：デフォルトの名無しさん：2011/08/05(金) 00:22:57.45

このスレ的には
７つの言語　７つの世界
http://www.amazon.co.jp/dp/4274068579/
のScalaの評価に対してはどう？

572 ：デフォルトの名無しさん：2011/08/05(金) 00:34:10.90

どうでもいい

573 ：デフォルトの名無しさん：2011/08/05(金) 00:54:07.93

また下らんのが出てるなw

574 ：デフォルトの名無しさん：2011/08/05(金) 01:39:49.25

>>569がベストアンサーに一票。
FAQの回答ご苦労さまです。

>>570
いきなり3冊目からで済む人も少なくないのでしょうけれど、
関数型言語が初めてなら関数脳入門は外せないと思います。

575 ：デフォルトの名無しさん：2011/08/05(金) 02:13:16.95

コップ本ペラい紙使ってるから裏面の字とか透けてウザいっす

576 ：デフォルトの名無しさん：2011/08/05(金) 05:43:51.45

紙って薄いほうが高級なんじゃないの？

577 ：デフォルトの名無しさん：2011/08/05(金) 08:21:46.09

「本腰を入れる」ってもともとは真剣に子作りのために性交で腰を動かす
というところから来ているって中学生の息子がしどろもどろに言ってきて、
町内会の会合で父さんあんまり「本腰を入れて頑張りましょう」ばかり
言うのは恥ずかしいからって・・・・。そうか？そうなのか？？

「褌をしめてかかる」「本腰を入れる」ともに古い日本では、特に重要な
子孫繁栄の辺縁から派生した言葉らしいのだが、そうか？　そうなのか？？

578 ：デフォルトの名無しさん：2011/08/05(金) 08:24:12.09

横からだけど、もう本当に学習時間を
短縮したい場合、最近はcheatCheet
っていって、まあアンチョコなんだけど
検索してみると結構分かりやすいのがたくさんある。
これをざっと、ながめるだけでも
この言語のポイントをおさえることができるのでみといて損はないと思う。ただし、いけてるものは英語です。

以上、参考まで。

579 ：デフォルトの名無しさん：2011/08/05(金) 09:27:18.91

>>577
精を出す

580 ：デフォルトの名無しさん：2011/08/05(金) 10:21:05.39

>>569
取り合えず今日は一冊目を買って帰ろう。
ありがとう！

581 ：デフォルトの名無しさん：2011/08/05(金) 10:46:06.89

三冊も読むのか?
一冊で充分だろ。読むだけ君かよ。

582 ：デフォルトの名無しさん：2011/08/05(金) 11:36:30.30

いらなくなったら俺がタダでもらってやるから心配するな

583 ：デフォルトの名無しさん：2011/08/05(金) 12:43:14.77

>>581
無駄にたくさん買う奴も必要なんだよ
出版社に、scalaは金になるって思わせないとw

俺はコップ本だけでいいけど

584 ：デフォルトの名無しさん：2011/08/05(金) 13:44:23.82

Scalaの本を三冊も読むくらいならコップ本とHaskellの本を一冊読めよ

585 ：デフォルトの名無しさん：2011/08/05(金) 14:37:24.24

俺がscalazの旨みがわかんねーのはHaskell理解してないからなのかい？

586 ：デフォルトの名無しさん：2011/08/05(金) 17:13:49.96

ファイルを読んで一行ずつ処理するとき、どうしてる？
コップ本のように

scala.io.Source.fromFile("test.txt").getLines

とやっても empty iterator しか帰ってこない…
結局JavaのFileReaderを使ってる。

587 ：デフォルトの名無しさん：2011/08/05(金) 17:23:06.08

手元の環境だと、普通に動くけど？

588 ：デフォルトの名無しさん：2011/08/05(金) 17:30:00.40

そうなの？
こちらはバージョン2.9.0.1です。

589 ：デフォルトの名無しさん：2011/08/05(金) 17:41:04.70

resource(test.txt)へのパス指定が間違っているんじゃね？

590 ：デフォルトの名無しさん：2011/08/05(金) 17:45:02.66

Scalaの短縮表記?についてのまとめとかってある?

conf setOutputKeyClass classOf[Text]
とかいうコードを見て吃驚したんだけど、これって
conf.setOutputKeyClass(classOf[Text])
と同じだよな?

591 ：デフォルトの名無しさん：2011/08/05(金) 17:59:35.05

TMTOWTDIなのがScalaのイヤンなところ
しかもPerlよりも酷い

592 ：デフォルトの名無しさん：2011/08/05(金) 18:19:06.73

また頭の悪いやつが発生しとる

593 ：デフォルトの名無しさん：2011/08/05(金) 18:59:00.24

ゆろよろのアイコン見るたびに微妙な気分になる人いる？
ほんとは不細工なのに、それなりに見える写真をがんばって選んだんだろうな、とか
何十回撮ったんだろうな、とかいろいろ考えてしまう
ていうか笑ってしまう

俺ゆろよろをフォローしてるけど、アイコン見ると気が散るから、ほんとはつぶやかないでほしいんだ

594 ：デフォルトの名無しさん：2011/08/05(金) 19:04:33.38

そんな事をここに書かれても困るんだが

595 ：デフォルトの名無しさん：2011/08/05(金) 19:04:59.61

おまえどう見てもJava顔だろって奴がScalaを触ってたりする
マジで不思議だ……鏡のない国に住んでるのかも………

596 ：デフォルトの名無しさん：2011/08/05(金) 19:12:07.26

なんかの改変コピペか？

597 ：デフォルトの名無しさん：2011/08/05(金) 19:14:42.69

java顔とscala顔の具体例を挙げてもらおうか

598 ：デフォルトの名無しさん：2011/08/05(金) 19:26:11.25

>>593
おまいにええ方法を教えてやるわ。
https://si0.twimg.com/profile_images/340971668/yuroyoro_reasonably_small.png をアドブロックに登録しろ。

599 ：デフォルトの名無しさん：2011/08/05(金) 21:38:03.77

不細工なのに角度で誤魔化そうとするなんて…
スイーツ思考＾＾；

600 ：デフォルトの名無しさん：2011/08/05(金) 21:48:21.54

マ板でやれ

601 ：デフォルトの名無しさん：2011/08/05(金) 23:23:02.28

>>578
> 横からだけど、もう本当に学習時間を
> 短縮したい場合、最近はcheatCheet

Cheat Sheet って、本来の意味は、カンニングペーパーのこと。

つまり、カンニングペーパーみたいに、箇条書きで要点をまとめたシートのこと。

個人的には、文法のCheat Sheet は要らねえから、
日常処理に使えるカンニングペーパーが欲しいなあ。

602 ：デフォルトの名無しさん：2011/08/05(金) 23:37:04.89

>>580

「Scalaで学ぶ関数脳入門」は、Ｓｃａｌａ以外にも役立つから、お勧め。

何かを素早く学習したかったら、複数の本を速読で読んじゃうのが効果的と思うよ。

もしも、業務で必要ですぐにマスターしたいのなら、
最初から5冊かって平行して速読しちゃうという手もある。

大学教授がそういう本の読み方をやっていた。
大学教授が「高校生でもわかるｘｘｘｘ」みたいな超入門本を買っているから何かと思ったら、
その方が理解のスピードが全然違う。

お金よりも、時間の方が貴重だからな。

603 ：デフォルトの名無しさん：2011/08/05(金) 23:44:01.37

>>602
> 大学教授がそういう本の読み方をやっていた。
> 大学教授が「高校生でもわかるｘｘｘｘ」みたいな超入門本を買っているから何かと思ったら、
> その方が理解のスピードが全然違う。

ごめん途中で送信しちゃったから追記するけど、

物事を速攻マスターしたければ、
厚くて詳細な本だけでなく、超簡単で平易に書かれた本も同時に買うのがおすすめってこと。

ただし、Ｓｃａｌａの場合、上述に上げた本よりも、ずっと超簡単な本が実はあるにはあるけど、
さすがにあれを買うのはおすすめしない。あえてタイトルは伏せるけど。

604 ：デフォルトの名無しさん：2011/08/05(金) 23:44:52.11

改行馬鹿

605 ：デフォルトの名無しさん：2011/08/06(土) 00:00:54.81

電子メール準拠

606 ：デフォルトの名無しさん：2011/08/06(土) 00:05:46.38

超入門本で「マスター」かよw

607 ：デフォルトの名無しさん：2011/08/06(土) 00:07:05.67

文化ギャップのるつぼだな。

608 ：デフォルトの名無しさん：2011/08/06(土) 01:13:06.82

改行馬鹿はよくしゃべるなあ

609 ：デフォルトの名無しさん：2011/08/06(土) 18:17:37.32

>>597
ttp://ja-jp.facebook.com/people/Kota-Mizushima/100001587175577

610 ：デフォルトの名無しさん：2011/08/06(土) 22:47:17.67

>>608

ごめんな。
ここは２ｃｈだから、改行とか句点とか誤字とかはあんまり気にせず書くんだ。

ていうか、ここの連中、文句言う暇あったら、ちゃんと答えろよ。

>>590
への回答：

「そのとおり。省略するとそういう書き方もできる。
だが、省略しすぎは察しの通り可読性を下げるので、お勧めできない場面の方が多い。」

611 ：デフォルトの名無しさん：2011/08/07(日) 08:40:39.32

ネガコメして荒らそうとしてるの一人だろ。

612 ：デフォルトの名無しさん：2011/08/07(日) 09:42:19.54

出たよ可読性馬鹿
読みやすいように「Javaっぽく」書いたらいいと思うよ＾＾

613 ：610,569：2011/08/07(日) 10:45:10.43

>>612

じゃあ、>590の２つの書き方を比べたら、上の方が良いって言っているわけね。

conf setOutputKeyClass classOf[Text]
conf.setOutputKeyClass(classOf[Text])

この２つの例で、ドット . と () の省略をしたがる人(>>612) ってどういう考え方してるか教えてほしいな。

先に予想してみるけど、612は、大して有益な情報を出せない。
少なくとも、これまでは、612よりもオレ様の方が、>590にとって有効な回答をしている。

614 ：デフォルトの名無しさん：2011/08/07(日) 10:58:30.60

>>613
有効な回答(笑)

短縮表記のまとめとかってある？
↓
可読性が下がるので短縮しないほうがよい(ｷﾘｯ

有効な回答ありがとうございます(笑)

615 ：デフォルトの名無しさん：2011/08/07(日) 11:00:36.17

Scalaのソース覗いてみればわかるけど
一つしか引数取らない場合は省略してることが多いよ
その程度で読みづらいと感じるのは慣れてないだけ

616 ：デフォルトの名無しさん：2011/08/07(日) 11:08:46.30

慣れの問題じゃない
品質が悪くなる

617 ：デフォルトの名無しさん：2011/08/07(日) 11:12:01.50

品質っていうのは統一されていることが重要で、短い長いの問題ではない

618 ：デフォルトの名無しさん：2011/08/07(日) 11:13:51.73

糞に統一されても意味ない

619 ：デフォルトの名無しさん：2011/08/07(日) 11:14:55.96

>>618
まあそれは理解できる

620 ：デフォルトの名無しさん：2011/08/07(日) 11:24:11.35

この殺伐した雰囲気も含めてはやくScalaをマスターしたい

621 ：611,569：2011/08/07(日) 11:25:05.68

>>614
話そらすなよ？
614みたい話は誰も書いてない。作り話を作って、逃げただけか。

お前の不親切な回答と、オレ様の回答とどっちが >590 にとって有効かどうかってことだ。
それは、>590が決めてくれればよい。

ただ、一点、オレ様も誤りがあった。 >612に謝罪したい。

「読みやすいように「Javaっぽく」書いたらいい」という 612の回答は褒めてやる。
590への回答としては、55点くらいの出来だ。
できればやれる子なんだから、 611より前に回答しろよ。やればできる子なんだから。

なお、 >532 へ最も有効な回答を示すことができたのは、オレ様である。
いっておくけど、 >569は、 >570 みたいな意見が出るのを知っていて、
でも敢えてあの行数でベストアンサーを出したのである。

(で、敢えて改行いっぱいつけたけど、これはスルーカを試してるんだからね！）

622 ：デフォルトの名無しさん：2011/08/07(日) 11:27:07.74

>>620
いや、この頭の悪そうな文体のやつは明らかにScala初心者だから一緒にしないでくれ

623 ：デフォルトの名無しさん：2011/08/07(日) 11:40:28.54

Scalaにも、 VBのOption Explicitみたいなのがあるとうれしいのだが。
個人的には、行末の ; は、必須の方がうれしい場合がある。
たまに、改行を構文区切りと誤解されて、意図しない結果になることがあるので。

でも、; を省略して書きたいときもあるので、 VBのOption Explicitみたいなので切り替えれるとうれしい。

624 ：デフォルトの名無しさん：2011/08/07(日) 11:41:18.34

結論としては、Java 7でＯＫ？

625 ：デフォルトの名無しさん：2011/08/07(日) 11:43:14.59

>>624
はい

626 ：デフォルトの名無しさん：2011/08/07(日) 11:44:22.67

ScalaってJava7ぱくってる？

627 ：デフォルトの名無しさん：2011/08/07(日) 11:44:54.53

釣り針でかすぎんだろ

628 ：デフォルトの名無しさん：2011/08/07(日) 11:48:46.80

>>626
はい

629 ：611,569：2011/08/07(日) 11:50:07.59

スルーしてくれって書いてから、自己レスしちゃいます。ごめんなさい。ごめんなさい。

>>615
> 一つしか引数取らない場合は省略
> その程度で読みづらいと感じるのは慣れてないだけ

確かに。この程度なら、慣れの問題かも。
いずれにせよ、省略を良しとするか悪いとするかは、時と場合によりますよね。

すみませんでした。殺伐としたふんいき(←なぜか漢字変換できない)になるくらいなら、スルーしてください。

630 ：デフォルトの名無しさん：2011/08/07(日) 11:51:49.78

>>623
REPLでもF#みたく;;で評価、みたいにしてくれた方がありがたいと感じる事あるな。
まぁ無いならしゃーないと諦めるしかないけど。

631 ：デフォルトの名無しさん：2011/08/07(日) 13:11:13.61

vimにfscとscalaコマンドをキーマッピングしてからメッキリREPLを使わなくなった。

632 ：デフォルトの名無しさん：2011/08/07(日) 14:07:56.58

>>630
REPLで、ユーザが思った「ここからここまで」をひととおりまとめて評価して欲しい場合は、{で入力を始めるのが有効かと。

633 ：デフォルトの名無しさん：2011/08/07(日) 14:09:12.33

ちなみに、最近のEclipse Scala PluginのREPL連携機能は結構便利。エディタ上で選択した行や範囲をREPLで評価して結果表示してくれる。
Emacsとかにもあるけど、IDEとかでもそういうのをしたいときはあるので、お勧め。

634 ：デフォルトの名無しさん：2011/08/07(日) 14:53:00.50

eclipseのplugin

もう一息かな

635 ：デフォルトの名無しさん：2011/08/07(日) 15:23:36.13

技術ではなく心構えでプログラミングをしようとする人がいますね

636 ：デフォルトの名無しさん：2011/08/07(日) 15:36:42.81

>>629
メソッドが二項演算子的に作用する時は、ドットを省略しても良いと思う。
それ以外の場合は、あまり意義を感じない。

637 ：590：2011/08/07(日) 16:11:34.34

みなさんありがとうございます
まとめ、っていうほどでもなく、
・「ソース読んで慣れろ」
・「もしくは省略すんな」
というスタンスなのかな?

関数適用の()の省略なら、
関数型言語と言えば当たり前かもしれないんですが、
"."まで省略するのはすごく抵抗が。
conf setOutputKeyClass classOf[Text]
だと、confっていう関数に順次適用してると、
パッと見、見えてしまいました。
(それに加えて"."が省略可能だというのも初見でした)

638 ：590：2011/08/07(日) 16:19:28.33

"."を省略する部分に関する説明を見つけました
Programming in Scala,2nd,p82(Sec5.8)

When you write "s.indexOf('o')", indexOf is not an operator.
But when you write "s indexOf 'o'", indexOf is an operator,
because you're using it in operation notation.

639 ：デフォルトの名無しさん：2011/08/07(日) 16:42:21.86

>>637
可読性が下がると思えば省略しないけど、Java厨のためにわざわざ省略しないでおくってことはしないスタンス

640 ：デフォルトの名無しさん：2011/08/07(日) 16:53:37.41

省略はx.op(y)をx op y、z.op()をz opと書くための
シンタックスシュガーなので、必要に応じて使い分ければいい。

641 ：デフォルトの名無しさん：2011/08/07(日) 17:05:36.53

実際はいかにもメソッド的なもの(例えばappendとか)も
省略記法で書いてあることが多いから、
自分のコーディングルールはともかく、
普通に読めるようにしておいたほうがいい

642 ：デフォルトの名無しさん：2011/08/07(日) 17:56:32.44

>>637
オレ様君が困ってるだろうが
もっとプログラマ初心者のように振る舞えよ

643 ：デフォルトの名無しさん：2011/08/07(日) 18:13:13.24

>>636
メソッドを二項演算子のように記述できるのは素晴らしいのですが、
乱用されすぎですね。

http://twitter.com/#!/yukihiro_matz/status/25091480997
>@kmizu そういうことになりますね。
>ただ、私が一番懸念してるのは、右結合ではなくて、
>演算子としてのメソッドが多重に重なった場合だったりします。
>っていうか、Scalaのspecで x should not be zero とか言われても、
>(私の脳が)パーズしきれませんです。

http://twitter.com/#!/kmizu/status/25092278159
>@yukihiro_matz なるほど。
>ちなみに、これは、(x should not) be zeroとパーズされます。
>notとzeroが値でshouldとbeがメソッドですね。

http://twitter.com/#!/kmizu/status/25092498344
>@yukihiro_matz この例の場合、notとかzeroが値なので紛らわしいだけで、
>パーズそのものは文脈考慮しなくていいので、実はかなり楽なんです。

http://twitter.com/#!/yukihiro_matz/status/25098333248
>「実はかなり楽」といわれても、私には困難である事実は変わらないw
>RT @kmizu: (x should not) be zeroとパーズされます。
>notとzeroが値でshouldとbeがメソッドですね。

644 ：デフォルトの名無しさん：2011/08/07(日) 18:58:08.10

DSLは難しいねー。表面的な可読性の高さは良いことなんだけど、
トラブった時にデバッグが難しいのでは本末転倒だし。
浅海さんも、エラーメッセージが暗号になるのは良くない、みたいなことを言ってたな。

645 ：デフォルトの名無しさん：2011/08/07(日) 19:13:01.65

DSL?

646 ：デフォルトの名無しさん：2011/08/07(日) 19:21:25.80

DSL危険だろ
Java7で我慢しろ

647 ：デフォルトの名無しさん：2011/08/07(日) 19:53:13.38

sealed classとパターンマッチとNothingがあればJavaでもいいんだけど

648 ：デフォルトの名無しさん：2011/08/08(月) 00:44:34.29

>>643
matzはどうしてこう素人みたいなイチャモンをつけるかね
こんなものが困難なわけないでしょ

649 ：デフォルトの名無しさん：2011/08/08(月) 00:48:57.41

RakeみたいなRubyのDSLは「きれいなDSL」で、
Scalaの括弧省略は「困難」な記法なのかね
その基準なんなんでしょうね

650 ：デフォルトの名無しさん：2011/08/08(月) 00:52:38.01

x should not be zero は should と be がメソッド
x should be zero になると should と zero がメソッドか
こんな書き方されたら嫌だな

651 ：デフォルトの名無しさん：2011/08/08(月) 00:53:47.99

実際にはScalaもRubyも糞なのにね

652 ：デフォルトの名無しさん：2011/08/08(月) 00:59:36.49

>>651
だな

653 ：デフォルトの名無しさん：2011/08/08(月) 01:18:11.19

>>649
フラットすぎるという印象はあるなあ。英文を読んでるみたいだ

Rubyの場合はメソッド呼び出しのドットが区切りになるのと、
あとはちょっとした文法上の省略ができるってだけなので、
呼び出し関係は読み取りやすいように感じる

ただ、Scalaのルールであれば、
より自然言語に近い記述ができるかもしれない

654 ：デフォルトの名無しさん：2011/08/08(月) 01:28:06.44

Scala Style Guideではこの辺でちょこっと触れてる
http://yanana.github.com/scala-style/method_invocation/index.html

IDEが"."入力したらメソッド補完するような感じでずっと行くなら
ScalaでIDEが普及していくにしたがって記号のみのメソッドやDSL以外で後置記法、中置記法はなくなっていくかもね

655 ： ◆CgacaMDhSQ ：2011/08/08(月) 01:36:35.37

しばらく自重していたのですが、それなりにやわらかい書き方も覚えてきたので、ちょっと復帰してみます。

>>648
matzさんとは一応顔見知りではあるのですが、matzさんご自身が本当にイチャモンをつけているとは思っていないです。
今の自分の考えは、メンタルモデルの違いが、私とmatzさんのすれ違いの原因ではないかというものです。
私は、一応構文解析屋出身なので、パーズルールが明らかに簡単なScalaの方が、パーズするのも楽だと思って
しまうのですが、matzさんはパーズルールの複雑さとは別の観点で、「パーズの困難さ」を考えているのではないかと思います。

656 ：デフォルトの名無しさん：2011/08/08(月) 01:42:54.15

エヴァンジェリスト(笑)が来たぞーー！！！

657 ： ◆CgacaMDhSQ ：2011/08/08(月) 04:43:20.29

>>656
うっとうしいようでしたら退散します。エヴァンジェリスト(笑)というのはその通りでしょうね。
まだまだ色々訓練が足りてないです。

658 ：デフォルトの名無しさん：2011/08/08(月) 06:27:21.12

なんか最近荒らしが来てるからスルーした方がいいよ、うん。

659 ：デフォルトの名無しさん：2011/08/08(月) 06:28:14.74

>>655
> それなりにやわらかい書き方も覚えてきたので、
どこがだよｗ
ってかなんか根本的に勘違いしてるよ、うん。

660 ：デフォルトの名無しさん：2011/08/08(月) 08:03:50.78

ルールが簡単と言われても、Scalaという言語内では簡単なだけで、門外漢の人には異様に映るってことをいってるようにも思える。
Javaから来た俺にはScalaもRubyも異様に映った。ルールが簡単かどうかより慣れが重要だった。
つまり、この件ではmatzは自己否定を含んだ批判をしているように見える。

661 ：デフォルトの名無しさん：2011/08/08(月) 09:40:53.26

メソッドチェーンを英語みたいに読めるようにしてるのがキモいってRailsでも言われたことなんだよね
こういうのはアメ公がよくやることで、matzの近視的な批判は全部ブーメランなんだよね

662 ：デフォルトの名無しさん：2011/08/08(月) 09:57:52.88

まああれだ、いわゆる「Lispはパーズし難い」みたいなノリだ
もちろんLispのパーズルールは単純極まりないが、
凡人にはあの入れ子がパッと見でパーズし難いという感じ

663 ：デフォルトの名無しさん：2011/08/08(月) 11:26:29.59

しかし単項メソッドでそこまでやっといてifやwhileの条件式にかっこを要求するのはどうなのよ？
もちろんJavaとの類似性を重視したのだろうけど、中途半端だ。

664 ：デフォルトの名無しさん：2011/08/08(月) 12:29:56.69

ifを関数で定義するならシグネチャこんな感じでしょ(elseのことは考えないとして)
def myIf[T](b: Boolean)(block : => T): T = ...
この関数条件式のかっこ省略して呼びだしたりできないのでまあいいんじゃね？

665 ：デフォルトの名無しさん：2011/08/08(月) 12:56:22.01

TとUnitのスーパークラスか...

666 ：デフォルトの名無しさん：2011/08/08(月) 14:55:44.23

久々に、「Scala 日本語情報サイト」見てみたら、ドキュメントの和訳が増えていた気がする。

バグ報告窓口って言うのはあるけど、要望窓口とかいうのはないのかなあ？
上述のOptionExplicit 欲しい。

他には、逆引きScala みたいなまとめってないのかなあ？

667 ：デフォルトの名無しさん：2011/08/08(月) 15:07:04.00

>>658

２ｃｈのレスの80％は、たったの20％の人が何度も投稿した結果によるものです。
２ｃｈを見る人の80％はReadOnlyで、書き込みする人はたったの20％にすぎません。

これを２ｃｈにおけるパレートの法則といいます。

荒らしの書き込みする人って、一匹見かけたら影に大量に隠れているかのような印象を持つかもしれないけど、
実際は、一匹がなんども出現しているだけ。
その一匹がまき散らした汚物のせいで、スレ全体が荒れて汚染されてしまうので、しっかり駆除することが重要だ。

668 ：デフォルトの名無しさん：2011/08/08(月) 18:32:05.52

>>667
荒らすなよクズ
これだから自覚のない馬鹿は

669 ：デフォルトの名無しさん：2011/08/08(月) 18:37:31.61

人の少ないスレは、煽り耐性の低いクズが一匹いるだけですぐゴミスレになるな

670 ：デフォルトの名無しさん：2011/08/08(月) 18:43:28.89

関係ないけど、色んな感情を溜め込んでるくせに
2chで発散しないでロムってるだけの奴って現実で何するのか怖い

671 ：デフォルトの名無しさん：2011/08/08(月) 18:57:21.59

俺は溜め込まないｷﾘｯ
俺はww発散すwるぞwwwﾃﾞｭｸｼwwwww

とか言ってれば、スレ違いが許されると思ってる馬鹿
関西人や韓国人と同レベル
こういう馬鹿にプログラミングは無理

672 ：デフォルトの名無しさん：2011/08/08(月) 18:59:06.50

頭から論理がスッポリ抜け落ちたウヨにも無理

673 ：デフォルトの名無しさん：2011/08/08(月) 23:05:41.66

また御大に喧嘩売ってる

674 ：デフォルトの名無しさん：2011/08/09(火) 00:10:07.43

>>673

お前自身が、Twitterフォローするのやめればよいのでは？
いちいち他人に気にし過ぎなのでは？

あと、お前、わざわざ２ｃｈに書き込まなくて良いから。

675 ： ◆CgacaMDhSQ ：2011/08/09(火) 00:15:01.51

>>666
バグ報告窓口がまだちゃんと出来ていないので、まずそこを設置する予定です。
これは、JIRAのライセンスを買ってあって、サーバも借りてあるので、今度の休みくらいに
やりたいところです。要望窓口も、設置したいところですが、どういう形式がいいでしょうか？

Scala日本語情報サイトは、多くが自分一人で更新していて、人手と時間が足りないので、要望
出してくれるだけでも助かります。特に、翻訳が稚拙な部分はなんとかしたいところ…

逆引きScalaみたいなのは、あちこちに散らばってる気がしますが、まとめたいですね…
個人的にWikiオンリーだと、あまりうまく行かない気がしてるので、日本語情報サイトの中に
Wikiを設置する、という事を考えています。もちろん、他の方が好きな場所でやってくださっても
構わないと思います。

676 ：デフォルトの名無しさん：2011/08/09(火) 00:29:17.99

REPLで、

> val a = new DynamicVariable("a")
> val a.value = "b"
> val a.value

ってやると"a"が返ってきてしまうんだけど、これは何で？

677 ：デフォルトの名無しさん：2011/08/09(火) 00:43:36.57

>>654
Eclipseは知らんけど、IntelliJのプラグインだとスペース入れたらメソッド補完してくれるよ

678 ：デフォルトの名無しさん：2011/08/09(火) 07:35:51.88

以前getLinesについて質問したものですが、こういう報告って
どこにすればいいんでしょう？　本家？
---
scala 2.9.0.1で以下のようにgetLinesがうまく動きません。
環境はwindows XP, cygwinからです。

scala> val s = scala.io.Source.fromFile("t.txt")
s: scala.io.BufferedSource = non-empty iterator

scala> for(l <- s.getLines) print(l)

scala> for(c <- s) print(c)
abc
def
ghi

なおt.txtはShift_JISで改行コードはCRLFです。

679 ：デフォルトの名無しさん：2011/08/09(火) 07:55:22.73

>>678
REPLじゃなけりゃ動く
あるいは
val s = scala.io.Source.fromFile("t.txt").getLines
でもOK
詳しい説明は任せた↓

680 ：デフォルトの名無しさん：2011/08/09(火) 08:36:11.66

>679
おお、確かに！
不思議ですね。

681 ：デフォルトの名無しさん：2011/08/09(火) 11:04:22.54

TLSによる実装でREPLのスレッドの使い方と親和性無いんじゃないかな。
scala> {val a = new util.DynamicVariable("a"); a.value = "b"; a.value}
res7: java.lang.String = b

682 ：デフォルトの名無しさん：2011/08/09(火) 13:05:04.00

REPLは問題山積だな。
しかしpackage宣言くらい通らんものか。

683 ：デフォルトの名無しさん：2011/08/09(火) 19:44:41.15

clojure→シンプルなのに表現力豊か
scala→無駄に複雑

684 ：デフォルトの名無しさん：2011/08/09(火) 20:00:20.45

無駄と感じるのは勉強不足。

685 ：デフォルトの名無しさん：2011/08/09(火) 20:12:53.38

>>684
お前そんなんばっかだよね

686 ：デフォルトの名無しさん：2011/08/09(火) 21:08:40.62

F#ならまだしもClojureはもう眼中にないわ

687 ：デフォルトの名無しさん：2011/08/09(火) 21:45:01.31

オブジェクト指向(笑)

688 ：デフォルトの名無しさん：2011/08/09(火) 22:00:30.68

>>687

またお前か！

特定したぞ。
>>656
>>651
>>618
>>673
>>502
>>490
>>464

↑お前は、2chに来なくて良いよ。
Twitterでの話題をTwitter上でコメントできずに2chに来ているなんてチキン野郎だな。M君は。

689 ：デフォルトの名無しさん：2011/08/09(火) 22:11:42.52

なにやら見えない敵と戦っている人が

690 ：デフォルトの名無しさん：2011/08/09(火) 23:15:00.45

イニシャルトーク(笑)

使えない特定厨だな(笑)

691 ：デフォルトの名無しさん：2011/08/10(水) 08:55:24.84

本人にダメージが入ればおk w

692 ：デフォルトの名無しさん：2011/08/10(水) 17:48:15.32

どうでもいいから技術の話をしろ。

693 ：デフォルトの名無しさん：2011/08/10(水) 18:08:18.31

>>692
しろってなんだよ
お前がすればいいだけでは？馬鹿？

694 ：デフォルトの名無しさん：2011/08/10(水) 18:33:35.22

x技術 o言語

695 ：デフォルトの名無しさん：2011/08/10(水) 19:28:52.12

変なのが湧く程度には有名になったってことだよなScalaも

696 ：デフォルトの名無しさん：2011/08/10(水) 19:35:30.79

誰かStack Overflowの日本語版作ってくれ。そっちに移住するから。

697 ：デフォルトの名無しさん：2011/08/10(水) 19:47:49.91

http://qiita.com/
http://answer.pythonpath.jp/

698 ：デフォルトの名無しさん：2011/08/12(金) 17:31:27.79

しまった asInstanceOf[] より type ascription 使うほうがいいのか

699 ：デフォルトの名無しさん：2011/08/12(金) 17:35:07.00

matchにおきかえれるように構造を見直すのがベスト

700 ：デフォルトの名無しさん：2011/08/13(土) 10:54:41.76

2.9.1 RC2

701 ：デフォルトの名無しさん：2011/08/13(土) 21:03:59.91

-nobootcpのバグが治ってるー

という夢をみた

702 ：デフォルトの名無しさん：2011/08/13(土) 21:08:30.33

；；

703 ：デフォルトの名無しさん：2011/08/16(火) 06:39:59.16

class Rational(n:Int, d:Int)
{
private def gcd(x:Int, y:Int): Int =
{
if (x==0) y
else if (x<0) gcd(-x, y)
else if (y<0) -gcd(x, -y)
else gcd(y%x, x)
}
private val g = gcd(n,d)

val numer:Int = n/g
val denom:Int = d/g

//略
}

本やWeb上で見かける例なんだけど、gは初期化の時しか使わないからフィールドである必要ないんだけど
プライマリコンストラクタで一時変数みたいのは定義できないのですか？
Rationalがgをフィールドに持つのは無駄なんですけど

704 ：デフォルトの名無しさん：2011/08/16(火) 06:55:27.28

>>703
locally { } を使え。

705 ：デフォルトの名無しさん：2011/08/16(火) 12:16:29.71

>>704

locallyというのがあるのですね。ありがとうございます。
しかしlocallyの中でgを定義しても
val numer:Int = n/g
の所ではgはスコープの外になって未定義になってしまいます。
numerをvarで宣言してlocally{}の中で値を設定すればできますけど。

706 ：デフォルトの名無しさん：2011/08/16(火) 15:31:47.56

nもdもgcdに渡して戻り値をタプルにするか、
nもdもgも受け取るメインのコンストラクタにするかって解決策しか浮かばない
もっと良いやり方がのかもだけどそこまでscalaを使いこなせてない。

707 ： ◆CgacaMDhSQ ：2011/08/16(火) 17:43:40.83

>>705
ありきたりだが、こんなのとか。

class Rational(n:Int, d:Int){

private def gcd(x:Int, y:Int): Int = {
if (x==0) y
else if (x<0) gcd(-x, y)
else if (y<0) -gcd(x, -y)
else gcd(y%x, x)
}

val (numer: Int, denom: Int) = {
val g = gcd(n, d)
(n / g, d / g)
}
}

708 ：デフォルトの名無しさん：2011/08/16(火) 20:13:18.14

>>706 >>707
ありがとうございます。タプルにすればできました！707をそのまま打ち込みました。
こんなふうにできるとは知りませんでした。

709 ：デフォルトの名無しさん：2011/08/18(木) 02:52:58.65

コップ本の第2版が出るのか
前からあんまり時間経ってないから買う気しないな

710 ：デフォルトの名無しさん：2011/08/18(木) 07:27:17.09

>>709
Scalaスケーラブルプログラミング第2版
http://www.amazon.co.jp/dp/product/4844330845
『Scalaスケーラブルプログラミング第2版』 2011/09/27発売予定
http://d.hatena.ne.jp/kmizushima/20110817/1313584677
>私もほんの少しですが、Scala 2.9の新機能解説
>(原著第二版出版時には2.9がリリースされていなかった)という形で執筆に携わった

いまさらScala 2.8の本は辛いなと思ったらそうきましたか。
これで「最新版に対応したScala入門書」と名乗れますね。

711 ：デフォルトの名無しさん：2011/08/18(木) 10:49:51.63

良書には下手に入門帯を付けないでほしい
「言語設計者がその思想を解説」でいいんだが
コンセプト＆コーディングじゃ掴みがわるいですかそうですか

編集「とりあえず入門って買いときゃ売れるんだよｗｗｗｗ」
みたいな出版はノーモア

712 ：デフォルトの名無しさん：2011/08/18(木) 11:32:04.41

>>711
もっと具体的に

713 ：デフォルトの名無しさん：2011/08/18(木) 21:00:24.43

4830円とか何様のつもりだよw

714 ：デフォルトの名無しさん：2011/08/18(木) 21:08:48.79

誰か炊いてくれ

715 ：デフォルトの名無しさん：2011/08/18(木) 23:10:25.76

当然自炊
最初から電子書籍だといいのだけどこの国は

716 ：デフォルトの名無しさん：2011/08/19(金) 01:46:25.66

2.9.1 RC3

717 ：デフォルトの名無しさん：2011/08/19(金) 02:10:00.68

こないだScalaスケーラブルプログラミング買ったばっかなんだけど・・・・

718 ：デフォルトの名無しさん：2011/08/19(金) 02:11:16.33

経費で落とせるから問題ない

719 ：デフォルトの名無しさん：2011/08/19(金) 10:16:23.10

>>717
Scalaアンバサダーに任命してやろう

720 ：デフォルトの名無しさん：2011/08/19(金) 10:47:22.52

だから代数データをもっとふやせよぼけおだ。
毎回毎回Seq,Set,Mapでつくってかなきゃならないからボトムアップ的にならざるを得ないんだよ。
Javaのオブジェクトではなくて、代数データ型でもっと色々なライブラリを用意すべき、
そうでないとボトムアップ的なプログラミングしかできない。
そうでなくても関数型はボトムアップになりやすいのだから。

すべてのぼけどもへ

721 ：デフォルトの名無しさん：2011/08/19(金) 12:02:58.81

722 ：デフォルトの名無しさん：2011/08/19(金) 12:15:49.39

いまさら

723 ：デフォルトの名無しさん：2011/08/20(土) 14:47:41.78

はっきり言って、強く型付けされていない言語なんて使い物にならん。
もっとはっきり言えば、型とか知らない連中がわかった気になって型なんかいらないとか言ってるだけ。
もっともっといえば、「自由」でなくなるとかいってるやつは、本気の馬鹿？型があっても何も不自由になりませんし、
そんなところに[自由」とか持ち出す完成がまじ引きこもりの中２病

こんなところだな。

724 ：デフォルトの名無しさん：2011/08/20(土) 15:04:36.89

楽な部分がいっぱいあるよ。
例えば数字が記入されてるテキストファイルを読み込んで、合計を求めるとか使い捨てツールを作る時とか。
PHPとかならサーバの環境構築も楽チン。
もちろんしっかりした物を作る場合はバリデーションするから結局、型ありと同じになるからそれなら最初から...って話になるけどね。

725 ：デフォルトの名無しさん：2011/08/20(土) 15:06:54.00

実際スクリプト言語(弱い型付)で書かれた使い物になるものが世の中にあるわけなんですがね。

726 ：デフォルトの名無しさん：2011/08/20(土) 15:10:17.98

型をガチガチに固めてしまうと、色々な型に通用するような汎用的な処理が書きづらい。
例えば、filterやmapcarみたいなリスト処理(中身の型は決めることが出来ない)とかね。
ジェネリクスとかで多少の対応は出来るが、型を考えてる時間が長くなるし。
それだったら本筋のロジックに集中したいよ。

727 ：デフォルトの名無しさん：2011/08/20(土) 15:37:12.32

おまえらが勝手に頭の中で作り上げている型にたいして、いちゃもんつけているだけｗｗｗ

filter,map, リスト処理、型付きでもまったくがちがちになりませんｗｗｗ

ジェネリクスとか型の世界で言えば風のヒューィレベルｗｗｗｗ

728 ：デフォルトの名無しさん：2011/08/20(土) 15:46:22.22

風のヒューイて何？

729 ：デフォルトの名無しさん：2011/08/20(土) 16:29:37.87

>>723みたいな頭の硬い人はSIErに多い気がする

730 ：デフォルトの名無しさん：2011/08/20(土) 16:36:02.10

sierはぷろぐらみんぐなんてしないだろ

731 ：デフォルトの名無しさん：2011/08/20(土) 16:51:03.91

実際頭が固くて＆頭が悪くて＆自分が理解できないものをけなすことで自己保身しているのが
どっちなのかなんて明らかなんだけど。型なしが良いとかいってるのは
そのほとんどが狭いコミュニティでなれあってる引きこもりプログラマｗ

732 ：デフォルトの名無しさん：2011/08/20(土) 17:07:17.64

Ruby 厨が必死に CoC の素晴らしさを伝えてる姿を見ると、
そうだその先に静的型付言語の世界があるのだ、あと一歩だ頑張れ、と目頭が熱くなります。

733 ：デフォルトの名無しさん：2011/08/20(土) 17:12:01.63

>>731
いやどっちが良い悪いではなく、どちらにも長所短所があるという話よ

734 ：デフォルトの名無しさん：2011/08/20(土) 17:13:37.08

いやどっちも長所短所があるというはなしじゃないんだよ。
そこがもうほとんどまちがっている。
どこからどう見ても、型があった方が良いという話なんだよ。

わかってないやつばっかｗ

735 ：デフォルトの名無しさん：2011/08/20(土) 17:15:44.50

>>730
前から不思議に思ってたんだが、System Integratorの略がなんでSIerになるんだ？

736 ：デフォルトの名無しさん：2011/08/20(土) 17:17:57.03

SI は System Integration だろう。違うのか?

737 ：デフォルトの名無しさん：2011/08/20(土) 17:17:56.72

>>735
System Integrate をする人って意味

738 ：デフォルトの名無しさん：2011/08/20(土) 18:36:40.90

(´-｀)｡o０（なにか嫌なことでもあったのだろうか…)

739 ：デフォルトの名無しさん：2011/08/20(土) 18:45:16.49

静的なScalaスレで何言ってんだ
Rubyとかそれ系のコミュニティで発言して来いよ
そもそもお前のいう使えない言語を作ってるのはどんな人間でどんな言語で作ってるのかってーの

740 ：デフォルトの名無しさん：2011/08/20(土) 19:22:44.81

スクリプト言語＋作り捨てWebフロントでバカにも雇用ができて喜ばしいことだが、
バカ故に自分たちが時代の最先端開発とか勘違いしてる奴が多すぎて萎える。

741 ：デフォルトの名無しさん：2011/08/20(土) 19:25:35.71

そのとおり、ぽっと出の馬鹿が何も知らずに最先端きどっって、さらにエンジニア、プログラマ気取り、
すくいよーねーなｗ

742 ：デフォルトの名無しさん：2011/08/20(土) 19:30:32.98

静的言語 vs 動的言語スレはここらしいよ
http://hibari.2ch.net/test/read.cgi/tech/1313314178/

743 ：デフォルトの名無しさん：2011/08/20(土) 19:49:10.12

糞スレに誘導すんな

744 ：デフォルトの名無しさん：2011/08/20(土) 19:51:25.72

ま、いまどき、ruby,perl,pythonとかいってるやつは少なくともプログラミングと言う観点からは素人だなｗ

745 ：デフォルトの名無しさん：2011/08/20(土) 20:29:57.92

Unix系のやつらはCを補完する形で使ってるよ

746 ：デフォルトの名無しさん：2011/08/20(土) 20:43:44.92

解決策を１つの言語に詰め込もうとしていた日々は、消え去ろうとしています。
私たちは、JavaとCLRという優れたマネージド・ランタイムを持っているので、
よりよいツールを使ってそれらのプラットフォームを利用するべきです。
多言語プログラミングは、重要な仕事をする既存のすべてのコードを捨てることなしに、
解決策をミックスし適用する事を可能にしてくれます。これらの２つの実績あるプラットフォームで
爆発的に新しい言語が開発されています。開発者として、仕事により適したツールを使って、
より良いコードを書くことが出来るように、この正調を活用する方法を学ぶべきです。

[The ThoughtWorks Anthology 4章多言語プログラミングより]

747 ：デフォルトの名無しさん：2011/08/20(土) 21:07:20.78

>>744
Perl,Pythonはともかく、Rubyは興味深い所を持ってると思うし、簡潔で強力だと思うよ。
matzが多言語の良所を把握出来る言語オタで良かったと思う。
静的型付けが無いのは個人的にいただけないけど、そう馬鹿にしたもんでもないかと。
Perl,Pythonにしても、バッドノウハウの轍を踏まないようにその悪所を見る意味はあるかと思う。

んで、玄人様はどんな言語を使ってるんで？
素人のぼくちんに教えちくり

748 ：デフォルトの名無しさん：2011/08/20(土) 21:18:27.10

matzは型については素人に付け焼刃つけた程度ｗ

749 ：デフォルトの名無しさん：2011/08/20(土) 21:35:16.26

具体的に何がダメなのか全く説明が無いよね
この時代に言語単位レベルでよくもそこまで人を馬鹿にできるな

750 ：デフォルトの名無しさん：2011/08/20(土) 22:11:00.80

人を馬鹿にしてるんじゃない、型があるほうがないよりいいって言うあたりまえのことをいってるだけｗ
これくらいで人を馬鹿にすることになるなら、どんな人だってどれだけの人を馬鹿にしていることになるか
かんがえたほうがいいよｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

751 ：デフォルトの名無しさん：2011/08/20(土) 22:21:36.44

だから何でなのかその理由をかけよ

752 ：デフォルトの名無しさん：2011/08/20(土) 22:43:19.42

ないよりあるほうがいいにきまってるだろ。
むしろ無いほうがいいとかいってるやつの方が理由を書くべきだろ。あほかｗ

753 ：デフォルトの名無しさん：2011/08/20(土) 23:15:05.80

オライリー本は難しそうで避けてきたけど、Scalaのやつは理解出来そうかも

754 ：デフォルトの名無しさん：2011/08/20(土) 23:57:15.08

静的型付けだとヘテロなリストとか作るの面倒くさいだろ…

755 ：デフォルトの名無しさん：2011/08/21(日) 00:03:56.07

ヘテロなリスト（笑）で問題起きた時の分析のほうが面倒臭いわ。

756 ：754：2011/08/21(日) 00:09:10.55

いや「だから動的型付けを使うべき！！」とか言ってるわけじゃなくてね…
使い分けたらいいんじゃないですか、って言ってるんですよ
ちょっとした使い捨てツール書くときでも型に縛られたいマゾヒストさんなんですか？

757 ：デフォルトの名無しさん：2011/08/21(日) 00:11:35.26

たまにそういうドMを見かける

758 ：デフォルトの名無しさん：2011/08/21(日) 00:44:56.92

ちょっとした使い捨てプログラムの話は動的vs静的でありがちなネタの1つだな
そのうち静的型チェックとテストの話やリファクタリングの話になるのかな

759 ：デフォルトの名無しさん：2011/08/21(日) 01:27:51.40

強い型付けと静的型付けが混同されている気がしてならない

760 ：デフォルトの名無しさん：2011/08/21(日) 01:29:17.77

動的で強い型付けなんてあんの？

761 ：デフォルトの名無しさん：2011/08/21(日) 01:37:14.72

python

762 ：デフォルトの名無しさん：2011/08/21(日) 01:43:21.24

静的な型づけでもヘテロなリスト簡単に作れるだろ
強い型づけというのは”強さ”が何を意味するのかわからん

763 ：デフォルトの名無しさん：2011/08/21(日) 01:48:35.62

http://en.wikipedia.org/wiki/Strong_typing

764 ：デフォルトの名無しさん：2011/08/21(日) 02:02:25.92

subtyping, gradual typing , parametric polymorphism こんなんどんどんいれていけば、
もう強い型づけと弱い型付けのちがいはあるにしても、明瞭なくべつはなくなっていくだろう。

int , float, string のリストをつくったとき
型システムA⇒タイプエラー
型システムB⇒int,float,stringのleast upper bound 型のリスト
…

全て静的な型づけだけど、その強さはちがう

765 ：デフォルトの名無しさん：2011/08/21(日) 02:32:24.80

(´-｀)｡o０（>>750 の本当の狙いはこれだろう…)

http://www.blue.sky.or.jp/grass/doc_ja.html

766 ：デフォルトの名無しさん：2011/08/21(日) 06:47:16.06

Scala等で↓のような関数を定義しようとすると、
型システムを黙らせるためにクラス等を持ちださなければならないので面倒。

def f(a:Int)(b:Int) = (a+b, f(a+b))

767 ：デフォルトの名無しさん：2011/08/21(日) 09:33:50.47

それバグってるから黙らせちゃアカンがな

768 ：デフォルトの名無しさん：2011/08/21(日) 09:48:56.56

静的型言語で実行できないプログラムはすべてバグですかそうですか。
これじゃ動的型言語で簡単に書けるケースをいくら挙げても無駄だわな。

ちなみに、こうすればScalaでも実行できるけど、わざわざこんな風に書き換えるのは面倒。
case class f(a:Int) { def apply(b:Int) = (a+b, f(a+b)) }

769 ：デフォルトの名無しさん：2011/08/21(日) 09:57:16.96

いや、もうちょっと役に立ちそうな例を挙げろよ
アホすぎて突っ込む気にもならん

770 ：デフォルトの名無しさん：2011/08/21(日) 10:04:54.49

反論できないと「役に立ちそうにないから」とか言い訳を始めるとか、予想通りすぎるw

このプログラムは、副作用を使わずに合計を保持する関数。
自分がPDFのラスタライザを作ったときに問題になった箇所のエッセンスを取り出したものだ。
PDFのラスタライザが役に立ちそうにないとでもいいたいのか?

771 ：デフォルトの名無しさん：2011/08/21(日) 10:23:38.47

つまりカリー化をそなえた動的型言語が最強ってことですね、わかります
でも、Perl, Ruby, Pythonってそうだったっけ？

772 ：(1) ◆CgacaMDhSQ ：2011/08/21(日) 10:27:24.55

>>770
それがエッセンスかどうかは、PDFのラスタライザ作った事が無いので判断できませんが
静的型付けで型が付きにくそう、という点でうまいところをついていると思います。ただ、これが
静的型付け言語で実行できないか、というとそういうわけでもなく、equi-reqcursive-typeという
型システムがあれば、実行できます。Scalaはequi-recursive-typeそのものをサポートしてない
のですが、OCamlだと-rectypesを付ければ実行できます。たとえばこんな感じです。
>ocaml -rectypes
Objective Caml version 3.11.0

# let rec f a b = (a+b, (f (a+b)));;
val f : int -> (int -> int * 'a as 'a) = <fun>
# f 3 4 ;;
- : int * (int -> 'a) as 'a = (7, <fun>)
# fst (f 3 4);;
- : int = 7
# (snd (f 3 4)) 5;;
- : int * (int -> 'a) as 'a = (12, <fun>)

773 ：デフォルトの名無しさん：2011/08/21(日) 10:34:33.26

このスレでOCamlを出すなんて酷いw

774 ：デフォルトの名無しさん：2011/08/21(日) 11:06:40.44

さあ、次は first class polymorphism の例を探すんだ

775 ：デフォルトの名無しさん：2011/08/21(日) 11:09:09.02

Rubyが最強ってことだろ

776 ：デフォルトの名無しさん：2011/08/21(日) 11:11:44.52

バグではなかったw

777 ：デフォルトの名無しさん：2011/08/21(日) 11:17:15.15

>>772
-rectypesを使わなくても似た事は出来るしね

> ocaml
Objective Caml version 3.12.1

# let rec f x y = `F(x + y, f (x + y));;
val f : int -> (int -> [> `F of int * 'a ] as 'a) = <fun>
# let `F(a, g) = f 3 4;;
val a : int = 7
val g : int -> [ `F of int * 'a ] as 'a = <fun>
# let `F(b, h) = g 5;;
val b : int = 12
val h : int -> [ `F of int * 'a ] as 'a = <fun>

778 ：デフォルトの名無しさん：2011/08/21(日) 11:18:24.29

型なんてある意味無いだろ
複雑化するし有害

779 ：デフォルトの名無しさん：2011/08/21(日) 11:21:04.63

動的型付けでも型はあるんだぜ

780 ：(2) ◆CgacaMDhSQ ：2011/08/21(日) 11:38:11.20

で、Scalaでこのようなのを定義したい場合、無理やりequi-recursive-typeをエミュレートすることもできますが、
それやると型が複雑になるので、これくらいでとどめておくのが良いような気がします。

scala> case class FTuple[X](_1: X, _2: X => FTuple[X])
defined class FTuple

scala> def f(a: Int)(b: Int): FTuple[Int] = FTuple(a + b, f(a + b))
f: (a: Int)(b: Int)FTuple[Int]

scala> f(3)(4)
res0: FTuple[Int] = FTuple(7,<function1>)

scala> res0._1
res1: Int = 7

scala> res0._2(5)
res2: FTuple[Int] = FTuple(12,<function1>)

781 ：(2) ◆CgacaMDhSQ ：2011/08/21(日) 11:45:27.45

>>777
はい。Polymorphic Variantでエンコーディングはできるだろうなーとは思ってました。ただ、一応
直接的なサポートが静的型付けで可能ということで、-rectypes使ってみました。Scalaで同様の
エンコーディングをしようとすると、型推論が弱いせいで、型注釈が複雑になるのが欠点ですね…。

782 ：デフォルトの名無しさん：2011/08/21(日) 11:57:56.30

どうして、Scalaは再起の返り値を型推論してくれないんでしょう？
なんか理由がある？

783 ：デフォルトの名無しさん：2011/08/21(日) 12:05:47.37

静的つっても型システムは一種類じゃなくて
言語やオプションによっても変わりうるのに
だた「型」としか言われない不思議

784 ：(3) ◆CgacaMDhSQ ：2011/08/21(日) 12:12:35.10

>>782
再帰型じゃなくて、再帰関数の返り値型を推論してくれるかどうか、ですよね？
理由としては、Scalaの型システム上で一般的に再帰関数の返り値型を推論する、
健全で完全な型推論アルゴリズムを作るのが困難(ひょっとしたら決定不能かも)だからかと。
再帰関数のテキトーなサブセットについて推論するアルゴリズムを構成するのは難しくないと思いますが、
中途半端に頑張られても帰ってややこしいので、今くらいの割り切りで丁度いい気もします。

785 ： ◆CgacaMDhSQ ：2011/08/21(日) 12:20:26.45

>>783
おっしゃる通りですね。「静的型付け」 VS. 「動的型付け」論争がよくありますが、実際には、
一口に「静的型付け｣と言っても様々なシステムがある、という事はもう少し知られても良い気がします。

786 ：766：2011/08/21(日) 12:23:28.12

>>772,777,780
以前静的型言語でこの問題に引っかかって、>>768 の方法で回避したけど、
もっといい方法があるんじゃないかとずっと気になってた。

結論としては、OCamlなら可能 (Scalaだと作りこみが必要) ってことかな。
OCamlはやったことないけど、今度処理系を入れてみるわ。

787 ：デフォルトの名無しさん：2011/08/21(日) 12:25:58.17

>>784
多分そうだと思うんだけど、むずむず気持ち悪いので証拠が欲しい。
推論できない反例とかある？
「この論文に書いてあるから嫁」でもいいよ。

788 ： ◆CgacaMDhSQ ：2011/08/21(日) 13:42:09.88

>>787
反例はちょっと考えて見ます。
論文については、何らかの型システムを対象にして、完全で健全な型推論アルゴリズムを構成できる/できない
とかいう「全体的な」話が書いてあるものはよく見かけますが、「返り値型の型推論に限定」した場合の型推論アルゴリズムの
決定不能性についてはちょっと読んだことがありません。自分は型システム専門じゃないので、あるいはそういう論文が
あるかもしれませんが。

789 ：デフォルトの名無しさん：2011/08/21(日) 15:44:48.05

でもこういう再帰を返り値とする構造ってScalaのコンセプトである
スケーラビリティな方向への拡張性を活かせないんじゃないの
線形なリストにしてmap/reduceって作りにするのじゃだめなんですか？

790 ：デフォルトの名無しさん：2011/08/21(日) 16:07:57.87

C#4と.net4のdynamic
http://msdn.microsoft.com/ja-jp/magazine/gg598922.aspx
コンパイル時で決まらない型は、（動的言語含む）動的インターフェースとのやり取りにあるといいなという感じ？
一時的なtsvの読み込みにしろそういう例になるのかな？

791 ：766：2011/08/21(日) 17:38:01.08

>>789
もしかして私へのレスでしょうか。

PDFは内部的にパス描画モードやテキスト描画モード等を切り替えで描画しており、
さらにモードごとに異なる内部状態を保持しなければなりません。
そのため、モード切替の命令が来たら、そのモードを専門に処理する関数を返すような設計にしようとしたのです。

できるだけ副作用に頼らないという方針だったのでこのような設計になりましたが、
副作用を使っても構わないのであれば、線形なリストにすることも可能だと思います。
でもそれだと、自分の当初の方針から外れてしまうのです。

792 ：デフォルトの名無しさん：2011/08/21(日) 17:39:15.29

で、結局この言語の読み方はスケーラなの？スカラなの？

793 ： ◆CgacaMDhSQ ：2011/08/21(日) 17:50:37.55

>>791
本題からそれてしまいますが、その話だけ聞くと、あえて>>766のような構造にしなくても良いように感じてしまいます。
>>772でレスした時点では、静的に型付けしづらいサンプルという意味で面白かったのと、>>766のようなコードの
実際の使用局面がよくわからなかったため、本当に必要かどうかは問いませんでしたが。

794 ：766：2011/08/21(日) 18:14:32.62

>>793
まず、>>770 では実用コードで直面した問題だったと主張したかっただけで、
それがPDFを解釈する上で必ず必要になると言いたかったわけではありません。
あのような構造にしたのは私の趣味の部分が大きいです。
>>769 に反論するために誇張してしまいました。すみません。

実際の構造としては、ここの「なんでも再帰」にあるような相互末尾再帰的な作りにしようとしていました。
ttp://practical-scheme.net/docs/tailcall-j.html

しかし、一般的な言語だと、末尾再帰が必ず最適化されるとは限らないため、
スタックオーバーフローを防ぐために、
次に呼び出したい関数をいったん呼び出し元に戻り値として返し、
呼び出し元から呼び出すという作りにしています。

795 ：デフォルトの名無しさん：2011/08/21(日) 18:26:14.23

JVM(JDK7)のInvokeDynamicって
Scalaでも
言語間インターフェースとかに使い道あるの？
動的言語側で実装すればいいの？
http://www.infoq.com/jp/news/2011/01/invokedynamic

796 ：デフォルトの名無しさん：2011/08/21(日) 18:44:27.03

PDFの解析にこんなむちゃくちゃな
実装必要なのかメンドイな

797 ：デフォルトの名無しさん：2011/08/21(日) 18:58:28.43

PDFの元になっているPostScriptが、スタックマシーンだった。

798 ：デフォルトの名無しさん：2011/08/21(日) 20:01:44.41

また静的型付けの勝利だなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

799 ：デフォルトの名無しさん：2011/08/21(日) 21:14:00.50

>>792
スカラ

800 ： ◆CgacaMDhSQ ：2011/08/21(日) 22:33:32.39

>>794
なるほど。了解しました。それなら話は理解できます。>>766のような構造が本質的に
必要、という主張なのかと思っていました。すいません。

> 次に呼び出したい関数をいったん呼び出し元に戻り値として返し、
> 呼び出し元から呼び出すという作りにしています。

これは、Scalaだとscala.util.control.TailCallsで末尾呼び出しの最適化を
エミュレーションしてるのと同じようなテクニックと考えてOKですか？要は
トランポリンの一種ですが。

801 ：デフォルトの名無しさん：2011/08/21(日) 22:43:20.05

例えばreduceを使ってて、後で実装を置き換えられるようにreduceを引数で渡す場合、
Scalaではどう書いたら良いですか？
下のはPythonで書いたサンプルです。

def f(my_reduce):
    g = lambda x,y: x + y
    a = my_reduce(g, [1, 2, 3])
    b = my_reduce(g, ['a', 'b', 'c'])

802 ：766：2011/08/21(日) 23:11:26.85

>>800
>これは、Scalaだとscala.util.control.TailCallsで末尾呼び出しの最適化を
>エミュレーションしてるのと同じようなテクニックと考えてOKですか？要は
>トランポリンの一種ですが。
その通りです。
ただし、PDFの命令列を持ちまわるのが嫌だったので、単独の命令を毎回渡す仕様にしています。

正直、TailCallsの存在は忘れてました。
命令列を持ちまわるようにしてTailCallsを使えば、あのような構造は必要なかったでしょう。
まあ、このプログラムはScalaで作ったわけではないので関係ないのですが。

803 ：デフォルトの名無しさん：2011/08/21(日) 23:42:39.62

ま、うえでいろんな人が形を変えていってたけど、
型システムといっても色々あるってのをわかってないんだよ。
で、自分がわかってないのを棚に上げて、というか、わかってないからこそ、動的！動的！といってるだけｗ

ま、極論を言えば、型なんかいらないとかいってる本気の馬鹿は、syntaxなんていらないといってるのと同じだよｗ
どんな動的言語（なんだそれｗ）にでも制限はあるからね、その制限が何かしらのinvariantをさしていることがわかってないんだよｗ

804 ：[1] ◆CgacaMDhSQ ：2011/08/21(日) 23:48:27.19

>>801
ランク2多相をどうエンコードするかという問題(Scalaはランク2多相の言語レベルサポートが無いので)ですよね。
とりあえず、解いて見ました。
まず、加算だけできる型クラスがScalaには標準で無いので定義してやります(Numericは必要なメソッドが多過ぎるので×)

scala> trait AddT[X] { def plus(a: X, b: X): X }
defined trait AddT

型クラスのインスタンスも作ってあげます。

scala> implicit object IntAdd extends AddT[Int] { def plus(a: Int, b: Int) = a + b }
defined module IntAdd

scala> implicit object StringAdd extends AddT[String] { def plus(a: String, b: String) = a + b }
defined module StringAdd

805 ：[2] ◆CgacaMDhSQ ：2011/08/21(日) 23:52:43.55

問題はその後です。>>801の例は、my_reduceを異なる複数の型に適用しているもので、直接的に書くには、ランク2多相性と呼ばれるもののサポートが必要です。
これはScalaでもMLでもOCamlでもHaskellでも標準ではありません(Haskell(GHC)はpragmaでONにできますが)。

これをランク2多相が無い言語でやるのは少し骨が折れますが、書いてみました。

scala> def f(reduce: { def apply[A:AddT] : ((A, A) => A, List[A]) => A }) {
| def g[A:AddT](x: A, y: A) = implicitly[AddT[A]].plus(x, y)
| println(reduce.apply[Int].apply(g, List(1, 2, 3)))
| println(reduce.apply[String].apply(g, List("A", "B", "C")))
| }
f: (reduce: AnyRef{def apply[A](implicit evidence$1: AddT[A]): ((A, A) => A, List[A]) => A})Unit

scala> f(new { def apply[A:AddT] = (f: (A, A) => A, lst: List[A]) => lst.reduceLeft[A](f) })
6
ABC

このコードが何を意図してるのかは、説明すると長くなるので、ランクN多相とかでググってくださると助かります。

806 ：801：2011/08/22(月) 00:22:18.17

>>804 >>805
丁寧な解説ありがとう。
直接書くとfの引数のところでmy_reduceの型がどれか一つに固定されてしまうのを
Scalaではこうやって避けるんですね。

807 ：デフォルトの名無しさん：2011/08/22(月) 00:46:33.34

お前らがなに言ってるのか全然わからん
だからお前ら出入り禁止な

808 ：デフォルトの名無しさん：2011/08/22(月) 01:27:53.40

難しそうに見えても、言ってることは別段難しいことではないよ。
キニシナサンナ

809 ： ◆CgacaMDhSQ ：2011/08/22(月) 01:31:57.04

>>808
そうですね。実際の所、概念としてはランク2多相とか特に難しくはないと思います。
説明の手間を省くために、既存の用語を使っているだけの話なので。

810 ：デフォルトの名無しさん：2011/08/22(月) 03:56:33.51

>>753
他のオライリー本と比べて特段どう、ということは無いと思うが

811 ：デフォルトの名無しさん：2011/08/23(火) 16:51:32.40

このスレのおかげで、動的型付けの方が
ロジックに集中できると再認識できたw

812 ：デフォルトの名無しさん：2011/08/23(火) 17:51:19.50

ランク2多相とか完全な型推論できないしな
やっぱ動的型最強だな

813 ：デフォルトの名無しさん：2011/08/23(火) 17:53:14.64

scala> res811.replaceFirst("ロジックに集中できると", "自分の能力の限界が")

814 ：デフォルトの名無しさん：2011/08/23(火) 18:05:05.66

静的型言語でできないことで動的言語でやって許せるのはダックタイピングくらいだな
>>801の例もダックタイピングに近いけど
evalとか見ると死ねと思う

815 ：デフォルトの名無しさん：2011/08/23(火) 19:00:40.65

動的型付け言語であっても、
evalはかなり抑制的に使われるのが普通だと思う

816 ：デフォルトの名無しさん：2011/08/23(火) 23:13:45.57

ロジックに集中ってことばほんと馬鹿っぽいよな
実際、型こそロジックなんだよ。
型を考えるという部分のみがロジックであってあとはアルゴリズム。

817 ：デフォルトの名無しさん：2011/08/23(火) 23:31:18.39

んじゃアルゴリズムに集中でいいよもう
何れにしてもどちらも長短あるんだから
どっちか片方が優れてるとかは無い

818 ：デフォルトの名無しさん：2011/08/23(火) 23:48:15.54

いや、型がある方が無いより優れているに決まってる。
型システムはあったほうがいい、で、オプションでもっとも緩い型システムに変更できるようにすればよいだけ。

819 ：デフォルトの名無しさん：2011/08/23(火) 23:59:48.54

緩くしすぎたら型推論が停止しない可能性があるのと違うん？

820 ：デフォルトの名無しさん：2011/08/24(水) 00:11:01.07

完全性を諦めればいいだけ、というか、完全性がある型推論持ってるのってOCamlくらいか？

821 ：デフォルトの名無しさん：2011/08/24(水) 00:20:12.58

Type system を緩くというのは、単に型なし（というか静的な型チェックをどんどんしない方向）に
近づけていくということなのでは？

822 ：デフォルトの名無しさん：2011/08/24(水) 00:28:17.65

そんなに型が嫌いならpythonでも使ってろよタコ。

ところでscalaでオススメのWAF教えてください。

823 ：デフォルトの名無しさん：2011/08/24(水) 00:44:04.65

WAFって何よ？

824 ：609：2011/08/24(水) 00:46:16.48

SystemF
http://ja.wikipedia.org/wiki/%E5%9E%8B%E4%BB%98%E3%81%8D%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97
http://ja.wikibooks.org/wiki/Haskell/Polymorphism#Polymorphism_.E9.AB.98.E9.9A.8E.E5.9E.8B
完全な型システム求めたら、決定不能に陥ることはあるんじゃないかな？

関係無いけどシークエント記法
http://www.lambdassociates.org/Studies/study01.htm

825 ：デフォルトの名無しさん：2011/08/24(水) 00:50:33.81

型システムが決定不能になることはない。アノテーションつければよいだけ。
（型システムが決定不能っていいかたは少しおかしいのかな？？）
型推論は決定不能に陥ることがある。

826 ：デフォルトの名無しさん：2011/08/24(水) 01:12:40.50

>>822
型を嫌ってる人はこのスレには居ないと思うが…
居るのは、両方に長所と短所あるって人と
型ありが絶対的に優れているって人だけでしょ

827 ：デフォルトの名無しさん：2011/08/24(水) 01:15:52.38

Web の画面まわりは Java でもリフレクションでメタ記述しまくりだから
動的型附言語でも変わらんな。

828 ：デフォルトの名無しさん：2011/08/24(水) 06:14:00.80

実践なんとかみたいな新刊でてない？

829 ：デフォルトの名無しさん：2011/08/24(水) 06:35:58.77

>>822
煽りにマジレスもなんだが、Pythonは、"強い"動的型付言語だから、かなり型を意識しないとロジックを組めないんだが…。

WAFってWebApplicationFrameworkのことか？知名度からいえばLiftなんだが、俺はScalatraのが好きだな。

830 ：デフォルトの名無しさん：2011/08/25(木) 00:57:16.27

object Foo { val 1 = 2 }
がなぜかコンパイルできてしまうらしい。

https://groups.google.com/forum/#!topic/scala-user/k57U6jt8Za0
https://issues.scala-lang.org/browse/SI-4939

831 ： ◆CgacaMDhSQ ：2011/08/25(木) 01:20:04.11

>>830
そこ、Paul Phillipsもコメントしてるけど、たぶん仕様の範疇内。val 1 = 2は単にパターンマッチで
失敗してMatchErrorが飛ぶだけ。REPLのトップレベルで val 1 = 2がコンパイルエラーになったりする
のはREPLのバグっぽい気がするけど。

832 ：デフォルトの名無しさん：2011/08/25(木) 17:07:54.86

Javaから来た人は val がパターンマッチなことに驚き、
関数型言語から来た人はパターンが網羅的でないのに
コンパイル時に警告が出なくて驚く

833 ：デフォルトの名無しさん：2011/08/25(木) 17:35:59.53

どっちつかずで中途半端なものは結局廃れるってことだよな。

834 ：デフォルトの名無しさん：2011/08/25(木) 17:56:06.20

継承するかもしれんから網羅的にこだわるわけにもいかんだろ
sealedを付ければチェックしてくれるがな

835 ：デフォルトの名無しさん：2011/08/25(木) 18:05:33.29

驚き最大の法則を採用
一度びっくりしたら忘れないから

836 ：デフォルトの名無しさん：2011/08/25(木) 18:59:19.85

>>835
お陰で好き嫌いがハッキリ出る言語だが。。。
一度嫌ったプログラマは2度と触ろうとしないんじゃないか？

837 ：デフォルトの名無しさん：2011/08/25(木) 19:26:10.24

そうなのか
Haskellあたりなら極端な拒絶反応というのもわかるが
ScalaとかC#あたりはあまり極度に嫌いというやつは見ない気が

838 ：デフォルトの名無しさん：2011/08/25(木) 20:13:18.32

>>837
むしろhaskellは嫌いになる前に挫折するか、壁を超えて好きになるかだと思う
(単純すぎて分からないとかかも。自分もそうだったし)

ScalaはjavaやC/C++に慣れた人にも、関数型言語に慣れた人にも中途半端で気持ち悪く映るんじゃないかと
(Cやjavaっぽい文法のScalaだった方が良かった気がする)

839 ：デフォルトの名無しさん：2011/08/25(木) 20:30:04.70

関数型に慣れた人間が気持ち悪いというのは理解できるが、
Javaやってた人間が気持ち悪がる理由がわからない

840 ：デフォルトの名無しさん：2011/08/25(木) 21:23:19.57

コンストラクタとクラスのメンバ宣言がまざってるところとか？

841 ：デフォルトの名無しさん：2011/08/25(木) 21:33:31.87

そこはむしろ気持ちいい

842 ：デフォルトの名無しさん：2011/08/25(木) 21:36:44.48

>>841
そうかなぁ
かなり筋が悪い設計だと思うけど

843 ：デフォルトの名無しさん：2011/08/25(木) 21:45:42.32

コンストラクタで何か処理したいときはlocallyで囲っちゃってる

844 ：デフォルトの名無しさん：2011/08/25(木) 21:54:55.67

F#使いの皆さんに明示的コンストラクタと暗黙的コンストラクタどっちが好きか聞いてまわれば決着つくかもなｗ

845 ：デフォルトの名無しさん：2011/08/25(木) 22:23:00.93

>>839
TMTOWTDIを良しとするかどうかでしょ

846 ：デフォルトの名無しさん：2011/08/25(木) 22:23:09.00

俺はHaskell使いだったが、Scalaは気持ちいいところがいっぱいあるよ。java見たいに使えるし。

847 ：デフォルトの名無しさん：2011/08/25(木) 22:26:28.14

>>846
HaskellかScalaを勉強しようと思っているんですが、
Haskellと比べてScalaの気持ち良いところと、
逆にScalaと比べてHaskellの気持ち良いところを教えて頂けませんか？

848 ：847：2011/08/25(木) 22:27:08.26

あ、後者はあったらで良いです。お願いします。

849 ：デフォルトの名無しさん：2011/08/25(木) 22:55:21.15

sbtのバージョンとかややこしくてよく分からん
もういい、sbtなんて俺にはもういい・・・

850 ：デフォルトの名無しさん：2011/08/25(木) 23:20:29.30

テンプレ的でいいならいくらでもあるだろ
参照透明性とか遅延評価とか、型推論もHindley/Milner方式だしな
所詮Scalaは関数型の機能をオブジェクト指向言語の中で再現したものだからな
キモいっちゃキモい

851 ：デフォルトの名無しさん：2011/08/26(金) 08:29:41.97

>>849
よう、一ヵ月前の俺
はやくこっちへきてSpecs2と格闘しようぜ

852 ：デフォルトの名無しさん：2011/08/26(金) 14:34:47.58

specs2はテストが並列実行されるから
そのへん気を付けないとハマるよね

853 ： ◆CgacaMDhSQ ：2011/08/27(土) 00:09:06.97

>>850
Haskellの利点として、
＞参照透明性とか遅延評価とか、型推論もHindley/Milner方式だしな

は賛成しますが、

＞所詮Scalaは関数型の機能をオブジェクト指向言語の中で再現したものだからな

は、異論があります。これは、関数型とオブジェクト指向を対立軸としてとらえるから
出てくる気持ち悪さではないかと。私は、関数型とオブジェクト指向を直交した概念ととらえているので、二つの概念を
統合することは特に気持ち悪さは感じません。というか、関数型とオブジェクト指向の統合は古くからある研究でもありますし。

854 ：デフォルトの名無しさん：2011/08/27(土) 00:20:37.49

型推論とnominalな型システムって相性悪くない？

855 ：デフォルトの名無しさん：2011/08/27(土) 00:28:17.71

Scalaは複雑ですね。

856 ：デフォルトの名無しさん：2011/08/27(土) 01:12:56.81

コテうぜえ

857 ：デフォルトの名無しさん：2011/08/27(土) 02:28:48.50

>>856
そう思うんなら自説の開陳なり適切な論文の提示なりして自分で潰せよ

858 ：デフォルトの名無しさん：2011/08/27(土) 02:59:37.11

2chでコテがウザいと思うやつは専ブラでNGするもんだと思うがな

859 ：デフォルトの名無しさん：2011/08/27(土) 03:08:12.60

そもそもなにがウザいんだ

860 ：デフォルトの名無しさん：2011/08/27(土) 04:07:47.64

>>859

このスレを上から眺めると分かるが、荒らしが1名はりついている。それだけの話。

861 ： ◆CgacaMDhSQ ：2011/08/27(土) 05:29:52.39

>>854
凄く相性悪いと思います。たとえば、nominalなシステムで引数の型推論を簡単にやってみよう、ということで、

def foo(x) = x.setSize(200, 300)

とかやったとき、xに適合する型は無数にあって、その中でプログラマが意図しているであろう型を
適切に推論するのはほぼ無理です。しかも、コンパイル時のクラスパスによって型推論の結果が左右されてしまいますし。

また、nominalでなくとも、サブタイピングと型推論の相性自体が悪いという話があります。
strcutural subtypingでも、多相メソッドの推論とかしようとすると色々無理が出てきますし。
簡単な例でいうと、

def foldl(collection, init)(f) = collection.foldLeft(init)(f)

とか。このとき、collection, init, fの型+foldlの型パラメータ+foldlの返り値型を推論しようとすると、複数通りの結果が考えられますが、「最も一般的な
推論結果の型」が存在しないので、困ったことになります。

コテがうざいという方がもし多ければ、名無しになりますが、ことScalaに関しては、自分の言説には責任持ちたいので現在はコテやってるという話
ですね。

862 ：デフォルトの名無しさん：2011/08/27(土) 06:07:51.50

>>860 お前のことか

863 ：デフォルトの名無しさん：2011/08/27(土) 06:54:32.30

ぶっちゃげコテ付けてなくてもわかっちゃうと思うからそのまんまでいいと思うよ。
(私は割と楽しく読ませて貰ってるが)気に入らない人がNGしやすいしね。

864 ：デフォルトの名無しさん：2011/08/27(土) 09:04:14.17

多相メソッドの型推論が難しいのは
ランク2多相の型推論が難しいのと同じ理由だよね？

865 ：デフォルトの名無しさん：2011/08/27(土) 11:19:08.57

サブタイピングと型推論は相性悪い && 関数型で型注釈を書かされるのは苦痛
=> 関数型とオブジェクト指向は相性悪い（ただし静的型に限る）

静的型ではどこかでバランスを取る必要があるが
そのセンスが言語設計者と一致したときScalaが気持ちよくなる

866 ：デフォルトの名無しさん：2011/08/27(土) 12:30:50.95

>>853
強引すぎるだろw

関数型とオブジェクト指向、
HaskellとScalaじゃ重心配分が全然違う。

867 ： ◆CgacaMDhSQ ：2011/08/27(土) 19:42:15.87

>>866
重心配分が違う、というのはその通りかと。ただ、Scalaが目指している方向は「関数型オブジェクト指向言語」
(関数型にもオブジェクト指向にも書けるという意味ではなく、関数型(データがimmutable)かつオブジェクト指向(subtyping
polymorphism))であることはおそらく確かだと思います。これは、Odersky自身が何度も強調していることでもありますが、
関数型とオブジェクト指向は別に対立概念ではないです。

868 ：デフォルトの名無しさん：2011/08/27(土) 19:57:46.54

ブログ書いてツイートしておまけに長文の便所の落書きまでする
それも内容がほぼ一貫してScalaの話題
そのエネルギーを見習いたいもんだよ・・・仕事はやってんのか？

869 ： ◆CgacaMDhSQ ：2011/08/27(土) 20:48:29.84

>>868
仕事は普通にやっていますよ。Scalaとは縁が遠い仕事ですけど。
仕事から帰った後か土日で、主にブログ書いたりツイートしてます。

エネルギーというか、Scala関係の事書くのが日常化してしまった
というか娯楽化してしまったので、それ自体は特に苦痛でないですね。

870 ：デフォルトの名無しさん：2011/08/27(土) 20:51:01.79

臀痛マソ

871 ： ◆CgacaMDhSQ ：2011/08/27(土) 20:59:11.01

ただ、自分の姿勢はまああまり見習わない方がいい気もします。私生活に
おける学習の優先度は

Scala関係(Twitter) >> その他プログラミング言語関係 > JVMとかの実装読み > 各種論文読み

とかなってて、それはそれで楽しいですが、色々いびつな生活な気がしますし、
持ってる技術スキルもおかげでかなり偏ってますし。

872 ：デフォルトの名無しさん：2011/08/27(土) 21:51:01.34

>>847
関数型の特徴とか真髄みたいなのを手っ取り早く学ぶならばHaskell、
Java技術者が関数型で自分の仕事がどう変わるか知りたいならばScala、
.NET技術者が関数型で...ならばF#がいいと思う。

Haskellはコンパイラとして実用されている例は少ないが、その言語理論は幅広く
影響を与えていて、特にこれからの言語の行く末を知りたければ勉強しておくべき。

873 ：デフォルトの名無しさん：2011/08/27(土) 23:33:22.73

これからの言語の行く末はどこですか？

874 ：デフォルトの名無しさん：2011/08/28(日) 00:32:10.86

文脈依存文法に違いない。あれやっといて動くプログラム。

875 ：デフォルトの名無しさん：2011/08/28(日) 05:29:22.25

関数型とオブジェクト指向が対立概念でないとしても、
関数型の視点からみると、
Scala は他の関数型言語に比べて、
記述のスマートさや簡潔性で見劣りするように感じられ、
その原因となっているのが、クラスベースOOを、
土台としているために、余計な複雑さが
生じているからじゃないかと思うんですが、
皆さんどう思われますか？

876 ：デフォルトの名無しさん：2011/08/28(日) 06:27:33.23

クラスベースOOの特徴というと、
データとそれに対する操作をクラスっていう形で
紐付けたことだと理解しているけど、それだけで複雑になるとは思えないなあ
データ型を木（やDAG）の形で整理するのは関数型でもやるわけだから……

シンタックスが中途半端にJavaに引っ張られてるのが
記述上の冗長さを生んでいるんじゃないかなと思うけど

877 ：デフォルトの名無しさん：2011/08/28(日) 07:04:16.20

スマートさがないって、ML系のダサ文法見直してから来いよ

878 ：デフォルトの名無しさん：2011/08/28(日) 08:44:36.82

特に冗長なOCamlと比べてさえ
Scalaの文法は冗長なんだが

879 ：デフォルトの名無しさん：2011/08/28(日) 09:52:42.65

>>875
たしかにScalaは他の関数型言語よりちょっとシンプルじゃない気がするけど
クラスベースOOだからというよりJavaとの接続をシームレスにするためじゃないかな
しかし、ScalaはHaskellやMLのような浮世離れした存在ではなく、汚いところも
きちんと面倒を見るような現実的に利用しやすい言語という位置づけになってるんじゃ
ないかな。
Haskellが今後爆発的に利用されることは現段階では考えられにくいけど、
Scalaは確実にシェアを伸ばしていくんじゃないかな。

880 ：デフォルトの名無しさん：2011/08/28(日) 10:34:49.44

>>869
> 仕事は普通にやっていますよ。Scalaとは縁が遠い仕事ですけど。

scalaできる企業に転職しろよｗ

881 ：デフォルトの名無しさん：2011/08/28(日) 14:04:49.52

しかし今月のTIOBE IndexでF#が19位になってるよね
まじでビックリなんだが

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

882 ：デフォルトの名無しさん：2011/08/28(日) 14:06:04.22

>>878
具体的にどこがだよ

883 ：デフォルトの名無しさん：2011/08/28(日) 16:27:23.99

OCamlのダサいところ文法編

1. 文末がセミコロン2つ

2. メソッド呼び出しが「#」

3. 整数(+ - * /)と実数(+. -. *. /.)で演算子が違う

4. funとfunctionで分ける意味は？

5. 再帰するときはlet rec

6. なにこのトラップ

# [1, 2, 3];;
- : (int * int * int) list = [(1, 2, 3)]

884 ：デフォルトの名無しさん：2011/08/28(日) 18:02:50.14

>>883
良く知らない言語をdisるのって滑稽だなwww

885 ：デフォルトの名無しさん：2011/08/28(日) 20:00:35.95

>>882
>>772と>>780とか
多分>>805もOCamlの方が短く書ける

886 ：デフォルトの名無しさん：2011/08/28(日) 20:18:29.85

文法じゃねーだろ

887 ：デフォルトの名無しさん：2011/08/28(日) 20:45:02.23

え？

888 ：デフォルトの名無しさん：2011/08/28(日) 21:22:23.83

じゃあ、Scalaの文法は冗長って、equi-recursive typeがないからということでいいの？
つーかequi-recursive type使ってんの？

889 ：デフォルトの名無しさん：2011/08/28(日) 21:39:51.08

>>888
>>777

890 ：デフォルトの名無しさん：2011/08/28(日) 22:49:26.87

>>999

891 ：デフォルトの名無しさん：2011/08/29(月) 07:58:39.74

TreeSetにmutableな奴はないのですか？

892 ：デフォルトの名無しさん：2011/08/29(月) 12:22:23.70

>>883

1. 文末が明らかな場合はセミコロン二つを省略できるので、REPL以外では滅多に使わない

2. 型推論でレコードと区別するため

3. ad-hoc多相が無いから（ad-hoc多相を直接サポートするG'Camlという処理系がある）
ただし、Variantでad-hoc多相をエンコードすることは可能

4. functionは引数が一つしか取れないかわりに、引数にパターンマッチが書ける

5. let と let rec が分かれてると、既存の関数をデコレートしたいとき便利
（例：let foo = bar $ foo）

6. リストは[1; 2; 3]

893 ：デフォルトの名無しさん：2011/08/29(月) 13:15:38.94

ocamlじゃなくてF#ちょっとさわっただけだけど無名関数にfunが必要なのはうざいな、
F#スレでもうざいって言われててやっぱそうなんだ、と思った

894 ：デフォルトの名無しさん：2011/08/29(月) 14:02:33.05

>>892
理由を訊いてんじゃなくて、その設計がダサいって言ってんの

895 ：デフォルトの名無しさん：2011/08/29(月) 14:08:52.16

>>893
SMLでもfnが必要だけどね
しかしfunとfunctionの二つがあるのはダサいでしょ

896 ：デフォルトの名無しさん：2011/08/29(月) 14:14:43.70

Haskellでも \x -> ... だな
たぶん何らかの記号は必要なんだろう

897 ：デフォルトの名無しさん：2011/08/29(月) 15:37:49.43

>>895
TMTOWTDIだからダサいってことなら、Scalaは物凄くダサいってことに

898 ：デフォルトの名無しさん：2011/08/29(月) 15:50:05.36

いや分ける意味ないでしょ
しかも名前がfunとfunctionってひどすぎる
まあもういいけどね
ちょっと煽ってみただけだから

899 ：デフォルトの名無しさん：2011/08/29(月) 15:56:10.14

>>898
funとfunctionは機能が違うから

SMLにはfn一つしか無いけど、SMLのfnはOCamlのfunctionで、funに相当する構文は無い
だから引数が複数ある場合も fun x y z -> とは書けず
fn x => fn y => fn z => になる（別にこれはこれで良いけど）

900 ：デフォルトの名無しさん：2011/08/29(月) 16:10:32.27

それはSMLがカリー化をあまり使わない文化だからなのでは？
つまり、fn (x, y, z) => と書くことが多いから

901 ：デフォルトの名無しさん：2011/08/29(月) 17:35:14.20

SMLでも関数定義では fun f x y z = ... と書ける

902 ：デフォルトの名無しさん：2011/08/29(月) 19:11:08.28

Scalaの型推論の話なんだけど、
型を省略したらstructuralな部分型だと見なし、
nominalに型を指定したいときだけ型注釈を書く、という感じで
OCaml並みの型推論を得る事は出来なかったのかな？

903 ：デフォルトの名無しさん：2011/08/29(月) 21:15:12.78

@n_k28　消えろ

904 ： ◆CgacaMDhSQ ：2011/08/29(月) 21:41:09.29

>>902
現実的に色々難しい。まず、現在のScalaのstrutural typeのシステムには、これをメインの型システム
として採用するには重要な欠点がある。たとえば、「+演算子を持ってる任意の型」とかいうのを書きたい
としよう。Scalaプログラマ的には、

type Additive[T] = { def +(other: T): T }

と書きたいところではあるんだが、残念ながら、これはScalaの型システム上許されない。これは、どちらかというと
JVMの上でstructural typeを実現する上での制約ではあるのだけど。あと、structural typeをメインのシステムに据えるの
は、パフォーマンス面とかでも問題がある。

あと、仮にstrcutural typeをメインに据えて、↑のような実装の制限が無かったとしても、それでも型推論は難しい。
mapとかflatMapの多相メソッドを呼び出しているオブジェクト(strctural)の型をどうやって推論するか、ってのを考えると
たぶんその面倒くささがわかると思う。結構簡単なプログラムでも、推論結果が一意に決まらない事がわかる。実際のところ、
OCamlでもオブジェクトシステム使ってそういう推論やろうと思うと、型注釈が結局必要になったりする。

905 ：デフォルトの名無しさん：2011/08/30(火) 06:28:29.68

流れとは全く関係ないけど、
◆CgacaMDhSQさんは、誰かに読ませたい気があるのなら
Twitterに書いている長文をブログか何かにまとめて書いて欲しい。
文章の開始部分を見つけるのが面倒で読みにくいです。

906 ：デフォルトの名無しさん：2011/08/30(火) 07:28:50.75

>>905
お前ごときが何言ってるの？

907 ：905：2011/08/30(火) 07:38:15.19

非難されるようなことは言っていないつもりなんだが…

908 ： ◆CgacaMDhSQ ：2011/08/30(火) 08:40:24.87

>>905
うーん。確かに、Twitterで分散して書いちゃうと、開始部分がわかりにくて
読みにくいってのはありますね。誰かに読ませたいかというと、読んで
何か刺激を受けてくれたならありがたいけど、そこまで読ませたい、とは
思ってない、という微妙な感じです。どちらかというと、自分メモ的な
ものかもしれません。ともあれ、検討はしてみます。

# あと、書くコストの面からTwitterを安易に選んでしまう、というのが
# あって、これは問題かもしれないなあ、とは思っています。

>>906
たぶん私の事を慮っていただいたのだろうと思いますが、要望は要望
として、それを反映するかは自分で選択するので大丈夫です。

909 ：905：2011/08/30(火) 08:46:14.93

>>908
メモであればそのままで良いと思います～
レスありがとうございました。

910 ：デフォルトの名無しさん：2011/08/30(火) 19:27:10.63

>>908
はてなのTwitter記法かTogetterで良いのではないかと。

911 ：デフォルトの名無しさん：2011/08/30(火) 22:46:08.43

Scalaってモダンな言語で難しいって噂だから
使うの尻込みしてたけど
触ってみたら型付きPerlみたいな言語で
とっつきやすいね

912 ：デフォルトの名無しさん：2011/08/31(水) 00:17:17.99

F#は良い言語だね複雑じゃないし
JavaはダメだったけどC#が良かったように

913 ：デフォルトの名無しさん：2011/08/31(水) 00:50:26.89

おれはオブジェクトを使うならScalaだないまんところ、
使わないなら、普通の関数型言語でいい

914 ：デフォルトの名無しさん：2011/08/31(水) 01:04:48.35

普通の関数型言語って何だ？

915 ：デフォルトの名無しさん：2011/08/31(水) 01:28:44.87

>>914
Haskell様に決まってんだろ平伏せよ

916 ：デフォルトの名無しさん：2011/08/31(水) 01:40:26.90

HeHe～～～

917 ：デフォルトの名無しさん：2011/08/31(水) 04:43:38.24

ぶっちゃけあれだろ。
Scala, Scala 騒いでるのは、
JavaとかC#上がりのやつばかりだろ?
元々、関数型やLispをやってたやつで、
Scala 最高ですね、なんて言うやつ聞いたことねえわ。

918 ：デフォルトの名無しさん：2011/08/31(水) 05:00:20.29

俺はJavaよりは関数型で書いたほうが多いな
研究室で関数型やってたから
仕事はCだけど
関数型は常用しようと思うとライブラリがなくてゲンナリするからScalaに逃げた感じ
スクリプトを書くときはGaucheを使う

919 ：デフォルトの名無しさん：2011/08/31(水) 12:40:28.29

ScalaってJavaがぽしゃったらどうなるの？

920 ：デフォルトの名無しさん：2011/08/31(水) 12:58:05.51

>>919
共倒れ
だが、プログラミング言語は惰性力がすごいからな
一度頂点に立ったものがぽしゃることはない

921 ：デフォルトの名無しさん：2011/08/31(水) 14:40:58.16

Scalaのカリー化ダサ過ぎワロタwww

922 ：デフォルトの名無しさん：2011/08/31(水) 15:38:29.66

言語としてのJavaが仮にポシャってもJVMって死なないような気がするなぁ

923 ：デフォルトの名無しさん：2011/08/31(水) 17:05:22.53

Javaも資産の量が凄いから、この先30年は廃れることはないと思うな。
あるとしたら、JVM自体が何らかの限界に直面するとか、くらいか。

924 ：デフォルトの名無しさん：2011/08/31(水) 21:11:16.81

2.9.1の変更点の要約きぼんぬ

925 ：デフォルトの名無しさん：2011/08/31(水) 21:57:53.48

大きなトップダウン的に作成する拡張とかの可能があるプログラムはjavaのほうがいい。
でも比較的まとまった機能をブラックボックス的に作るなら小回りの利く関数型の方がよい。
なのでそのどちらでも対応できるscalaはここちいい。
これってまさにおだのどうきそのままじゃね？おれって。

926 ：デフォルトの名無しさん：2011/08/31(水) 22:39:17.42

>>924
変更点つかバグフィックスだけじゃね?

927 ：デフォルトの名無しさん：2011/08/31(水) 23:25:11.46

>>924
継続が死んでたのの修正とか。

928 ： ◆CgacaMDhSQ ：2011/08/31(水) 23:45:33.93

>>924
・REPLの起動速度が改善(環境にもよるだろうけど、自分の環境だと7秒→1秒になった)
・コンパイルも速くなってる(これも環境によるだろうけど、テキトーに色々なプログラム食わせてみた感じ、大体1.5倍くらい速くなってる。
・1.getClass()とかできるようになった
・バグフィックス色々

929 ：デフォルトの名無しさん：2011/08/31(水) 23:58:22.90

ほー、No more もっさり

930 ：デフォルトの名無しさん：2011/09/01(木) 03:26:38.04

コンパイル時間、一秒未満にならないかなぁ。
スクリプト的にちょっと書いて試すような使い方するには辛い。

931 ：デフォルトの名無しさん：2011/09/01(木) 03:40:05.64

fscなら...1秒未満は流石に無理か

932 ：デフォルトの名無しさん：2011/09/01(木) 07:50:41.43

コンパイルが速くなっても、scalaの起動が遅いままでは仕方ない。

933 ：デフォルトの名無しさん：2011/09/01(木) 14:15:51.10

REPLの起動速度は本当に早くなったな。
前が遅すぎたのがあるけど

934 ：デフォルトの名無しさん：2011/09/01(木) 23:29:57.80

REPLってなに

935 ：デフォルトの名無しさん：2011/09/01(木) 23:39:03.76

RubyとErlangをパクったProgramming Languageの略
つまりScalaの別名

936 ：デフォルトの名無しさん：2011/09/01(木) 23:41:49.76

ググッたら対話環境ってでてきた
ErlangはともかくRubyが関数型言語からぱくりまくりだから

937 ：デフォルトの名無しさん：2011/09/02(金) 07:02:03.02

パクりまくり、素晴らしいじゃないか。

938 ：デフォルトの名無しさん：2011/09/02(金) 07:37:24.25

パクるならもっとちゃんとパクってくれよ
Haskellより後発の言語なんだぞこれ

939 ：デフォルトの名無しさん：2011/09/02(金) 07:49:51.58

HaskellってJavaより古いんだぞ
別に新しい言語でも何でもない

940 ：デフォルトの名無しさん：2011/09/02(金) 07:56:06.06

haskellはやくにたたん

941 ：デフォルトの名無しさん：2011/09/02(金) 07:58:10.72

ScalaはHaskellはもちろんMLにすら到底及ばない

942 ：デフォルトの名無しさん：2011/09/02(金) 08:01:02.52

ナチュラルにMLに喧嘩売ってんな
まあHaskellerはいつもそうだけど

943 ：デフォルトの名無しさん：2011/09/02(金) 08:07:59.21

>>940
ふざけんなこのクソボケ
寝言は寝て言え
あの表記の簡潔さ、美しさ、その純粋性は現存言語の中でピカイチだろが。
いざとなれば言語の実装母体になっちゃえる実用性を備えてるのに役に立たないだと？

944 ：デフォルトの名無しさん：2011/09/02(金) 08:10:02.47

Haskell >> ML >>>>>>> Scala >>> Java

945 ：デフォルトの名無しさん：2011/09/02(金) 08:11:27.36

>>943
こいつ絶対Haskell使ってないわ

946 ：デフォルトの名無しさん：2011/09/02(金) 08:21:32.94

REPL というのは、単に対話型というだけじゃなくて、その言語における、
(loop (print (eval (read)))) という処理が走ってるものを言う。

947 ：デフォルトの名無しさん：2011/09/02(金) 09:48:24.97

皆Scalaを何に使ってる？
起動が遅いからクライアントサイドでは使い辛いんだけど
トイプログラム書いて遊んでるの？

948 ：デフォルトの名無しさん：2011/09/02(金) 12:18:44.18

>>946
> (loop (print (eval (read))))

対話型やん

949 ：デフォルトの名無しさん：2011/09/02(金) 12:22:14.07

>>947
言語仕様マニアになるのが目的だからプロダクトやツールなんてどうでもいい

950 ：デフォルトの名無しさん：2011/09/02(金) 12:34:21.66

>>948 たとえばBasicの対話環境とかは、対話環境ではあるがreplではない。

951 ：デフォルトの名無しさん：2011/09/02(金) 12:53:20.63

そんな俺定義で語られても

952 ：デフォルトの名無しさん：2011/09/02(金) 12:58:15.84

Scalaは、機能としては関数型のスタイルを取り込んではいるけど、
対象をその性質のままに記述出来るっていう、
関数型言語の思想的な部分が欠落してるように感じる。
結局OOの世界を介在して表現しなければならないから。

関数型と考えて記述しようとすると、いつもそこに不満を感じるんだよな。
なんで、関数型的なスタイルを利用しつつも、
あくまでOOの視点から考えるのが、
Scalaらしいやり方なのかな、と最近思う。
諦めがついたというか、なんというか。

953 ：デフォルトの名無しさん：2011/09/02(金) 14:03:10.56

>>861
古い話を蒸し返して悪いが、

> def foldl(collection, init)(f) = collection.foldLeft(init)(f)

これって型推論できるよね？

954 ：デフォルトの名無しさん：2011/09/02(金) 15:17:46.38

抽象論でしか語らないやつは本当にプログラミングしてるのか疑わしい

955 ：デフォルトの名無しさん：2011/09/02(金) 17:47:52.39

OCamlで考えると、

# let foldl collection init f = collection#foldLeft init f;;
val foldl : < foldLeft : 'a -> 'b -> 'c; .. > -> 'a -> 'b -> 'c = <fun>

一見、推論できているが、

class type ['a] hasfoldLeft =
object method foldLeft : 'b -> ('b -> 'a -> 'b) -> 'b end;;

class ['a] mylist (l : 'a list) =
object (self : 'a #hasfoldLeft)
method foldLeft init f = List.fold_left f init l
end;;

と定義して動かそうとするとタイプエラー

# foldl (new mylist [1;2;3]) 0 (+);;
(エラーは略)

キャストしてもタイプエラー

# (foldl :> int #hasfoldLeft -> int -> (int -> int -> int) -> int);;
(エラーは略)

956 ：デフォルトの名無しさん：2011/09/02(金) 17:49:00.62

当然最初から型を与えれば動くわけだが、

# let foldl : 'a #hasfoldLeft -> 'b -> ('b -> 'a -> 'b) -> 'b =
fun collection init f -> collection#foldLeft init f;;
val foldl : 'a #hasfoldLeft -> 'b -> ('b -> 'a -> 'b) -> 'b = <fun>
# foldl (new mylist [1;2;3]) 0 (+);;
- : int = 6

やっぱり最初の型はちゃんと推論できていないのだろう

俺が理解できてないだけなんだろうけど、
strcutural subtypingの型推論って
OCamlのせいで印象最悪なんだけど

957 ：デフォルトの名無しさん：2011/09/02(金) 17:58:48.66

>>950
MS-BASICとかは典型的なreplじゃん
不細工なだけで

958 ：デフォルトの名無しさん：2011/09/02(金) 18:01:29.21

>>956
> strcutural subtypingの型推論って

今時二者択一はない。

959 ：デフォルトの名無しさん：2011/09/02(金) 18:02:57.80

>>958
どういう意味？

960 ：デフォルトの名無しさん：2011/09/02(金) 18:10:44.10

>>935
どうせなら"Ruby to Erlang wo Pakkuta Language"にすればよかったのに。

961 ：デフォルトの名無しさん：2011/09/02(金) 18:13:57.53

>>947
sbt + REPLが便利過ぎて生きるのが辛い。

962 ：デフォルトの名無しさん：2011/09/02(金) 18:41:19.77

>>955

let foldl collection init f = collection#foldLeft init f
class type ['a, 'b] hasfoldLeft = object method foldLeft : 'b -> ('b -> 'a -> 'b) -> 'b end
class ['a, 'b] mylist (l : 'a list) =
object (self : ('a, 'b) #hasfoldLeft)
method foldLeft init f = List.fold_left f init l
end
let _ = foldl (new mylist [1; 2; 3]) 0 (+)

で動くわけだが

963 ：デフォルトの名無しさん：2011/09/02(金) 18:45:31.12

>>962
ちょっと今、手が離せないんで後で確認する
やっぱり俺が間違ってたかｗ

964 ：デフォルトの名無しさん：2011/09/03(土) 00:15:48.85

うん、動くな
しかし、この方法はポリモーフィックタイプを全部パラメタライズしなきゃいけないのか
どうなってんのかよくわからない…

OCamlをリファレンスで考えていいのかという問題もあるが
でも、strcutural subtypingで型推論ができるのって、OCamlしか知らないんだよな

まあ、前座の雑魚は黙って、水島氏の登場を待ちますか

965 ：デフォルトの名無しさん：2011/09/03(土) 00:54:16.20

OCamlを正としたほうがいいな

966 ：(1) ◆CgacaMDhSQ ：2011/09/03(土) 01:38:48.60

>>953
はい。型推論は「できます」。問題は、推論の結果が「適切な」ものか、どうかです。

まず、原理的な話を。Hindley/Milner 型推論(ML系言語の基礎となる型推論アルゴリズム。
OCamlとかHaskellとかはそれらに色々拡張が加わっているので、そのままではないですが)は、
与えられた「全ての」式に対して、最も一般的な型(principal typeと呼ばれます)を完全かつ健全に
推論できることが保証されています。この事実によって、型推論の結果の適切さを担保することが
できます。

しかし、structural subtyping(+ parametric method)が入ると、principal typeを完全かつ
健全に推論することができなくなります(というか、principal typeが存在しない、というのが正確でしょうか)。
ただ、この辺り、専門外なので、実はできる、という文献があれば示していただけるとありがたいです。
(続く)。で、OCamlは型推論をできるようにするために、メソッドは多相的になれない(単相的でなければいけない)
という制限が設けられています。

967 ：(2) ◆CgacaMDhSQ ：2011/09/03(土) 01:39:50.82

>>955
>>966
>>963
>>964

プログラマの意図した型としては、

class type ['a] hasfoldLeft =
object method foldLeft : 'b -> ('b -> 'a -> 'b) -> 'b end;;

class ['a] mylist (l : 'a list) =
object (self : 'a #hasfoldLeft)
method foldLeft init f = List.fold_left f init l
end;;

であったはずなので、おっしゃる事は正しくて、このケースでは、プログラマの意図した型をOCamlの型推論器が
適切に推論できていないように見えます。ただ、OCamlでは、メソッドが多相的になれないという制限を型システムに
設けているため(つまり、そもそもfoldLeft[A]というメソッドが作れない)、OCamlの型推論器としては正しく「型推論できて」
いることになります。

968 ：955：2011/09/03(土) 01:45:05.88

なるほど、解説ありがとうございます
OCamlの型システムについて勉強不足でした

969 ：(3) ◆CgacaMDhSQ ：2011/09/03(土) 01:47:27.81

>>962
はい。それで動きます。しかし、それでは、「foldLeftが」型パラメータを一つ持つ多相的なメソッドになっていませんよね。
これは無理も無くて、先ほど書いたように、OCamlでは、メソッドは多相的になれないという制限が設けられているからです(これは、
まさに型推論の問題を回避するためにそうなっています)。ともあれ、Scala的に書くと、

type HasFoldLeft[A] = {
def foldLeft[B](init: B)(f: (B, A) => B): B
}

という(これは、引数の位置に型エイリアスの型パラメータAが出てきているので、正しいScalaプログラムではありませんが)型は
推論できていないわけです。

とりあえず、説明が十分ではないかと思いますが、OCamlでは、Scalaのように多相的なメソッドがそもそも書けないので、この場合の
比較対象として持ってくるのは適切ではないです。

970 ：(4) ◆CgacaMDhSQ ：2011/09/03(土) 01:51:51.91

この辺のスレッド
http://caml.inria.fr/pub/ml-archives/caml-list/2008/01/08787d6fa804461e8db9e3ccfece5ee7.en.html
が参考になるかと思います。ちなみに、Jacques Garrigue先生はOCamlのコア開発者です。ただ、その
スレッドで出てくるJon Harropという人は色々な意味で悪名高いので、あまり信用しない方がいいですが。

971 ：(4) ◆CgacaMDhSQ ：2011/09/03(土) 02:26:10.11

ちょっと補足。メソッドが多相的になれない、というのは、型注釈を書かない場合の制限で、型注釈を明示的に付ければ
メソッドを多相的にすることができます。例としては、

# class ['a] newlist(src : 'a list) =
object
method foldLeft : 'b. ('b -> 'a -> 'b) -> 'b -> 'b = fun f a -> List.fold
_left f a src
end;;
class ['a] newlist :
'a list -> object method foldLeft : ('b -> 'a -> 'b) -> 'b -> 'b end
# (new newlist [1; 2; 3]);;
- : int newlist = <obj>
# (new newlist [1; 2; 3])#foldLeft (fun b a -> b + a) 0;;
- : int = 6

な感じになります。しかし、これだと、型注釈を書かない場合に推論される型と一致しないため、実質的にあまり使われる事は無いと思います
(OCamlに関しては素人なので、実はよく使われる、という事もありえなくもないですが)。

972 ：デフォルトの名無しさん：2011/09/03(土) 03:24:35.08

Scalaとは、
JVM界のC++であり、
関数型言語界のPHPである。

973 ：デフォルトの名無しさん：2011/09/03(土) 03:32:44.39

PHP大好きっす

974 ：デフォルトの名無しさん：2011/09/03(土) 03:33:30.31

C++は自分が書くのでなければ大好き

975 ：デフォルトの名無しさん：2011/09/03(土) 04:00:59.91

REPL上で、:historyと入力すると、履歴一覧が番号と共に出力されますが、
この番号を指定して実行することはできるのでしょうか？

http://labo.patentbureau.co.jp/blog/?p=291では、
> さらに履歴番号を入力することで、コマンドを再実行できます。
> scala>:history 499
とありましたが、これは履歴を499件出力するというもので
間違いのようです。

976 ： ◆CgacaMDhSQ ：2011/09/03(土) 08:09:46.87

>>975
ちょっと確認のため、REPLで使えるコマンド(powerモード含む)調べてみましたが、
それに該当する機能はちょっと無いですね…。シェルの!<num> みたいなのがやりたい
事だと思うのですが、残念ながら現段階では無理、ということですね。
ただ、:replayが出来ているくらいなので、実現が難しい、ということは無いはずです。
あとは、sbtコンソールにはそういうヒストリ実行機能がありますが、sbtコンソールそれ
自体はREPLじゃないですし…。

977 ：デフォルトの名無しさん：2011/09/03(土) 09:29:45.20

>>967

>>955のクラス定義は（本人の意図はどうあれ）foldLeftが多相メソッドになってしまってる一方で、
foldlの引数には型注釈が無い（無い場合は多相メソッドにならない）のがfoldlが通らない理由
だから、

let foldl (collection: 'a #hasfoldLeft) init f = collection#foldLeft init f

のように定義してやると>>955は通るし、また

class ['a] mylist2 (l : 'a list) =
object
method foldLeft : 'b. 'b -> ('b -> 'a -> 'b) -> 'b = fun init f -> List.fold_left f init l
end

と直接的に多相メソッドを定義した場合も通る（>>955のmylistとmylist2は同じ定義になる）

978 ：977：2011/09/03(土) 09:44:35.12

なお、>>955の本当に意図した型は

class ['a] mylist (l : 'a list) =
object
  method foldLeft init f = List.fold_left f init l
end

だと思うが、これはクラス定義の制限（より正確にはOCamlのlet多相性の制限）によって通らない
なので>>962のように定義してやる必要がある（そのかわりfoldLeftは多相的にならない）
一方で、こういったOCamlの型推論の制限に引っかからないように
オブジェクトを直接定義してやると多相的なfoldLeftを持つオブジェクトが得られる

let foldl collection init f = collection#foldLeft init f
let obj = object
  val lst = [1; 2; 3]
  method foldLeft init f = List.fold_left f init lst
end
let _ = foldl obj 0 (+)
let _ = foldl obj "0" (fun x y -> x ^ string_of_int y)

ま、何にしろOCamlの型推論は慣れるまで難しいな

979 ：デフォルトの名無しさん：2011/09/03(土) 09:59:53.03

>>971
> な感じになります。しかし、これだと、型注釈を書かない場合に推論される型と一致しないため、実質的にあまり使われる事は無いと思います

実質的には、OCamlではオブジェクト自体あまり使わないな
モジュールとファンクタで良いじゃん、みたいな

980 ：デフォルトの名無しさん：2011/09/03(土) 10:00:40.48

Scalaって型推論しかできない？

981 ： ◆CgacaMDhSQ ：2011/09/03(土) 12:19:40.56

>>978
なるほど。ありがとうございます。生兵法は怪我の元というかなんというか。そういう風にすることで、型注釈無しに
多相的なfoldLeftを持つオブジェクトを作れる事は知りませんでした。勉強になります。ありがとうございます。ただ、

let foldl collection?init?f?=?collection#foldLeft init f
let obj = object
val lst = [1; 2; 3]
method foldLeft init f = List.fold_left f init lst
end

で得られるfoldLeftの型は

'_a -> ('_a -> int -> '_a) -> '_a

であって、確かにfoldLeft自体は多相的になっているのですが、反対にobjectをそのまま使っているせいで、単相的になってしまっていて、退化している
ような…。

>>979

>>実質的には、OCamlではオブジェクト自体あまり使わないな
>>モジュールとファンクタで良いじゃん、みたいな

それはOCamlな方々からよく聞きます。

982 ：デフォルトの名無しさん：2011/09/03(土) 19:59:32.22

ケーミズが怖い人を脱却しようとしてるｗｗ

うざいって言っちゃうといろいろアレだから、オブラートに包んで「怖い」って
表現してるわけだけど、本人は気づいちゃいないのねｗ

983 ： ◆CgacaMDhSQ ：2011/09/03(土) 20:32:29.30

>>982

なるほど。「怖い」は「うざい」のオブラートにくるんだ表現だったわけですね。自分は色々
空気読めない人なので、その辺り気づかなかったです。そういう直球の指摘をいただけるのはありがたいです。

984 ：デフォルトの名無しさん：2011/09/03(土) 20:42:09.51

scalaで開発するときには

scala XXX

という形でプログラムを何度も実行すると思うんだけど、そのたびに数秒またされる。
たぶんVMを起動してクラスライブラリを読み込む時間なのだと思うけど、これ省略できないのかな？
つまり、コンパイル時のfscに相当するものが欲しいのだけど…

985 ：デフォルトの名無しさん：2011/09/03(土) 21:00:53.25

sbtのrunは別プロセスだっけ？ちょっとは速くなるんじゃないかな？

986 ：デフォルトの名無しさん：2011/09/03(土) 21:29:09.49

sbt で ~run とか ~test とかしとけばファイル変更を監視して実行してくれるがどうかな

987 ：デフォルトの名無しさん：2011/09/04(日) 11:03:28.40

これからの時代ScalaよりもGroovyなわけですが

988 ：デフォルトの名無しさん：2011/09/04(日) 11:51:45.90

OOPとFPとJVMとの狭間でキモイ言語仕様になったScalaは
Groovyから呼び出す価値も無い

989 ：デフォルトの名無しさん：2011/09/04(日) 12:02:45.39

JVM言語の求人トレンド
http://www.indeed.com/jobtrends?q=jython%2Cjruby%2Cgroovy%2Cscala%2Cclojure&l=

990 ：デフォルトの名無しさん：2011/09/04(日) 12:06:19.74

んなこと言っても、haskell/JVMは実用化で難航してるがな

991 ：デフォルトの名無しさん：2011/09/04(日) 13:28:43.01

JavaコンパイラよりもCコンパイラの可搬性が高い現状で、わざわざJVMコードにコンパイルすることのメリットってなんだろ…

992 ：デフォルトの名無しさん：2011/09/04(日) 13:34:40.49

Write Once, Run Anywhere()
でしょ

>>990
そうなんけ？

993 ：デフォルトの名無しさん：2011/09/04(日) 13:36:22.45

GCをJVMに丸投げできるのは魅力

994 ：デフォルトの名無しさん：2011/09/04(日) 15:02:33.41

Oracleに買収されてJVMの魅力にも翳りが……。

995 ：デフォルトの名無しさん：2011/09/04(日) 15:08:03.01

しかしJVMに代わるものなんて・・・

ところで次スレ誰かよろ。私はムリでした

996 ：デフォルトの名無しさん：2011/09/04(日) 17:21:47.47

>>981
確かに指摘の通り、obj#foldLeftは多相ではない
obj#foldLeftとobjの型を見比べてみると

# obj#foldLeft;;
- : '_a -> ('_a -> int -> '_a) -> '_a = <fun>
# obj;;
- : < foldLeft : 'a -> ('a -> int -> 'a) -> 'a > = <obj>

となっていて、これがfoldLeft自体は多相メソッドではないのに
objが多相的に振る舞える理由になってる
退化といえばその通りだが、この性質のおかげで型注釈無しのfoldlに渡せるわけだ

ま、正直言って複雑だよな
巷ではScalaが複雑だと噂らしいけど、OCamlの型推論も闇を抱えてるってことだな

997 ：デフォルトの名無しさん：2011/09/04(日) 17:33:50.57

>>993
全部丸投げだとcons多用する言語はきついけどね。

998 ：デフォルトの名無しさん：2011/09/04(日) 18:58:52.72

ここってOCamlのスレですか？
次スレいらないですか？

999 ：デフォルトの名無しさん：2011/09/04(日) 19:19:37.91

Haskellへの嫉妬が凄い言語ですね

1000 ：デフォルトの名無しさん：2011/09/04(日) 19:37:00.68

1000ならHaskellerが死滅してScalaが関数型の王者になる！！

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。