11/09/28 20:01:24.54
PEPLとREPL(p703)って別物？誤植なのかな？
251:デフォルトの名無しさん
11/09/29 04:37:46.16
つーか2.9.1の話まで載ってんのか
ギリギリまで書いてたんだな
252:デフォルトの名無しさん
11/09/29 12:36:51.07
ミズシマさんﾊﾟﾈｯｽ
253:デフォルトの名無しさん
11/09/29 12:44:57.28
だが、正直キモい。
254:デフォルトの名無しさん
11/09/29 13:01:46.68
キモカッコイイ
255: ◆CgacaMDhSQ
11/09/29 23:28:25.23
>>249
申し訳ありません。それは誤植です。「バイナリ互換であることを目標」が正しいです。そう読めば意味
が通るようになっています。Twitterで既に何名かの方に指摘を受けているので、正誤表に載せていただくようにします。
>>250
一瞬何のことだかわからなかったのですが、p.703のリスト99.1ですか。これも誤植ですね。
同じく、正誤表に載せていただくことにします。ご指摘ありがとうございます。
>>251
それほどギリギリ、というわけではないのですが、大体書籍が出版される頃には2.9.1が
出てるだろう、という目測が立つくらいの時期ではありますね。ちなみに、誤解されると
申し訳ないので言っておくと、2.9.1 finalそのものの改善点(REPL高速化など)については
載っていません。記事自体もページ数の制約もあり、あくまで2.9新機能の概要なので、
おまけ程度に思っていただければ。
>>253
明らかに誰かわかる形でコテハンやってる時点で既にキモい奴だなあと自分で思います。
256:デフォルトの名無しさん
11/09/30 00:49:34.44
このスレ初めてなのですが、◆CgacaMDhSQさんは、Scalaの本の著者なんですか？
257:デフォルトの名無しさん
11/09/30 01:57:36.50
>>256
mizushima kagerou
でググれ
258:デフォルトの名無しさん
11/09/30 09:25:22.88
Scalaエヴァがんばってください
うごいてよ！今動かなきゃ(ry
259:デフォルトの名無しさん
11/09/30 12:04:00.70
Scales Xml 0.2
Performance, Flexibility and Correctness Improvement
URLﾘﾝｸ(implicit.ly)
ライブラリー実装:
ミュータブルのが速いし省メモリだよ派
遅延評価寸止め革命中の今がのし上がるチャンスだよ派
260:デフォルトの名無しさん
11/10/01 04:39:38.26
とうとう みずしまはんも カリスマ性を帯びてきたか。
261: ◆CgacaMDhSQ
11/10/01 12:51:24.88
>>259
そっちも気になってたんですけど、@djspiewak の
Anti-XML URLﾘﾝｸ(github.com)
も標準のXMLライブラリよりフットプリントが軽くて、
かつimmutableなのをウリにしてるんですよね。ちょっと
ベンチマーク取ってみたいところですね。
262:デフォルトの名無しさん
11/10/02 00:45:21.37
akka1.1のデータフローAPIに登場するFuture/Promiseって、
javaのFuture/Promiseと別物？
Scalaの限定継続プラグインを使っているみたいだし。
URLﾘﾝｸ(akka.io)
263:デフォルトの名無しさん
11/10/02 01:09:08.63
>>261
なるほどっすな。
Scala2.8の登場で、XMLをもっとうまく実装できる環境が整ったんでしょうね。
そして、これは有望なWebフレームワーク？
BlueEyes
URLﾘﾝｸ(github.com)
A lightweight Web 3.0 framework for Scala, featuring a purely asynchronous architecture, extremely high-performance, massive scalability, high usability, and a functional, composable design.
Sinatraクローン（Scalatra）をネタに上を目指すとか。MVCならLift使えとか。
264:デフォルトの名無しさん
11/10/02 08:20:30.82
ms単位の差が問題になるパーサを作っているのですが、
scalaで高速なパーサを作る定番はあるのでしょうか？
パーサコンビネータライブラリしかないのかなあ。
265: ◆CgacaMDhSQ
11/10/02 09:39:18.38
>>264
Scalaのパーサコンビネータライブラリは、速度が重要になるパーザを書く用途には
本質的に向いていません(これはコップ本にも書かれていますが、Scalaのパーザコンビネータライブラリの
実装によるところが大きいです)。
速度的に、それよりもっと良いものとして、@djspiewak の GLL Combinators
URLﾘﾝｸ(github.com)
というのがあります。これもパーザコンビネータですが、Scala標準のものより速度が出るように
設計されています(特に、LL(k)文法に収まる場合)。
もっと速度を追求したい場合は、既存のJava用パーザジェネレータを使うという手もあります。いくつか
注意すべき点はありますが、基本的にScalaから問題なく使えます。ANTLR辺りが個人的にお勧めですが、
この辺は(必要に応じて)どれ選んでも良いと思います。性能がかなり重要とのことなので、実際にいくつかの
パーザジェネレータで簡単なベンチマーク取ってみるのが良いかと。
最後に手書きの場合ですが、Scalaで手書きパーザで速度出したい、となると、どうしてもある程度手続き的なコード
書く必要があって、その場合、本質的にJavaとあまり変わらないコードになります(型推論とかで多少楽はできますが)。
266: ◆CgacaMDhSQ
11/10/02 09:55:52.85
>>262
概念的にはjava.util.concurrent.FutureとAkkaのFutureは類似のものですが、
AkkaのFutureはモナドなので、他のFutureから簡単にFutureを合成できたりと、
機能がよりリッチなものになっています。で、Promiseですが、これは
java.util.concurrentには無いもので、データフロー変数と呼ばれるものを作成
して、後からそこにFuture型の値をくくりつけることができるようになっています。
267:デフォルトの名無しさん
11/10/02 10:27:30.17
>>265
ありがとうございます。
やはり標準のパーサコンビネータは向いてないようですね。
GLL（GLRのLL版？）をまずは試してみます。
268:デフォルトの名無しさん
11/10/03 18:06:33.04
scala実践プログラミングを母校の図書館で借りたんだけどあまり人気ないみたいね
269:デフォルトの名無しさん
11/10/03 19:17:15.84
>>268
尾崎のクオリティが低いばかりに…申し訳ありません…
270:デフォルトの名無しさん
11/10/03 20:51:21.89
そろそろ名誉毀損とか、そういう言葉を持ち出した方がいいのか。
271:デフォルトの名無しさん
11/10/03 21:07:28.17
ループの外側でリストを生成して、直下のループのなかでTuple2オブジェクトを生成して、そのリストに追加して行く。(ループ回数は不定)
このコードってどう書くの？
リストにタプルを追加しようとするとtype mismatch になっちゃう。
272:デフォルトの名無しさん
11/10/03 21:17:56.37
>>269-270
コンセンサスがとれているならともかく、まあ確かに、具体的にクオリティの低い箇所を
具体的に指摘すべきだよな。
273:デフォルトの名無しさん
11/10/03 21:24:36.06
本人の自虐だと思った
274:デフォルトの名無しさん
11/10/03 21:44:06.13
>>271
Scala歴二日のHaskellプログラマが書いてみました
意図どおりですかね？
たぶんエラーになったコードを貼ったほうが思い違いが少なくてよいと思います
var l : List[(Int,Int)] = List()
for (i <- List(1,2,3)) {
l ::= (i, i + 1)
}
println(l)
Scalaキモいなあが二日間いじった感想です
subtypeキモいです
これからこのスレでお世話になろうと思います
よろしくおねがいします
275:デフォルトの名無しさん
11/10/03 22:00:00.46
>>271
タプルを囲むカッコを書いたつもりで、実は引数のカッコを書いていた、
というのがありがちだから、とりあえずタプルのカッコを更にカッコで包んでみるんだ。
276:デフォルトの名無しさん
11/10/03 23:19:34.11
>>274 >> 275
ありがとう！
どうやらListの宣言の時点で間違っていた（理解していなかった）みたい。
object GetOptions {
def main( args:Array[String] ){
var list:List[(String,String)] = List()
for ( i <- 1 to 10 ) {
//list =:: "a"+i -> i.toString()
list = list ::: List("a" + i -> i.toString())
}
println (list)
}
}
普段仕事でJavaとPHPしか触らなくて、まったくScalaの勉強が進まなかったから、とりあえずPerlのGetOptions
みたいなものでも作ってみようと思っていきなり躓いてた。
277:デフォルトの名無しさん
11/10/03 23:41:17.15
>>276
ListBuffer使えばいいと思うよ
object GetOptions {
def main(args: Array[String]) {
val buf = new scala.collection.mutable.ListBuffer[(String, String)]
for (i <- 1 to 10) {
buf += "a" + i -> i.toString
}
println(buf.result)
}
}
278:デフォルトの名無しさん
11/10/04 15:29:50.69
>>276
(1 to 10).map(i => "a" + i -> i.toString)
または
for(i <- 1 to 10) yield i => "a" + i -> i.toString
どうしてもリストが良ければ、最後で
toList
でどうでしょうか
279:デフォルトの名無しさん
11/10/05 09:32:38.59
Scala 2.9.1 ＆ Akka 1.2 のお手軽インストーラ
「Typesafe Stack 1.1」がリリースしてるよぉ
URLﾘﾝｸ(typesafe.com)
こっそり同僚のPCにインストールするのに便利！
280:デフォルトの名無しさん
11/10/05 09:53:37.98
Finagleはまだscala2.8.1だし食い合わせのいいakkaにしようかな
281:デフォルトの名無しさん
11/10/05 20:35:54.05
>>280
何を作る気なんだ？
282:デフォルトの名無しさん
11/10/05 23:31:18.43
>>278
元々の質問読んだら？
283:デフォルトの名無しさん
11/10/06 08:22:43.96
akkaり～ん!
284:デフォルトの名無しさん
11/10/06 18:19:49.24
アニオタきめえ
285:デフォルトの名無しさん
11/10/06 18:34:14.33
日本のScalaユーザの大半はアニオタだろ。お前も含めて。
286:デフォルトの名無しさん
11/10/06 18:53:13.75
Haskellほどではないな
287:デフォルトの名無しさん
11/10/06 19:48:54.71
Haskellやったらかわいい彼女やかっこいい彼氏が出来るらしいけど、
Scalaやったところでモヒカンになれる気しかしねぇぜ！
288:デフォルトの名無しさん
11/10/07 00:10:20.65
酢辛って感じ
289:デフォルトの名無しさん
11/10/07 13:03:21.77
やっぱさー
文系馬鹿がScala使ったところで、ベタージャバにしかならないね
文系にはオブジェクト指向
290:デフォルトの名無しさん
11/10/07 13:19:39.52
文系くん、ベターな日本語で頼む
291:デフォルトの名無しさん
11/10/07 13:31:23.34
どうしたのおっさん？年下の上司にScala却下されたの？
292:デフォルトの名無しさん
11/10/07 20:20:05.30
ベターなJavaでも、全然OKだと思う、、。
だが、問題は、Java自体が人気下降気味なこと。
Android関連で、また、盛り返してくれればうれしいけど。
Javaは、GUIとかがイマイチ垢抜けないよね。
SwingXとかでサクサク作れる開発環境があると良いのだが。
293:デフォルトの名無しさん
11/10/07 22:47:55.67
Javaはオワコンだろう
294:デフォルトの名無しさん
11/10/07 23:00:40.02
AndroidのJavaはOracleに訴えられちゃったからね……
295:デフォルトの名無しさん
11/10/08 01:13:37.51
Java言語とJVMは分けて考えろよおめーら
296:デフォルトの名無しさん
11/10/08 01:23:29.47
jvmのjava離れ
297:デフォルトの名無しさん
11/10/08 02:00:11.94
jvmってジャヴァで実装されてるんですか？
298:デフォルトの名無しさん
11/10/08 02:32:55.07
Squawk VMの話？
299:デフォルトの名無しさん
11/10/09 06:31:46.58
「すっからかん」に「あっかん」やろ？関西弁にしたらすからはあかん
のや
300:デフォルトの名無しさん
11/10/09 11:49:29.38
>>299
つまんねえんだよクズ
これだから土人は…
301:デフォルトの名無しさん
11/10/09 21:37:20.95
>>300
頭がすっからかんなのね。気の毒に。
302:デフォルトの名無しさん
11/10/09 21:47:38.71
荒らしはスルーでお願いします
303:デフォルトの名無しさん
11/10/10 20:18:15.70
普及率を考えるとWebはPHP >> java >> rubyの順でずっと席巻してそうだな。
scalaはベターC++を目指したD言語と同じ末路確定
304:デフォルトの名無しさん
11/10/10 21:36:34.72
ちょっと何言ってるかわかりませんね
305:デフォルトの名無しさん
11/10/10 23:40:58.62
Facelets/JSF2.xみたいなのがScalaで書けたらなぁ…。
306:デフォルトの名無しさん
11/10/10 23:42:46.37
Scalaの日本語wikipediaの記事を見るたびに、いたたまれないというか、悲しい気持ちになる。
307:デフォルトの名無しさん
11/10/11 01:46:27.81
>>303
言語仕様に優れ、C言語と連携もばっちりのD言語は
かつてベターC++と一部で騒がれたが、結局は普及率せず風前の灯し火
scalaの立場と似ているだろ
そして言語仕様の酷いPHPが普及率で君臨し続ける
308:デフォルトの名無しさん
11/10/11 02:36:23.39
>>307
別に国内での普及率なんてどうでもいいなぁ
俺はScalaが気に入ってるから使うけど、JavaやPHPが好きな人はそれを使い続けてればいいと思うよ
309:デフォルトの名無しさん
11/10/11 03:22:06.62
D言語はともかく、信頼できる体制でメンテされる言語なら仕事でも使いたいじゃん
だから普及してくれないと困る
310:デフォルトの名無しさん
11/10/11 03:31:28.22
>>309
同意。
とりあえず一度普及してくれれば、その後もメンテされ続けるからなあ。
311:デフォルトの名無しさん
11/10/11 06:45:00.66
>>303 >>307
しかし何故に比較対象がPHP…？？
C言語とかも出てくるし、どういう分野での話をしてるのだ？
312: ◆CgacaMDhSQ
11/10/11 07:27:25.50
国内はともかく、海外では、著名なサービス(Twitter, LinkedIn)を提供している会社が何社も使っていますし、
著名じゃない所でもScalaを採用している会社が増えています。Typesafe社という形でサポートビジネス等を
立ち上げたからには、それらの会社が軒並みScalaを破棄するという事にならなければ、当分はメンテされるでしょう。
Typesafeがどれだけ儲かってるかはわかりませんが、主要メンバって結局はEPFLのScalaチームなので、Typesafe
が儲からなくてもメンテナンス自体は継続可能な状態ですし。
あと、互換性の問題を無視して言語仕様を拡張しようとしても、公式MLで文句言う「仕事でScala使ってるユーザ
(海外)」がそれなりに居ますし今後しばらくは「破壊的な」言語仕様の変更は起こらないと思います。
313:デフォルトの名無しさん
11/10/11 07:37:09.81
JVM依存が無くなってくれれば……
314:デフォルトの名無しさん
11/10/12 06:59:33.93
URLﾘﾝｸ(www.youtube.com)
小田好先生ってこんなイケメンだったんだな
315: ◆CgacaMDhSQ
11/10/12 07:50:00.29
>>314
Odersky先生に会った個人的な印象としては、ナイスミドル、という感じでしたね。なんか顔つきがあまり泥臭くない
というかw あと、結構情熱家だなあ、とも。
316:デフォルトの名無しさん
11/10/12 21:31:21.43
>>313
使う人がいなくなる。
317:デフォルトの名無しさん
11/10/12 21:38:54.52
.NET移植が順調に進んで、進みすぎて本家追い越すくらいになればあるいは
でもあれIKVMだったっけ？
318:デフォルトの名無しさん
11/10/13 00:44:34.76
コンパイルターゲットがJVMなのは、各種のJVM資産が使えるというメリットもある一方で、
環境が限られるというデメリットもあるよねえ。
、
まあ、OpenJDKとかもあるから、JVMがなくなることはないと思うのだけど、、。
あと、JavaならGWTで JavaScriptに変換できるけど、
Scalaではそういうのないの？？
319:デフォルトの名無しさん
11/10/13 01:39:52.57
The Scala Compiler Corner, for .NET and Mono fans: A collection of resources for compiler hackers focusing on the MSIL backend of the Scala compiler
URLﾘﾝｸ(lamp.epfl.ch)
jdk2ikvm: A source-level conversion tool to migrate Scala programs from JDK to .NET
URLﾘﾝｸ(lamp.epfl.ch)
ikvmを使ってconvertするみたいだけど、よくわからん
320: ◆CgacaMDhSQ
11/10/13 02:29:37.92
>>318
＞あと、JavaならGWTで JavaScriptに変換できるけど、
＞Scalaではそういうのないの？？
あるよ。
URLﾘﾝｸ(scalagwt.github.com)
まだ正式リリースは無いが、GWTのJavaで書かれたデモ(に相当するScalaコード)ほとんどがコンパイル/動作できるくらいには進展してる
らしい。
321:デフォルトの名無しさん
11/10/13 02:58:37.26
s2jsというコンパイラプラグインもあるが、俺の所で動いたためしがないな。
322:デフォルトの名無しさん
11/10/13 09:03:52.31
JVM抜きでは衰退するというのは、ScalaってJava使いから来てる人
が圧倒的に多いようだからだよ。逆に言えば、Java使いから魅力が
あっても、それ以外からは魅力がない言語ということを暗に意味してる。
C＃なんかも.NETじゃなかったら普及してないだろう？それと同じ。
323:デフォルトの名無しさん
11/10/13 13:50:46.17
今のところJVMの問題よりJava文化の恩恵を受けているほうが遥かに大きいだろ
324:デフォルトの名無しさん
11/10/13 21:24:51.51
今更だが、並列コレクションを使ってみた。
確かに全CPUを使いきってくれる。
手軽だね。
ただ、共有データを操作する際にロックは必要だと思うけど、見当たらない。
これはJavaのロック機能を使えということなのかな。
325:デフォルトの名無しさん
11/10/14 01:43:53.25
Javaの経験のある初心者です。scalaすごくいいですよね。Javaで面倒くさいと思った部分（ex new）をいろいろ楽にしてくれているし。
これが広まらずに終わるのって正直やだなと思います。
scalaが信用され利用できる範囲が広がる事を祈ってます。
326: ◆CgacaMDhSQ
11/10/14 06:16:14.73
>>324
まず、並列コレクションでは、明示的なロック操作を行う事は基本的には想定されていません。
並列コレクションのモデルは、いわゆる「暗黙的な」並列化という奴で、不変コレクションを使って
いて、共有データを高階関数内で書き換えなければ、処理が並列化されている事は、プログラマ
から「見えない」というものです。ですから、そもそも並列コレクション専用のロックメカニズムは
用意されていません。Javaのsynchronizedを使うことはできますが、基本的にそれはやらない方
が賢明です。
ロックを使う必要がある場合には、ロックを使わないでいい形に、並列コレクションを使った処理にうまく
変換するか、Actorなどの「明示的な」並行処理を提供するライブラリを利用するべきです。
327:デフォルトの名無しさん
11/10/14 16:25:08.38
プログラミング初心者なんですが、コップ本とSICPはどちらがためになりますか
328:デフォルトの名無しさん
11/10/14 16:32:58.51
その前置きが必要な質問か
329:デフォルトの名無しさん
11/10/14 16:33:05.20
高校生でお金がないので、どちらか一冊を読み込もうと思っています
330:デフォルトの名無しさん
11/10/14 17:29:39.85
そりゃSICPのほうが役に立つだろうが、通読するのはなかなかきつい
特に日本語版
331:デフォルトの名無しさん
11/10/14 17:47:37.27
図書館か図書室の司書に言って買ってもらえや
332:デフォルトの名無しさん
11/10/14 17:52:17.71
SICPなら工学部がある大学の図書館に行けばあるかもね。
そこの学生じゃなくても入館はできるよね？
333:デフォルトの名無しさん
11/10/14 19:21:44.98
最近のデジタルネイティブのネイティブっぷりはほんと驚異だなぁ。
334:デフォルトの名無しさん
11/10/14 22:06:01.77
SICPはプログラミング(もっというとコンピューターサイエンス)を
学ぶための手段としてSchemeを使う本で、コップ本はScalaを学ぶための本。
だいぶ毛色が違うんで目指してる方向が逆ならそれぞれ役に立たない。
それから、ほんとにまったくプログラムしたことない状態なら
コップ本一冊だけでやるのはかなりきつい
335:デフォルトの名無しさん
11/10/14 22:24:07.93
任意の関数を受け取って、その関数をラップした同じ引数の新しい関数を返す関数ってタイプセーフに書けますか？
336:デフォルトの名無しさん
11/10/14 23:25:37.56
>>335
任意の関数を受け取る時点で無理じゃない？
def wrap[T,R](f: Function1[T,R]) = (t: T) => {
println("wrapped")
f(t)
}
こんな感じでFunction0からFunction22用まで定義するとか
337:デフォルトの名無しさん
11/10/14 23:37:43.34
ちょっと違っちゃうがwrap呼ぶ前にtupled呼んで1つのタプルを引数に取る関数に変換すれば
338:デフォルトの名無しさん
11/10/15 00:31:43.64
tupleですか。ありがとうございます。
一応やりたい事のサンプルみたいなのをpythonで書いておきます。
型のない言語だと可変長引数でなんとでもなるのですが、
タイプセーフにできないものかと思いまして。
...def wrap(func):
... def cls(*args, **kwargs):
... brfore()
... try:
... return func(*args, **kwsrgs)
... finally:
... after()
... return cls
こういう感じでラップ前と同じ引数で呼び出せば
実行前になんらかの処理を実行してくれて、
かつ呼び出す側はラップされてるかどうかを
意識する必要がないという状態にしたいです。
できなければいくつか引数の違う関数を作る方法で妥協するのが一番かなと思ってます。
339:デフォルトの名無しさん
11/10/15 00:33:25.37
Scalaで書いてから質問しろよｗ
340:デフォルトの名無しさん
11/10/15 00:50:17.65
俺よくこういうコードを書くんだがもしかしてこんなので代用できねーか？
def wrap[A](block: => A): A = {
before()
try {
block
} finally {
after()
}
}
wrapに渡すときに引数も一緒に渡す
wrap(hoge(a,b))
やりたいことと違ったらゴメンだが
341:デフォルトの名無しさん
11/10/15 00:50:47.56
詳細がわからないから何とも言えないけど、
どうも発想の筋が悪いというか、関数型っぽくないというか
342:デフォルトの名無しさん
11/10/15 03:11:52.66
>>341
関数型ではデコレーターとかあまり使わないのでしょうか？
代わりにどのような方法で代用するのでしょうか？
ログ出力とか楽なのになぁ。
343:デフォルトの名無しさん
11/10/15 08:30:28.80
普通の関数型言語は、1引数関数しかないので何の問題もない。
残念ながらscalaはJavaとあわせるという制約があって、そうなっていないので
ちょっとぎこちなくなるね。
344:デフォルトの名無しさん
11/10/15 14:47:24.92
>>330-334
レスありがとうございます
JavaとJavaScriptは少しだけ書けます
JavaもJavaScriptのように自由に関数を扱えればいいのにと思っていたところ
Scalaを知って大変興味を持ちました
SICPは翻訳も内容も難しいとのことですが、挑戦してみよぅと思います
Scalaプログラマの皆さん、ありがとうございました
345:デフォルトの名無しさん
11/10/15 16:36:35.35
>>344
SICPは何年かかっても読む価値のある本だ
問題も解けよ。感動がある
分厚いので挫折しそうになるが、なんとか二章までがんばれ
偉そうなこと言えるレベルになるぞ
346:デフォルトの名無しさん
11/10/15 16:57:13.27
SICPは前半は抽象化の話で
後半はmeta circular
重要だけどちょっと毛色が違う
347:デフォルトの名無しさん
11/10/15 17:08:53.26
>>343
なるほど！
1引数の関数しかないってことですか。
じゃあ関数をカリー化する関数を作れば
なんとかなりそうな気がしてきました。
ありがとうございます。
def wrap[T, U](func: T => U): T => U = {
val r: T => U = {...}
r
}
こんな感じ？
348:デフォルトの名無しさん
11/10/15 21:56:40.01
scalaからJavaで書いたクラスのメソッドを呼び出すとき、
そのメソッドと同名のフィールドがあると呼び出せません。
public class A {
private int m;
public int m() { return 0; }
}
--- scala
def f(A a) {
a.m() <-- エラー
}
scalaではメソッドとフィールドの名前空間が同じためかと思うのですが
回避策はあるのでしょうか？
349:デフォルトの名無しさん
11/10/18 00:38:14.38
ここよりいい解説知りませんか？
URLﾘﾝｸ(twitter.github.com)
350:デフォルトの名無しさん
11/10/18 00:41:04.56
こっちだった
URLﾘﾝｸ(apocalisp.wordpress.com)
URLﾘﾝｸ(www.codecommit.com)
351:デフォルトの名無しさん
11/10/18 01:30:20.95
>>350
URLﾘﾝｸ(dl.dropbox.com)
これを貼れというステマですか？
352:デフォルトの名無しさん
11/10/21 13:59:25.96
Scala IDE for Eclipse入れてjavaのプロジェクト触ってるとよくScalaのライブラリを
ビルドパスに追加するか聞かれてうざったいんだけど、これ消せない？
353:デフォルトの名無しさん
11/10/22 08:43:48.90
>>327
SICPを読むくらいならHaskell勉強した方が学びやすいし、ためにもなると思うよ。
基礎的な勉強がしたいならTAPLの方がオススメ URLﾘﾝｸ(www.cis.upenn.edu)
354:デフォルトの名無しさん
11/10/22 10:35:57.23
ITProで新しいScalaの連載始まったね。けっこうわかりやすい。
「Scalaプログラミングに欠かせない機能---Scalaの基本4」
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
355:デフォルトの名無しさん
11/10/22 12:21:48.24
始まったね、とかいいつつ最終回の記事を紹介するとは
356:デフォルトの名無しさん
11/10/22 13:04:35.67
>>355 あれ、これって4回で終わりなの？もっと連載してほしいのに。
357:デフォルトの名無しさん
11/10/22 14:00:01.44
>>356
連載っていうか、もともとは月刊雑誌の一回だけの特集を、Webに乗せただけ。
日経ソフトウェアの2011年6月号 pp.78-79 が、
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
変数とクラスを学ぶ---Scalaの基本1
同じく pp.85-87が
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
Scalaプログラミングに欠かせない機能---Scalaの基本4
だから、最初から これで完結だよ。
358:デフォルトの名無しさん
11/10/24 00:33:03.64
HaskellもOCamlも、定義したヴァリアントはデータ型の内部構造を
直接さらしてしまう、という欠点を持っているけど
Scalaではケースクラスにしつつ内部表現を隠蔽することも簡単にできるらしい
これってどういうこと？
359:デフォルトの名無しさん
11/10/24 08:36:24.45
プライベートなメソッドを持てるかどうかって事？
なんかOCamlとかでもできそう。
360:デフォルトの名無しさん
11/10/24 10:03:50.82
Haskellならデータ構築子をモジュール外に公開しないことで可能
内部と外部の境界がモジュールなので、クラスとかに比べたら少し大きい
361:デフォルトの名無しさん
11/10/24 17:22:44.52
発想の基本がOOPの言語と発想の基本が関数型では違ってくるよ。
ありがたがってる土俵が関数型のプログラミングではあまりありがたみが
ないというのはよく有りそうだよ。
362:デフォルトの名無しさん
11/10/24 17:53:53.25
関数型言語ではそもそもアクセスされて困るプロパティが作れないからなぁ。
363:デフォルトの名無しさん
11/10/24 18:15:42.33
>>362
何を言っているのか理解できないので
くわしく教えて
364:デフォルトの名無しさん
11/10/24 19:49:26.90
そもそも、関数型でOOP的なものが必要なところは限られてる。シミュレーション
をやるなら重宝するんだけど。でもScalaをやってる人のソースを見てるとやっぱり
関数型っぽくないというのかJavaの後継という使い方に見える。
関数型のスタイルでScalaをやってるブログなどがあったらぜひ見てみたいので
英語でもいいし教えてね。
365:デフォルトの名無しさん
11/10/24 20:13:16.66
scalaz界隈をうろつけばいいじゃない（想像）
366:デフォルトの名無しさん
11/10/24 23:01:42.68
なぜScalaモヒカンは他言語をdisるのか
それも詳しく知りもしないくせに
367:デフォルトの名無しさん
11/10/24 23:11:28.45
>>366
いいじゃん別に
disらせとけば
なんか不利益でも被ってんの？
368:デフォルトの名無しさん
11/10/24 23:20:17.71
不利益を被ってないなら黙ってろって？
どうせScalaをdisられたら顔真っ赤にして反論するくせにw
369:デフォルトの名無しさん
11/10/24 23:31:42.66
うむ、disられたら顔真っ赤にしてキッチリ反論するのはいいと思うよ
2chの言語スレに来てグダグダいうよりはよっぽど
370:デフォルトの名無しさん
11/10/24 23:41:40.60
>>358
ocamlのvariantもモジュールで隠蔽できるから、
たぶんそれ書いた人の勘違いじゃないか？
371:デフォルトの名無しさん
11/10/25 00:42:22.72
sbtのtestの出力結果ってwinではカラー表示できないの？
372: ◆CgacaMDhSQ
11/10/25 00:48:17.81
>>370
たぶん書いた本人です。
>>358はちょっと誤解で、元の発言は
URLﾘﾝｸ(twitter.com)
URLﾘﾝｸ(twitter.com)
これはこれでちょっとわかりにくいですけど、要はパターンマッチ使いたかったら
variantの内部構造さらさなきゃいけないけど、Scalaだとパターンマッチのために
内部構造さらさなくても良いよね、という話です。
Haskellだとviewパターン、F#ならActive Patternがあるので似たような事が比較的簡単に
できますが、少なくともOCamlではvariantの構造をさらさなければパターンマッチング
できない(モジュールにvariantの構造を隠蔽しちゃうと外からパターンマッチングはできない)と
認識しています。もし間違っていたら、文献へのポインタを教えていただけるとありがたいです。
>>364
>>365が挙げてるようにscalaz界隈の人(単なるマニア向けライブラリに見えますが、意外にこれ
使ってるScalaプロジェクトは多いです)はかなり関数型的なスタイルやってますし、sbtも
かなり関数型的なコードになってます。全体的に見て、関数型スタイルでScalaプログラミング
やってる人は以前に比べてかなり増えてる印象です(少なくとも海外は)。
あと、ブログでも、関数型的なスタイルでScalaやってるところは、たくさん見つけられるかと。
@djspiewak さんのブログとか、@jamesiry さんのブログとか、色々ヒットしますよ。
373:デフォルトの名無しさん
11/10/25 00:58:38.49
actorでreplyするとAny型じゃん．
Int型の値に代入すると怒られるんだが，match文使わずにエレガントに
代入したい．
374:デフォルトの名無しさん
11/10/25 07:44:36.51
>>372
variantの構造、で何を指してるのかがイマイチわからない
例があると良いと思う
375:デフォルトの名無しさん
11/10/25 08:02:14.78
あ、良く読んでなかった。F#のActive Patternsねー
あれと同じことをOCamlでやるにはパターンガード使うしか無いけど、
それでパターンマッチできてるとは言わないわな
376:デフォルトの名無しさん
11/10/25 08:14:15.47
個人的にはパターンって内容を取り出すのが目的だと思ってた
377:デフォルトの名無しさん
11/10/25 08:20:26.47
Scalaは型ちゃんと書くから2nd order polymorphismが表現できてもよいと思うんだけど
(つまり、forall をいろんなところにつけれる)
例えば:
def foo(id : [A]. A => A) : Unit =
id(id)(())
これが普通にできればMLやHaskellより明らかに強力と言えるのではないか。
378:デフォルトの名無しさん
11/10/25 08:38:11.46
>>376
ですよねー
379:デフォルトの名無しさん
11/10/25 08:46:09.53
多分この中のどれかにやりたいことがあるのでは？
(* データ型の隠蔽 *)
module type S1 = sig
type r
type s
type t = Foo of r | Bar of s
end
(* コンストラクタの隠蔽 *)
module type S2 = sig
type t = private Foo of int | Bar of string
end
(* 幽霊型 *)
module type S3 = sig
type s = Foo | Bar
type 'a t constraint 'a = s
end
380:デフォルトの名無しさん
11/10/25 11:55:40.54
Camlp4使うしexperimental featureだけど一応こんなのあるみたいっすよ
URLﾘﾝｸ(martin.jambon.free.fr)
381:デフォルトの名無しさん
11/10/25 16:32:39.86
>>377
書いてみた
import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id.apply[Unit])(())
foo(new Forall[({ type X[A] = A => A })#X] { def apply[A] = identity })
382:デフォルトの名無しさん
11/10/25 17:30:56.34
もうちょっと短く書けた
import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id[Unit])(())
foo(Forall[({ type X[A] = A => A })#X](_(identity)))
383:デフォルトの名無しさん
11/10/25 18:57:12.81
>>372
ありがと いくつかのブログ漁ってみるよ。
384:デフォルトの名無しさん
11/10/25 22:36:49.23
ファイル出力の標準的な方法ってありますか？
ファイル入力のSource.fromFileに対応するようなものです。
今はFileOutputStream～PrintWriterといったJavaのAPIを使ってますが正直面倒です。
385:デフォルトの名無しさん
11/10/25 22:50:02.40
jajava.nioで
386:デフォルトの名無しさん
11/10/27 08:47:25.77
(Int)=>Intのような関数を引数に取るAPIを、Javaから呼ぶにはどうやって引数を渡せばよいの？
自力でFunction2にラップする？
そういうユーティリティが既にある？
387:デフォルトの名無しさん
11/10/27 13:41:22.80
>>386
scala.Function1をimportして
new Function1<Integer,Integer>() { public Integer apply(Integer i) {...}}
とすればよいのではないか。
388:デフォルトの名無しさん
11/10/27 13:56:12.49
>>386
ScalaのtraitはJavaのinterfaceになるから、具体メソッドはすべてつぶされてしまう(ヒドス)。
Function1はtraitなのでJavaから便利に使うためにabstract classにする。
==========scala============
abstract class Fun[-A,+B] extends Function1[A,B] {
override def andThen[T](g: (B) => T): (A) => T = this.andThen(g)
override def compose[T](g: (T) => A): (T) => B = this.compose(g)
override def toString(): String = this.toString()
}
389:デフォルトの名無しさん
11/10/27 13:59:31.00
==========java=============
import scala.Function1;
import scala.Some;
public class Main {
public static void main(String[] _args) {
Fun<Integer,Integer> f = new Fun<Integer,Integer>() {
@Override
public Integer apply(Integer n) {
return n+1;
}
};
System.out.println(new Some(3).map(f));
}
}
390:386
11/10/28 08:38:52.69
>>387,388,389
さんきゅー！
基本は388&389の方針に従った。
scala側は
abstract class Func1[-A,+B] extends Function1[A,B]
で十分みたい。
andThen,compose,toStringは勝手に生成されたよ。
実装のあるtraitをabstract classでextendsしたら
その実装を引き継ぐコードが自動生成されるみたいだね。
(Int)=>Intの関数は、JavaではFunction1<Object,Object>に
見えるらしく、Java側はこんなコードになったけど、
まあ、我慢できる範囲かな。andThenもこのまま使えたよ！
| Func1<Object,Object> f = new Func1<Object,Object>() {
| @Override public Object apply(Object v) {
| return (Integer)v + 1;
| }
| };
ありがと！
391:デフォルトの名無しさん
11/10/28 11:37:21.63
play2.0ってeclipsify出来ないの？
392:デフォルトの名無しさん
11/10/28 19:04:31.14
上でファイル出力の質問があったけど、実際みんなJavaのAPIでやってます？
Sourceはなぜこんな非対称な仕様なんだろう…
393:デフォルトの名無しさん
11/10/28 20:59:19.04
俺はOutputStreamへの書き込みは次のようなusing関数を使うのがよいと思うのだが
どうだろう？
| def using[T](out : OutputStream)(f : Outputstream => T) : T = {
| try {
| val r = f(out)
| out.close()
| r
| } catch {
| e => out.close(); throw e
| }
| }
394:デフォルトの名無しさん
11/10/28 21:01:17.45
def usingFile[T](fileName : String) = using[T](new FileOutputStream(filename))
395:デフォルトの名無しさん
11/10/28 21:07:42.43
使い方
usingFile("foo.txt") {
out =>
val w = new PrintWriter(out)
w.println("firstLine")
w.println("secondLine")
}
396:デフォルトの名無しさん
11/10/28 22:17:31.96
>>395
out => ってどこから使えるようになったの？
397:デフォルトの名無しさん
11/10/28 22:43:58.48
>>396
仮引数だよ。
list.map { a => a+1 }
の a と一緒。
398:デフォルトの名無しさん
11/10/28 22:47:46.22
PrintWriterもusingFileで作ってしまったら？
399:デフォルトの名無しさん
11/10/28 22:49:50.13
か、か、かりひきすう？
それなに？まだよくわからん
引数と違うの？
400:デフォルトの名無しさん
11/10/28 23:15:58.69
>>399
仮引数ってのは正確な物言いじゃあないかもしらんが、Java でも何でも一般的な概念でしょう。
401:デフォルトの名無しさん
11/10/28 23:21:54.39
仮引数に束縛…とか、アリティが…とか、正直実用だけを考えるなら、用語を知る必要もない。
つか仮引数とかって基本情報とかに出てきたような過去の記憶が。
402:デフォルトの名無しさん
11/10/29 08:05:34.67
>>396
関数を引数として渡すときに #Scala ではしばしば {}で囲って表現する。
someArray.foreach(x => save(x); println(x)) って書くよりも
someArray.foreach {
x =>
save(x)
println(x)
}
って書いた方がDSLぽくてカッコいいでしょ。
403:デフォルトの名無しさん
11/10/29 09:07:43.26
>>388
> Function1はtraitなのでJavaから便利に使うためにabstract classにする。
>
> ==========scala============
> abstract class Fun[-A,+B] extends Function1[A,B] {
その目的のためには、scala.runtime.AbstractFunction1が既に標準で用意されている也。
404:デフォルトの名無しさん
11/10/29 09:24:30.22
>>396
気になってるのは out が前触れなしに出てきたからでしょ。
これってたとえば 「def add1(a: Int) = a + 1」 の add の直後に出てくる a つまり仮引数と一緒なんですよ。
で、もう最初に気になったあたりを見直すと、
def using[T](out : OutputStream)(f : Outputstream => T)
ってなってて、結果的に usingFile の 2 つめの引数の型は「Outputstream => T」になる。
これは「Outputstream を一つ引数にとり T を返す関数」を要求してることになるから、
(out: Outputstream) => hogehoge....
と書くところを
out => hogehoge...
と書けるわけ。
405:デフォルトの名無しさん
11/10/29 13:54:53.12
>>404
def using[T](out : OutputStream)(f : Outputstream => T)
って表記されればわかった。
REPLってなんで定義した関数の型とか引数の情報も
詳しく出してくれないのですか？F#ならでるのですが
406:デフォルトの名無しさん
11/10/29 23:47:25.13
>>405
え、嘘、出るだろ！？と思ってやってみたら出たけど、
どういう時に出ないの？
407:デフォルトの名無しさん
11/10/30 02:18:06.25
今更かもしれませんが、これってどう思いますか？
SIP-12 - Uncluttering Scala's syntax for control structures.
URLﾘﾝｸ(docs.scala-lang.org)
(なぜか過去のコメントが見られなくなってしまったようです)
個人的には、利点があまり感じられない上に、
ユーザ定義の制御構造との統一感が無くなるので、
賛成できないのですが。
408:デフォルトの名無しさん
11/10/30 03:02:51.57
forのカッコは鬱陶しいと思ってたので歓迎
他はどっちでもいいかな
409:デフォルトの名無しさん
11/10/30 09:40:42.29
>>407
#Scala がますます #Haskell や #OCaml みたいになるな。
しかしあまりJavaと離してしまうと、Javaユーザーが導入しづらくなり、
ポストJavaの立場がやばくなるのでは。scalaユーザが増えてほしい俺としては
ちょっと反対。
410:デフォルトの名無しさん
11/10/30 09:51:31.15
>>409
その#は何？
411:デフォルトの名無しさん
11/10/30 09:54:00.13
Twitterのつもりなのでは。
412: ◆CgacaMDhSQ
11/10/30 10:23:03.80
>>409
個人的には、もっと早いタイミングで導入するのならアリだった。
シンタックスがよりJavaっぽくなくなってしまうことはそれほど問題じゃないと思う。
ただ、2.10のタイミングで、こういう、言語の表現力を上げるわけでもない「些細な」
構文的変更入れてしまうのは、反対というか遅すぎるな。
まだSIPの段階なんで入ると決まったわけじゃない。提案者が
Odersky先生ではあるけれど、まだpendingだし、MLで反対票が
多ければ入らない可能性も十分ある(2.8のときに、Seq -> Sequence
の名前変更が、反対が多くて断念したという実例とか)。
今は当時よりもScalaを実用で使ってるユーザが増えてるので、幅広く
意見集めれば反対票も出てくるのでは、と思う。
413:デフォルトの名無しさん
11/10/30 11:10:07.78
>>412
Javaユーザが敬遠してしまう要因を増やすことになると思うがそれはよい？
JavaユーザがScalaへ移行することは重要ではないと言っている？
414: ◆CgacaMDhSQ
11/10/30 11:51:43.42
>>413
最初の問いについては、元々Scalaの構文はJava互換でないので、>>407くらいの
変更が入ったところで、敬遠する要因が増えるかというとそんなに変わらないのでは、というのが自分の考え。
ただ、「2.10のタイミングで」これを入れるのは、Scalaへの移行を検討しているJavaユーザを遠ざける
要因になり得るので、反対(既存の構文がすぐに使えなくなるわけではないにせよ、
しばらく、旧構文と新構文を使ったコードの両方が出てきて、無用な混乱を招きそう)。
二つ目の問いについては、重要だと思っている。だからこそ、SIP 12に対しては反対。
なら行動起こせよ、と言われそうなので、説得力のある反論をまとめて、>>407のページに
コメントする事は検討中。
415:デフォルトの名無しさん
11/10/30 12:20:19.45
>>413
お前も然るべきところで意見できるように精進しろよ＾ｗ＾
416:デフォルトの名無しさん
11/10/30 12:31:12.24
>>415 はい。勉強させていただきます。先生。
417:デフォルトの名無しさん
11/10/30 13:17:07.97
しかしifにかっこがいるというのは最初の頃はしょっちゅう間違えたところなので、
できれば導入して欲しいな。
せっかく一引数関数のかっこを不要にしてるんだから。
418:デフォルトの名無しさん
11/10/30 15:46:25.80
構文まで変えるなら2.10じゃなくて3.0にすればいいのでは
419:デフォルトの名無しさん
11/10/30 16:42:09.31
省略できるもんはなんでも省略しようぜｗｗ
Javaなんて忘れて新しい秩序をつくるんだ
420:デフォルトの名無しさん
11/10/30 16:45:16.71
Scalaが話題にのぼるようになってから、もう何年経つと思ってるんだ
未だにJavaで満足してる奴はもう切り捨て！いらね！
というわけで「Javaっぽさ」という視点はもうScalaには不要
421:デフォルトの名無しさん
11/10/30 20:38:06.81
>>419
カッコは必ず書く派としては賛同できんな。
言語仕様として「できる」ようにする事には必ずしも反対ではないが、原則は書くべき。
422:デフォルトの名無しさん
11/10/30 20:49:46.82
設定した通りにカッコとかを付けたり付けなかったりしてくれるコード整形ツールがあればいいと僕は思います！
423:デフォルトの名無しさん
11/10/30 21:53:06.95
よく分からんが、
現在の
if (expression) expression else expression
という構文は廃止して
if expression then expression [else expression]
という構文になるってことか。
ただ、expression の外側に "( )" をつけてもそれはexpression だから、
if ( expression ) then expression [else expression]
はOKなんだよね？
つまり、then 必須になるってこと？
424:デフォルトの名無しさん
11/10/30 22:23:50.38
これまでかっこが果たしていたセパレータとしての役割をthenが果たすようになるってこと
425:デフォルトの名無しさん
11/11/04 10:06:39.96
Javaで書いていたswingの部品（たとえばJPanel）を
scala.swingのフレームに張り付けるなんてことは可能でしょうか？
scala.swingは薄いラッパーといわれているので、Javaとまぜて使えないかと期待してます。
426:デフォルトの名無しさん
11/11/05 15:30:38.80
>>425
できるよー。scala.swingのコンポーネントには、peerというメソッドがあって、対応するSwingの
コンポーネントを取り出すことができる。
val panel : scala.swing.Panel = ...
val peer = panel.peer
みたいな感じで
427:デフォルトの名無しさん
11/11/05 16:12:50.58
>>426
横からだけど便利だな～
objectにしておいてくれたほうが良かった気がするけど。
何か理由があるのかな？
428:デフォルトの名無しさん
11/11/05 21:19:41.59
>>426
ありがとうございます。
私のやりたかったこととは逆（scalaで書いていた部品をJavaに取り込む方法ですよね？）
ですが、便利そうです。
なお私のやりたかったことはwrapでできるということがわかりました。
429:デフォルトの名無しさん
11/11/07 01:00:13.70
URLﾘﾝｸ(www.eclipse.org)
もうScala不要じゃね？
430:デフォルトの名無しさん
11/11/07 01:13:52.90
関数型としてじゃなくてBeyond javaとしては、そっちの方が筋いいかも
431:デフォルトの名無しさん
11/11/07 03:15:48.89
genericsの型制約のシンタックスが好きじゃない
? extends とか読めない
Scalaのほうが良いと思う
432:デフォルトの名無しさん
11/11/07 07:32:22.17
Scala終わったなぁ
433:デフォルトの名無しさん
11/11/07 10:58:20.13
URLﾘﾝｸ(lambda-the-ultimate.org)
これぐらいしかnewsがないな。
xtext2.1リリースで、xtendもバージョンアップしたのかな？
URLﾘﾝｸ(www.infoq.com)
434:デフォルトの名無しさん
11/11/08 14:15:14.59
バイトコードじゃなくて、Javaコードを吐くというのが特徴？
435:デフォルトの名無しさん
11/11/08 14:21:55.62
このクロージャの構文、リスト内包表記に喧嘩売ってる気が
val predicate = [ Person person | "Hans" == person.name ]
436:デフォルトの名無しさん
11/11/08 17:42:24.87
どっちかというとSmalltalkのパクりじゃね？
437:デフォルトの名無しさん
11/11/08 19:57:24.06
公式の右下に開発環境は何よ？ってミニアンケートがあるね。
もちろん皆 vimだよな？！
438:デフォルトの名無しさん
11/11/08 23:03:23.17
IDEA1択
439:デフォルトの名無しさん
11/11/08 23:05:28.63
sbtがあるから普通のテキストエディタでも問題ないね
440:デフォルトの名無しさん
11/11/09 00:10:47.06
>>429
JetBrainsのKotlin といい、 ほとんど同じような言語開発する暇あったら、
Scala を手伝ってやれよ、って思ってしまう。
言語ばっかり乱立しても、共倒れするだろうに。
441:デフォルトの名無しさん
11/11/09 00:19:08.57
xtendは、xtextのサンプルでもあるから、
JVM上のbetter javaのCeylonやKotlinとはちょっと意味合いが違うと思う。
442:デフォルトの名無しさん
11/11/09 00:27:54.68
たしかにいくつ作るんだよとは思うが。
Javaのシンタックスシュガーに徹するんならJSRにのせたりしないのかね。
443:デフォルトの名無しさん
11/11/09 00:59:45.83
別にいくら作ってもいいんだが、なぜみんなScalaとJavaの中間を目指すんだろう
仕様は日和っているわりに、これから実装しますとか実用性もない状態で、誰が使おうと思うのだろう
444:デフォルトの名無しさん
11/11/09 03:11:09.07
えっ、気分でしょ？
445:デフォルトの名無しさん
11/11/09 06:07:14.92
>>443
Scalaより単純で実用的と言ってるんだから、使える標準ライブラリとひとまとめにしてさっさと公開すればよいのにね
結局、現時点でScalaの方が基本インフラ整ってる分実用性が高いとか皮肉すぎる
446:デフォルトの名無しさん
11/11/09 06:33:03.79
>>443
発想が「ぼくのかんがえた さいきょうの Better Java」だから、だろうねぇ。
447:デフォルトの名無しさん
11/11/09 10:14:51.22
xtext,xbase,xtend 2.1 リリース
URLﾘﾝｸ(www.infoq.com)
scalaこれで実装したら遅くなるんだろうな
448:デフォルトの名無しさん
11/11/09 23:00:13.38
Oderskyはバリバリ実装する人であると同時に優秀な理論屋なので、Scalaの仕様は
理想と現実の妥協点がよく考えられてるんだけど、後発のおいしい所取り狙ってる言語は、
なんかよくわからずにテキトーにScalaの一部分持ってきてるだけに見えるんだな
449:デフォルトの名無しさん
11/11/10 00:58:45.17
最近更新されてないんだな。
あんまり学会発表しなくなった？
URLﾘﾝｸ(www.scala-lang.org)
450:デフォルトの名無しさん
11/11/10 01:10:23.66
URLﾘﾝｸ(ppl.stanford.edu)
もしかして、こっちで少し指導してる？
並列とDSLだね。（C++テンプレート使った奴が何年か前かなり流行ってた。最近はHaskellとかも）
451:デフォルトの名無しさん
11/11/12 05:41:40.07
#xtend って結局Javaと #Scala の中間的言語だから Java->Scalaの道が
よりなだらかになったと考えるべきじゃね。だから Scalarはむしろ
xtendを大歓迎すべきだと思う。そしてxtendに新しい機能が追加される
度に「あーそれ2年前にやったわー」と言っておけばよい。
問題はむしろJavaがいつまでも使われ続けること。
452:デフォルトの名無しさん
11/11/12 06:33:46.17
JVMで動く言語、に限らずだけど、スクリプト系の言語みたいに一ファイルだけデプロイして置き換えるだけでOKって出来ないのが辛い
453:デフォルトの名無しさん
11/11/12 06:43:17.48
>>452 まともなスクリプト言語開発者なら、デプロイする前に
単体テストしたりコミットしたりするだろ？それを考えると
そこまで大差ないと思うんだが。
454:デフォルトの名無しさん
11/11/12 06:52:33.30
s/スクリプト言語開発者/スクリプト言語を使う開発者/
455:デフォルトの名無しさん
11/11/12 12:52:56.77
xtendがあればScalaが不要になるんだよね？
456:デフォルトの名無しさん
11/11/12 13:50:53.98
gitからhotデプロイ出来る仕組みにしてみるとか？
457:デフォルトの名無しさん
11/11/12 14:23:29.35
JRebelのscala lisenceのページが消えて、購入ページに飛びますな
URLﾘﾝｸ(sales.zeroturnaround.com)
変わりに非商用プロジェクト向けのJRebel Socialなるものが
URLﾘﾝｸ(social.jrebel.com)
そして、facebookかtwitterでログインしろとか
458:デフォルトの名無しさん
11/11/12 22:11:01.67
テキストファイルの内容を丸ごと文字列に変換するライブラリ関数はありませんか？
今は，scala.io.Source.fromFile(file).getLinesで一行ずつ読みながらつなげていってますが、
どうも馬鹿げているので。
459:デフォルトの名無しさん
11/11/12 22:17:49.01
mkString使え
460:デフォルトの名無しさん
11/11/16 01:54:53.92
最近、whileで書いていたところは、大体Stream.iterateに置換できることを発見して、うひょーと思ったが
前スレを見たら余裕で紹介されてた
461:デフォルトの名無しさん
11/11/17 07:30:00.45
Stream.iterateめちゃくちゃ遅い
forはwhileでガチガチに最適化するのがいい
462:デフォルトの名無しさん
11/11/18 19:45:48.66
Javaのソースファイルが生成されるってのは予想以上に便利だな
ものすごく親和性が高い気がする
463:デフォルトの名無しさん
11/11/18 21:44:24.30
URLﾘﾝｸ(twitter.com)
464:デフォルトの名無しさん
11/11/19 00:56:45.66
株式会社ドワンゴでも使っているみたいね。
URLﾘﾝｸ(live.nicovideo.jp)
ドワンゴ研究開発チャンネル
465:デフォルトの名無しさん
11/11/19 04:47:49.82
非公開設定してるユーザーのツイート貼ってんじゃねえぞボケナス
466:デフォルトの名無しさん
11/11/19 10:46:18.94
URLﾘﾝｸ(scan.netsecurity.ne.jp)
tokuhirom、ma.la？っていう人の話だけ聞きたい
色々なスレで見かけるけどWEB業界で有名らしいね
動画ありませんか？
467:デフォルトの名無しさん
11/11/19 11:39:12.14
貼られたときは公開してたよ
468:デフォルトの名無しさん
11/11/19 12:10:04.06
>>464
なにこれ面白そうじゃん
タイムシフト予約したわ
あまり初心者向けにならないでほしい
469:デフォルトの名無しさん
11/11/20 01:22:05.72
>>464
面白そうだな
ドワンゴのレベルを見させてもらおう
470:デフォルトの名無しさん
11/11/20 11:13:49.83
会場がドワンゴなだけじゃないの
471:デフォルトの名無しさん
11/11/20 14:02:51.62
発表スキルの落差がすさまじいな
472:デフォルトの名無しさん
11/11/20 15:08:48.04
そら社内リソース+αだけじゃ裾野が狭すぎ。
473:デフォルトの名無しさん
11/11/20 15:41:44.46
俺も度湾後入りたくなったわw
内容は初心者向けに平易なものにしてくれてたのかな
474:デフォルトの名無しさん
11/11/20 15:43:50.07
これ平易じゃなかっただろｗ
475:デフォルトの名無しさん
11/11/20 15:49:59.24
そうかな？
476:デフォルトの名無しさん
11/11/20 20:25:13.99
javaのComparableインタフェースを実装したクラスC
public class C implements Comparable { ... }
のサブクラスをscalaで定義したいのですが、ここにある問題にぶつかってしまいました。
URLﾘﾝｸ(scala-programming-language.1934581.n4.nabble.com)
class D extends C {
def compareTo(other:AnyRef) : Int = 0
}
とやっても
class D needs to be abstract, since method compareTo in trait Comparable of type (x$1: T)Int
is not defined (Note that T does not match AnyRef)
というエラーになります。
なにか回避策はないでしょうか？
477:デフォルトの名無しさん
11/11/20 20:26:31.02
ちなみにクラスCの実装はJavaのライブラリ内にあって修正はできない状態です。
できればscala側で何とかしたいのですが…
478:デフォルトの名無しさん
11/11/20 21:08:29.88
Java側でcompareToをoverrideしないと無理かもしれぬ
479:デフォルトの名無しさん
11/11/20 21:11:47.43
これ何でエラーが出てるの
型が違うのか
anyrefとobjectで
480:デフォルトの名無しさん
11/11/20 22:31:57.43
>> 476
"Note that T does not match AnyRef"
っていうメッセージのとおり、compareToの引数の型がAnyRefではだめってだけじゃないの？
リンク先のメーリングリストの議論は、2.8のRCのときだからたまたまbugってたというだけで、関係なさそうだけれど
481:デフォルトの名無しさん
11/11/20 22:43:50.37
ここを見ると、scala単体での回避は無理そうだね。
URLﾘﾝｸ(stackoverflow.com)
482:デフォルトの名無しさん
11/11/21 00:29:22.79
ドワンゴ入ればScalaやらせてもらえるらしい
483:デフォルトの名無しさん
11/11/21 00:34:27.70
Scala書ける人を雇ってphpを書かせる
怖いお
484:デフォルトの名無しさん
11/11/21 00:38:26.76
絶対Scalaなんてやってないだろ
そもそも人気高くて入れなさそうだけど
485:デフォルトの名無しさん
11/11/21 00:50:39.16
今年新卒60人採用でしょ
景気のいい話さ
486:デフォルトの名無しさん
11/11/21 01:26:05.89
しかしあそこに集まってた連中は流石に濃いメンツだったな
本当にニコニコかという感じだったw
487:デフォルトの名無しさん
11/11/21 03:12:02.22
あぁいつものメンバーかって感じがしたわ
488:デフォルトの名無しさん
11/11/22 08:25:06.61
ひろゆきもちょっと来てたらしいね。
さすが技術には力を入れているっていう感じだった。
489:デフォルトの名無しさん
11/11/22 09:58:05.88
なにその胡散臭すぎる話
490:デフォルトの名無しさん
11/11/22 10:01:14.69
いつものメンバーは一人病欠だろｗ
491:デフォルトの名無しさん
11/11/22 23:14:37.57
>>490
病欠ですいませんorz
492:デフォルトの名無しさん
11/11/23 01:04:25.68
今回のは、ニコ動本部の配信だけど、
草の根的なScala勉強会も、地方にストリーミングしてほしいなあ。
493:デフォルトの名無しさん
11/11/23 01:08:30.57
渋谷のやつなら大体Ustしてるんじゃね
494:デフォルトの名無しさん
11/11/23 01:30:16.47
URLﾘﾝｸ(www.scala-users.org)
これって毎週やってんでしょ？ネタなくならないの？
たまに録画みるけどすごいぐだぽよ～な感じだよね
495:デフォルトの名無しさん
11/11/23 01:56:03.09
今思うとscala東北の配信は最高に濃かったよな
496:デフォルトの名無しさん
11/11/23 15:29:35.16
>>495
@ymnk さんというスーパーハカーの力あってのものでしたね…
あのクオリティを毎週維持できてたのはほんと凄いとしかいいようが無いです
震災の影響で休止になったままなのが残念
497:デフォルトの名無しさん
11/11/23 18:01:37.76
コテつけろやエバンジェ！
498: ◆CgacaMDhSQ
11/11/23 18:07:16.99
了解です。最近スレをあまり覗かなくなったのと、マシン環境変えたのでトリップ付けるの失念してました
いやまあ、たぶん発言の仕方でバレてる気もしますが。
499:デフォルトの名無しさん
11/11/23 18:35:53.93
>>498
ついでに>476にも愛の手を
500: ◆CgacaMDhSQ
11/11/23 18:59:13.55
>>499
ちょっとでかけるので、手短に言うと、>>476の問題はJava側でワークアラウンド用のJavaコード書くしかないです。
これは、ジェネリックなクラス/インタフェースの型パラメータ無し(raw type)をスーパータイプとして
Java側で継承したときに起きる、ややレアな問題で、当面は対処されないと思います。
501:デフォルトの名無しさん
11/11/23 20:47:44.23
URLﾘﾝｸ(d.hatena.ne.jp)
早速ヒロちゃんが来てる。このブログ主は訳してるだけだから・・・そっとしておいたげて。
502:デフォルトの名無しさん
11/11/23 20:50:23.76
そこの元記事：
URLﾘﾝｸ(blog.joda.org)
すでに、炎上してて、読む気が起こらん。FUD連呼厨をみてどこも同じだな。
とは思った。
503:デフォルトの名無しさん
11/11/23 21:07:31.74
>476みたいなJavaとの相互運用上の落とし穴をまとめた資料ってどっかにないのかな
504:デフォルトの名無しさん
11/11/23 21:13:13.09
>500
ありがとうございます。
Javaで接続用のクラスを作ることにします。
eclipseだとscalaとJavaを同一プロジェクトに共存させられないのが
こういうとき面倒ですね。
505:デフォルトの名無しさん
11/11/23 22:00:40.96
>>501
そこのコメント欄、読みづらすぎｗ
506:デフォルトの名無しさん
11/11/23 22:04:51.03
でもJodaTimeは俺も使ってるからショックだなあ
実はScalaTimeのしょぼラッピングぶりとか見て切れてたりして
507:デフォルトの名無しさん
11/11/24 01:43:06.26
>>504
eclipseでScalaとJavaを同一プロジェクトに共存させることはできます(というかそれをするために、JDTがまともな拡張ポイントを提供してくれてない
せいで、ScalaのEclipseプラグインはかなり苦労してます)。単に、Javaパッケージ下に.scalaファイル置けばそれでOKです。
>>501
さすがに、ブログ主がその主張をしてるとは思ってません。日本語だけ見る人が訳のまとめ見て誤解したら
嫌だなあ、と思ってつい長文コメント書いてしまいました。ただ、そのブログ主にとっては迷惑だったかもしれませんし、今は反省してます…
>>506
自分も、JodaTimeは良い設計してると思うだけに、その作者がこんなに残念な(感情的な)書き散らしをするのだなあ、というのはちょっとショックでした。
508: ◆CgacaMDhSQ
11/11/24 01:44:42.41
>>507は自分です(見ればわかるかとは思いますが)
509:デフォルトの名無しさん
11/11/24 03:02:29.87
向こうは、営利的な部分でも感情的に振る舞う、ポジショントークは多い気はする（経営者っぽい？）
そして人間関係は別だったりする。
日本の技術者は、普段は公平性を重んじるから、会社の立場はあまり気にしないんだけど。
本当に好き嫌いでポジショントークしたり、論理的に装ったりする場合も多いから、イマイチ立場が判りづらい。
510:デフォルトの名無しさん
11/11/25 11:36:00.48
この場合、scalaをこき下ろす営利ってなんだろうか？利害はなさそうに思うけどな。
ただ、感情的なものがあるとしたらコミュニティへの不信感はあらわにしてると思う。
仕様が複雑なものに柔軟性を加え用とすると、さらに仕様が複雑になって手に負えな
くなるというパターンは普通にあることだし、言ってることもわからないことではな
いかな。複雑にすればするほど、直交性も崩れやすいのも当然だしね。だから、
感情的なところと理性的な部分を含んだ内容と理解してるね。
511: ◆CgacaMDhSQ
11/11/25 17:43:19.46
彼の場合、正直、Scala(コミュニティ？)嫌いが先にありきでそのために理由を作り出しているようにしか見えないのが問題
つーのは、彼の挙げてる例とかコメント見る限りで、Scalaをほとんど使った事が無い事がわかるので。 状況証拠は大体揃ってて
(1) ++ が java.util.List#addAll() と同じだという初歩的な勘違い
Scalaを使ってプログラムしたことがあれば、この程度の勘違いをするはずが無い
(++ は immutable collectionの連結で、 java.util.List#addAll()は、mutable listへの要素の追加)
(2) List(1, "foo") の結果型が List[Any] でコンパイルエラーにならないのが問題だと言っている
コンパイルエラーが検出されるタイミングがずれるという意味では全く問題ではないとは言わないけど、
少なくとも安全性の面で問題は無い(mutable listに要素を追加するのと勘違いしているのだろうと推測)
(3) Scalaのフレキシブルな構文のせいでコンパイラが遅いと言っている
本当の理由は、implicit searchのコスト + コンパイラのパス数の多さ
彼は、パージングにかかる時間が一般にコンパイル時間の多くを占めていないということすら知らない
(4) Scalaが言語レベルでimmutablityを強制できていない(ので、並行プログラミングで問題だ)という事をことさら問題視している
実際には、たとえばActorでmutable objectをわざわざ渡す奴は居ないし、海外Scala MLでもその手のトラブルは聞いたことが無い
(5) 空想のScalaコミュニティに対して反発している
型理論とかを知らない奴をけなしている、などと言っているが、実際にはそのような人物はコミュニティではほとんど居ない。
むしろ、そういう質問があったら、積極的に答えようとする人が多い(多すぎるくらい)。つまり、実際のScalaコミュニティ(特に公式
MLなどでの経験があったわけではないのは、ほとんど確実)
(6) Scalaを使用した経験から批判してるのか、そうでないのか、どっち？という質問を全スルー。
他にも色々あるのだけど、この辺で。要はScalaをまるで知らないのに、一知半解どころか一知すら無い状態でこきおろしてる、ってのが一連の
ポストとコメントでわかったのが収穫かな。で、誠実な部分含めて、都合の悪い指摘全スルーしてる辺り、確信的にやってる(FUD)とやはり俺は思う
512: ◆CgacaMDhSQ
11/11/25 17:52:57.35
もちろん、Scalaには色々な問題があると俺は思う。
・実用的には重要な標準IOライブラリが中途半端なscala.ioしかない
・sbtという重要な基盤ツールの進化が速過ぎて、ドキュメントが追いついていない
・標準ライブラリのscaladocのドキュメンテーションコメントが少ない
・これは、コミュニティ内部でも問題視されてて、その結果、 URLﾘﾝｸ(docs.scala-lang.org) が出来たわけだが。
・コンパイル遅い(sbtでだいぶ緩和される & 改善に向けて内部的にも色々進行中だけど)
・バージョン間バイナリ非互換性の問題(Typesafeが、この問題を解決するツールを開発してるみたいだが)
IDEはかなり良くなってきた(特にIntelliJは良い)ので、そっちの方の不満は少なくなってきたけど、もっと周辺ライブラリとの強調とか
標準IOライブラリへの取り組み(Scala-IOの支援とか)とかを積極的にやって欲しいな、という印象。言語自体は、もうちょい型推論
強化してくれたらな、というくらいで、不満はそれほど多く無いかな。
513:デフォルトの名無しさん
11/11/25 18:01:25.62
sbtもclojureのleiningenほど使えるようになればいいのにね。
514:デフォルトの名無しさん
11/11/25 18:07:14.44
マイナー言語が人気出てくると、貶すためだけの書き込みが
一時的に増えるのは、お局様が新人に切れるのと似てるな。
515:デフォルトの名無しさん
11/11/25 18:33:08.63
FUDはなぁ。 URLﾘﾝｸ(ja.wikipedia.org)
言語のことで、毛嫌いされてるといえば、lisperという立場から見ると
さんざんいろんな誤解を書き散らされてるけど、率直にいって、しゃーないなー
スルー。って感じが多いよ。中には、誤解に対して丁寧に答えてる人も
いるけど、よくあることさ。あんまり、FUDと捉えないほうがいいよ。
どんな話があっても流れてくる人はいるもんだ。
516:デフォルトの名無しさん
11/11/25 19:29:32.73
そうそう、楽する方法を一つ。適当なよくある質問を集めて、FAQを
作ってみたら？あるんだったら、そこに新たな質問と答を逐次追加し
ていけばいいしね。いつも丁寧に答えてたら、時間がいくらあっても
大変だろうし、水嶋さんは見る限り周囲の空気にはやや鈍感なのかも
しれないけど、聡明な方みたいだしね。その行動力はすごいと思って
見てるよ。でも、この性質は時々頭のよい人に見られるものだからな。
それを、より建設的な方向に利用すればいいってことだと思う。あなた
位ならば、すでに、どこがよく誤解されやすくって、その誤解をどう
説明するかは察しがついてると思うんだよね。
FAQもどんな形式が読み手が楽かとなると１問１答１ページ＋目次のほ
うが余裕があるかも。
517:デフォルトの名無しさん
11/11/25 19:35:34.58
FAQを作って、いろんな誤解があるものをまた良くわからんとって批判しとる
と見てたらいいし、乗り込んで丁寧に答えるような労力もつかわなくても
よくできると思うよ。
いちいち論戦したり答えたりするより、言語を使ってこんなこともあんなことも
そんなこともできるって示していったほうが、腕利きさんのセンスを持った
人を獲得しやすいんじゃないかなと思うよ。
長くなったけど、ほな頑張ってね～
518: ◆CgacaMDhSQ
11/11/26 02:56:53.23
>>515
なるほど。少なくとも、FUDというワードを使うのは議論をややこしくする可能性が高いので、避けるべきかもしれない。
ただ、今回の場合は色々反論があった(自分は何もしていないというかコメント欄で馬脚を現しただけだが)おかげで、
彼の批判が実経験に基づかない空想上のものである事が明らかになったわけで、まあ反論することにも意義は
あるかなと。自分の質問へのレスポンス
URLﾘﾝｸ(blog.joda.org)
で、結局、彼は「俺はScalaの経験はほとんど無いが、Scalaが駄目だって事を判断できる(キリッ」とか言ってるだけの人
だって事が確定したので、もう怒る気持ちすら失せて呆れてる段階だけど。
>>516
ちょっと今回は色々大人げ無くて、みっとも無かったかもしれませんが、丁寧なアドバイスありがとうございます。
よくある誤解に関するFAQについては、仰る通りそろそろ用意すべきときかもしれませんね。
また、FAQの形式に関しても、1問１答１ページ＋目次という構成は良さそうですね。その辺り含めて、
ちょっと検討してみます。
ちなみに、おっしゃる通り、自分はかなり空気が読めない方です(という自覚はあります)。聡明かどうかは自分では
どうにも判断できないですが。で、自分が聡明かはともかく、これまでのTwitterでのbot活動wによって、大量の疑問点に
対するリプライの蓄積があるので(twilogで読めます)、ある程度誤解やハマりパターンの傾向は把握している感じです。
>>517
応援ありがとうございます。確かに、誤解 or 曲解に対して、乗り込んで論戦するとかは結構労力使う
割に得るものが少ないという意味で、費用対効果が悪いですね。>>516さんのリプライでも書きましたが、
FAQをちょっとずつ書き溜めていきます。あとは、本家Scalaコミュニティに対してもっと貢献していきたい
ですね。今年になってからあまりバグレポートもできていないので。
519:デフォルトの名無しさん
11/11/26 10:50:28.50
文章の長いコテハンって痛いの法則
520:デフォルトの名無しさん
11/11/26 11:35:53.85
日本のScalaコミュニティが怖くて粘着質でウザイのは
まぎれも無い事実
521:デフォルトの名無しさん
11/11/26 14:09:33.31
このスレでは、519,520 みたいなウザイの短文野郎が現れるけど、ゴミだね。
なんで、わざわざScalaのスレにきて、粘着するんだろうね？彼は。
>516とか>517
は自分も同意です。
>誤解 or 曲解に対して、乗り込んで論戦するとかは結構労力使う
>割に得るものが少ないという意味で、費用対効果が悪いですね。
見る側にとっても、この手の議論に飽きてきたところ。
章立てとかいらないから、どっかにFAQでまとめといて、って感じ。
そんなことより、Scalaの事例を増やしたいなあ。
最近だと、C#とかは Kinectやりたいって理由だけで C#人口増えている。
Scalaもそういうキラーアプリがないかなあ。
他、日常業務スクリプト集 とかあったらうれしい。本でたら買う。
522:デフォルトの名無しさん
11/11/26 14:29:50.70
Scalaスレにウザくて粘着質な奴が張り付いているのは
まぎれも無い事実
523:デフォルトの名無しさん
11/11/26 14:53:29.60
>>521
対抗してQUMA用API充実させるとか？
524:デフォルトの名無しさん
11/11/26 15:36:43.61
Scalaの.net実装？が復活するって前に聞いた記憶があるかど今どうなってるのかしら？
525: ◆CgacaMDhSQ
11/11/26 15:55:39.33
>>521
第二回Scala会議で、その辺りについてちょっと発表できるかもです＞FAQでまとめ
Scala事例に関しては、国内だと細々とした利用は増えてるのですが、キラーアプリ
というのはまだ不在ですね。Play 2.0がTypesafe Stackのインストーラに統合される予定
なので、今までよりWebアプリをScalaで作りやすくはなるかもしれません。
>>524
.net実装自体はexperimentalですが既に動かせます。
URLﾘﾝｸ(lamp.epfl.ch)
にやり方が書いてあるので、参考までに。ちなみに、昔のScalaの.NET実装と違い、
今回復活したのはIKVMのランタイムを利用したものになっているため、手順が違うことに注意してください。
526:デフォルトの名無しさん
11/11/26 16:27:50.38
あああ、引数の型とか再帰の返り値型を書かなきゃならんとはめんどくせえ！
なんで他の言語と同じように推測してくれないんだよ！
誰か、俺があきらめがつくように、型推定できない最小の反例を見せてくれ！
引数と返値の2パターンでよろしく。あとゴルフでな。
527:デフォルトの名無しさん
11/11/26 22:35:27.03
def f(x,y) = x + y
とか
528:デフォルトの名無しさん
11/11/26 23:26:50.27
>>527
そうそう、その問題も。
なんで他の関数型ではできるそれが、Scalaでは許されないようにデザインされたのか？も知りたい。
529: ◆CgacaMDhSQ
11/11/27 00:00:00.30
>>526-528
まず、Scalaでは許されないようにデザインされた、というのは順序が逆、ということを念頭においてください。
ScalaはJavaの型システムをリファクタリングした上で拡張するという既定路線があって、その制約の元で
どこまで型推論できるのか、というのが問題になるわけです。
さて、
def f(x,y) = x + y
相当の関数が、何故ML系の言語では完全に推論できるのに、Scalaでは無理かというと、まず、"+"演算子の意味するところが
違うからです。たとえば、OCamlなら (+) の型は int -> int -> int なので、そこから x が Int, y がIntである事を容易に
推定することが(人力でも)できます。
一方で、Scalaでは、
def f(x,y) = x + y
における + は 式 x をレシーバとしたメソッド呼び出し (引数はy) になります。この時点でまず、+の型が不明である事に注意して
ください。この時点で、fは多相関数として推論しなければいけません(たとえば、Int同士の+だとみなすと、他の型に適用できなくなる)。
さて、この定義のx, yおよび x + y にどのような型を割り当てるべきでしょうか？
ひとつの方法として、
def f[T <: { def +(other: T): T }](x: T, y: T) = x + y
という方向が考えられます。しかし、以下のように別の推論を行うことも可能です。
def f[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y
さて、このどちら(他の推論候補もありますが、とりあえず2種類で考えて見ます)。少し考えればわかるのですが、
これはどちらが正解である(より一般的な型を推論している)とも言うことができません。MLのHM型システムの
元では、一切の型注釈無しに、完全かつ健全に、関数の「もっとも一般的な型」を推論できる事が保証されて
いますが、Scalaの型システム上では、それは「原理的に」無理なようになっています。この辺りはScalaが
サブタイピングを持っている事などと関係があるのですが、その辺りは長くなるのでこの辺りで。
530: ◆CgacaMDhSQ
11/11/27 00:01:55.84
捕捉ですが、説明の都合上、
def f[T <: { def +(other: T): T }](x: T, y: T) = x + y
というScalaの関数を定義してみましたが、現在のScalaのstructural typeの実装制約上、これはコンパイルを通りません。
通りませんが、この制約が緩められて、上のように書けたとしても、Scalaの型システム上での型推論は単純なものですら
かなり難しくなりえます。
531:デフォルトの名無しさん
11/11/27 00:06:56.06
>>507
> eclipseでScalaとJavaを同一プロジェクトに共存させることはできます(というかそれをするために、JDTがまともな拡張ポイントを提供してくれてない
> せいで、ScalaのEclipseプラグインはかなり苦労してます)。単に、Javaパッケージ下に.scalaファイル置けばそれでOKです。
これ、scalaプロジェクトの下にJavaパッケージ作って、その下にJavaクラスを置いたのでは駄目なんだね。
scalaソースからJavaパッケージのJavaクラスを参照しても見つけてくれない。
532: ◆CgacaMDhSQ
11/11/27 01:12:09.41
>>531
うーん。こちらの環境では、その方法で普通に使えましたけど…。ひょっとして、JavaエディタからScalaオブジェクトのメソッド
補完などが効きにくい事を仰っている？
533:デフォルトの名無しさん
11/11/27 08:06:48.58
>>532
いや、コンパイルエラー（エディタ上でエラーマーカーがつく）になります。
きっと微妙な落とし穴があるのでしょう。
scalaプラグインの完成度は余り高くないので。
534:デフォルトの名無しさん
11/11/27 08:48:59.45
>> 529,530
ありがと！
>> 529
前者のfと後者のfを比べると、「より一般的な型を推論している」という
意味では、明らかに後者の方がより一般的だけど？
それとも「一般的な型」の意味に齟齬がある？
日本語だと曖昧になるなら英語でも大丈夫すよ。
さらに、一般的な型という意味なら、こちらの方が。
def f[T <: { def +[U,V](other: U): V }](x: T, y: U) = x + y
これでFAでいいじゃん。
でも、Scalaはこれは許されないし、
許さないようにしているのは理由があるんだよね？それが知りたい。
>> 530
> Scalaの型システム上での型推論は単純なものですらかなり難しくなりえます。
そりゃ、探索空間が増えるから、比較すると難しいのは自明だけど、
「かなり」って主観的だし、もう一声！
実際のところ、どれくらい難しいの？
(a) 一般的なコーディングでも推論不可能なケースが多い
(b) 一般的なコーディングでは推論不可能なケースはまれだが存在する
(c) すべての推論可能だけどコンパイラ性能的に計算量が実用的でない
(d) すべての推論可能だけどコンパイルが実用範囲内で遅くなる
(e) すべての推論可能でコンパイル時間も問題無し
535:(1) ◆CgacaMDhSQ
11/11/27 10:19:16.01
>>534
おそらく、「より一般的な型を推論している」という言葉の使い方に齟齬があるかと思います
ここで、自分が「より一般的である」といっているのはメソッドシグニチャの包含関係がある
かどうかをさしています。
たとえば、次のfの推論と
(1) def f1(x: Int, y: Int): Int = x + y
以下の多相的なfの推論を比較したとき、
(2) def f2[T <: { def +(other: T): T }](x: T, y: T): X = x + y
(2)は(1)に比べて、「より一般的な型」を推論しているといえます。これは、
全ての式 x: X, y: Y について、f1(x, y) が型チェックを通るならば、f2(x, y) も型チェックを通るからです。
さて、次に
(3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y
と(2)を同様に比較してみます。結論から言うと、(2)では型チェックを通るが、(3)では
型チェックを通らない例が存在します。たとえば、x: Int, y: Intのとき、
f2(x, y) は 型チェックを通りますが、 f3(x, y) は型チェックを通りません。この理由は、必要であれば別のレスで述べますが、
ともあれそのような意味で、(3)は(2)より「一般的ではない」という事ができます。ここで、HM型システム
の元では、型付け可能な関数について、かならず「もっとも一般的な型」(principal typeと呼ばれます)
を推論することができる事が保証されており、推論結果の「正しさ」が保証されます。しかし、Scalaの
型システムではprincipal typeが存在しないので、そのような保証がありません。
536:(2) ◆CgacaMDhSQ
11/11/27 10:28:15.64
>>535
> 実際のところ、どれくらい難しいの？
前提として、推論が可能かと言えば「可能」です(推論結果の正しさや実用性を問わなければ)。
しかし、仰っているのは、そのような型推論システムでは無いでしょうから、それを前提
として答えると、答えは (a) になります。実際のところ、もうちょっと答えは複雑で、principal type
は推論できないけど、「大体のケースで正しくなりそうな」型推論を多くのケースで行えるアルゴリズムを
Scala上の型システムに構築できる可能性はあります。しかし、仮にできたとしても、それは理論上の
保証が無い(少なくとも簡単に保証できない)ので、HM型システムの型推論のような「安心感」を得ることは
できないでしょう。
537:デフォルトの名無しさん
11/11/27 10:59:10.98
>>535
> 必要であれば別のレスで述べますが、
ぷりーず。そこが議論の本質な気がする。
あと、(2)と(3)はそれで正しい？
538: ◆CgacaMDhSQ
11/11/27 12:32:56.22
>>537
おーけーです。これから述べます。の前に
> あと、(2)と(3)はそれで正しい？
はい。それで正しいです(少なくともScalaにおいて) 。
さて、その理由が議論の本質、ということなので以下に理由を述べます。先ほどは、
> (3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y
に対して、f3(100, 200) のような式が型チェックを通らないということを書きました。
ここで、問題になるのは、Intの+のシグニチャが(オーバーロードバージョンを無視したとして)、
(Int)Int
であるのに対して、(3)で、structural typeによって要求されているシグニチャは
[U >: T](U)U
であることです(ちなみに、これはScalaにおける「メソッド型」の表記法です)。この二つの
メソッドシグニチャ(というより、非ジェネリックメソッドとジェネリックメソッド一般に)には
互換性が無いので、型チェックを通りません。一方、(2)の場合、structural typeによって要求されるシグニチャは
(T)T
になります。ポイントは、(2)の場合、「+そのもの」は多相メソッドではないので、T = Intとしてインスタンス化されている
場合、
(Int)Int
になり、(1)のケースを包含することです。長くなりましたが、一言で理由を述べるなら、「非多相メソッド」と「多相メソッド」の
シグニチャの間には互換性が成立しない、ということが根本的な問題です。
539:デフォルトの名無しさん
11/11/27 13:41:49.74
>>531
ナイトリービルドやRCを使ってるから違うかも。
それからプロジェクトのクリーンで再ビルドすると見えるようになることもある。
540:デフォルトの名無しさん
11/11/27 17:49:58.02
>>518
URLﾘﾝｸ(cl-www.msi.co.jp)
読んでみたらいいよ。
541:デフォルトの名無しさん
11/11/27 21:06:15.99
>>540
もくじ付けて
542:デフォルトの名無しさん
11/11/28 12:21:00.07
Scalaは新しいEJB 2か
URLﾘﾝｸ(www.infoq.com)
543:デフォルトの名無しさん
11/11/28 12:40:50.00
静的型付け言語全体の評価を下げているって部分は論理がよく分からんな。
他はまぁうん、問題提起としてはいいんじゃないかというのが初心者の俺の感想。
544:デフォルトの名無しさん
11/11/28 13:05:42.25
>>543
関数型言語として一番最初にscalaに遭遇すると、型宣言の仰々しさを
一番感じて、敬遠するだろう。これが型システムの複雑さなんだが、
適当な例は少し上の水嶋さんのコメントからも分かるだろう。
この複雑さが初めての人にとって静的型付け関数言語ってと頭の中で
一般化してしまうことがある。（どれだけかわからない。）→静的型
付け関数型はとても複雑で、頭のいい人しかわからない。使えない。
→他人との話題でそんな話になる。→静的型付け関数型の評判が落ち
る。という流れになることを指してる＜その論理。
関数型を学習するのにscalaからはいるのは不適当だとは思うが、ここ
の人の多くは異論を持つだろう。
scalaの作者ってむかしpizzaって言語を作ってたんだね？Haskellの
本を読んで知った。
545:デフォルトの名無しさん
11/11/28 13:44:25.76
いや、ScalaをやるならまずJavaとHaskellをマスターしてから来いと再三言ってるが、実践してる人は少ないだろう
546:デフォルトの名無しさん
11/11/28 13:52:46.07
自分はまずSchemeから入ってOCaml→Haskell・Scalaと流れたから、割とすんなり関数型を理解できたなあ。
強い静的な関数型の入門はOCamlがいいんではなかろうか。
ちなみにJavaは全くできない。
547:デフォルトの名無しさん
11/11/28 20:57:36.17
>>545
そんなこと言ってるから複雑だとかコミュニティがとかになるんだろ
548:デフォルトの名無しさん
11/11/28 21:48:07.58
だからScalaはオブジェクト指向と関数型を掛け合わせたくらいの複雑さはあるし、
関数型を学ぶなら専用の関数型言語で学んだほうがいいって言ってるだけなんだけどな
Scalaの標準ライブラリのソースは関数型っぽく書かれてないしね
549:デフォルトの名無しさん
11/11/28 22:28:09.07
Scalaは新しいEJB 2か
URLﾘﾝｸ(www.infoq.com)
550:デフォルトの名無しさん
11/11/28 22:29:28.20
しつこい
551:デフォルトの名無しさん
11/11/28 23:09:26.99
ここは天丼に行くべきか？
552:デフォルトの名無しさん
11/11/28 23:20:14.59
549
また、いつもの粘着野郎かな？
言語の比較の話はもう飽きた。
そんなことより、おまいら、Scalaで何作る？
553:デフォルトの名無しさん
11/11/28 23:28:09.36
JVMに足りないのはlikeが付いてるあたりか。
groovy(ほか) ←→ clojure
==================
java → C#-like
==================
scala
==================
sml/haskell-like
554:デフォルトの名無しさん
11/11/29 09:11:36.22
>>549
これ読んだら別にscalaじゃなくても
javaのままでいいや
と思ってしまう。
555:デフォルトの名無しさん
11/11/29 10:31:57.57
えーscalaじゃないと思っても、Fantom、Kotlin、Groovy、Ceylonを気になれよｗ、javaでいいのかよ
556:デフォルトの名無しさん
11/11/29 11:27:53.35
>>555
結局商用とかでつかわれない
趣味レベルだし、
やがてjavaでもできるようになる
機能しかもってないから
javaのみに注力すればよいのでは？
557:デフォルトの名無しさん
11/11/29 12:00:34.81
新しいの勉強したくないわーって正直に言えばいいと思う
558:デフォルトの名無しさん
11/11/29 14:26:00.92
>>557
釣りかもしれないけど
勉強したいけど時間を無駄にしたくないだけだよ。優先度を考えてるだけ。
どうせ勉強するなら実用的で
業務にもつかえるものにしたい。
でも既存の技術にしがみつかないで
将来有効な技術なら勉強したい。
1997年くらいにjavaを勉強
しはじめて後悔してない。
Androidの公式開発にもつかえるし
サーバサイトのデファクトだ。
15年後scalaがそのような地位を
気づけているか気にしてるだけだよ。
559:デフォルトの名無しさん
11/11/29 14:31:26.42
釣りかもしれないけどｗ
560:デフォルトの名無しさん
11/11/29 14:43:22.35
558さんの先見性ぱねえっす
561:デフォルトの名無しさん
11/11/29 14:56:59.72
ｿｯｶｰ、さすがに15年後scalaがどうとか誰にもまったくワカンないと思うわー
558さんが15年後でもscalaおｋって感じ取れたらまたこのスレに遊びにきてねー
562:デフォルトの名無しさん
11/11/29 15:39:37.96
基礎と実用ってよくトピックになるが、
実用という言葉ってけっこうマジックだからなぁ。
基礎を強くしようとしてる人は、いわゆる 土方への道は進まなくてもいいけど
基礎がない人は 。。。 ね。この話しとは違うことだけど。
scalaが１５年後どうなるかって？ちょっと考えてみればいいよ。あれだけ、
複雑な仕様だってことを考えると、５年先には別のものがはやってると考
えてしまうよね。今がピークで２，３年で傾くように思うよ。
現に、javavmのライバルは増えてる。
むしろ、変化についていけるようにしておくほうが賢そうに思うけどな。
言語なんて、似たものが増えた所で学習コストは余り変わらないのでね。
Lisp族、CやJava族、ML族 この辺をおさえておいたらどれでもこいにな
れるだろう。
１５年後はまさかのSmalltalkの天下だったりしてな。もともと近未来
志向言語だったからな。
563:デフォルトの名無しさん
11/11/29 15:54:37.55
数ヶ月後、そこにはSmalltalkを勉強する558さんの姿が！
564:デフォルトの名無しさん
11/11/29 16:02:15.66
おれは558ではないが、
おまえら強がってるけど
結局scalaはそのうち廃れるんじゃね？
ってのには反論できねーんだな。
廃れるかもしれないけどそんなの
わかんないじゃんみたいな思考停止が招いた事故
565:デフォルトの名無しさん
11/11/29 16:07:48.72
実用がマジックワードだとしても、LispやMLの仕事なんてほとんどないでしょ
仕事で使えるかもしれない関数型言語というのは大きい
566:デフォルトの名無しさん
11/11/29 16:20:41.01
まあでも実際廃れるかどうかはマジでわからんし562の言うとおりいろんな言語触っとくといいよねってのは同意するよ
その中にscalaも混ぜておくとおもしろいと思うわー
567:デフォルトの名無しさん
11/11/29 16:44:09.05
>>565
それがね。。。基礎云々と言った理由なんだよ。動的の他の言語やるにしても
その他にしても、多くのアイデアや技術は、そこから流れてくるから新言語で
突拍子もなく新しいものを触るより学習を助けるってことからなんだよ。「
あっ、あの考えを使ってるのか。」ってわけ。
多分、scalaを触り続けて、scalaの複雑さに苛立った人が、また別の言語
を作るみたいなながれになるような気もする。scala△ だとか ｗ 出てく
るかも。
scalaはここ２，３年が勝負さ。その間にキラーを作って無いとね。頑張り
なよscalaの諸君！
568:デフォルトの名無しさん
11/11/29 16:52:35.95
>>567
ちょっと何を言ってるのかわからないけど、
Scalaをやってる人が他の言語を知らないという前提なら間違っていると思うが
569:デフォルトの名無しさん
11/11/29 16:58:03.90
まとめるとscala△てことか
570:デフォルトの名無しさん
11/11/29 19:04:55.82
まとめるとscala(笑)ってことか
571:デフォルトの名無しさん
11/11/29 19:12:23.85
興味のある言語を好きなだけ何個でも弄ればいいじゃん
572:デフォルトの名無しさん
11/11/29 19:15:20.25
Scala ▼0.13%
573:デフォルトの名無しさん
11/11/29 19:17:49.27
なんか新しい言語でまわりを出し抜いてみたかったんだよ。
変身願望なのかな、これって。
574:デフォルトの名無しさん
11/11/29 20:42:35.54
正直「仕事で使えるかもしれない（静的型付けの）関数型言語」という点でScalaには期待してる
もっとJavaっぽい言語に偽装して騙す感じでマーケティングして欲しい
575:デフォルトの名無しさん
11/11/29 21:44:17.15
スレのメイン話題で盛り上がっているところで流れをぶった切ってスマン。
>>538
(T)T が (Int)Int を包含するのは異論なし。
しかし、[U >: T](U)U が (Int)Int を包含しないのは納得いかない。
> 長くなりましたが、一言で理由を述べるなら、「非多相メソッド」と「多相
> メソッド」のシグニチャの間には互換性が成立しない、ということが根本的
> な問題です。
(T)T と [U >: T](U)U が互換性が無いのも異論なし。
だって [U >: T](U)U ⊇ (T)T なのは自明だから。
んで、(T)T ⊇ Int(Int) なのだから、
[U >: T](U)U ⊇ (T)T ⊇ Int(Int) になるよね。
だから、[U >: T](U)U は (Int)Int を包含するじゃん？
あと、もう一度聞くけど、>>535の(2)と(3)はそれで正しい？
大文字のXが未定義とか、Uが[]の中に含まれていないとか、
Scalaは+メソッドに交換法則を強制していないから
def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y
の方が一般的とか、気になる点が3点もあるんだけれど。
576:デフォルトの名無しさん
11/11/29 22:28:34.02
>575のような礼儀知らずに真摯に答え続ける水嶋さんを尊敬
577:デフォルトの名無しさん
11/11/29 23:08:12.48
そう思っているのはあなただけだよ
水嶋さんはこういうネチネチした議論大好物だよ
578:デフォルトの名無しさん
11/11/30 00:06:09.22
議論って本来、ねちっこさはあるよ。
それを避けて陰口を叩くだけの人多いけどな。
579: ◆CgacaMDhSQ
11/11/30 00:16:45.87
>>575
疑問にお答えする前に、まずは私のミスについて訂正を
> 大文字のXが未定義とか、Uが[]の中に含まれていないとか、
これは自分の単純ミスですね。確認が不足していて申し訳ないです。
正しくは、
(2) def f2[T <: { def +(other: T): T }](x: T, y: T): T = x + y
(3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: T) = x + y
です。ご指摘ありがとうございます((2)は、そもそも現在のscalaではどの道コンパイルを通らないですが)。
> (T)T と [U >: T](U)U が互換性が無いのも異論なし。
> だって [U >: T](U)U ⊇ (T)T なのは自明だから。
「 [U >: T](U)U ⊇ (T)T」という前提に問題があります。これは全く自明では無いどころか、
「 [U >: T](U)U ⊇ (T)T」は一般に成立しません。ここで、TがUと同様に多相的っぽく見えるから
話がややこしくなるので、T に Int を代入して(インスタンス化して)考えてみます。すると、
[U >: Int](U)U ⊇ (Int)Int が成り立つか、という話になります(Uはメソッド適用までインスタンス
化されない点が重要です)。で、おそらくおわかりかと思うのですが、これは成り立ちません
(リスコフの置換原則を思い出してください)。というわけで、それを前提にした
> だから、[U >: T](U)U は (Int)Int を包含するじゃん？
という結論も正しくありません。とりあえず、また疑問があれば言ってくださればと思います。
なお、
> def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y
の方が一般的というのは、技術的に誤りです。説明が若干ややこしいので、
一般的だと考えられた根拠を述べていただけると解説しやすくなります。
580:デフォルトの名無しさん
11/11/30 00:18:14.17
この兄ちゃんもよくやるなあ
581: ◆CgacaMDhSQ
11/11/30 00:19:38.14
>>576
そのように評価していただけるのはありがたいのですが、真実は
>>577が近いです。ねちっこいかどうかはともかく、技術的な議論自体が好物なのは確かなので。
ちなみに、あえて訂正しなかったのですが、s/嶋/島/です。いや、別に不快なわけではないのすが。
582:デフォルトの名無しさん
11/11/30 00:51:28.65
◆CgacaMDhSQ 氏は、せっかく能力あるんだから、もっと他のことに使ってほしいなあ。
とりあえず、10月ころのScalaのアップデートのスライドをたまたまWebで見たけど、
あれ、なかなか良かったです。
結局、プログラム言語の良し悪しは、どんだけその言語を使う人が居るか、プログラマーの数って重要だと思う。
プログラマーが増えるには、最近では、ライブラリーとか使用例とか、ググったらやりたいことが見つかるか
とかそういうのが重要。
Scalaでググると、言語の話ばっかりなのが、最近、飽き飽きしてきた。
Scalaは、まだまだ基本ライブラリが足りないよね。。
ちょっと今、CSVからデータ抜き出す方法をしらべてて、
たまたま次のページ見たのだけど、RubyやGroobyに比べて、ちょっと面倒なのが残念。
URLﾘﾝｸ(d.hatena.ne.jp)
583: ◆CgacaMDhSQ
11/11/30 01:09:06.42
>>582
> あれ、なかなか良かったです。
関数プログラミングの集いの時のやつでしょうか？そう言っていただけるとありがたいです。
> Scalaでググると、言語の話ばっかり
海外を見渡すと、色々新しいフレームワークの話とか話題になってたりするんですが、国内だと
まだ言語の話が多いですね…
> プログラマーが増えるには、最近では、ライブラリーとか使用例とか、ググったらやりたいことが見つかるか
> とかそういうのが重要。
> (snip)
> Scalaは、まだまだ基本ライブラリが足りないよね。。
賛成です。Scalaは、標準ライブラリがあまりにも偏っている点が「実用的な」問題だと考えています。
# 特に、よく書いてますが、腐ったscala.ioはなんとかならないものかと思っています。Scala-IOは
# いつ取り込まれるのかわからんですし…
で、(本家) Scalaのコミュニティの問題の一つは、そういう実用的なライブラリを標準に取り込む動きが
遅い点にあるのではないかと。言語としてはともかく、そういう標準ライブラリの取り込みに
関してはGroovyの方が先に行っている印象です。
584:デフォルトの名無しさん
11/11/30 01:40:10.27
Iterator.continuallyを見て、便利だと思うか、面倒だと思うかでScalaを使う資質が分かれると思うね
585:デフォルトの名無しさん
11/11/30 02:21:38.85
15年後も、なんていってたら情報系黒板言語しか選択肢がないぞw
もっとも、最近のMITのオープンクラスを眺めてみれば、
RoRを使ってウェブアプリ作る講義があったりで、
黒板に書かれる言語すらも徐々に変化しているみたいだわ
ソフトウェアに永遠の命なんて戯けたことを抜かすなら、
FSFの信仰者になってGPLでソフトウェアを配布するしかないぞ
586:デフォルトの名無しさん
11/11/30 02:32:51.75
MITでRailsやってんの？イメージに合わない…
587:デフォルトの名無しさん
11/11/30 02:35:24.42
寿命だけで言えばプログラミング言語なんてめちゃくちゃ寿命長いからね
ScalaよりJVMの寿命を心配したほうが良さそうだ
588:デフォルトの名無しさん
11/11/30 12:38:13.26
>>587
Delphiの寿命は長かったといえる？
589:デフォルトの名無しさん
11/11/30 16:28:59.72
Yammer.comがScalaからJavaに戻したそうな。
理由とかはまだ調べられてないけど。
590:デフォルトの名無しさん
11/11/30 16:41:26.98
URLﾘﾝｸ(codahale.com)
591: ◆CgacaMDhSQ
11/11/30 18:32:48.66
>>589
>>590のURLと一緒に、その背景
URLﾘﾝｸ(codahale.com)
も読むといいかもです。わかりやすいように時系列で整理すると、
(1) Yammerのエンジニアの人(@coda)が、昔の同僚(Twitter時代)に、Scalaの一部をJavaに置き換えてるとメンション飛ばす
(2) それを見た Donald Fischer (現Typesafe CEO。 Odersky先生は現在チーフアーキテクト) が、数日語、@codaに、詳細を聞きたい
旨のメール出す(CCにOdersky先生が入っていた)
(3) @codaは、Scalaの改善に関われる中心的な人物がそういうメールを送ってきた、ということで、Scalaの経験からどんな問題があった
かを Donald Fischer にリプライ(CC: Odersky)。このやり取りはprivateなものだった。
(4) @codaは、e-mailのドラフトをgistに置いていたので、それがHacker NewsやTwitterに流出
(5) しまった、と気づいた@codaがあわててgistを削除するも時既に遅く、publicに
(6) @jodastephen はそれが流出したものだという事を知らずにYammerが公式にアナウンスしたとブログに掲載
(7) @coda -> @jodastephen 「ちょw それ、Yammerの公式アナウンスじゃなくて、それ、俺の個人的見解だから」
(8) @jodastephen のポストの影響でTwitterなどあちこちでその話が飛び交う
(9) @code が URLﾘﾝｸ(codahale.com) のコンテキストを釈明 (イマココ)
592: ◆CgacaMDhSQ
11/11/30 18:46:29.97
まあ、流出情報ということはともかく、 URLﾘﾝｸ(codahale.com)
に書かれている事自体は(書かれたコンテキストを踏まえる必要があるにせよ) @jodastephen
の記事とは異なり、読む価値があると思います。私が彼のメールで特に重要だと思ったのは
(a) Scalaの学習曲線の問題(特に、チームメンバにどうやってScalaのコンセプトを教育するか)
(b) sbt 0.7系 -> sbt 0.10移行に伴う問題
(b) Scalaのバージョン間のバイナリ非互換性問題
辺りでしょうか。彼自身がそれほど重要な問題ではない、と書いている通り、scala.collection.{mutable, immutable}
がどうとかの話は、まあパフォーマンス特性を踏まえてコレクションを使いましょうね、という話で、場合によっては
彼の書いたような指針に従ってチューニングするのもありかもしれませんが、Scalaに関する一般論としてはあまり
重要ではないでしょう。
ただ、私も原文読んだ中から、特に重要だと思った部分を抜き出しただけなので、実際の所は原文読んだ方がよかろうと思います。