5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2010/06/07(月) 15:26:14
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 3冊目
http://pc12.2ch.net/test/read.cgi/tech/1261779856/

2 :デフォルトの名無しさん:2010/06/07(月) 15:28:02
・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 :デフォルトの名無しさん:2010/06/08(火) 21:43:02
>>1


4 :デフォルトの名無しさん:2010/06/10(木) 19:40:27
ほしゅ

5 :デフォルトの名無しさん:2010/06/11(金) 13:35:11
ほしゅ ほしゅ

6 :デフォルトの名無しさん:2010/06/11(金) 15:37:49
前スレの >> 943
CodeZineの記事の著者です。

> e.getProperty("user")では空文字列が返り、
> e.getProperty("members")ではNullが返ってきてしまう理由がよくわからないのですが、
> これはなぜなのでしょうか?
> [User]と[JList[User]]の違いなのか、それとももしかするとapp engine sdkの仕様なのでしょうか。

その通りで、"members"プロパティはListPropertyと呼ばれるもので、
keyに対してのvalueが一件もない場合はnullが返るのがLowLeveAPIの仕様です。
本来はList[User]()が返ってきて欲しいし、
そのようにimplcit conversionできればいいんですが、
ジェネリックスの仕様的に無理なんでnullチェックするしかないです。

記事のコードでそのへんのチェックが抜けていたのは
完全なバグですのであとで直します。



7 :sage:2010/06/11(金) 15:39:17
あと、LiftをREPL環境で動かすには、
LiftConsoleってのがあってそいつが便利です。

mvn scala:console
でmavenからREPLを起動した後に、

(new bootstrap.liftweb.Boot).boot

とREPLに入力することでLiftのBootStrapが読み込まれて、
Modelなんかにアクセスできるようになります。
GAE環境ではSDKがサポートするローカル環境をエミュレートする必要があるため、
LowLevelAPIを利用したModelはさわれませんが。
このへんは、Slim3とかことーじゃを参考にすればなんとかなるかな、
とは思ってますが手をつけてません。

最近はあまりLift追ってない。。。

8 :デフォルトの名無しさん:2010/06/11(金) 15:40:39
sageまちがえたorz


9 :デフォルトの名無しさん:2010/06/12(土) 00:30:43
どんまい‼

10 :デフォルトの名無しさん:2010/06/12(土) 01:15:34
http://tryhaskell.org/
http://tryruby.org/
http://www.tryerlang.org/

Scala はこういうの無いん?

11 :デフォルトの名無しさん:2010/06/12(土) 08:44:55
http://www.simplyscala.com/

12 :デフォルトの名無しさん:2010/06/12(土) 21:53:38
ボクらのScala ~ 次世代Java徹底入門 浅海 智晴 (単行本 - 2010/6/25)

って、どうだろう?

別にお金出して買うのに抵抗はないけど、
部屋の本棚がオーバーフローしているので、本買うのは躊躇してしまう。。

13 :デフォルトの名無しさん:2010/06/12(土) 21:56:16
次世代Javaって

14 :デフォルトの名無しさん:2010/06/12(土) 21:59:27
>>11
さんきゅ

15 :デフォルトの名無しさん:2010/06/12(土) 22:33:38
>>12
タイトルが釣りすぎる

16 :デフォルトの名無しさん:2010/06/12(土) 22:41:42
Relaxerの人か
著者は悪くないね

17 :前スレの943:2010/06/12(土) 23:29:00
おおお、yuroyoroさんご本人ですか!レスありがとうございます!
twitterでフォローさせてもらってますw

>>keyに対してのvalueが一件もない場合はnullが返るのがLowLeveAPIの仕様です。
やはりそうなんですね。
自分はまず前編を拝見させて頂いて、そのアプリでブラウザから操作をしてみて、
そのあと後編のソースコードを上書きしたんです。
前編でmembersプロパティがないeventエンティティをデータストアしてしまったので、
後編のソースコードに上書きしたらnullエラーが出るようになってしまっていたのでした。
途中ででそれに気づいてDBからデータを全部消したら後編のプロジェクトもうまく動くようになって、
それで今いろいろ勉強させて頂いているところです。

ちょうどScalaでGAEアプリを作ってみたいと思っていたところでyuroyoroさんの記事に出会い、
とてもラッキーでした。
とてもためになる記事を書いていただきまして、本当にありがとうございます。

18 :デフォルトの名無しさん:2010/06/12(土) 23:33:12
せめて
次世代Java系スクリプト徹底入門
じゃないかと思うぜ


19 :デフォルトの名無しさん:2010/06/13(日) 01:27:34
>>12
「次世代Java徹底入門」はかなり気が早いですね。
でもGroovyより速いペースで普及しているから
数年後には現実が本のタイトルに追いつくかもしれません。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Java
http://www.indeed.com/jobtrends?q=Scala,Groovy

>18
「次世代Java系スクリプト徹底入門」は問題外だと思います。
GroovyがJava系スクリプト言語とされるのは言語仕様に動的型付けを含むからです。
Scalaは型推論を取り込んだ静的型付け言語です。
Javaがスクリプト言語ではないように、Scalaもスクリプト言語ではありません。

20 :デフォルトの名無しさん:2010/06/13(日) 01:38:49
動的型付だからスクリプト言語じゃないってのも違うような

21 :デフォルトの名無しさん:2010/06/13(日) 01:40:37
動的じゃないや静的

インタプリタ的(ソースそのまま)に動かせるかどうかって所だと思うわスクリプトか否かって

22 :デフォルトの名無しさん:2010/06/13(日) 02:10:55
明確な定義ないしどうでもいい

23 :デフォルトの名無しさん:2010/06/13(日) 12:47:53
<-
の代わりに

が使えるけどみんな使ってる?

24 :デフォルトの名無しさん:2010/06/13(日) 13:27:29
>>23

使ってないな。そうでなくてもたくさん矢印あるんだから、意味が一緒ならこれ以上増やすなと言いたい。
いわゆる全角ってのも受け付けない。

25 :デフォルトの名無しさん:2010/06/13(日) 19:27:46
http://demo.liftweb.net/count


object CountHolder extends SessionVar[HashMap[String, Int]](new HashMap[String, Int] {
override def default(key: String): Int = 0
})
の文法についてなんですが、
new HashMap[String, Int] のあとにある 
{
override def default(key: String): Int = 0
}
って、なんなのでしょう?
これはHashMapクラスの default メソッドをオーバーライドしてるって理解で
いいんでしょうか?
[String, Int]のあとの
{
}
がよくわからないです。new したあとにクラスのメソッドをオーバーライドできる?
のでしょうか?

26 :デフォルトの名無しさん:2010/06/13(日) 19:59:05
>>25

Javaの無名クラスと同じ。継承とインスタンス作成を同時におこなってる。
その場でHashMapのdefaultメソッドをoverrideしたクラスを定義してる。

(なおかつ、それをSessionVarのコンストラクタに渡し、さらにそれを継承したCountHolderというobjectを定義してる)


27 :デフォルトの名無しさん:2010/06/14(月) 07:03:01
>12
そのうち、Scala自体が、Java好きな人達に叩かれるようになるんじゃないだろか。

28 :デフォルトの名無しさん:2010/06/14(月) 13:41:27
>>27
でも、Scalaの周辺環境やツール類の問題(ビルドが遅いとか、IDEがJavaに比べて未成熟だとか)は
ともかくとして、言語としてのJavaがScalaに勝ってる箇所って無いに等しいから叩くにしても
言語仕様が複雑過ぎる〜とかそういうのになりそうな気がする

29 :デフォルトの名無しさん:2010/06/14(月) 14:09:03
一番重要な実行速度はJavaが上だろ

30 :デフォルトの名無しさん:2010/06/14(月) 14:46:36
実際の使用に差出るほどの影響はないんじゃないの。

31 :デフォルトの名無しさん:2010/06/14(月) 18:34:27
なんでそう思う?

32 :デフォルトの名無しさん:2010/06/14(月) 18:51:10
むしろ遅い方の実測値を出せ

33 :デフォルトの名無しさん:2010/06/14(月) 21:52:46
なんともいえないけど、前より差が減った気がする。

64bit クワッドコア http://shootout.alioth.debian.org/u64q/scala.php
64bit シングルコア http://shootout.alioth.debian.org/u64/scala.php
Scala compiler version 2.7.7.final
jdk1.6.0_18


ところで、Actorsの競争はどうなってんだ。ベンチマークするのめんどい・・・
http://www.slideshare.net/jboner/akka-simpler-scalability-faulttolerance-concurrency-remoting-through-actors
http://www.malhar.net/sriram/talks/kilim-google.pdf
http://www.slideshare.net/VaclavPech/concurrency-on-the-jvm

34 :デフォルトの名無しさん:2010/06/14(月) 21:56:48
Actor Frameworks for the JVM Platform: A Comparative Analysis
http://osl.cs.uiuc.edu/docs/pppj09/paper.pdf
一年前なのにもう古くなってるんだよな。

35 :デフォルトの名無しさん:2010/06/14(月) 22:14:16
Actorの共有資源に対する制御はどうしてるの?

36 :デフォルトの名無しさん:2010/06/14(月) 22:17:46
Javaと比較すると意外にコード量も実行速度も変わらないみたいだな
http://shootout.alioth.debian.org/u64q/scala.php

コード量は若干少なくなるけど、実行速度は若干遅くなるって所か

37 :デフォルトの名無しさん:2010/06/14(月) 22:20:31
Javaと比べてコード量が変わらないっておかしくね?
計算アルゴリズム書くだけのベンチ?


38 :デフォルトの名無しさん:2010/06/14(月) 22:21:06
そんなにおかしくもないだろ別に

39 :デフォルトの名無しさん:2010/06/14(月) 22:23:04
入門書なんかは決定的にコードが減るパターンをセンセーショナルに取り上げてたりするからねぇ。
実際は書き方が変わるだけで、一つ一つのロジックレベルでは、
決定的にコード量が減るってもんでも無いと思う。
小さな積み重ねをすると、総合的に目に見えて分量が減るのは確かだけど。

40 :デフォルトの名無しさん:2010/06/15(火) 03:12:29
一般論としては、数値計算系のベンチマークだとあまり言語による
コード量の差が出にくい。つーのは、よく知られたアルゴリズムが
既存の手続き型言語用のものだったりするので、それをベタ移植しても
あまりコード量が変わらないという…。あと、あまり数値計算系で
扱うデータ構造ってあまり複雑じゃないんで、高階関数とかの出番が
少ないんだよな…。一方、コンパイラとか言語処理系みたいな、複雑な
データ構造をいじりいまわすプログラムだと滅茶苦茶差が出る。

あと、shootoutのプログラムコード見るとわかるんだけど、全然Scala
っぽくなくて、ほとんどJavaみたいなコードが結構ある。Javaっぽい
書き方した場合、型宣言+αくらいしかコード量が減らない代わりに
実行速度もほとんど変わらないから、まあ納得の結果だなあと。

41 :デフォルトの名無しさん:2010/06/15(火) 20:09:27
普段はScalaが遅いとは感じないけど
Eclipseでデバッグ実行すると異様に重く感じる。

42 :デフォルトの名無しさん:2010/06/15(火) 21:24:25
そりゃ普段は遅くは感じないと思うよ
単に素のJavaの方が速いってだけの話で

43 :デフォルトの名無しさん:2010/06/15(火) 22:36:31
>>41
単にEclipseのScalaプラグインが重いとかその辺りだろう

>>42
なんでそうなる?
scalacがコンパイルしたコードを逆アセンブル or 逆コンパイル
してみりゃわかるが、原理的にほぼjavaと同等の速度が出るようになってるよ
Javaの方が速いってのは単なる先入観だ

違いが出るのは、暗黙型変換使いまくったり、高階関数使い
まくったりした場合だな。特に2.7だとspecializationが無いせいで
プリミティブ型のboxingでアロケーションが多発するので遅くなる。

44 :デフォルトの名無しさん:2010/06/15(火) 22:40:13
要するに違いが出るんだろ

45 :デフォルトの名無しさん:2010/06/15(火) 22:50:07
>>44
書き方に依存するって言ってる。
基本的にはJVMの上で動く以上、Javaと同じように書けば、同じような速度が出るし、実際そのようなコード
は書ける。Scalaっぽいコードっつうか、関数型プログラミングスタイルで書いた場合は、JVMの上だとどうしても
パフォーマンスが劣る傾向があるので、性能と簡潔さをトレードする感じになる。でまあ、もちろん0か1かの二択
じゃなくて、基本的には関数型で書きつつ、チューンしたい部分をJavaっぽく書くとかそういうこともできるわけ

46 :デフォルトの名無しさん:2010/06/15(火) 23:55:01
やっぱ関数型的に綺麗に書くと遅くなるもんなのか

47 :デフォルトの名無しさん:2010/06/16(水) 01:12:11
JVM上で動いてかつJavaとの互換性を高いレベルに保つってことで
一般の関数型言語ではやれる最適化手法の一部は使えなかったりするだろうし

48 :デフォルトの名無しさん:2010/06/16(水) 01:24:17
>>45
要するに素のJavaの実行速度は超えることが出来ないんだからJavaよりは遅いで間違ってないだろ

49 :デフォルトの名無しさん:2010/06/16(水) 03:04:07
>>48
え?
Javaと同じかそれより遅い、なら真だけど
Javaよりは遅い、は偽でしょ
Javaの速度≧Scalaの速度(実はこれも語弊があるけど。
JavaでScalaみたいに関数型プログラミングをやると同様に遅くなるはず
なので) ⇒ Javaの速度>Scalaの速度
って意味不明だろ

50 :デフォルトの名無しさん:2010/06/16(水) 03:08:21
厳密に言うとJavaと等価にはなりえんだろう。

51 :デフォルトの名無しさん:2010/06/16(水) 03:13:23
>>50
等価ってのが何を意味するかにもよるが
Javaっぽく、というか副作用を駆使すればJavaと同じ(これは
*誇張ではなく*ほぼ同じ)速度が出るって点には納得してもらえてる?
もしそうなら、Javaより遅いってのは論理的に明らかにおかしいのが
わかると思うのだけど…。

52 :デフォルトの名無しさん:2010/06/16(水) 03:13:48
ほぼ同じ=同じ
ではないんじゃね?

53 :デフォルトの名無しさん:2010/06/16(水) 03:17:40
Scalaを好意的に見たいってのは解るんだけど、
現実を見ると、どんだけ厳密に最適化したところで、最高はJavaと等価が限界で、
Javaの実行速度を越えることはできなんだし、
Javaと同じ速度が出る場面なんて殆ど無いんだから、
Javaと同じ速度が出るって公言していい訳じゃないと思う。

54 :デフォルトの名無しさん:2010/06/16(水) 07:19:35
今時、言語の速度だけ語ってもしゃーなくない?

Javaより生産性が高くて、Javaに近い実行速度ができて、
生産性の高さのメリットがその実行速度の差のデメリットを埋めることができればいい、くらいで

ま、そんなの用途や既存や手持ちのライブラリにもよるんだけど、
Ruby(Rails)が一部で使われているのはそういうのが理由でしょ。
でないと、あんな動作速度でいえば最悪級(失礼)な言語誰もつかわないでしょ。


どうでもいいが、JRubyなんてさ実行速度はRuby並だわ、
起動の遅さはJava並、動かないRubyのライブラリあるわ散々でまさに誰得言語だと思わんかね・・・

その点、Scalaはいい線だと思う



55 :デフォルトの名無しさん:2010/06/16(水) 08:31:32
>>52
「ほぼ同じ」ってのが、「ちょっと負けてるけど、比較できるくらい速い」
というニュアンスで受け取られたんだったら、それは俺の書き方が悪かった
「ほぼ同じ」っていったのは、Javaっぽく書いた場合でも、scalacが完全に
javacと同じバイトコード出すわけじゃない(命令列の配置が少し違う)から、
厳密な書き方しただけで、実用上は「同じ速度」と言ってもいい。

>>53
いやいや、まだ理解されてないのかもだけど、わざわざ頑張って
しなくても、Javaっぽいスタイルで書くだけでJavaと同じ速度出るんだってば
で、現実にJavaと同じ実行速度が出る場面なんてほとんど無いとか、測定
したことも無い(だろうと思われる)のになんで語れる?
実測値示してみせりゃ納得するのだろうか?
好意的に見たいとかそういう問題じゃなくて、単純に事実の話だよ

56 :55:2010/06/16(水) 08:55:40
つーか、Scalaの速度について、Javaより遅いけど頑張って最適化すれば
Javaに近いくらいの速度が出るくらいの受け取り方する人って意外に多い
ことに驚いた。

たとえば、今Java 7に入る入らないでもめてるクロージャあるよね。
あれ多用したコードの性能は、ほとんど間違いなくScalaで高階関数を
多用したときと同じように落ちると思われるんだが、そうなったとき、
Java 7以前の速度は、Java 7よりも速いと言うのは正しいの?
自分が言っているのはそういうレベルの話。

ふつーにループ構文(whileとか)とJavaのAPI使って書けば性能はJavaと
同じだし、Scalaっぽく書けばより遅くなるというだけの話なんだけどなあ。
もちろん、Scalaがややこしい作業を色々肩代わりしてくれるおかげで、
つい、Javaよりも気楽に遅いコードを書いちゃうというのはあるんだけど、
それって言語処理系の速度評価とは独立な問題だよね

57 :デフォルトの名無しさん:2010/06/16(水) 10:51:06
なんで全てのパターン試してきたら同じ速度出たのを検証したみたいな断言するのか解らん
そんな簡単に最適化できるわけでもなかろうに

58 :デフォルトの名無しさん:2010/06/16(水) 10:53:17
同等可否レベルのパフォーマンスの話はバイトコードで語れっての。

59 :デフォルトの名無しさん:2010/06/16(水) 10:57:42
普通にScalaっぽく書いたら速度差出るなら、
それは等速とは言わないよね。
Javaっぽく書いて最適化すれば等速出るって言われても、
もはやそれはJavaじゃん。

60 :55:2010/06/16(水) 13:51:57
>>57
いや、全パターン試すまでもわかることもある。

Scalaのwhile --> ジャンプ文(goto,ifeqなど)
Scalaのif --> 条件分岐命令(if_icmpeq,ifeqなど)
Scalaのmatch --> 対象が整数でcaseの値が定数の場合はlookupswitchなど専用命令を使用。
        それ以外の場合、if(...) ... else if(...) ...相当のコードを吐く。
Scalaのtry-catch --> メソッドの例外テーブルに情報を書き込む(Javaと同じ)
Scalaのthrow --> athrow命令
Scalaのメソッド呼び出し --> 単なるメソッド呼び出し命令(invokevirtual,invokestaticなど)
Scalaのオブジェクトの生成 --> new+invokespecial
Scalaのプリミティブ型(AnyVal)のメソッド呼び出し --> JVMのプリミティブ型に対する演算命令(iadd,imulなど)
Scalaの配列に対する演算 --> JVMの配列型に対する演算命令 --> (aaloadなど)
Scalaのclass,trait --> JVMのクラスファイル (ただし、traitが実装を持っている場合除く)


全部列挙するのは面倒なので避けるけど、こんな調子で、基本的にJavaと同じ
ような演算は同じ命令にマップされるので、Javaと同じように書いた場合には、
同じような速度が出る(いくつか例外はあるが…)。これは憶測じゃなくて、
自分で今までに色々なコードパターンに対してscalacした結果を逆アセンブル
した結果。別にユーザが「最適化」とか考える必要は基本的にはなく、単に
Scalaの暗黙型変換とか高階関数とか多用しなければ同じくらいの速度が出る
ようになってる。

ちなみに、こちらの方がまだ検証してなくて憶測になるのだけど、2.8.0.RC2
以降でジェネリクス使ったコードだと、specializeアノテーションでboxingの
コストが減らせる分、Scalaの方が速くなるケースもあるかも。


61 :55:2010/06/16(水) 13:57:07
>>59
事実関係についてはおおむね同意してもらえたとして、そこまで来ると
もはや見解の相違としか。一応言っておくと、ScalaでJavaっぽく書くことは
特に努力が必要な作業でもないよ。ふつーにScalaの基本構文を使って書く
だけ。暗黙型変換使うなとか使う機能に関して縛りは出るけど、特にScalaを
熟知していないとできない作業でもない。

ただまあ、

・Javaっぽく書くこと自体は特に難しくないこと
・そのようにして書かれたコードはJavaと同等の速度が出ること

に納得してもらえたなら、それ以上、特に等速という言葉を使うことに
こだわりは無い。単に、「性能の上限はJavaと同じくらいだけど、それを
達成するためには頑張ってチューンしなければならない」みたいな認識が
広まるのが嫌なだけなので。

62 :デフォルトの名無しさん:2010/06/16(水) 15:12:58
リスト+mapやforを使ったコードもただのループになったりすればいいのに。

63 :デフォルトの名無しさん:2010/06/16(水) 15:49:30
>>61
いやだからそれってもはやJavaじゃん

64 :55:2010/06/16(水) 16:08:14
>>63
そうとも言えない。
・型推論があるおかげで型を書く必要がある箇所がJavaに比べてかなり減る
・型の別名付けがあるおかげで、ジェネリクスを使ったコードがJavaに
比べて楽に書ける
・case classなどのおかげで、クラスの作成がJavaに比べて楽
・どこでもimport
・末尾再帰の最適化
・メソッド内メソッド
・パターンマッチ

などなど。これらの性能にあまり影響しない特徴を使うだけでも、
コードを書くのはJavaに比べて楽だよ。

65 :デフォルトの名無しさん:2010/06/16(水) 16:21:18
んでそれで書くと等速になるって実際に確かめたの?

66 :デフォルトの名無しさん:2010/06/16(水) 16:35:16
>>62
ただのループに変換するにはクラスを合成する必要があるから
クラス単位でコンパイルするScalaコンパイラでは難しいでしょうね。

Javaにクロージャが追加されたらJVMがクロージャを
ただのループに最適化するようになるかもしれません。
そうなればScalaの高階関数も同様に最適化されるだろうから
Scalaっぽく書いたScalaコードもJavaっぽく書いた場合と
同等の速度がでるようになると考えられます。
Javaにクロージャが追加されるのを期待しましょう。

>>65
>>55が何を実際に確かめたのかは>>60に書いてあるのでは?

67 :55:2010/06/16(水) 16:38:57
>>65
あらゆるコードで、とは言わないけど、典型的なコードパターン
では結構試したかな。つか、さっきも書いたけど、Java的なコードは
Java的にコンパイルされるので、全部確かめる必要も無い。

あとは、>>36のリンク先の、regex-dna,n-body,binary-trees,fannkuch-redux
辺りのコードが参考になるかな。 Javaと同じような書き方してる
ベンチマークはほとんど同じ結果になってる。ちなみに、大きく差が出てる
k-nucleotideなんかはJava版とScala版でやり方が大きく異なってる点に注意ね。

68 :デフォルトの名無しさん:2010/06/16(水) 16:42:11
机上の空論で議論しても仕方ない。
殆ど同じ、じゃなくて完全に同じかどうか聞かれてるんでしょ?

69 :デフォルトの名無しさん:2010/06/16(水) 16:49:05
みんなtwitterのクジラは見たくないんだよ

70 :デフォルトの名無しさん:2010/06/16(水) 16:51:27
全か無かでしか思考出来ないのは、認知のゆがみの典型的パターン。

71 :55:2010/06/16(水) 16:56:16
>>68
んな自明なこと聞かれてたの?
完全に同じなんてことは、scalacがjavacのforkでも無い限り(
というかforkであっても「完全に同じ」なんてことはまず無いが)
ありえないってことは議論するまでも無く明らかだと思うのだけど。

俺は実際のコードでほぼ同じであることを説明すれば十分だと考えた
ので、scalaのコードがどういうバイトコードにコンパイルされるか、
や、shootoutのコードを示したわけなんだが、あとは何があればいいの?

72 :デフォルトの名無しさん:2010/06/16(水) 17:03:47
素のJavaよりも速いのか、遅いのか、全く同じなのか、ってことでしょ?
ちょっとでも遅いのなら、Javaと等速っていうのは過剰評価じゃね?ってことだよ
細かな速度は重要じゃないって言ってる人が、何故か一番Javaと
等速であることに拘ってるよね

73 :デフォルトの名無しさん:2010/06/16(水) 17:12:25
>>55
実行速度に関する情報提供ありがとうございました。
大変参考になりました。

74 :デフォルトの名無しさん:2010/06/16(水) 17:15:45
ベンチマーク的な事じゃなくて、実際に実務でどうなるのかが唯一重要な希ガス

75 :デフォルトの名無しさん:2010/06/16(水) 17:17:33
速度なんて関係ねーよとは言いつつ、殆どの人がこだわるのが速度だからねぇ
Rubyの人を除く

76 :デフォルトの名無しさん:2010/06/16(水) 17:35:30
さすがAKB大好きなだけありますね。

77 :55:2010/06/16(水) 18:36:36
>>72
いや、だからその三択がおかしいんだってば。
「全く同じ」なんて言い方するなら、Javaと全く同じ速度が
出るのはJavaそれ自身しか現実的にありえないんだから、無意味
だよ(どんな入力に対してもjavacと「全く同じ」出力を出す
コンパイラなんて現実的に無理だし)
それと細かな速度が重要なんて一言も言ってないんだが…
単に、「Javaと全く同じ」なんて言明は無意味だからそんな
言い方はしないだけのこと。

もう一度言うけど、「Javaと等速」ってのは過剰評価でもなんでもない。
shootoutでも、Javaぽく書かれたコードは、Javaとの性能差はほとんど
誤差みたいなもので、Scalaが勝ってるベンチマークすらある。
つーか、実際にScalaでJavaっぽく書かれたコードで、Javaより有意に
遅くなるケース示してくれんと、もはや悪魔の証明を要求されてるような
もんでどうしようもないんだが…。Javaっぽくってのは、高階関数の
代わりにwhileループやvarを多用したコード程度の意味ね。

>>74
実務に関しては、答えは簡単で、典型的なScalaっぽく書かれたコードは、
典型的なJavaコードより遅い(どの程度遅いかは問題によるが)。ただ、
Scalaは静的型付け言語だけあって、それでも動的型付け系のスクリプト
言語よりは速い。あと、Scalaっぽさを捨てていいならJavaと同じ速度が
出るようにするのは難しくない。

78 :55:2010/06/16(水) 18:40:48
つけくわえておくと、ほぼ同じって言葉の意図は、Javaに近いけど、ちょっと
遅い、じゃないからね。Javaっぽく書いたScalaのコードとJavaのコードの
速度差はほとんど誤差のレベルだから優劣を比較するのが難しいってこと。

79 :デフォルトの名無しさん:2010/06/16(水) 19:04:50
そういう事じゃないのでは

80 :デフォルトの名無しさん:2010/06/16(水) 22:44:10
だいたいJavaっていってもVMのバージョンやベンダによって全然違うわけだが
ある程度近いなら同じって言い切って構わないよ

81 :デフォルトの名無しさん:2010/06/16(水) 22:46:36
なんか良く分からんが、
・C++は遅いから禁止。 Cで書け!
・ハードェアを叩きたかったら、既存のドライバ使うな!ドライバは自分で書け!
・OSなんか使うなよ。そんなのを介すると当然遅くなる。
・可能だったらアセンブラで書け!Cだと遅いからな。
という話と同じだな。
組み込みの分野では、未だにそういうプログラミングやるよ。

で、数年前、C++はCより速度が劣るからダメ!と拒否しまくっていた人が居た。
まさにデジャブだね。

最近は組み込みでもC++で書くことも多くなってきている。
当然、C++っぽい書き方をしまくるとCより遅くなるのだが、
速度よりも分かりやすさ優先な場合は、そういう書き方しても全然問題でない。


要するに頭を使って適材適所でプログラミングすれば、
組み込みの現場でも CとC++の速度は同等だし、かつ、C++は便利といえるんだよ。


82 :デフォルトの名無しさん:2010/06/16(水) 22:47:00
ScalaコードをJavaにトランスコードすればいいんだよ。 javapを応用すれば出来るでしょ?

83 :デフォルトの名無しさん:2010/06/16(水) 22:54:52
>>79
毎度毎度お前は。
twitterでつぶやいてろ。

84 :デフォルトの名無しさん:2010/06/16(水) 23:34:28
>>81
駄目、使うな、って言ってるんじゃなくて
速度はJavaと全く同じは言い過ぎじゃね?ってだけの議論だろ

85 :デフォルトの名無しさん:2010/06/16(水) 23:38:51
ScalaはJavaより速い!


86 :デフォルトの名無しさん:2010/06/16(水) 23:40:20
兄よりすぐれた弟なぞ存在しねぇ!!

87 :55:2010/06/17(木) 01:47:25
>>84
そりゃ二つの異なる言語処理系の性能が「全く同じ」なんて、
いかなる場合でも言えるわけが無いと何度言ったら…

とりあえず、同じような書き方した場合にベンチマークで有意な差が
出ないってのはshootoutのコードだけ見ても十分わかるし、原理的にも
「ほぼ」同じ速度が出る。で、無限にあるJavaプログラムと
Scalaプログラムの速度を比較するにあたって、同じような書き方すれば
速度が「ほぼ」同じだろう、以上の事はどうやっても言えないんだけど、
一体どうしろと言うんだ?そこまでして、Scalaの実行性能がJavaと同程度
であるってこと認めたくないわけ?Javaより少し遅いといえば満足なの?

88 :55:2010/06/17(木) 01:59:35
とりあえず、反論してくる人が何を主張したいのかさっぱりわからんので
主張をまとめてもらえないか。自分の主張はシンプルで、原理的にも
実用的にも、Javaと同じような書き方(whileループやvarの利用)をした
コードはJavaとほぼ同じ速度が出る。以上、これだけ。

反論してくる人は、「全く同じ」という無意味な言葉を使わないで
主張の要点を説明してくれ。二つの異なる言語処理系の速度が「全く同じ」
なんてことはそもそもありえないし、こちらはそんな事言ってないんだから。

89 :デフォルトの名無しさん:2010/06/17(木) 02:06:29
>>84
> 駄目、使うな、って言ってるんじゃなくて
> 速度はJavaと全く同じは言い過ぎじゃね?ってだけの議論だろ

そもそも、そんな議論はしていない。

誰が、「速度が全く同じかどうか」にこだわっているんだ?お前くらいだろ。
さっきからのその問題点のすり替えで、どうどうめぐりなので、辞めてくれるかな?


ていうか、お前、55氏の書いている内容を理解してないだろ?
これ以上愚問を繰り返すならば、せめて >60 の意味が分かってからにしようよ。


90 :デフォルトの名無しさん:2010/06/17(木) 02:07:34
速度はJavaと全く同じは言い過ぎってのは間違いじゃないだろうに。

91 :デフォルトの名無しさん:2010/06/17(木) 02:10:33
お前ら仲良くしろ
結局の所、>>33-36の結果を覆さないと堂々巡りになるんじゃないかね。
散々俺たちだってベンチマークの結果出して、RubyやPythonおせえwwwって言ってきたわけだし

92 :55:2010/06/17(木) 02:27:49
>>91
OK。>>33-36のベンチマークで、トータルでScalaの方が遅い理由については
説明つけられるので、ちょっと書いてみる。とりあえず、以下では、
>>36のベンチマークを基準にして話を進めるね。

まず、regex-dna,reverse-complement,n-body,fannkuch-redux,
binary-treesはほとんど有意な差が出てない(Scalaが勝ってる
ベンチすらある始末)のでまず除外。

残りは、spectral-norm,mandelbrot,fasta,k-nucleotideの4つなので
順番に検討していく。

93 :デフォルトの名無しさん:2010/06/17(木) 02:33:29
>>90
> 速度はJavaと全く同じは言い過ぎってのは間違いじゃないだろうに。

君の主張は詭弁だらけだな。

とりあえず、
「全く同じ」 「言い過ぎ」 「間違いじゃない」
って言葉を使うのは辞めておけ。


で、もう一度、スレを読み直してごらん?君は、いったい何を言いたいの?

94 :デフォルトの名無しさん:2010/06/17(木) 02:52:33
>>90
誰もそんなこと言ってねーって。
JavaとかScalaの前に日本語勉強した方がいいよ。

95 :55:2010/06/17(木) 02:56:57
まず、spectral-normだけど、これは差は比較的小さいけど、少しScalaが
遅い。いくつか原因はあると思うけど、たぶん、Scala版は
for(i <- ...) で、foreach、つまり高階関数を多用しているのに対して、
Java版は普通のループ構文を使ってる。それ以外大きな違いが無いので、
この辺りが原因になってると思われる。

次に、mandelbrotだけど、これはアルゴリズム部分はScala版もJava
っぽく書かれてるけど、スレッドがらみで、Java版はAtomicInteger
使ってるところを、Scala版はsynchronziedやnotifyを使うなど、
より効率が悪くなる書き方してる。

次、fastaだけど、これはプログラムの書き方が結構違っちゃってる
ので比較が難しい。実際にfastaのJava版をベタ移植してみるのが
手っ取り早そうだけど、めんどいな。ここはとりあえずpendingという
ことで。

最後に、k-nucleotide、これは、Scala版はActor使ってる一方で、Java版
はjava.util.concurrent駆使してるしで、完全に別物と言っていいくらい
組み方が違ってるので、処理系の速度比較としてはかなりアンフェア。
これも、Scala版でJavaと同じようにutil.concurrent使った場合と比較
しないとまともな比較にはならんだろう。

まあ、はっきりしないやつについても、Java版のコードを全部Scalaに
ベタ移植してみればはっきりするんだけど、そこまで手間かけるのも
面倒なので、誰か気が向いた人がやってくれれば。

コードはざっとしか読んでないので、ゆっくり読めばもうちょいまともな
分析ができるだろうけど、とりあえず、Java版とScala版で差が出てる
ベンチはコードの書き方がそれなりに違ってるという事は確か。

96 :デフォルトの名無しさん:2010/06/17(木) 03:31:20
55のレスの合間って不自然に口汚い援護射撃入るよな。
55がいない時間には入らないのに。

97 :デフォルトの名無しさん:2010/06/17(木) 03:35:49
煽ってる奴もマジレスしてる奴も、意見の辻褄がおかしくなってるから
もういい加減落ち着いて辞めた方が双方のためだと思う。

98 :デフォルトの名無しさん:2010/06/17(木) 09:11:36
jvm上のシステムはgcがどんだけ使われるかによってスピードがきまる。
言語ではない。

99 :デフォルトの名無しさん:2010/06/17(木) 09:20:03
それはない

100 :デフォルトの名無しさん:2010/06/17(木) 09:23:23
このスレ一番のトンデモ理論出ました

101 :デフォルトの名無しさん:2010/06/17(木) 10:45:12
gcが使われると遅くなるだろ
どこが、とんでもなんだ?

102 :デフォルトの名無しさん:2010/06/17(木) 10:46:28
>>99
お前はtwitter かはてぶしてろ

103 :デフォルトの名無しさん:2010/06/17(木) 10:56:27
>>96
あーあ、言っちゃったw

104 :66:2010/06/17(木) 14:35:51
>>96
話の筋を理解しないレスに突っ込みたい人は何人もいるでしょう。
私も突っ込みましたが私は>>55なんですか?

>>55
同じ内容を繰り返しているレスはスルーしてくれませんか?
不毛なやりとりでScalaスレが埋まるのはうれしくありません。

105 :55:2010/06/17(木) 15:02:32
>>104
スルースキルが低くて申し訳ない。納得いかないとつい書いてしまう性質
なもので。確かにどうどう巡りになってて、不毛だったかも。

106 :デフォルトの名無しさん:2010/06/17(木) 17:26:48
長島雄一郎入っちゃった

107 :デフォルトの名無しさん:2010/06/17(木) 22:00:51
>>104
> 話の筋を理解しないレスに突っ込みたい人は何人もいるでしょう。
> 私も突っ込みましたが私は>>55なんですか?

俺も、問題点をすり替えて、何度も同じ主張をするやつに文句言ったが、
別に、66でも、55でもないぞ。

他にも、コイツにツッコミ入れたやつは、あと4人くらい居るみたいだ。


108 :デフォルトの名無しさん:2010/06/17(木) 22:49:45
なんで急に弁解しだしたんだ。

109 :デフォルトの名無しさん:2010/06/17(木) 23:45:00
疑われたからだろ。

110 :デフォルトの名無しさん:2010/06/18(金) 00:54:56
大嶽親方「今は言えない。時が来たら話す。」

111 :デフォルトの名無しさん:2010/06/18(金) 01:25:00
とりあえず、「全く同じは言い過ぎってのは間違いじゃない」という発言のアホさに
ようやく気付いたみたいだから、彼も進歩したようだ。

でも、複数の人からアホ認定されているのは認めたくないようで、
現実から逃げて自作自演とかって騒いでいるから、まだまだアホのままだな。

>79, >90 のその後の発言は、>106, >108 ,>109 , >103, >96 , >99 なのだが、
アホの発言ってアホ丸出しだから本当分かりやすいよなあ。


112 :デフォルトの名無しさん:2010/06/18(金) 08:57:27
2chでは行間開ける人はまずいないことを、
こうなる前に早めに教えてあげるべきだったろうか。

113 :デフォルトの名無しさん:2010/06/18(金) 09:10:53
ダブルスペースで書く奴はいないけど、
話の区切りに行間を開ける奴はいるだろ。

てか、同一人物認定したところで、アホがアホである事実は変わらない。

114 :デフォルトの名無しさん:2010/06/18(金) 09:23:42
話の区切りが必要な長文書くヤツもまずいないって教えてあげなきゃだな

115 :デフォルトの名無しさん:2010/06/18(金) 09:34:01
そりゃ、ニュース系の話だろ。

116 :デフォルトの名無しさん:2010/06/18(金) 09:35:25
2ちゃんねるといえばニュース系しかないと思ってる頭の弱い人もいるってことだよw

117 :デフォルトの名無しさん:2010/06/18(金) 11:39:39
・俺の意見ではない。みんなが言っているんだ。
・自分を批判するレスを全て妄想のイコールで結び始める。

118 :デフォルトの名無しさん:2010/06/18(金) 11:42:01
>>112
マジレスすると、むしろもうちょっと早い段階で皆スルーすべきだった
>>77 あたりで

119 :デフォルトの名無しさん:2010/06/18(金) 11:43:39
この人もしかしてあの入門の人じゃね

120 :デフォルトの名無しさん:2010/06/18(金) 11:59:32
それ指摘したらヤバいだろ。

121 :デフォルトの名無しさん:2010/06/18(金) 12:59:18
この流れを見るまでにscalaとjavaの速度差が気になるって人が
いることに思いがよらなかったよ。

スクリプト言語よりは遙かに速いんだし
Scalaで物足りないときはCでカリカリ書くものだと思ったよ

122 :55:2010/06/18(金) 13:08:11
なんだか悪い意味で盛り上がるきっかけになってしまって申し訳ない…
とりあえず、55以降のレスは全て名前欄に55つけてるので、(なんだか
疑いをもたれてる書き込みについて)同一人物ではないとだけ言っておく。
信じてもらえるかはわからんけど。

123 :デフォルトの名無しさん:2010/06/18(金) 13:08:47
気にしてるんじゃなくて、
JavaがScalaに勝ってる箇所って無いに等しい
って話が出て来て、速度は多少劣っているのではって話になって
そんなことは絶対にないって荒れ始めたのでは。

124 :デフォルトの名無しさん:2010/06/18(金) 13:36:42
まさにcとcppの差だね
一番の弱点はjavaライブラリを使うときに色々気を使う必要があることじゃね

125 :デフォルトの名無しさん:2010/06/18(金) 14:05:03
色々って何だ?

126 :デフォルトの名無しさん:2010/06/18(金) 14:51:35
Option[T]を前提にできないとか、
Tupleが帰ってこないから、参照渡ししないといけないとか

127 :デフォルトの名無しさん:2010/06/18(金) 15:25:43
ttp://d.hatena.ne.jp/kwatch/20100618/1276818038
これってこのスレに関係ある話?

128 :デフォルトの名無しさん:2010/06/18(金) 15:44:07
Scalaの話なのこれ?

129 :デフォルトの名無しさん:2010/06/18(金) 18:05:44
>>127
このスレには関係ないと思います。
そこのblog主は言語処理系の速度とアプリケーションの速度は関係ないと主張しています。
スクリプト言語処理系が遅いからと言ってアプリも遅くなるとは言えないと言いたいのでしょう。
このスレはScala言語処理系はJavaと比べて遅くないという話で盛り上がりました。
どちらも実行速度の話ですが論点が違います。

130 :デフォルトの名無しさん:2010/06/18(金) 19:10:27
>>122

このグダグダの中でも、>>60 のような非常に参考になる資料が書き込みされて良かったです。

しかし、これってどうやって調べられたのだろうか?
javapで 逆アセンブルだろうか?

気になるルーチンは逆アセンブルすることで、scalacがどのようにコードを変換したか分かって面白そうですね。


131 :55:2010/06/18(金) 19:31:51
>>130

はい。javapで片っ端から逆アセンブルです。逆コンパイルもありなのですけど、対応する命令や
クラスファイルの構造を正確に調べたい場合には不向きなんですよね…。ただ、逆コンパイルでも、
おおまかにどのようにscalacがコードをコンパイルしているかはわかるので、バイトコードは
よくわからないって人は逆コンパイラ使ってみると良いかもです。

132 :デフォルトの名無しさん:2010/06/18(金) 20:20:21
水島氏は自演疑惑にも負けず、晒しエントリーにも負けず、これからも素直なままでいてほしいものである

133 : ◆CgacaMDhSQ :2010/06/18(金) 21:25:25
>>55あらため、みずしまです。トリップのキーをうっかり忘れてしまったので、別のトリップで。
>>132
素で>>55 = みずしまである事がばれたのにちょっと驚き。いや、別にあえて隠してたわけじゃないんだけど、
以前使ってたトリップのキー忘れてしまったので、コテをやめてただけなんですが。まあ、文体とか見れば
わかるのかなあ…。見抜いた>>132氏はよくわかったなあ。

134 :デフォルトの名無しさん:2010/06/18(金) 21:30:32
あー、やっぱりそうだったの?
なんとなくそんな感じはしてた。

135 :デフォルトの名無しさん:2010/06/18(金) 21:34:17
次はRC6かなぁ・・・finalはいつ?

http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_0_RC6

136 :デフォルトの名無しさん:2010/06/18(金) 21:43:01
JVM上の言語に早いも遅いもあるかボケども
命令が丸見えなんだから書き直せ!

137 :デフォルトの名無しさん:2010/06/18(金) 22:46:27
なんか酷い感じになって来たな…
もうやめようよ

138 :デフォルトの名無しさん:2010/06/18(金) 23:01:10
まだRC3のままだったけどRC6まで来てたのか
finalマダー?チンチン

139 :デフォルトの名無しさん:2010/06/18(金) 23:30:52
clojureにはRCなんぞないズラ...たしか

140 :デフォルトの名無しさん:2010/06/18(金) 23:36:54
Planet Scala、火曜日で止まってるけどそういうもんだっけ?

blog以外も集めてるよな?
そして、手動じゃ無いよな?

141 :140:2010/06/19(土) 01:59:28
>>140
> PlanetScala's crontab has apparently
> broken orbit and departed for deep
> space.
twitterから
やっぱり止まってたみたい、自分の早とちりじゃなければ…

142 :140:2010/06/19(土) 02:31:54
そして、Planet Scala 軌道回復のお知らせ

143 :デフォルトの名無しさん:2010/06/19(土) 13:57:37
質問です
関数funcで2つめの引数がオプションだったとするとオーバーロードを使って
def func(i: Int, s: String)
def func(i: Int)
みたいに書けますけど

2.8だとデフォルト引数とオプション型を使って
def func(i: Int, s: Option[String] = None)
みたいにも書けますよね

どっちがいいと思いますかね?

144 :デフォルトの名無しさん:2010/06/19(土) 14:22:00
>>143
互換性を考えるならオーバーロード。

互換性を考えないなら、s を取るか取らないかによって、
実装が大きく変わる => オーバーロード
あまり変わらない => デフォルト引数

じゃあなかろうか。

145 : ◆CgacaMDhSQ :2010/06/19(土) 15:27:44
>>143
二つ目のfuncの意味がどうなるかが問題じゃないかな
二つ目のfuncで、実際には単にデフォルト値を与えて(たとえば"")、一つ目のfuncを
呼び出しているだけなら、

def fun(i: Int, s: String = "")

みたいにした方がいいと思う。

一方、意味的に両者が大きく異なるなら、オーバーロードを使うべきだと思う。

146 :デフォルトの名無しさん:2010/06/19(土) 16:37:24
RC6でたぉ〜

http://www.scala-lang.org/node/6743

147 :デフォルトの名無しさん:2010/06/19(土) 16:51:19
ワシのRCは百八式まであるぞ

148 :143:2010/06/19(土) 16:53:35
ふむ、たしかにfuncの例じゃあ意味的にどうとか全くわかんないけど
思い付かないからしょうもない例だけどたとえば
class Person(name:String, age:Int, child:Option[Person]=None)
とかなら問題ない感じかな?

自分はなんかクラアント側の使い勝手はどうなのかなぁみたいなことばっかり考えてた
デフォルト引数バージョンのはただ呼び出すだけならSomeでラップしなきゃダメでちょっとうざい
val x = func(10, Some("a"))

でもクライアント側から呼び分けたい場合はオーバーロードバージョンのはメンドイな
val s: Option[String] = ...
val x = s match {
case None => func(10)
case Some(s) => func(10, s)
}

こっちならそのまま渡せるな〜
val s: Option[String] = ...
val x = func(10,s)

みたいな感じで

149 :デフォルトの名無しさん:2010/06/19(土) 17:51:15
yuroyoroさんがオプショナルな引数はカリー化して定義するのが2.8のAPIの流儀とつぶやいておられる
def func(i: Int)(s: Option[String] = None)

150 :デフォルトの名無しさん:2010/06/19(土) 17:51:25
>>148
どうやら、
> オプショナルな引数はカリー化して定義するのが2.8のAPIの流儀に見える。
> def func( i:Int )( s:Option[String] = None)
て、○○家の祖母がいってた。

151 :150:2010/06/19(土) 17:54:06
orz

152 :デフォルトの名無しさん:2010/06/19(土) 17:54:32
なんか勝った!

しかし、これ、なんか違和感があるなあ
どういう意図があるんだろ

153 :143:2010/06/19(土) 18:27:02
うーむ、それじゃあ呼び出すときに
func(10)()
みたいにする必要があるみたいだ
implicitが抜けてる気がする
def func(i: Int)(implicit s: Option[String] = None)
でも俺の脳じゃどういう利点があるのかはよく分からないな

154 :デフォルトの名無しさん:2010/06/19(土) 18:32:53
>153
利点は、シグネチャがどんどん複雑になって、Java厨にはったりをかませるとこ。

155 :デフォルトの名無しさん:2010/06/19(土) 18:43:08
そういうのいらない

156 :デフォルトの名無しさん:2010/06/19(土) 18:49:19
あんまりそういうのは関数原理主義者みたいで気が乗らないなぁ

ループを再帰に書き換えるのもそう思う。

157 :デフォルトの名無しさん:2010/06/19(土) 20:04:36
むしろ、これは関数型的なセンスではないよね
カリー化しておいて部分適用で使うわけじゃないんだから
Scala流ってことなんだろうなあ

158 : ◆CgacaMDhSQ :2010/06/19(土) 20:44:44
>>157
Scalaのカリー化って他の関数型言語のカリー化とだいぶ意義が違うんだよねえ
部分適用したいだけなら、 _ 構文使えばいいだけだし、カリー化とかする意味が無い
どちらかというと、implicit parameter使うためとか、function typeの型推論するためって
のが大きい。function typeの型推論するためってのはどういうことかというと、

def map[A, B](list: List[A], f: A => B) = list.map(f)
map(List(1, 2, 3), x => x + 1)

だと、

error: missing parameter type
map(List(1, 2, 3), x => x + 1)

になってしまうけど、カリー化して、

def map[A, B](list: List[A])(f: A => B) = list.map(f)
map(List(1, 2, 3))(x => x + 1)

だとOKとか。

159 :デフォルトの名無しさん:2010/06/20(日) 10:08:51
>>158
正直それダサいと思うんだけど
関数リテラルの型推論ってよくわかんない
んだよね
怒られたら型を書くようにしてるけど、
なんで失敗するのかわからないと気持ち悪い

160 : ◆CgacaMDhSQ :2010/06/20(日) 14:06:05
>>159
まず、前提として、Scalaは、(...)という引数リスト(確かこういうのを言語仕様ではセクションと言ってた)単位で
「前から順番に」型推論をしている、というのがある。たとえば、カリー化された
def map[A, B](list: List[A])(f: A => B) = list.map(f)
の場合、先に
(list: List[A])
の部分に関する推論が行われて、それから
(f: A => B)
の部分に関する推論が
行われる、といった具合。で、関数リテラルに関する型推論規則は実は簡単で、関数リテラルの
パラメータ部分(x => x + 1だったら、xの部分)の型が、関数リテラルの型を推論するまでに確定していないといけない。
で、
def map[A, B](list: List[A])(f: A => B) = list.map(f)
だと、先に(list: List[A])で、Aの型がたとえばIntとか推論された後に、(f: A => B)の部分の型推論が行われるので、 A = Int
とわかるけど、
def map[A, B](list: List[A], f: A => B) = list.map(f)
だと、list: List[A]の部分とf: A => Bの部分の推論は「同時に」(という表現が適切かどうかは微妙なところだけど)行われる
ために、関数リテラルの型推論をする時点で、関数リテラルの引数の型が確定してないので、エラーになる。

ちなみに、「前から順番に」ってのは、言語仕様書でそのように明示されてるわけじゃないんだけど、引数リスト単位で
型推論が行われてるってのはほぼ確実だと思う。

161 :デフォルトの名無しさん:2010/06/20(日) 19:06:00
なるほど、括弧を分けることで、先に型をバインドさせるわけね
ダサいという印象は拭えないが、
でも、テクニックとして、型パラメータを使って関数を引数にとる場合は、
カリー化させて関数の引数を後ろに回したほうがいいということはわかった
実際、foldLeftなんかもそうなっていると
しかし、結局これは関数の引数を常に分けるようになるよな
またRubyっぽい雰囲気になるな

162 : ◆CgacaMDhSQ :2010/06/20(日) 21:56:56
>>161
ダサいというのは自分も同意。たぶん、もうちょっと頑張って推論すれば>>160の前者のような場合でもうまく
推論できそうだし。ただ、そうすると、推論できない場合とできる場合の境界がよりわかりにくくなるって
デメリットもあるといえばある。
現在の関数リテラルの型推論規則は割と簡単なので仕組みさえわかってしまえばそこそこ理解しやすいんだけど、
頑張って推論した場合の規則はかなり複雑怪奇なものになりそうな気がする
完全な型推論ができればいいんだけど、Scalaの型システムだと原理的に無理があるし…

163 :デフォルトの名無しさん:2010/06/21(月) 23:24:53
今からでも遅くない これから始めるScala(前編)
ttp://codezine.jp/article/detail/5193

Hello worldがコンパイルエラーになる解説記事を見たのは久しぶりだ。

164 :デフォルトの名無しさん:2010/06/21(月) 23:41:55
codezineか

165 :デフォルトの名無しさん:2010/06/21(月) 23:44:36
とりあえずyuroyoroさんが日本語キーボードを使っているということはわかりました

166 :デフォルトの名無しさん:2010/06/22(火) 01:04:28
なおったみたいだね

167 :デフォルトの名無しさん:2010/06/22(火) 01:21:26
Mission Complete !! ですって?
←も使えるぐらいだから、全角スペースも認識する。とかはなかったか。
ソースファイルのほうは日付古いままだったけど、試したら問題なく動いたよ。

168 :ゆろよろ:2010/06/22(火) 13:02:11
codezineの記事、修正しました。ご指摘有り難うございます。
恥ずかしくて体中の穴という穴から汁があふれそうになりました。

昨日は規制中で書き込めなかったので。

169 :デフォルトの名無しさん:2010/06/22(火) 14:37:34
codezineって、どういうノリで記事が決まるの?
編集部が「今はScalaが売れる!」って感じで企画立ててるの?

170 :デフォルトの名無しさん:2010/06/22(火) 18:34:19
ScalaとSpring:両世界のベストを一体化
http://www.infoq.com/jp/articles/scala_and_spring

171 :デフォルトの名無しさん:2010/06/23(水) 13:49:05
scalaはC#のイベントみたいな言語が標準で提供してるObserver パターンのやつはないの?

172 :デフォルトの名無しさん:2010/06/23(水) 20:25:38
>>171
言語レベルでというのは無い
でも、C#のeventのほとんどの機能はライブラリレベルで十分エミュレートできそうな気がするけど
どうなんだろう

173 :デフォルトの名無しさん:2010/06/23(水) 23:55:43
「はじめてのScala」 っていう本を本屋でちらりと見た。
http://www.kohgakusha.co.jp/books/detail/978-4-7775-1510-3

前半は、「はじめての〜」という内容で、飽き飽きした内容かもしれないけど、
後半2/3くらいが、「Rails風データベース・アプリケーション」 で、
XMLファイルの読み書きなど。

著者は、主婦らしい。


だれか、買った人いる?

174 :デフォルトの名無しさん:2010/06/24(木) 00:12:09
ボクらのScala ~ 次世代Java徹底入門 浅海 智晴
本屋で売っていたのでパラパラ見てみた。
まったくの初心者向けとしては悪い本では無いと思うが
それ以外の人はコップ本を読んだほうがいいと思った

175 :デフォルトの名無しさん:2010/06/24(木) 00:18:34
>>173のは作りながらみたいなよくある入門書だけど
>>174のはコップやScalaプログラミング入門の劣化版でしかなくてかなりどうでもいい感じだと思う

176 :デフォルトの名無しさん:2010/06/24(木) 00:21:01
やさしいなんちゃらの二の舞になりそうだな

177 :デフォルトの名無しさん:2010/06/24(木) 00:22:34
主婦頑張ってるな

178 :デフォルトの名無しさん:2010/06/24(木) 00:41:08
主婦はわりかし有名で評判がいい
工学社のシリーズが地味すぎてマイナーだけども

179 :デフォルトの名無しさん:2010/06/24(木) 01:03:37
Scalaの本、増えすぎだろ
仕事で使ってるやつはどんだけいるんだよ

180 :デフォルトの名無しさん:2010/06/24(木) 01:07:06
増えたらなんか問題あるのか

181 :デフォルトの名無しさん:2010/06/24(木) 04:52:59
馬鹿向けのScala本たくさん出して
そんなに需要あるのか?

182 :デフォルトの名無しさん:2010/06/24(木) 06:55:02
プログラム初心者が一番最初の言語としてどマイナーなscalaを選ぶケースは
ほとんど無いから実際は入門書はいらない。いきなりコップ本を読めばいい

コップ本の内容が難しくて理解できないならばscalaを学ぶための
周辺知識が欠けていると思われるのでscalaの入門書でなく
javaや関数型プログラミングの本を読んで基礎を固めたほうがいい

183 :デフォルトの名無しさん:2010/06/24(木) 08:20:25
確かに他言語の経験がある人の独学はコップ本で良いですね。
でも前提知識を要求するコップ本は教科書には向いていません。
ボクらのScalaはScala教科書の定番になると予想します。

184 :デフォルトの名無しさん:2010/06/24(木) 09:20:15
俺は一番難しい本が理解できる
それが解らない奴はバカ

こういうアドバイスはいらない

185 :デフォルトの名無しさん:2010/06/24(木) 10:56:18
翻訳が理解できない本が素晴らしいとか本末転倒してるよな
翻訳自体は、その本の価値をがんばっても保つくらいにしかできず、普通は減ずるというのに

186 :デフォルトの名無しさん:2010/06/24(木) 11:21:49
入門書たたいてる奴は、入門書がないからいつまでたっても玄人向けのマイナー言語だという発想はないんだろうか。

187 :デフォルトの名無しさん:2010/06/24(木) 11:46:14
>>185
日本語で

188 :デフォルトの名無しさん:2010/06/24(木) 12:24:11
素人向けにするにはまだちょっと早いと思う

189 :デフォルトの名無しさん:2010/06/24(木) 12:59:23
そうやって言い訳して排除排除かね

190 :デフォルトの名無しさん:2010/06/24(木) 13:24:48
結局足の引っ張り合いなんだよな、日本人は


191 :デフォルトの名無しさん:2010/06/24(木) 13:33:14
じゃあ、今度ニュー速にプログラミング入門スレが立ったら、
「スカラっていうのが簡単でVBよりもいいらしいよ!」とか
しれっと書いてくる!

192 :デフォルトの名無しさん:2010/06/24(木) 13:39:54
はいはい
ワッフルワッフル

193 :デフォルトの名無しさん:2010/06/24(木) 22:53:58
むしろコップ本より詳しい本を誰か書いてくれ

194 :デフォルトの名無しさん:2010/06/24(木) 23:06:50
言いだしっぺの法則

195 :デフォルトの名無しさん:2010/06/24(木) 23:21:40
いや、2.8用コップ本が先だろ。


196 :デフォルトの名無しさん:2010/06/24(木) 23:29:34
そいやオライリー・ジャパンからはscala本まだ出てねーんだな

197 :デフォルトの名無しさん:2010/06/24(木) 23:46:33
オライリーは偏ってるから
PHPやPostgreSQLなんかも日本語のはずっと出なかった

198 :デフォルトの名無しさん:2010/06/25(金) 00:44:56
オライリーは表紙に悪意を込めたりするねw

199 :デフォルトの名無しさん:2010/06/26(土) 04:29:25
個人的には、ScalaでDSLとか簡易言語を実現するような本が欲しい。

200 :デフォルトの名無しさん:2010/06/26(土) 18:55:13
すいません、質問させてください。

http://pomu0325.blogspot.com/2010/04/scalagae-dispatchoauthgae.html
ここのコードをそのままコンパイルしようとすると
URL型が見つからないと言われたので
import java.net.URL
を追加したものをコンパイルしてみたのですが、

[ERROR] src/main/scala/demo/model/TwitterOauth.scala:20: error: type mismatch;
[INFO] found : dispatch.Request
[INFO] required: java.lang.String
[INFO] Note: implicit method dispatch2gae is not applicable here
[INFO] because it comes after the application point and it lacks an explicit result type
[INFO] val g = new HTTPRequest(new URL(r), if (isPost) HTTPMethod.POST else HTTPMethod.GET, FetchOptions.Builder.withDeadline(10))
[INFO] ^
[ERROR] src/main/scala/demo/model/TwitterOauth.scala:21: error: type mismatch;
[INFO] found : org.apache.http.Header
[INFO] required: com.google.appengine.api.urlfetch.HTTPHeader
[INFO] Note: implicit method dispatch2gae is not applicable here
[INFO] because it comes after the application point and it lacks an explicit result type
[INFO] r.req.getAllHeaders.foreach(h => {g.addHeader(h); println(h)})
[INFO]

のようなエラーが出てしまってコンパイルできませんでした。

色々いじってみたのですが解決せず・・もし分かる方いらっしゃったら
ご教示いただけないでしょうか。
お願いします><

201 :デフォルトの名無しさん:2010/06/26(土) 20:45:19
ttp://stackoverflow.com/questions/2731185/why-does-this-explicit-call-of-a-scala-method-allow-it-to-be-implicitly-resolved

202 :pomu0325:2010/06/26(土) 21:04:05
>>200
201のurlにも書かれてますが、implicit defで戻り値の型明示するか、implicit defを宣言しているobjectのimportを後で書けばよいようです。

203 :pomu0325:2010/06/26(土) 21:14:52
>>200
すみません… dispatch.Request -> Stringにするimplicit defを他で書いていたのですが、それも必要でした。blog直しておきます…。

/**
* convert dispatch.Request -> String
*/
implicit def r2s(r: Request) = {
r.host.get + r.req.getRequestLine.getUri
}

204 :デフォルトの名無しさん:2010/06/27(日) 22:42:42
org.apache.http.Header -> com.google.appengine.api.urlfetch.HTTPHeader
するimplicitも要りそう。

205 :デフォルトの名無しさん:2010/06/27(日) 23:08:35
implicit 使う奴って、保守性とか考えてんの?

206 :デフォルトの名無しさん:2010/06/28(月) 09:49:41
>>205
保守性を考えないのが、関数型プログラミングだ

207 :デフォルトの名無しさん:2010/06/28(月) 13:28:00
んだよねー
俺もScala勉強し始めてから気がついたわ
Perl並だってのに
まぁ昔ちょっとSchemeやってたんだけどそんな長いの書いたこと無かったし

208 :デフォルトの名無しさん:2010/06/28(月) 14:15:28
そんな事言い始めてもどうしようもないだろ。スクリプト言語なら型が動的に変わるのが当たり前なんだから。だからって、それがダメてわけじゃない。

209 :デフォルトの名無しさん:2010/06/28(月) 14:17:07
誰もスクリプト言語とか動的とかの話してないけど
関数型言語の保守性が悪いってだけの話で

210 :デフォルトの名無しさん:2010/06/28(月) 18:11:39
>>206
>>209

なんで関数型だと保守性悪い(悪くなる)の?
最初205でimplicitと使うやつは保守性考えているのか?って言う話だったのに。
議論が全く見えてこないんだが・・・。implicitと関数型の関係は?

211 : ◆CgacaMDhSQ :2010/06/28(月) 18:18:12
問題点が混ざってる気がする

1.implicit conversionを多用したコードは保守性が悪い
2.implicit parameterを多用したコードは保守性が悪い
3.関数型で書いたコードは保守性が悪い

これらはそれぞれ独立してる問題で、1または2が真だったとしても、3が真だということにはならない

ってのを踏まえた上で根拠を省いて私見を述べるなら、1.については、implicit conversionを、特にメソッドの追加目的で使う場合は、
その事をわかりやすい形でドキュメントに書かないと保守性が下がる傾向はある。Twitterのコーディング規約で基本的に
implicit conversion禁止なのはそういう事を考慮してだと思う。2.については、implicit parameter
はimplicit conversionよりは害は少ないけど、2.8のコレクションライブラリみたいにトリッキーな事やる場合は、
implicit parameterの型とそれに対応する実際の型の対応関係など、やはり十分なドキュメントが必要。3.については
関数型で書いた方が保守性は高い傾向があると思う。特に、mutableなオブジェクトが共有される事について悩まなくて
済むのは大きい。

212 :デフォルトの名無しさん:2010/06/28(月) 18:25:33
いや、関数型の保守性はいいとは言えんだろ流石に。
Perlよかマシだけど。

213 :デフォルトの名無しさん:2010/06/28(月) 18:27:14
>>211
2.8のコレクションライブラリみたいにトリッキーな事

あれは一体どうなっているんだ?
ある程度ソースコード追ってみたけど理解出来ない・・・org
別に使う分には全部理解する必要もないのか?

214 :デフォルトの名無しさん:2010/06/28(月) 18:27:23
implicitを多用してDSLっぽく使えるライブラリがあるとして
そのライブラリ自体のコードの保守性はさがるけど
そのライブラリを使用して書かれたコードは読みやすかったりして保守性が上がったりするんでそ?

215 :デフォルトの名無しさん:2010/06/28(月) 18:47:23
関数型だから保守性がいいというのは妄想
規約がなければどの言語でもほぼ同じ

216 : ◆CgacaMDhSQ :2010/06/28(月) 20:15:56
>>212
その辺の議論をすると話が長くなりそうだけど、関数型で書くことで、手続き型(OO言語服務)言語においてしばしば見られる
悪いコーディング方法(たとえば、mutableなオブジェクトを安易に複数のモジュールで共有するなど)を排除できる、という
のは、それだけでも十分価値があると思う。あと、プログラミング手法の話をしてるのにPerlという特定の言語名を例に出すのは
変じゃないかな?

もちろん、関数型で書いたらそれだけで良いコーディングができるなんて楽観的には考えてないけど、少なくとも(手続き型に
比べて)より良いプラクティスを提供してくれると思う。

>>213
おっしゃる通り、使う分には全部理解する必要は無い。で、あれをちゃんと理解しようと思うと少し面倒なんだけど、
あれがやっている事をかなり単純化したサンプルコードを以前作ってみた
http://gist.github.com/408693
ので、よければ参考にしてくださいな。ポイントは、引数の型(READ or WRITE or READ_WRITE,
CHARS or BYTES)によって、返り値の型(Reader,Writer,RandomAccessFile,InputStream,OutputStream)
が変化している(オーバーロードされている)点で、これは2.8で拡張された、implicit parameterの推論ルールに
基づいている。

>>214
DSLのセマンティクスがきちんと文章化されていれば、そういう可能性はもちろんあると思う。

>>215
言語というよりプログラミングパラダイムの話をしているつもりだったんだけど、違うのかな?言語の話を
しているのだったら、関数型言語だから保守性がいいってのは確かに妄想だと思う。でも、どの言語でも
同じってのは極論に過ぎるだろう。

217 :デフォルトの名無しさん:2010/06/28(月) 21:13:31
関数型というかクロージャを多用した他人のコードは読みにくく感じる
名前が不足してるせいだと思ってる

218 :デフォルトの名無しさん:2010/06/28(月) 21:49:42
>>215
規約があろうとなかろうと、
Prologの方がCOBOLよりは保守性はいいよ。


219 :デフォルトの名無しさん:2010/06/28(月) 21:54:26
implicit conversionでドキュメント化されてないから訳分からんと言えば、
Liftの事ですな。

220 :デフォルトの名無しさん:2010/06/28(月) 22:26:20
そこでCOBOL持ってくるのがなんというか

221 :デフォルトの名無しさん:2010/06/28(月) 23:30:15
プログラム仕様書がない昨今、可読性が保守性を作用するという前提で、
関数言語の特徴である、構文拡張みたいな事を頻繁にされると、読みにくいのではと、
軽い気持ちでかいてしまいました。
すいませんでした。

222 : ◆CgacaMDhSQ :2010/06/28(月) 23:44:09
>>221
関数型言語で(具象)構文拡張の機能を標準で持ってるのなんてごく一部だよ
そこそこ名前が知られてる言語の中だと
OCaml(Camlp4),Common Lisp(リーダーマクロ等)くらい?
Template Haskellは標準で持ってるかというと微妙か。あと、Common Lispを関数型言語扱いしていいのかはわからん。
いずれにしても関数型言語の特徴とは言えないのは確か。

で、関数型プログラミングの特徴はというと、色々意見はあるだろうけど、最大公約数的には
不変データ構造と高階関数を多用したプログラミングスタイル、というところだと思う。で、どちらもよほど
変な使い方しなければ可読性は下がらないというかむしろ上がると思うんだけどなあ。

223 :デフォルトの名無しさん:2010/06/29(火) 00:49:50
関数型プログラミングの威力をみよ!

flip (.) h . ((.) . (f . g))

224 :デフォルトの名無しさん:2010/06/29(火) 01:24:09
メンテナンス性わりー

225 :デフォルトの名無しさん:2010/06/29(火) 01:31:37
>>216
例えばSICPでは銀行口座が取り上げられているが、
状態を明示的に操作するパラダイムのほうが、
自然なモデル化を実現できる場合もある

関数型で自然に書けるのであれば、関数型で書くことが勧められるとは思う
というより、効率とかの要求がない限り、わざわざ環境をいじる必然性がない
環境の破壊がないコードは挙動を推論しやすい

関数型かどうかと保守性はあんまり関係ないと思う……
むしろモジュールシステムとか、名前をうまく分ける機能が重要だったりするから

226 :デフォルトの名無しさん:2010/06/29(火) 12:00:05
そういうのを保守性が悪いと思うなら、Javaを使っておけば良いんだ。

227 :デフォルトの名無しさん:2010/06/29(火) 13:01:07
>225
他人のソースを読む時には名前、識別子が手がかりなのに、
一見しただけでは名前が出てこないimplicit conversionは超最悪ですよね。

228 :デフォルトの名無しさん:2010/06/29(火) 13:12:17
関数型に文句を言いたいのか
Scalaに文句を言いたいのかはっきりしてほしい
>>225は関数型の話でしょ

あと、暗黙の型変換はObjectをimportしなきゃいけないから、そんな驚くようなことにはならないよ

229 :デフォルトの名無しさん:2010/06/30(水) 11:17:32
文句を言いたいとかじゃなくてさ、どうしても必要な時以外は使うべきじゃない機能だ
って話でしょ? gotoとか、演算子オーバーロードみたいなレベルで。

twitterさんもコーディング規約で禁止してるの?

230 :デフォルトの名無しさん:2010/06/30(水) 17:27:40
そろそろEffective Scalaが欲しいな

231 :デフォルトの名無しさん:2010/06/30(水) 21:23:41
Liftでセッション毎の情報を持たせるのって
どうやったらいいですか?


232 :デフォルトの名無しさん:2010/07/01(木) 02:45:36
>231
net.liftweb.http.SessionVar でいいんじゃないの?
javax.servlet.http.HttpSession を直に呼び出す事も出来たはずだけど。

233 :デフォルトの名無しさん:2010/07/01(木) 02:50:17
RC7きたぁ〜〜〜w

http://www.scala-lang.org/node/6881


234 :231:2010/07/01(木) 10:50:35
>>232
ありがとうございます。
SessionVarでできました。

235 :デフォルトの名無しさん:2010/07/01(木) 11:48:23
2.8.0 finalまだぁ〜待ちくたびれた(ry

236 :デフォルトの名無しさん:2010/07/01(木) 13:08:42
次は、確実にRC8

237 :デフォルトの名無しさん:2010/07/01(木) 14:10:04
開発者はRCの意味解ってるのか

238 :デフォルトの名無しさん:2010/07/01(木) 14:27:29
>>237
Remainder of Cloverでしょ。
そんくらい、中卒の俺でも知ってるw

239 :デフォルトの名無しさん:2010/07/01(木) 18:05:02
>>237
当然わかってるだろうけど
ユーザ数が増えてきて今までのプロジェクトの運営方法ではうまく回らなくなってるんだろう(たぶん)
RCの番号が増え続けてるのも、RC出た後に大きなバグが見つかる→フィックスの繰り返しが起きてるからだし

あとは最初のRCがScala Daysにあわせたものであって品質があまり良くなかったのが響いてるというのもあるかも

240 :デフォルトの名無しさん:2010/07/01(木) 18:28:23
RCはReleaseCitainaの略

241 :デフォルトの名無しさん:2010/07/01(木) 19:48:32
>>240

(とりあえずバグあるけど) ReleaseCitemimasita の略


242 :デフォルトの名無しさん:2010/07/01(木) 20:11:14
業務で使いたいんだが…まだ早いかな?

243 :デフォルトの名無しさん:2010/07/01(木) 20:18:35
>>242
どうなんだろうねぇ

社内でのJavaで作ったシステムに、ちょっとscalaを混ぜて使ってるけど。

244 :デフォルトの名無しさん:2010/07/01(木) 20:44:31
正直、コンパイラのバグが怖いなあ

245 :231:2010/07/01(木) 22:24:43
国内でのそれなりの規模の採用例って
特許を検索するやつ?以外にどこかあります?

246 :デフォルトの名無しさん:2010/07/01(木) 23:07:08
一定規模以上だと長期のメンテナンスが怖いな。
結構仕様変わってるし。
自分用の小規模コード用なら好きなんだが。

247 : ◆CgacaMDhSQ :2010/07/01(木) 23:50:14
>>244
コンパイラのバグについては、特定のコード書くとコンパイラがクラッシュする系の
バグはたまに見つけることがあるけど、計算結果が間違ってるとかそういう系のバグは、安定版(2.7.7)では
まず遭遇しないと思う。0ではないけど、実験的な機能(-Yオプション系の奴)やよほど変態的なコード書かない限りは
それほど恐れることも無いかと。2.8も正式リリースが出たら、安心して使って大丈夫じゃないかな。現状のRC7
でもまず大丈夫だとは思うけど。

248 : ◆CgacaMDhSQ :2010/07/01(木) 23:58:59
あとは、既に国外ではTwitterとかLinkedInとかFoursquareとか結構有名なサービスが採用してる
事例もあるし、EDF Tradingみたいな、ちょっとミスが多大な損失につながるクリティカルな現場での採用事例も
あるので、その辺もまあ安心材料になるかな。どちらかというと問題は採用したとしてScala技術者をどんだけ確保
(育成)できるかってところじゃないかねえ。パテントビューロ(上の特許を検索するシステム作ったとこ)の人の
http://qcontokyo.com/pdf/qcon_TakashiMiki.pdf
発表スライドは、実際にScala導入してみようかと考えている人にとっては結構参考になると思う。単なる宣伝だけじゃなくて
実際に採用してみてリプレース前の既存システムでコード量にどれくらい違いが出たかとかの比較もあって結構面白い。

249 :デフォルトの名無しさん:2010/07/02(金) 00:19:36
こういうのもなんだがll言語よりはちゃんと動くイメージがある

実際にはライブラリのバグの方が日常茶飯事だから気にならない

250 : ◆CgacaMDhSQ :2010/07/02(金) 00:33:27
>>249
LL系言語は実行環境も自前で持ってるから、足回りはJVMという安定した実行環境が使える
Scalaなどの言語に比べるとどうしても劣る部分はあるだろうねえ。Twitterがバックエンドを
RubyからScalaに切り替えたのもGCの性能が悪いのが問題の一つだったらしいし。

251 :デフォルトの名無しさん:2010/07/02(金) 04:28:21
Lift 2.0 age

252 :デフォルトの名無しさん:2010/07/02(金) 08:37:25
細かいところばっかりだけどね
gcもそうだけど
llだとcと連動するところでトラブルが起きがちなんだよね
文字列をうまく処理できない場合があったり、リソースロックしていたり
それがjvm内で完結しているとトラブルが少ないしデバッグもしやすい

253 :デフォルトの名無しさん:2010/07/02(金) 09:00:46
foursquare.comでも、LiftのAjaxによるGC回避のpingをやってるんだね。
200秒ごと?
あれは、大きなサイトでも大丈夫なのかなとちょっと心配な仕様だったんだけど。

254 :デフォルトの名無しさん:2010/07/02(金) 14:06:51
>251
LiftScreenとWizardは面白そう。
タグレベルで細かくいじろうとすると、めんどくさいのかもしれないけど。
http://liftweb.assembla.com/wiki/show/liftweb/Lift's_Screen

255 :デフォルトの名無しさん:2010/07/04(日) 10:09:13
アンドロイド上でscalaのインタプリタって動くの?


256 :デフォルトの名無しさん:2010/07/04(日) 17:01:48
動くよ

257 :200:2010/07/05(月) 10:13:55
お礼遅れてすいません、レスありがとうございます。
ブログの記事の方までレスくださったようで・・ありがとうございましたm(_ _)m

>>org.apache.http.Header -> com.google.appengine.api.urlfetch.HTTPHeader
>>するimplicitも要りそう。

これがやっぱり必要なようですが・・まあ分かってません。
自分でも調べていますが、分かる方いらっしゃったら教えてくださると幸いです。
ありがとうごじましたm(_ _)m

258 :デフォルトの名無しさん:2010/07/05(月) 13:50:40
>>257
implicit def h2h(h: Header) = new HTTPHeader(h.getName, h.getValue)

試してないけどこれを追加したら動くかも。
間違ってたらごめん。




259 :デフォルトの名無しさん:2010/07/06(火) 12:15:53
Scalaは短命だったな
覚えて損したわ

260 :デフォルトの名無しさん:2010/07/06(火) 12:25:56
次の言語、頑張って覚えてね

261 :デフォルトの名無しさん:2010/07/06(火) 18:11:00
すげー期待してたのにD言語みたいになってきてちょっとショック

262 :デフォルトの名無しさん:2010/07/06(火) 20:43:05
なにいってるんだ
D言語はバイブルが出てこれから大攻勢に

出るといいな

263 :デフォルトの名無しさん:2010/07/06(火) 23:14:33
>>261
D言語みたい、ねえ…どのへんが?

264 :デフォルトの名無しさん:2010/07/06(火) 23:23:50
既に翻訳も含めて日本語のScala本が5冊出てるし
Twitter,foursquare,LinkedIn,などそれなりに知名度があるサービスのScala乗り換え事例
も増えてきてるしそんなに悪い状態とも思わないけどな

265 :デフォルトの名無しさん:2010/07/06(火) 23:44:41
知名度が出たときに一気にブレイクできなかった言語は衰退するのみ

266 :デフォルトの名無しさん:2010/07/07(水) 05:08:19
いいんじゃないの、Lispみたいにしぶとく生きてれば

267 :デフォルトの名無しさん:2010/07/07(水) 06:31:56
>>263
仕様変えてRC出し続けてるところが

268 :デフォルトの名無しさん:2010/07/07(水) 16:12:58
>>267
2.8の仕様はもうfixされてるはず。RC上がり続けてるのは主としてバグ修正目的
RC1→RC2で継続プラグインが入ったりspecializationが入ったりしてるがこれは元々
2.8で入る予定のものでRC1でまだ入ってなかったというだけの話だし

そんなんでRC出しちゃったのがまずかったというならその通りではあるんだが

269 :デフォルトの名無しさん:2010/07/07(水) 18:30:43
Scalaの求人と普及中のスクリプト言語の求人を比べてみました。

Scalaの普及が始まってからまだ1年ちょっとしか経っていません。
http://www.indeed.com/jobtrends?q=Scala
Groovyの普及はScalaより1年半ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy
Rubyの普及はGroovyより4年半ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby
Pythonの普及はRubyより2年ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby,Python

Scalaの普及は続いており、短命だったは事実に反します。
一気にブレークできなかった言語も普及が続き、衰退していません。
プログラミング言語の普及には何年もかかるのです。

270 :デフォルトの名無しさん:2010/07/07(水) 18:33:59
他のヒットしなかった言語も同じ事言われてたけどね
本当に必要とされてる言語はJavaやPHPみたいにグイっと来るんだよ

271 :デフォルトの名無しさん:2010/07/07(水) 18:56:53
Cは普及するまでにかなり時間かかったけどな
本格的な普及がANSI C以降とするなら20年前後ってとこか

272 :デフォルトの名無しさん:2010/07/07(水) 20:12:07
PHPの普及はPythonより2年ほど先行しています。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby,Python,PHP
PHPは安定成長を続ける事でシェアを取りました。

Javaの方は確かに一気に普及しました。
http://www.indeed.com/jobtrends?q=Scala,Groovy,Ruby,Python,PHP,Java
Javaが一気に普及したのは主要プレイヤーがJavaを支持したために
Javaが次の主流言語になると信じた人たちがたくさんいたからでしょう。
LinuxもIBMがRedHatに出資したのがきっかけで普及しました。
JavaよりScalaの方が間違いなく生産性と保守性が高いとされるようになれば
Scalaが大手の支持を受けて一気に普及する目もあるでしょうね。

273 :デフォルトの名無しさん:2010/07/07(水) 20:17:54
Scalaは保守性が低いからなあ。

274 :デフォルトの名無しさん:2010/07/07(水) 20:36:51
>>273
煽るわけじゃないけどどの部分が?

275 :デフォルトの名無しさん:2010/07/07(水) 20:40:02
Javaが急速に普及したのはWebという新しいプラットフォームが登場した事による
UnixでC、WindowsでVBが普及したのと同じ
Linuxが普及したのは十分な性能を持ち安価な1Uラックマウントサーバが登場した事による
同じ土俵で生産性や保守性を理由に後発の言語が普及した例はほとんどないのではないか
DelphiはVBより評価されていたようだがVB以上に普及することはなかった

276 :デフォルトの名無しさん:2010/07/07(水) 20:44:19
数少ない例外がC→C++かな
Scalaもそうなればいいけど

277 :デフォルトの名無しさん:2010/07/07(水) 20:48:29
>>275
Rubyがここ数年で普及したのは、Perlと比べたときの生産性や保守性が理由
(もちろん、Railsというフレームワークがあったのが大きいけど)だと思うけど、どうなんだろう…

278 :デフォルトの名無しさん:2010/07/07(水) 20:53:01
>Perlと比べたときの生産性や保守性

あんま変わらんな
フルビルドだとインストール失敗するし
gemとか糞だし

279 :デフォルトの名無しさん:2010/07/07(水) 20:54:45
> フルビルドだとインストール失敗するし

そういう問題があるならバグレポートしてくれよ

280 :デフォルトの名無しさん:2010/07/07(水) 21:10:47
>>276
Cの普及時期から見るとC++の登場は後発と言うほど遅れていない
ANSI C制定(89年)と同時期にARM(The Annotated C++ Reference Manual, 90年)が出された
特にWindowsでは普及期(3.1〜95)にVisualC++の影響でCをやらずにいきなりC++の方が普通だった

>>277
非エンタープライズという意味でのWeb2.0というプラットフォーム(というより顧客/マーケットか)の
登場(拡大)が影響したのではないか

281 :デフォルトの名無しさん:2010/07/07(水) 21:30:11
現時点で新しめのプラットフォームというとクラウドとスマートフォン
もしiPhoneアプリがScalaでしか作れなかったら・・・
クラウド特にGAEはまだチャンスがあると思う
GAEに特化した有力なフレームワークがあればScalaは普及するのではないか

282 :デフォルトの名無しさん:2010/07/07(水) 21:45:18
>>281
言う通り、GAEは狙い目かもね
Scalaの表現力を生かして、BigTableへのアクセスとかが簡単にできる良い
Webアプリフレームワークがあれば…

283 :デフォルトの名無しさん:2010/07/07(水) 21:50:38
GAEならScala + Slim3でどう?

284 :デフォルトの名無しさん:2010/07/07(水) 21:51:41
Slim3はAPT使ってるせいでScalaと相性が悪い

285 :デフォルトの名無しさん:2010/07/07(水) 22:01:14
おまいら GAE に夢見すぎ

286 :デフォルトの名無しさん:2010/07/07(水) 22:08:35
まぁGAEが現状のScalaよりも遙かに普及してくれないと意味がない話ではあるな

287 :デフォルトの名無しさん:2010/07/07(水) 22:25:45
>274
「有るから使う」程度の理由でimplicit使う奴が大量に居るから。


288 :デフォルトの名無しさん:2010/07/07(水) 22:35:34
このスレってずっと暗黙の型変換で粘着されてるけど、そんなに嫌なら使うの禁止すれば?としか言いようがない

上のほうでgotoに例えられてるけど、よく知らないやつの怯えっぷりは似てるかもしれない
暗黙の型変換はgotoほど必須ではないと思うが

289 :デフォルトの名無しさん:2010/07/07(水) 22:49:44
>>288
確かに。なんでこんなに(implicitに)怯えてるのか不思議でならない。
まあ使い方間違えれば可読性に負の影響を及ぼすことはあるけど、別にんなのはimplicitに
限った話じゃないしなあ…

290 :デフォルトの名無しさん:2010/07/07(水) 22:56:45
怯えるとかそういう大げさな話じゃない。
濫用気味でしょと言ってるだけ。


291 :デフォルトの名無しさん:2010/07/07(水) 23:00:02
そんなやつが大量にいるようには感じないけど
どちらにせよ規約で縛ればおkな話だな

292 :デフォルトの名無しさん:2010/07/07(水) 23:19:47
rubyとかで動的にメソッドがばりばり作成されたりするのとかと比べれば
implicitなんか明快すぎて楽勝だろ
変だなと思えば、簡単に調べられるし

293 :デフォルトの名無しさん:2010/07/07(水) 23:24:51
まあ、怖がっているのはJava層かPHP層だろうな
PerlとかRuby使っているやつがこんなんでうだうだ文句言うとは思えない

294 :デフォルトの名無しさん:2010/07/07(水) 23:58:28
C++やJavaはimplicit is evilって思想だからなぁ

そこでできるだけexplicitにしてみたらキーパンチが多すぎて収拾が付かなくなったってのが
ここ10年の歴史だとは思うんだけどね。

295 :デフォルトの名無しさん:2010/07/08(木) 00:07:22
C#の変化の歴史を見ても、「外向けにはexplicit、内向けにはimplicit」が
今の流行じゃないのか?


296 :デフォルトの名無しさん:2010/07/08(木) 00:11:12
一方歴戦のVBプログラマはoption explicitを使った

297 :デフォルトの名無しさん:2010/07/08(木) 01:12:40
>>293
Rubyでもevalやリフレクションの濫用が問題になってた(なっている)
強力な機能は使い方を誤るとエライことになる
そこで最近は「ここぞという所にだけ使え」って原則が普及してきたように感じる

まあScalaについては、まずは濫用が問題視されるぐらい
普及してからの話じゃなかろうか

298 :デフォルトの名無しさん:2010/07/08(木) 01:27:35
もしそう言うのが大々的に問題になったらIDEの機能でimplicitな所は分かりやすく色を変えたりして表示したりみたいな機能がつくんじゃね?

299 :デフォルトの名無しさん:2010/07/08(木) 01:30:52
だから怖がりすぎだって
evalとかそういう次元じゃないから

300 :デフォルトの名無しさん:2010/07/08(木) 09:21:54
>>277-278
Rubyメインで使っているけど、言語の良し悪しを置いておくなら、
ライブラリが数そろっててメンテされてて、
優秀な技術者がやとえる(というかもうそういう人しか残ってない予感がする)であろうPerlは
まだまだいけるように見える

RubyはRailsである壁を超えて広まりはしたけど、
ぶっちゃけると他にいいフレームワークがあったら移るような人たちばかりだろ、今使っているのはw

Perlの優秀な技術者どこで見つけてくるんだよって?Rubyも似てるだろ?w

保守性?依存性ごっちゃなgemやらバージョンあげるとすぐに動かなくなるgem郡、
下位互換性もすぐに切り捨てられ常に変わり続けるRailsや周辺プラグイン

「Railsの生産性が高い」と行った場合、結局はwebアプリの開発にどのくらいなれているかで決まってくるし。
(公平に既存の資産がない、という前提)
少なくとも、ふだんRuby書いている奴が、Rails使ったからって簡単にwebアプリ作れない。
だからといって他の言語から乗り換えたい奴は、よっぽど不満なやつだけ。
そういう奴らも、すぐに目移りする。


ようするに仕事だとphp最強!!

301 :デフォルトの名無しさん:2010/07/08(木) 09:25:48
Rubyメインでのくだりが繋がってないな、失礼。独立した別の行段落と考えてくれ

302 :デフォルトの名無しさん:2010/07/08(木) 10:17:05
仕事メインはC++で、
週末にrailsで遊んでみたが
毎週gemは動かないし、アップデートするのに半日つぶれる
かといってバージョン固定したらバグやセキュリティーホールは直らないし
で、使うの諦めた

かと言ってC++でwebやる気は起きない
なのでscala+liftに逃げてきた

303 :デフォルトの名無しさん:2010/07/08(木) 10:26:23
Rubyの話題はもういいよ
ここで長文書くことないでしょ

304 :デフォルトの名無しさん:2010/07/08(木) 10:28:27
次はRC8?それとも正式リリース?

305 : ◆CgacaMDhSQ :2010/07/08(木) 18:12:23
>>304
scala-internalsを読んだ限り、これ以上クリティカルなバグが報告されなければ
正式リリースされそうな感じ。

306 :デフォルトの名無しさん:2010/07/08(木) 23:42:12
scala1のeclipseプラグインって現状galileoかGanymedeしか対応してなかったという認識だが、
Heliosに対応する予定はあるのか?
もしくはHelios飛ばしてM4のほうが先とか?

307 :306:2010/07/08(木) 23:48:03
>scala1のeclipse
なぜかscala1とかいうわけわからないタイプミスしたが気にしないでくれ

308 :デフォルトの名無しさん:2010/07/09(金) 01:00:19
公式サイトにもうすぐへリオス対応するって書いてある

309 :306:2010/07/09(金) 02:12:57
>308

そうなのか。ありがとう

310 :デフォルトの名無しさん:2010/07/09(金) 09:19:44
現時点でScalaを書くのに一番良いIDEって何かな?
自分はIntelliJのCEを使ってるんだけど。

311 :デフォルトの名無しさん:2010/07/09(金) 10:32:57
このスレの人たち的にはrustってどうなの

312 :デフォルトの名無しさん:2010/07/09(金) 18:56:50
最近EmacsでENSIME + sbt使ってるよ
・補完
・定義ジャンプ
・カーソル位置の変数の型推論
・flymakeっぽい自動コンパイルチェック
くらいはできるよ
Emacs派にはおすすめ

313 :デフォルトの名無しさん:2010/07/09(金) 19:35:35
>>312
EMSIME、割と評判いいねえ。EclipseのScalaプラグインの出来が
イマイチだから、いっそのこと乗り換えようかな…

314 :デフォルトの名無しさん:2010/07/09(金) 19:36:02
typoしたorz EMSIME→ENSIME

315 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 14:55:31
scalaでスクリプトを実行するときの起動時のオーバーヘッドを減らすのってどうやるんでしたっけ?
2年ぐらい前に記事で読んだことがあったような気がして本家を探してみたんですが、見つからなかったです。
もしよろしければ、やりかたかリンクを教えてもらえないでしょうか。
よろしくお願いします。

316 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 16:22:08
ちょうど昨日見てたけど、URLがみつからない。
Xshare:dumpとかコンパイルしたらどうだみたいな話だったよね?

とりあえず。

Javaアプリを高速起動する方法「JRubyテク」
http://journal.mycom.co.jp/news/2010/03/04/009/index.html

nailgunは、scala-2.8.0-rc5だと、いまのところ使えてない。
Xshare:dumpは、32bit -client用みたい。

317 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 16:27:12
http://www.scala-lang.org/search/node/nailgun
これだった。

318 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 16:36:22
-savecompiled の話か

319 :名無し~3.EXE:2010/07/10(土) 17:46:17
下記の、どれが存在する言語なのでしょうか?
C+−、C−+、C−−

320 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 18:00:04
>>316-318
ありがとうございます。
nailgunはちょっと面倒で、-savecompiledは初回が遅いこととjarファイルが作られてしまって邪魔なのが欠点ですね。
ちょいnailgunについて調査してみます。


321 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 18:42:19
nailgunで、コンパイル後ならOKかな。

clojure書いてる人が用意したnailgun用のclasspath-managerというのを使ってみてるけど、
これを使うと、ng-cpせずに動的に呼び出すので、
・クラス名の重複が避けられる
現時点だと、
・逐次にclasspathというファイルを用意する必要がある
・classpathに書いた、ディレクトリ内のclassファイルを上手く読みに行かないので、jarやzipにしたほうがよい
・scala-library.jarを上手く呼び出せない
・他にも呼び出せないものがあるっぽい

http://github.com/stuartsierra/classpath-manager

今は、こんな感じでためしてる。
java -verbose -Xms32m -Xmx128m -server -cp lib\nailgun-0.7.1.jar;lib\classpath-manager-1.1.0.jar;lib\scala-library.jar com.martiansoftware.nailgun.NGServer
ng ng-alias cm com.stuartsierra.ClasspathManager
classpathファイル用意
ng cm メインクラス名

322 :名無しさん@そうだ選挙に行こう:2010/07/10(土) 19:06:38
test

323 :名無しさん@そうだ選挙に行こう:2010/07/11(日) 16:41:26
>>294
そんな歴史は無いだろ。
吠えてたのはLL信者だけじゃん。

324 :デフォルトの名無しさん:2010/07/12(月) 12:01:40
にゃー

325 :デフォルトの名無しさん:2010/07/12(月) 21:11:52
タプルを引数に渡したいとき、どうするですか?
val xy = (1,2)
def f(i:Int,j:Int): Int = i+j
f(xy) //ここ!

326 : ◆CgacaMDhSQ :2010/07/12(月) 21:15:31
>>325
その場合、残念ながら直接渡せないので、
f(xy._1, xy._2)
のようにするしかない。タプルを直接渡せるメソッド(関数ではなく)を定義するには、
def f(ij: (Int, Int)): Int = ij match { case (i, j) => i + j }
みたいに書くしかないけど、これはこれでめんどいし。

タプルを引数に取るメソッドと複数引数を取るメソッドが同じじゃないのはJavaの
calling conventionにあわせた結果なんだろうけど、うっとおしいよねえ。

327 :デフォルトの名無しさん:2010/07/12(月) 21:21:39
あと、
val (x,y) = (1,2)
ならいいのに、
private val (X,Y) = (1,2)

not found: value X
って怒られるのはなぜですか?

328 :デフォルトの名無しさん:2010/07/12(月) 21:32:17
なにー!
大文字と小文字で違うのかっ!

329 :デフォルトの名無しさん:2010/07/12(月) 21:33:00
とりあえず326さん、ありがとうございます。

330 : ◆CgacaMDhSQ :2010/07/12(月) 21:48:27
>>327
パターンマッチングの仕様。
パターンの名前が大文字で始まる場合、未束縛の変数ではなく、その名前の値が
既に存在しているとみなされて、その値に対するパターンマッチが行われる。
つまり、
val (X, Y) = (1, 2)
の場合は、Xと1、Yと2が同じかどうか比較されるってこと。

331 :デフォルトの名無しさん:2010/07/12(月) 22:07:10
>>330
何故にこんな仕様?

332 :デフォルトの名無しさん:2010/07/12(月) 22:10:20
def f(a: Int, b: String) = ...
val tuples = ...
tuples.map { t => f(t: _*) }

みたいなことできればいいのに。


333 : ◆CgacaMDhSQ :2010/07/12(月) 22:22:31
>>331
何故かという事に関しては直接は知らないのだけど(MLを検索すると出てくるかもしれないが)、
この仕様のメリットとしては

1.構文解析が簡単にできる
2.パターン名のtypoが検出できる

という二点があると思う。たとえば、仮に存在しない変数名がパターン部に記述されたら変数パターンだ
という仕様だったとする。すると、match式などの構文解析をするために構文解析時にいちいち変数表などを
もって回るか、構文解析の処理の一部を意味解析に回すことになる。一方、大文字小文字かで区別する
なら、そのような面倒な処理なしに変数パターンが値パターンかを簡単に区別できる。これが一点目。

二点目としては、たとえば、
x match { case R => ... }
のつもりが、誤って
x match { case T => ... }
としてしまった場合、大文字小文字で判定している場合、Tという値は存在しないというエラーを
出すことができるが、存在しない名前が現れたら変数パターンとみなすという仕様だと、Tという
変数が新しく定義されて正しくコンパイルされてしまい、エラーに気づかない可能性がある。

334 :デフォルトの名無しさん:2010/07/12(月) 23:38:45
>> 325

Function.tupled(f _)(xy)

でどうでしょうか


335 :デフォルトの名無しさん:2010/07/13(火) 20:17:35
シングルトンオブジェクトを
その名前の文字列から取得するにはどうしたらよいでしょうか?

336 : ◆CgacaMDhSQ :2010/07/13(火) 23:07:14
>>335
こんな感じ?
object Refl {
def getSingleton(name: String): AnyRef = {
(Class.forName(name + "$").getField("MODULE$").get(null))
}
def main(args: Array[String]) {
val singleton = getSingleton("MyObject")
val klass = singleton.getClass
klass.getMethod("hello", Array[Class[_]]():_*).invoke(singleton)
}
}
object MyObject {
def hello { println("Hello, MyObject") }
}

337 :335:2010/07/14(水) 00:52:23
>>336
ありがとうございます。完璧です。

予想以上に難しくてびびりました。
REPL で
> object A
> Class.forName("A$")
てやって、できないなー、とかやってたレベルなので。

338 :デフォルトの名無しさん:2010/07/14(水) 02:18:04
>>336

技術的にできるのはわかるけど、

objectの実際のclassファイル名が、"名前+$"になっているとか、
"MODULE$"と名前のフィールドが存在しているのって、
言語仕様で規定されてたりするんだっけ?(そもそもそういった厳格な言語仕様ってあるの?)

scalaのソース上での表記と、classファイルにしたときの実装がどうなっているかってのは別の話だよね?
(いわゆるCRubyとJRubyみたいに標準の実装以外に別の実装があってもいい?)

もちろん、実用で使うには普通やるべきではないよね?ていうかやる必要ないよね?

まぁこういうふうにリフレクションつかってみるのは勉強にもなるし、楽しいけど。

あと、
object ++{}
みたいに記号名のobject定義できるけど、その場合って
$plus$plus.class
ってファイル名になるよね?それの変換まで実装したら大変だな・・・

339 : ◆CgacaMDhSQ :2010/07/14(水) 02:48:49
>>338
おっしゃる通り、objectの名前と実際のclassファイル名の対応関係とかは、言語仕様では
規定されてなくて、あくまでも現在のScala実装に依存した話なので、それを承知でやるならアリかと
思うけど、普通はやるべきじゃないとは思う。

記号名は、各文字ごとに単純に表引きで変換できるから、そんなに大変ではないと思うけど、多少手間は
増えるね。

340 :デフォルトの名無しさん:2010/07/14(水) 13:11:33
下のが実行時に
scala.MatchError: null
で落ちて困っているのですが、どうしたらいいのでしょうか。
ちなみに型パラメータをやめて[Double]とべた書きすれば大丈夫なのですが。

class Matrix[T](n) {
var mat = Array[Array[T]](n)
def init(v: T) {
mat=mat.map(_=>Array.fromFunction(_=>v)(n))
}
}

341 : ◆CgacaMDhSQ :2010/07/14(水) 14:10:27
>>340
MatchError以前にそれだとそもそもコンパイル通らない
Array.fromFunctionの第二引数がIntだからnはInt型じゃないといけないが、
それだとArray[Array[T]](n)のところでエラーになるし…。推測すると、

class Matrix[T](n :Int) {
var mat = new Array[Array[T]](n)
def init(v: T) {
mat=mat.map(_=>Array.fromFunction(_=>v)(n))
}
}

が書きたかったコードじゃないかと思うけど、あってる?で、そうだとして仮定して
話を進めるけど、Scala 2.7では、ジェネリックな配列に関しては、内部的にBoxedXXXArray
(XXXは型名)というクラスのオブジェクトに変換して扱ってる。で、mat.map(_ => ...)の、
無名関数(_ => ...) の中で、最初に引数をBoxedXXXArrayに変換しようとするんだけど、配列の
要素がnullなので変換できずに失敗する。不具合といえば不具合かな。2.8では、Arrayは必ず
Javaの配列にマッピングされるようになったので、このような問題は起こらなくなってる。

class Matrix[T:ClassManifest](n :Int) {//2.8でしか動かないコード
var mat = new Array[Array[T]](n)
def init(v: T) {
mat=mat.map(_=>Array.fromFunction(_=>v)(n))
}
}
object MatrixMain {
def main(args: Array[String]) {
val x = new Matrix[Double](10)
x.init(20.0)
println(x.mat)
}
}

342 :デフォルトの名無しさん:2010/07/14(水) 14:25:05
すげー。聞かないとまったく分からなかったです!
(通らないコード書いてすみません。ご推察の通りです。)

あと、v2.8では多次元配列の生成はfromFunction((i,j)=>...)が廃止されているので、
質問したケースではtabulateかfillを使えばいいみたいですね。

というわけで
class Matrix[T:ClassManifest](n:Int,value:T) {
private var mat = Array.fill[T](n,n)(value)
override def toString = mat.map(_.mkString(" ")).mkString("\n")
}

val thanks = new Matrix(10,3.14)
println(thanks)

343 :デフォルトの名無しさん:2010/07/14(水) 16:08:32
こんどはこれで引っかかった・・・。
初めて数日なので、エラーに対してまったく勘が効かなくって困っています。
しばしご教授願います。
検索するに、java.lang.StringとDoubleで似たような話があるみたいなのですが、
x.toDoubleとかできないし。。。

$ cat point.scala
case class Point[T](x:T,y:T) {
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
}

object Run {
def main(argv:Array[String]) {
val p,q = Point[Int](3,5)
println(p+q)
}
}
$ make point
scalac-2.8 point.scala
point.scala:2: error: type mismatch;
found : T
required: String
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
^
point.scala:2: error: type mismatch;
found : T
required: String
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
^
two errors found
make: *** [point] Error 1

344 : ◆CgacaMDhSQ :2010/07/14(水) 17:16:28
>>343
ひょっとしてC++ or D系の言語から来た人かな?
JavaやScalaなどの言語では、型パラメータが持っている演算を
制約として明示しないといけない事になっている。この例だと、型パラメータTが+メソッド
を持っていることを、コンパイラは知らないので、怒っちゃうわけだ。required: Stringって
出るのは、T + Stringという文字列連結だと解釈しようとしてそれに失敗しちゃうからだね。

で、解決策だけど、大きく分けて二つあって
1.implicit conversionを使う
2.implicit parameterを使う
のどちらかになる。

345 : ◆CgacaMDhSQ :2010/07/14(水) 17:25:11
まず、1.の場合だけど、+メソッドをもった型Addible[T]みたいな型を定義して、
TからAddible[T]へのimplicit conversionを必要な型ごとに定義する。次のような感じ。

trait Addible[T] {
def +(that:T): T
}

case class Point[T <% Addible[T]](x:T,y:T) {
def +(that:Point[T]): Point[T] = Point[T](x+that.x,y+that.y)
}

object Implicits {
implicit def intAddible(i: Int) = new Addible[Int] {
def +(that:Int) = i+that
}
implicit def doubleAddible(i: Double) = new Addible[Double] {
def +(that: Double) = i+that
}
}
import Implicits._
object Run {
def main(argv:Array[String]) {
val p,q = Point(3,5)
println(p+q)
val r,s = Point(3.5, 4.5)
println(r+s)
}
}

この方法だと、足し算するごとにPoint以外にも余計なオブジェクトが生成されるので、
メモリにあまり優しくない。

346 : ◆CgacaMDhSQ :2010/07/14(水) 17:33:29
次に2.の場合だけど、2引数を取るplusメソッドをもった型PlusOp[T]みたいな型を定義してやって、
PlusOp[T]をimplicit parameterとしてPointのコンストラクタの渡すようにしてやる。こちらの場合、
余計なオブジェクトの生成は避けられるが、x + yと書くことができず、num.plus(x, y)みたいに書かなければ
いけないのでちょっと美しくない。

trait PlusOp[T] {
def plus(x:T,y:T): T
}

object PlusOp {
implicit object IntPlus extends PlusOp[Int] {
def plus(x:Int,y:Int) = x + y
}
implicit object DoublePlus extends PlusOp[Double] {
def plus(x:Double,y:Double) = x + y
}
}

case class Point2[T](x:T,y:T)(implicit num: PlusOp[T]) {
def +(that:Point2[T]): Point2[T] = {
Point2[T](num.plus(x,that.x),num.plus(y,that.y))
}
}

object Run {
def main(argv:Array[String]) {
val p,q = Point2(3,5)
println(p+q)
val r,s = Point2(3.5, 4.5)
println(r+s)
}
}

347 : ◆CgacaMDhSQ :2010/07/14(水) 17:36:11
ちなみに、今回の例の場合、Scala 2.8ではNumeric[T]というtraitが定義されているので、自前で
PlusOpみたいなtraitを定義する必要は無く、以下のように書くことができる。

import scala.math.Numeric

case class Point2[T](x:T,y:T)(implicit num: Numeric[T]) {
def +(that:Point2[T]): Point2[T] = {
Point2[T](num.plus(x,that.x),num.plus(y,that.y))
}
}

object Run {
def main(argv:Array[String]) {
val p,q = Point2(3,5)
println(p+q)
val r,s = Point2(3.5, 4.5)
println(r+s)
}
}

implicit conversionとimplicit parameterそのものに関する解説はここですると長くなってしまうので、
必要であれば、Web上にあるドキュメントを読むなり、Scala本を買うなりしてください。

348 :デフォルトの名無しさん:2010/07/14(水) 17:37:07
> ひょっとしてC++ or D系の言語から来た人かな?
はい、その通りでございます。
Swing使いたいけど、Javaはヤダっていうわがまま。

def +(that:Point[U]): Point[T] = Point[T](x+that.x,y+that.y)
と書いてみて「Uなど存在しない」と怒られたり・・・(トホホ)。
やっぱJava系の型計算をよく分かってないせいでしょうかね。
標準で使えるオブジェクトの種類が多すぎて的を絞れていないです。

> で、解決策だけど
手元にコップ本はあるので、そこら辺をよく読んでみます。
毎度大変助かります。


349 :デフォルトの名無しさん:2010/07/14(水) 17:41:18
うわ、返信書いてる間に・・・。
親切すぎる!

350 :デフォルトの名無しさん:2010/07/14(水) 17:57:11
おぉ、コップ本21章は必読ですね。implicitマジックやな、これは。

implicit def 名前テキトー(x:Double) = x.toInt
を勝手に探しにいったりするわけですか。
・・・うかつな使いかたをするとエラーの所在を当てるのが難しくなりそうですね。


351 :デフォルトの名無しさん:2010/07/14(水) 19:27:27
コップ本の31章の一番最後(573ページ)に、

>パーサー生成でLALR(1)のような効率のよい解析アルゴリズムが使える。・・・(途中略)
>誰かがそのようなジェネレーターを作れば、それは標準Scalaライブラリーに簡単に統合できるだろう。

とか書いてあるけど、誰か作ってる人いるの?(もしくは実はもう出来てるとか?)

これは著者は作る気ないけど"誰か作ってくれないかなぁ〜"ってことなのかな?

352 :デフォルトの名無しさん:2010/07/14(水) 22:18:17
もうすぐ2.8が正式リリースされるだろうけど
コップ本の内容って役に立つよね?
買おうかどうか悩んでる。

353 :デフォルトの名無しさん:2010/07/14(水) 22:23:38
>>352
9割以上はそのままじゃなかろうか。

354 :デフォルトの名無しさん:2010/07/14(水) 23:28:57
>>352
ほかにいい本ないしね。買ったほうがいいよ。


355 :デフォルトの名無しさん:2010/07/15(木) 01:51:05
ついにキタ!
Scala 2.8.0.final
http://www.scala-lang.org/node/7009

356 :デフォルトの名無しさん:2010/07/15(木) 01:53:08
ついにfinal RCか。

357 :デフォルトの名無しさん:2010/07/15(木) 05:24:45
(* ̄∇ ̄)/゜・:*【2.8.0 final】*:・゜\( ̄∇ ̄*)

358 :デフォルトの名無しさん:2010/07/15(木) 05:47:49
(* ̄∇ ̄)/゜・:*【2.8.0 final】*:・゜\( ̄∇ ̄*)

359 :デフォルトの名無しさん:2010/07/15(木) 06:07:49
(´・ω・`)人(´・ω・`)

360 :デフォルトの名無しさん:2010/07/15(木) 08:56:08
一番にキターしたかったのにorz

361 :デフォルトの名無しさん:2010/07/15(木) 10:23:08
寝る前にチェックしたときはリリースしてなかったのに(´・ω・`)

362 :デフォルトの名無しさん:2010/07/15(木) 12:10:24
Helios対応 Scala-IDEまだぁ〜待ちく(ry

363 :デフォルトの名無しさん:2010/07/15(木) 14:26:19
(;^_^ /゜・:*【2.8.0 final】*:・゜\(;^_^

364 :デフォルトの名無しさん:2010/07/15(木) 18:22:02
次の、2.8.1または2.9または3.0はいつでるの?w

365 :デフォルトの名無しさん:2010/07/15(木) 19:50:05
>>354
> ほかにいい本ないしね。買ったほうがいいよ。

「ボクらのScala ~ 次世代Java徹底入門 」
を買ったけど、思ったより良かった。

・日本人が書いているから、変な和訳はないので、読みやすい。
・洋書にありがちな、分かりやすいようで分かりにくい例え話は、ない。
・日本の出版社の本は、図とかレイアウトが丁寧で分かりやすい。
・だけど、本の題名で損している。
「ボクらの〜」という題名で敬遠している人は多いかと思うけど
「たのしいRuby」とかと同じ系統の本で、なかなか良い。
「次世代Java入門」っていう副題は、意味不明。内容的にほとんど意味なし。


366 :デフォルトの名無しさん:2010/07/15(木) 22:43:14
Scalaは自称次世代Javaだから

367 :デフォルトの名無しさん:2010/07/15(木) 22:47:56
自称してるのは、「次世代javaの先取り」だけどな

368 :デフォルトの名無しさん:2010/07/15(木) 22:51:25
先取り次世代Javaならまだよかったのに

369 :デフォルトの名無しさん:2010/07/16(金) 00:50:09

なんでmutableなのにListBufferはvalで宣言して、
しかも+=ができるの?
意味わかんなくて理解できなくて睡魔に襲われたんですけど

370 :デフォルトの名無しさん:2010/07/16(金) 01:02:58
+=っていう名前のメソッドが定義されてるから

371 :354:2010/07/16(金) 01:13:37
>>>365
ん〜〜〜・・・初心者にはいいのかもしれないが、ある程度Javaとか知ってるなら、コップ本以外ありえないと思うんだけどなぁ。
自分的は、コップ本で理解できるから、他の本は内容薄くて、まったく買う価値が見いだせないっていう感じ。

>変な和訳、分かりやすいようで分かりにくい例え話、
この辺はどんな洋書の和訳でもそういうものだし、別にコップ本はそういうのあまりないと思うけど。
っていうか、そういう翻訳されたものとか結構読んでるから、洋書独特の例え話とか慣れてしまって、意識すらしてなかったな。




372 : ◆CgacaMDhSQ :2010/07/16(金) 01:23:04
>>369
オブジェクトがmutableということと変数がmutableということを混同している
valは、あくまでその変数に再代入不可ということを保証するだけで、その変数が指す先の
オブジェクトがmutableであるかどうかは関知しない。+=に関しては、>>370の言う通り、そういう
名前のメソッドがListBufferに定義されているからだね。

373 :デフォルトの名無しさん:2010/07/16(金) 02:05:33
ListBufferはインチキしてるから。
インチキの実態は、コップ本に詳しく書いてある。

外向きには関数型言語っぽいけど、ライブラリ内部は全然そうじゃない、ってとこが
Scalaの特徴のひとつだろう。これには幻滅する人も何割か居そう。


374 :デフォルトの名無しさん:2010/07/16(金) 02:23:38
ScalaでのSymbolってどういうときに使えばいいの?

記法上は組み込みで特別な構文があるけど、Rubyとかと違って、
実態は単なる普通のクラスと何ら変わりないわけだし、
パフォーマンス考えたら、JVMの仕様上、Stringで代用したほうが、速そうな気がするんだけど。

(比較するのは速いかもしれないけど、生成するのにコストがかかる?
JVMはStringは特別扱いするけど、JVMから見ればSymbolは単なる普通のクラスでしかないよね?)


コップ本にも1ページ分くらいしか載ってないし・・・

375 :デフォルトの名無しさん:2010/07/16(金) 02:30:29
>>373
>外向きには関数型言語っぽいけど、ライブラリ内部は全然そうじゃない

パフォーマンスのこと考えてるんだろうから、それは正しい選択だと思うが・・・
幻滅する人はHaskellでもやればいいよ

376 :デフォルトの名無しさん:2010/07/16(金) 10:56:07
>>375
Dみたいにconst(final)とimmutableを区別できるのはメリットがあると思うけどな

377 :デフォルトの名無しさん:2010/07/16(金) 22:41:59
>オブジェクトがmutableということと変数がmutableということを混同している
なるほど…!理解した

378 :デフォルトの名無しさん:2010/07/17(土) 10:24:55

val x = numbers.head
val y = numbers.last
val r = numbers.tail

ボクらのScalaでListの変数名を r にしてるんだけど、
これってどういう意味合いかわかりますか?
range の意?
(挫折した) Haskellだと複数形の s つけて xs ってしてたような

379 :デフォルトの名無しさん:2010/07/17(土) 11:10:17
restですかね
いやさっぱりわかりませんが

380 :デフォルトの名無しさん:2010/07/17(土) 11:51:44
>>378
一時変数で適当につけてるみたいだし意味ないんじゃないの?
そもそも、rのいみわからなくて、そのxとyの意味あいはわかった?

ループ変数のi,jに意味求めるようなものだろう。元の意味や語源はあるけど意識してはつかってない

真意は著者に聞いたほうが早いと思う

381 :デフォルトの名無しさん:2010/07/17(土) 12:55:35
i, j, k とか x, y とか n は数学的なものでしょ
意味合いも理解できるし、なによりいろんなプログラミング言語でも使われてる

382 :デフォルトの名無しさん:2010/07/17(土) 13:37:01
i,j,kはFORTRANから。初期のFORTRANは整数型の変数名にI,J,K…しか
付けられなかったためいまだにその名残がある。

それよりscalaはすごく遅いのだがそういうものなんだろうか?

383 :デフォルトの名無しさん:2010/07/17(土) 14:40:09
>整数型の変数名にI,J,K…しか付けられなかったため

宣言しなかった場合だけだろ

384 :デフォルトの名無しさん:2010/07/17(土) 15:04:18
初期のFORTRANには宣言が無い。

385 :デフォルトの名無しさん:2010/07/17(土) 16:18:35
restの頭文字とったんじゃないの
head/tail = first/rest = car/cdr

386 :デフォルトの名無しさん:2010/07/17(土) 16:23:19
(゚Д゚)クダー

387 :デフォルトの名無しさん:2010/07/17(土) 17:37:51
>>385
追加
head/tail = first/rest = car/cdr = x/xs

本当はX|Xsと書きたい

388 :デフォルトの名無しさん:2010/07/17(土) 19:07:09
>>387
> 本当はX|Xsと書きたい
しかし、こういう命名をすると次にXsをheadとtailにわけるとき、名前に困るという罠が

389 :デフォルトの名無しさん:2010/07/17(土) 19:09:11
yとysでおk

390 :デフォルトの名無しさん:2010/07/17(土) 19:18:07
つーか再帰して今のXsが次のXとXsに分けられるだけだろ
なんで違う名前が必要なんだ?

391 :378:2010/07/18(日) 01:15:32
著者にTwitterで聞いてみたら、
書いたときは remainder のつもりだったんじゃないかなと思います。 とのこと


392 :デフォルトの名無しさん:2010/07/18(日) 01:20:32
著者に気軽に質問ができるなんて、ホント便利な世の中になったもんだ

393 :デフォルトの名無しさん:2010/07/18(日) 12:18:02
javaの
static class X {
static { ... }
}
(staticオブジェクトが初めて起動されたときだけ実行される)
と同じことをScalaでやろうとすると、

object X {
{
println(new java.util.Date())
}
def exec() = println("world!")
}
X.exec()
X.exec()

これで良さそうですが、
def init() { ... }
みたいなマジックワードがあったりするのでしょうか?
(初期化し直したかったりする場合のため)
初期化コードが長い場合に他のメソッドが埋もれないように、
とりあえず上のように中括弧いれてみましたが、それ以外で。

394 : ◆CgacaMDhSQ :2010/07/18(日) 21:13:29
>>393
def init() { ... } みたいな初期化時に呼ばれる専用メソッドは特に無いので、
object X { ... } の中に初期化コードを直接入れるのでOK.ちなみに、{}をいれずに
直接初期化をobject直下に書いた場合、初期化コード中でしか使わないローカル変数を宣言しようと思っても、
フィールド扱いになってしまうので、そういうのを避ける意味でも初期化コードが長くなるなら、初期化
コードを{}で囲むのは良いと思う。

395 :デフォルトの名無しさん:2010/07/18(日) 21:25:11
マクロ機能はいつサポート予定ですか?

396 :デフォルトの名無しさん:2010/07/18(日) 21:33:25
これ以上複雑にされると、もうついていけない。


397 :デフォルトの名無しさん:2010/07/19(月) 02:36:26
>>391
乙乙
疑問が解けた

特に習慣的に決まっていて書いていたわけでもないのねw

398 :デフォルトの名無しさん:2010/07/19(月) 09:57:49
>>396
>これ以上複雑にされると、もうついていけない。

scala の cheat sheet でも。
http://www.bing.com/search?q=Scala+cheat+sheet

399 :デフォルトの名無しさん:2010/07/19(月) 12:39:46
>>396
なにがサポートされようが便利なら使えば良い便利でないとか判定できないなら
無視すれば良い。それで困ることがあるはずない。

400 :デフォルトの名無しさん:2010/07/19(月) 12:42:26
もっと複雑になればJRubyの需要が高まるね(ニッコリ

401 :デフォルトの名無しさん:2010/07/19(月) 14:29:56
val xs: List[Int] = eval("List(3,2)")
みたいに、リスト限定でevalをしたいのですが、
正規表現、パーサー作る、以外の簡単な方法はありますか?

402 :デフォルトの名無しさん:2010/07/19(月) 15:38:47
import scala.tools.nsc.Interpreter
val xs = (new Interpreter).evalExpr[List[Int]]("List(1,2,3)")
一応こういうのはあるけど、こう使うものなのかよくわからない

403 :401:2010/07/19(月) 16:08:34
実は正統なやり方もよくわかっていません。
Cだとsscanfで簡単に3と2を切り出せるのですが、
こういう修飾された文字列からTokenizerを使って読めるのでしょうか?
(検索するとCSVのサンプルはたくさんあるけど、あれは余計なゴミがついてないから・・・)

404 :401:2010/07/19(月) 20:24:54
なんかいじめとしか思えないのですが、
findInLineを使おうとするとmatchが使えないという・・・
ttp://webcache.googleusercontent.com/search?q=cache:YmIStkq4fN8J:ja.doukaku.org/170/nested/

405 :デフォルトの名無しさん:2010/07/19(月) 20:41:38
sscanfでは配列を読めないんじゃ…
まあ、なにをやりたいのかわからないけど、
特にこだわりがないなら内部DSLにするのがScala的なんじゃないかな
その次はパーサーコンビネーターを使う
evalはScalaではかなり邪道でしょう

ちなみにList[Int]を読み込むだけなら
パーサーコンビネーターでこのくらいで書ける
この程度なら書いたほうが早いでしょ

import scala.util.parsing.combinator.JavaTokenParsers
val parser = new JavaTokenParsers {
def list = "List" ~ "(" ~> repsep(decimalNumber ^^ (_.toInt), ",") <~ ")"
}
val xs = parser.parseAll(parser.list, "List(1,2,3)").get

406 :401:2010/07/19(月) 21:34:08
自分のケースについては完全に動作しました。ありがとうございます。
ただ、パターンの部分は勉強しないと読めませんね・・・。

407 :デフォルトの名無しさん:2010/07/19(月) 22:35:38
Google Web ToolkitをScalaでやるのって可能なの?

あれって、Javaソースコード(.java) => javascriptソースコード(.js)
へコンパイルしているんだろうけど、
Scalaソースコード(.scala) => Javaソースコード(.java) へのコンパイラがあれば、
Scalaソースコード(.scala) => Javaソースコード(.java) => javascriptソースコード(.js)

ていう感じでできるかな?(コンパイルすごく時間かかりそうだけどw)

408 :デフォルトの名無しさん:2010/07/19(月) 22:39:08
ところがだ
Javaソースコード(.java) => javascriptソースコード(.js)
にとって意味のあるコードは
Scalaソースコード(.scala)
としてはまったく無意味なコードになるであろう

409 :デフォルトの名無しさん:2010/07/19(月) 22:44:13
ちなみに以前読んだ記憶では一旦JavaのASTにはしてるけど
Javaバイトコードに落ちる前だった。

410 : ◆CgacaMDhSQ :2010/07/20(火) 00:06:32
>>407
原理的にはできるし、現状でもexperimentalなjava-srcバックエンド使えば一応できないことも無いけど
現状では十分に実用的とは言い難いってのが正直なところだと思う。一応こんなプロジェクトも
あるけど、どこまで使えるのかはちょっとわからない。
http://scalagwt.gogoego.com/

411 :407:2010/07/20(火) 02:36:59
>>410
一応プロジェクトもあるのかぁ。ありがとうございます。

412 :デフォルトの名無しさん:2010/07/22(木) 23:32:27
packageと、実際のソースがあるフォルダが対応してなくていいのって、
なんでこんな仕様になってるの?
使うときなくない?
対応してなかったら紛らわしいだけだと思うんだが。

413 :デフォルトの名無しさん:2010/07/24(土) 03:36:58
http://d.hatena.ne.jp/yuroyoro/20080809/1218253532を参考に、
下記を実行しても、コンソールには「value:world :: Empty」と出力されてしまい、
S.param("whoField")の部分が「Empty」となってしまいます。
「value:world :: :world」にならないのは何故でしょうか。

class Test {
object who extends RequestVar(Full("world"))

def show(xhtml: NodeSeq): NodeSeq = {
bind("hello", xhtml,
"whoField" -> text(who.openOr(""), v => who(Full(v))) % ("size" -> "10") % ("id" -> "whoFieldText"),
"submit" -> submit("Send", () => {println("value:" + who.openOr("") + " :: " + S.param("whoField"))}),
"who" -> who.openOr("")
)
}
}

<lift:surround with="default" at="content">
<h1>Hello Form2</h1>
<lift:Test.show form="POST">
Hello <hello:who/>
<br/>
<label for="whoField2">Who :</label>
<hello:whoField/>
<hello:submit/>
</lift:Test.show>
</lift:surround>

414 :デフォルトの名無しさん:2010/07/24(土) 18:24:22
抽象型って抽象メソッドとかと違って実装しなくてもコンパイルできんだな、なんでこんなんなの?

trait Hoge {type A}
class Fuga extends Hoge //コンパイルできる

415 : ◆CgacaMDhSQ :2010/07/25(日) 14:10:24
>>414
抽象型はそれだけでも、「何だかわからない不明な型」みたいに型チェッカに扱われるので、コンパイル通る。

416 :デフォルトの名無しさん:2010/07/25(日) 15:05:50
プログラムの実行ファイルってみんなどうやって作ってるんだろ?
eclipseとかnetbeansにそういう機能がついてんの?

417 :デフォルトの名無しさん:2010/07/25(日) 15:45:14
416みたいな人(失礼!)でも使うくらい、scalaって知名度があるんだな。
少し見直した。


418 :デフォルトの名無しさん:2010/07/26(月) 10:10:11
まぁ裏でMavenが何やってるか知っておきたい気はする


419 :デフォルトの名無しさん:2010/07/26(月) 23:34:38
>>412

package scala.collection
package immutable

とした場合と、

package scala.collection.immutable

とした場合にスコープが違くなるとかそういう話?

420 :デフォルトの名無しさん:2010/07/27(火) 06:51:27
scalaは書き方が好きなんだけどいざ使ってみるとすごく遅い。
単純なプログラムでも起動してから最初の結果を得るまでに1秒くらいかかるけど
インストールでへまやったんだろうか? みんなもこんなに遅い?

421 :デフォルトの名無しさん:2010/07/27(火) 08:58:09
>>420
eclipseとかつかってる?
コンパイル(と起動)が遅いだけで、実行スピードは、Javaと対して変わらないよ。
System.currentTimeMillisとかで、起動したときと、終了する前の時間調べればわかるけど

422 :デフォルトの名無しさん:2010/07/27(火) 09:14:41
そんなあなたにfsc

423 :デフォルトの名無しさん:2010/07/27(火) 09:27:52
起動が遅いのはJVM系言語の共通の弱点だね
コンパイルが遅いのは、もうちょっと頑張ってほしい

424 :デフォルトの名無しさん:2010/07/27(火) 12:38:59
レスサンクス。
>>421
eclipseは使ってない。起動に1秒くらいかかるだけで処理が始まってからの時間は
lispと大きく変わらないようだ。

>>422,>>423
両方早いにこしたことは無いが実行時間が早くなってほしい。jruby,jython,clojureも
同じ状況なんだろうな。

425 :デフォルトの名無しさん:2010/07/27(火) 18:19:07
質問です。

scala2.8で
val list = nw ListBuffer[(Int, String)]
list += (1, "a")
とすると、下記のようなエラーがでます。

<console>:8: error: type mismatch;
found : Int(1)
required: (Int, String)
list += (1, "a")
^

ちなみに2.7.7.finalだと正しく動作します。これってなんで。

426 :425:2010/07/27(火) 18:26:01
list += Tuple2(1, "a")
だと上手くいきました。
なんか2.8で変わったのかな。

427 : ◆CgacaMDhSQ :2010/07/27(火) 18:26:04
>>425
ListBufferのAPIドキュメント
http://www.scala-lang.org/docu/files/api/scala/collection/mutable/ListBuffer.html
見ればわかるんだけど、
def +=(elem1: A, elem2: A, elems: A*): Growable[A]
というシグネチャの可変長引数のメソッドがある(2.7では無かった)。そのため、
list += (1, "a")
というのが、可変長引数のメソッド呼び出しと解釈されてしまうため、第1引数がIntで第2引数がStringで、
という風になっちゃうわけだ。しかし、ListBuffer[(Int, String)]の場合、各引数は(Int, String)でないといけない
から型が合わなくてエラーになる。回避するには、
list += (1 -> "a")
のように->演算子を使うか、
list += ((1, "a"))
のように括弧を余計に入れて、可変長引数バージョンでなく1引数バージョンのものだと解釈させる
ようにする。個人的には、->演算子使う方が好みかな。

428 :デフォルトの名無しさん:2010/07/27(火) 18:45:33
>>427
理由まで説明してくださり勉強になりました。
有難うございます。

429 :デフォルトの名無しさん:2010/07/27(火) 18:51:12
この話、前もあったよね
意外とひっかかるポイントなのかも
タプルは->を使うというのがScalaの豆知識だね

430 :デフォルトの名無しさん:2010/07/27(火) 21:54:29
lift使いの皆さんはストレージとのやりとりに
mapper and recordとJPAどっちつかってる?

jpaの方がejbにそっててなじみがあるので良いような気がするんだけどどうなんだろ。


431 :デフォルトの名無しさん:2010/07/28(水) 00:58:51
>>429
要素が3つ以上の時は -> だと駄目だよね

432 :デフォルトの名無しさん:2010/07/28(水) 07:02:23
>>422-424
Scala気になってるんですが、
こういうのってハックみたいなもので解決する方法ってあるんでしょうか?

Rubyなんかだと、素のRubyは速いけれどライブラリたくさんよむとやたら重くなって
テスト実行時にDRbだかRubyのサーバー?みたいなのを裏で立てておいてライブラリの読み込みを高速化する方法とかあったけど
webアプリは開発モードだと必要なものだけリロードできるし


433 :デフォルトの名無しさん:2010/07/28(水) 07:33:35
いくら起動が遅いと言ってもインタプリタが動的に読み込むよりは早いんじゃないの

434 :デフォルトの名無しさん:2010/07/28(水) 14:56:47
ブーチ「ただ、現在、わたしの興味を引く言語の1つとして、
Scalaを挙げることができる。なぜなら、伝統的な言語である
C/C++でもFORTRANでも隠ぺいできていなかった並行性の問題に
Scalaは光を当てているからだ。」
http://www.itmedia.co.jp/enterprise/articles/1007/28/news032.html

>>423-424
Groovyだとこんなのあるね。
ttp://d.hatena.ne.jp/nobeans/20100309/1268149199

435 :デフォルトの名無しさん:2010/07/28(水) 18:08:25
>>432
fscはそういうアプローチなのでは。
実行はOSGiバンドルでやるとJVMの起動分は早くならないかな?

436 :デフォルトの名無しさん:2010/07/31(土) 09:28:44
ターミナルもう一つ立ち上げてsbtで監視がFA

437 :デフォルトの名無しさん:2010/07/31(土) 09:33:15
sbtのことサバトってよんでもいいかな

438 :デフォルトの名無しさん:2010/07/31(土) 09:43:18
スブタにしようぜ

439 :デフォルトの名無しさん:2010/07/31(土) 16:51:07
質問させてください

import scala.util.control.Exception.catching
def castToInt(v: Any): Option[Int] = catching(classOf[ClassCastException]) opt v.asInstanceOf[Int]

こういう関数を定義すると

scala> castToInt(24)
res1: Option[Int] = Some(24)

scala> castToInt("abc")
res2: Option[Int] = None

こういう実行結果になると思います。

def cast[T](v: Any): Option[T] = catching(classOf[ClassCastException]) opt v.asInstanceOf[T]

そこでこういう関数を定義して castToInt の汎用版を作りたいと思ったのですが

scala> cast[Int](24)
res3: Option[Int] = Some(24)

scala> cast[Int]("abc")
res4: Option[Int] = Some(abc)

こうなってしまいます。なぜこのような挙動をするのでしょうか?ちなみに、

scala> res4.get
java.lang.ClassCastException

となるので、get したときに初めて ClassCastException が発生しているようです。

440 :デフォルトの名無しさん:2010/07/31(土) 21:27:52
asInstanceOfはコンパイラ向けであって、
実際にキャストしてるというわけじゃないんだろうね
Manifestを使ってクラスを取ってきて無理矢理キャストしてみるとか?
まあ、そんな関数作らないほうがいいよねw

441 :デフォルトの名無しさん:2010/07/31(土) 22:18:13
>>439
JVMつかってることによるscalaの型システムの限界かな

442 :441:2010/07/31(土) 22:42:32
こんなふうな関数つくって

def cast[T](t:T)(v: Any):Option[T] = {
try{
Some( t.asInstanceOf[AnyRef].getClass.cast(v).asInstanceOf[T] )
}catch{
case e:ClassCastException => None
}
}

第一引数に、castしたい型のオブジェクトの実態をいれれば
どうにかそれっぽいことできるけど・・・(´・ω・`)カッコ悪い・・・


scala> cast(0)("abc")
res0: Option[Int] = None




443 :439:2010/08/01(日) 00:43:05
>>440-442
ありがとうございます。Manifest 調べてみます。classOf[T] もできないんですね。
もともとやりたかったのは、例えば KVM のようなデータストアにアクセスする以下のような Java のライブラリがあったときに

interface Store {
 Object get(String key);
 void set(String key, Object value);
}

これに対して Scala らしいインターフェースのラッパーを作りたかったんです。そこで

class Wrapper(store: Store) {
 def apply[T](key: String): Option[T] = {
  val value = store.get(key)
  if (value == null) None
  else catching(classOf[ClassCastException]) opt value.asInstanceOf[T]
 }
 def update(key: String, value: Any) {
  store.set(key, value)
 }
}

というのはどうかなと思ったところうまくいかなくて、先ほどの質問をしました。
静的型の言語に慣れてないのでうまいやり方がわからないのですが、
皆さんだったらどのようなインターフェースにしますか?

444 :デフォルトの名無しさん:2010/08/01(日) 01:04:37
そうか、Manifestでクラスを取ってきてもBoxingできないんだね
まあ、自力でテーブル作ればいいけど

445 :デフォルトの名無しさん:2010/08/01(日) 01:15:40
>>443
いや、それはキャストエラーをNoneで潰しちゃ駄目なんじゃない?
見つからないのか、型が違うのか、区別したほうがいいと思う

446 :439:2010/08/01(日) 01:34:51
manifest 使ってみました。こういうことでしょうか。

def cast[T <: AnyRef](v: AnyRef)(implicit m: reflect.Manifest[T]): Option[T] =
 catching(classOf[ClassCastException]) opt m.erasure.cast(v).asInstanceOf[T]

AnyRef を Any にしたければテーブル作れって事ですね。


>>445
確かにそうですね。
目的と違う型ならどうせ利用できないから無いも同然でもいいかと思ってこうしました。
少なくとも厳密なAPIは別に必要ですね。

447 :デフォルトの名無しさん:2010/08/01(日) 01:44:33
静的型言語でキャスト失敗するって99%バグだからね
むしろ、そうやって型を活かすように書くべきというか
だからキャストエラーなんてそのまま上に投げちゃって構わない

448 :439:2010/08/01(日) 02:22:15
確かにバグ以外は思い浮かびません。
catching の方は消すことにします。
アドバイスありがとうございます。

最初 Option[T] にせず T をそのまま返してたので気づかなかったんですが、
Option[T] にすると型推論も効かなくなるみたいなのでもうすこし考えてみます。

449 :デフォルトの名無しさん:2010/08/03(火) 18:26:36
いつのまにやら、helios用のscalaプラグインがでていたようですな

(´・ω・)つ
ttp://download.scala-ide.org/
ttp://download.scala-ide.org/nightly-update-helios-2.8.0.final



450 :デフォルトの名無しさん:2010/08/03(火) 20:09:26
>449 コレ使うと、liftのビルドおかしくなるのかな、やっぱ。

451 :デフォルトの名無しさん:2010/08/04(水) 17:24:58
やっとheliosにscalaプラグインインストールできた&かなり良くなってる

129 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)