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

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

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

1 :デフォルトの名無しさん:2011/09/04(日) 20:07:34.70
The Scala Programming Language
ttp://www.scala-lang.org/

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

■前スレ
プログラミング言語 Scala 6冊目
ttp://hibari.2ch.net/test/read.cgi/tech/1307416864/

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

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

2 :デフォルトの名無しさん:2011/09/04(日) 21:10:02.11
>>1
乙なんだぜ!
「ERROR:Lvが足りなくてスレッド立て(ら)れません。」
とか言われてスレ立てられなかったんだぜ…。日に日に使いにくくなる2ch。
しかしこれ、"ERROR"が全角で"Lv"が半角という統一感の無さで憤死しそうになるな…。

あと次スレからリンクにはこれも追加しようぜ

プログラミング言語Scala 日本語情報サイト
http://sites.google.com/site/scalajp/

3 :デフォルトの名無しさん:2011/09/04(日) 21:25:15.30
前スレの終わり方なんなの…

4 :デフォルトの名無しさん:2011/09/04(日) 21:32:59.14
前スレのことは次スレに持ち込まないのが2chのルール

5 :デフォルトの名無しさん:2011/09/04(日) 22:14:45.74
はい

6 :デフォルトの名無しさん:2011/09/04(日) 22:33:14.54
そんなルールは初耳だなぁ

7 :デフォルトの名無しさん:2011/09/04(日) 22:36:41.32
上手く使えば、いい感じで話題が切り替えられるのが
1000スレッド落ちシステムの特徴だとは思う

8 :デフォルトの名無しさん:2011/09/05(月) 00:46:15.08
結局またモヒカンが来て
この定義はおかしいって騒ぐだけだろ?

9 :デフォルトの名無しさん:2011/09/05(月) 01:31:26.76
>>2
前方互換性の考慮の結果だよ

10 :デフォルトの名無しさん:2011/09/05(月) 21:30:15.12
なぜScala村にはモヒカン族が沢山居るのですか?

11 :デフォルトの名無しさん:2011/09/05(月) 21:35:57.01
とんでもない!Scalaは初心者でもウェルカムですよ!!

12 :デフォルトの名無しさん:2011/09/05(月) 21:54:14.00
そうやって騙すのはもう無理だと思うの

13 :デフォルトの名無しさん:2011/09/05(月) 22:46:55.09
そんなにたち悪いモヒカンは居ないだろ。
JavaとかRubyのモヒカンのガチのキモさに触れたら、Scalaなんぞ平和そのもの。

14 :デフォルトの名無しさん:2011/09/05(月) 23:14:26.13
そもそもScala周辺には人がまだ少ないから、、、。

ていうかScalaやってる人って、何作ってるの?

Webから情報収集するプログラム書きたいのだが、他言語に比べて情報が少なすぎる、、。



15 :デフォルトの名無しさん:2011/09/05(月) 23:29:11.96
>>14
そのくらいならまずJavaで作ってみて、書き換えていけばいいのでは?

16 :デフォルトの名無しさん:2011/09/06(火) 00:05:47.55
Scalaの総代将がモヒカン過ぎるのがいけないのでは?

17 :デフォルトの名無しさん:2011/09/06(火) 00:12:23.51
C++はハゲだけど大丈夫だよ

18 :デフォルトの名無しさん:2011/09/06(火) 00:31:48.06
中之条

19 :デフォルトの名無しさん:2011/09/06(火) 00:36:02.42
REPLからJavaクラスを実行すると、その中の
URL url = Thread.currentThread().getContextClassLoader().getResource("log4j.properties")
という箇所で、urlにnullが格納されてしまうのですが、どなたか回避をご存知でしょうか?
(当然ながら、log4j.propertiesはクラスパス上においています。)

普通にコンパイルして実行すると、urlにはlog4j.propertiesのパスがちゃんと入るのですが…。

20 :デフォルトの名無しさん:2011/09/06(火) 03:27:55.43
おまえらがそうやって新しい言語に飛びついてる間に、cを極めてニッチかつ専門的な分野でウマー

21 :デフォルトの名無しさん:2011/09/06(火) 03:35:12.89
>>19
Thread.currentThread().getContextClassLoader()
で取得されるクラスローダが別物なので。
> val url = getClass().getClassLoader().getResource("log4j.properties")
とやるとちゃんと取得できます。

22 : ◆CgacaMDhSQ :2011/09/06(火) 03:38:50.48
>>16
総大将になったつもりは無かったんですけど、モヒカン過ぎると色々摩擦を生む事自体は理解してます。
あまりモヒカン的になりすぎないようにしようとは思っているのですけど、人間、すぐには変われないですね…。

23 :デフォルトの名無しさん:2011/09/06(火) 06:39:24.86
けーみずさん、スルーするのも大事w

24 :デフォルトの名無しさん:2011/09/06(火) 07:44:28.63
総大将というより、最大限持ち上げて切り込み隊長だろww

25 :デフォルトの名無しさん:2011/09/06(火) 09:38:56.36
>>22
限界集落のOCaml村に煽られてもスルーできるが、
同じJVM言語仲間のGroovy村に煽られたら戦争だろうが……!
って感じですかね?

26 :デフォルトの名無しさん:2011/09/06(火) 17:43:27.37
>>14
情報が少ないならここで聞けばいいじゃん

27 :デフォルトの名無しさん:2011/09/06(火) 20:03:24.84
他の言語がクソならdisってやりゃいいんだよ
馴れ合う必要なんてないね

28 :デフォルトの名無しさん:2011/09/06(火) 20:05:32.01
>>27
そういう怖い人はScala使わないでください><

29 :デフォルトの名無しさん:2011/09/06(火) 20:13:05.51
Scala ノ ヒンイ ガ 10 サガッタ


30 :デフォルトの名無しさん:2011/09/06(火) 20:38:53.53
ここのモヒカンよ、これ読んで少しは見習えよ
http://journal.mycom.co.jp/articles/2011/09/05/efl2/index.html

31 :デフォルトの名無しさん:2011/09/06(火) 20:47:44.01
>>30
キモいもん貼るなボケ

32 :デフォルトの名無しさん:2011/09/06(火) 22:29:36.75
どっかに配布されているjarファイルをこんな感じで読み込もうとすると、
> scalac a.scala -cp path/*.jar
error: IO error while decoding ... with UTF-8
Please try specifying another one using the -encoding option
で数時間ハマりました。
正解は
> scalac a.scala -cp "path/*:."
だそうです。("path/*.jar:."もダメらしい)

エンコーディングとか関係ねーじゃん!

33 :32:2011/09/06(火) 22:32:55.34
ぜんぜん関係ないですがこのスレ久々で、「モヒカン」の流れがわかりません。
誰か簡単に解説してちょ。

34 :デフォルトの名無しさん:2011/09/06(火) 22:39:38.71
>>33
はてな村用語。
http://mohican.g.hatena.ne.jp/keyword/%E3%83%A2%E3%83%92%E3%82%AB%E3%83%B3%E6%97%8F
「対立した文化として→ムラ社会」なんて書いてあるけど、
モヒカンが集まってムラ社会形成してるよな。


35 :32:2011/09/06(火) 22:43:39.34
>>34
thxです。
こんな用語かってに作られて、本家(native american)は迷惑してるだろな。

36 :デフォルトの名無しさん:2011/09/06(火) 23:20:52.38
モヒ漢

37 :デフォルトの名無しさん:2011/09/07(水) 13:32:17.20
引数に型Tをとって、Tを継承した型を返す関数って
どうやって書くんだっけ?

38 :デフォルトの名無しさん:2011/09/07(水) 19:59:16.62
http://groups.google.com/group/clojure/browse_thread/thread/b18f9006c068f0a0?pli=1

39 :デフォルトの名無しさん:2011/09/07(水) 23:21:37.73
>>37
お前モヒカン村で何聞いてるの?


40 :デフォルトの名無しさん:2011/09/07(水) 23:42:34.16
>>38
ソースとテストケース出さずにそんな事言われても…

41 :デフォルトの名無しさん:2011/09/08(木) 04:12:17.13
モヒカンならソースとテストケースで事実を示して反論しよう!

42 :デフォルトの名無しさん:2011/09/08(木) 05:10:10.64
>>38
長いから要約して

43 :デフォルトの名無しさん:2011/09/08(木) 08:01:09.88
>>42
Scalaの標準のアクター実装のせいで、負荷をかけるとOut of Memoryで落ちた
Clojureで書き直してみたら負荷かけても動くようになった
さらにコードも短くなった(行数:1,000行から260行、文字数:31kから11.5k)

44 :デフォルトの名無しさん:2011/09/08(木) 08:55:01.95
>>37
動的型言語では簡単に出来るけど、Scalaでは出来ません。

45 :デフォルトの名無しさん:2011/09/08(木) 16:42:36.92
そういえばScala-Swing使ってて、ComponentのpaintComponentをオーバーライドしてGraphics2Dを描画させる時に、
イベント処理でrepaintを呼ぶと以前描画したものが消えてしまうのの回避方法ってある?

例えで言うと、マウスでクリックした所に円を描くプログラムに関して、
新たにクリックすると直前に描いた円が消えてしまう感じ。
ここで聞くなって話なら申し訳ない。

46 :デフォルトの名無しさん:2011/09/08(木) 17:30:41.95
>>45
描いた円を全て覚えておくか、メモリ上にビットマップ展開して、そこに円を描画。
paint(repaint含む)はメモリ上のビットマップを画面に描画するだけ

Java/scalaに限らず、GUI全般の問題やね


47 :デフォルトの名無しさん:2011/09/08(木) 17:57:18.52
>>46
ありがとう。GUIプログラミングについてもっと勉強し直す。
スレチに近くてスマソ。

48 :デフォルトの名無しさん:2011/09/08(木) 17:57:46.91
>>43
カッコだらけの時代遅れ糞言語なんて誰も使わねえよ、ばーかばーか
っていうのを翻訳して投稿しておいてくれ

49 :デフォルトの名無しさん:2011/09/08(木) 23:58:46.23
>>44 >>37の意味がいまいちわからない。でもこれだけはいえる

動的言語にできるという意味でなら、scalaでもできる

以上

50 :デフォルトの名無しさん:2011/09/09(金) 07:31:09.91
>>49
こんなことがしたいのでは?

Python

def newType(T):
    class Foo(T):
        pass
    return Foo

C++

template <class T>
class Foo : public T {
};

51 :デフォルトの名無しさん:2011/09/09(金) 10:52:05.68
よくわからん

52 :デフォルトの名無しさん:2011/09/09(金) 18:00:05.89
ゆろよろがTwitterのアイコン変えてつまらん
不細工を角度で誤魔化そうとするスイーツ臭はどこにいった

53 :デフォルトの名無しさん:2011/09/09(金) 18:01:59.54
そういうのはヲチ板でやってくれ

54 :デフォルトの名無しさん:2011/09/09(金) 18:05:16.48
だから、Scalaでこんなコードが書けたら良いなってことかと(実際は以下のようには書けない)

def newType[T:ClassManifest]() : ClassManifest[Foo[T]] = {
    class Foo[T] extends T {}
    return implicitly[ClassManifest[Foo[T]]]
}
def construct[T](t:ClassManifest[T]) : T =
{
    return t.erasure.newInstance().asInstanceOf[T]
}
val t = newType[Bar]()
val x = construct(t)


こっちはPython版
http://ideone.com/lNfZi

55 :デフォルトの名無しさん:2011/09/10(土) 08:17:53.06
>>49「動的言語にできるという意味でなら、scalaでもできる(キリッ」

馬鹿過ぎワロタwww

56 :デフォルトの名無しさん:2011/09/10(土) 08:34:26.27
静的動的でいろんな所を煽ってるいつもの人でしょ
相手にするだけ無駄

57 :デフォルトの名無しさん:2011/09/10(土) 11:28:47.84
静的動的で煽り合いするスレどこいったんだ?
隔離スレとして機能してたのに

58 :デフォルトの名無しさん:2011/09/10(土) 11:39:05.96
ScalaはRubyより劣る
Pythonより劣る
F#のような洗練された言語設計もない

どうやってつかえばいいの?

59 :デフォルトの名無しさん:2011/09/10(土) 11:52:17.03
無理して使わなくていいんだよ^^

60 :デフォルトの名無しさん:2011/09/10(土) 16:01:01.60
ジェネリックの型引数って継承できたらいいと思わない?
実体化したらそれで終わりなんて継承ツリーの中で使いにくい
自分と同じ型のメンバーを表すだけでも大変
抽象型を使ってみたが妙に不自然な書き方しか思いつかない

abstract class Base {
type TParent <: Base
var parent: Option[TParent] = None
}

class とり extends Base {
override type TParent <: とり
override def toString = "とり"
}

class とんび extends とり {
override type TParent <: とんび
override def toString = "とんび"
}

object AbstractTypeTest {
def main(args: Array[String]) = {
var とり = new とり { type TParent = とり }
とり.parent = Option(new とり { type TParent = とり })
println(とり.parent)
var とんび = new とんび { type TParent = とんび }
とんび.parent = Option(new とんび { type TParent = とんび })
println(とんび.parent)
}
}

61 :デフォルトの名無しさん:2011/09/10(土) 20:37:55.02
>>55 馬鹿すぎるのはお前。そもそも自分の思い込みが完全にまちがっていることにまるできずいていないwww

62 :デフォルトの名無しさん:2011/09/10(土) 21:42:59.38
>>61
「使うプログラミング言語により思考は制限される」
http://www.slideshare.net/yukihiro_matz/ruby-9183142
http://itpro.nikkeibp.co.jp/article/NEWS/20110909/368352/

つまり、静的厨の発想は制限されてるから
動的言語でしか出来ない事は思い浮かばないw

63 :デフォルトの名無しさん:2011/09/10(土) 21:47:24.37
Rubyより劣るScalaを使うと思考が制限されるよ

64 :デフォルトの名無しさん:2011/09/10(土) 22:00:13.97
>>62
静的言語でしかできないこともあるから
両方やれば一番いいんだよな


65 :デフォルトの名無しさん:2011/09/10(土) 22:36:27.47
心を落ち着けて>>56を読むんだ

66 :デフォルトの名無しさん:2011/09/10(土) 22:41:08.86
バイトコード操作で実行時に引数の型を継承したクラスを生成って言う風になら出来るがちょっとずれるか

67 :デフォルトの名無しさん:2011/09/10(土) 23:42:54.39
Rubyのような幅広い概念を取り込んで
いない言語なんてつかっちゃダメだよなぁ

68 :デフォルトの名無しさん:2011/09/10(土) 23:56:58.90
まあアンチがいるだけ言語発展してる証拠にもなるし微笑ましい対応で

69 :デフォルトの名無しさん:2011/09/10(土) 23:59:57.79
>>68
モヒカン言語らしくしろよ

70 :デフォルトの名無しさん:2011/09/11(日) 00:13:01.01
動的言語の方がより制限されていることにまだきづいていないようだなww


71 :デフォルトの名無しさん:2011/09/11(日) 00:22:03.38
>>69何故俺がD 言語住民と…!

72 :デフォルトの名無しさん:2011/09/11(日) 04:05:52.98
動的言語+型+静的型チェック=静的型付け言語
と考えれば、静的型付けの方がリッチだな。
いらないときは静的型チェックをはずせばいいだけ。

73 :デフォルトの名無しさん:2011/09/11(日) 05:30:03.22


74 :デフォルトの名無しさん:2011/09/11(日) 06:31:09.57
scala好きだけどIDEとか未熟だから止めたとかいう英語の記事かなんかが紹介されてたけど、みつけられません。
確かコンパイラ系を作ってる人の文章で、Javaと別のtoolに戻ったとか言ってました。
どんなtoolか知りたいので、もう一度その記事を教えて下さい。

75 :デフォルトの名無しさん:2011/09/11(日) 08:30:31.50
>>70>>72
じゃあ、Dumpクラスを継承したクラスの全ての公開メソッドに
引数と戻り値を出力する処理を追加するようなDumpクラスを
Scalaで書いてみてよ
動的言語なら10行くらいで書けるから

76 :デフォルトの名無しさん:2011/09/11(日) 10:44:24.56
>>75
っ AspectJ

77 :デフォルトの名無しさん:2011/09/11(日) 10:57:45.99
bytecode manipulationなんて卑怯ですう><

78 :デフォルトの名無しさん:2011/09/11(日) 11:02:13.76
>>77
そんな君にはdynamic proxy。

79 :デフォルトの名無しさん:2011/09/11(日) 11:47:01.83
何でも使っていいからScalaで書いてみなよ

80 :デフォルトの名無しさん:2011/09/11(日) 11:59:30.26
そもそもLoggingのweavingを、言語のネイティブな機能だけを使って10行で書けると何かメリットがあるのか。

81 :デフォルトの名無しさん:2011/09/11(日) 12:01:40.91
さすがモヒカン言語
コードは書けないが口だけは一人前

82 :デフォルトの名無しさん:2011/09/11(日) 12:08:27.00
Scalaだけでは書けないよ、うん、終了。
で、それが実用においてどういうデメリットがあるの? って聞いてるんだけど。

83 :デフォルトの名無しさん:2011/09/11(日) 13:03:24.06
またモヒカンが暴れてる

84 :デフォルトの名無しさん:2011/09/11(日) 13:23:30.71
>>60
暗黙的変換を使って少しましな書き方ができた
でも素直じゃない

class HasParent[TParent <: Base](any: TParent) {
def parent = any.parent
def parent_=(p: TParent) = any.parent = p
}

abstract class Base {
var parent: Base = _
}
class とり extends Base {
override def toString = "とり"
}
class とんび extends とり {
override def toString = "とんび"
}

object AbstractTypeTest {
implicit def toHasParent[T <: Base](any: T): HasParent[T] = new HasParent[T](any)
def main(args: Array[String]) = {
var とり = new とり
とり.parent = new とり
println(とり.parent)
var とんび = new とんび
とんび.parent = new とんび
println(とんび.parent)
}
}


85 :デフォルトの名無しさん:2011/09/11(日) 14:05:16.68
>>83
自分の思い通りにならないとモヒカンのせいにするのはよくないな。

86 :デフォルトの名無しさん:2011/09/11(日) 14:09:56.28
スカラって10回言って。


スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ
スカラ

巣から落ちた鳥は?

カラス!

87 :デフォルトの名無しさん:2011/09/11(日) 14:26:26.20
死ねよ

88 : ◆CgacaMDhSQ :2011/09/11(日) 14:29:29.51
>>60
型引数「を」スーパークラスから継承したい場合は、まさに抽象型使えってのがScala流かと思います。あと、
ジェネリックで型引数を継承できるようにしたとして、ややこしくなるだけな気がします。型引数はメンバ
じゃないので、本来継承できるべきものじゃないですし。

あと、ここで「とび」や「とんび」クラスをさらに継承する必要が無いなら、
override type TParent <: とび
じゃなくて、
override type TParent = とび
にしてしまった方がいいのではないかと。そうすれば、new とび { type TParent = とび } じゃなくて、単にnew とび
と書けますし。

89 :デフォルトの名無しさん:2011/09/11(日) 14:38:16.65
スクルト

90 :デフォルトの名無しさん:2011/09/11(日) 14:38:37.60
モヒカンだ助けてくれぇ

91 :デフォルトの名無しさん:2011/09/11(日) 15:41:54.64
みんな飽きてるのにずっとモヒカン言ってるのっていつもの知的障害の人?

92 :60,88:2011/09/11(日) 17:01:16.07
>>88
ありがとうございます
override type TParent = とび
継承する必要がないのならこの方がよいのはわかります
それだと継承の可能性を閉じてしまいますのであえてあの書き方にしました


93 :60,88:2011/09/11(日) 17:04:08.90
変数の変位(代入互換性)の問題は残るのですが、
こんな書き方が許されたらと思いました

abstract class Base {
type TParent <: Base
var parent: Option[TParent] = None
}

class とり extends Base {
override type TParent = とり //ここで指定しても派生クラスで継承できる
override def toString = "とり"
}

class とんび extends とり {
override type TParent = とんび //ここで指定しても派生クラスで継承できる
override def toString = "とんび"
}

object AbstractTypeTest {
def main(args: Array[String]) = {
var とり = new とり
とり.parent = Option(new とり)
println(とり.parent)
var とんび = new とんび
とんび.parent = Option(new とんび)
println(とんび.parent)
}
}


94 :60,84:2011/09/11(日) 17:18:37.67
60,88→60,84 間違った失礼

95 :デフォルトの名無しさん:2011/09/11(日) 20:14:05.28
静的型チェックはずせばいいだけw

96 :uy:2011/09/11(日) 21:49:39.13
>>94
ゴミだから間違えるんだよな

お前みたいな奴はプログラムで変なミスするよ

むいてない 死んだほうがいい しんだほうが いい

97 :デフォルトの名無しさん:2011/09/11(日) 22:10:44.72
>>96
welcome to http://hibari.2ch.net/test/read.cgi/tech/1312201995/

98 :デフォルトの名無しさん:2011/09/11(日) 23:51:17.55
Scalaだけでは書けないよ、うん、終了(キリッ

99 :デフォルトの名無しさん:2011/09/12(月) 02:34:06.66
http://krautchan.net/files/1315760995001.jpg
↑糞言語の開発者 メガネ、ハゲ、ヒゲなどが特徴

http://lamp.epfl.ch/~odersky/images/Martin.JPG
↑神言語の開発者 なんというナイスガイ!

100 :デフォルトの名無しさん:2011/09/12(月) 07:02:18.99
プログラム板って何か変なのが住み着いてるんだな。

101 :デフォルトの名無しさん:2011/09/12(月) 08:12:06.06
ハゲが二人いる

102 :デフォルトの名無しさん:2011/09/12(月) 09:14:02.69
>>99
美的センスのなさが見てくれにも言語にも表れてるな

103 :デフォルトの名無しさん:2011/09/12(月) 10:21:45.33
scalaがはやると困るやつがいるみたい

104 :デフォルトの名無しさん:2011/09/12(月) 11:01:04.90
メガネ率たかいな

105 :デフォルトの名無しさん:2011/09/12(月) 11:29:07.53
>>100
慣れると避けて歩ける
無視されているのがわかるとなんとかしてレスさせようとどんな変なことでも書くようになるが、
それだと余計わかりやすくなるのでむしろ好都合だったりもする

106 :デフォルトの名無しさん:2011/09/12(月) 17:43:57.00
全然避けられてないじゃないっすか

107 :デフォルトの名無しさん:2011/09/12(月) 18:45:32.64
http://tech.cm55.com/wiki/scala/ruby

こんなサイトがあるからScalaにも粘着が湧くんじゃね?

108 :デフォルトの名無しさん:2011/09/12(月) 18:51:25.10
>>106
避けてるってば
「どんな変なことでも書くようになる」の意味噛み締めれ

109 :デフォルトの名無しさん:2011/09/12(月) 18:53:42.98
>>107
こんなところに書いても世の中は何も変わらんけどな

110 :デフォルトの名無しさん:2011/09/12(月) 18:59:00.94
>>108
自演っぽいのは時々見るよね…

111 :デフォルトの名無しさん:2011/09/12(月) 18:59:12.67
Scala の記述力は動的型言語に遠く及ばない、とか
Scala の structural subtyping や型推論は出来損ない、とか
そういう荒し発言はやめてもらいたいね

112 :デフォルトの名無しさん:2011/09/12(月) 19:35:04.73
慣れると避けて歩ける(ドヤッ

これが荒らしトリガーのレスじゃなくてなんなの(笑)(笑)(笑)
荒らしにアンカでレスしなければセーフとか思ってんのか(笑)(笑)
恥ずかしい奴だ
お前はルビーでも使ってろよ(笑)

113 :デフォルトの名無しさん:2011/09/12(月) 21:10:11.06
はっきり言って旧世代のRubyとか眼中にないんで、しつこく絡むのはやめていただきたい

114 :デフォルトの名無しさん:2011/09/12(月) 22:21:51.59
これが誘い受けというやつか

115 :デフォルトの名無しさん:2011/09/12(月) 22:23:02.98
IDEはほとんど話題に上がっていないが IntelliJ IDEA 使ってる?
結構優れもののように思う
インテリセンスで暗黙型変換のメソッドまで表示してくれる


116 : ◆CgacaMDhSQ :2011/09/12(月) 22:33:07.79
>>115
IntelliJ IDEAが今のところ自分のScalaメイン開発環境です。Scala IDE for Eclipseは
補完がだいぶマシになって、インクリメンタルビルドがちゃんとできるようになったので、
テキトーにプログラム書くときには重宝しています。

ただ、IntelliJ IDEAのScalaプラグインにはまだ及ばないかな、という気が(個人的には)しています。
(Java + Scalaの)inter-language renamingとか、実装するのが面倒だけどいざというときに必要になりそう
な、そういう細かいところも含めてサポートしてくれて便利だなと思います。ただ、IDEA + Scalaプラグインだけ
だとビルドが糞重いので、sbt plugin入れてます。

117 :デフォルトの名無しさん:2011/09/13(火) 00:06:05.03
なんでながいの?

118 :デフォルトの名無しさん:2011/09/13(火) 00:34:24.51
短文しか読めない理解できない馬鹿を排除するため

119 :デフォルトの名無しさん:2011/09/13(火) 00:50:14.82
三文字で頼む

120 :デフォルトの名無しさん:2011/09/13(火) 01:03:27.30
>>119
かえれ

121 :デフォルトの名無しさん:2011/09/13(火) 01:12:34.41
これはひどい

122 :デフォルトの名無しさん:2011/09/13(火) 02:03:07.01

vimがあればなにもいらないもん!

123 :デフォルトの名無しさん:2011/09/13(火) 02:10:30.33
最近vimとHHKBの組み合わせは偉大だということを知った
……とはいえ、Scalaは本来IDEを使うべきじゃないのか

124 :デフォルトの名無しさん:2011/09/13(火) 06:38:01.76
>>116
Eclipseはうちのマシンだとエディタが遅くて
タイピングに付いてこないので候補に入れていませんでした。
(Java + Scalaの)inter-language renaming そんなことできるんですか
自分は コンパイラオプションで Use fsc(fast scalac)を有効にしたら
結構早くなって満足していたのですが sbt plugin で
もっと早くなるのだったら入れようかと思いました。

125 :デフォルトの名無しさん:2011/09/13(火) 14:28:02.17
Scalaでは戻り値は常に明示的に書くべきなの?

126 :デフォルトの名無しさん:2011/09/13(火) 15:06:50.64
>>125
俺は書く
関数のシグネチャは大事だと思ってるから省略しない

127 :デフォルトの名無しさん:2011/09/13(火) 15:10:34.70
俺も書く
Unitのときも省略しない

128 :デフォルトの名無しさん:2011/09/13(火) 15:22:49.83
俺も書くなー、可読性を維持するためには必要な税金だと思ってるがどうなんだろ

129 :デフォルトの名無しさん:2011/09/13(火) 17:09:27.64
型推論なんていらんかったんや!

130 :デフォルトの名無しさん:2011/09/13(火) 17:27:38.05
まあ型推論なんてJava7のダイヤモンドオペレータ程度で十分なんじゃないの、とは思う

131 :デフォルトの名無しさん:2011/09/13(火) 17:50:36.84
プログラミング言語史上最も可愛いマスコットキャラのScalaちゃん
なぜエロ同人が出ない

132 :デフォルトの名無しさん:2011/09/13(火) 17:51:48.94
死ねよキモオタ

133 :デフォルトの名無しさん:2011/09/13(火) 17:55:07.99
俺は書かない派だったけど、最近なんか雰囲気的に書かなきゃ駄目っぽくなってるね
でも一行関数とか書く気しないんだよなあ

134 :デフォルトの名無しさん:2011/09/13(火) 18:42:47.65
>>130
Hindley-Milner型推論じゃないですもんね
すっぱい葡萄ですね

135 :デフォルトの名無しさん:2011/09/13(火) 19:12:22.21
え、Hindley/Milnerじゃないんだ























わからないのにレスしてみる

136 :デフォルトの名無しさん:2011/09/13(火) 21:05:18.02
>>134
あれってたまに凄いエラーメッセージを返してくるとか言われない?
強力な型推論を採用しちゃうと、型宣言のような
型に関する冗長な情報を書かなくなるので
矛盾があった時にどこがエラーか決定できなくなるんだと思うけど

137 :デフォルトの名無しさん:2011/09/13(火) 23:27:22.44
型を書かなくても、IDEが型推論の結果を表示出来れば
可読性は維持出来るんじゃないの?

138 :デフォルトの名無しさん:2011/09/13(火) 23:46:16.75
あれほどのモヒカンっぷりを見せつけておきながら、
匿名じゃない場所で質問が来ると思ってたのかw
面白い人だなぁ

139 :デフォルトの名無しさん:2011/09/14(水) 00:20:41.30
>>137
Scala IDEの完成度がもう少し上がればねー。

140 :デフォルトの名無しさん:2011/09/14(水) 00:28:03.84
とか言ってたらbeta 10が出た。
http://www.scala-ide.org/2011/09/scala-ide-beta-10-available/

SBT統合とかセミコロン表示とか、楽しげな機能が増えたな。

141 :デフォルトの名無しさん:2011/09/14(水) 02:40:20.91
>>140

そのセミコロン表示機能の紹介
http://scala-ide-portfolio.assembla.com/wiki/show/scala-ide/Show_Inferred_Semicolons

で例として出されているコードだけど

object Test extends App {
 val result = 3;
  +12;
 println(result)
}

みたいに、意図せず 式が途中で区切られてしまうScalaの仕様はどうにかならないのだろうか?

たとえば、「この先セミコロンを忘れるべからず」 みたいな命令があって、
それ以降は、セミコロンが必須になるようにしてほしい。


Martin先生に直訴したら、機能追加してくれるだろうか??


142 : ◆CgacaMDhSQ :2011/09/14(水) 05:46:00.09
>>138
実のところ、それほど多くの質問が来ることは期待してませんでした
ただ、もう少し来るかなーと思っていたのが正直なところです。その辺の
感覚が世間ズレしてるのは認めます

>>142
> みたいに、意図せず 式が途中で区切られてしまうScalaの仕様はどうにかならないのだろうか?

セミコロン省略可能であることのトレードオフというかScala慣れたらあまりぶつからない問題な気がします。私は、

(1) 基本的に行頭に2項演算子は書かない
(2) 読みやすさの問題から、行頭に演算子を置きたいときは式全体を括弧で囲む
例:
val statement: Parser[Statement] = (
while_stmt
| for_stmt
)

という感じで対処しています。(1)は既に意識してない感じです

> たとえば、「この先セミコロンを忘れるべからず」 みたいな命令があって、
> それ以降は、セミコロンが必須になるようにしてほしい。

そういうad hocな機能追加は言語屋さんは嫌う傾向にありますし、文法がさらに無駄に複雑になるという
デメリットもあるので、たぶん採用されないと思います。やるなら、自分でそういうuse("strict");みたいなの
を宣言できるコンパイラプラグイン書くか、CheckStyle的なツール作るしか無いのではないかと。

143 : ◆CgacaMDhSQ :2011/09/14(水) 05:47:12.55
申し訳ない。>>142>>141の間違いです。

144 :デフォルトの名無しさん:2011/09/14(水) 12:55:31.55
セミコロンが省略可能なのもナニだけど
ターミネータじゃなくてセパレータだってのもアレ

145 :デフォルトの名無しさん:2011/09/14(水) 17:51:54.51
セミコロンなんていらないだろ
ってこの話題、前もしたことあるような


146 :デフォルトの名無しさん:2011/09/14(水) 21:13:57.50
for式の型はどう規定されているのかな。
for(...) yield eならIterable[eの型]としか保証されていない?

147 :デフォルトの名無しさん:2011/09/14(水) 23:54:18.60
scalaのforはシンタックスシュガーなのでmapやらflatMapが返す型を返す
http://www.ne.jp/asahi/hishidama/home/tech/scala/collection/for.html

scalaのコレクションライブラリはだいたいが自分と同じ型を返すので

for {
a <- hoge
b <- fuga
} yield ...

みたいなのだと最初のジェネレータのhogeと同じ型を返す場合が多い

148 :デフォルトの名無しさん:2011/09/15(木) 23:46:56.02
>>142

セミコロンの対処方法だが、

> (1) 基本的に行頭に2項演算子は書かない

↑こういう記述スタイルが不可になるのは、窮屈だと思う。

たまに、行頭に演算子置きたい時ってあるよね!!


> (2) 読みやすさの問題から、行頭に演算子を置きたいときは式全体を括弧で囲む

なるほど。。このテクニックでなんとかやってみる。Thanks!


ちょっと窮屈だけど、、まあ、慣れるしかないかあ。。


149 :デフォルトの名無しさん:2011/09/15(木) 23:49:37.24
バッドノウハウ

150 :デフォルトの名無しさん:2011/09/16(金) 07:23:52.85
Rubyを笑えない

151 :デフォルトの名無しさん:2011/09/16(金) 11:36:48.08
セミコロン推論は落とし穴でも何でもないな


152 :デフォルトの名無しさん:2011/09/16(金) 12:27:41.24
>>151
> セミコロン推論は落とし穴でも何でもないな

落とし穴かどうかは、慣れで解決する。
それよりか、記述スタイルに制限が付くのが、イヤなの。

文法としては、ステートメントの最後には、セミコロン必須の方が、
文法として美しかっただろう。



今は、改行がステートメントの区切りであったりなかったりと、文法的に美しくない。
慣れで解決するから別に良いのだけど、言語として美しくない。


153 :デフォルトの名無しさん:2011/09/16(金) 12:29:50.60
慣れないと解決しない時点で負けてる

154 :デフォルトの名無しさん:2011/09/16(金) 12:38:44.74
俺は;が必須でも必要なコストとして納得できる。むしろソースコードのフォーマットなんぞの為にケースバイケースを求められるほうが苦痛。

155 : ◆CgacaMDhSQ :2011/09/17(土) 01:18:09.69
>>152
それほど記述スタイルに制限付くものでしょうか?確かに、行頭に二項演算子とかおきたいことは
たまにありますが、それは>>142の方法で十分対処できる話ですし、頻度もそれほど多いとは思えません。
というか、セミコロン推論は、元々、低頻度で出現するパターンが書きにくくなる代わりに、高頻度で
出現するパターンが書きやすくなる、というものですよね。

また、ステートメントというか式ですね。というのはともかく、セミコロン必須の方が確かに文法はシンプル(美しいか
どうかはおいといて)になりますが、文法の美しさ(シンプルさ?)をそれほど気にするなら、極論を言えば、S式
使ってればいいのでは?とかいう話になってしまうような…。

>>154
両者が同頻度くらいで出てくるなら確かに嫌な話ですが、実際のところ、明らかに頻度の偏りがある以上、私はセミコロン推論が
あった方がトータルのコストは安くなると思います。実際、最近の言語の多くが;相当の省略をどんどん取り入れてるのはそれを
示しているかと。

156 :デフォルトの名無しさん:2011/09/17(土) 01:54:58.47
君がScalaを愛してやまないのは分かるが
無理な擁護は逆効果だぞ

157 : ◆CgacaMDhSQ :2011/09/17(土) 02:06:21.37
>>156
Scalaを愛しているかというどうかは別の話です。別にRubyとかの他のセミコロン省略できる言語でも構わないです。で、
>>152>>154の批判に、「嫌い」とか「美しくない」以外の指標での実用的問題が発生するのかなあという話です。
私は経験上、そういう問題が発生することはほとんどありませんでしたし、Ruby等でその事がそれほど問題視
されたことも無かったと記憶しています。結局、頻度の問題だというのが私の認識です。

実際に〜というコードパターンを書きたい事が頻繁にあって、それでScalaのセミコロン推論が邪魔をして困る、
という問題提起なら意義があると思います。

158 :デフォルトの名無しさん:2011/09/17(土) 02:13:32.54
Rubyは文法がどれだけ難解になっても
ユーザー側から見て多くのケースで便利になるなら問題ないという立場だったが、
>>152が言うように文法上美しくないという観点もありえる
Scala的には何を良しとするべきなのだろうね

159 :デフォルトの名無しさん:2011/09/17(土) 02:14:45.02
Rubyはどうだか知らんがPerlやJavaScriptではセミコロンを省略するのは悪い習慣だとされているな

160 :デフォルトの名無しさん:2011/09/17(土) 02:37:40.56
たかだか1文字省略できるだけで大して書きやすくなるわけじゃなし
ていうか書くときに気にしなければならないことが増えてむしろ面倒になるし
文の区切りが分かりにくくなって可読性は落ちるし
場合によっては分かりにくいバグの元にもなるし

まあなんもいいことないよね

161 :デフォルトの名無しさん:2011/09/17(土) 03:13:05.95
まあ、少なくともRubyに比べりゃ分かり易いって
Rubyなんて

p 1 + (1
    + 1)

て書いたら2が出力される言語だぜ?
こんな言語でも実質問題が起きてない(ということになってる)んだからScalaも無問題

162 :デフォルトの名無しさん:2011/09/17(土) 05:02:50.41
>>161
算術記号の名前を持つメソッドに限って、 1.+( 1 ) は1 + 1 と空白区切りで書いてよいという
シンタックスシュガーが影響を及ぼしているので、例としてはあまり適切ではない
p( 1.+( (1; +1) ) );
+メソッドの引数 (1; +1) の戻り値は最後に評価された+1なので、結局は1+1になって表示は2

163 :デフォルトの名無しさん:2011/09/17(土) 05:08:19.05
(1; +1) のセミコロンを省略できることが原因じゃんかよ

164 :デフォルトの名無しさん:2011/09/17(土) 06:33:20.29
基本的には改行で、改行の代わりにセミコロンを書いてもよいという動作
セミコロンを省略してもよい、というのとはちょっと違う

165 :デフォルトの名無しさん:2011/09/17(土) 06:36:37.60
なにその言葉遊び

166 :デフォルトの名無しさん:2011/09/17(土) 07:07:07.30
ステートメント終了の改行をセミコロンで表現することができるというだけで、セミコロンには意味はないってことだろ
まあ他の言語は文化ごと違うので参考にはならんな
>>161だって正しく「(2つ目の1の直後の)改行は文の終わり」と判断しているだけに過ぎん

167 :デフォルトの名無しさん:2011/09/17(土) 07:15:19.27
人間にどう見えるか(慣習含む)は関係なく、正しくパース出来れば良いって話なら
そもそもScalaのセミコロン推論もまったく問題ないがな

168 :デフォルトの名無しさん:2011/09/17(土) 09:24:07.66
連言・選言や並行性の制御を表現するために使うんならいいと思うし、
むしろそれ相当のものは必須だと思うぜ、;。
「無くしても意味通る」とかいうレベルで考えるべき要素じゃ無いと思う。
記号は慎重に、大切に使うべき。

169 :デフォルトの名無しさん:2011/09/17(土) 22:23:05.44
eclipseでのJavaのフォーマッタのように、ツールを前提にしている言語ならセミコロン必須にしたほうが享受できるメリットが大きい。
改行、空白は人間の美的感覚というテキトーなものに左右されやすいので言語的な機能を持たせることは間違い。

Python全否定。

170 :デフォルトの名無しさん:2011/09/17(土) 22:23:26.25
eclipseでのJavaのフォーマッタのように、ツールを前提にしている言語ならセミコロン必須にしたほうが享受できるメリットが大きい。
改行、空白は人間の美的感覚というテキトーなものに左右されやすいので言語的な機能を持たせることは間違い。

Python全否定。

171 :デフォルトの名無しさん:2011/09/17(土) 22:36:29.30
空白を無視といえばFORTRAN66。
マリナー1号のバグは有名。

172 :デフォルトの名無しさん:2011/09/19(月) 14:19:46.73
Scalaスケーラブルプログラミング第2版、表紙をサムネイル画像で見ると
第1版と区別しづらいな…と思ったのだけど、コップが2つになってるんですね。


173 :デフォルトの名無しさん:2011/09/19(月) 18:29:57.23
誰か画像処理に詳しい奴はいないか?
openCV使ってステレオビジョンで視差画像を出したいんだが
誰か心優しい方教えてけろ


174 :デフォルトの名無しさん:2011/09/20(火) 02:30:57.47
スレチ

175 :デフォルトの名無しさん:2011/09/20(火) 02:33:46.48
List(8,6,3,2)の標準分散求めるコードは、mapを使って
どのように書くのでしょうか?

176 :デフォルトの名無しさん:2011/09/20(火) 02:37:15.46
scalaプログラマが愛用してる汎用スクリプト言語は?

177 :デフォルトの名無しさん:2011/09/20(火) 05:35:53.96
val avg = list.sum / list.size
(list map { i => (avg - i) * (avg - i) }).sum / list.size


178 :デフォルトの名無しさん:2011/09/20(火) 05:40:12.90
>>176

基本的には bash のシェルスクリプト。辛くなってくると
ファイルの頭にこれ書いて、何でもかんでも Scala で書いてるわ。

#!/bin/sh
exec scala "$0" "$@"
!#


179 :デフォルトの名無しさん:2011/09/20(火) 09:05:57.08
$ cat a.sh
#!/bin/sh
exec scala "$0" "$@"
!#
print("hello")

$ time ./a.sh
hello
real 0m13.741s
user 0m0.815s
sys 0m2.254s

小さい方にはスケーラブルじゃないな

180 :デフォルトの名無しさん:2011/09/20(火) 11:13:17.24
こういうのってスクリプトに使えたっけ?
コンパイルしてるから関係ない?

http://www.google.co.jp/search?q=scala+groovyserv
http://www.infoq.com/jp/articles/groovyserv


181 :デフォルトの名無しさん:2011/09/20(火) 12:47:16.49
Scalaってなんか実績あんの?
面白そうかとは思うけどただの言語オタの趣味ならやめておこうと思ってる

182 :デフォルトの名無しさん:2011/09/20(火) 12:54:56.63
twitterのバックエンドとか。つか、実績で左右されるって、脆い知的好奇心だな。

183 :デフォルトの名無しさん:2011/09/20(火) 13:06:50.12
scalaでliftとかplayを書いた場合、
javaのwicketやrubyのrailsと
並べて評価した場合どうですか?
言語の違いでフレームワークも結構変わりますかね?

184 :デフォルトの名無しさん:2011/09/20(火) 13:49:42.30
どこに知的好奇心の要素があるんだ

185 :デフォルトの名無しさん:2011/09/20(火) 13:58:12.51
評価を他人に委ねてる時点でだめだろ
>>183が実際使ってみてなにか分かったら報告してくれ
それまで連絡はしなくてかまわん、以上だ

186 :デフォルトの名無しさん:2011/09/20(火) 13:58:38.90
暗黙の型変換を使って、いかにトリッキーなことができるか

187 :デフォルトの名無しさん:2011/09/20(火) 14:41:47.30
同じならマイナーで普及しそうにない言語なんて
時間の無駄だからな

188 :デフォルトの名無しさん:2011/09/20(火) 18:56:12.26
そこで普及するまで待つという手がある

189 : ◆CgacaMDhSQ :2011/09/20(火) 20:21:20.44
>>178
スクリプトで、サードパーティのライブラリ使いたい場合とか、scalasが何気に便利です。
http://blog.twiwt.org/e/f835d9
スクリプトの最初の方にdependency書くだけで、勝手にライブラリのjar落として来てくれ&&そのまま使えます。

>>184
知的好奇心、という面でもScalaは結構面白い試みを色々していると思います。全く新しいパラダイムを提示する、という
わけではないですが、Scala 2.8のコレクションアーキテクチャとかは精巧に作られていて凄いですし、プラグインとし
て型システムを拡張できるおかげで、型システムに関する実験的&&そこそこ実用的な試みがしやすいと思います。

あとは、Scalaの型システム自体も、λ計算をベースに発展してきた静的型付け関数型言語とは異なったアプローチ
を取っているのですが、それが、既存の静的型付け関数型言語のモジュールシステムとかとうまく対応付く、とかも
面白いです。

何が面白いかは主観になりますが、ともあれ、単に既存のアプローチを集めただけの言語ではないことは確かです。

190 :デフォルトの名無しさん:2011/09/20(火) 21:14:12.44
>>189
ああ、書いた直後に誤解されるかな、と思った懸念がそのまま…
>>184ではScalaに対して知的好奇心をそそるものが無い、と言いたかったわけではなく、
>>181が求めてるのは知的好奇心じゃなく実用性なんじゃね、その問いに>>182の返しは変じゃね、
ということです。

191 :182:2011/09/20(火) 22:30:25.19
まぁ「面白そうかとは思うけど」って部分で揚げ足取っただけなんで、そう解説されるとそのなんだ困る。

192 : ◆CgacaMDhSQ :2011/09/20(火) 23:39:24.40
>>190,191
どうもすいませんorz

ともあれ、実績の話なら、Twitterだけではなく、既にVMWare, LinkedIn, Amazon.com, Foursquare, Novell, Siemens,
Remember the Milkとかそれなりに名前の知られてるのが色々ありますね。求人見ても、Scalaなどの関数型言語の
経験のあるエンジニアを求めてるところも増えて来てる感じです。名前出せないけどとある金融系のところで
使われているとか(Scala Days 2011での情報)。

あとは、前どっかで見た話でソース失念なのですが、githubが一部をScalaで置き換えてるという話もあります。

国内だと、有名なところはあまり無いですけど、有限会社ITプランニングさんとか、GMO株式会社さんとかパテントビューロさんとか、
その他中小/フリーランスで使われているところが少しずつ増えて来てるみたいですね。

全く問題が無いわけじゃないですけど、使える周辺ツールは一通り揃っていますし(sbt, ScalaTest/Specs)、IDEに関してもScala版が
だいぶ進歩した他、IntelliJ IDEAは「普通に使える」レベルになってます。あとは、Scala自体の教育コストとか、チーム開発でのノウハウ
とか、それ以外の政治的な話が問題になってくるのかなあと思ってます。

193 :デフォルトの名無しさん:2011/09/22(木) 00:12:33.24
>>189

確かに便利だけど、java しか入っていない環境に持って行って即座に展開できるようなものがあったらなあ、とも思います。

194 :デフォルトの名無しさん:2011/09/22(木) 10:07:34.99
>>193
TypeSafeの作ってくれたインストーラ使え
ttp://typesafe.com/stack/download

195 :デフォルトの名無しさん:2011/09/23(金) 16:01:47.86
ScalaDays 2011 Resources (Paper | Slides | Video | Home Page)
https://wiki.scala-lang.org/display/SW/ScalaDays+2011+Resources


196 :デフォルトの名無しさん:2011/09/24(土) 08:53:29.72
scala って 関数型系では異質というのか違和感がある言語だけど
IDEの話を読んでて思ったのは、やっぱりjavaの流れでやってる人が
多いんだな。と思った。

なぜ他の言語コミュと上手くいかんのかしらん。でも何かあれば
FUD FUDだからな。S式言語なんて使ってもいない奴がDISるけど
相手にされないのが普通なのにな。いちいち FUDといってるような
無駄はしないわな。ここでも他言語を一人前にDISる連中はおるよう
だけど、わがままだよな。(>>113など)海外のscala使いにそんな狭量を感じる
事は少ないような印象は持ってるんだが。

197 :デフォルトの名無しさん:2011/09/24(土) 08:56:56.49
>>192
|Scala自体の教育コスト
全てを知らなくても使えるだろうけど、自由度を得るために、複雑な仕様を
みてるとC++と同じに見えることはある。複雑すぎて使いこなせない言語
なんじゃなかろうか?better javaというだけでいいならそれでいいんだろう
けどね。

198 :デフォルトの名無しさん:2011/09/24(土) 09:15:24.83
>>196
Scala関数型言語じゃない
そのように見える機能を集めたOOだろ

199 :デフォルトの名無しさん:2011/09/24(土) 09:20:57.86
>>107
そのサイトも他をDISってscalaを持ち上げるパターンだよね。
別にその信念で使ってることは問題ではないけど、発想が減点法というか
他の言語を使っててDISる人も減点法的に書いて使えないと喚く連中は
見かけるから、阿呆な連中は他にもおるとは思うがね。
優れてるならその点だけ全面的にだして話をすればいいだけなんだけどな。
ここでもそうだけど、rubyへの敵対感はかなり強すぎるよな。なんか幼稚
なんだよね。
松本氏の態度に気に入らない連中も多いのも理解はできるけどさ。

200 :デフォルトの名無しさん:2011/09/24(土) 09:27:54.13
>>198
そうゆう見方もあるね。

>>199
続き、ブログとかでかかれて第三者が読むときって、他をDISって持ち上げる
ような阿呆としか言えない書き方より、どう使って行ったらいいか?という
ことを書いてくれて特徴を生かせるアイデアを出していけばいいんだよね。
言語が複雑になれば、関数や機能が似通ったもんだとかよく使い方がわからない
ものは増えるけど、どんなときに有効か分かるだけでずいぶん読者は参考になるよね。
だけど、DISるだけというのは、それ以上の情報が含まれないから、読む価値
としてはあまりなくなるよね。

201 :デフォルトの名無しさん:2011/09/24(土) 09:32:17.01
Scalaってインテリが使って満足する言語でしょ
DISられて当然じゃないか?

202 : ◆CgacaMDhSQ :2011/09/24(土) 09:32:44.25
>>196
>なぜ他の言語コミュと上手くいかんのかしらん。
一般論として、Scala特異の事情があるかというと、どうなんでしょうね。他の言語コミュニティとの
摩擦というのは、それなりに名前が知られてきた言語だと大体とこでもある話のような。

>海外のscala使いにそんな狭量を感じる
>事は少ないような印象は持ってるんだが。

コアなScalaistがJavaをこきおろしまくってるのは結構よく見ます。ただ、大体そういう人たちは
生産性の問題から真剣にJavaを嫌がってて、Javaをこき下ろしたい、という印象はあまり受けないです。

ちなみに、海外のScalaistがML/OCaml/HaskellとかCommon Lisp/Scheme/ClojureをDISってるのは
ほとんど見ないです。というか、JVM系言語で言うと、Clojureとかの人たちがむしろScala意識しまくりで、
コード行数の比較の話になると、かなりの確率でScalaが出てきます。

あと、Scalaコミュニティの人(海外勢含む)は不当なDISりには結構敏感で、CeylonやKotlinの
中の人が根拠レスの「Scala is too complex」マーケティング展開したときは、中の人のブログ
がかなり炎上してました(根拠レス、というのは、本当に"too complex"だけしか言わなくて、
どこが"too complex"なのか、というまともなDISりが皆無でした)。Ceylonについては、Gavin King
が、捨て台詞吐いてブログ閉鎖するくらいの勢いで。あと、Odersky先生ご本人が、不当なScala DISが
あったらブログにコメントとかしてるのを時折みます。

203 :デフォルトの名無しさん:2011/09/24(土) 10:38:53.12
2chの煽りレスを真に受けて日本のScalaコミュニティを語る馬鹿がいると聞いてやってきました

204 :デフォルトの名無しさん:2011/09/24(土) 10:54:00.25
Scala is too complex

205 :デフォルトの名無しさん:2011/09/24(土) 12:10:11.04
> 生産性の問題から真剣にJavaを嫌がってて、

こういうことをサラッと書いてしまうのも、
また理由があればdisって良いという思想もヤベェw

206 :デフォルトの名無しさん:2011/09/24(土) 12:20:07.85
理由があればディスってもいいんじゃねーの
JavaもC++もいたるところでディスられまくってるけどね
C++なんかよく耐えてるよな
実際ディスってるやつでC++使ったことないやつも多いだろ

207 :デフォルトの名無しさん:2011/09/24(土) 12:21:22.36
>>205
いいんじゃないか?言語作者自信が、ブログ炎上させて閉鎖に追い込んだりと一部では、思想体系がネオナチに近いって言われているからな。

208 :デフォルトの名無しさん:2011/09/24(土) 12:24:08.18
酷い日本語を見た

209 :デフォルトの名無しさん:2011/09/24(土) 12:28:28.75
むしろ日本の問題点はこういうところだろうな
なぜか言語じゃなくて個人攻撃になる
コミュニティがどうとか口調が怖いとか
そういう低レベルなところでしか言語を語ることができないのが問題
英語読めないやつが多いんだろうな

210 :デフォルトの名無しさん:2011/09/24(土) 12:34:29.23
反論があればかかってこいやぐらいの気概があればdisもいいんじゃねーかと思う

反論でファビョったり、一方的な言い逃げとかだとあららって感じ

211 :デフォルトの名無しさん:2011/09/24(土) 14:30:13.89
>>206
DISるのって根拠が不十分なことも多かったり、実際に使ってない
状況で、オナニーしてるだけのもあってね。それは水嶋さんが
書いてるような傾向もあるんだけど、他のところならスルーする
ところがこっちではFUDだとか刈込にいったりするからな。
おかしいんだよな。

212 :デフォルトの名無しさん:2011/09/24(土) 14:33:56.67
disるのって大体が極論なことが多くってね。参考にならないことがある。
たいてい会話が成り立たないから、炎上してしまうんだろうな。
言語界のネオナチか。。。なんでそこまで陶酔するんだろうか?
Scalaに麻薬的要素があるの? 知らんねんけど

213 :デフォルトの名無しさん:2011/09/24(土) 14:38:56.54
宗教論争は麻薬
言語でも何でも

214 :デフォルトの名無しさん:2011/09/24(土) 14:46:26.39
スカスケ2版amazonから発送通知来た!

215 :デフォルトの名無しさん:2011/09/24(土) 15:00:38.71
>>210
disじゃなくてただの感想言っただけなのに突撃してくるイメージ。

216 :デフォルトの名無しさん:2011/09/24(土) 15:09:27.76
そしてその突撃は正当なものと信じて疑わず、
「議論できないのは日本人の悪いところ」と言わんばかりに揚げ足を取り、
挙句には「◯◯を示せたので満足です」「実は◯◯は重要だとは思っていません」などと捨て台詞を残して去って行く。

217 :デフォルトの名無しさん:2011/09/24(土) 15:12:32.67
うむ。なるほどモヒカンだな

218 :デフォルトの名無しさん:2011/09/24(土) 18:59:05.57
たぶんScalaユーザーを減らしたいんだろう

219 :デフォルトの名無しさん:2011/09/24(土) 19:44:07.53
技樹的に間違ったことを書いておいて、それを指摘されたら人格攻撃にすり替えるんだから
日本のネットのプログラマーは救いようがねえな
しかも本人には言えず2chでネチネチと叩くんだから酷すぎるわな

220 :デフォルトの名無しさん:2011/09/24(土) 20:03:32.79
何でも一般化しようとするな

221 :デフォルトの名無しさん:2011/09/24(土) 20:59:20.13
http://mobile.twitter.com/tatsuya6502/status/117520413545873409
http://mobile.twitter.com/tatsuya6502/status/117522292564692992
>38
これって、主にJVMのGC実装の問題で、
追加でscalaの不変データ構造の実装の問題なのかな。

222 :デフォルトの名無しさん:2011/09/25(日) 00:02:46.87
http://www.infoq.com/jp/news/2010/09/bigmemory
こういうやつのscala版が必要なのか、akkaあたりで良いのか
http://akka.io/docs/akka/1.1/general/jmm.html

223 :デフォルトの名無しさん:2011/09/25(日) 00:39:29.14
clojureで、scalaと比較が多くなるのは
JVM言語でとりあえず両方触れるぐらいの人が多いのと、
あとは、たまたま当時のscala実装(>221)で商用アプリの実装が上手いかず
clojureを使ったら上手くいったという、経路の書き込みが多いから。

移行時に行数が出てくるのは当たり前だけど、
javaからrubyに移動した時と同じ話で
静的型チェックを補うテストコードまで考えていないし、
scalaでチェック済みではあるので、rubyでテストコードが膨らんでscalaに移行したら総行数減ったというのとは
ちょっと違う。

そして、cl,schemeと行数比較する機会や意味はあまりない。

224 :デフォルトの名無しさん:2011/09/25(日) 02:04:05.68
2.8から不変データ構造の実装変えてたよね?
twitterの話は、2.8以降の話なんだろうか?

225 : ◆CgacaMDhSQ :2011/09/25(日) 04:29:58.20
>>221
http://mobile.twitter.com/tatsuya6502/status/117522292564692992
の書き込みは、一部勘違いがあるのではないか、というのが私見です。原理的に、現在のSTW型のGCは、
色々工夫されているとはいえ、メモリ量に応じて最大停止時間が長くなる傾向があるので、
特にメモリ搭載量がどんどん増えてるサーバでは、そっちの方が問題なんじゃないかと。Erlang VMのGCは
詳しくないですが、Erlangの複数のプロセスでGCが走ったらやっぱり問題が起きるような気が…。Erlang VM
のGCは詳しく無いので、外してるかもしれません。


>>223
clojureも不変データ構造が基本なので、scalaでダメで、clojureで上手く行ったとしたら、それは当時のScalaの不変データ構造の実装が
あまりこなれて無かった、というのがあるでしょうね。

>>224
Continuation Workshop参加してましたので、Scala < 2.8なのかそれ以降なのかわからないですけど、今のJVM(1.6.0 u24以降くらい?)だと
エスケープ解析が効くので、関数型プログラミングでよくあるパターンの、大量の短寿命オブジェクトによる実行コストの増大はかなり減らせます。
実験的に、implicit conversionで短寿命オブジェクト生成しまくるベンチマーク取ってみましたが、うまいことスタックにアロケートされてるっぽく、GCが
ほぼ起きてなかったです。あと、immutable objectがGCと相性悪いか、というと、使い方の問題も大きいと思います。2.8で導入されたVector
型はかなり効率が良くて、コンパイラ内部にこれを導入しただけでパフォーマンスが結構改善したという話があったり。

Java 6を採用できる現場がどのくらいあるのか、って話は別にあると思いますが。

226 :デフォルトの名無しさん:2011/09/25(日) 07:56:15.29
ClojureとScalaが好きって人は海外のClojure使いのサイトを見ればよくいる
印象があるけど、ここって前スレの後半にもあったけどClojureを敵視してる
人たちがいるよ。特に敵対する必要もないのに無駄に敵をつくろうとしてる。

227 :デフォルトの名無しさん:2011/09/25(日) 09:50:08.97
もう、めんどくさいからgithubに多くコミットしてる奴の発言が一番正しいことにしようぜ。

228 : ◆CgacaMDhSQ :2011/09/25(日) 12:04:46.49
>>226
私が見ている範囲がずれてるのかもしれませんが、設計思想の根幹が違うこともあってか、
(Clojureが好き∧Scalaが好き)という方はあまり見かけないです。Clojure作者のRich Hickeyご本人
からして、Scalaには批判的な立場で、実際にpublicな場で"Scala isn't really a functional language"
等等のという批判をしています。

ちなみに、Clojureを敵視しているScalaな人は、国内でも海外でもほとんど居ないです。Scalaな人が、
Clojure --> Scala という批判への応答として、Clojureコミュの人に何か言うことはあっても、積極的に
Clojureに勝負を挑むモチベーションがそもそも無いだけだと思いますが。

ここでClojureを敵視してる人を何名か見かけるのは事実ですけど、それが原因でClojureコミュニティとの軋轢を生む
というのは杞憂じゃないかと。

正直なところ、Clojure言語そのものを羨ましいとは思わないのですが、I/Oも含めて(準)標準ライブラリが揃っているのは
良いなあと思います(ScalaはI/Oが…)。

229 :デフォルトの名無しさん:2011/09/25(日) 12:16:21.04
>>228
日本人で「ぼくのかんがえたさいきょうのIOライブラリ」を作って世に問うというのはどうか。

230 :デフォルトの名無しさん:2011/09/25(日) 12:27:04.64
>>229
それはとても楽しそうな案だと思う。

231 :デフォルトの名無しさん:2011/09/25(日) 14:11:23.73
Scala isn't really a functional language は的を得た感想だと思うけど。
個人的には。



232 :デフォルトの名無しさん:2011/09/25(日) 14:33:05.43
OCaml isn't really a functional language

233 :デフォルトの名無しさん:2011/09/25(日) 15:19:13.56
>>231
素直な感想を書くとそうかもしれない。でも、受け取る側は批判ととる。
これがSCALAクオリティー

234 : ◆CgacaMDhSQ :2011/09/25(日) 16:14:07.36
>>231
その言葉が述べられたコンテキストをはずしてたのがまずかったですね。コンテキストとしては、
Scalaはpurityをプログラマに強制しないので、関数型言語としては不適格というもので、
関数型プログラミング=良いもの、という前提に立ってる人の言葉としては、十分な「批判」だと思います。

ちなみに、私自身はRich Hickeyの批判に妥当性が無いとも言って無い、というか彼の立場からすればある程度妥当だろうとすら思っている
ということは付け加えておきます。念のため。

235 :デフォルトの名無しさん:2011/09/25(日) 16:19:36.07
Perl忍者は偉大
Perlの知名度を上げPerl業界に大きく貢献した

◆CgacaMDhSQでは話にならない
帰れ
Perl忍者様に土下座しろ詫びろ

236 :デフォルトの名無しさん:2011/09/25(日) 16:39:30.27
巣に帰れよクソ忍者

237 :デフォルトの名無しさん:2011/09/25(日) 17:25:24.55
P忍 って Scalaモヒカン としてここで現れる予定だろ?

238 :デフォルトの名無しさん:2011/09/25(日) 17:25:27.54
Scalaサムライと聞いて。

239 :デフォルトの名無しさん:2011/09/25(日) 17:40:49.63
変なID粘着してからまともな議論
何もないけどこのままでいいのかな

240 :デフォルトの名無しさん:2011/09/25(日) 19:04:16.16
では、俺らの考えるさいきょうのI/Oライブラリの要件出しでもしようか。

241 :デフォルトの名無しさん:2011/09/25(日) 23:09:23.59
そもそも俺はScalaのIOのどこがヘボいのかすら把握してないのでそこから頼む。

242 :デフォルトの名無しさん:2011/09/26(月) 00:23:11.28
へぇー

We will have a PrePrint of Greg's book out soon, with final publication set for early next year.
http://www.scala-lang.org/node/10448#comment-47711
http://www.biosimilarity.com/publications.html

歴史秘話ヒストリア
http://www.amazon.com/Pro-Scala-Monadic-Design-Patterns/dp/143022844X (発売中止)
Monadic Design Patterns for the Web has moved to Artima
http://comments.gmane.org/gmane.comp.lang.scala/19713

243 :デフォルトの名無しさん:2011/09/26(月) 00:52:21.27
関数型IOだと、こういう話になるのではないか。
Scalaz Tutorial: Enumeration-Based I/O with Iteratees
http://apocalisp.wordpress.com/2010/10/17/scalaz-tutorial-enumeration-based-io-with-iteratees/

最新のJAVA APIでScala/JVMの関数型IOが高速化することが
できたら実装する人いるんだろうか。

発信源のHaskellさんの記事もろもろ
http://www.google.co.jp/search?q=Enumerator+Iteratee

244 :デフォルトの名無しさん:2011/09/26(月) 01:00:29.74
そういえば、この人たちもscalazの本かもしれないけど、Functional Programming in Scalaという本を執筆中。
http://www.scala-lang.org/node/10448 (上のリンクと同じ)

245 : ◆CgacaMDhSQ :2011/09/26(月) 02:02:17.65
>>244
スレッドの最初から出てくる、Tony MorrisはScalaz始めた人ですね。ただ、スレッドを流し読みした感じ、
Scalazの本にはならないんじゃないですかね?本の中で紹介とかはしそうですが。

246 :デフォルトの名無しさん:2011/09/27(火) 00:26:25.83
ttp://hibari.2ch.net/test/read.cgi/tech/1316016777/438

247 :デフォルトの名無しさん:2011/09/27(火) 04:54:11.67
俺もそろそろScalaz習得して優越感ポイント稼ごうかな

248 :デフォルトの名無しさん:2011/09/27(火) 11:58:56.46
じゃあ俺は圏論はじめまつ

249 :デフォルトの名無しさん:2011/09/28(水) 19:50:27.83
コップ2のp702、
「Scala2.9.1はScala2.9.0.1と完全にバイナリ非互換であることを目標にしています。」
ってどういう意味?いや意味というか意図というか。前後の文章とのつながりがわからん。
あと、バイナリ非互換って目標にするようなものなの?


250 :デフォルトの名無しさん:2011/09/28(水) 20:01:24.54
PEPLとREPL(p703)って別物?誤植なのかな?

251 :デフォルトの名無しさん:2011/09/29(木) 04:37:46.16
つーか2.9.1の話まで載ってんのか
ギリギリまで書いてたんだな

252 :デフォルトの名無しさん:2011/09/29(木) 12:36:51.07
ミズシマさんパネッス

253 :デフォルトの名無しさん:2011/09/29(木) 12:44:57.28
だが、正直キモい。

254 :デフォルトの名無しさん:2011/09/29(木) 13:01:46.68
キモカッコイイ

255 : ◆CgacaMDhSQ :2011/09/29(木) 23:28:25.23
>>249
申し訳ありません。それは誤植です。「バイナリ互換であることを目標」が正しいです。そう読めば意味
が通るようになっています。Twitterで既に何名かの方に指摘を受けているので、正誤表に載せていただくようにします。

>>250
一瞬何のことだかわからなかったのですが、p.703のリスト99.1ですか。これも誤植ですね。
同じく、正誤表に載せていただくことにします。ご指摘ありがとうございます。

>>251
それほどギリギリ、というわけではないのですが、大体書籍が出版される頃には2.9.1が
出てるだろう、という目測が立つくらいの時期ではありますね。ちなみに、誤解されると
申し訳ないので言っておくと、2.9.1 finalそのものの改善点(REPL高速化など)については
載っていません。記事自体もページ数の制約もあり、あくまで2.9新機能の概要なので、
おまけ程度に思っていただければ。

>>253
明らかに誰かわかる形でコテハンやってる時点で既にキモい奴だなあと自分で思います。

256 :デフォルトの名無しさん:2011/09/30(金) 00:49:34.44
このスレ初めてなのですが、◆CgacaMDhSQさんは、Scalaの本の著者なんですか?

257 :デフォルトの名無しさん:2011/09/30(金) 01:57:36.50
>>256
mizushima kagerou
でググれ

258 :デフォルトの名無しさん:2011/09/30(金) 09:25:22.88
Scalaエヴァがんばってください
うごいてよ!今動かなきゃ(ry

259 :デフォルトの名無しさん:2011/09/30(金) 12:04:00.70
Scales Xml 0.2
Performance, Flexibility and Correctness Improvement
http://implicit.ly/scales-xml-02

ライブラリー実装:
ミュータブルのが速いし省メモリだよ派
遅延評価寸止め革命中の今がのし上がるチャンスだよ派

260 :デフォルトの名無しさん:2011/10/01(土) 04:39:38.26
とうとう みずしまはんも カリスマ性を帯びてきたか。

261 : ◆CgacaMDhSQ :2011/10/01(土) 12:51:24.88
>>259
そっちも気になってたんですけど、@djspiewak の
Anti-XML https://github.com/djspiewak/anti-xml
も標準のXMLライブラリよりフットプリントが軽くて、
かつimmutableなのをウリにしてるんですよね。ちょっと
ベンチマーク取ってみたいところですね。

262 :デフォルトの名無しさん:2011/10/02(日) 00:45:21.37
akka1.1のデータフローAPIに登場するFuture/Promiseって、
javaのFuture/Promiseと別物?
Scalaの限定継続プラグインを使っているみたいだし。
http://akka.io/docs/akka/1.1/scala/dataflow.html


263 :デフォルトの名無しさん:2011/10/02(日) 01:09:08.63
>>261
なるほどっすな。
Scala2.8の登場で、XMLをもっとうまく実装できる環境が整ったんでしょうね。


そして、これは有望なWebフレームワーク?
BlueEyes
https://github.com/jdegoes/blueeyes
A lightweight Web 3.0 framework for Scala, featuring a purely asynchronous architecture, extremely high-performance, massive scalability, high usability, and a functional, composable design.

Sinatraクローン(Scalatra)をネタに上を目指すとか。MVCならLift使えとか。

264 :デフォルトの名無しさん:2011/10/02(日) 08:20:30.82
ms単位の差が問題になるパーサを作っているのですが、
scalaで高速なパーサを作る定番はあるのでしょうか?
パーサコンビネータライブラリしかないのかなあ。

265 : ◆CgacaMDhSQ :2011/10/02(日) 09:39:18.38
>>264
Scalaのパーサコンビネータライブラリは、速度が重要になるパーザを書く用途には
本質的に向いていません(これはコップ本にも書かれていますが、Scalaのパーザコンビネータライブラリの
実装によるところが大きいです)。

速度的に、それよりもっと良いものとして、@djspiewak の GLL Combinators
https://github.com/djspiewak/gll-combinators
というのがあります。これもパーザコンビネータですが、Scala標準のものより速度が出るように
設計されています(特に、LL(k)文法に収まる場合)。

もっと速度を追求したい場合は、既存のJava用パーザジェネレータを使うという手もあります。いくつか
注意すべき点はありますが、基本的にScalaから問題なく使えます。ANTLR辺りが個人的にお勧めですが、
この辺は(必要に応じて)どれ選んでも良いと思います。性能がかなり重要とのことなので、実際にいくつかの
パーザジェネレータで簡単なベンチマーク取ってみるのが良いかと。

最後に手書きの場合ですが、Scalaで手書きパーザで速度出したい、となると、どうしてもある程度手続き的なコード
書く必要があって、その場合、本質的にJavaとあまり変わらないコードになります(型推論とかで多少楽はできますが)。

266 : ◆CgacaMDhSQ :2011/10/02(日) 09:55:52.85
>>262
概念的にはjava.util.concurrent.FutureとAkkaのFutureは類似のものですが、
AkkaのFutureはモナドなので、他のFutureから簡単にFutureを合成できたりと、
機能がよりリッチなものになっています。で、Promiseですが、これは
java.util.concurrentには無いもので、データフロー変数と呼ばれるものを作成
して、後からそこにFuture型の値をくくりつけることができるようになっています。

267 :デフォルトの名無しさん:2011/10/02(日) 10:27:30.17
>>265
ありがとうございます。
やはり標準のパーサコンビネータは向いてないようですね。

GLL(GLRのLL版?)をまずは試してみます。

268 :デフォルトの名無しさん:2011/10/03(月) 18:06:33.04
scala実践プログラミングを母校の図書館で借りたんだけどあまり人気ないみたいね

269 :デフォルトの名無しさん:2011/10/03(月) 19:17:15.84
>>268
尾崎のクオリティが低いばかりに…申し訳ありません…

270 :デフォルトの名無しさん:2011/10/03(月) 20:51:21.89
そろそろ名誉毀損とか、そういう言葉を持ち出した方がいいのか。

271 :デフォルトの名無しさん:2011/10/03(月) 21:07:28.17
ループの外側でリストを生成して、直下のループのなかでTuple2オブジェクトを生成して、そのリストに追加して行く。(ループ回数は不定)
このコードってどう書くの?
リストにタプルを追加しようとするとtype mismatch になっちゃう。

272 :デフォルトの名無しさん:2011/10/03(月) 21:17:56.37
>>269-270
コンセンサスがとれているならともかく、まあ確かに、具体的にクオリティの低い箇所を
具体的に指摘すべきだよな。


273 :デフォルトの名無しさん:2011/10/03(月) 21:24:36.06
本人の自虐だと思った

274 :デフォルトの名無しさん:2011/10/03(月) 21:44:06.13
>>271
Scala歴二日のHaskellプログラマが書いてみました
意図どおりですかね?
たぶんエラーになったコードを貼ったほうが思い違いが少なくてよいと思います

var l : List[(Int,Int)] = List()
for (i <- List(1,2,3)) {
l ::= (i, i + 1)
}
println(l)

Scalaキモいなあが二日間いじった感想です
subtypeキモいです
これからこのスレでお世話になろうと思います
よろしくおねがいします

275 :デフォルトの名無しさん:2011/10/03(月) 22:00:00.46
>>271
タプルを囲むカッコを書いたつもりで、実は引数のカッコを書いていた、
というのがありがちだから、とりあえずタプルのカッコを更にカッコで包んでみるんだ。

276 :デフォルトの名無しさん:2011/10/03(月) 23:19:34.11
>>274 >> 275
ありがとう!
どうやらListの宣言の時点で間違っていた(理解していなかった)みたい。
object GetOptions {
def main( args:Array[String] ){
var list:List[(String,String)] = List()
for ( i <- 1 to 10 ) {
//list =:: "a"+i -> i.toString()
list = list ::: List("a" + i -> i.toString())
}
println (list)
}
}

普段仕事でJavaとPHPしか触らなくて、まったくScalaの勉強が進まなかったから、とりあえずPerlのGetOptions
みたいなものでも作ってみようと思っていきなり躓いてた。


277 :デフォルトの名無しさん:2011/10/03(月) 23:41:17.15
>>276
ListBuffer使えばいいと思うよ

object GetOptions {
def main(args: Array[String]) {
val buf = new scala.collection.mutable.ListBuffer[(String, String)]
for (i <- 1 to 10) {
buf += "a" + i -> i.toString
}
println(buf.result)
}
}


278 :デフォルトの名無しさん:2011/10/04(火) 15:29:50.69
>>276

(1 to 10).map(i => "a" + i -> i.toString)

または

for(i <- 1 to 10) yield i => "a" + i -> i.toString

どうしてもリストが良ければ、最後で

toList

でどうでしょうか



279 :デフォルトの名無しさん:2011/10/05(水) 09:32:38.59
Scala 2.9.1 & Akka 1.2 のお手軽インストーラ
「Typesafe Stack 1.1」がリリースしてるよぉ

http://typesafe.com/stack/download

こっそり同僚のPCにインストールするのに便利!

280 :デフォルトの名無しさん:2011/10/05(水) 09:53:37.98
Finagleはまだscala2.8.1だし食い合わせのいいakkaにしようかな


281 :デフォルトの名無しさん:2011/10/05(水) 20:35:54.05
>>280
何を作る気なんだ?

282 :デフォルトの名無しさん:2011/10/05(水) 23:31:18.43
>>278
元々の質問読んだら?

283 :デフォルトの名無しさん:2011/10/06(木) 08:22:43.96
akkaり〜ん!

284 :デフォルトの名無しさん:2011/10/06(木) 18:19:49.24
アニオタきめえ

285 :デフォルトの名無しさん:2011/10/06(木) 18:34:14.33
日本のScalaユーザの大半はアニオタだろ。お前も含めて。

286 :デフォルトの名無しさん:2011/10/06(木) 18:53:13.75
Haskellほどではないな

287 :デフォルトの名無しさん:2011/10/06(木) 19:48:54.71
Haskellやったらかわいい彼女やかっこいい彼氏が出来るらしいけど、
Scalaやったところでモヒカンになれる気しかしねぇぜ!

288 :デフォルトの名無しさん:2011/10/07(金) 00:10:20.65
酢辛って感じ

289 :デフォルトの名無しさん:2011/10/07(金) 13:03:21.77
やっぱさー
文系馬鹿がScala使ったところで、ベタージャバにしかならないね
文系にはオブジェクト指向

290 :デフォルトの名無しさん:2011/10/07(金) 13:19:39.52
文系くん、ベターな日本語で頼む

291 :デフォルトの名無しさん:2011/10/07(金) 13:31:23.34
どうしたのおっさん?年下の上司にScala却下されたの?

292 :デフォルトの名無しさん:2011/10/07(金) 20:20:05.30

ベターなJavaでも、全然OKだと思う、、。


だが、問題は、Java自体が人気下降気味なこと。
Android関連で、また、盛り返してくれればうれしいけど。

Javaは、GUIとかがイマイチ垢抜けないよね。
SwingXとかでサクサク作れる開発環境があると良いのだが。


293 :デフォルトの名無しさん:2011/10/07(金) 22:47:55.67
Javaはオワコンだろう

294 :デフォルトの名無しさん:2011/10/07(金) 23:00:40.02
AndroidのJavaはOracleに訴えられちゃったからね……

295 :デフォルトの名無しさん:2011/10/08(土) 01:13:37.51
Java言語とJVMは分けて考えろよおめーら

296 :デフォルトの名無しさん:2011/10/08(土) 01:23:29.47
jvmのjava離れ


297 :デフォルトの名無しさん:2011/10/08(土) 02:00:11.94
jvmってジャヴァで実装されてるんですか?

298 :デフォルトの名無しさん:2011/10/08(土) 02:32:55.07
Squawk VMの話?

299 :デフォルトの名無しさん:2011/10/09(日) 06:31:46.58
「すっからかん」に「あっかん」やろ?関西弁にしたらすからはあかん
のや

300 :デフォルトの名無しさん:2011/10/09(日) 11:49:29.38
>>299
つまんねえんだよクズ
これだから土人は…

301 :デフォルトの名無しさん:2011/10/09(日) 21:37:20.95
>>300
頭がすっからかんなのね。気の毒に。

302 :デフォルトの名無しさん:2011/10/09(日) 21:47:38.71
荒らしはスルーでお願いします

303 :デフォルトの名無しさん:2011/10/10(月) 20:18:15.70
普及率を考えるとWebはPHP >> java >> rubyの順でずっと席巻してそうだな。
scalaはベターC++を目指したD言語と同じ末路確定

304 :デフォルトの名無しさん:2011/10/10(月) 21:36:34.72
ちょっと何言ってるかわかりませんね

305 :デフォルトの名無しさん:2011/10/10(月) 23:40:58.62
Facelets/JSF2.xみたいなのがScalaで書けたらなぁ…。

306 :デフォルトの名無しさん:2011/10/10(月) 23:42:46.37
Scalaの日本語wikipediaの記事を見るたびに、いたたまれないというか、悲しい気持ちになる。

307 :デフォルトの名無しさん:2011/10/11(火) 01:46:27.81
>>303
言語仕様に優れ、C言語と連携もばっちりのD言語は
かつてベターC++と一部で騒がれたが、結局は普及率せず風前の灯し火
scalaの立場と似ているだろ

そして言語仕様の酷いPHPが普及率で君臨し続ける

308 :デフォルトの名無しさん:2011/10/11(火) 02:36:23.39
>>307
別に国内での普及率なんてどうでもいいなぁ
俺はScalaが気に入ってるから使うけど、JavaやPHPが好きな人はそれを使い続けてればいいと思うよ

309 :デフォルトの名無しさん:2011/10/11(火) 03:22:06.62
D言語はともかく、信頼できる体制でメンテされる言語なら仕事でも使いたいじゃん
だから普及してくれないと困る

310 :デフォルトの名無しさん:2011/10/11(火) 03:31:28.22
>>309

同意。

とりあえず一度普及してくれれば、その後もメンテされ続けるからなあ。



311 :デフォルトの名無しさん:2011/10/11(火) 06:45:00.66
>>303 >>307
しかし何故に比較対象がPHP…??
C言語とかも出てくるし、どういう分野での話をしてるのだ?

312 : ◆CgacaMDhSQ :2011/10/11(火) 07:27:25.50
国内はともかく、海外では、著名なサービス(Twitter, LinkedIn)を提供している会社が何社も使っていますし、
著名じゃない所でもScalaを採用している会社が増えています。Typesafe社という形でサポートビジネス等を
立ち上げたからには、それらの会社が軒並みScalaを破棄するという事にならなければ、当分はメンテされるでしょう。
Typesafeがどれだけ儲かってるかはわかりませんが、主要メンバって結局はEPFLのScalaチームなので、Typesafe
が儲からなくてもメンテナンス自体は継続可能な状態ですし。

あと、互換性の問題を無視して言語仕様を拡張しようとしても、公式MLで文句言う「仕事でScala使ってるユーザ
(海外)」がそれなりに居ますし今後しばらくは「破壊的な」言語仕様の変更は起こらないと思います。

313 :デフォルトの名無しさん:2011/10/11(火) 07:37:09.81
JVM依存が無くなってくれれば……

314 :デフォルトの名無しさん:2011/10/12(水) 06:59:33.93
http://www.youtube.com/watch?v=jAMNyqYLh78
小田好先生ってこんなイケメンだったんだな

315 : ◆CgacaMDhSQ :2011/10/12(水) 07:50:00.29
>>314
Odersky先生に会った個人的な印象としては、ナイスミドル、という感じでしたね。なんか顔つきがあまり泥臭くない
というかw あと、結構情熱家だなあ、とも。

316 :デフォルトの名無しさん:2011/10/12(水) 21:31:21.43
>>313
使う人がいなくなる。

317 :デフォルトの名無しさん:2011/10/12(水) 21:38:54.52
.NET移植が順調に進んで、進みすぎて本家追い越すくらいになればあるいは
でもあれIKVMだったっけ?

318 :デフォルトの名無しさん:2011/10/13(木) 00:44:34.76
コンパイルターゲットがJVMなのは、各種のJVM資産が使えるというメリットもある一方で、
環境が限られるというデメリットもあるよねえ。

まあ、OpenJDKとかもあるから、JVMがなくなることはないと思うのだけど、、。


あと、JavaならGWTで JavaScriptに変換できるけど、
Scalaではそういうのないの??



319 :デフォルトの名無しさん:2011/10/13(木) 01:39:52.57
The Scala Compiler Corner, for .NET and Mono fans: A collection of resources for compiler hackers focusing on the MSIL backend of the Scala compiler
http://lamp.epfl.ch/~magarcia/ScalaNET/
jdk2ikvm: A source-level conversion tool to migrate Scala programs from JDK to .NET
http://lamp.epfl.ch/~magarcia/jdk2ikvm/
ikvmを使ってconvertするみたいだけど、よくわからん

320 : ◆CgacaMDhSQ :2011/10/13(木) 02:29:37.92
>>318
>あと、JavaならGWTで JavaScriptに変換できるけど、
>Scalaではそういうのないの??
あるよ。
http://scalagwt.github.com/
まだ正式リリースは無いが、GWTのJavaで書かれたデモ(に相当するScalaコード)ほとんどがコンパイル/動作できるくらいには進展してる
らしい。

321 :デフォルトの名無しさん:2011/10/13(木) 02:58:37.26
s2jsというコンパイラプラグインもあるが、俺の所で動いたためしがないな。

322 :デフォルトの名無しさん:2011/10/13(木) 09:03:52.31
JVM抜きでは衰退するというのは、ScalaってJava使いから来てる人
が圧倒的に多いようだからだよ。逆に言えば、Java使いから魅力が
あっても、それ以外からは魅力がない言語ということを暗に意味してる。
C#なんかも.NETじゃなかったら普及してないだろう?それと同じ。

323 :デフォルトの名無しさん:2011/10/13(木) 13:50:46.17
今のところJVMの問題よりJava文化の恩恵を受けているほうが遥かに大きいだろ

324 :デフォルトの名無しさん:2011/10/13(木) 21:24:51.51
今更だが、並列コレクションを使ってみた。
確かに全CPUを使いきってくれる。
手軽だね。

ただ、共有データを操作する際にロックは必要だと思うけど、見当たらない。
これはJavaのロック機能を使えということなのかな。


325 :デフォルトの名無しさん:2011/10/14(金) 01:43:53.25
Javaの経験のある初心者です。scalaすごくいいですよね。Javaで面倒くさいと思った部分(ex new)をいろいろ楽にしてくれているし。
これが広まらずに終わるのって正直やだなと思います。
scalaが信用され利用できる範囲が広がる事を祈ってます。

326 : ◆CgacaMDhSQ :2011/10/14(金) 06:16:14.73
>>324
まず、並列コレクションでは、明示的なロック操作を行う事は基本的には想定されていません。
並列コレクションのモデルは、いわゆる「暗黙的な」並列化という奴で、不変コレクションを使って
いて、共有データを高階関数内で書き換えなければ、処理が並列化されている事は、プログラマ
から「見えない」というものです。ですから、そもそも並列コレクション専用のロックメカニズムは
用意されていません。Javaのsynchronizedを使うことはできますが、基本的にそれはやらない方
が賢明です。

ロックを使う必要がある場合には、ロックを使わないでいい形に、並列コレクションを使った処理にうまく
変換するか、Actorなどの「明示的な」並行処理を提供するライブラリを利用するべきです。

327 :デフォルトの名無しさん:2011/10/14(金) 16:25:08.38
プログラミング初心者なんですが、コップ本とSICPはどちらがためになりますか

328 :デフォルトの名無しさん:2011/10/14(金) 16:32:58.51
その前置きが必要な質問か

329 :デフォルトの名無しさん:2011/10/14(金) 16:33:05.20
高校生でお金がないので、どちらか一冊を読み込もうと思っています

330 :デフォルトの名無しさん:2011/10/14(金) 17:29:39.85
そりゃSICPのほうが役に立つだろうが、通読するのはなかなかきつい
特に日本語版

331 :デフォルトの名無しさん:2011/10/14(金) 17:47:37.27
図書館か図書室の司書に言って買ってもらえや

332 :デフォルトの名無しさん:2011/10/14(金) 17:52:17.71
SICPなら工学部がある大学の図書館に行けばあるかもね。
そこの学生じゃなくても入館はできるよね?

333 :デフォルトの名無しさん:2011/10/14(金) 19:21:44.98
最近のデジタルネイティブのネイティブっぷりはほんと驚異だなぁ。

334 :デフォルトの名無しさん:2011/10/14(金) 22:06:01.77
SICPはプログラミング(もっというとコンピューターサイエンス)を
学ぶための手段としてSchemeを使う本で、コップ本はScalaを学ぶための本。
だいぶ毛色が違うんで目指してる方向が逆ならそれぞれ役に立たない。

それから、ほんとにまったくプログラムしたことない状態なら
コップ本一冊だけでやるのはかなりきつい

335 :デフォルトの名無しさん:2011/10/14(金) 22:24:07.93
任意の関数を受け取って、その関数をラップした同じ引数の新しい関数を返す関数ってタイプセーフに書けますか?

336 :デフォルトの名無しさん:2011/10/14(金) 23:25:37.56
>>335
任意の関数を受け取る時点で無理じゃない?

def wrap[T,R](f: Function1[T,R]) = (t: T) => {
println("wrapped")
f(t)
}

こんな感じでFunction0からFunction22用まで定義するとか


337 :デフォルトの名無しさん:2011/10/14(金) 23:37:43.34
ちょっと違っちゃうがwrap呼ぶ前にtupled呼んで1つのタプルを引数に取る関数に変換すれば

338 :デフォルトの名無しさん:2011/10/15(土) 00:31:43.64
tupleですか。ありがとうございます。

一応やりたい事のサンプルみたいなのをpythonで書いておきます。
型のない言語だと可変長引数でなんとでもなるのですが、
タイプセーフにできないものかと思いまして。

...def wrap(func):
... def cls(*args, **kwargs):
... brfore()
... try:
... return func(*args, **kwsrgs)
... finally:
... after()
... return cls

こういう感じでラップ前と同じ引数で呼び出せば
実行前になんらかの処理を実行してくれて、
かつ呼び出す側はラップされてるかどうかを
意識する必要がないという状態にしたいです。

できなければいくつか引数の違う関数を作る方法で妥協するのが一番かなと思ってます。

339 :デフォルトの名無しさん:2011/10/15(土) 00:33:25.37
Scalaで書いてから質問しろよw

340 :デフォルトの名無しさん:2011/10/15(土) 00:50:17.65

俺よくこういうコードを書くんだがもしかしてこんなので代用できねーか?

def wrap[A](block: => A): A = {
 before()
 try {
  block
 } finally {
  after()
 }
}

wrapに渡すときに引数も一緒に渡す
wrap(hoge(a,b))

やりたいことと違ったらゴメンだが

341 :デフォルトの名無しさん:2011/10/15(土) 00:50:47.56
詳細がわからないから何とも言えないけど、
どうも発想の筋が悪いというか、関数型っぽくないというか

342 :デフォルトの名無しさん:2011/10/15(土) 03:11:52.66
>>341
関数型ではデコレーターとかあまり使わないのでしょうか?
代わりにどのような方法で代用するのでしょうか?

ログ出力とか楽なのになぁ。

343 :デフォルトの名無しさん:2011/10/15(土) 08:30:28.80
普通の関数型言語は、1引数関数しかないので何の問題もない。

残念ながらscalaはJavaとあわせるという制約があって、そうなっていないので
ちょっとぎこちなくなるね。

344 :デフォルトの名無しさん:2011/10/15(土) 14:47:24.92
>>330-334
レスありがとうございます
JavaとJavaScriptは少しだけ書けます
JavaもJavaScriptのように自由に関数を扱えればいいのにと思っていたところ
Scalaを知って大変興味を持ちました

SICPは翻訳も内容も難しいとのことですが、挑戦してみよぅと思います
Scalaプログラマの皆さん、ありがとうございました

345 :デフォルトの名無しさん:2011/10/15(土) 16:36:35.35
>>344
SICPは何年かかっても読む価値のある本だ
問題も解けよ。感動がある
分厚いので挫折しそうになるが、なんとか二章までがんばれ
偉そうなこと言えるレベルになるぞ

346 :デフォルトの名無しさん:2011/10/15(土) 16:57:13.27
SICPは前半は抽象化の話で
後半はmeta circular
重要だけどちょっと毛色が違う

347 :デフォルトの名無しさん:2011/10/15(土) 17:08:53.26
>>343
なるほど!
1引数の関数しかないってことですか。
じゃあ関数をカリー化する関数を作れば
なんとかなりそうな気がしてきました。
ありがとうございます。

def wrap[T, U](func: T => U): T => U = {
val r: T => U = {...}
r
}

こんな感じ?

348 :デフォルトの名無しさん:2011/10/15(土) 21:56:40.01
scalaからJavaで書いたクラスのメソッドを呼び出すとき、
そのメソッドと同名のフィールドがあると呼び出せません。

public class A {
private int m;
public int m() { return 0; }
}

--- scala

def f(A a) {
a.m() <-- エラー
}

scalaではメソッドとフィールドの名前空間が同じためかと思うのですが
回避策はあるのでしょうか?

349 :デフォルトの名無しさん:2011/10/18(火) 00:38:14.38
ここよりいい解説知りませんか?

http://twitter.github.com/scala_school/basics2.html

350 :デフォルトの名無しさん:2011/10/18(火) 00:41:04.56
こっちだった

http://apocalisp.wordpress.com/
http://www.codecommit.com/blog/ruby/monads-are-not-metaphors

351 :デフォルトの名無しさん:2011/10/18(火) 01:30:20.95
>>350
http://dl.dropbox.com/u/261418/Monads_are_Elephants/index.html
これを貼れというステマですか?

352 :デフォルトの名無しさん:2011/10/21(金) 13:59:25.96
Scala IDE for Eclipse入れてjavaのプロジェクト触ってるとよくScalaのライブラリを
ビルドパスに追加するか聞かれてうざったいんだけど、これ消せない?

353 :デフォルトの名無しさん:2011/10/22(土) 08:43:48.90
>>327
SICPを読むくらいならHaskell勉強した方が学びやすいし、ためにもなると思うよ。
基礎的な勉強がしたいならTAPLの方がオススメ ttp://www.cis.upenn.edu/~bcpierce/tapl/

354 :デフォルトの名無しさん:2011/10/22(土) 10:35:57.23
ITProで新しいScalaの連載始まったね。けっこうわかりやすい。
「Scalaプログラミングに欠かせない機能---Scalaの基本4」
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370491/

355 :デフォルトの名無しさん:2011/10/22(土) 12:21:48.24
始まったね、とかいいつつ最終回の記事を紹介するとは

356 :デフォルトの名無しさん:2011/10/22(土) 13:04:35.67
>>355 あれ、これって4回で終わりなの?もっと連載してほしいのに。

357 :デフォルトの名無しさん:2011/10/22(土) 14:00:01.44
>>356


連載っていうか、もともとは月刊雑誌の一回だけの特集を、Webに乗せただけ。


日経ソフトウェアの2011年6月号  pp.78-79 が、
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370488/
変数とクラスを学ぶ---Scalaの基本1

同じく pp.85-87が
http://itpro.nikkeibp.co.jp/article/COLUMN/20111011/370491/
Scalaプログラミングに欠かせない機能---Scalaの基本4


だから、最初から これで完結だよ。

358 :デフォルトの名無しさん:2011/10/24(月) 00:33:03.64
HaskellもOCamlも、定義したヴァリアントはデータ型の内部構造を
直接さらしてしまう、という欠点を持っているけど
Scalaではケースクラスにしつつ内部表現を隠蔽することも簡単にできるらしい

これってどういうこと?

359 :デフォルトの名無しさん:2011/10/24(月) 08:36:24.45
プライベートなメソッドを持てるかどうかって事?
なんかOCamlとかでもできそう。

360 :デフォルトの名無しさん:2011/10/24(月) 10:03:50.82
Haskellならデータ構築子をモジュール外に公開しないことで可能
内部と外部の境界がモジュールなので、クラスとかに比べたら少し大きい

361 :デフォルトの名無しさん:2011/10/24(月) 17:22:44.52
発想の基本がOOPの言語と発想の基本が関数型では違ってくるよ。
ありがたがってる土俵が関数型のプログラミングではあまりありがたみが
ないというのはよく有りそうだよ。

362 :デフォルトの名無しさん:2011/10/24(月) 17:53:53.25
関数型言語ではそもそもアクセスされて困るプロパティが作れないからなぁ。

363 :デフォルトの名無しさん:2011/10/24(月) 18:15:42.33
>>362
何を言っているのか理解できないので
くわしく教えて

364 :デフォルトの名無しさん:2011/10/24(月) 19:49:26.90
そもそも、関数型でOOP的なものが必要なところは限られてる。シミュレーション
をやるなら重宝するんだけど。でもScalaをやってる人のソースを見てるとやっぱり
関数型っぽくないというのかJavaの後継という使い方に見える。
関数型のスタイルでScalaをやってるブログなどがあったらぜひ見てみたいので
英語でもいいし教えてね。

365 :デフォルトの名無しさん:2011/10/24(月) 20:13:16.66
scalaz界隈をうろつけばいいじゃない(想像)

366 :デフォルトの名無しさん:2011/10/24(月) 23:01:42.68
なぜScalaモヒカンは他言語をdisるのか
それも詳しく知りもしないくせに

367 :デフォルトの名無しさん:2011/10/24(月) 23:11:28.45
>>366
いいじゃん別に
disらせとけば
なんか不利益でも被ってんの?

368 :デフォルトの名無しさん:2011/10/24(月) 23:20:17.71
不利益を被ってないなら黙ってろって?
どうせScalaをdisられたら顔真っ赤にして反論するくせにw

369 :デフォルトの名無しさん:2011/10/24(月) 23:31:42.66
うむ、disられたら顔真っ赤にしてキッチリ反論するのはいいと思うよ
2chの言語スレに来てグダグダいうよりはよっぽど

370 :デフォルトの名無しさん:2011/10/24(月) 23:41:40.60
>>358
ocamlのvariantもモジュールで隠蔽できるから、
たぶんそれ書いた人の勘違いじゃないか?

371 :デフォルトの名無しさん:2011/10/25(火) 00:42:22.72
sbtのtestの出力結果ってwinではカラー表示できないの?

372 : ◆CgacaMDhSQ :2011/10/25(火) 00:48:17.81
>>370
たぶん書いた本人です。
>>358はちょっと誤解で、元の発言は
http://twitter.com/#!/kmizu/status/128044795615653888
http://twitter.com/#!/kmizu/status/128045117264248832

これはこれでちょっとわかりにくいですけど、要はパターンマッチ使いたかったら
variantの内部構造さらさなきゃいけないけど、Scalaだとパターンマッチのために
内部構造さらさなくても良いよね、という話です。

Haskellだとviewパターン、F#ならActive Patternがあるので似たような事が比較的簡単に
できますが、少なくともOCamlではvariantの構造をさらさなければパターンマッチング
できない(モジュールにvariantの構造を隠蔽しちゃうと外からパターンマッチングはできない)と
認識しています。もし間違っていたら、文献へのポインタを教えていただけるとありがたいです。

>>364
>>365が挙げてるようにscalaz界隈の人(単なるマニア向けライブラリに見えますが、意外にこれ
使ってるScalaプロジェクトは多いです)はかなり関数型的なスタイルやってますし、sbtも
かなり関数型的なコードになってます。全体的に見て、関数型スタイルでScalaプログラミング
やってる人は以前に比べてかなり増えてる印象です(少なくとも海外は)。

あと、ブログでも、関数型的なスタイルでScalaやってるところは、たくさん見つけられるかと。
@djspiewak さんのブログとか、@jamesiry さんのブログとか、色々ヒットしますよ。

373 :デフォルトの名無しさん:2011/10/25(火) 00:58:38.49
actorでreplyするとAny型じゃん.
Int型の値に代入すると怒られるんだが,match文使わずにエレガントに
代入したい.

374 :デフォルトの名無しさん:2011/10/25(火) 07:44:36.51
>>372
variantの構造、で何を指してるのかがイマイチわからない
例があると良いと思う

375 :デフォルトの名無しさん:2011/10/25(火) 08:02:14.78
あ、良く読んでなかった。F#のActive Patternsねー
あれと同じことをOCamlでやるにはパターンガード使うしか無いけど、
それでパターンマッチできてるとは言わないわな

376 :デフォルトの名無しさん:2011/10/25(火) 08:14:15.47
個人的にはパターンって内容を取り出すのが目的だと思ってた

377 :デフォルトの名無しさん:2011/10/25(火) 08:20:26.47
Scalaは型ちゃんと書くから2nd order polymorphismが表現できてもよいと思うんだけど
(つまり、forall をいろんなところにつけれる)
例えば:
def foo(id : [A]. A => A) : Unit =
 id(id)(())
これが普通にできればMLやHaskellより明らかに強力と言えるのではないか。

378 :デフォルトの名無しさん:2011/10/25(火) 08:38:11.46
>>376
ですよねー

379 :デフォルトの名無しさん:2011/10/25(火) 08:46:09.53
多分この中のどれかにやりたいことがあるのでは?

(* データ型の隠蔽 *)
module type S1 = sig
  type r
  type s
  type t = Foo of r | Bar of s
end

(* コンストラクタの隠蔽 *)
module type S2 = sig
  type t = private Foo of int | Bar of string
end

(* 幽霊型 *)
module type S3 = sig
  type s = Foo | Bar
  type 'a t constraint 'a = s
end

380 :デフォルトの名無しさん:2011/10/25(火) 11:55:40.54
Camlp4使うしexperimental featureだけど一応こんなのあるみたいっすよ
http://martin.jambon.free.fr/mikmatch-manual.html#htoc10

381 :デフォルトの名無しさん:2011/10/25(火) 16:32:39.86
>>377
書いてみた
import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id.apply[Unit])(())
foo(new Forall[({ type X[A] = A => A })#X] { def apply[A] = identity })

382 :デフォルトの名無しさん:2011/10/25(火) 17:30:56.34
もうちょっと短く書けた
import scalaz.Forall
def foo(id : Forall[({ type X[A] = A => A })#X]) : Unit = id.apply(id[Unit])(())
foo(Forall[({ type X[A] = A => A })#X](_(identity)))

383 :デフォルトの名無しさん:2011/10/25(火) 18:57:12.81
>>372
ありがと いくつかのブログ漁ってみるよ。

384 :デフォルトの名無しさん:2011/10/25(火) 22:36:49.23
ファイル出力の標準的な方法ってありますか?
ファイル入力のSource.fromFileに対応するようなものです。

今はFileOutputStream〜PrintWriterといったJavaのAPIを使ってますが正直面倒です。

385 :デフォルトの名無しさん:2011/10/25(火) 22:50:02.40
jajava.nioで

386 :デフォルトの名無しさん:2011/10/27(木) 08:47:25.77
(Int)=>Intのような関数を引数に取るAPIを、Javaから呼ぶにはどうやって引数を渡せばよいの?
自力でFunction2にラップする?
そういうユーティリティが既にある?

387 :デフォルトの名無しさん:2011/10/27(木) 13:41:22.80
>>386
scala.Function1をimportして
new Function1<Integer,Integer>() { public Integer apply(Integer i) {...}}
とすればよいのではないか。

388 :デフォルトの名無しさん:2011/10/27(木) 13:56:12.49
>>386
ScalaのtraitはJavaのinterfaceになるから、具体メソッドはすべてつぶされてしまう(ヒドス)。
Function1はtraitなのでJavaから便利に使うためにabstract classにする。

==========scala============
abstract class Fun[-A,+B] extends Function1[A,B] {
override def andThen[T](g: (B) => T): (A) => T = this.andThen(g)
override def compose[T](g: (T) => A): (T) => B = this.compose(g)
override def toString(): String = this.toString()
}

389 :デフォルトの名無しさん:2011/10/27(木) 13:59:31.00
==========java=============
import scala.Function1;
import scala.Some;

public class Main {
public static void main(String[] _args) {
Fun<Integer,Integer> f = new Fun<Integer,Integer>() {
@Override
public Integer apply(Integer n) {
return n+1;
}
};
System.out.println(new Some(3).map(f));
}
}

390 :386:2011/10/28(金) 08:38:52.69
>>387,388,389

さんきゅー!
基本は388&389の方針に従った。

scala側は

abstract class Func1[-A,+B] extends Function1[A,B]

で十分みたい。
andThen,compose,toStringは勝手に生成されたよ。

実装のあるtraitをabstract classでextendsしたら
その実装を引き継ぐコードが自動生成されるみたいだね。

(Int)=>Intの関数は、JavaではFunction1<Object,Object>に
見えるらしく、Java側はこんなコードになったけど、
まあ、我慢できる範囲かな。andThenもこのまま使えたよ!

| Func1<Object,Object> f = new Func1<Object,Object>() {
|  @Override public Object apply(Object v) {
|   return (Integer)v + 1;
|  }
| };

ありがと!

391 :デフォルトの名無しさん:2011/10/28(金) 11:37:21.63
play2.0ってeclipsify出来ないの?

392 :デフォルトの名無しさん:2011/10/28(金) 19:04:31.14
上でファイル出力の質問があったけど、実際みんなJavaのAPIでやってます?
Sourceはなぜこんな非対称な仕様なんだろう…

393 :デフォルトの名無しさん:2011/10/28(金) 20:59:19.04
俺はOutputStreamへの書き込みは次のようなusing関数を使うのがよいと思うのだが
どうだろう?
| def using[T](out : OutputStream)(f : Outputstream => T) : T = {
| try {
| val r = f(out)
| out.close()
| r
| } catch {
| e => out.close(); throw e
| }
| }


394 :デフォルトの名無しさん:2011/10/28(金) 21:01:17.45
def usingFile[T](fileName : String) = using[T](new FileOutputStream(filename))

395 :デフォルトの名無しさん:2011/10/28(金) 21:07:42.43
使い方
usingFile("foo.txt") {
 out =>
  val w = new PrintWriter(out)
  w.println("firstLine")
  w.println("secondLine")
}

396 :デフォルトの名無しさん:2011/10/28(金) 22:17:31.96
>>395
out => ってどこから使えるようになったの?


397 :デフォルトの名無しさん:2011/10/28(金) 22:43:58.48
>>396
仮引数だよ。

list.map { a => a+1 }

の a と一緒。

398 :デフォルトの名無しさん:2011/10/28(金) 22:47:46.22
PrintWriterもusingFileで作ってしまったら?

399 :デフォルトの名無しさん:2011/10/28(金) 22:49:50.13
か、か、かりひきすう?
それなに?まだよくわからん

引数と違うの?

400 :デフォルトの名無しさん:2011/10/28(金) 23:15:58.69
>>399

仮引数ってのは正確な物言いじゃあないかもしらんが、Java でも何でも一般的な概念でしょう。

401 :デフォルトの名無しさん:2011/10/28(金) 23:21:54.39
仮引数に束縛…とか、アリティが…とか、正直実用だけを考えるなら、用語を知る必要もない。
つか仮引数とかって基本情報とかに出てきたような過去の記憶が。

402 :デフォルトの名無しさん:2011/10/29(土) 08:05:34.67
>>396
関数を引数として渡すときに #Scala ではしばしば {}で囲って表現する。
someArray.foreach(x => save(x); println(x)) って書くよりも
someArray.foreach {
 x =>
  save(x)
  println(x)
}
って書いた方がDSLぽくてカッコいいでしょ。

403 :デフォルトの名無しさん:2011/10/29(土) 09:07:43.26
>>388

> Function1はtraitなのでJavaから便利に使うためにabstract classにする。
>
> ==========scala============
> abstract class Fun[-A,+B] extends Function1[A,B] {

その目的のためには、scala.runtime.AbstractFunction1が既に標準で用意されている也。


404 :デフォルトの名無しさん:2011/10/29(土) 09:24:30.22
>>396

気になってるのは out が前触れなしに出てきたからでしょ。
これってたとえば 「def add1(a: Int) = a + 1」 の add の直後に出てくる a つまり仮引数と一緒なんですよ。

で、もう最初に気になったあたりを見直すと、

def using[T](out : OutputStream)(f : Outputstream => T)

ってなってて、結果的に usingFile の 2 つめの引数の型は「Outputstream => T」になる。
これは「Outputstream を一つ引数にとり T を返す関数」を要求してることになるから、

(out: Outputstream) => hogehoge....

と書くところを

out => hogehoge...

と書けるわけ。

405 :デフォルトの名無しさん:2011/10/29(土) 13:54:53.12
>>404

def using[T](out : OutputStream)(f : Outputstream => T)
って表記されればわかった。

REPLってなんで定義した関数の型とか引数の情報も
詳しく出してくれないのですか?F#ならでるのですが

406 :デフォルトの名無しさん:2011/10/29(土) 23:47:25.13
>>405
え、嘘、出るだろ!?と思ってやってみたら出たけど、
どういう時に出ないの?

407 :デフォルトの名無しさん:2011/10/30(日) 02:18:06.25
今更かもしれませんが、これってどう思いますか?

SIP-12 - Uncluttering Scala's syntax for control structures.
http://docs.scala-lang.org/sips/pending/uncluttering-control.html
(なぜか過去のコメントが見られなくなってしまったようです)

個人的には、利点があまり感じられない上に、
ユーザ定義の制御構造との統一感が無くなるので、
賛成できないのですが。


408 :デフォルトの名無しさん:2011/10/30(日) 03:02:51.57
forのカッコは鬱陶しいと思ってたので歓迎
他はどっちでもいいかな

409 :デフォルトの名無しさん:2011/10/30(日) 09:40:42.29
>>407
#Scala がますます #Haskell や #OCaml みたいになるな。
しかしあまりJavaと離してしまうと、Javaユーザーが導入しづらくなり、
ポストJavaの立場がやばくなるのでは。scalaユーザが増えてほしい俺としては
ちょっと反対。

410 :デフォルトの名無しさん:2011/10/30(日) 09:51:31.15
>>409
その#は何?

411 :デフォルトの名無しさん:2011/10/30(日) 09:54:00.13
Twitterのつもりなのでは。

412 : ◆CgacaMDhSQ :2011/10/30(日) 10:23:03.80
>>409
個人的には、もっと早いタイミングで導入するのならアリだった。
シンタックスがよりJavaっぽくなくなってしまうことはそれほど問題じゃないと思う。
ただ、2.10のタイミングで、こういう、言語の表現力を上げるわけでもない「些細な」
構文的変更入れてしまうのは、反対というか遅すぎるな。

まだSIPの段階なんで入ると決まったわけじゃない。提案者が
Odersky先生ではあるけれど、まだpendingだし、MLで反対票が
多ければ入らない可能性も十分ある(2.8のときに、Seq -> Sequence
の名前変更が、反対が多くて断念したという実例とか)。

今は当時よりもScalaを実用で使ってるユーザが増えてるので、幅広く
意見集めれば反対票も出てくるのでは、と思う。

413 :デフォルトの名無しさん:2011/10/30(日) 11:10:07.78
>>412
Javaユーザが敬遠してしまう要因を増やすことになると思うがそれはよい?
JavaユーザがScalaへ移行することは重要ではないと言っている?

414 : ◆CgacaMDhSQ :2011/10/30(日) 11:51:43.42
>>413
最初の問いについては、元々Scalaの構文はJava互換でないので、>>407くらいの
変更が入ったところで、敬遠する要因が増えるかというとそんなに変わらないのでは、というのが自分の考え。

ただ、「2.10のタイミングで」これを入れるのは、Scalaへの移行を検討しているJavaユーザを遠ざける
要因になり得るので、反対(既存の構文がすぐに使えなくなるわけではないにせよ、
しばらく、旧構文と新構文を使ったコードの両方が出てきて、無用な混乱を招きそう)。

二つ目の問いについては、重要だと思っている。だからこそ、SIP 12に対しては反対。
なら行動起こせよ、と言われそうなので、説得力のある反論をまとめて、>>407のページに
コメントする事は検討中。

415 :デフォルトの名無しさん:2011/10/30(日) 12:20:19.45
>>413
お前も然るべきところで意見できるように精進しろよ^w^

416 :デフォルトの名無しさん:2011/10/30(日) 12:31:12.24
>>415 はい。勉強させていただきます。先生。

417 :デフォルトの名無しさん:2011/10/30(日) 13:17:07.97
しかしifにかっこがいるというのは最初の頃はしょっちゅう間違えたところなので、
できれば導入して欲しいな。
せっかく一引数関数のかっこを不要にしてるんだから。

418 :デフォルトの名無しさん:2011/10/30(日) 15:46:25.80
構文まで変えるなら2.10じゃなくて3.0にすればいいのでは

419 :デフォルトの名無しさん:2011/10/30(日) 16:42:09.31
省略できるもんはなんでも省略しようぜww
Javaなんて忘れて新しい秩序をつくるんだ

420 :デフォルトの名無しさん:2011/10/30(日) 16:45:16.71
Scalaが話題にのぼるようになってから、もう何年経つと思ってるんだ
未だにJavaで満足してる奴はもう切り捨て!いらね!
というわけで「Javaっぽさ」という視点はもうScalaには不要

421 :デフォルトの名無しさん:2011/10/30(日) 20:38:06.81
>>419
カッコは必ず書く派としては賛同できんな。
言語仕様として「できる」ようにする事には必ずしも反対ではないが、原則は書くべき。

422 :デフォルトの名無しさん:2011/10/30(日) 20:49:46.82
設定した通りにカッコとかを付けたり付けなかったりしてくれるコード整形ツールがあればいいと僕は思います!

423 :デフォルトの名無しさん:2011/10/30(日) 21:53:06.95
よく分からんが、

現在の
if (expression) expression else expression
という構文は廃止して
if expression then expression [else expression]
という構文になるってことか。


ただ、expression の外側に "( )" をつけてもそれはexpression だから、

if ( expression ) then expression [else expression]

はOKなんだよね?
つまり、then 必須になるってこと?

424 :デフォルトの名無しさん:2011/10/30(日) 22:23:50.38
これまでかっこが果たしていたセパレータとしての役割をthenが果たすようになるってこと

425 :デフォルトの名無しさん:2011/11/04(金) 10:06:39.96
Javaで書いていたswingの部品(たとえばJPanel)を
scala.swingのフレームに張り付けるなんてことは可能でしょうか?

scala.swingは薄いラッパーといわれているので、Javaとまぜて使えないかと期待してます。

426 :デフォルトの名無しさん:2011/11/05(土) 15:30:38.80
>>425
できるよー。scala.swingのコンポーネントには、peerというメソッドがあって、対応するSwingの
コンポーネントを取り出すことができる。

val panel : scala.swing.Panel = ...
val peer = panel.peer

みたいな感じで

427 :デフォルトの名無しさん:2011/11/05(土) 16:12:50.58
>>426
横からだけど便利だな〜
objectにしておいてくれたほうが良かった気がするけど。
何か理由があるのかな?

428 :デフォルトの名無しさん:2011/11/05(土) 21:19:41.59
>>426
ありがとうございます。

私のやりたかったこととは逆(scalaで書いていた部品をJavaに取り込む方法ですよね?)
ですが、便利そうです。

なお私のやりたかったことはwrapでできるということがわかりました。

429 :デフォルトの名無しさん:2011/11/07(月) 01:00:13.70
http://www.eclipse.org/Xtext/xtend/
もうScala不要じゃね?

430 :デフォルトの名無しさん:2011/11/07(月) 01:13:52.90
関数型としてじゃなくてBeyond javaとしては、そっちの方が筋いいかも

431 :デフォルトの名無しさん:2011/11/07(月) 03:15:48.89
genericsの型制約のシンタックスが好きじゃない
? extends とか読めない
Scalaのほうが良いと思う

432 :デフォルトの名無しさん:2011/11/07(月) 07:32:22.17
Scala終わったなぁ

433 :デフォルトの名無しさん:2011/11/07(月) 10:58:20.13
http://lambda-the-ultimate.org/node/4396
これぐらいしかnewsがないな。

xtext2.1リリースで、xtendもバージョンアップしたのかな?
http://www.infoq.com/jp/news/2011/06/xtext-20

434 :デフォルトの名無しさん:2011/11/08(火) 14:15:14.59
バイトコードじゃなくて、Javaコードを吐くというのが特徴?

435 :デフォルトの名無しさん:2011/11/08(火) 14:21:55.62
このクロージャの構文、リスト内包表記に喧嘩売ってる気が

val predicate = [ Person person | "Hans" == person.name ]

436 :デフォルトの名無しさん:2011/11/08(火) 17:42:24.87
どっちかというとSmalltalkのパクりじゃね?

437 :デフォルトの名無しさん:2011/11/08(火) 19:57:24.06
公式の右下に開発環境は何よ?ってミニアンケートがあるね。
もちろん皆 vimだよな?!

438 :デフォルトの名無しさん:2011/11/08(火) 23:03:23.17
IDEA1択

439 :デフォルトの名無しさん:2011/11/08(火) 23:05:28.63
sbtがあるから普通のテキストエディタでも問題ないね

440 :デフォルトの名無しさん:2011/11/09(水) 00:10:47.06
>>429

JetBrainsのKotlin といい、 ほとんど同じような言語開発する暇あったら、
Scala を手伝ってやれよ、って思ってしまう。

言語ばっかり乱立しても、共倒れするだろうに。

441 :デフォルトの名無しさん:2011/11/09(水) 00:19:08.57
xtendは、xtextのサンプルでもあるから、
JVM上のbetter javaのCeylonやKotlinとはちょっと意味合いが違うと思う。

442 :デフォルトの名無しさん:2011/11/09(水) 00:27:54.68
たしかにいくつ作るんだよとは思うが。
Javaのシンタックスシュガーに徹するんならJSRにのせたりしないのかね。

443 :デフォルトの名無しさん:2011/11/09(水) 00:59:45.83
別にいくら作ってもいいんだが、なぜみんなScalaとJavaの中間を目指すんだろう
仕様は日和っているわりに、これから実装しますとか実用性もない状態で、誰が使おうと思うのだろう

444 :デフォルトの名無しさん:2011/11/09(水) 03:11:09.07
えっ、気分でしょ?

445 :デフォルトの名無しさん:2011/11/09(水) 06:07:14.92
>>443
Scalaより単純で実用的と言ってるんだから、使える標準ライブラリとひとまとめにしてさっさと公開すればよいのにね
結局、現時点でScalaの方が基本インフラ整ってる分実用性が高いとか皮肉すぎる

446 :デフォルトの名無しさん:2011/11/09(水) 06:33:03.79
>>443
発想が「ぼくのかんがえた さいきょうの Better Java」だから、だろうねぇ。

447 :デフォルトの名無しさん:2011/11/09(水) 10:14:51.22
xtext,xbase,xtend 2.1 リリース
http://www.infoq.com/jp/news/2011/11/xtext21
scalaこれで実装したら遅くなるんだろうな

448 :デフォルトの名無しさん:2011/11/09(水) 23:00:13.38
Oderskyはバリバリ実装する人であると同時に優秀な理論屋なので、Scalaの仕様は
理想と現実の妥協点がよく考えられてるんだけど、後発のおいしい所取り狙ってる言語は、
なんかよくわからずにテキトーにScalaの一部分持ってきてるだけに見えるんだな

449 :デフォルトの名無しさん:2011/11/10(木) 00:58:45.17
最近更新されてないんだな。
あんまり学会発表しなくなった?
http://www.scala-lang.org/node/143

450 :デフォルトの名無しさん:2011/11/10(木) 01:10:23.66
http://ppl.stanford.edu/wiki/index.php/Publications
もしかして、こっちで少し指導してる?
並列とDSLだね。(C++テンプレート使った奴が何年か前かなり流行ってた。最近はHaskellとかも)

451 :デフォルトの名無しさん:2011/11/12(土) 05:41:40.07
#xtend って結局Javaと #Scala の中間的言語だから Java->Scalaの道が
よりなだらかになったと考えるべきじゃね。だから Scalarはむしろ
xtendを大歓迎すべきだと思う。そしてxtendに新しい機能が追加される
度に「あーそれ2年前にやったわー」と言っておけばよい。
問題はむしろJavaがいつまでも使われ続けること。


452 :デフォルトの名無しさん:2011/11/12(土) 06:33:46.17
JVMで動く言語、に限らずだけど、スクリプト系の言語みたいに一ファイルだけデプロイして置き換えるだけでOKって出来ないのが辛い

453 :デフォルトの名無しさん:2011/11/12(土) 06:43:17.48
>>452 まともなスクリプト言語開発者なら、デプロイする前に
単体テストしたりコミットしたりするだろ?それを考えると
そこまで大差ないと思うんだが。

454 :デフォルトの名無しさん:2011/11/12(土) 06:52:33.30
s/スクリプト言語開発者/スクリプト言語を使う開発者/

455 :デフォルトの名無しさん:2011/11/12(土) 12:52:56.77
xtendがあればScalaが不要になるんだよね?

456 :デフォルトの名無しさん:2011/11/12(土) 13:50:53.98
gitからhotデプロイ出来る仕組みにしてみるとか?

457 :デフォルトの名無しさん:2011/11/12(土) 14:23:29.35
JRebelのscala lisenceのページが消えて、購入ページに飛びますな
http://sales.zeroturnaround.com/
変わりに非商用プロジェクト向けのJRebel Socialなるものが
https://social.jrebel.com/
そして、facebookかtwitterでログインしろとか

458 :デフォルトの名無しさん:2011/11/12(土) 22:11:01.67
テキストファイルの内容を丸ごと文字列に変換するライブラリ関数はありませんか?
今は,scala.io.Source.fromFile(file).getLinesで一行ずつ読みながらつなげていってますが、
どうも馬鹿げているので。

459 :デフォルトの名無しさん:2011/11/12(土) 22:17:49.01
mkString使え

460 :デフォルトの名無しさん:2011/11/16(水) 01:54:53.92
最近、whileで書いていたところは、大体Stream.iterateに置換できることを発見して、うひょーと思ったが
前スレを見たら余裕で紹介されてた

461 :デフォルトの名無しさん:2011/11/17(木) 07:30:00.45
Stream.iterateめちゃくちゃ遅い
forはwhileでガチガチに最適化するのがいい

462 :デフォルトの名無しさん:2011/11/18(金) 19:45:48.66
Javaのソースファイルが生成されるってのは予想以上に便利だな
ものすごく親和性が高い気がする

463 :デフォルトの名無しさん:2011/11/18(金) 21:44:24.30
http://twitter.com/#!/Isuzu_T/status/137495976599486465


464 :デフォルトの名無しさん:2011/11/19(土) 00:56:45.66
株式会社ドワンゴでも使っているみたいね。
http://live.nicovideo.jp/watch/lv71111927
ドワンゴ研究開発チャンネル

465 :デフォルトの名無しさん:2011/11/19(土) 04:47:49.82
非公開設定してるユーザーのツイート貼ってんじゃねえぞボケナス

466 :デフォルトの名無しさん:2011/11/19(土) 10:46:18.94
http://scan.netsecurity.ne.jp/article/img/2011/11/13/27625/93.html
tokuhirom、ma.la?っていう人の話だけ聞きたい
色々なスレで見かけるけどWEB業界で有名らしいね
動画ありませんか?

467 :デフォルトの名無しさん:2011/11/19(土) 11:39:12.14
貼られたときは公開してたよ

468 :デフォルトの名無しさん:2011/11/19(土) 12:10:04.06
>>464
なにこれ面白そうじゃん
タイムシフト予約したわ
あまり初心者向けにならないでほしい

469 :デフォルトの名無しさん:2011/11/20(日) 01:22:05.72
>>464
面白そうだな
ドワンゴのレベルを見させてもらおう

470 :デフォルトの名無しさん:2011/11/20(日) 11:13:49.83
会場がドワンゴなだけじゃないの

471 :デフォルトの名無しさん:2011/11/20(日) 14:02:51.62
発表スキルの落差がすさまじいな

472 :デフォルトの名無しさん:2011/11/20(日) 15:08:48.04
そら社内リソース+αだけじゃ裾野が狭すぎ。

473 :デフォルトの名無しさん:2011/11/20(日) 15:41:44.46
俺も度湾後入りたくなったわw
内容は初心者向けに平易なものにしてくれてたのかな

474 :デフォルトの名無しさん:2011/11/20(日) 15:43:50.07
これ平易じゃなかっただろw

475 :デフォルトの名無しさん:2011/11/20(日) 15:49:59.24
そうかな?

476 :デフォルトの名無しさん:2011/11/20(日) 20:25:13.99
javaのComparableインタフェースを実装したクラスC

public class C implements Comparable { ... }

のサブクラスをscalaで定義したいのですが、ここにある問題にぶつかってしまいました。
http://scala-programming-language.1934581.n4.nabble.com/extend-from-a-Java-class-interface-implementing-Comparable-without-type-parameters-in-2-8-0-x-td2258995.html

class D extends C {
def compareTo(other:AnyRef) : Int = 0
}

とやっても
class D needs to be abstract, since method compareTo in trait Comparable of type (x$1: T)Int
is not defined (Note that T does not match AnyRef)

というエラーになります。
なにか回避策はないでしょうか?

477 :デフォルトの名無しさん:2011/11/20(日) 20:26:31.02
ちなみにクラスCの実装はJavaのライブラリ内にあって修正はできない状態です。
できればscala側で何とかしたいのですが…

478 :デフォルトの名無しさん:2011/11/20(日) 21:08:29.88
Java側でcompareToをoverrideしないと無理かもしれぬ

479 :デフォルトの名無しさん:2011/11/20(日) 21:11:47.43
これ何でエラーが出てるの
型が違うのか
anyrefとobjectで

480 :デフォルトの名無しさん:2011/11/20(日) 22:31:57.43
>> 476

"Note that T does not match AnyRef"

っていうメッセージのとおり、compareToの引数の型がAnyRefではだめってだけじゃないの?

リンク先のメーリングリストの議論は、2.8のRCのときだからたまたまbugってたというだけで、関係なさそうだけれど

481 :デフォルトの名無しさん:2011/11/20(日) 22:43:50.37
ここを見ると、scala単体での回避は無理そうだね。

http://stackoverflow.com/questions/3329001/scala-class-cant-override-compare-method-from-java-interface-which-extends-java

482 :デフォルトの名無しさん:2011/11/21(月) 00:29:22.79
ドワンゴ入ればScalaやらせてもらえるらしい

483 :デフォルトの名無しさん:2011/11/21(月) 00:34:27.70
Scala書ける人を雇ってphpを書かせる
怖いお

484 :デフォルトの名無しさん:2011/11/21(月) 00:38:26.76
絶対Scalaなんてやってないだろ
そもそも人気高くて入れなさそうだけど

485 :デフォルトの名無しさん:2011/11/21(月) 00:50:39.16
今年新卒60人採用でしょ
景気のいい話さ

486 :デフォルトの名無しさん:2011/11/21(月) 01:26:05.89
しかしあそこに集まってた連中は流石に濃いメンツだったな
本当にニコニコかという感じだったw

487 :デフォルトの名無しさん:2011/11/21(月) 03:12:02.22
あぁいつものメンバーかって感じがしたわ

488 :デフォルトの名無しさん:2011/11/22(火) 08:25:06.61
ひろゆきもちょっと来てたらしいね。
さすが技術には力を入れているっていう感じだった。

489 :デフォルトの名無しさん:2011/11/22(火) 09:58:05.88
なにその胡散臭すぎる話

490 :デフォルトの名無しさん:2011/11/22(火) 10:01:14.69
いつものメンバーは一人病欠だろw

491 :デフォルトの名無しさん:2011/11/22(火) 23:14:37.57
>>490
病欠ですいませんorz

492 :デフォルトの名無しさん:2011/11/23(水) 01:04:25.68
今回のは、ニコ動本部の配信だけど、

草の根的なScala勉強会も、地方にストリーミングしてほしいなあ。

493 :デフォルトの名無しさん:2011/11/23(水) 01:08:30.57
渋谷のやつなら大体Ustしてるんじゃね

494 :デフォルトの名無しさん:2011/11/23(水) 01:30:16.47
http://www.scala-users.org/shibuya/index.php
これって毎週やってんでしょ?ネタなくならないの?
たまに録画みるけどすごいぐだぽよ〜な感じだよね

495 :デフォルトの名無しさん:2011/11/23(水) 01:56:03.09
今思うとscala東北の配信は最高に濃かったよな

496 :デフォルトの名無しさん:2011/11/23(水) 15:29:35.16
>>495
@ymnk さんというスーパーハカーの力あってのものでしたね…
あのクオリティを毎週維持できてたのはほんと凄いとしかいいようが無いです
震災の影響で休止になったままなのが残念

497 :デフォルトの名無しさん:2011/11/23(水) 18:01:37.76
コテつけろやエバンジェ!

498 : ◆CgacaMDhSQ :2011/11/23(水) 18:07:16.99
了解です。最近スレをあまり覗かなくなったのと、マシン環境変えたのでトリップ付けるの失念してました
いやまあ、たぶん発言の仕方でバレてる気もしますが。

499 :デフォルトの名無しさん:2011/11/23(水) 18:35:53.93
>>498
ついでに>476にも愛の手を

500 : ◆CgacaMDhSQ :2011/11/23(水) 18:59:13.55
>>499
ちょっとでかけるので、手短に言うと、>>476の問題はJava側でワークアラウンド用のJavaコード書くしかないです。
これは、ジェネリックなクラス/インタフェースの型パラメータ無し(raw type)をスーパータイプとして
Java側で継承したときに起きる、ややレアな問題で、当面は対処されないと思います。

501 :デフォルトの名無しさん:2011/11/23(水) 20:47:44.23
ttp://d.hatena.ne.jp/karasuyamatengu/20111122/1321978693
早速ヒロちゃんが来てる。このブログ主は訳してるだけだから・・・そっとしておいたげて。

502 :デフォルトの名無しさん:2011/11/23(水) 20:50:23.76
そこの元記事:
http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html
すでに、炎上してて、読む気が起こらん。FUD連呼厨をみてどこも同じだな。
とは思った。

503 :デフォルトの名無しさん:2011/11/23(水) 21:07:31.74
>476みたいなJavaとの相互運用上の落とし穴をまとめた資料ってどっかにないのかな

504 :デフォルトの名無しさん:2011/11/23(水) 21:13:13.09
>500

ありがとうございます。
Javaで接続用のクラスを作ることにします。

eclipseだとscalaとJavaを同一プロジェクトに共存させられないのが
こういうとき面倒ですね。

505 :デフォルトの名無しさん:2011/11/23(水) 22:00:40.96
>>501
そこのコメント欄、読みづらすぎw

506 :デフォルトの名無しさん:2011/11/23(水) 22:04:51.03
でもJodaTimeは俺も使ってるからショックだなあ
実はScalaTimeのしょぼラッピングぶりとか見て切れてたりして

507 :デフォルトの名無しさん:2011/11/24(木) 01:43:06.26
>>504
eclipseでScalaとJavaを同一プロジェクトに共存させることはできます(というかそれをするために、JDTがまともな拡張ポイントを提供してくれてない
せいで、ScalaのEclipseプラグインはかなり苦労してます)。単に、Javaパッケージ下に.scalaファイル置けばそれでOKです。

>>501
さすがに、ブログ主がその主張をしてるとは思ってません。日本語だけ見る人が訳のまとめ見て誤解したら
嫌だなあ、と思ってつい長文コメント書いてしまいました。ただ、そのブログ主にとっては迷惑だったかもしれませんし、今は反省してます…

>>506
自分も、JodaTimeは良い設計してると思うだけに、その作者がこんなに残念な(感情的な)書き散らしをするのだなあ、というのはちょっとショックでした。

508 : ◆CgacaMDhSQ :2011/11/24(木) 01:44:42.41
>>507は自分です(見ればわかるかとは思いますが)

509 :デフォルトの名無しさん:2011/11/24(木) 03:02:29.87
向こうは、営利的な部分でも感情的に振る舞う、ポジショントークは多い気はする(経営者っぽい?)
そして人間関係は別だったりする。
日本の技術者は、普段は公平性を重んじるから、会社の立場はあまり気にしないんだけど。
本当に好き嫌いでポジショントークしたり、論理的に装ったりする場合も多いから、イマイチ立場が判りづらい。


510 :デフォルトの名無しさん:2011/11/25(金) 11:36:00.48
この場合、scalaをこき下ろす営利ってなんだろうか?利害はなさそうに思うけどな。
ただ、感情的なものがあるとしたらコミュニティへの不信感はあらわにしてると思う。

仕様が複雑なものに柔軟性を加え用とすると、さらに仕様が複雑になって手に負えな
くなるというパターンは普通にあることだし、言ってることもわからないことではな
いかな。複雑にすればするほど、直交性も崩れやすいのも当然だしね。だから、
感情的なところと理性的な部分を含んだ内容と理解してるね。

511 : ◆CgacaMDhSQ :2011/11/25(金) 17:43:19.46
彼の場合、正直、Scala(コミュニティ?)嫌いが先にありきでそのために理由を作り出しているようにしか見えないのが問題
つーのは、彼の挙げてる例とかコメント見る限りで、Scalaをほとんど使った事が無い事がわかるので。 状況証拠は大体揃ってて

(1) ++ が java.util.List#addAll() と同じだという初歩的な勘違い
Scalaを使ってプログラムしたことがあれば、この程度の勘違いをするはずが無い
(++ は immutable collectionの連結で、 java.util.List#addAll()は、mutable listへの要素の追加)

(2) List(1, "foo") の結果型が List[Any] でコンパイルエラーにならないのが問題だと言っている
コンパイルエラーが検出されるタイミングがずれるという意味では全く問題ではないとは言わないけど、
少なくとも安全性の面で問題は無い(mutable listに要素を追加するのと勘違いしているのだろうと推測)

(3) Scalaのフレキシブルな構文のせいでコンパイラが遅いと言っている
本当の理由は、implicit searchのコスト + コンパイラのパス数の多さ
彼は、パージングにかかる時間が一般にコンパイル時間の多くを占めていないということすら知らない

(4) Scalaが言語レベルでimmutablityを強制できていない(ので、並行プログラミングで問題だ)という事をことさら問題視している
実際には、たとえばActorでmutable objectをわざわざ渡す奴は居ないし、海外Scala MLでもその手のトラブルは聞いたことが無い

(5) 空想のScalaコミュニティに対して反発している
型理論とかを知らない奴をけなしている、などと言っているが、実際にはそのような人物はコミュニティではほとんど居ない。
むしろ、そういう質問があったら、積極的に答えようとする人が多い(多すぎるくらい)。つまり、実際のScalaコミュニティ(特に公式
MLなどでの経験があったわけではないのは、ほとんど確実)

(6) Scalaを使用した経験から批判してるのか、そうでないのか、どっち?という質問を全スルー。

他にも色々あるのだけど、この辺で。要はScalaをまるで知らないのに、一知半解どころか一知すら無い状態でこきおろしてる、ってのが一連の
ポストとコメントでわかったのが収穫かな。で、誠実な部分含めて、都合の悪い指摘全スルーしてる辺り、確信的にやってる(FUD)とやはり俺は思う

512 : ◆CgacaMDhSQ :2011/11/25(金) 17:52:57.35
もちろん、Scalaには色々な問題があると俺は思う。

・実用的には重要な標準IOライブラリが中途半端なscala.ioしかない
・sbtという重要な基盤ツールの進化が速過ぎて、ドキュメントが追いついていない
・標準ライブラリのscaladocのドキュメンテーションコメントが少ない
・これは、コミュニティ内部でも問題視されてて、その結果、 http://docs.scala-lang.org/ が出来たわけだが。
・コンパイル遅い(sbtでだいぶ緩和される & 改善に向けて内部的にも色々進行中だけど)
・バージョン間バイナリ非互換性の問題(Typesafeが、この問題を解決するツールを開発してるみたいだが)

IDEはかなり良くなってきた(特にIntelliJは良い)ので、そっちの方の不満は少なくなってきたけど、もっと周辺ライブラリとの強調とか
標準IOライブラリへの取り組み(Scala-IOの支援とか)とかを積極的にやって欲しいな、という印象。言語自体は、もうちょい型推論
強化してくれたらな、というくらいで、不満はそれほど多く無いかな。

513 :デフォルトの名無しさん:2011/11/25(金) 18:01:25.62
sbtもclojureのleiningenほど使えるようになればいいのにね。

514 :デフォルトの名無しさん:2011/11/25(金) 18:07:14.44
マイナー言語が人気出てくると、貶すためだけの書き込みが
一時的に増えるのは、お局様が新人に切れるのと似てるな。

515 :デフォルトの名無しさん:2011/11/25(金) 18:33:08.63
FUDはなぁ。 http://ja.wikipedia.org/wiki/FUD
言語のことで、毛嫌いされてるといえば、lisperという立場から見ると
さんざんいろんな誤解を書き散らされてるけど、率直にいって、しゃーないなー
スルー。って感じが多いよ。中には、誤解に対して丁寧に答えてる人も
いるけど、よくあることさ。あんまり、FUDと捉えないほうがいいよ。
どんな話があっても流れてくる人はいるもんだ。

516 :デフォルトの名無しさん:2011/11/25(金) 19:29:32.73
そうそう、楽する方法を一つ。適当なよくある質問を集めて、FAQを
作ってみたら?あるんだったら、そこに新たな質問と答を逐次追加し
ていけばいいしね。いつも丁寧に答えてたら、時間がいくらあっても
大変だろうし、水嶋さんは見る限り周囲の空気にはやや鈍感なのかも
しれないけど、聡明な方みたいだしね。その行動力はすごいと思って
見てるよ。でも、この性質は時々頭のよい人に見られるものだからな。
それを、より建設的な方向に利用すればいいってことだと思う。あなた
位ならば、すでに、どこがよく誤解されやすくって、その誤解をどう
説明するかは察しがついてると思うんだよね。

FAQもどんな形式が読み手が楽かとなると1問1答1ページ+目次のほ
うが余裕があるかも。

517 :デフォルトの名無しさん:2011/11/25(金) 19:35:34.58
FAQを作って、いろんな誤解があるものをまた良くわからんとって批判しとる
と見てたらいいし、乗り込んで丁寧に答えるような労力もつかわなくても
よくできると思うよ。
いちいち論戦したり答えたりするより、言語を使ってこんなこともあんなことも
そんなこともできるって示していったほうが、腕利きさんのセンスを持った
人を獲得しやすいんじゃないかなと思うよ。
長くなったけど、ほな頑張ってね〜

518 : ◆CgacaMDhSQ :2011/11/26(土) 02:56:53.23
>>515
なるほど。少なくとも、FUDというワードを使うのは議論をややこしくする可能性が高いので、避けるべきかもしれない。
ただ、今回の場合は色々反論があった(自分は何もしていないというかコメント欄で馬脚を現しただけだが)おかげで、
彼の批判が実経験に基づかない空想上のものである事が明らかになったわけで、まあ反論することにも意義は
あるかなと。自分の質問へのレスポンス
http://blog.joda.org/2011/11/scala-ejb-2-feedback.html?showComment=1322218727885#c5182138328634130006
で、結局、彼は「俺はScalaの経験はほとんど無いが、Scalaが駄目だって事を判断できる(キリッ」とか言ってるだけの人
だって事が確定したので、もう怒る気持ちすら失せて呆れてる段階だけど。

>>516
ちょっと今回は色々大人げ無くて、みっとも無かったかもしれませんが、丁寧なアドバイスありがとうございます。
よくある誤解に関するFAQについては、仰る通りそろそろ用意すべきときかもしれませんね。
また、FAQの形式に関しても、1問1答1ページ+目次という構成は良さそうですね。その辺り含めて、
ちょっと検討してみます。

ちなみに、おっしゃる通り、自分はかなり空気が読めない方です(という自覚はあります)。聡明かどうかは自分では
どうにも判断できないですが。で、自分が聡明かはともかく、これまでのTwitterでのbot活動wによって、大量の疑問点に
対するリプライの蓄積があるので(twilogで読めます)、ある程度誤解やハマりパターンの傾向は把握している感じです。

>>517
応援ありがとうございます。確かに、誤解 or 曲解に対して、乗り込んで論戦するとかは結構労力使う
割に得るものが少ないという意味で、費用対効果が悪いですね。>>516さんのリプライでも書きましたが、
FAQをちょっとずつ書き溜めていきます。あとは、本家Scalaコミュニティに対してもっと貢献していきたい
ですね。今年になってからあまりバグレポートもできていないので。

519 :デフォルトの名無しさん:2011/11/26(土) 10:50:28.50
文章の長いコテハンって痛いの法則

520 :デフォルトの名無しさん:2011/11/26(土) 11:35:53.85
日本のScalaコミュニティが怖くて粘着質でウザイのは
まぎれも無い事実

521 :デフォルトの名無しさん:2011/11/26(土) 14:09:33.31
このスレでは、519,520 みたいなウザイの短文野郎が現れるけど、ゴミだね。
なんで、わざわざScalaのスレにきて、粘着するんだろうね?彼は。


>516とか>517
は自分も同意です。

>誤解 or 曲解に対して、乗り込んで論戦するとかは結構労力使う
>割に得るものが少ないという意味で、費用対効果が悪いですね。

見る側にとっても、この手の議論に飽きてきたところ。
章立てとかいらないから、どっかにFAQでまとめといて、って感じ。


そんなことより、Scalaの事例を増やしたいなあ。
最近だと、C#とかは Kinectやりたいって理由だけで C#人口増えている。
Scalaもそういうキラーアプリがないかなあ。

他、日常業務スクリプト集 とかあったらうれしい。本でたら買う。

522 :デフォルトの名無しさん:2011/11/26(土) 14:29:50.70
Scalaスレにウザくて粘着質な奴が張り付いているのは
まぎれも無い事実

523 :デフォルトの名無しさん:2011/11/26(土) 14:53:29.60
>>521
対抗してQUMA用API充実させるとか?

524 :デフォルトの名無しさん:2011/11/26(土) 15:36:43.61
Scalaの.net実装?が復活するって前に聞いた記憶があるかど今どうなってるのかしら?

525 : ◆CgacaMDhSQ :2011/11/26(土) 15:55:39.33
>>521
第二回Scala会議で、その辺りについてちょっと発表できるかもです>FAQでまとめ

Scala事例に関しては、国内だと細々とした利用は増えてるのですが、キラーアプリ
というのはまだ不在ですね。Play 2.0がTypesafe Stackのインストーラに統合される予定
なので、今までよりWebアプリをScalaで作りやすくはなるかもしれません。

>>524
.net実装自体はexperimentalですが既に動かせます。
http://lamp.epfl.ch/~magarcia/ScalaNET/2011Q2/PreviewScalaNET.pdf
にやり方が書いてあるので、参考までに。ちなみに、昔のScalaの.NET実装と違い、
今回復活したのはIKVMのランタイムを利用したものになっているため、手順が違うことに注意してください。

526 :デフォルトの名無しさん:2011/11/26(土) 16:27:50.38
あああ、引数の型とか再帰の返り値型を書かなきゃならんとはめんどくせえ!
なんで他の言語と同じように推測してくれないんだよ!

誰か、俺があきらめがつくように、型推定できない最小の反例を見せてくれ!

引数と返値の2パターンでよろしく。あとゴルフでな。

527 :デフォルトの名無しさん:2011/11/26(土) 22:35:27.03
def f(x,y) = x + y

とか

528 :デフォルトの名無しさん:2011/11/26(土) 23:26:50.27
>>527
そうそう、その問題も。
なんで他の関数型ではできるそれが、Scalaでは許されないようにデザインされたのか?も知りたい。

529 : ◆CgacaMDhSQ :2011/11/27(日) 00:00:00.30
>>526-528

まず、Scalaでは許されないようにデザインされた、というのは順序が逆、ということを念頭においてください。
ScalaはJavaの型システムをリファクタリングした上で拡張するという既定路線があって、その制約の元で
どこまで型推論できるのか、というのが問題になるわけです。

さて、

def f(x,y) = x + y
相当の関数が、何故ML系の言語では完全に推論できるのに、Scalaでは無理かというと、まず、"+"演算子の意味するところが
違うからです。たとえば、OCamlなら (+) の型は int -> int -> int なので、そこから x が Int, y がIntである事を容易に
推定することが(人力でも)できます。

一方で、Scalaでは、
def f(x,y) = x + y
における + は 式 x をレシーバとしたメソッド呼び出し (引数はy) になります。この時点でまず、+の型が不明である事に注意して
ください。この時点で、fは多相関数として推論しなければいけません(たとえば、Int同士の+だとみなすと、他の型に適用できなくなる)。
さて、この定義のx, yおよび x + y にどのような型を割り当てるべきでしょうか?
ひとつの方法として、

def f[T <: { def +(other: T): T }](x: T, y: T) = x + y

という方向が考えられます。しかし、以下のように別の推論を行うことも可能です。

def f[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y

さて、このどちら(他の推論候補もありますが、とりあえず2種類で考えて見ます)。少し考えればわかるのですが、
これはどちらが正解である(より一般的な型を推論している)とも言うことができません。MLのHM型システムの
元では、一切の型注釈無しに、完全かつ健全に、関数の「もっとも一般的な型」を推論できる事が保証されて
いますが、Scalaの型システム上では、それは「原理的に」無理なようになっています。この辺りはScalaが
サブタイピングを持っている事などと関係があるのですが、その辺りは長くなるのでこの辺りで。

530 : ◆CgacaMDhSQ :2011/11/27(日) 00:01:55.84
捕捉ですが、説明の都合上、
def f[T <: { def +(other: T): T }](x: T, y: T) = x + y
というScalaの関数を定義してみましたが、現在のScalaのstructural typeの実装制約上、これはコンパイルを通りません。
通りませんが、この制約が緩められて、上のように書けたとしても、Scalaの型システム上での型推論は単純なものですら
かなり難しくなりえます。

531 :デフォルトの名無しさん:2011/11/27(日) 00:06:56.06
>>507
> eclipseでScalaとJavaを同一プロジェクトに共存させることはできます(というかそれをするために、JDTがまともな拡張ポイントを提供してくれてない
> せいで、ScalaのEclipseプラグインはかなり苦労してます)。単に、Javaパッケージ下に.scalaファイル置けばそれでOKです。

これ、scalaプロジェクトの下にJavaパッケージ作って、その下にJavaクラスを置いたのでは駄目なんだね。
scalaソースからJavaパッケージのJavaクラスを参照しても見つけてくれない。


532 : ◆CgacaMDhSQ :2011/11/27(日) 01:12:09.41
>>531
うーん。こちらの環境では、その方法で普通に使えましたけど…。ひょっとして、JavaエディタからScalaオブジェクトのメソッド
補完などが効きにくい事を仰っている?

533 :デフォルトの名無しさん:2011/11/27(日) 08:06:48.58
>>532
いや、コンパイルエラー(エディタ上でエラーマーカーがつく)になります。
きっと微妙な落とし穴があるのでしょう。
scalaプラグインの完成度は余り高くないので。

534 :デフォルトの名無しさん:2011/11/27(日) 08:48:59.45
>> 529,530
ありがと!

>> 529
前者のfと後者のfを比べると、「より一般的な型を推論している」という
意味では、明らかに後者の方がより一般的だけど?
それとも「一般的な型」の意味に齟齬がある?
日本語だと曖昧になるなら英語でも大丈夫すよ。

さらに、一般的な型という意味なら、こちらの方が。

def f[T <: { def +[U,V](other: U): V }](x: T, y: U) = x + y

これでFAでいいじゃん。
でも、Scalaはこれは許されないし、
許さないようにしているのは理由があるんだよね?それが知りたい。

>> 530
> Scalaの型システム上での型推論は単純なものですらかなり難しくなりえます。

そりゃ、探索空間が増えるから、比較すると難しいのは自明だけど、
「かなり」って主観的だし、もう一声!

実際のところ、どれくらい難しいの?

(a) 一般的なコーディングでも推論不可能なケースが多い
(b) 一般的なコーディングでは推論不可能なケースはまれだが存在する
(c) すべての推論可能だけどコンパイラ性能的に計算量が実用的でない
(d) すべての推論可能だけどコンパイルが実用範囲内で遅くなる
(e) すべての推論可能でコンパイル時間も問題無し

535 :(1) ◆CgacaMDhSQ :2011/11/27(日) 10:19:16.01
>>534
おそらく、「より一般的な型を推論している」という言葉の使い方に齟齬があるかと思います
ここで、自分が「より一般的である」といっているのはメソッドシグニチャの包含関係がある
かどうかをさしています。

たとえば、次のfの推論と

(1) def f1(x: Int, y: Int): Int = x + y

以下の多相的なfの推論を比較したとき、

(2) def f2[T <: { def +(other: T): T }](x: T, y: T): X = x + y

(2)は(1)に比べて、「より一般的な型」を推論しているといえます。これは、
全ての式 x: X, y: Y について、f1(x, y) が型チェックを通るならば、f2(x, y) も型チェックを通るからです。
さて、次に

(3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y

と(2)を同様に比較してみます。結論から言うと、(2)では型チェックを通るが、(3)では
型チェックを通らない例が存在します。たとえば、x: Int, y: Intのとき、

f2(x, y) は 型チェックを通りますが、 f3(x, y) は型チェックを通りません。この理由は、必要であれば別のレスで述べますが、
ともあれそのような意味で、(3)は(2)より「一般的ではない」という事ができます。ここで、HM型システム
の元では、型付け可能な関数について、かならず「もっとも一般的な型」(principal typeと呼ばれます)
を推論することができる事が保証されており、推論結果の「正しさ」が保証されます。しかし、Scalaの
型システムではprincipal typeが存在しないので、そのような保証がありません。



536 :(2) ◆CgacaMDhSQ :2011/11/27(日) 10:28:15.64
>>535
> 実際のところ、どれくらい難しいの?
前提として、推論が可能かと言えば「可能」です(推論結果の正しさや実用性を問わなければ)。
しかし、仰っているのは、そのような型推論システムでは無いでしょうから、それを前提
として答えると、答えは (a) になります。実際のところ、もうちょっと答えは複雑で、principal type
は推論できないけど、「大体のケースで正しくなりそうな」型推論を多くのケースで行えるアルゴリズムを
Scala上の型システムに構築できる可能性はあります。しかし、仮にできたとしても、それは理論上の
保証が無い(少なくとも簡単に保証できない)ので、HM型システムの型推論のような「安心感」を得ることは
できないでしょう。

537 :デフォルトの名無しさん:2011/11/27(日) 10:59:10.98
>>535
> 必要であれば別のレスで述べますが、

ぷりーず。そこが議論の本質な気がする。

あと、(2)と(3)はそれで正しい?

538 : ◆CgacaMDhSQ :2011/11/27(日) 12:32:56.22
>>537
おーけーです。これから述べます。の前に
> あと、(2)と(3)はそれで正しい?
はい。それで正しいです(少なくともScalaにおいて) 。

さて、その理由が議論の本質、ということなので以下に理由を述べます。先ほどは、
> (3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: U) = x + y
に対して、f3(100, 200) のような式が型チェックを通らないということを書きました。
ここで、問題になるのは、Intの+のシグニチャが(オーバーロードバージョンを無視したとして)、
(Int)Int
であるのに対して、(3)で、structural typeによって要求されているシグニチャは
[U >: T](U)U
であることです(ちなみに、これはScalaにおける「メソッド型」の表記法です)。この二つの
メソッドシグニチャ(というより、非ジェネリックメソッドとジェネリックメソッド一般に)には
互換性が無いので、型チェックを通りません。一方、(2)の場合、structural typeによって要求されるシグニチャは
(T)T
になります。ポイントは、(2)の場合、「+そのもの」は多相メソッドではないので、T = Intとしてインスタンス化されている
場合、
(Int)Int
になり、(1)のケースを包含することです。長くなりましたが、一言で理由を述べるなら、「非多相メソッド」と「多相メソッド」の
シグニチャの間には互換性が成立しない、ということが根本的な問題です。

539 :デフォルトの名無しさん:2011/11/27(日) 13:41:49.74
>>531
ナイトリービルドやRCを使ってるから違うかも。
それからプロジェクトのクリーンで再ビルドすると見えるようになることもある。

540 :デフォルトの名無しさん:2011/11/27(日) 17:49:58.02
>>518
ttp://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/script-lang
読んでみたらいいよ。

541 :デフォルトの名無しさん:2011/11/27(日) 21:06:15.99
>>540
もくじ付けて

542 :デフォルトの名無しさん:2011/11/28(月) 12:21:00.07
Scalaは新しいEJB 2か
http://www.infoq.com/jp/news/2011/11/scala-ejb2

543 :デフォルトの名無しさん:2011/11/28(月) 12:40:50.00
静的型付け言語全体の評価を下げているって部分は論理がよく分からんな。
他はまぁうん、問題提起としてはいいんじゃないかというのが初心者の俺の感想。

544 :デフォルトの名無しさん:2011/11/28(月) 13:05:42.25
>>543
関数型言語として一番最初にscalaに遭遇すると、型宣言の仰々しさを
一番感じて、敬遠するだろう。これが型システムの複雑さなんだが、
適当な例は少し上の水嶋さんのコメントからも分かるだろう。
この複雑さが初めての人にとって静的型付け関数言語ってと頭の中で
一般化してしまうことがある。(どれだけかわからない。)→静的型
付け関数型はとても複雑で、頭のいい人しかわからない。使えない。
→他人との話題でそんな話になる。→静的型付け関数型の評判が落ち
る。という流れになることを指してる<その論理。
関数型を学習するのにscalaからはいるのは不適当だとは思うが、ここ
の人の多くは異論を持つだろう。
scalaの作者ってむかしpizzaって言語を作ってたんだね?Haskellの
本を読んで知った。

545 :デフォルトの名無しさん:2011/11/28(月) 13:44:25.76
いや、ScalaをやるならまずJavaとHaskellをマスターしてから来いと再三言ってるが、実践してる人は少ないだろう

546 :デフォルトの名無しさん:2011/11/28(月) 13:52:46.07
自分はまずSchemeから入ってOCaml→Haskell・Scalaと流れたから、割とすんなり関数型を理解できたなあ。
強い静的な関数型の入門はOCamlがいいんではなかろうか。
ちなみにJavaは全くできない。

547 :デフォルトの名無しさん:2011/11/28(月) 20:57:36.17
>>545
そんなこと言ってるから複雑だとかコミュニティがとかになるんだろ

548 :デフォルトの名無しさん:2011/11/28(月) 21:48:07.58
だからScalaはオブジェクト指向と関数型を掛け合わせたくらいの複雑さはあるし、
関数型を学ぶなら専用の関数型言語で学んだほうがいいって言ってるだけなんだけどな
Scalaの標準ライブラリのソースは関数型っぽく書かれてないしね

549 :デフォルトの名無しさん:2011/11/28(月) 22:28:09.07
Scalaは新しいEJB 2か
http://www.infoq.com/jp/news/2011/11/scala-ejb2

550 :デフォルトの名無しさん:2011/11/28(月) 22:29:28.20
しつこい

551 :デフォルトの名無しさん:2011/11/28(月) 23:09:26.99
ここは天丼に行くべきか?

552 :デフォルトの名無しさん:2011/11/28(月) 23:20:14.59
549

また、いつもの粘着野郎かな?

言語の比較の話はもう飽きた。


そんなことより、おまいら、Scalaで何作る?



553 :デフォルトの名無しさん:2011/11/28(月) 23:28:09.36
JVMに足りないのはlikeが付いてるあたりか。

groovy(ほか) ←→ clojure
==================
java → C#-like
==================
scala
==================
sml/haskell-like


554 :デフォルトの名無しさん:2011/11/29(火) 09:11:36.22
>>549
これ読んだら別にscalaじゃなくても
javaのままでいいや
と思ってしまう。

555 :デフォルトの名無しさん:2011/11/29(火) 10:31:57.57
えーscalaじゃないと思っても、Fantom、Kotlin、Groovy、Ceylonを気になれよw、javaでいいのかよ

556 :デフォルトの名無しさん:2011/11/29(火) 11:27:53.35
>>555
結局商用とかでつかわれない
趣味レベルだし、
やがてjavaでもできるようになる
機能しかもってないから
javaのみに注力すればよいのでは?

557 :デフォルトの名無しさん:2011/11/29(火) 12:00:34.81
新しいの勉強したくないわーって正直に言えばいいと思う

558 :デフォルトの名無しさん:2011/11/29(火) 14:26:00.92
>>557
釣りかもしれないけど
勉強したいけど時間を無駄にしたくないだけだよ。優先度を考えてるだけ。
どうせ勉強するなら実用的で
業務にもつかえるものにしたい。
でも既存の技術にしがみつかないで
将来有効な技術なら勉強したい。
1997年くらいにjavaを勉強
しはじめて後悔してない。
Androidの公式開発にもつかえるし
サーバサイトのデファクトだ。
15年後scalaがそのような地位を
気づけているか気にしてるだけだよ。

559 :デフォルトの名無しさん:2011/11/29(火) 14:31:26.42
釣りかもしれないけどw

560 :デフォルトの名無しさん:2011/11/29(火) 14:43:22.35
558さんの先見性ぱねえっす

561 :デフォルトの名無しさん:2011/11/29(火) 14:56:59.72
ソッカー、さすがに15年後scalaがどうとか誰にもまったくワカンないと思うわー
558さんが15年後でもscalaおkって感じ取れたらまたこのスレに遊びにきてねー

562 :デフォルトの名無しさん:2011/11/29(火) 15:39:37.96
基礎と実用ってよくトピックになるが、
実用という言葉ってけっこうマジックだからなぁ。
基礎を強くしようとしてる人は、いわゆる 土方への道は進まなくてもいいけど
基礎がない人は 。。。 ね。この話しとは違うことだけど。

scalaが15年後どうなるかって?ちょっと考えてみればいいよ。あれだけ、
複雑な仕様だってことを考えると、5年先には別のものがはやってると考
えてしまうよね。今がピークで2,3年で傾くように思うよ。
現に、javavmのライバルは増えてる。

むしろ、変化についていけるようにしておくほうが賢そうに思うけどな。
言語なんて、似たものが増えた所で学習コストは余り変わらないのでね。
Lisp族、CやJava族、ML族 この辺をおさえておいたらどれでもこいにな
れるだろう。

15年後はまさかのSmalltalkの天下だったりしてな。もともと近未来
志向言語だったからな。

563 :デフォルトの名無しさん:2011/11/29(火) 15:54:37.55
数ヶ月後、そこにはSmalltalkを勉強する558さんの姿が!

564 :デフォルトの名無しさん:2011/11/29(火) 16:02:15.66
おれは558ではないが、
おまえら強がってるけど
結局scalaはそのうち廃れるんじゃね?
ってのには反論できねーんだな。
廃れるかもしれないけどそんなの
わかんないじゃんみたいな思考停止が招いた事故

565 :デフォルトの名無しさん:2011/11/29(火) 16:07:48.72
実用がマジックワードだとしても、LispやMLの仕事なんてほとんどないでしょ
仕事で使えるかもしれない関数型言語というのは大きい

566 :デフォルトの名無しさん:2011/11/29(火) 16:20:41.01
まあでも実際廃れるかどうかはマジでわからんし562の言うとおりいろんな言語触っとくといいよねってのは同意するよ
その中にscalaも混ぜておくとおもしろいと思うわー

567 :デフォルトの名無しさん:2011/11/29(火) 16:44:09.05
>>565
それがね。。。基礎云々と言った理由なんだよ。動的の他の言語やるにしても
その他にしても、多くのアイデアや技術は、そこから流れてくるから新言語で
突拍子もなく新しいものを触るより学習を助けるってことからなんだよ。「
あっ、あの考えを使ってるのか。」ってわけ。

多分、scalaを触り続けて、scalaの複雑さに苛立った人が、また別の言語
を作るみたいなながれになるような気もする。scala△ だとか w 出てく
るかも。

scalaはここ2,3年が勝負さ。その間にキラーを作って無いとね。頑張り
なよscalaの諸君!

568 :デフォルトの名無しさん:2011/11/29(火) 16:52:35.95
>>567
ちょっと何を言ってるのかわからないけど、
Scalaをやってる人が他の言語を知らないという前提なら間違っていると思うが

569 :デフォルトの名無しさん:2011/11/29(火) 16:58:03.90
まとめるとscala△てことか

570 :デフォルトの名無しさん:2011/11/29(火) 19:04:55.82
まとめるとscala(笑)ってことか

571 :デフォルトの名無しさん:2011/11/29(火) 19:12:23.85
興味のある言語を好きなだけ何個でも弄ればいいじゃん

572 :デフォルトの名無しさん:2011/11/29(火) 19:15:20.25
Scala ▼0.13%

573 :デフォルトの名無しさん:2011/11/29(火) 19:17:49.27
なんか新しい言語でまわりを出し抜いてみたかったんだよ。
変身願望なのかな、これって。

574 :デフォルトの名無しさん:2011/11/29(火) 20:42:35.54
正直「仕事で使えるかもしれない(静的型付けの)関数型言語」という点でScalaには期待してる
もっとJavaっぽい言語に偽装して騙す感じでマーケティングして欲しい

575 :デフォルトの名無しさん:2011/11/29(火) 21:44:17.15
スレのメイン話題で盛り上がっているところで流れをぶった切ってスマン。

>>538

(T)T が (Int)Int を包含するのは異論なし。
しかし、[U >: T](U)U が (Int)Int を包含しないのは納得いかない。

> 長くなりましたが、一言で理由を述べるなら、「非多相メソッド」と「多相
> メソッド」のシグニチャの間には互換性が成立しない、ということが根本的
> な問題です。

(T)T と [U >: T](U)U が互換性が無いのも異論なし。
だって [U >: T](U)U ⊇ (T)T なのは自明だから。
んで、(T)T ⊇ Int(Int) なのだから、
[U >: T](U)U ⊇ (T)T ⊇ Int(Int) になるよね。
だから、[U >: T](U)U は (Int)Int を包含するじゃん?


あと、もう一度聞くけど、>>535の(2)と(3)はそれで正しい?
大文字のXが未定義とか、Uが[]の中に含まれていないとか、
Scalaは+メソッドに交換法則を強制していないから

def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y

の方が一般的とか、気になる点が3点もあるんだけれど。

576 :デフォルトの名無しさん:2011/11/29(火) 22:28:34.02
>575のような礼儀知らずに真摯に答え続ける水嶋さんを尊敬

577 :デフォルトの名無しさん:2011/11/29(火) 23:08:12.48
そう思っているのはあなただけだよ
水嶋さんはこういうネチネチした議論大好物だよ

578 :デフォルトの名無しさん:2011/11/30(水) 00:06:09.22
議論って本来、ねちっこさはあるよ。
それを避けて陰口を叩くだけの人多いけどな。

579 : ◆CgacaMDhSQ :2011/11/30(水) 00:16:45.87
>>575
疑問にお答えする前に、まずは私のミスについて訂正を
> 大文字のXが未定義とか、Uが[]の中に含まれていないとか、
これは自分の単純ミスですね。確認が不足していて申し訳ないです。
正しくは、
(2) def f2[T <: { def +(other: T): T }](x: T, y: T): T = x + y
(3) def f3[T <: { def +[U >: T](other: U): U }](x: T, y: T) = x + y
です。ご指摘ありがとうございます((2)は、そもそも現在のscalaではどの道コンパイルを通らないですが)。

> (T)T と [U >: T](U)U が互換性が無いのも異論なし。
> だって [U >: T](U)U ⊇ (T)T なのは自明だから。

「 [U >: T](U)U ⊇ (T)T」という前提に問題があります。これは全く自明では無いどころか、
「 [U >: T](U)U ⊇ (T)T」は一般に成立しません。ここで、TがUと同様に多相的っぽく見えるから
話がややこしくなるので、T に Int を代入して(インスタンス化して)考えてみます。すると、
[U >: Int](U)U ⊇ (Int)Int が成り立つか、という話になります(Uはメソッド適用までインスタンス
化されない点が重要です)。で、おそらくおわかりかと思うのですが、これは成り立ちません
(リスコフの置換原則を思い出してください)。というわけで、それを前提にした
> だから、[U >: T](U)U は (Int)Int を包含するじゃん?
という結論も正しくありません。とりあえず、また疑問があれば言ってくださればと思います。

なお、
> def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y
の方が一般的というのは、技術的に誤りです。説明が若干ややこしいので、
一般的だと考えられた根拠を述べていただけると解説しやすくなります。

580 :デフォルトの名無しさん:2011/11/30(水) 00:18:14.17
この兄ちゃんもよくやるなあ

581 : ◆CgacaMDhSQ :2011/11/30(水) 00:19:38.14
>>576
そのように評価していただけるのはありがたいのですが、真実は
>>577が近いです。ねちっこいかどうかはともかく、技術的な議論自体が好物なのは確かなので。
ちなみに、あえて訂正しなかったのですが、s/嶋/島/です。いや、別に不快なわけではないのすが。

582 :デフォルトの名無しさん:2011/11/30(水) 00:51:28.65
◆CgacaMDhSQ 氏は、せっかく能力あるんだから、もっと他のことに使ってほしいなあ。

とりあえず、10月ころのScalaのアップデートのスライドをたまたまWebで見たけど、
あれ、なかなか良かったです。

結局、プログラム言語の良し悪しは、どんだけその言語を使う人が居るか、プログラマーの数って重要だと思う。
プログラマーが増えるには、最近では、ライブラリーとか使用例とか、ググったらやりたいことが見つかるか
とかそういうのが重要。

Scalaでググると、言語の話ばっかりなのが、最近、飽き飽きしてきた。


Scalaは、まだまだ基本ライブラリが足りないよね。。

ちょっと今、CSVからデータ抜き出す方法をしらべてて、
たまたま次のページ見たのだけど、RubyやGroobyに比べて、ちょっと面倒なのが残念。
http://d.hatena.ne.jp/fits/20101129/1291043635



583 : ◆CgacaMDhSQ :2011/11/30(水) 01:09:06.42
>>582

> あれ、なかなか良かったです。
関数プログラミングの集いの時のやつでしょうか?そう言っていただけるとありがたいです。

> Scalaでググると、言語の話ばっかり
海外を見渡すと、色々新しいフレームワークの話とか話題になってたりするんですが、国内だと
まだ言語の話が多いですね…

> プログラマーが増えるには、最近では、ライブラリーとか使用例とか、ググったらやりたいことが見つかるか
> とかそういうのが重要。
> (snip)
> Scalaは、まだまだ基本ライブラリが足りないよね。。
賛成です。Scalaは、標準ライブラリがあまりにも偏っている点が「実用的な」問題だと考えています。
# 特に、よく書いてますが、腐ったscala.ioはなんとかならないものかと思っています。Scala-IOは
# いつ取り込まれるのかわからんですし…
で、(本家) Scalaのコミュニティの問題の一つは、そういう実用的なライブラリを標準に取り込む動きが
遅い点にあるのではないかと。言語としてはともかく、そういう標準ライブラリの取り込みに
関してはGroovyの方が先に行っている印象です。

584 :デフォルトの名無しさん:2011/11/30(水) 01:40:10.27
Iterator.continuallyを見て、便利だと思うか、面倒だと思うかでScalaを使う資質が分かれると思うね

585 :デフォルトの名無しさん:2011/11/30(水) 02:21:38.85
15年後も、なんていってたら情報系黒板言語しか選択肢がないぞw
もっとも、最近のMITのオープンクラスを眺めてみれば、
RoRを使ってウェブアプリ作る講義があったりで、
黒板に書かれる言語すらも徐々に変化しているみたいだわ

ソフトウェアに永遠の命なんて戯けたことを抜かすなら、
FSFの信仰者になってGPLでソフトウェアを配布するしかないぞ

586 :デフォルトの名無しさん:2011/11/30(水) 02:32:51.75
MITでRailsやってんの?イメージに合わない…

587 :デフォルトの名無しさん:2011/11/30(水) 02:35:24.42
寿命だけで言えばプログラミング言語なんてめちゃくちゃ寿命長いからね
ScalaよりJVMの寿命を心配したほうが良さそうだ

588 :デフォルトの名無しさん:2011/11/30(水) 12:38:13.26
>>587
Delphiの寿命は長かったといえる?

589 :デフォルトの名無しさん:2011/11/30(水) 16:28:59.72
Yammer.comがScalaからJavaに戻したそうな。
理由とかはまだ調べられてないけど。

590 :デフォルトの名無しさん:2011/11/30(水) 16:41:26.98
http://codahale.com/downloads/email-to-donald.txt

591 : ◆CgacaMDhSQ :2011/11/30(水) 18:32:48.66
>>589
>>590のURLと一緒に、その背景
http://codahale.com/the-rest-of-the-story/
も読むといいかもです。わかりやすいように時系列で整理すると、
(1) Yammerのエンジニアの人(@coda)が、昔の同僚(Twitter時代)に、Scalaの一部をJavaに置き換えてるとメンション飛ばす
(2) それを見た Donald Fischer (現Typesafe CEO。 Odersky先生は現在チーフアーキテクト) が、数日語、@codaに、詳細を聞きたい
旨のメール出す(CCにOdersky先生が入っていた)
(3) @codaは、Scalaの改善に関われる中心的な人物がそういうメールを送ってきた、ということで、Scalaの経験からどんな問題があった
かを Donald Fischer にリプライ(CC: Odersky)。このやり取りはprivateなものだった。
(4) @codaは、e-mailのドラフトをgistに置いていたので、それがHacker NewsやTwitterに流出
(5) しまった、と気づいた@codaがあわててgistを削除するも時既に遅く、publicに
(6) @jodastephen はそれが流出したものだという事を知らずにYammerが公式にアナウンスしたとブログに掲載
(7) @coda -> @jodastephen 「ちょw それ、Yammerの公式アナウンスじゃなくて、それ、俺の個人的見解だから」
(8) @jodastephen のポストの影響でTwitterなどあちこちでその話が飛び交う
(9) @code が http://codahale.com/downloads/email-to-donald.txt のコンテキストを釈明 (イマココ)

592 : ◆CgacaMDhSQ :2011/11/30(水) 18:46:29.97
まあ、流出情報ということはともかく、 http://codahale.com/downloads/email-to-donald.txt
に書かれている事自体は(書かれたコンテキストを踏まえる必要があるにせよ) @jodastephen
の記事とは異なり、読む価値があると思います。私が彼のメールで特に重要だと思ったのは

(a) Scalaの学習曲線の問題(特に、チームメンバにどうやってScalaのコンセプトを教育するか)
(b) sbt 0.7系 -> sbt 0.10移行に伴う問題
(b) Scalaのバージョン間のバイナリ非互換性問題

辺りでしょうか。彼自身がそれほど重要な問題ではない、と書いている通り、scala.collection.{mutable, immutable}
がどうとかの話は、まあパフォーマンス特性を踏まえてコレクションを使いましょうね、という話で、場合によっては
彼の書いたような指針に従ってチューニングするのもありかもしれませんが、Scalaに関する一般論としてはあまり
重要ではないでしょう。

ただ、私も原文読んだ中から、特に重要だと思った部分を抜き出しただけなので、実際の所は原文読んだ方がよかろうと思います。

593 :デフォルトの名無しさん:2011/11/30(水) 22:14:03.98
技術的な問題もあるが、In addition toからの3パラグラフもなぁ

594 :デフォルトの名無しさん:2011/11/30(水) 22:16:13.04
釜本さん…

595 :デフォルトの名無しさん:2011/11/30(水) 23:18:26.31
@codeはたぶん消されるなw


596 : ◆CgacaMDhSQ :2011/12/01(木) 00:50:14.69
>>593
コミュニティの話については、まあ、scalazコミュニティの一部の人とOdersky先生がひと悶着あったとか
そういう事実はあったりします。scalaz自体は私は好きなんですが、過激な人が一部に居るという話はあって、
そういう人の声が目立ってしまうという側面はありますね…。

ちなみに、パフォーマンスについて言えば、端的に@codaのやり方はエンジニアリング的に(Scala以前の問題で)
間違っているんじゃ?というのが正直な感想です。実際、java.util.HashMapよりscala.collection.mutable.HashMap
が遅いという事実は正しいです。が、実測してみればわかるように、実際には最大で3倍くらいの差で(OpenHashMapだと
java.util.HashMapとほぼ同じ速度だったりする)、チューニングする必要があるとして、パフォーマンスにクリティカルな部分
のみを置き換えるというアプローチが技術的には正しいでしょう(それよりはるかに遅いLL言語のいわゆる「ハッシュ」が
普通に使われている事を考えてください)。ボトルネックを考えずに片っ端からwhileに置き換えるとかそういうチューニングする
ルールを導入するのは、あまり筋が良いとは言えないです。これは、技術的な観点からの感想で、YammerがJavaに
戻した事についてどうこう言うつもりは無いですが。

この辺りのチューニングの話については、現Typesafe(元Google)のJosh Suerethのブログ記事
「Macro vs. Micro Optimisation」
http://suereth.blogspot.com/2011/11/macro-vs-micro-optimisation.html
が参考になるかと。

597 :デフォルトの名無しさん:2011/12/01(木) 03:48:30.31
皆どうやってそんなに詳しくなれるんだ
自信無くすぜ

598 :デフォルトの名無しさん:2011/12/01(木) 04:54:40.41
Javaのプロファイラは余りいいものがないなあ。
キャッシュミスとか取れないし。

eclipseよりNETBeansの方がまだましか。

599 :デフォルトの名無しさん:2011/12/01(木) 09:47:56.93
>>597
なーにが自信だw
このアマチュアがw

600 :デフォルトの名無しさん:2011/12/01(木) 11:08:53.39
>>599
おまえ最低なやつだな。最低だ。

601 :デフォルトの名無しさん:2011/12/01(木) 12:23:04.34
思ったことより大したこと無かった。が多いと思って突き進め。
学習曲線や効率のいい資料の探し方は重要かも。

602 :デフォルトの名無しさん:2011/12/01(木) 14:40:14.48
fantomの方が良い言語なんだろうか

603 :デフォルトの名無しさん:2011/12/01(木) 15:20:16.70
>>602
「良い」の定義にもよるが。

604 :デフォルトの名無しさん:2011/12/01(木) 16:10:15.69
scala出来ますって言ったら内定もらえました!
一昔前のスマホ持ってるアピールみたいですね!

605 :デフォルトの名無しさん:2011/12/01(木) 17:25:48.48
おかしいな
三年くらいScalaやってるのに一向に職が見つからないのだが

606 :デフォルトの名無しさん:2011/12/01(木) 18:44:26.06
すっからかん

607 :デフォルトの名無しさん:2011/12/01(木) 20:59:44.57
Scalaを叩いてる人が引き合いに出した言語ってのは確かに気に
なるところではあるが、マイナーだからいろいろまだ足りないんだろうな

608 :デフォルトの名無しさん:2011/12/01(木) 21:01:55.18
>>605
つ 現実
http://www.dreamnews.jp/?action_Image=1&p=0000027847&id=bodyimage1

609 :デフォルトの名無しさん:2011/12/01(木) 21:10:31.28
cがやたらと需要高いみたいだがどこで使われてるんだろ

610 :デフォルトの名無しさん:2011/12/01(木) 21:16:40.93
組み込みとかデジタル家電とかじゃないかな
メーカー中心だし給料良さそう

611 :デフォルトの名無しさん:2011/12/02(金) 05:36:56.16
>>579
> [U >: Int](U)U ⊇ (Int)Int が成り立つか、という話になります(Uはメソッド
> 適用までインスタンス化されない点が重要です)。で、おそらくおわかりかと思う
> のですが、これは成り立ちません(リスコフの置換原則を思い出してください)。

なるほど。齟齬の原因が判った。

(a) [U >: Int] (U)U で表現可能な関数型の集合には(Int)Intを含む
(b) [U >: Int] (U)U で表現可能な関数型の集合には(Int)Intを受理しないものがある
は両方とも真。
俺は(a)を指して [U >: Int] (U)U ⊇ (Int)Int が成り立つと言っているのだが、
◆CgacaMDhSQさんは(b)を指して [U >: Int] (U)U ⊇ (Int)Int が
成り立たないと書いているらしい。つまり、[U >: Int] (U)U は (Int)Int の
Liskov substituion principleにおけるsubtypeではないことを書いているのだろう。

それには異論無し。
俺ならtype orderを表す時は⊇でなく≧を使うので、混乱した。申し訳ない。

齟齬が生じた原因は、想定した型推論のアプローチの違いだろう。

俺が想定していたのは、Cartesian Product Algorithm (CPA)のような、解候補集合の
うち制約充足解を選び出すconstraint-based analysisの方。だから、解は多数の
型の集合の中から制約で1つに絞れればいい。なので、(a)でOKという立場。

◆CgacaMDhSQさんはprincipal typeをunification-basedで求めたいので、
(ひとつの)解候補が無矛盾かどうかが興味の対象だと推測する。
だから、(b)なのでダメという立場。(正しい?)

ちなみに、constraint-based analysisアプローチは、
Demand-Driven Analysis with Goal Pruning (DDP)の提案者が
現在Scalaに適用チャレンジ中とのこと。
それ以上は知らないので、詳しい人がいたら教えてほしい。

612 :デフォルトの名無しさん:2011/12/02(金) 05:44:33.60
>>579
長いので分割。

> > def f[T <: { def +[U,V](other: U): V }, U, V](x: T, y: U) = x + y
> の方が一般的というのは、技術的に誤りです。説明が若干ややこしいので、
> 一般的だと考えられた根拠を述べていただけると解説しやすくなります。

「一般的かどうか」については>>611で齟齬があったことが判ったので、落着。

残る点は、クラスAに、型(B)Cの+メソッドがあったとして、
def f(x, y) = x + y
というfの定義があって、これが
f(new A, new B)
を受理するためには、xとyが同じ型である訳にはいかないよね、
という単純な話。

# Scalaの言語仕様では、+には結合優先順序しか規定されていないから、
# 交換則などが利用できず、型推論には不利だよなあ。

613 : ◆CgacaMDhSQ :2011/12/02(金) 07:32:32.18
>>611
> ◆CgacaMDhSQさんは(b)を指して [U >: Int] (U)U ⊇ (Int)Int が
> 成り立たないと書いているらしい。つまり、[U >: Int] (U)U は (Int)Int の
> Liskov substituion principleにおけるsubtypeではないことを書いているのだろう。はい。その通りです。
はい。それを意図していました。

> 俺ならtype orderを表す時は⊇でなく≧を使うので、混乱した。申し訳ない。
あー。なるほど。なんで、⊇使うんだろ…とか思いつつ、議論進めてたのがまずかったですね。
こちらも、その辺りについては意識を合わせておくべきでした。

> 齟齬が生じた原因は、想定した型推論のアプローチの違いだろう。

> ◆CgacaMDhSQさんはprincipal typeをunification-basedで求めたいので、
> (ひとつの)解候補が無矛盾かどうかが興味の対象だと推測する。
> だから、(b)なのでダメという立場。(正しい?)

正しいです。まさにprincipal typeを(unification-basedなアプローチで)求めようとすると、
Scalaの型システムだと死ねる、というのが私の言いたかったことです。

> ちなみに、constraint-based analysisアプローチは、
> Demand-Driven Analysis with Goal Pruning (DDP)の提案者が
> 現在Scalaに適用チャレンジ中とのこと。

おお。それは興味深い情報です。ちょっと調べてみます。

ところで、今更なんですが、その辺りのバックグラウンドをお持ちであったわけですし、
それを最初に明かしていただけたら、議論に齟齬が生じにくくて良かったと思います。
初学者の方が相手なのか、私などの門外漢よりも詳しい方 (:- が相手なのかによって
説明の仕方も自ずと異なってくると思いますし。

614 : ◆CgacaMDhSQ :2011/12/02(金) 07:44:12.34
> f(new A, new B)
> を受理するためには、xとyが同じ型である訳にはいかないよね、
> という単純な話。

理解しました。

ちなみに、#コメントについてですが、SMLやOCaml、Haskellの言語でも、一般に2項演算子の交換則
などは仕様レベルの規定は無かったように記憶しています(つまり、conventionとしてそういうのが
存在するだけ)。

615 :デフォルトの名無しさん:2011/12/02(金) 12:21:03.40
Spark: 高速なデータ分析のための新たな手段
http://www.ibm.com/developerworks/jp/opensource/library/os-spark/

616 :デフォルトの名無しさん:2011/12/03(土) 00:48:38.13
>>615

おお、こういうScalaで実装したライブラリが増えてくると、Scala言語も安泰だよね。


ところで、これって、個人で使って面白いもの? それともやっぱ企業の大規模プロジェクトで使うもの?

617 :デフォルトの名無しさん:2011/12/03(土) 01:16:55.03
みずしまさんみずしまさん、

以前、ScalaのIO周りが未整備な点について弱点として挙げてたけど、
Scalaの特性を生かした感じでIOのAPIを作るとしたら、どんな方式があると思います?
(サードパーティで既にある、とかいうオチでも良いです)

618 :デフォルトの名無しさん:2011/12/03(土) 03:30:54.84
>>617
https://github.com/scala-incubator

619 :デフォルトの名無しさん:2011/12/03(土) 04:24:14.32
>>618
これ、さっぱり更新されてないんだけど、大丈夫なの?
標準に入るって噂だったけど、なくなったの?

620 :デフォルトの名無しさん:2011/12/03(土) 04:39:18.57
ScalaIO開発してんのはこっち
https://github.com/jesseeichar/scala-io

621 : ◆CgacaMDhSQ :2011/12/03(土) 08:26:06.28
>>617
私自身のもくろみは実はまた別にあるのですが、時間がなくてほとんど動けていないので、現在は
Scala-IO https://github.com/jesseeichar/scala-io
を使っています。これは、scala.ioと違ってバイト列の読み書きを含めた、「まともな」
機能郡が一通りそろっていますし、ドキュメント(scaladocだけでなく、チュートリアルが
かなり丁寧に書かれています)。まだ若干バグもありますが、そういうのを含めて
バグ報告/pull requestを送ってあげると喜ばれるのではないでしょうか。
また、プロジェクトページ自体は移っていますが、依然としてscala-incubator
プロジェクトの一つで、将来的に入る予定です(Scalaチームのプライオリティ
としてはまだそれほど高くなさそうですが)。

http://jesseeichar.github.com/scala-io-doc/index.html

622 : ◆CgacaMDhSQ :2011/12/03(土) 08:34:45.04
また、Java 7が仮に使える環境なら(おそらく、プロダクションでJava 7を使えるところは
まだほとんどないと推測しますが)、Java 7のNIO2を使うのも一つのテかと思います。
http://docs.oracle.com/javase/7/docs/api/
ちょっとわかりにくかもですが、java.nio.fileパッケージ以下のやつです。これは、今までのjava.io
等と比べてかなり簡潔に書けるようになっています。

623 :デフォルトの名無しさん:2011/12/03(土) 12:30:31.06
>>613
ああ、申し訳ない。
俺は本当にScalaも型システムも初心者なんだ。

初心者なりに「型推論」という問題を考えてはみたが、
それを簡潔に説明するための専門用語を全然知らなかった。

この数日で、それじゃあ全然話が通じないのが判った。
だから、◆CgacaMDhSQさんの使った用語を起点にして、
関連する主要な論文を何本か読んで、
なんとか会話が成立するスタート地点にやっと立ったというのが現状のレベル。

ここまでだけでもすごく勉強になった。ありがとう。
飽きてなければ、これからもよろしく。

とりあえず、この数日のやり取りで、
Scalaは他ができてることができないんじゃなくて、
他が踏み込んでいない領域に(Javaとの相性向上のため)敢えて踏み込んでいて、
そこには最新研究でも未踏の困難が広がっている、というのが判ったよ。

624 :デフォルトの名無しさん:2011/12/03(土) 19:21:26.63
>>621
>時間がなくてほとんど動けていないので

天才と凡人の差がここにあり。

mizさんには、もっと大きいことをやって欲しいなあ。
つまらない論争に顔をだしてないで。


ただ、あちこちのBlogに顔出して技術サポートしているのは、結構助かってるので続けてほしい気も。
Scalaの話題でBlogあちこち見たりするんだけど、
内容が怪しいところにはたいていmizさんのコメントが入っているので、見ていて安心感がある。




625 :デフォルトの名無しさん:2011/12/03(土) 20:27:54.70
>>621-622
なるほど、ありがとう。

626 :デフォルトの名無しさん:2011/12/03(土) 20:54:11.48
みずしまさんって何者さんですか?

627 : ◆CgacaMDhSQ :2011/12/04(日) 04:14:34.09
>>623
なるほど。最初からバックグラウンドをお持ちなのかと思っていました。
私は特に飽きてはいないので、またネタがありましたら、議論しましょう。

>>624
そうですね…。確かに、自分は天才ではなく、行動力が少しあるだけの凡人だと思います。
「もっと大きいこと」ができるか、に関しては、12月中にとある発表ができると思いますので、お待ちあれ

論争に関しては、顔を出す前にその「質」を見極めることが重要なのだろうと今は思っています
今回の件で特に痛感したのですが、議論するだけ無駄、という場合はやはり多くあるので。技術サポート
というか、無差別な訂正の方は、今となってはややC/Pが悪いかな…という気がしています。

>>626
何者でもない、新米社会人エンジニアで、Scalaが好きなだけの人です。コテやってるのは、単に後から
参照したときに自分がどういう風に議論してたか思い出すためと、もはやトリップつけなくても発言特定
されてしまうので、他の人がNG指定しやすいように、くらいで深い意味は無いです

628 :@n_k28 偽善者乙:2011/12/04(日) 21:50:59.43
くたばれゴミクズ

629 :デフォルトの名無しさん:2011/12/04(日) 22:09:06.05
>>500
これの対応って型システムの拡張が必要なのかな?
結構ぶつかる問題なので、早めになんとかしてほしい…

630 : ◆CgacaMDhSQ :2011/12/04(日) 22:29:59.81
>>629
実装上の問題(バイトコードレベルでのジェネリックスの表現に関する問題)で、型システムは拡張
しなくても良いです。ただ、これを修正することでどれくらい影響が出るか、ちょっと把握できていない
ので、必要なら公式MLで聞いてみるとかした方が良いのではないかと。

631 : ◆CgacaMDhSQ :2011/12/04(日) 22:30:26.82
s/バイトコードレベル/クラスファイルレベル/ です。

632 :デフォルトの名無しさん:2011/12/04(日) 22:52:58.82
>>630
ありがとう。
とりあえず、できるけど面倒ということで、
当分(下手したら永遠に)改善されないことがわかったw


633 :デフォルトの名無しさん:2011/12/05(月) 23:57:22.03
>>627
> そうですね…。確かに、自分は天才ではなく、行動力が少しあるだけの凡人だと思います。

当たり前だ。誰がお前の事を天才だなんて思ってるんだw

日本の技術者だの研究者なんて99.9% が紹介屋なんだよ。

はやく Odersky と一緒に並んで写真撮ってけ

いろいろ役に立つぞw


634 : ◆CgacaMDhSQ :2011/12/06(火) 01:15:21.22
>>633
別に誰かがそう思ってるとは言ってなくて、単にまあ自分は凡人ですね、という同意レス返しただけですけど
それはともかく、Oderskyと一緒に並んで写真を撮る機会はこれまでもありましたが、それがどれほど役に
立つものでしょうか?そういう風な権威付けは実態が伴って無いものですし、すぐにメッキが剥がれるもの
じゃないですかね。

635 :デフォルトの名無しさん:2011/12/06(火) 01:28:35.76
つーか、大学院生 or 研究者上がりだと、普通にその分野の権威と
飯食ったり酒飲んだりする機会が結構あって、エラい人と一緒に居たとか
そういうのに希少価値を感じないよな

636 :デフォルトの名無しさん:2011/12/06(火) 01:32:07.20
>>634

633 は、マジレスする内容じゃないだろ。w


そんなことより、情報サイト充実させよーぜ。TIPS集がまだまだ足りない。

637 :デフォルトの名無しさん:2011/12/06(火) 01:49:18.06
謙遜すらできないこんな世の中じゃ

638 :デフォルトの名無しさん:2011/12/06(火) 02:01:45.80
>>635
程度問題でもあるんじゃないの
クヌースと飲み屋で飲み明かしたとか、それぐらいになれば
さすがに得難い経験だと思うw

639 :デフォルトの名無しさん:2011/12/06(火) 02:05:31.93
「ジョブズと昔、川に行ってさあ」みたいな感じか

640 :デフォルトの名無しさん:2011/12/06(火) 05:39:45.20
scalaプラグインはデバッガ周りが弱いなあ。
変数の値がほとんどみられないのはストレスだ。
なんか対策ない?

641 : ◆CgacaMDhSQ :2011/12/06(火) 07:58:33.29
>>635
それはあると思います。いやまあ、自分はミーハーなんでファンとしてサイン
ねだったりすることがありますが、それはともかく。

>>636
マジレスしてすいませんorz
TIPS集とか足りない兼はなんとかします。ただ、私一人だとどうあがいても労力に
限界があるのも確かです。その辺の新しい動きは12/10(土)に発表しますんで、もうちとお待ちください

>>640
ちょっと今確かめたところ、エディタからの変数のインスペクションがうまくいかんですね。これ、以前の
バージョンでは機能していたような。ともあれ、Debugパースペクティブの「Variables」ビューで、ローカル
変数を含めた変数の値が取れます。あと、Window -> Preferences -> Scala -> Compiler で、デバッグ
用シンボル情報吐かないように設定してたりしません?

642 :デフォルトの名無しさん:2011/12/06(火) 12:13:06.70
InfoQ: YammerがScalaからJavaへ移行中
http://www.infoq.com/jp/news/2011/12/yammer-scala

643 :デフォルトの名無しさん:2011/12/06(火) 12:41:23.28
Scalaはオワコン

644 :デフォルトの名無しさん:2011/12/06(火) 12:42:10.93
はじまってもいねーよ

645 :デフォルトの名無しさん:2011/12/06(火) 14:01:30.97
InfoQは喧嘩売ってんのか
潰すか

646 :デフォルトの名無しさん:2011/12/06(火) 22:04:57.55
>>645
知り合いのハッカーに泣きつくんですか?

647 :デフォルトの名無しさん:2011/12/06(火) 23:21:10.89
>>646
kmizuとyuroyoroとxuwei_kをなめんなよ
InfoQなんて明日にはこの世界から消滅してるぞ

648 :デフォルトの名無しさん:2011/12/06(火) 23:33:16.22
殺意の波動に目覚めたscalaちゃんがInfoQ潰してる絵はよ

649 :デフォルトの名無しさん:2011/12/06(火) 23:58:50.96
>>647
何かを召喚できそうなトリオだな。

650 :デフォルトの名無しさん:2011/12/07(水) 10:31:38.38
何でもいいからコード書けよカスども

651 :デフォルトの名無しさん:2011/12/07(水) 12:12:46.71
よーしパパ糞コード量産しちゃうぞー

652 :デフォルトの名無しさん:2011/12/07(水) 22:19:02.83
javaのstaticフィールドにはどうやってアクセスすればいいのでしょうか?

A.java
class A { static int si; }

に対して,scalaからA.siとやってもコンパイルエラーになってしまいます。



653 : ◆CgacaMDhSQ :2011/12/07(水) 23:47:23.75
>>652
単にアクセス修飾子の問題
siをpublicにすればOK
https://gist.github.com/144306
もちろん、クラスAが名前ありのパッケージに所属してるなら、package privateでも、
同じパッケージのScalaクラス/オブジェクトからアクセスできるけど、今回はそれに当てはまらない。

654 :デフォルトの名無しさん:2011/12/07(水) 23:56:57.23
ありがとうございます。
逆に言うと、public にしなければ不可なんですね…

うーん、またjavaでラッパーを書くことになりそうです。

ちなみにgithubのコードはC++でしょうか?

655 : ◆CgacaMDhSQ :2011/12/08(木) 00:07:56.99
>>654
あ、申し訳ない。なんか別のを貼ってしまったようだ。こっちが正しい
https://gist.github.com/1443062
それで、よくわからないところがちょっと。無名パッケージを使うときって、
使い捨てのコードくらいというのが普通の認識なんだけど、無名パッケージの
package privateなstatic 変数にScalaからアクセスしたいというのはどういう状況なんでしょうか?

656 :デフォルトの名無しさん:2011/12/08(木) 00:20:10.76
仕事で使っているライブラリがちょっと特殊なんですよ…

しかしscalaとjavaの相互運用はなかなか微妙なんですね。
ちょっと自分のscalaのレベルでは併用は早過ぎたようです。

657 : ◆CgacaMDhSQ :2011/12/08(木) 00:38:01.59
>>656
>仕事で使っているライブラリがちょっと特殊なんですよ…
なるほど。しかし、それってちょっとというかかかなり特殊なのでは?
それでもあえてやるなら、リフレクション使う、という手はありますが…

scalaとjavaの相互運用が微妙かというと、微妙な点はいくつかありますが、多くの
ケースで十分に上手くいく、というのが自分の認識です。現時点すら相互運用
のために色々妥協しているのに、100%の相互運用を目指すのはScalaにとっては
自殺行為じゃないかと

658 :デフォルトの名無しさん:2011/12/08(木) 08:08:58.22
みずしまさんAdvent Calendarは?

659 : ◆CgacaMDhSQ :2011/12/08(木) 08:33:10.54
>>658
今確認しました。あれ、自己申告制だと思ってたので、12/07に割り振られてたのに
気づきませんでした。今日明日くらいに書くのでご勘弁を

660 : ◆CgacaMDhSQ :2011/12/08(木) 09:41:18.73
というわけで、ちょっとテキトーですが、Advent Calendarの記事アップしました。
https://gist.github.com/1445310

661 :デフォルトの名無しさん:2011/12/08(木) 13:25:08.85
scala使ってる人のことなんて言うの?scalaer?

662 :デフォルトの名無しさん:2011/12/08(木) 15:28:52.53
スカリスト

663 :デフォルトの名無しさん:2011/12/08(木) 16:29:33.34
Scala, Scaler, Scalistの順で位が高くなります。

664 :デフォルトの名無しさん:2011/12/08(木) 18:03:25.86
Scalizerに変身できるようになると一人前。

665 :デフォルトの名無しさん:2011/12/08(木) 23:51:10.70
スカラマニア

666 :デフォルトの名無しさん:2011/12/09(金) 07:15:03.23
微妙だな。

667 :デフォルトの名無しさん:2011/12/09(金) 18:13:50.51
スカリー

668 :デフォルトの名無しさん:2011/12/09(金) 18:33:53.15
このスレ、コードがほとんど書き込まれてないんですが。

669 :デフォルトの名無しさん:2011/12/09(金) 19:27:30.97
気付いたか…

670 :デフォルトの名無しさん:2011/12/09(金) 20:12:18.61
どや
val fileText = io.Source.fromFile("data.txt").mkString
val (passed, failed) = List(49, 58, 76, 82, 88, 90) partition ( _ > 60 )

671 :デフォルトの名無しさん:2011/12/09(金) 22:43:34.85
def prime: Stream[Int] = {
def prime1(n: Stream[Int]): Stream[Int] = n.head #:: prime1(n.tail filter (_ % n.head != 0))
prime1(Stream from 2)
}

素数を求めるプログラム
面接で書けと言われたらとっさに書けないよねw

672 :デフォルトの名無しさん:2011/12/09(金) 22:47:18.00
コードはかけそうだが、計算量は?って聞かれたらつまると思う。

673 :デフォルトの名無しさん:2011/12/10(土) 00:19:58.17
Streamって何?

674 :デフォルトの名無しさん:2011/12/10(土) 01:08:20.38
止まらないことさ

675 :デフォルトの名無しさん:2011/12/10(土) 01:13:40.92

http://eed3si9n.github.com/scala-collections-doc-ja/
http://eed3si9n.github.com/scala-collections-doc-ja/collections_14.html

676 :デフォルトの名無しさん:2011/12/10(土) 10:38:14.32
大学の課題で少し質問させてください

val cmd = "val x = 0"
といった感じにscalaで実行させたいコマンドが文字列で格納されている場合に
簡単に格納されているコマンドを実行する方法はないでしょうか?
(Compiler APIは使い方がいまいち分かりません。。。)

677 :デフォルトの名無しさん:2011/12/10(土) 11:13:01.40
今日は13時から第二回Scala会議
http://partake.in/events/7b7f6551-8683-4968-855f-f8a62ec4bc93
ust
http://www.ustream.tv/channel/scala-kaigi
ニコ生
http://live.nicovideo.jp/gate/lv72707765

678 :nat-pool-nrt-u1.redhat.com:2011/12/10(土) 12:56:57.39
てst

679 :デフォルトの名無しさん:2011/12/10(土) 15:02:35.79
みなさんマサカリ投げすぎですよ

680 :デフォルトの名無しさん:2011/12/10(土) 15:14:44.25
コネー

681 :デフォルトの名無しさん:2011/12/10(土) 16:41:10.87
>>677
お昼寝してたら寝過ごしたけど、どうだった?

682 :デフォルトの名無しさん:2011/12/10(土) 16:44:14.00
>>671
見た目は洒落てるけど、結局_ % n.head != 0なんだな。素数だから仕方ないか

683 :デフォルトの名無しさん:2011/12/10(土) 16:49:00.55
>>676
val settings = new scala.tools.nsc.Settings { usejavacp.value = true }
val main = new scala.tools.nsc.interpret.IMain(settings)
main.interpret("val x = 0")
val x = main.valueOfTerm("x") //Option[AnyRef]で帰ってくるので適当に取り出す

……でいけるはずなんだけど、
2.9.1のREPLで試してみたらmain.valueOfTerm("x")がNoneになっちゃうな
なんでだろ

684 :デフォルトの名無しさん:2011/12/10(土) 18:29:06.33
大学の課題ってム板のネタなの?
こんな課題出るわけないと思うんだけどw
Twitterのutil-eval使うか参考にすれば?

685 :デフォルトの名無しさん:2011/12/10(土) 19:08:30.11
>>683
ありがとうございます。
私も某ページに文字列をeval化するサンプルがあったので
それを参考にやってみたのですが、2.9.1で試したところ同じくNoneが帰ってきていました。。

>>684
さすがにこの内容そのものが出たわけではないですww
やはりutil-evalを参考にするのが正しいんでしょうね、ありがとうございます。

686 :デフォルトの名無しさん:2011/12/10(土) 23:36:11.45
>>685
処理系自分で作れじゃなくて、Lisp系でもなくてそういう課題が出るってどんなせめた講義なのかきになる。

687 :デフォルトの名無しさん:2011/12/11(日) 17:55:11.97
Scalaは死んじゃうの?

688 :デフォルトの名無しさん:2011/12/11(日) 18:01:05.49
それが定めならね・・・

689 :デフォルトの名無しさん:2011/12/11(日) 18:10:54.14
バルス

690 :デフォルトの名無しさん:2011/12/11(日) 18:11:48.96
何度でもよみがえるさ
Scalaの力こそ人類の夢だからだ
って書こうとしたら先にオチが…

691 :デフォルトの名無しさん:2011/12/11(日) 20:10:41.40
scalaのvalって定義時に前方参照してもコンパイル通るけど、
実行時に例外で落ちることがあるね。
PackratParserを使って構文定義を書いてはまった。

ただ、常に落ちるわけではないのがよくわからない。
どうもval x = yみたいな単純コピーは危ないみたい。

692 :デフォルトの名無しさん:2011/12/11(日) 20:14:49.26
「Scalaが難しい」という批判がある時に、
1. 書きたいことを冗長あるいは複雑にしている。
2. 学習・教育コストが高い。
の二つがある。

言語オタクは1ばかり語りたがるが、一般人は2にしか関心ないよ。
エヴァンジェリストの諸君は、そこを勘違いしちゃダメだ。

693 :デフォルトの名無しさん:2011/12/11(日) 20:50:55.92
言語オタクはその二つしか語りたがらないから駄目だ

694 :デフォルトの名無しさん:2011/12/11(日) 21:37:17.76
他に何かあるか?

695 : ◆CgacaMDhSQ :2011/12/11(日) 22:06:25.27
>>691
そういう覚え方は逆に危ないです。valが危ないわけではなくて、パーザコンビネータでは、その性質上、
val同士の相互参照が発生し得るので、それを意識してないと問題になるという話です。普通にvalを書く分に
何か危険があるわけではないです。ちなみに、そういう理由もあって、パーザコンビネータの規則には
lazyを付けることが多いです。

696 :デフォルトの名無しさん:2011/12/11(日) 22:47:17.69
そのときは、valの順序を変えただけで解決したので深く考えませんでした。
val の順序を変えることで相互参照が断ち切れたのでしょうか?

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

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

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