プログラミング言語 Scala

プログラミング言語 S ..

2:デフォルトの名無しさん
08/03/10 23:06:25
不感症になったのか、こーいうのみてもなんも感じなくなってしまった

3:デフォルトの名無しさん
08/03/10 23:08:04
日本語の入門書がでたら買う。

4:デフォルトの名無しさん
08/03/10 23:28:11
Java のライブラリがそのまま使えるってのは
ライブラリ実装の手間を省けるいいやり方だな。

5:デフォルトの名無しさん
08/03/11 11:47:44
Javaのgenericsはそのまま使えないと聞いた気が

6:デフォルトの名無しさん
08/03/11 23:12:02
>>5
URLﾘﾝｸ(www.scala-lang.org)
Version 2.7.0-final (released on 06-Mar-2008)
# [changed] - Generic Java types are now supported by default (was -Ygenerics).
# [changed] - Target jvm-1.5 is now the default.

7:デフォルトの名無しさん
08/03/12 00:19:52
>>5-6
試してみた

$ scala -version
Scala code runner version 2.7.0-final -- (c) 2002-2008 LAMP/EPFL

$ cat generics.scala
import java.util._
var list = new ArrayList[String]
list add "one"
list add "two"
list add "three"
println( list size )
println( list )

$ scala generics.scala
3
[one, two, three]

8:デフォルトの名無しさん
08/03/12 00:33:29
チュートリアル日本語訳
URLﾘﾝｸ(homepage.mac.com)

↑を読んでたんだけど「ケースクラス」っていうのがよくわかんなかった。
多態性みたいなのが簡単に記述できますよってことなのかな
よくわかんないまま読み進めてたらいきなり微分の話が出てきて頭が爆発した。

9:デフォルトの名無しさん
08/03/12 01:27:25
>>8
MLとかHaskellにあるやつで、
要は強力なcase文、なはず

でもcase文だから下手に使うと拡張性を失うわけだよね

10:デフォルトの名無しさん
08/03/12 08:26:14
ものすごい説明でびっくりした。「MLとかHaskellにあるやつで」までしかあってないよ！

11:9
08/03/12 12:24:00
>>10
む、そんなに間違ってる?

拡張性と言ったのは、既存のコードを修正せずに型を追加できるかという話で、
型の定義の追加に関してはたいていの関数型言語では構文上無理な気がするが、
Scalaはcase classを別の場所であとから追加すれば可能な気がする。

一方、パターンマッチのコードは一カ所にまとめないといけないから、
拡張しようとしたら修正が必要では?

12:デフォルトの名無しさん
08/03/12 22:00:57
んー、言いたいポイントがよく理解できないんだけど、
まずmatch構文の中で特殊に使える「クラス定義」であって、case「文」じゃないでしょっていうのと、
MLやHaskellを引き合いに出して1行で説明しようとするなら「元々は代数データ型を模すためのもの」とでもいうのが適切では？と思った。

拡張性云々はOCamlのポリモーフィックヴァリアントと比較すると面白いかもしれないけど、
8に対するレスとしては飛びすぎではないかな。

13:9
08/03/13 00:02:03
>>12
>>8が多態性と書いていたので拡張性に関する話をふってみた。
代数データ型をといわれてもピンとこないんだが...
MLやHaskellを引き合いに出さない方がよかったか。

14:8
08/03/13 01:08:58
まだよくわかってないけど
「関数型言語ではよくあること」ってことね
JVMで動く言語って聞いたのでJavaの知識が役に立つかと思って触れてみたのだけど
Javaしか知らない俺には難しい

よく考えてみたら多態性は継承で実現できるのだから
ケースクラスってのは、多態性とは違う何か得体のしれない概念なのだろうなあ
pdfをもうちょっとよく読んでみるよ

15:デフォルトの名無しさん
08/03/13 01:44:40
ちょっとメモ
URLﾘﾝｸ(www.ibm.com)

16:デフォルトの名無しさん
08/03/14 01:50:55
>>14
case classもクラスの一種なので多態性を実現するのにも使える
ただ、case classで定義したクラスは
・クラス名(引数列)でインスタンスを生成できる
・パターンマッチングに使える
という特徴がある。具体例を示した方が早いと思うので示すと

abstract class Exp
case class Add(lhs :Exp, rhs :Exp) extends Exp
case class Sub(lhs :Exp, rhs :Exp) extends Exp
case class Num(value :Int) extends Exp

という定義があったとして、(5 - 3) + 1という式の構文木は次の
ように表記できる。

val exp :Exp = Add(Sub(Num(5), Num(3)), Num(1))

この式を計算する評価器はパターンマッチングを使って
次のように書くことができる(MLとかHaskell知っている人には
お馴染みだけど)。

def eval(exp :Exp) :Int = exp match {
case Add(l, r) => eval(l) + eval(r)
case Sub(l, r) => eval(l) + eval(r)
case Num(n) => n
}

ここでポイントは、インスタンスのクラスによる分岐と、インスタンスから
フィールドを取り出す操作が同時に行えていること。

17:デフォルトの名無しさん
08/03/14 07:17:08
>>16
なんとなく分かってきた
昔聞いたことのあるインタープリターパターンに似てる

メンバ変数を定義して、コンストラクタで代入っていうのを書かなくても
クラス名（引数列）　って書いたら引数列の部分がが勝手にメンバ変数になってくれるのか

Javaで構文木みたいなの作ろうとしたら
URLﾘﾝｸ(anond.hatelabo.jp)
↑こんな感じになったよ（長い！）

18:デフォルトの名無しさん
08/03/14 07:24:35
eval()を外に出すと

public int eval(Exp exp){
　if(exp instanceof Add){
　　return exp.getHidari() + exp.getMigi();
　}else if(exp instanceof Sub){
　　return exp.getHidari() + exp.getMigi();
　}else if(exp instanceof Num){
　　return exp.getSelf();
　}
}

こんな感じにしないといけなくて
こんなif文をズラズラと書くよりだったら
それぞれのクラスの中でeval()するべきだろうって思っちゃうので
理解するのが難しかったんだ

19:デフォルトの名無しさん
08/03/14 07:28:02
あ、間違えた

　public int eval(Exp exp){
　　if(exp instanceof Add){
　　　return eval(exp.getHidari()) + eval(exp.getMigi());
　　}else if(exp instanceof Sub){
　　　return eval(exp.getHidari()) + eval(exp.getMigi());
　　}else if(exp instanceof Num){
　　　return exp.getSelf();
　　}
　}

こうか

20:デフォルトの名無しさん
08/03/14 09:46:06
>>18
>>19
ごめん。Subを計算するときにも足しちゃってた。
正しいのはこう。
def eval(exp :Exp) :Int = exp match {
case Add(l, r) => eval(l) + eval(r)
case Sub(l, r) => eval(l) - eval(r) // Subなのにミスって足してた
case Num(n) => n
}
あと、パターンマッチングは本質的にはif(a instanceof A) ... else if(a instanceof B) ...を
簡潔に書くための仕掛けでしかないけど
・フィールドからの値の取り出しを同時に行える
・パターンをネストできる(後述)
・パターンが網羅されているかを静的にチェック可能(後述)
のがポイント。パターンがネストできるというのは、例えば
exp match {
case Sub(Add(e1, e2), Add(e3, e4)) => println("(e1 + e2) - (e3 + e4)")
case _ => println("failure")
}
のようにすることで、複雑な構造に対してマッチングを行うことができること
を示している

21:デフォルトの名無しさん
08/03/14 09:46:41
続き。
パターンが網羅されているかを静的にチェック可能というのは、
例えば次のようなコードを書いたときに(Numのパターンの書き忘れ)、コンパイラが
warningを出してくれることを指している。
def eval(exp :Exp) :Int = exp match {
case Add(l, r) => eval(l) + eval(r)
case Sub(l, r) => eval(l) + eval(r)
}
ただし、Scalaでこの場合にwarningを出すためには、宣言を
abstract sealed class Exp
case class Add(lhs :Exp, rhs :Exp) extends Exp
case class Sub(lhs :Exp, rhs :Exp) extends Exp
case class Num(value :Int) extends Exp
のように、抽象クラスであるExpをsealedとして宣言しておく必要がある。

22:デフォルトの名無しさん
08/03/15 00:54:41
とりあえず A Scala Tutorial for Java programers を読んだのですが
次は何を読めばいいですか？
どうもプログラミング言語の学習の仕方がいまだによくわからなくて困ってます。

23:デフォルトの名無しさん
08/03/15 01:34:52
>>22
とりあえず、何かネタを決めて適当なプログラムを書いてみるのが
良いと思う。Scalaやってるってことは他の言語は既に知ってるってこと
だろうから、とにかく書いて慣れるのが一番。あと、ScalaReference.pdfは
読むのにやや知識が必要だけど、Scalaにどんな機能があるのかを知るのに
有用だから、暇なときに眺めてみるのも良いかも

24:デフォルトの名無しさん
08/03/15 01:46:48
日本語の入門書がまだないのはしょうがないとして。。。
洋書だったらなんかある？

25:デフォルトの名無しさん
08/03/15 01:53:40
>>20-21
丁寧にありがとう！

sealed（シールド） class なんてのがあるんだ
また守備力があがってしまうな

26:デフォルトの名無しさん
08/03/15 01:55:08
Java 系だから final でいいと思うのに
C# 風の名前付けしてるんだな。

27:デフォルトの名無しさん
08/03/15 02:06:23
>>26
いや、実はfinal classもあるんだけど、sealedとは意味が違うという罠
final classはJavaのそれと同じで、そのクラスから継承することができない
という意味。sealed classは同じコンパイル単位でならそのクラスから継承する
ことができる

28:デフォルトの名無しさん
08/03/15 02:08:49
>>24
洋書では、Programming in Scalaという本が(今年中？)出る予定。
現在は、PrePrint版を購入することができる。
URLﾘﾝｸ(www.artima.com)

29:デフォルトの名無しさん
08/03/15 02:09:40
>>27
なるほど。

30:デフォルトの名無しさん
08/03/15 02:11:46
>>27
なるほど

31:デフォルトの名無しさん
08/03/15 02:16:44
URLﾘﾝｸ(www.scala-lang.org)
を読んでたんだけど（読めないけど）
予約語の一覧に「public」が見当たらない

しかも
AccessModifier ::= (‘private’ | ‘protected’) [AccessQualifier]
って書いてある。

もしかしてScalaには「public」修飾子がない？
クラスもメンバもみんなデフォルトでpublic？

32:デフォルトの名無しさん
08/03/15 02:22:19
>>28
サンクス
今年中か。。
英語の勉強でもしとくか・・・

33:31
08/03/15 02:27:08
試してみればよいのか

scala> var public = 1
public: Int = 1

scala> System.out.println( public )
1

あぁ…　無いんだ

34:デフォルトの名無しさん
08/03/15 02:27:47
>>31
うん。Scalaではアクセス修飾子はデフォルトでpublicなので
用意されてない。

35:デフォルトの名無しさん
08/03/15 12:14:16
>>27
jarのマニフェストに書くSealedと同じようなものか。

36:デフォルトの名無しさん
08/03/15 15:53:01
>>8
case classは、
pattern matchのある
C言語でいうところのunionです。

一つの型にマージしたいところに使います。
例えばポインタがどのケースも指す可能性がある場合。

37:デフォルトの名無しさん
08/03/15 21:42:49
Rubyとどっちが強いの？

38:デフォルトの名無しさん
08/03/15 21:49:33
Scalaです。普及度以外は。

39:デフォルトの名無しさん
08/03/15 22:04:37
Rails相当のものはありますか？

40:デフォルトの名無しさん
08/03/15 22:08:04
Javaの標準ライブラリなら何でも使えるの？

41:デフォルトの名無しさん
08/03/16 01:44:44
traitとabstract classの違いって何ですか？
なんか、同じのような……。

>>40
多分そうです。

42:デフォルトの名無しさん
08/03/16 02:13:39
>>41
abstract class は抽象クラスで trailtはmixin
継承元としての抽象クラスはひとつしか指定できないけど、mixinはなんぼでも指定できる。

abstract class 通信機
trait テレビ
trait おサイフ
class 携帯電話 extends 通信機 with テレビ with おサイフ {
　…
}

43:デフォルトの名無しさん
08/03/16 02:22:25
class A extends B とした場合、
継承だと B に A の実装を追加したものが A になるし、
mixin だと A に B の実装を追加したものが A になる。
継承と mixin の大きな違いはここにある。

>>1 のチュートリアルにある例で言えば、
Ord の実装の中に

　def <=(that: Any): boolean =
　　(this < that) || (this == that)

ってのがあるけど、Ord の中には == の実装どころか宣言すらない。
mixin 先に == があれば使えるし、無ければ使えない。
== が既にあるクラスに mixin されることを前提に作られている。

44:デフォルトの名無しさん
08/03/16 02:28:46
つまり、mixin の場合は A にある実装を B で使うことができる。
継承では派生クラスの情報を基底クラスで使うことになるから、
こういうことは基本的にはできない（CRPT は例外だが）。

45:デフォルトの名無しさん
08/03/16 14:55:02
CRPTって何?

46:デフォルトの名無しさん
08/03/16 18:48:17
URLﾘﾝｸ(en.wikipedia.org)

要するに親クラスが派生クラスの実装に依存できる。
boostのiterater_facadeで非常にうまく使われてる。

47:デフォルトの名無しさん
08/03/17 08:24:53
mixinがあれば継承はなくてもいいのかな
overrideができないのかも知れないが

48:デフォルトの名無しさん
08/03/17 10:15:18
Scala的に望ましい言語仕様と、JVMのセマンティクスとの軋轢ってないの?

YASVﾏﾀﾞｰﾁﾝﾁﾝ。

49:デフォルトの名無しさん
08/03/17 10:17:58
>>22
次に読むべきはたぶん、このへん。
URLﾘﾝｸ(www.pana-wave.com)

50:デフォルトの名無しさん
08/03/17 11:11:29
「スカラー値」とかの普通名詞じゃなくてなんかの固有名詞で
響きが脳みそのどっかにひっかかってたんだけど

これだったか・・・

51:デフォルトの名無しさん
08/03/17 22:44:57
The Scala Language Specificationとかにさっと手が伸びるような人は
画面で読んでるのでしょうか?
印刷して読んでるのでしょうか?

52:デフォルトの名無しさん
08/03/17 23:06:46
印刷一読、画面参照

53:デフォルトの名無しさん
08/03/19 23:08:23
初ほしゅ・・・って、まだ不要なのか？

54:デフォルトの名無しさん
08/03/22 20:14:39
なぜ素直にJRubyをつかわないのか

55:デフォルトの名無しさん
08/03/22 21:30:09
JRubyってアプレット作れるの？

56:デフォルトの名無しさん
08/03/22 21:33:55
作れるけどなに？

57:デフォルトの名無しさん
08/03/22 21:44:01
Rubyは危険な宗教だから近づきたくない

58:デフォルトの名無しさん
08/03/22 21:46:35
モルモン教か

59:デフォルトの名無しさん
08/03/22 21:48:17
>>54
やっぱスピードじゃない？

60:デフォルトの名無しさん
08/03/23 02:41:29
>>54
型チェックに魅力を感じるからじゃない

61:デフォルトの名無しさん
08/03/23 03:57:02
代入式がUnitを返すのですが、こういう仕様なのですか？

62:デフォルトの名無しさん
08/03/23 05:15:27
うん

63:デフォルトの名無しさん
08/03/23 05:26:08
Scalaは面白いしそこそこ使えそうではあるんだけど
構文を導入せずに見た目の帳尻だけ合わせてる部分が
長い目でみればマイナスに表れるという感がぬぐえない。
丁度C++のような立ち位置だと思うこともあって、将来的な筋の悪さを感じる。
(C/オブジェクト指向/C++ と Java/関数型/Scala という対比。)

64:デフォルトの名無しさん
08/03/23 08:29:46
>>63
C++のような立ち位置といのは言い得て妙だな

65:デフォルトの名無しさん
08/03/23 08:31:24
途中で送信してしまった。
ただ、構文を導入せずに見た目の帳尻だけ合わせてるってのは
どの辺だろう？case class/pattern matchingの辺り？

66:デフォルトの名無しさん
08/03/23 14:54:43
>>63
おいおい、Scalaは設計センスはすごくいいぞ。
ありとあらゆる言語をよく研究した結果作られた言語。
問題は流行るかどうか。

うまく作りすぎてるんで、
perl/python/rubyなんかのなんちゃって言語よりは、
最初のハードルが高いし。

67:デフォルトの名無しさん
08/03/23 14:56:39
ScalaってHaskellかOCaml
強いて言えばどっちに近いですか？

68:デフォルトの名無しさん
08/03/23 16:09:26
OCamlじゃないかな。評価戦略とオブジェクト指向。

69:デフォルトの名無しさん
08/03/23 19:57:06
>>66
> ありとあらゆる言語をよく研究した結果作られた言語。

は

> おいおい、Scalaは設計センスはすごくいいぞ。

の根拠にはならんだろう。

70:デフォルトの名無しさん
08/03/23 21:07:51
>>67
強いて言えばOCamlだけど
OCamlは関数型言語にOOするための機能を入れた言語
ScalaはOO言語に関数型プログラミングをするための機能を入れた言語
って感じでScalaの方がよりOOよりな感じはするね

71:デフォルトの名無しさん
08/03/23 23:24:09
型システムは、メジャーな言語ではC++0xが一番近いよ。
後はHaskellとかGとか。

JavaとかノーマルなOCamlはクラス指向が非常に強いから似てない。

72:デフォルトの名無しさん
08/03/23 23:29:17
C++0xってメジャーな言語なのか？

73:デフォルトの名無しさん
08/03/23 23:35:25
おお、Scalaのスレができてる
Scala自体はいい言語だけど、Javaのライブラリがうんこだよな

74:デフォルトの名無しさん
08/03/23 23:57:28
ライブラリのどの変がダメ？

75:デフォルトの名無しさん
08/03/24 00:03:13
Scalaのライブラリはどうですか？

76:デフォルトの名無しさん
08/03/24 11:10:28
>>74
粒度が細かすぎて使いづらいというのはよく言われていることだけど、
それをScalaから使うというのがまたしんどい
結局Java使ってるのと大差ない気がしてくる

77:デフォルトの名無しさん
08/03/24 12:57:22
>>76
Scalaから使うときは簡単なラッパーをかましてやるのが良い使い方だと思う
本当のところ、早いところScala独自のライブラリが充実して欲しいんだけど
簡単なラッパー作るくらい大した手間じゃないし自作するのが手っ取り早い
たとえば、IOならこんな感じ

// 定義
def withReader[T](File path)(proc :BufferedReader => T) :T = {
val reader = new BufferedReader(new FileReader(path))
try {
proc(reader)
} finally {
reader.close
}
}

// 使用
withReader(new File("hoge.txt")){reader =>
//readerを使ったコード
}

ちなみにscala.io.Sourceは色々と微妙で、使いづらい

78:デフォルトの名無しさん
08/03/24 22:58:01
それだと使う側のセンスが問われそうだな
俺だと劣化Rubyライブラリになってしまいそうだ
標準ライブラリで言語のポテンシャルを示してほしいところなのだが
つーかこんなラッパーが全世界で何百と作られてんだろうなあ

79:デフォルトの名無しさん
08/03/24 23:01:55
というかラッパーが物凄く簡単に書けて、
再利用性も高いのが言語の売りの一つなので。

80:デフォルトの名無しさん
08/03/25 10:15:09
Lisp方言並に溢れかえるラッパーにｗｋｔｋ

81:デフォルトの名無しさん
08/03/25 12:08:18
>>48に誰も反応してくれなくて寂しい俺が来ましたよ
# あれは正確には、「JVM命令セット群のセマンティクス」と書くべきだった

ライブラリの話も出てるし、言語として完成度上げるには、やっぱそろそろJava依存抜けようか。
って無理か。

82:デフォルトの名無しさん
08/03/25 16:48:04
どうしても隠せないのは実装に近いところ。
例えばboxing/unboxing関係のAnyVal/AnyRef。

83:暗黙のthis
08/03/25 17:24:39
ScalaOverview.pdfの
def + (x: Nat): Nat =
if (x.isZero) this else succ + x.pred
って、
def + (x: Nat): Nat =
if (x.isZero) this else this.succ + x.pred
のことなんだな。ちょっと混乱したので書いとく。

84:デフォルトの名無しさん
08/03/25 17:58:15
>>81
配列周りはScalaの処理系が凄いがんばって他のgenericなクラスと同じように
見せようとしてるなあと思った。JVMでは配列が特別扱いされてるから、
genericなクラスのように見せかけるのはなかなか大変

>>83
暗黙のthisはJavaでもほぼ同じだから、そんなに混乱しないと思ったけど、どうなんだろう。
Java以外の言語からScala入った人？

85:暗黙のthis
08/03/25 18:04:02
operation invocationに()がないから混乱した。
Java以外にも関数型言語も分かるので、
curry化されてるのかな？と思ってしまった。

86:デフォルトの名無しさん
08/03/25 18:04:55
>>82
> boxing/unboxing関係のAnyVal/AnyRef。
なんとなく想像は付くんだが、具体的にはどんな例がある？

87:デフォルトの名無しさん
08/03/25 18:06:59
>>85
ああ、なるほど。invocationの()省略できる辺りは、なんか
構文的にRubyっぽい感じがするね。Scalaは細かいところで、
色々syntax sugarが多いから、慣れない内は混乱の元にも
なるなと思った

88:デフォルトの名無しさん
08/03/25 18:11:19
あ、省略できるってのはちょっと不正確だったのでちょっと補足。
Scalaで0引数のメソッドを定義する方法は二つあって、
一つは

class HelloWorld {
def print :Unit = { println("Hello, World!") }
}

という形。この形の場合、
val hello = new Hello
hello.print
という形でのみ呼び出すことができ、hello.print()という呼び出し形式は
コンパイルエラーになる。もう一つは、

class HelloWorld {
def print() :Unit = { println("Hello, World!") }
}

という形。この形の場合、hello.print()と書いてもhello.printと書いても
OK。

89:デフォルトの名無しさん
08/03/25 18:29:49
>>86
BoxedArrayはあれば便利だけど、なくても何とかなる。
どうしてもArrayの要素をポインタ共有したい時は、
セルクラスに入れてからArrray[セル]にすればいいから。
けどJavaではBoxedArrayがあるから、作っとかないと困る。

>>84のいうようにうまく処理されているとは思う。
Nothingがあるからprimitive = null;問題も起きないし。

90:デフォルトの名無しさん
08/03/26 02:37:56
あんま愚痴っててもしょうがないので、
ありがちなところで、Ruby風文字列、正規表現ラッパーを作ってみた
と言っても、まだ半分も実装できてないけど

URLﾘﾝｸ(hexx.sakura.ne.jp)

使い方は、こんな感じ

import ruby._
import ruby.RubyString._

println("hoge %d %s" % (1, "fuga"))
// → hoge 1 fuga
// Rubyでは
// "hoge %d %s" % [1, "fuga"]

"a\nbbb\nccccc\n".each(l => print(l.length))
// → 246
// Rubyでは
// "a\nbbb\nccccc\n".each {|l| print(l.length)}

println("abcde".sub("(a)b(c)d(e)") { m =>
val lm = RubyRegexp.lastMatch
lm(1).upcase + lm(2).upcase + lm(3).upcase
})
// → ACE
// Rubyでは
// "abcde".sub(/(a)b(c)d(e)/) { $1.upcase + $2.upcase + $3.upcase }

今のところ、Rubyに比べて嬉しいのは、EmacsのFlymakeがよく効くところだな
悪いところは、スクリプトで使うと、やっぱり起動が遅い

91:デフォルトの名無しさん
08/03/26 02:57:01
>>90
遅いよねぇ。

開発をスクリプトでやってデプロイはコンパイルしてって感じになるのかな。
でもあの起動の遅さはリズムが崩れる。

92:デフォルトの名無しさん
08/03/28 00:39:06
NetBeansでScalaが書けるって聞いたんだけど
試してみた人いる？

93:デフォルトの名無しさん
08/03/28 00:42:07
>>90じゃあ開発者の楽しさとしてはやっぱりRubyのほうがいいんだね。実行するたびにモタつくなんてなぁ。

94:デフォルトの名無しさん
08/03/28 01:38:57
>>93
> 開発者の楽しさ

俺はコンパイラに指摘される型エラーをつぶしていくのが楽しい
だからMLも好き

95:デフォルトの名無しさん
08/03/28 06:50:40
同じJVMをつかっているのに、なぜJRubyよりも性能がいいのですか？
Rubyをなんちゃって言語というほど高尚なのですか？Rubyより悪い点はどこですか？

96:デフォルトの名無しさん
08/03/28 07:01:52
>>95
性能がいいのは主に

・静的型付けであり、かつ比較的Javaに型システムが近いこと
(メソッド呼び出し時にinvokevirtualなどVMのメソッド呼び出し命令をそのまま
利用できるし、数値演算もVMの命令を利用できる)

が理由だろうな。他の理由もあるだろうけど、たぶんこれが一番大きい。

97:デフォルトの名無しさん
08/03/28 09:36:07
楽しさって言われてもなあ、スクリプトの起動がそれほど気になるならそうかもしれないけど
対話環境で開発することも多いだろうし、Scalaはスクリプトの方がメインではないだろうし

Rubyとの違いは、やっぱり型が静的か、動的かにつきるんじゃないの？
静的な型でもここまでできると思うか、
やっぱり面倒臭いから静的な型なんていらないと思うか

あとは関数型から引き継いだパターンマッチ、ケースクラスとか
ErlangからパクったActorがどれくらい役に立つか

98:デフォルトの名無しさん
08/03/28 09:39:38
JRubyより性能いいの?
JRubyってJavaのバイトコードをターゲットにしたコンパイラなの?
独自バイトコードインタープリタなら遅くて当たり前だけど…

99:デフォルトの名無しさん
08/03/28 09:42:59
>>97
あと、mixin-compositionがあるのが重要。

100:デフォルトの名無しさん
08/03/28 10:03:23
ああ、そういえばScalaは後からmixinを足せるんだったな
確かに使い方によっては強力な感じはする

101:デフォルトの名無しさん
08/03/28 11:34:23
ぶっちゃけmixinはあんまり要らんなーと個人的には思う
caseクラスとかマッチングあたりはうれしいけど
Actorはまだ触ってないのでなんとも

102:デフォルトの名無しさん
08/03/28 13:53:22
>>92
6.1betaに開発版プラグインの所を参照させて出来たよ。

103:デフォルトの名無しさん
08/03/28 14:52:00
actorやmixinはプログラミングモデルだから、
慣れてない人は有り難みは分からない。
使って慣れるのみ。

104:デフォルトの名無しさん
08/03/28 16:36:28
>>101
mixinはライブラリ書くとき嬉しいよ
例えば、コレクションぽく見せかけたいものに対して、scala.Iterable[T]をmix-inして、
elements :Iterator[T]だけを実装すれば、Iterable[T]にある便利な高階関数やらを
全部使えるとか。たとえば、Reader系のクラスをサブクラス化してIterable[String]
を実装するなどが考えられる。

105:デフォルトの名無しさん
08/03/28 16:38:55
>>98
昔のJRubyは普通のインタプリタだったはず。その頃は凄く遅かった
最近のJRubyは内部でJVMのバイトコードにコンパイルして実行するようになった
ので速くなった。でも、Scalaには性能で遠くおよばない(言語の特性上仕方無い
けど)

106:デフォルトの名無しさん
08/03/28 22:34:26
開発効率ではJRubyに遠く及ばない（言語の仕様上しかたないけど）

107:デフォルトの名無しさん
08/03/28 22:48:31
どうせJRubyもScalaも使ったことないくせに

108:デフォルトの名無しさん
08/03/28 22:58:47
JRubyは使ってるよ。Scalaはこれから試すよ。
仕様が汚ないけど、型があるからRubyより性能は良いってことだろ。

109:デフォルトの名無しさん
08/03/28 23:13:00
マジレスだったのかよ！
で、Scalaの仕様のどの辺が気に食わないのよ
開発効率が遠く及ばないというほどの何かがあるの？

110:デフォルトの名無しさん
08/03/29 03:11:22
rubyの話いらね

111:デフォルトの名無しさん
08/03/29 08:35:05
>>104
多重継承の代用？
多重継承ではなくmix-inが欲しくなる場面の例はありませんか？

112:デフォルトの名無しさん
08/03/29 09:06:23
基本的にmixinは多重継承の代用でしょ
mixinそのものの有用性については
Rubyが先駆者だからRubyの事例を調べた方がいいと思うよ
(またRubyの話になっちゃったけど…)

113:デフォルトの名無しさん
08/03/29 10:23:43
機能的にはリッチ版だよ。
name conflictやmutliple pathを解決するための機構をプログラマに対して与える。

どれもがコンクリートクラスになりがちなクラス指向のプログラミングモデルから、
機能mixinを集めてくっつけて実用クラスを構成する～モデルになる、というかする。

name conflictやmutliple pathはmixする時に解決できるから、
このクラスとあのクラスはうまく多重継承/結合出来ないというケースがぐんと減る。

代用とかじゃなくて、機能が増えたのがmixin。
元祖はLisp Machine LispのFlovors。
基本フレーバーを調合して、香水を作るって考え。
コンポーネント志向が強い。

もちろんmixinなくても同じことはできるよ。
アセンブラあればなんでもできるという意味では。

114:デフォルトの名無しさん
08/03/29 10:39:13
え、ちょっとよくわからない
どの辺が多重継承よりリッチなの？

115:デフォルトの名無しさん
08/03/29 10:56:30
つ版

116:デフォルトの名無しさん
08/03/29 11:03:09
版？

117:デフォルトの名無しさん
08/03/30 00:34:31
機能は多いだけじゃだめだとおもう。わかりやすくないと。
Rubyはその辺のバランス感覚に優れているからね。

118:デフォルトの名無しさん
08/03/30 00:53:52
Ruby信者もバランス感覚を覚えて欲しい

119:デフォルトの名無しさん
08/03/30 12:21:15
だからもっと具体的な話しろよ
Scalaの仕様のどこがいいとか悪いとか、mixinの話も>>111に答えてやれよ

と嗾けるだけでもなんだから
俺がScalaで良いと思ったのはカリー化と無名関数だな
Rubyのブロックはへんてこ構文だったけど、Scalaはすっきりしてると思う

120:デフォルトの名無しさん
08/03/30 17:56:01
部分適用はあるが、カリー化なんてあったっけ?

121:デフォルトの名無しさん
08/03/30 18:02:14
カリー化はFunction.curriedでできるが、
ここで俺が言いたいのはカリー化された関数を直接書けるということだな
言葉足らずですまんが

122:デフォルトの名無しさん
08/03/30 18:12:43
これか

def add(a: Int)(b: Int)(c: Int) = a + b + c

add(1)(2)(3) // 6

123:デフォルトの名無しさん
08/03/30 18:18:28
>>119
それならお前が答えればいいのに

124:デフォルトの名無しさん
08/03/30 18:26:14
>>122
うん、それ
Rubyではわざわざブロック構文を導入しているが
Scalaではそれと無名関数を組み合わせて、
同じようなことがすっきりとできるじゃん
というだけの話なんだけど

>>123
いや、俺はmixinは制限付き多重継承だと思ってるから
だから>>113が答えてやれよと
まあ多重継承の定義の問題なんだろうな

125:デフォルトの名無しさん
08/03/30 20:11:51
> 俺はmixinは制限付き多重継承だと思ってるから

kwsk

126:デフォルトの名無しさん
08/03/30 20:25:14
mixin 多重継承でググれば、mixinは多重継承の一種だという説明が多い
Rubyのまつもとさんによれば、mixinは多重継承のサブセットらしい
俺もそう思っていたというだけの話
Scalaのmixinに何か特別な機能があるかどうかは知らない

127:デフォルトの名無しさん
08/03/30 22:16:06
>>126
基本的にそういう認識(mixinは多重継承のサブセット)でいいと思う
Scalaのmixinに何か特別な機能があるかと言えば、たぶん無い
俺がScalaで好きなのは、ExtractorとViews、implicit parameterだな
これらの機能がある言語は、今まで見たことがなかったので新鮮だった

128:デフォルトの名無しさん
08/03/30 22:20:39
開発効率の話について言えばScalaがRubyに遠くおよばないなんて
ことは無いと思う。静的言語ゆえの制約(evalできないとか)はもちろんあるけど、
そもそもそういうのを濫用したプログラミングはそうそうする必要は無いし
for-comprehensionやextractorなどRubyに無い便利な機能もあるし

129:デフォルトの名無しさん
08/03/31 06:33:34
Scalaのmixinは多重継承にならないよう配慮してるね。
別クラスから継承して作ったtraitはmixinできないとか。

130:デフォルトの名無しさん
08/04/02 20:45:51
>>128正論だとはおもうが、そゆ発言はRuby厨を刺激するのでは

131:デフォルトの名無しさん
08/04/03 23:51:57
簡潔にかける!=わかりやすい、というのを体現した言語だなあ。
確かに個々の機能は優れていると思うが、表現の幅がひろすぎて自分とスタイルの違う書き方がほんと馴染まない。
Rubyのほうがコードの一貫性という意味では良いのかもしれないね。

132:デフォルトの名無しさん
08/04/04 00:32:15
文法的にはRubyにforとパターンマッチが入った程度だろうに
ほんとにScala使ったことあるのかよ

133:デフォルトの名無しさん
08/04/04 00:45:09
>>131
Rubyと違って仕様が一貫してそうですが

134:デフォルトの名無しさん
08/04/04 02:23:30
>>132
＞文法的にはRubyにforとパターンマッチが入った程度だろうに
あなたもちゃんと使ったことがあるのか疑問があるんだが
どうせ、ちょっとTutorial見ただけで、決め付けただけなんじゃないの？

135:デフォルトの名無しさん
08/04/04 02:29:46
特にScalaの型システム(implicit conversion, higher-kind generics, path-dependent typeなど)
調べてみれば、とてもRubyにforとパターンマッチが入った程度なんて言えない
もちろん、それらがどれくらい使い勝手に影響があるか、という評価は必要だが

136:デフォルトの名無しさん
08/04/04 02:33:36
>>134
ちゃんと使ったことあるというのがどのレベルかはわからないがプログラムはある程度書いたよ
他にRubyよりわかりにくくなるほど簡潔にかけるところあるか？
型絡みは簡潔にはなるという方向じゃないでしょ

>>135
だからViewsやジェネリクスでRubyより簡潔にはならないでしょ
>>131は簡潔に書けすぎたり、表現の幅が広すぎてRubyより一貫性がないって言ってんだから
そういうレベルの話だよ

つーか、なんで俺が文句言われるのがわからん

137:デフォルトの名無しさん
08/04/04 06:45:15
相変わらずRuby厨が無駄に湧くスレだなぁ

138:デフォルトの名無しさん
08/04/04 10:52:07
阿呆は放置推奨

139:デフォルトの名無しさん
08/04/04 22:50:01
逆にRubyやったことがある人に向いてる言語と思うんだけどなあ。

140:デフォルトの名無しさん
08/04/04 23:10:57
Rubyと比較しただけでRuby厨呼ばわりはひどいですね。
Rubyから来た私とJavaからの移行組の同僚のコードがスタイルバラバラになったんで感想を延べただけなんですが。

141:デフォルトの名無しさん
08/04/04 23:27:13
同僚って、もう仕事でしかも共同開発って使ってるの？すごい

142:デフォルトの名無しさん
08/04/05 01:02:21
Scalaで仕事？

143:デフォルトの名無しさん
08/04/05 01:30:16
>>140
コーディングスタイルについては、Rubyだってかなり幅が広くて、
書く人によって全然違うコードになったりすると思うんだが、違う？
というか、○○言語だったらコーディングスタイルを均質化できるというのが
そもそも幻想な気がする

144:デフォルトの名無しさん
08/04/05 01:31:53
馬鹿だから厨と言われてるんであって、Rubyはむしろ被害者。

145:デフォルトの名無しさん
08/04/05 03:14:08
>>139
Rubyなんて触ったことすらない

146:デフォルトの名無しさん
08/04/05 08:32:24
>>143
そのとおり。というか>>131は、
Rubyでしか一貫性のあるコードが書けない（書く気がない）という気がする

147:デフォルトの名無しさん
08/04/05 22:34:48
確かにrubyに似ているんだけど、{}スタイルのブロックは俺には必要だなと再認識した。
haskellでみた変態的コーディング表記も緩和されてわかりやすいスタイルになっている。
一部なんとなく気にくわない所もあるけど仕様上しかたないことなのかな?(arrow回り)
それと変数名が先にくるのは後で何かよいことあるの?
あとdefineじゃなくてdefならさー、objectじゃなくてobjくらいにしてくれたほうがいいなぁ。

と、c++もjavaもrubyもhaskellもMLもlispも全然できないvb6厨の俺が見た目だけで評価。

148:デフォルトの名無しさん
08/04/05 23:04:56
>>147
型宣言が後置で良いことがあるかと言えば、まあ好みの問題なんで
なんとも。ただ、一般論として型宣言が後置の方がパーザ書きやすくなるという
話はある。

149:デフォルトの名無しさん
08/04/05 23:43:18
なんか、配列やマップ（ハッシュ）の参照も()なのが紛らわしい・・・
なんで同じにしたんだろ。

150:デフォルトの名無しさん
08/04/06 00:00:27
リテラルじゃなくてapplyで実装されてるからな
Rubyみたいに大クラス主義ならリテラルと相性が良いと思うが
Scalaの場合、Javaのものと合わせて大量にコレクションクラスがあるから、
リテラルの恩恵があまりないという判断なんだろうな

151:デフォルトの名無しさん
08/04/06 01:07:40
ツアーを読み始めてからjavaのよく分からない
機能(アノテーションとかジェネリック?)とかを調べ始めているうちに
まったく放置していたC#って言語が出てきて、これにも結構近いなぁ。
c# extends c++ interface 関数型言語,vm
に対して、
scala extends ruby,java,変態的言語

C++0xもおもしろそうだがまだvb6の総合的な簡潔さにはかなわない気がする。

152:デフォルトの名無しさん
08/04/06 02:56:08
>>149
genericsのために、既に[]は使っちゃってるからぶつかる
っていうのが主な理由じゃないかと

153:デフォルトの名無しさん
08/04/06 02:58:53
ところで、()使うのがそんなに紛らわしいかな？別に区別が付かない場面なんて
そうそう無いと思うんだが。あと、実用上のご利益として、関数引数を
要求してるとこに、配列やらMapをそのまま突っ込める、というのがある
val f : String => Int = Map("A" -> 1, "B" -> 2, "B" -> 3)
なんてのがＯＫなわけだ

154:デフォルトの名無しさん
08/04/06 04:06:22
これって知らなかったが、PartialFunctionを先祖で継承しているからなのか？
関数を継承してるコレクションって珍しいな

155:デフォルトの名無しさん
08/04/06 04:39:06
>>154
YES。
確かに、単に関数っぽい、じゃなくて、実際に関数として扱うことができるコレクションという
設計はあまり見かけない気がするね

156:デフォルトの名無しさん
08/04/06 07:38:00
>>149
Fortranと一緒だと思えばいい

157:デフォルトの名無しさん
08/04/06 10:56:18
～.run()とか～.invoke()じゃなくて～()って出来る

こういうのが浸透してきたから、
コレクションの要素取得にも一般化したんでしょ。

158:デフォルトの名無しさん
08/04/07 14:41:16
他に、関数と配列で同じ表記使う言語あったかなと思ったら、
BASICもそうだったなｗ

159:デフォルトの名無しさん
08/04/07 17:44:31
なんか、型推論があれば、
動的型付けなんかいらないみたいな事が書いてあったけど、
本当にそうなの？

160:デフォルトの名無しさん
08/04/07 18:07:32
>>159
動的型付けや型推論の定義によるけど
動的型と言っても結局実行時には何の型であるかを決めて変換しないと実行できないので
それをコンパイル時にやってるのが型推論ということだとすれば
実行時まで型がわからない状況以外は全部型推論で片付くことになる
ただ実行時まで型がわからない状況ってevalくらいしか思いつかないのだが・・・

161:デフォルトの名無しさん
08/04/07 19:50:51
動的型付けだと、状況によって型が違う関数とかが発生するでしょ。
例えば Lisp 系なんて、何でも入るリストがデータ構造の基本なんで、多くの関数の型は引数とかに依存する。
型を決めて変換するってよりは、型に応じて分岐処理したりするような世界だから、推論は難しいと思うけど。

162:デフォルトの名無しさん
08/04/07 20:09:32
型に応じて分岐処理ってポリモーフィズム？

163:デフォルトの名無しさん
08/04/07 20:11:42
>>161
何でも入るっていっても、本当に実際に何でもつっこむような使い方って
Lisp系でもそんなにしない気がするんだが、どうだろう。Lispのエキスパートじゃないので
自信があるわけじゃないけど。で、もしこれが真ならvariant(VBのじゃなくて、MLとかの
やつね。Scalaで言うとcase class)があれば大体事足りるのではないかと

164:デフォルトの名無しさん
08/04/07 20:40:31
>>159
「型推論」じゃなくて「強い型付け」の間違いですか?

165:デフォルトの名無しさん
08/04/07 20:50:26
Scala at Waves (SaW):
　問題をガリガリ破壊していくフレームワークのような何か。白装束を着ないと自分も破壊される。

166:デフォルトの名無しさん
08/04/07 20:54:14
なんでgenericsに<>使わないの? Foo<Bar<Bazz>> ←ここの問題とかだったりしたら orz

{ブレース}使って見た目の「普通感」があるのはJavaneseに取ってもいいことだと思うんだけど、
それをメリットとして軽く触れられた後で<>が[]です、[]が()です、型は後置です、って言われても
やっぱり見慣れない感が。
理論的・技術的に問題ないのと、今までの目の慣れにやさしいかは別問題。

167:デフォルトの名無しさん
08/04/07 21:01:41
C++はC++0xで>>とくっつけて書いていいようになりました。
要するに文脈依存でlexer頑張れと。

168:デフォルトの名無しさん
08/04/07 21:07:30
>>167
lexerに文脈を表す状態を持たせる必要……この道はいつか来た道。 ←ruby/parse.y orz

169:デフォルトの名無しさん
08/04/07 21:11:48
<>でも[]でもどっちでもいいじゃん

170:デフォルトの名無しさん
08/04/07 21:24:44
{}でもdo..endでもでもどっちでもいいじゃん

171:デフォルトの名無しさん
08/04/07 21:34:19
それは{}でお願いします

172:デフォルトの名無しさん
08/04/07 22:14:10
>>166
Javaのgenericsにその問題はないから別の理由だろ

173:デフォルトの名無しさん
08/04/07 22:25:20
>>166
本当のところ、理由はわからんが、記号がかぶらん方が、パーザにとって
色々都合が良いという話はある。例えば、 A[B] Cという式があったとして、
これがA<B> Cだったら、記号表みないと、A < B > Cという式と区別つかんとか。

174:デフォルトの名無しさん
08/04/07 22:29:23
>>173の例はミス。A[B] Cだとまずかった。書き直すと、

a.b[C](d)という式があったとして、これがa.b<C>(d)だったら、
記号表みないと、a.b < C > dという式と区別つかんとか。

175:デフォルトの名無しさん
08/04/08 00:34:40
>>174は処理系実装と言語仕様の思考分離を(ry

176:デフォルトの名無しさん
08/04/08 01:11:10
>>175
いや、もちろんわかってるよ。ただ、処理系(というかパーザ)の実装のしやすさを
考えて、問題無い程度に構文を変えるというのは普通にあり得る話だと思う

177:デフォルトの名無しさん
08/04/08 01:28:03
D 言語なんかまさにそうだな。
実装しやすいような言語仕様にするってのを１つの柱にしている。
D 言語は構文解析と意味解析が 100% 分離可能。
逆に C++ とかは泥沼。全言語の中で最もパーサが作りづらい。

178:デフォルトの名無しさん
08/04/08 18:22:34
>>176
同意。ただ>>173のような例が「問題がある」程度の実装の難しさを引き起こすかな。
テーブル見る必要があるのはスマートじゃないけど、見慣れた記号の意味が変わらない、というのは
一つのメリットになり得るから、トレードオフとして検討する価値はあるんじゃないかなぁ。

けど、[とか]が単独で演算子として使われたことはないだろうから、それを<と>の代替として選んだ
Scalaの中の人は確かにちゃんと考えてるなーと思う。

179:デフォルトの名無しさん
08/04/08 18:23:45
>>177
C++なぞ問題外 (^^)

180:デフォルトの名無しさん
08/04/08 18:35:02
とりあえず参考資料っ

>　* Features of Ruby
>　　+ Simple Syntax
(from README)

Pseudo simplicityとか言い張ってるやつだな。どこがpseudoって、parse.yの大きさ見れば分かる。

Rubyの主張は、見た目の良さと実装難易度は直交するということじゃまいか。
たしかにBrainf**kなんか挙げればそれっぽい気もするが、ある程度の複雑さを備えた実用的な
言語仕様でも上記が主張できるかどうかは、意見が分かれるところだろう。
(見た目がシンプルなら実装も簡単になりやすいんじゃないか、等々)

181:デフォルトの名無しさん
08/04/08 18:37:23
>>180
「見た目の良さ」だと曖昧だな。理解のしやすさ、くらいか。まぁその指標自体が曖昧だが。

182:デフォルトの名無しさん
08/04/08 21:54:49
>>174
不等号を連続させられないようにする、という選択肢もあるね。

183:デフォルトの名無しさん
08/04/08 23:21:05
>>180
> Pseudo simplicityとか言い張ってるやつだな。どこがpseudoって、parse.yの大きさ見れば分かる。

それだけだと単にyaccが適切な道具じゃなかったという可能性が否定できないよ。

184:デフォルトの名無しさん
08/04/08 23:25:20
>>183
Rubyの文法は、lexer/parserを分離する事が前提の構文解析アルゴリズム
は向いてない可能性はあるね。

185:デフォルトの名無しさん
08/04/08 23:52:00
Cが駄目だね。> 分離

186:デフォルトの名無しさん
08/04/10 23:23:22
>>183
LALR(1)が、なら同意だけど、単にyacc(bison)が、ならあんまり同意できないかも。
parse.y覗いたことある? あんなことやってたら他のパーザジェネレータ使ってもコードが太りそう。
結局は>>184のが本質ついてるのかも。

187:デフォルトの名無しさん
08/04/10 23:34:41
とりあえず誰か、Scalaの超絶技巧を使って[Type]を<Type>と書けるようにするライブラリの実装ヨロスコ
// TypeじゃなくてKlassか?

188:デフォルトの名無しさん
08/04/11 00:03:10
>>187
さすがにそりゃ無理があるw
Camlp4みたいに標準的な構文拡張のための方法が用意されてるならともかく
Scalaではそういうのは無いはずだし

189:デフォルトの名無しさん
08/04/11 00:15:09
>>186Rubyをわかってねーな。プログラマのためにあえてあーなってんだろうが。

190:186
08/04/11 01:55:57
>>189
んと、言語として「プログラマのためにあーなって」るのは否定も嫌悪もしてないっす。
ただ、とりあえず現状の(というか「lexer/parserを分離する事が前提…」であると?)
実装は、大変そうだな、と。lex_stateとかlex_stateとか。

だからといって、プログラミング言語の文法に置ける、人にとってのsimplicityの定義:
　　LALR(1)に収まること。
っていうのは違うよなぁ。

おぉっと、Scalaな話からそれてしまう。いいかみんな、共産ゲリラたちが発する電磁波は……

191:デフォルトの名無しさん
08/04/12 00:27:00
>>189
Ruby書きづらいし遅くて使い物にならないけど

192:
08/04/12 01:23:41
Scalaの日本語版Wikipediaには影響を受けた言語にRubyが入ってるけど、英語版にはない。

193:デフォルトの名無しさん
08/04/12 01:48:56
>>192
それはひどいな
捏造かよ

194:デフォルトの名無しさん
08/04/12 03:18:59
もうRubyはいいって。
内容のある比較もないし。

195:デフォルトの名無しさん
08/04/12 08:57:01
>>191
負け惜しみ乙。どこがどう書きづらいんだよw

196:デフォルトの名無しさん
08/04/12 12:30:55
てかscalaとrubyってユーザそんなに被らないと思うけどなあ
RoRとかが出てきてから流行に乗っかるような「現実的な」ユーザにとっては
今のscalaはまだ使う価値がないと思うし

197:デフォルトの名無しさん
08/04/12 12:59:55
Ruby信者はRubyより優れている所があると言われる言語にでていく習性があってだな…
格下認定(HSP,PHP,LISP,VBあたり)されるか、信者（HaskellとかErlang？）が突撃してくるかくらいしか選択肢がない。

次ページ