プログラミング言語 Scala 11冊目 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
The Scala Programming Language
ttp://www.scala-lang.org/
日本Scalaユーザーズグループ
ttp://jp.scala-users.org/
■前スレ
プログラミング言語 Scala 10冊目
http://peace.2ch.net/test/read.cgi/tech/1390629242/
■Scalaの紹介文（さわり）
Scalaは簡潔かつ優雅で型安全な方法でよくあるプログラミングパターンを表現できるように
設計された汎用プログラミング言語です。
Scalaはオブジェクト指向と関数型言語の特徴をスムーズに統合しておりJavaやその他の言語を扱う
プログラマをより生産的にすることができます。（以下略）
ttp://www.scala-lang.org/node/25
■Scalaに関する書籍（英語）
ttp://www.scala-lang.org/node/959
リファレンスマニュアルや草稿のPDFなども充実しているのでそちらも参照してください。
日本語の資料には、チュートリアルの訳やIBM dW、IT Pro, @ITの連載記事、各々で開かれた勉強会の資料などがあります。 高級言語とやらは安全と無責任を取り違えてるだけだべ >>25
生産性の向上だけじゃなくて安全性ってメリットもあるよ Scalaと比較されるのはJavaだから安全性はメリットにならない (javaより安全性が高い 型安全的な意味で)
つーか日本だけでもはてなやドワンゴみたいな大企業が使ってて普及してないとか言われると
微妙な気がするんだけど
アドテクでも最近流行ってるし
スピードと安全性と生産性 両立したい！みたいなところから需要がある >>35
日本語の本だけに限ったって
scala逆引き
コップ本
fp in scala
オライリーのscala本
とかあるじゃん！
英語の本だったらライブラリやフレームワークの本含め
沢山でてるし Scalaの生産性が高いというのは大多数に当てはまらない虚言だろ
いくらコードが短くなると言っても覚えることが半端な量じゃない
まともに使いこなせるまで相当な学習コストがかかる
生産性が高いと言う触れ込みに飛びついて開発言語にScalaを選定し、大炎上してるプロジェクトを知ってるぞ Scalaは「生産性の高いJava」という方向で採用すると失敗例が多い
「型安全なPHP(もしくはnode.js、Ruby)」という方向での採用の方がしっくりくる例が多い 学習コスト
と
生産性
は違う気がする
生産性が高い(javaと比べて)って感じかもわからんから生産性だけを重視するならスクリプト言語の方がいい気がする
学習コストは確かに高いと思う
特にjvmの変なところを埋めようとしてるところとか(型消去や配列周りは罠)、残念な型推論やimplicitは鬼門
うちではrubyやってた人はわりとすんなりできるようになってる印象 後 sbtがとっつきにくい
というかアレscala結構できるようになってもキツイし初心者死ぬのにscalaやる上でほぼ必須という
<+=とか止めろ
dsl力が高いのは結構な事だけどマクロとimplicit使いまくるとすごい事になるわ HListって色んなところで使われてるんだな
なんやねんこれ ☆ ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ〜
ﾏﾁｸﾀﾋﾞﾚﾀ〜
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ Play2.5まだぁー？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| 愛媛みかん |／ playとscalatraってどっちがいいですか？
playはセッションまわりが変な希ガス >>73
当たるか当たらないか分からないサービスに最初からscalaで書いたり、
保守性が重要な業務アプリでscalaとか違和感しか感じない
Rails, PHP, nodeで書いて、パフォーマンスが足りないような事情でもない限り、
scalaを積極的に使うだけの理由なんてないんじゃないの >>89
ええとー、nodeはどうなんだろ？
普及度はScalaよりマシって程度だし、できあがるコードはお世辞にも保守性が
高いとはいえないし >>90
Node.jsは敷居が低いだろう
基本的にマイクロフレームワーク使うから小さいものを素早く作る分には非常に覚えやすく見通しもいい。
Scalaは言語やフレームワークを学習するオーバーヘッドが非常に大きい上にそれらの変化も無駄に激しい。
実務で使うならそれらを受け入れるのに見合ったリターンが必要なわけ。
求められる基準点が違うんだよ。 >>92
だから求められる基準点が違うと言っている
expressなんかサンプルコードチラ見したら使える
変わったところで大したことじゃない おれは型なし言語がscalaより保守性あるってのが理解できないわ。
とくにレールズなんて変化しまくりやんか 型システムが強力なのはビジネスロジックには非常に有効だけど、
HTTPリクエストの中身を必死に型付けしようとするみたいにフロントエンドの近くで型遊びやるのは生産性下がるだけの阿呆 そもアプリケーションがサーバーからクライアントに移っていってるんで5年10年前とは違うのだよ >>95
ちょっとテーブルの列を追加/削除みたいな時に割りとコンパイルエラーになるのは嬉しい
保守性というより安全性か
>>96
sprayとかはHTTPリクエストの型付けを自然な感じで記述できるよ
レスポンスはjson返す事が多いからそんなに負担に感じない scala 普通に使いこなす分にはそんなに学習コスト高いとは思わない
javaしか書いた事ないって人にはきついかも知れんけど 数年前にもここで同じこと書いたけど
マクロやら内部DSLバリバリ使ったライブラリ書こうと思ったらしんどいけど
普通に書く分にはそんな難しいことないよな
よく言われる淫プリ嫉妬もIDE使えばどこからインスタンス供給されてるかすぐ分かるし 他の主要言語とシンタックスがズレている事が問題だろこの言語はｗ
言語設計者にセンスがなかった >他の主要言語とシンタックスがズレている
どこらへん？ Martin Oderskyは Generic Javaも設計してるからもろ主要言語の人なんだけどな
型引数の[]はxmlリテラル<>を使うからだし
配列またはリストに特別なリテラル与えなかったのはコレクションを統一的に扱いたかったからだろうし 言語が難しい？簡単？を議論される時点でもうダメ
学習コストが1日かからないような洗練された言語が数ある中で
Scalaの居場所なんてありませんよ
オワコン まあでも、勝手に利用者増えてってる状況だからな。
普通に学部のCS出たらML系には馴染みがあるし、
erlangから移植したものとjvmから引き継げるものがあって、さっと使えるし、監視系に強いのが利点だと思う。
goが置き換えそうな分野が増えてるけどね。 ml系使えるならhaskellやocamlでなんで書かないのというのはあるが、そこはライブラリがあったり情報があったりなんだろうなと。 Scalaは普通にオブジェクト指向言語として書ける ＆ jvmで動きjavaライブラリが普通に使える
って点がでかい
てかscala書いててそんなに関数型プログラミング意識しないし scalazとか使うのならともかく
>>104
>学習コストが1日かからないような洗練された言語が数ある中で
そんな言語はない 仮に1日かからない言語があったとするとその言語の使用者は代わりがいくらでも簡単に用意できるということ
学習コストが高いというのはある意味長所だと思う
まあGoとかScalaとかHaskellとか業務系でメインじゃない言語をやってる人って
プログラミングが好きな人のイメージだから学習コストとか気にしないんじゃないかな
実際俺も実務で使わないけどScalaやり始めたし
今はScalaメインの会社に転職して楽しくコーディングしてるわ アセンブラとか低級言語は1日で理解できるが会得は困難
比較的高級なC++はとりあえず書けるが理解は一生かかってもできないと思う
どこまでを学習コストと見るかだな
Scalaは既存のJavaアプリの段階的移植という学習方法があるのがいい
Haskellは勉強のための勉強ばっかで苦痛だった どうやら、
IQに差がありすぎて会話になりませんね
Scala厨はもう少し頑張りましょう uyは色々な言語スレに登場しては荒らしていってる奴だから、無視が正解 すごいHaskellすげー面白かったぞ
パラダイムの学習以上のことをしようと思ったら苦痛そうだけど 職種別、資格別、スキル別の平均最低月給リスト（ほぼ毎日更新）
http://jobinjapan.jp/cate/
全掲載求人109,160件の平均最低月給195,800円
Scalaの求人 の平均最低月給268,000円
http://jobinjapan.jp/job-listing/keyword-scala.html haskellって圏論やらないと使えないのが痛いけど
scalaはjavaの亜種だから親しみがあっていいよな 寧ろJavaなんかに親しんでしまった人々を哀れむ
というかScalaは「Javaでない」ところに
魅力というか存在意義があると思うんだが
ScalaはJavaの亜種って相当な皮肉に聞こえる JVM上で動くから、Javaのクラスが普通に使えるってだけで、全然別言語だよな Javaの資産を流用できることが最大の売りであると同時に足を引っ張ってる
おかげで仕様に不自然な制限がとても多いしライブラリもクソ使いづらい 過去の資産使えなかったらまず始まりがないからな
C#あたりはそれだけで完結させるなら綺麗だがやはり既存のNativeコードとの連携では足を引っ張られてるしな NashornやJRubyやOCamlJavaだとJVMで動くからJavaのクラスが使えるだけの別言語という雰囲気だが
ScalaやGroovyだとJavaとの相互運用性を念頭に設計されてて別言語っていうのにも違和感ある >>121
具体的には？
jvmのアレさが足を引っ張ってる所は感じてるけど
（主にarrayと型消去） >>124
単にJavaAPIをFFI出来るだけにJavaとの互換性限定すればJVM上でも配列や型消去も(パフォーマンス上の問題はあるが)好きにやれるんじゃないか？ Scalaを勉強した感想
・複雑な処理でも簡潔に書けると謳っているが、簡潔に書けるまでにはかなり勉強が必要だと思った
・可読性なくね？ >>127
もうベターJavaというか完全にJavaじゃないか
これだったらもう普通にJavaでいいわ >>126
scalaで簡潔に書けないのは関数型に慣れてないだけでは？
あとちょっと勉強したくらいでその言語の可読性を語っちゃいけない >>126
普通に書いてる分にはそんなに可読性悪くないと思う
implicit使いまくると可読性落ちるけど あとあんまりにもdslっぽく書くために演算子を使いまくったり
macroに手を出したりするとわけわかめ >>129
どのへんが完全にJavaなのかわからなかった >>133
むしろどのへんがScalaらしいのか教えてほしい
普通のJavaとしてはお手本のような綺麗なコードだけど、少なくとも関数型プログラミングとは言い難い Implicit 最高やろ。extends AnyVal が効くようになってから使いまくってるわ 可読性は言語自体が持つ構文にも影響されるけど
最も可読性に影響を与えるのはコードを書く人だから
twitter社のscalaのコードが読みやすい読みにくいはtwitter社のプログラマのせい >>127が「実世界での開発におけるScalaの正しい使い方」なんだとしたら、
一部の企業でScalaからJavaに回帰する動きがあるのも納得
これなら確かにJava8でいいね 単純にvar禁止にすれば嫌でもある程度scalaっぽいコードになるだろうな >>127のようなインフラに近い部分って本質的にミュータブルにならざるを得ないんだよな
それにweb系は基本的にモデルが単純であることが多く、関数型のメリットを受けづらい
関数型の真価はむしろ、見ただけで吐き気するようなクソ複雑な業務ロジックと業務フローを記述するのに発揮されると思うが
日本の大規模システム開発に果たしてそんな日が来るのかどうか 関数型っぽいコード書けなくても
・ある程度速くて
・冗長すぎず
・Javaの資産を呼び出せる
ってだけでも使う価値あるだろ。少なくともJava直接書くよりは断然生産性がいい ローレベルなメソッドではミュータブルに命令形的に高速に書いて、中間はイミュータブルに関数型的に書いて、その入出力をOOPでまとめるってすごくScala的だと思う >>141
わかる。副作用が扱えるscala のいい使い方だな 速度の要求厳しくなければ細部もイミュータブルに書けるし、開発者がHaskellやML系での設計に慣れてればクラスは単にモジュールとしてだけ使えるかな scalaz使えば型クラス使えるし
shapeless使えば自動導出だってあるよ！ 技術に拘る意識高い系って業務から逃げちゃうからなあ
そういう連中が積極的に業務に向き合えば関数型バリバリ使ってWebなんかよりよっぽど面白い世界になりそうだけど 関数型って要はモナドだろ？みんながアレを使いこなせることはこの先ないだろうな。
関数型ブーム来てるけど、けっきょく高階関数が便利とかイミュータブルにしようとか、当たり前のことだけで落ち着くだろうな haskellこそが関数型言語だっていう風潮どうなのよ
遅延評価かつ副作用をモナドに閉じるって関数型言語一般の話じゃない まぁそうだけど、じゃあ関数型一般に特有なのはなんだ
最近の言語はラムダくらい使えて当たり前だし 147のとパターンマッチと型推論と型安全で当たり前に便利でも十分だとおもう >>147
maybeモナドやlistモナドあたりに限って言えば全然難しくないので広まるのでは
特にmaybeモナドがないプログラミングはもう考えられないっていうレベルで便利だし
>>149
関数型の定義が曖昧だから再代入禁止にして高階関数使ってイミュータブルコレクション使えば
もう関数型でいい気がするけど最近のオブジェクト指向言語大体揃えてる気がする。。
ml系になってしまうけど代数的データ型、パターンマッチ、型クラスあたり・・？ ScalaMatsuri 二日目まだTBDが半数以上とかどうなっとるんですか… モナドみたいな汚いハックが持て囃されるうちは関数型は主流にはなれないよね
関数型の実用的なメリットはその宣言性の高さなのに
それを損なうことがカッコいいみたいな空気は気に入らない 純粋なオブジェクト指向が主流になったことがないように
関数型が主流になることはないだろうし
仮に関数型が主流になったところで
Scalaがその筆頭になることはないから安心しろ C#だと最近null propagation operatorっていう演算子が入って
mayBeNull() ?. nullの場合 .? 単に .? nullが .? 返る();
みたいな書き方でMaybeモナドのようなことを実現できるようになったけど
これ自体がイケてるかどうかは別にして、本来プログラミング言語が目指すべきところはこっちだと思うんだよね
それを安易にハックに頼っちゃうと際限なく複雑になってしまう >>155のいう「ハック」って何なんだろう？
モナドは数学的バックグラウンドがある理論なんだけど… 関数型で文脈を記述するDSLを実現する「ハック」だな
こういう言語内言語みたいなのは進化の過渡期にありがちな状態で、いずれ言語本体に自然な形で統合されていく プログラミング言語がどんなに進化しようとも
それを扱う人間の質が変わらないのなら 進化というより再定義だな。
モナドを言語に統合していけば、結局は関数型言語の中に従来の手続き型言語に似たものが同居する形に行き着くはず。
そうなったところで実質何も変わらないが、ガチ関数型信者連中にとっては関数モデルが基礎になっていることが重要なんだよ。 >>155
なんか色々勘違いしてるようだけどそれmonadじゃなくてただのfunctorじゃね？
ハックが云々って言ってもmonadってただの型クラスなのですごい特別なものでもないし
do構文やfor式が嫌いなら>>=やflatMapを使えばいいし
>>157
monadを使えば文脈を表せるっていうけど別にListやOptionやTry（モナド則満たさないけど）使う時は意識しないし
多くの純粋ではない関数型言語では状態やIOをそのまま使えばいいわけで >>160
>モナドを言語に統合していけば、結局は関数型言語の中に従来の手続き型言語に似たものが同居する形に行き着くはず。
maybeやeitherはどうするんですかね
ていうかfunctorやapplicativeを言語を統合するみたいな話と同じなので意味がよく分からん
STArrayやSTRefやIO Monadが汚いハックってんならわからんでもないけど
普通の関数型言語では使わないし
>そうなったところで実質何も変わらないが
純粋な関数から副作用がある関数を呼べないという点が違う(unsafePerformIO? 知らんな) >>155
あ ごねん勘違いしてた
途中でnull返ったら全体がnullになるのね
でもnullableかどうかを型で表せないからっぽい？ので やっぱmaybe monadより力が劣ると思う
mayBeNull() ?. nullが返らないと思ったけどnullだった . 返る(); // ぬるぽ
nullの為に特殊な構文を導入するよりかはmonadのほうがいいと思う 155が言いたいのはモナドも模倣するような機能が、後から入ってくるのがハックってことでは？ Scalaでモナドのような型クラスを使おうとするとimplicit conversionを使ったりしなきゃ
いけないのが汚いということなのかなぁ？
いやでも>>153で関数型全体の話をしてるから、Haskellみたいに型クラスを普通に
扱える言語もあるから違うか
それとも単純にモナドのような強烈な抽象化が生理的に受け付けないだけなのかなぁ？ 状態扱うのに、参照透明でも手続き型を模倣した方法使い始めると、そのうち管理しきれなくなるとかそういうのはないの？ 状態を濫用すると結局手続き型と等価になっちゃうだけだよ
相当慎重に作らないとあっという間に大部分の関数がモナドで汚されてしまう chainer とかの backward って勾配を計算してるんだから、実際自動微分だと思ってたんだけど違うの？
Theano も同じことやってるだろ？ emacs + ensime …はだめですよね、はい ■ このスレッドは過去ログ倉庫に格納されています
