08/03/10 22:40:17
The Scala Programming Language
URLﾘﾝｸ(www.scala-lang.org)
チュートリアル日本語訳
URLﾘﾝｸ(homepage.mac.com)
どう書く？org Scala
URLﾘﾝｸ(ja.doukaku.org)
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？）が突撃してくるかくらいしか選択肢がない。
198:デフォルトの名無しさん
08/04/12 16:37:37
>>195
うわぁ・・・Ruby信者いいかげんにしろ
199:デフォルトの名無しさん
08/04/12 17:42:28
こたえられないんですね。
完膚なきまでに論破。
200:デフォルトの名無しさん
08/04/12 17:47:39
信者なのかアンチの嫌がらせなのかの区別がつかない。
どちらにしてもScalaの絡まないRubyの話は
Ruby関連のスレかLLスレでやってほしい。
201:デフォルトの名無しさん
08/04/12 21:26:20
Railsにブチ切れた外人がフレームワーク作った模様
InfoQ: David Pollak氏 lift と Scala を語る
URLﾘﾝｸ(www.infoq.com)
202:デフォルトの名無しさん
08/04/12 22:17:14
>>189,191,198,199あたりはRubyを貶めようとする輩の自作自演の可能性が高い。
本当のRuby信者がRubyの心証が悪くなるような行動をするわけがない。
203:デフォルトの名無しさん
08/04/12 22:23:48
まつもとゆきひろが率先してやってる件について
204:デフォルトの名無しさん
08/04/12 22:25:39
>>202
>>195が抜けてるけど>>195ですか？
205:デフォルトの名無しさん
08/04/12 22:29:16
すまん、訂正する。>>189,191,195,198,199あたりはRubyを貶めようとする輩の自作自演だろ。
206:デフォルトの名無しさん
08/04/12 22:56:28
なんでもかんでもアンチのせいにしてごまかそうとしてるな酷すぎる
207:デフォルトの名無しさん
08/04/12 23:21:34
>>202-206
>200
>どちらにしてもScalaの絡まないRubyの話は
>Ruby関連のスレかLLスレでやってほしい。
どうでもいいけどRubyスレのほうが盛りあがっててワロタ
良く釣れる連中だから遊んでもらえるんだな
208:デフォルトの名無しさん
08/04/12 23:26:34
そんなことより2.7.1RC1が出てるぞ
バグフィックス中心だけど、簡単な正規表現ライブラリも追加されている
209:デフォルトの名無しさん
08/04/12 23:30:28
正規表現だってー！！
210:デフォルトの名無しさん
08/04/13 10:26:23
java.util.regex.*でいいじゃん...
211:デフォルトの名無しさん
08/04/13 12:18:10
鬼車キボン
212:デフォルトの名無しさん
08/04/13 13:23:47
またRuby厨が沸きそうなネタを…
213:デフォルトの名無しさん
08/04/13 14:12:42
PEGの方がいいじゃん
214:デフォルトの名無しさん
08/04/13 14:45:28
>>210
いや簡単なjava.util.regexのラッパー
215:デフォルトの名無しさん
08/04/13 15:19:47
自前LL作るときにJVM利用する価値があるのは同意する。
しかしライブラリまでラッパでおk、ってのはいかがなものか。
たしかにJavaの豊富かつ実績のあるライブラリが使えるのはすげーメリットだが、
自前言語に合った、使いやすい物をもっと作れるはずだろ。インタフェース的な意味で。
藻前らが独自言語を設計してもJVMの命令列に落とすのと同じだ。
独自インタフェースのライブラリを設計して、標準ライブラリを利用しろよ。
Java標準パッケージ脳乙。
ということを繰り返し書いている漏れは……うー。
もしこれ以上雑多な拡張が必要になる将来が来るなら、それよかPEGにしたらいいと思う。 >regex
216:デフォルトの名無しさん
08/04/13 16:23:42
なんだregexリテラルくらい作ってくれればいいのに
217:デフォルトの名無しさん
08/04/13 17:42:33
>>216がフラグ立てた。(リテラルっぽい表記をライブラリで実現する的な意味で
218:デフォルトの名無しさん
08/04/13 18:00:15
まあ、"abc".r で正規表現オブジェクトができるから短かくは書けるけど
219:216
08/04/13 19:53:32
>>217
Scala触ったこともないんだけどだいぶ待ってもらっていい？
……と書こうとしたら>>218でオワタ
220:デフォルトの名無しさん
08/04/13 20:12:23
/abc/と書けないのは中途半端だな。
221:デフォルトの名無しさん
08/04/14 00:17:16
>>213
scalaにPEGライブラリってあったっけ？
222:デフォルトの名無しさん
08/04/14 00:35:08
>>221
無いけど、Parser Combinatorがそれに近い
223:デフォルトの名無しさん
08/04/14 07:24:37
PEGとParser Combinatorってどうちがうの
224:デフォルトの名無しさん
08/04/14 16:41:54
>>218
いっそのこと、文字列から正規表現への暗黙の変換を定義するというのはどうだろう
以下のような感じで(2.7.1.RC1じゃないと動かないので注意)
import scala.util.matching.Regex
implicit def string2Regex(s :String) :Regex = new Regex(s)
for(r <- "[0-9]+" findAllIn "123 456 789") println(r)
225:デフォルトの名無しさん
08/04/14 20:45:38
> 文字列から正規表現への暗黙の変換
実にPerlish……けど型が保証されるから問題無しか。すげ
226:デフォルトの名無しさん
08/04/14 22:06:50
毎回やるのは嫌すぎるぞ。Emacsのようにキャッシュ利かせるとかしないと。
227:デフォルトの名無しさん
08/04/14 22:09:35
個人的にはこのくらいで変換はしない方がいいと思うが
じゃあどういう基準で変換すべきかというのがわからんな
新技術はこういうところが困る
228:デフォルトの名無しさん
08/04/14 22:17:09
キャッシュねえ…こんな感じ？
import scala.util.matching.Regex
import scala.collection.mutable.HashMap
object RegexConversion {
private val cache = new HashMap[String, Regex]
implicit def string2Regex(key :String) :Regex = {
cache.synchronized {
cache get key match {
case Some(regex) => regex
case None =>
val regex = new Regex(key)
cache(key) = regex
regex
}
}
}
}
import RegexConversion._
for(r <- "[0-9]+" findAllIn "123 456 789") println(r)
229:デフォルトの名無しさん
08/04/14 22:18:34
>>227
まあ、自分で書いといてなんだが、俺もこういうケースで
implicit conversion使うのが良いかっていうのはちと疑問ではある
ただまあ、実害があまり無い使い方ではあると思う
230:デフォルトの名無しさん
08/04/15 00:16:55
これはひどい
231:デフォルトの名無しさん
08/04/15 01:06:52
>223
PEG: 文法の記法
Parser Combinator: パーザの実装方法の一つ（ちょっと違うけどそんなもん）
232:デフォルトの名無しさん
08/04/15 07:34:18
パーザコンビネータつうのは文法とか文法解析のアルゴリズムとは独立してるもんなの？
233:デフォルトの名無しさん
08/04/15 11:00:07
>>232
実際に使えるパーザコンビネータはほとんど再帰下降型（＋バックトラック）だと思う
ただ、LRなどのボトムアップ型も作れないことは無い、はず
234:デフォルトの名無しさん
08/04/17 23:59:23
ScalaってWindowsでまともなプログラム書けますか？
サーバーサイドじゃなくって
Scala.netって止まってるような気がするけど・・・
235:デフォルトの名無しさん
08/04/18 00:04:09
うぜぇ。文句があるならRubyでも使ってろ。
236:デフォルトの名無しさん
08/04/18 00:19:33
WindowsユーザはScala使うな
237:デフォルトの名無しさん
08/04/18 00:23:10
知的水準の低い人はScalaを使わなくて結構です
238:デフォルトの名無しさん
08/04/18 00:34:56
なんだ。関数型言語ってやっぱり学者しか使わないか・・・
239:デフォルトの名無しさん
08/04/18 00:51:52
ごめん、嘘です。気を悪くしたらスマソ。
「自分がやられて嫌なことは、他人にしたらいけない」って死んだ猫いってたのを思い出した・・・
240:デフォルトの名無しさん
08/04/18 14:23:55
何この流れw
241:デフォルトの名無しさん
08/04/18 19:13:35
>>234
ScalaでWindowsのGUIプログラム書けるかって話なら
Swing/AWT使うか、SWT使うくらいしか選択肢は無いんじゃない？
242:デフォルトの名無しさん
08/04/18 19:26:24
「まとも」＝「GUI」！
243:デフォルトの名無しさん
08/04/18 19:55:27
>>241
.NET対応がちゃんとしてくれるんなら、それでいいっす^^
244:デフォルトの名無しさん
08/04/18 20:04:12
>>242
234の文章から、234の考える「Windowsのまともなプログラム」を推測すると、
俺もそうなる。
245:デフォルトの名無しさん
08/04/18 20:18:19
>>242
>>244の書いてる通り、234の文章から、234が考える「Windowsのまともなプログラム」
＝ＧＵＩプログラムのことと推測したまで。俺自身が「Windowsのまともなプログラム」＝
ＧＵＩプログラムのことだと考えてるわけじゃない
246:デフォルトの名無しさん
08/04/18 20:27:57
SWT使えば見栄えも問題ないよ
247:デフォルトの名無しさん
08/04/19 09:26:39
あんな低レベルのGUIに満足してるの？
248:デフォルトの名無しさん
08/04/19 09:44:53
俺はGUI全く使わない。
249:デフォルトの名無しさん
08/04/19 10:36:08
GUIも使えるけどあえて使わないってこと？今だにキャラクタベースのUIのほうが玄人っぽいとか、そんな発想？
あなたのような人には文字ベースで十分なのかもしれないけれど、一般的な用途にはGUIが必要とされる時代なんです。いい加減わかってください。
250:デフォルトの名無しさん
08/04/19 10:59:27
お前のことはお前が決めろ。
251:デフォルトの名無しさん
08/04/19 11:10:36
>>247
世の中はOSと違うインターフェースは敬遠されるらしい
252:デフォルトの名無しさん
08/04/19 11:13:56
必要なものを自分で作る能力のないプログラマが飛び付く言語じゃない。
253:デフォルトの名無しさん
08/04/19 12:20:38
>>242>>244
おそらく、>>234=>>243なので、さらにその内容を合わせると
>>234の考えるまともなプログラム
＝「.NET Framework を使ったGUIプログラム」
というように読める。
254:デフォルトの名無しさん
08/04/20 17:51:36
どちらかというと言語がプログラマの要求についてこれれてない部分があるっつーことでしょ。
その辺を他言語と比較されるとすぐファビョりはじめる奴がいるのが困りものだね。
255:デフォルトの名無しさん
08/04/20 21:28:40
.NET対応ってそんなに要求あるのかな？
Java VMで十分な気がするけど
256:デフォルトの名無しさん
08/04/22 21:33:18
Introduction to SDT
URLﾘﾝｸ(www.codecommit.com)
期待。
257:デフォルトの名無しさん
08/04/23 00:55:30
Emacsにも補完つけてほしい
258:デフォルトの名無しさん
08/04/23 01:33:45
Stream.const がはじかれるんですが、これっていつからの関数ですか？
259:デフォルトの名無しさん
08/04/23 01:54:41
Stream.consのことか？
260:デフォルトの名無しさん
08/04/24 02:41:40
>>259
いや。実際にStream.constというメソッドがある。
たとえば、Stream.const(1)とすると、1のみを含む無限Streamが生成できる。
261:デフォルトの名無しさん
08/04/27 11:00:01
ふと聞きたいのですが、Scala以外にどんな言語に興味ありますか？
Scalaを使ってらっしゃる方が普段どんな言語つかっているのか知りたいです。
262:デフォルトの名無しさん
08/04/27 11:42:13
JavaとRuby
263:デフォルトの名無しさん
08/04/27 12:39:15
JavaとRubyかな。最近はErlangに手を出し始めてる
264:デフォルトの名無しさん
08/04/29 15:46:25
>>193
small talkも知らない馬鹿が書いているんだろｗｗｗ
無視しろ。
265:デフォルトの名無しさん
08/04/29 20:12:31
ScalaはRubyの影響をうけているよ。
266:デフォルトの名無しさん
08/04/29 21:23:18
>>265
まあ、受けてる可能性は否定できないけど、明らかに影響を受けてる
という程じゃないなあ。Groovyくらいそっくりだったら、話は別だけど。
267:デフォルトの名無しさん
08/04/30 02:42:57
>>264
他人を罵る前にだ。
Smalltalkを区切るな、ボケw
268:デフォルトの名無しさん
08/04/30 22:17:30
>>264
くだらない釣りはヤメロよ
269:デフォルトの名無しさん
08/04/30 23:05:54
JJUG Cross Community Conference の Scala のセッション、えらい盛況でワロタ:-)
270:デフォルトの名無しさん
08/04/30 23:14:43
URLﾘﾝｸ(shootout.alioth.debian.org)
271:デフォルトの名無しさん
08/05/04 19:50:05
既出かもしれんけどscalaの動画が紹介されてた。
関数型言語mlのすれ
272:デフォルトの名無しさん
08/05/06 16:48:05
Scala 2.7.1.final
URLﾘﾝｸ(www.scala-lang.org)
273:デフォルトの名無しさん
08/05/07 19:49:29
>>271
Scalaの動画ってこれか
URLﾘﾝｸ(www.youtube.com)
274:デフォルトの名無しさん
08/05/09 23:39:00
>>271
ニコニコ動画で見つけました。
関数型言語Scalaの動画もう一つ
URLﾘﾝｸ(www.nicovideo.jp)
275:デフォルトの名無しさん
08/05/10 14:28:21
>>274
>>1乙ｗｗｗｗ
276:デフォルトの名無しさん
08/05/10 14:33:51
>>1 なのかwww
277:デフォルトの名無しさん
08/05/10 14:34:18
Rubyの人とけんかしてるので仲良くして欲しいwww
278:
08/05/10 18:50:55
記法が柔軟性あるみたいだけど、そのためIDEのインテリセンスつくるの大変そうだね。
EclipseのJavaエディタ並みの賢い開発環境があればJavaから乗り換えたいけど。
279:デフォルトの名無しさん
08/05/10 20:20:11
>>274
「スレを立てる」ｸｿﾜﾛﾀ
その結果がこのスレかｗｗｗ
280:デフォルトの名無しさん
08/05/11 03:07:41
emacsで充分
281:デフォルトの名無しさん
08/05/11 12:09:33
>>278
開発中のEclipse用プラグインが割と頑張ってる感じ
282:
08/05/12 07:55:41
>>281
そうなのか、使ってみる。
283:デフォルトの名無しさん
08/05/12 13:55:30
Eclipse で実行のたびに Run Configuration が増殖するのは仕様ですか？
284:
08/05/14 04:39:03
Scalaって文の区切りに；が必要ないの？
なんか怖いです。
285:デフォルトの名無しさん
08/05/15 14:44:24
誰でもはじめては怖いもんだ
286:デフォルトの名無しさん
08/05/15 21:35:10
>>284
関数型言語などでは ; が必要ない方が普通。
HaskellやOCamlなんかでも;は必要ない。
287:デフォルトの名無しさん
08/05/15 21:49:16
ありますよ。
288:デフォルトの名無しさん
08/05/15 23:52:14
必要だけど必要じゃない。
289:デフォルトの名無しさん
08/05/16 03:05:20
Lispだとセミコロンはコメントアウトだな。
290:デフォルトの名無しさん
08/05/17 08:43:04
JavaとRubyとScalaの比較
URLﾘﾝｸ(codezine.jp)
291:デフォルトの名無しさん
08/05/17 15:35:15
Scalaの文法でDみたいなネイティブコンパイラって作れないかな。
292:デフォルトの名無しさん
08/05/17 18:38:06
単にネイティブバイナリがほしいだけだったらgcjであれこれ挑戦してみたら委員では
293:デフォルトの名無しさん
08/05/20 10:25:32
inforno :: Scalaでスタック指向言語をサクッと実装する
URLﾘﾝｸ(inforno.net)
294:デフォルトの名無しさん
08/05/21 23:03:40
scalaって遅延評価あるんだな。
最初からそれ言ってくれたら切り捨てたりしなかったのに。
295:デフォルトの名無しさん
08/05/21 23:11:11
お前の方が切り捨てられたんだよ。
296:デフォルトの名無しさん
08/05/22 18:11:38
煽られたら乗るよ？
scalaに意志はないから切り捨てるも切り捨てないも人の意志にゆだねられる。
scalaと人を混同しないでくださいね。
それとも、scalaたんとかいって擬人化してるキモオタくんですか？
297:デフォルトの名無しさん
08/05/22 20:11:14
scalaたんの擬人化マダー？
298:デフォルトの名無しさん
08/05/23 05:02:26
>>296
君、さぞ国語の成績が悪かったろうな。
299:デフォルトの名無しさん
08/05/23 05:38:47
>>296
乗るにしてもその乗り方はないだろ。
>scalaに意志はないから切り捨てるも切り捨てないも人の意志にゆだねられる。
って、どんな返しだよ。
というか、返しにすらなってないか・・・。
300:デフォルトの名無しさん
08/05/23 05:48:16
>>296
煽られたら乗るよ？
> scalaに意志はない（後略）
まず、議論の前に、どのような哲学的立場をもとにしているのかをハッキリしてもらおうか。
301:デフォルトの名無しさん
08/05/23 05:48:24
>>296
scalaにはMartin Oderskyの意思が宿っている
と返して欲しかったんですね。
わかります。
302:デフォルトの名無しさん
08/05/23 05:54:40
キモオタとか言って煽ってる本人が
なんか凄くオタクに詳しいっぽいのがたまらんね
沸いた頭で煽りを書き殴ったら、自分が普段言われてるモノが出てきました、みたいな
303:デフォルトの名無しさん
08/05/23 07:50:20
どんな言い方してみても>>294が付いて行けなかった事にかわりはない。
304:デフォルトの名無しさん
08/05/23 08:44:58
>>294の書いたscalaたんが観たかった…
305:デフォルトの名無しさん
08/05/23 09:27:29
codezineのメルマガのタイトルに scala が出てきて吹いた
◆【Web】私がScalaを選んだ理由
最近自分の中でScalaという言語が熱い。RubyやPython等のスクリプト言語や、
JavaやC#等現在のエンタープライズ領域を支える言語、HaskellやErlangといった
関数型言語もある。そんなにいっぱいいい言語がある中で，なぜ今Scala
なんだろう？そんな理由を解説してみたいと思います。
URLﾘﾝｸ(codezine.jp)
306:デフォルトの名無しさん
08/05/23 11:33:17
>>303
scalaを一見したらどう見えるかというと、
・JAVAのクラスファイルはくの？つまり所詮はJAVAの亜種ってこと？JAVAにはウンザリなんだよなぁ
・クラス？なんだ、またオブジェクト指向言語か。ツマンネ。
・アルジェブライックデータタイプなし？キモ。おいおい、どこが関数型言語だよ。
・しかも見た目は完全手続き型言語っぽい。
遅延評価以外これといった特徴無いですよね。
307:デフォルトの名無しさん
08/05/23 17:23:39
>>306
英語docの読めない香具師はScalaに手を出すなｗ
308:デフォルトの名無しさん
08/05/23 17:35:11
>>307
既存のプログラミング言語が多すぎて新しい言語が出てきても大して興味もでないのに、
ドキュメントまで見ようと思うわけがないだろ？ｗ
ブログを見ていて、たまたま言語の紹介があったら読む程度。
言語に興味を持つか持たないかが決まるのはせいぜい5分程度だ。
まぁ、言語の特徴を説明しきれていない糞ブロガーが全部悪いわけだがwww
309:デフォルトの名無しさん
08/05/23 17:39:56
そうやってすぐ雑草を生やす
310:デフォルトの名無しさん
08/05/23 17:58:10
まぁ、小物アプリ作者の俺としてはネイティブ吐いてくれない時点でアウト
311:デフォルトの名無しさん
08/05/23 18:04:47
遅延評価以外これといった特徴無い言語に興味を抱いて、ここに来たの？
312:デフォルトの名無しさん
08/05/23 18:06:31
>>311
遅延評価が実装されている言語を挙げてみろ。
思いつく限りでは片手に収まる。
313:デフォルトの名無しさん
08/05/23 20:16:42
>>312
Haskell
Scala
Clean
UnLambda
314:デフォルトの名無しさん
08/05/23 21:21:34
>・JAVAのクラスファイルはくの？つまり所詮はJAVAの亜種ってこと？JAVAにはウンザリなんだよなぁ
>・クラス？なんだ、またオブジェクト指向言語か。ツマンネ。
さすがにこの釣り餌は、おいしそうじゃないな。
315:デフォルトの名無しさん
08/05/23 21:27:18
じゃあ食いつくなよｗ
316:デフォルトの名無しさん
08/05/23 21:29:16
ごめｗ
317:デフォルトの名無しさん
08/05/24 01:10:13
自分が食いついた餌の低質さをいくら口にしたところで、相手のレベルじゃなく
「そんなのに食いついた自分のレベル」の低さをアピールするだけなのにね（相手には1ポイント入る）。
318:デフォルトの名無しさん
08/05/24 01:17:48
ごめん、わるかったって
319:デフォルトの名無しさん
08/05/24 01:45:38
>>312
OCaml
pypy
320:デフォルトの名無しさん
08/05/24 03:59:21
>>306
頭悪そうだね
321:デフォルトの名無しさん
08/05/24 04:00:25
>>312
> 思いつく限りでは片手に収まる。
なんて無知な…
322:デフォルトの名無しさん
08/05/24 12:58:25
なんだここの奴ら・・・
まだHaskellスレの方が「できた」人間が多いぞ・・・
323:デフォルトの名無しさん
08/05/24 12:59:02
スレ住人の人間性を見てもわかる。
この言語はJavaの系列なんだな。
324:デフォルトの名無しさん
08/05/24 14:11:12
Javaじゃないのが最大の利点。
325:デフォルトの名無しさん
08/05/24 15:03:27
JVMに縛られたローカル言語
326:デフォルトの名無しさん
08/05/24 15:08:52
>>322-324
Haskellの名前だけ挙げてPD.Martin Oderskyに直接何も言えないのって恥ずかしいよな
327:デフォルトの名無しさん
08/05/24 15:09:00
もうJVMを次期windowsに埋め込めばいいんじゃね？
328:デフォルトの名無しさん
08/05/24 15:11:55
>>326
俺はscalaのこと何もしらねーもん＾＾
俺が批判してるのが言語scalaだと思っていたら大間違いだぜ。
お前らを含めたコミュニティと広報活動全般についてなんだよ。
「外」の人間がどう感じるか感想を言ったまでさ。
お前ら被害妄想ひどすぎwww
329:デフォルトの名無しさん
08/05/24 15:25:30
>>328
> 俺はscalaのこと何もしらねーもん＾＾
（ ´,_ゝ｀）ﾌﾟｯ
330:デフォルトの名無しさん
08/05/24 15:42:11
>>329
頭の可哀想な子に触るの禁止ーーー!!
331:デフォルトの名無しさん
08/05/24 15:46:29
俺が思うに、コミュニティが健全であるためには、Javaとのつながりを完全に切った方がいいと思うんですよ。
>>329-330のような奴らをJavaに隔離すべきだと思うんです。
332:デフォルトの名無しさん
08/05/24 15:47:06
っていうかさ、数学出来ないやつが関数型言語さわるなよ＾＾＾
333:デフォルトの名無しさん
08/05/24 15:47:46
「このマスにとまったら、ム板のScalaスレを荒らしてくる」
とかいうゲームなんだよ。
334:デフォルトの名無しさん
08/05/24 15:49:36
>>328
> お前らを含めたコミュニティ
2chをコミュニティ認定しないでくれ
335:デフォルトの名無しさん
08/05/24 16:49:54
>>334
馬鹿にそんなこと言っても始まらないだろ。
336:デフォルトの名無しさん
08/05/24 16:57:08
>>334
妄想がどうのと言い出す人が、むしろ自分こそ激しい妄想を前提としているのはよくある話。
つまり、自分が言われると致命的な指摘を、先に相手になすりつけておく手法。
337:デフォルトの名無しさん
08/05/24 17:01:32
自己投影化ですねわかります
338:デフォルトの名無しさん
08/05/24 18:38:40
>>328
人間やコミニティまで批判するのはやめような。
フレームにしかならないよ
339:デフォルトの名無しさん
08/05/24 18:53:07
>>338
ああ悪かったな。
「活動」を批判すべきだったなｗ
340:デフォルトの名無しさん
08/05/25 04:52:14
もう引くに引けなくなってるのねｗ
341:デフォルトの名無しさん
08/05/25 06:57:59
>>332
関数型さわって慣れてから、数学勉強するのでいいと思う。
342:デフォルトの名無しさん
08/05/25 22:50:07
興味持てないのにいちいち荒らしにくる＞ツンデレ
343:デフォルトの名無しさん
08/05/26 02:18:42
というか、このところのScalaの取り上げられ方を見て
「なんか落ち着かない気分になった」Ruby信者では。
344:デフォルトの名無しさん
08/05/26 06:35:01
序盤に遅延評価を連呼していたあたり、遅延評価で切り捨ての子じゃないのか？
345:デフォルトの名無しさん
08/05/26 18:19:49
C#並にIDEの支援が充実してくれるといいんだが・・・・
;が省略可なんて仕様はIDEにとって厄介者にならないのだろうか？
346:デフォルトの名無しさん
08/05/26 21:27:38
;を書かなくていい言語が変に思うヤツは、プログラミング言語知らなさすぎ。
他の言語も知っといた方がいい。勉強しろ。
347:デフォルトの名無しさん
08/05/26 21:42:27
勉強の問題じゃないが。
348:デフォルトの名無しさん
08/05/26 21:49:59
アホが勉強しろとか言ってるの見ると滑稽でたまらん
349:デフォルトの名無しさん
08/05/26 21:50:08
そういや、VBのインテリセンスは完璧だったな
350:デフォルトの名無しさん
08/05/26 22:11:23
Haskell知ってるヤツと、Javaしか知らないヤツのコードを見ると、同じScalaでも全然違う。
あたりまえだが。
351:デフォルトの名無しさん
08/05/27 20:28:26
荒れてるなあ
とりあえず、Algebraic data type相当の機能はScalaにもあるよ
あと、Scalaの特徴と言ったらやっぱりimplicit conversion/parameterとか
Extractorとかじゃないかと個人的には思う
352:デフォルトの名無しさん
08/05/27 20:29:35
>>345
Visual StudioとかEclipse並にはまだ程遠いけど、Scalaで書き直された
新Scala Eclipse Pluginは結構補完頑張ってるよ。implicit conversionで
追加されたメソッドとかも補完してくれる。
353:デフォルトの名無しさん
08/05/27 20:48:15
>>343言い得て妙だな。まさにそんなのが身近にいるのでツボった。
354:デフォルトの名無しさん
08/05/27 22:15:41
またいつもの浮気癖か＞Ruby信者
浮気するくせに浮気相手にRubyを求めるからなあ。
355:デフォルトの名無しさん
08/05/27 22:27:06
；と｛ばかりの言語しかやったことない俺涙目
そんな人は何からやればいいですか？やっぱりHASKELLとかですか？
356:デフォルトの名無しさん
08/05/27 23:15:50
あと、SmalltalkとSchemeかな。
357:デフォルトの名無しさん
08/05/27 23:20:30
>>354信者のふりしたアンチに騙されてるんだよ。Rubyistは向上心のある人格者が多い。
358:デフォルトの名無しさん
08/05/27 23:42:38
間を取って、Ruby信者とRubyistは違うということでこの話はお開き。
359:デフォルトの名無しさん
08/06/02 18:18:44
>355
ここは forth で
360:デフォルトの名無しさん
08/06/10 10:17:32
本家ホムペ落ちてる！＞＜;
・・・
大幅リニューアルということか？
361:デフォルトの名無しさん
08/06/10 20:53:23
>>360
いつまで落ちてたのか知らんが、もう復旧してるよ
Webページのデザインは以前と特に変化無し
362:デフォルトの名無しさん
08/06/10 21:15:06
1つだけ、def という適当な予約語が気に入らない
363:デフォルトの名無しさん
08/06/11 01:07:42
じゃあdefunで…
364:デフォルトの名無しさん
08/06/11 02:02:47
>>362
じゃあ、defineだったら良かった？予約語って特に頻繁に
使用するものは、省略形を使ってでも短くした方が良いと思う
どうせ予約語の数なんて知れてるし、覚えることの労力よりも、
短くすることのメリットの方が大きいと思う
365:デフォルトの名無しさん
08/06/11 02:05:03
あと、defって予約語自体は結構メジャーなものだと思う。俺が知ってる言語では
Ruby,Python,Groovy,Scala,Nemerle,が採用してるな。Nemerleはかなりマイナーだと
思うが
366:デフォルトの名無しさん
08/06/12 00:27:39
クラスの宣言がclassなんだから、
メソッドの宣言はmethodでいいじゃん。
367:デフォルトの名無しさん
08/06/12 03:41:56
def か fun がいいな
368:デフォルトの名無しさん
08/06/13 20:31:18
ユニットテストフレームワークは何を使っていますか？
JUnit、TestNG、SUnit、ScalaTest、と色々な選択肢があるので迷っています。
369:デフォルトの名無しさん
08/06/15 09:50:53
def, fun は飽きた。df, fn とかしてほしい。
370:デフォルトの名無しさん
08/06/15 10:54:52
ディスク残量の表示をファンクションキーに割り当てたいんですね。わかります。
371:デフォルトの名無しさん
08/06/15 10:58:37
Scala の関数プログラミングが理解できません。
ScalaTutorial.pdf を読んでみました。Martin Odersky は scala で OOP
language と functional programming を統合して compose program を目指
していると理解しています。
でも tunctional programming は状態を持たないこと、変更できるデータが
存在しないことが特徴です。関数呼び出しに side effect がないことが特徴
です。 Python は、既存の関数に side effect があることから本格的な
functinal programming には踏み込もうとしません。Scala では関数の
side effect をどうやって防いでいるのでしょうか？
私には Scala の関数プログラミングは side effect を許しているとしか思
えません。もしそうだとすると、scala の関数プログラミングは偽関数プロ
グラミングだとも言えると思います。
372:デフォルトの名無しさん
08/06/15 11:07:44
tunctional programmingと言われても…
Scalaは関数型言語じゃないよ。
373:デフォルトの名無しさん
08/06/15 11:34:45
機能として見た場合、参照透明自体はそんなに重要じゃないでしょ
並列処理とか遅延評価のときに都合がいいだけで
それに純粋な関数型言語っていわゆる関数型言語の中でも一部分であって
純粋じゃなかったら偽というのも極端な気がするけど
374:デフォルトの名無しさん
08/06/15 13:27:32
371 です。
>純粋じゃなかったら偽というのも極端な気がするけど
同意します。
でも、side effect 使いまくりの pattern match: match .. case ... を書
いていたら、それは偽関数プログラミングと言っても良いでしょう。そして
scala は、それを許しているように思えます。Stateless, immutable にす
るのはユーザーの努力に委ねられているように思えます。違いますでしょう
か。
375:デフォルトの名無しさん
08/06/15 13:59:00
それはプログラミングスタイルの話で、言語がどうかって話とはちょっと違う気がする。
376:デフォルトの名無しさん
08/06/15 13:59:56
ん？よくわからん
パターンマッチと副作用がどう関係してるんだ？
377:デフォルトの名無しさん
08/06/15 14:16:17
>>374
>それは偽関数プログラミングと言っても良いでしょう。
誰にも会わずに一人で呼ぶ分には別に良いんじゃない？
>Stateless, immutable にするのはユーザーの努力に委ねられているように思えます。
という言語は別にScalaが最初という訳じゃないというか歴史に何度も登場したものに思われ。
URLﾘﾝｸ(user.ecc.u-tokyo.ac.jp)
>関数的プログラミングとは，副作用ではなく，値を返すことで動作するプログラムを書くことだ．
>副作用とはオブジェクトの破壊的な変更（rplacaの使用等）や変数への代入（setqの使用等）を含む．
>副作用を使う数が少なく，その影響範囲もローカルなものであれば，
>プログラムの読み取り，テスト，デバッグは簡単になる．
>Lispのプログラムが必ずこの方法で書かれてきた訳ではないが，
>時を追ってLispと関数的プログラミングは次第に分かち難いものになってきた．
378:デフォルトの名無しさん
08/06/15 14:20:10
371 です
>パターンマッチと副作用がどう関係してるんだ？
Pattern match は functional programming の機能だと思います。ここで書
かれるコードは副作用のないものに限定されるべきだと思います。クラス・
データ・メンバーを設けて、それを操作するなんてしてはならないと思いま
す。そうでなかったら、compose program なんて実現できないでしょう。
379:デフォルトの名無しさん
08/06/15 14:22:31
>>378
> Pattern match は functional programming の機能だと思います
なこたーない
380:デフォルトの名無しさん
08/06/15 14:22:50
>>378
マッチングのときに副作用が起きるのがいけないということ？
それともマッチングの後の話？
compose programというのもよくわからんな
381:デフォルトの名無しさん
08/06/15 14:24:26
>>379
パターンマッチって関数型由来じゃないんだっけ？
382:デフォルトの名無しさん
08/06/15 14:28:51
>>378
要するにMartin Oderskyの謳い文句が煽りっぽくて気に入らないなら本人に言った方が良いよ。
副作用なしでプログラミングを行うという意味論的なテーマと、
単なるシンタックス(Pattern match)の議論がごっちゃになってる気がする。
「条件分岐の意味論」と「条件分岐が楽に書けるか」は全然別の話。
意味論の定義については偉い人に任せる。
URLﾘﾝｸ(d.hatena.ne.jp)
383:デフォルトの名無しさん
08/06/15 14:35:32
>>369
そこで defun ですよ。Lisp 的に。
384:デフォルトの名無しさん
08/06/15 14:50:53
join計算では破壊的変数操作は許されるのですか？
385:デフォルトの名無しさん
08/06/15 15:09:24
>>381
由来は知らんがPrologとかにもあるだろ
だいたいパターンマッチングで副作用を否定したらawkの立場はどうなるんだよｗ
386:デフォルトの名無しさん
08/06/15 15:15:20
371 です
>マッチングのときに副作用が起きるのがいけないということ？
>それともマッチングの後の話？
cast ... ==> の後に書かれるコードで副作用があるものを呼び出さないの意味です。
>compose programというのもよくわからんな
下の Martin Odersky 自身の説明から持ってきました。彼はプログラムの部
品化を本気で可能にしようとしています。
URLﾘﾝｸ(video.google.com)
URLﾘﾝｸ(lampwww.epfl.ch)
>パターンマッチって関数型由来じゃないんだっけ？
関数型由来由来でしょう。switch case 文で置き換えられる代物ではないでしょう。
387:デフォルトの名無しさん
08/06/15 15:24:02
Pattern match は functional programming の機能
と
Pattern match は functional programming に由来
は別物だぞ
関数型言語以外でもパターンマッチングが見られるから前者は間違い
wikipediaによるとKen Thompson(Unixの作者)が作ったエディタや
SNOBOLが由来だから後者も間違い
388:デフォルトの名無しさん
08/06/15 16:01:39
なんちゃって知識を抱えて、新規言語に刃向かいに来たボクちゃんってことで決着ですか？
389:デフォルトの名無しさん
08/06/15 16:24:50
>381
『由来』と『機能』は別物。
Lispみたいにパターンマッチ前提にしていない関数型言語は普通にあるよ。
逆にC++のオーバーロードとかだって一種のパターンマッチだし。
>378
そんなつまらん理由で『べき』なんて断定するもんじゃないよ。
・Pattern Matchに失敗したときの挙動が複雑すぎて制御不能
・追加したパターンマッチの影響が他の関数に波及するリスクがある。
状態の管理が困難になる
とか具体的な理由ぐらい書いたら？
状態（副作用）の本質についてはガウディ本が詳しいので、一回読んでみたら。
390:デフォルトの名無しさん
08/06/15 16:24:56
>>386
だったら、通常のifとパターンマッチを区別して、パターンマッチを特別視する理由は？
パターンマッチって便利なifみたいなもんだと思っているんだけど
391:デフォルトの名無しさん
08/06/15 16:50:12
なんか不毛な議論になっとるなー
>>374の言っているのに合致するのって、HaskellとCleanくらいじゃね？
あと、パターンマッチについては強力なif文という認識くらいで良いと思うなー
392:デフォルトの名無しさん
08/06/15 18:18:32
パターンマッチ＞判定にパターンのみ使用可＞判定に副作用無し
Scalaのクラスフィールドは暗黙のゲッタ・セッタ呼び出し＞
ゲッタ・セッタの明示定義でもフィールド名のみで呼び出し＞
意図せざる副作用はそれらで相殺可
393:デフォルトの名無しさん
08/06/15 19:56:33
OCamlだとパターンマッチ使って、
let (x,y) = mouse_point in
printf "%dだお, %dだお" x y
とかできるけど、scalaだとどんななんだろ。
394:デフォルトの名無しさん
08/06/15 20:01:40
scala> val (a, b) = (1, 2)
a: Int = 1
b: Int = 2
こんなのなら動くよ
395:デフォルトの名無しさん
08/06/16 00:39:39
Tuple以外でも使えるけど、なんか違和感があるな
case class TypeA(val a:Int,val b:Int)
val TypeA(a,b)=TypeA(10,20)
println(a)
println(b)
396:デフォルトの名無しさん
08/06/16 01:48:47
>>395
違和感あるってのは単にパターンマッチ自体に慣れていないという
事じゃないかなあ。Scalaに限らず、SML,OCaml,Haskellなどでも同様の
事はできるわけだし
397:デフォルトの名無しさん
08/06/16 02:36:04
ちなみに1行目caseつけるならvalは要らない。
398:デフォルトの名無しさん
08/06/16 03:02:29
case関係なくval要らなくね？
399:デフォルトの名無しさん
08/06/16 10:28:28
>>398
いや、要るでしょ。case classにしなきゃパターンマッチの
対象にできない。もちろん、別途unapply定義したobjectを
定義すれば別だけど
400:デフォルトの名無しさん
08/06/16 10:50:05
あ、ごめん、意図を取り違えていた。case classじゃなきゃ、そもそも
valのあるなしに関わらずパターンマッチできないわけで、確かに
必要ないわな。
401:デフォルトの名無しさん
08/06/16 11:37:31
細かいことだが、unapplySeqでもおｋ
val s = "([0-9]*)(.*)".r
val s(x,y) = "123いちにさん"
println(x) // 123
println(y) // いちにさん
402:デフォルトの名無しさん
08/06/16 20:00:45
case classでは暗黙にvalだが、case以外でもvalやvarで
コンストラクタ引数もメンバ化できるのだだだだだだ
403:デフォルトの名無しさん
08/06/18 03:44:07
Javaでは
String.class
のように書くと、対象のクラスのインスタンスを作成せずに
Class型のオブジェクトを取得することができますが、
scalaで同様のことをするにはどのように書けばよいのでしょうか？
404:デフォルトの名無しさん
08/06/18 04:35:06
つ type
405:デフォルトの名無しさん
08/06/18 05:15:02
つ classOf[String]
406:デフォルトの名無しさん
08/06/18 06:13:01
>>405
ありがとうございます。探していたのは正にこれでした。
>>404
type a = b で型の別名が作れるんですね。
今回探していたものとは違いましたが、参考になりました。
407:デフォルトの名無しさん
08/06/19 12:55:22
def getFunc(fun:Option[String => _ <: AnyRef]) = {
fun match {
case None => null
case Some(f) => (i:String) => f(i).notify()
}
}
上記のコードをコンパイルすると notify() の部分でエラーになりました。
fがStringを引数に取る関数であるというところまでは推論できているのに、
fの戻り値がAnyRefを継承した型である事を推論できないのはなぜなのでしょうか？
408:デフォルトの名無しさん
08/06/19 16:08:45
Existential Type周りの推論の仕組みは正直よくわかっていないので
確定的な事は言えないのですが、推論できていないというより、どうもバグな気がします
たとえば、上記のコードを
def getFunc(fun:Option[String => _ <: AnyRef]) = {
fun match {
case None => null
case Some(f) => (i:String) =>
val a: AnyRef = f(i); a.notify()
}
}
とすると、コンパイルが通ることから、少なくともf(i)の返り値が
AnyRefのサブタイプであることは(コンパイラによって)認識されている
ように見えます。色々試してみたところ、以下のようなコードの場合
val fun: Option[String => _ <: AnyRef] = Some((s: String) => s)
val Some(f) = fun
コンパイラが
error: fatal error: bad type: ?(class scala.tools.nsc.symtab.Types$WildcardType$)
というメッセージを吐いて落ちるようです。この辺の事から推測すると、
Existential Typeとパターンマッチを組み合わせたときのバグのような気がしますが、
本当のところはわからないので、本家ScalaのMLで聞いてみるのが良い気がします
409:デフォルトの名無しさん
08/06/19 16:10:42
回避策ですが、Function Typeは、返り値についてcovariant
annotationが付加されているので、わざわざExistential Typeを使わずに、単純に
def getFunc(fun:Option[String => AnyRef]) = {
fun match {
case None => null
case Some(f) => (i:String) => f(i).notify()
}
}
とすれば良いです。これで、ちゃんと
getFunc(Some((s: String) => s))
などのコードをコンパイルできます
410:デフォルトの名無しさん
08/06/19 23:16:10
>>408-409
いろいろと試して頂き、ありがとうございました。
Existential Typeを使わないようにすることで、無事、動くようになりました。
英語は苦手なのですが、
そのうち、本家ScalaのMLでの質問にも挑戦してみようと思います。
411:デフォルトの名無しさん
08/07/09 08:47:29
ScalaのEclipsePluginは、Eclipseのどのバージョンで動きますか？
412:デフォルトの名無しさん
08/07/09 23:33:30
URLﾘﾝｸ(www.scala-lang.org)
413:デフォルトの名無しさん
08/07/31 19:30:46
プログラミングしりとり
ｽﾚﾘﾝｸ(575板)l50
414:デフォルトの名無しさん
08/08/21 01:19:30
Webサイトが変わった
415:デフォルトの名無しさん
08/08/21 09:21:03
Renewal ですな
NetBeans 用プラグインも追加されてる > ヘルプも含めて IDE 本体のオール
日本語化は NetBeans の方がダンゼン速いので日本人にとっては良い知ら
せか
ただし 6.5 以上だけど (現在日本語はまだ GUI のみか日本語開発版のみ)
416:デフォルトの名無しさん
08/08/22 02:27:02
Scala本5月には出版っていってたのにまだプレプリントか。
417:デフォルトの名無しさん
08/08/22 14:10:17
Scala本待てない人は、単なる個条的抜き書き程度のしろものですが
それまではこちらをどーぞ
URLﾘﾝｸ(www.h7.dion.ne.jp)
418:デフォルトの名無しさん
08/08/22 15:00:49
うはｗ こういうのうれしい。
英語のリファレンス読むのメンドくさくて、いまいちちゃんと理解できてなかったんで、
すげーうれしい。
419:デフォルトの名無しさん
08/08/22 21:31:43
>>417
これ、ただの機械翻訳じゃないの？
420:デフォルトの名無しさん
08/08/22 21:51:13
>>416
URLﾘﾝｸ(www.artima.com)
そろそろ出るんじゃないの？
421:デフォルトの名無しさん
08/08/22 21:51:42
機械翻訳はこういう文章を吐かないと思う
なんていうか、プログラマというよりは人文系の方が書いたような文章
422:417
08/08/22 23:32:47
プログラマ向け、でなくJavaとJavaScriptならわかる、という人を想定したら
こんな文章に。
Scalaは、そんな人たちの(関数型言語)入門学習用に向く言語仕様である
ように思われたので。
(つーか私自身にとっても最新の関数型言語の入門学習目的で言語仕様
原文から外せない部分を抜き出す形でまとめました(直訳はおろか意訳で
すらねぃです、でも原文読む参考程度にはなるはず)。ちなみにコンカレント
云々はまだわからない程度のレベルな私)
423:417
08/08/22 23:37:07
あーあといちばん最初に訳した言語仕様要約は直すべき部分が最多ですが
今はいろいろあって直すヒマがないのであしからず(私自身によるコメント部分
に集中してるので、そこの変なのは無視してくだされ。要約でない解説諸ペー
ジの方のが正しいです)。
424:デフォルトの名無しさん
08/08/22 23:42:12
＞If you purchase just the PDF eBook for $27.50, you will be entitled to receive periodic updates as the authors
＞complete the book, as well as the final PDF when the book is finished, for no additional charge. If you purchase PDF
＞+ Paper Book combo for $59.99, you will be entitled to the PDF eBook updates, and we'll ship you the paper book
＞when it is published, on or around August 30, 2008. (Once the book has been printed, you'll be able to purchase just
＞the paper book here for $49.99.)
すいません。これ訳してください。
425:デフォルトの名無しさん
08/08/22 23:55:28
こんな感じか？
$27.50でPDF買ったら、本が完成するまで
追加料金なしでPDFのアップデート受けられるよ。
$59.99でPDFと紙の本買ったら、PDFのアップデートできるし、
10月30日くらいに出版されたら紙の本も送るよ。
出版後は$49.99で紙の本買えるよ。
426:デフォルトの名無しさん
08/08/22 23:57:21
August 30
8月30日、ですね
427:デフォルトの名無しさん
08/08/23 00:05:59
>>425-426
ありがとうございます！
もうすぐ発売日じゃないですか！
428:デフォルトの名無しさん
08/08/23 15:41:22
>>417
ひさびさに電波ぽい文章を見た
429:デフォルトの名無しさん
08/08/23 16:48:38
>>428
だなｗ
頑張ってくれたのに悪いが、行間びっちりな上にろくに段落を区切ってないから、
文章ではなくなんかの模様に見えてしまう。そんなだから最初の一文すら読む気が起きない。
430:デフォルトの名無しさん
08/08/23 17:34:52
>417
むむむ……典型的な『頭の良い人が書いた難しい文章』だな。
・文が長すぎ／意味詰め込みすぎ
・読者に必要な前提知識が多過ぎ
・話が発散しすぎ
ということでおいらもムリ。
自分も素人なんであんまり偉そうなことは言えないけど、
・一文の意味／意図が一つになるように文を解体する。
- ()の解説は多用しない。注釈で飛ばした方が良い。
- 直前の文までに出てきた言葉だけで文章を組む。新規の言葉は解説する。
・段落の基本構造（序破急）を意識して文章を構築する
・文章の基本構造（起承転結）を意識して段落や章を構成する
あたりだけでも注意すればずいぶん違うんじゃない？
431:417
08/08/23 20:41:20
いちばん最初のページの水平線から下は「言語哲学的意味論」なのでいわゆる
リファレンスとしては読む必要はまったくないです (つまり、この水平線は、ここから
下は「Scalaという言語に対する(個人的)注解」である、という意味です)
水平線から上の部分にザッと目を通したあとはそのまま「1階受付」へとお進みく
ださい (そこからはいくらかでもマシになってるかと)
432:417
08/08/23 20:47:00
あと行間は、私は逆に空いてると読みづらい方なので、直すかどうかは微妙です
Firefoxなら「スタイルシートを利用しない」すればほんの少しだけ行間が空いて字
ももう少しだけ大きくなるよーですが ...
433:デフォルトの名無しさん
08/08/23 21:11:55
行間以前の問題だろ＞読みづらさ
434:デフォルトの名無しさん
08/08/23 21:27:38
>>417
論文ではなく、仕様書を書くようになればみんなの気持ちが分かるようになるよ。
435:デフォルトの名無しさん
08/08/23 21:47:37
>>430
頭がよいのとおかしいのと狭間くらいだと思う
436:デフォルトの名無しさん
08/08/23 21:59:18
これで難しいって、どれだけ土方なんだよ。
スタイルシートは変更したけど。
437:417
08/08/23 21:59:54
読みづらさについては申し訳ないですが、いずれこのScalaページは6月頃に
書いたもので (必要な人はググって自力で見つけるだろうと思いこちらでとく
には宣伝しませんでした; まだいろいろと不完全であるためもありますが)、今
はほかにやるべきことができてしまって当分私自身による修正は無理っす
ぬか喜びさせてしまって申し訳なひ、おのおの方