[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 09/04 23:04 / Filesize : 158 KB / Number-of Response : 669
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

プログラミング言語 Scala



1 名前:デフォルトの名無しさん mailto:sage [2008/03/10(月) 22:40:17 ]
The Scala Programming Language
ttp://www.scala-lang.org/

チュートリアル日本語訳
ttp://homepage.mac.com/takashi_miyamoto/scala/ScalaTutorial.pdf
どう書く?org Scala
ttp://ja.doukaku.org/lang/scala/

116 名前:デフォルトの名無しさん mailto:sage [2008/03/29(土) 11:03:09 ]
版?

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

118 名前:デフォルトの名無しさん mailto:sage [2008/03/30(日) 00:53:52 ]
Ruby信者もバランス感覚を覚えて欲しい

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

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

120 名前:デフォルトの名無しさん mailto:sage [2008/03/30(日) 17:56:01 ]
部分適用はあるが、カリー化なんてあったっけ?

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

122 名前:デフォルトの名無しさん mailto:sage [2008/03/30(日) 18:12:43 ]
これか

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

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

123 名前:デフォルトの名無しさん mailto:sage [2008/03/30(日) 18:18:28 ]
>>119
それならお前が答えればいいのに

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

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



125 名前:デフォルトの名無しさん mailto:sage [2008/03/30(日) 20:11:51 ]
> 俺はmixinは制限付き多重継承だと思ってるから

kwsk

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

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

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

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

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

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

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

133 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 00:45:09 ]
>>131
Rubyと違って仕様が一貫してそうですが

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



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

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

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

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

137 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 06:45:15 ]
相変わらずRuby厨が無駄に湧くスレだなぁ

138 名前:デフォルトの名無しさん mailto:sage [2008/04/04(金) 10:52:07 ]
阿呆は放置推奨

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

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


141 名前:デフォルトの名無しさん [2008/04/04(金) 23:27:13 ]
同僚って、もう仕事でしかも共同開発って使ってるの?すごい

142 名前:デフォルトの名無しさん mailto:sage [2008/04/05(土) 01:02:21 ]
Scalaで仕事?

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

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



145 名前:デフォルトの名無しさん mailto:sage [2008/04/05(土) 03:14:08 ]
>>139
Rubyなんて触ったことすらない

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

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

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

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

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

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

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

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

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

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

154 名前:デフォルトの名無しさん mailto:sage [2008/04/06(日) 04:06:22 ]
これって知らなかったが、PartialFunctionを先祖で継承しているからなのか?
関数を継承してるコレクションって珍しいな



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

156 名前:デフォルトの名無しさん mailto:sage [2008/04/06(日) 07:38:00 ]
>>149
Fortranと一緒だと思えばいい

157 名前:デフォルトの名無しさん mailto:sage [2008/04/06(日) 10:56:18 ]
〜.run()とか〜.invoke()じゃなくて〜()って出来る

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


158 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 14:41:16 ]
他に、関数と配列で同じ表記使う言語あったかなと思ったら、
BASICもそうだったなw

159 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 17:44:31 ]
なんか、型推論があれば、
動的型付けなんかいらないみたいな事が書いてあったけど、
本当にそうなの?

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

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

162 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 20:09:32 ]
型に応じて分岐処理ってポリモーフィズム?

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

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



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

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

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

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

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

169 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:11:48 ]
<>でも[]でもどっちでもいいじゃん

170 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:24:44 ]
{}でもdo..endでも でもどっちでもいいじゃん

171 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 21:34:19 ]
それは{}でお願いします

172 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 22:14:10 ]
>>166
Javaのgenericsにその問題はないから別の理由だろ

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

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

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



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

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

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

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

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

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

180 名前:デフォルトの名無しさん mailto:sage [2008/04/08(火) 18:35:02 ]
とりあえず参考資料 っ

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

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

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

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

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

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

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

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



185 名前:デフォルトの名無しさん mailto:sage [2008/04/08(火) 23:52:00 ]
Cが駄目だね。> 分離


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

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

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

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

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

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

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

191 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 00:27:00 ]
>>189
Ruby書きづらいし遅くて使い物にならないけど

192 名前: mailto:sage [2008/04/12(土) 01:23:41 ]
Scalaの日本語版Wikipediaには影響を受けた言語にRubyが入ってるけど、英語版にはない。

193 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 01:48:56 ]
>>192
それはひどいな
捏造かよ

194 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 03:18:59 ]
もうRubyはいいって。
内容のある比較もないし。



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

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

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

198 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 16:37:37 ]
>>195
うわぁ・・・Ruby信者いいかげんにしろ

199 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 17:42:28 ]
こたえられないんですね。

完膚なきまでに論破。

200 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 17:47:39 ]
信者なのかアンチの嫌がらせなのかの区別がつかない。
どちらにしてもScalaの絡まないRubyの話は
Ruby関連のスレかLLスレでやってほしい。

201 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 21:26:20 ]
Railsにブチ切れた外人がフレームワーク作った模様

InfoQ: David Pollak氏 lift と Scala を語る
www.infoq.com/jp/news/2008/03/liftweb

202 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 22:17:14 ]
>>189,191,198,199あたりはRubyを貶めようとする輩の自作自演の可能性が高い。
本当のRuby信者がRubyの心証が悪くなるような行動をするわけがない。

203 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 22:23:48 ]
まつもとゆきひろが率先してやってる件について

204 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 22:25:39 ]
>>202
>>195が抜けてるけど>>195ですか?



205 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 22:29:16 ]
すまん、訂正する。>>189,191,195,198,199あたりはRubyを貶めようとする輩の自作自演だろ。

206 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 22:56:28 ]
なんでもかんでもアンチのせいにしてごまかそうとしてるな酷すぎる

207 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 23:21:34 ]
>>202-206
>200
>どちらにしてもScalaの絡まないRubyの話は
>Ruby関連のスレかLLスレでやってほしい。

どうでもいいけどRubyスレのほうが盛りあがっててワロタ
良く釣れる連中だから遊んでもらえるんだな

208 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 23:26:34 ]
そんなことより2.7.1RC1が出てるぞ
バグフィックス中心だけど、簡単な正規表現ライブラリも追加されている

209 名前:デフォルトの名無しさん mailto:sage [2008/04/12(土) 23:30:28 ]
正規表現だってー!!

210 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 10:26:23 ]
java.util.regex.*でいいじゃん...

211 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 12:18:10 ]
鬼車キボン

212 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 13:23:47 ]
またRuby厨が沸きそうなネタを…

213 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 14:12:42 ]
PEGの方がいいじゃん

214 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 14:45:28 ]
>>210
いや簡単なjava.util.regexのラッパー



215 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 15:19:47 ]
自前LL作るときにJVM利用する価値があるのは同意する。
しかしライブラリまでラッパでおk、ってのはいかがなものか。
たしかにJavaの豊富かつ実績のあるライブラリが使えるのはすげーメリットだが、
自前言語に合った、使いやすい物をもっと作れるはずだろ。インタフェース的な意味で。

藻前らが独自言語を設計してもJVMの命令列に落とすのと同じだ。
独自インタフェースのライブラリを設計して、標準ライブラリを利用しろよ。
Java標準パッケージ脳乙。

ということを繰り返し書いている漏れは……うー。
もしこれ以上雑多な拡張が必要になる将来が来るなら、それよかPEGにしたらいいと思う。 >regex

216 名前:デフォルトの名無しさん mailto:sage [2008/04/13(日) 16:23:42 ]
なんだregexリテラルくらい作ってくれればいいのに






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<158KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef