プログラミング言語 Scala 11冊目 [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/08/28(金) 07:25:25.39

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の連載記事、各々で開かれた勉強会の資料などがあります。

**デフォルトの名無しさん** · 2016/02/09(火) 22:32:28.42

確かに単純なwebアプリを作るとかだとたしかにruby使えよって思うな
重いバッチ処理があるとか
非同期ですぐレスポンス返す必要があるとかだね>scala
playはformのバリデーションの型付けがとにかく面倒で

**デフォルトの名無しさん** · 2016/02/11(木) 07:52:13.90

簡単なものつくるにしてもrubyとかだと固まらない粘土で像つくってるみたいで不安が拭えない勢

**デフォルトの名無しさん** · 2016/02/11(木) 08:51:06.73

フロント寄りのところは固めたそばから変わるからほとんど意味無いけどね
奥の方の頻繁に変わらなくてスループットが重要なところに使うのが正しい

**デフォルトの名無しさん** · 2016/02/11(木) 09:54:49.72

>>206
うまい表現やなわかるわそれ

**デフォルトの名無しさん** · 2016/02/11(木) 14:16:33.47

>>206
Rubyは粘土で作ってる感じ
作り上げてもすぐ変形しそうだけど、逆に言えば変更には柔軟

Scalaは型枠を作ってそこに材料を流し込む感じ
かっちり作れるけど変更するときはうまく型枠を変形する技術がいる

**デフォルトの名無しさん** · 2016/02/11(木) 14:21:41.85

ruby は言語自体は好きだけど周りのツールとかが面倒くさいんだよな

**デフォルトの名無しさん** · 2016/02/11(木) 22:18:42.90

「変更のしやすさ」は色々あってフロント側の変更は型安全なところが面倒だけど
逆にビジネスロジックで少し変更がしっかりとコンパイルエラーになるからむしろ動的型付けより
変更が楽に感じる

**デフォルトの名無しさん** · 2016/02/11(木) 22:48:52.29

同意
フロントでフォームを型付けしたりとかはガチの阿呆

**デフォルトの名無しさん** · 2016/02/12(金) 01:01:56.97

>>211
ビジネスロジックなんてテスト書くの必須なんだから動的静的はあまり関係ない気がする
どちらかというとスループットの方がScalaのメリットじゃないか

**デフォルトの名無しさん** · 2016/02/12(金) 06:57:04.54

そもそも静的型や関数型の堅牢性のメリットが得られるほどビジネスロジックが複雑な分野でScalaが使われてるかっていうとね
Web系ばっかりで、スループットくらいしか恩恵がないのが現状
業務系のドカタITは自動テストなんてまず無いし業務ロジッククソ複雑だし頻繁に更新しないし論理的な正しさが最重要だしで
まさに静的型の関数型言語向きなんたけど

**デフォルトの名無しさん** · 2016/02/12(金) 13:00:42.64

>>213
なんかいつもの動的型付けvs静的型付けになるけど型は証明だけどテストはそうじゃなくてテストが全部網羅してるわけではないので安心感が違うというか
例えばDBのあるcolumnがnot nullになった場合にOption[A]をAに変えればいいけどこの影響を全部テストでカバーできるかっという不安

**デフォルトの名無しさん** · 2016/02/12(金) 14:20:10.23

>>213
テストはどっちにしても必須なのは同意だけど、書かないといけないテストの量が段違いやん？

**デフォルトの名無しさん** · 2016/02/12(金) 17:15:59.71

それな

**デフォルトの名無しさん** · 2016/02/13(土) 15:02:14.88

>>214
アドテク

**デフォルトの名無しさん** · 2016/02/13(土) 22:45:56.09

アドテクやってないお前らがアドテクで使われてますって喧伝しても滑稽なだけなんだが

**デフォルトの名無しさん** · 2016/02/13(土) 23:47:40.16

アドテクってビジネスロジック複雑なのか?
スループットが重視される好例としか思えないんだが

**デフォルトの名無しさん** · 2016/02/14(日) 03:19:33.91

バッチ処理なんかは結構複雑
逆にスループットはそこまで求めてない
>>219
実際うちは使ってるわけで

**デフォルトの名無しさん** · 2016/02/14(日) 12:36:18.72

>>221
え？バッチ処理こそ速度命だろ
そもそも時間がかかるからバッチに回してるわけなんだし

**デフォルトの名無しさん** · 2016/02/14(日) 12:39:05.75

開発と運用が簡単だからリアルタイム性が必要ない処理を安易にバッチにするというのはドカタITじゃ珍しくないよ

**デフォルトの名無しさん** · 2016/02/14(日) 12:49:33.33

というか、計算機資源をうまく使うためのバッチは、常套手段でしょ。

**デフォルトの名無しさん** · 2016/02/14(日) 13:43:33.80

scalaはバッチ処理にはかなり重宝してるわ。
ある程度速いし、コレクションメソッド山ほどあるし、並列化も超簡単だし、ジャバも呼べるし

**デフォルトの名無しさん** · 2016/02/14(日) 16:20:04.20

>>222
リアルタイム性は重要じゃないので言語の速度（という言葉は正確じゃないけど）はんな重要じゃなくて
いかに並列にするかスケールするかとかの方が重要
時間は早いに越したことはないけどデータウェアハウスなんか使う場合はIO待ちの方が多いしね

**デフォルトの名無しさん** · 2016/02/15(月) 21:22:53.68

scala2.12-の新しいのが一向に出て来ないのは何でなんでしょうか？
詳しいかた教えて下さい。

**デフォルトの名無しさん** · 2016/02/15(月) 22:36:31.91

わろた
俺も分からん

**デフォルトの名無しさん** · 2016/02/16(火) 03:09:13.11

kotlin1.0がリリースされたよ～

**デフォルトの名無しさん** · 2016/02/16(火) 11:36:54.76

おれはscalaでAndroid書いてるわ

**デフォルトの名無しさん** · 2016/02/16(火) 12:50:39.62

>>230
まだScalaでAndroidやってんのｗ

**デフォルトの名無しさん** · 2016/02/16(火) 12:58:33.50

>>231
コトリン使えってこと？
コトリンってscalaの劣化版じゃないの？

**デフォルトの名無しさん** · 2016/02/16(火) 16:28:50.12

Scalaでandroidは辛みかでかすぎる

**デフォルトの名無しさん** · 2016/02/18(木) 01:23:17.40

Android+Kotlin流行りそうだし、Javaに次ぐJVM言語の座は1年後にはKotlinになってそうだなｗ

**デフォルトの名無しさん** · 2016/02/18(木) 06:53:50.82

Scalaの劣化というより改良といっていいと思う
Scalaと違ってまともな取捨選択のセンスがあるってだけで十分乗り換えるモチベーションになるよね

**デフォルトの名無しさん** · 2016/02/18(木) 07:25:07.57

Kotlinはbetter Javaの領域をまったくはみ出していないという点では、Scalaとは別物だろう

**デフォルトの名無しさん** · 2016/02/18(木) 07:33:35.31

Kotlinのスレを立てよう

**デフォルトの名無しさん** · 2016/02/18(木) 08:06:28.90

>>236
具体的には?
一般的なScalaらしさってほとんどは言語仕様ではなくあのカオスな標準ライブラリによるもので、
implicitを除けば大部分はKotlinの範囲で問題なく実装できると思うが

**デフォルトの名無しさん** · 2016/02/18(木) 11:36:34.88

そのカオスな標準ライブラリでimplicitめっちゃ使われてる(collectionや型クラス)のでむずくね？
型消去対策が最初からしっかりしてるのはいいところ
後委譲用の構文があるのはいいよね

**デフォルトの名無しさん** · 2016/02/18(木) 13:35:19.49

scala の for 式に相当するものとパターンマッチがあればあんまり文句はないが…

**デフォルトの名無しさん** · 2016/02/19(金) 00:56:53.94

scalaは十分に枯れているので
androidではなくサーバーでkotlinを使いたいとは思わない

**デフォルトの名無しさん** · 2016/02/19(金) 01:40:42.90

言語仕様はscalaで、VM言語じゃない言語が欲しい。近いのはrustかswift？

**デフォルトの名無しさん** · 2016/02/20(土) 11:41:35.02

Scalaパズル Kindle版が半額セール

**デフォルトの名無しさん** · 2016/02/20(土) 17:15:40.44

Scalaパズルは固定レイアウトかぁ
逆引きレシピも半額だね

**デフォルトの名無しさん** · 2016/02/20(土) 17:39:10.95

発売直後の本を半額セールするという誠意のなさ

**デフォルトの名無しさん** · 2016/02/20(土) 19:46:47.09

出版社的には前からkindle半額セールあるみたいなので、今後は考慮して買うしかないね。

**デフォルトの名無しさん** · 2016/02/21(日) 15:11:10.55

>>243
翔泳社全点半額セールってことで早速購入したけど、電子書籍って微妙に扱いづらいな

**デフォルトの名無しさん** · 2016/02/21(日) 17:42:44.10

慣れれば電子書籍しか読めなくなるよ

**デフォルトの名無しさん** · 2016/02/21(日) 22:11:19.84

>>248
読み物はそうやけど
マニュアル系は紙のほうがよくね？

**デフォルトの名無しさん** · 2016/02/21(日) 22:16:35.30

逆だろ
マニュアルは検索性能が大事だから電子媒体の方が強い

**デフォルトの名無しさん** · 2016/02/21(日) 23:13:00.64

電子書籍は形式によって読みにくかったり検索しにくかったりするので当たりハズレがある

紙書籍で読みにくい書き方・編集・構成のものは電子書籍になっても読みにくい

紙書籍は一度通して読んでればだいたいどの辺に欲しい情報が載ってるか分かる
一度通して読むのは初めて学習するときくらいしかないがパソコンの脇に置いておいてもすぐ探せる
利点は電気機器を使えない場所でも読める。欠点は場所を取る、持ち運びに重い。
また複数のジャンルにまたがる情報が必要なときその分だけ紙書籍を揃える必要があり糞邪魔

紙書籍は通して読むのでなくリファレンスマニュアルのような字引きとして使うには邪魔で不便
検索機能のある電子書籍のほうが便利な場合が多い（もちろん前述のとおり書籍の形式次第だが)

数千ページを１つのPDFやHTML1ページにまとめたタイプとか俺としては使いにくいので嫌い

電子書籍サイトの専用アプリで閲覧するとき同時に２冊以上を展開できないタイプもあったりするので
電子書籍で読む場合は形式等を十分に考慮するべし

**デフォルトの名無しさん** · 2016/02/22(月) 02:09:43.67

Kindleの固定レイアウトは勘弁
検索もできないし、マーカーも引けない

Kindle版のScalaパズルがそれ

**デフォルトの名無しさん** · 2016/02/22(月) 21:00:15.86

たまにはGroovyのこと思い出してあげてください。

**デフォルトの名無しさん** · 2016/02/22(月) 21:43:08.26

あいつはもう消した

**デフォルトの名無しさん** · 2016/02/23(火) 15:41:24.42

swift がサーバーサイドに入り込んでくるっぽいな
scala は java のおかげで地位は確保できるだろうけど

**デフォルトの名無しさん** · 2016/02/23(火) 21:20:22.62

swiftの敵はKotlinじゃないかな

**デフォルトの名無しさん** · 2016/02/23(火) 21:42:13.32

Go(笑)だろ

**デフォルトの名無しさん** · 2016/02/24(水) 00:06:35.70

Goとかマジで持て囃されはじめてて引くわ
Rust, Swiftの方がマシだ

**デフォルトの名無しさん** · 2016/02/24(水) 00:18:19.56

go は if err !＝ nil 書くゲームだからな。
optionモナドに慣れてる人間からしたら我慢ならん。あとGenericsがないせいで事実上リストの高階関数が作れないのも終わってる。モダンの欠片もないロクでもない言語だわ

**デフォルトの名無しさん** · 2016/02/25(木) 22:21:14.20

Android用のGroovyそのまま使えてメッチャ楽なのに
何でみんな使わないんだろ？
Android開発でscalaとか正気の沙汰じゃないと思うけど

**デフォルトの名無しさん** · 2016/02/25(木) 22:22:57.56

>>259
静的なOptional/Nullableに慣れてる人からすると
scalaのモナドを動的マッチングするのもかなり我慢ならんけどね

**デフォルトの名無しさん** · 2016/02/25(木) 22:23:47.81

正確にはモナドじゃなくてモナド型か

**デフォルトの名無しさん** · 2016/02/25(木) 23:01:57.10

>>260
GroovyとJavaとかRubyとかPHPを比較するならわかるけど
Scalaと比較するのは方向性からして間違ってない？
Scalaを選択した人が求めているものはGroovyにはないと思うの（逆もしかり）

**デフォルトの名無しさん** · 2016/02/26(金) 00:22:25.83

>>261
静的なOptionて何？
おれはfor式で複数のモナドをまとめて扱えてハッピーくらいにしか思ってない人間なんだけど

**デフォルトの名無しさん** · 2016/02/26(金) 07:10:25.90

>>263
Scalaを選択してしまった大半の人が求めているのはLightweight Java
まあ実際使うと全然Lightweightじゃないことを思い知るんだけどね

**デフォルトの名無しさん** · 2016/02/26(金) 11:35:47.36

Groovyって型書けるんだな。。
今後新規で泥アプリの開発することあったらKotlinとどちらを採用するか悩むな
Scalaで書けるならそれが一番良いのだけれど

**デフォルトの名無しさん** · 2016/02/26(金) 13:12:05.70

>>266
scala でAndroidは環境整えたりライブラリアノテーション有功にしたりがとにかく面倒。
それ以降は快適そのもの…と言おうと思ったがコンパイルが面倒

**デフォルトの名無しさん** · 2016/02/26(金) 20:18:24.96

>>265
それはないわ

関数型というオブジェクト指向とはまったく違うパラダイムを前面に押し出してるのに
Better Javaだと思い込んで選択してるんだとしたら、それはただの調査能力不足かと

**デフォルトの名無しさん** · 2016/02/26(金) 22:49:00.74

>>265
あんだけ関数型を前面に押し出してるのにそう思う奴いねーだろ

**デフォルトの名無しさん** · 2016/02/26(金) 22:52:24.97

>>261
(動的マッチングってなんだろう)

**デフォルトの名無しさん** · 2016/02/26(金) 23:50:43.13

型クラスのインスタンスはScalaではtraitのサブクラスのオブジェクトだから
それに対するコールは動的バインディング（＝動的マッチング？）になるって事では？

仮想関数の呼び出しコストすら看過できない
めちゃパフォーマンスクリティカルなシステムを組まれているお方なのかなと

**デフォルトの名無しさん** · 2016/02/27(土) 00:10:47.85

ガチな方の関数型には動的ディスパッチなんか無いからな
速度云々じゃなくて不確定な振る舞いが存在するのが問題なんだよ

**デフォルトの名無しさん** · 2016/02/27(土) 01:23:24.32

haskellで instance で自分でモナド型を宣言して使うのって実質的に動的バインディングと同じじゃない？

virtualメソッド呼び出しの何が問題なのかもイマイチ分からんのだけど

**デフォルトの名無しさん** · 2016/02/27(土) 03:16:16.54

>>272
不確定ってどこが不確定なんでしょう？

**263** · 2016/02/27(土) 08:48:41.19

>>265
少なくとも自分はJavaより強力な型システムを求めて辿り着いたわ
Better Java的な使い方にとどまるならGroovyを選んでたと思う

**デフォルトの名無しさん** · 2016/02/27(土) 08:57:35.28

>>267
最近泥Scala環境見直しけど、以前に比べると環境構築自体は大分楽になったと思う
確かここを参考にしたはず
https://tanoshiilife.wordpress.com/2015/12/16
Scaloidも便利なんだけどハマりどころが多い気がする

まあ、コンパイル時間の問題は解決しないけどなー

**デフォルトの名無しさん** · 2016/02/27(土) 12:04:44.80

>>273-274
haskellとかだと、コンパイルリンクした時点で、
実行時に呼び出される関数が確定してるって意味でしょ
たとえ自分で宣言したモナド型であってもね

**デフォルトの名無しさん** · 2016/02/27(土) 12:26:14.93

>>277
いやそうだろうけど、haskellでも多相にできるんだから、その型を使う側からしたら振舞いは不確定じゃん？
というかその不確定さが多相、多態性の売りなんじゃない？
scala でもコンパイル時にチェックはしてるんだから変なメソッド呼び出しにはならないし

**デフォルトの名無しさん** · 2016/02/28(日) 06:12:35.94

>>278
scalaはAnyがあるので、haskellと違って型推論だけで判断してません
型のマッチングは動的になってる

**デフォルトの名無しさん** · 2016/02/28(日) 06:20:22.65

型が強いと言う理由でscala使ってる人たちは他の言語使ってるのかな？
型を中心に見た静的型付けの関数型言語としてはかなり微妙だと思うんだけど

**デフォルトの名無しさん** · 2016/02/28(日) 10:05:13.94

>>280
webアプリ作るとかだと他に選択肢あるっけ？

**デフォルトの名無しさん** · 2016/02/28(日) 10:15:59.48

>>281
OCamlとかHaskellとか。手抜きがしたいならF#。
Webは書けない言語のが珍しいんじゃない？

**デフォルトの名無しさん** · 2016/02/28(日) 10:20:56.50

F#はセンスいいよな
あれJVMで使えたらいいのに

**デフォルトの名無しさん** · 2016/02/28(日) 12:07:15.32

>>279
理論上そうだけどまともなプログラマーなら Any で型指定することなんてまずあり得ないから

scala の型が強いって思ってる人いるのかね？

**デフォルトの名無しさん** · 2016/02/28(日) 12:16:43.25

>>284
いないならこっちの早とちりだった。

>理論上そうだけどまともなプログラマーなら Any で型指定することなんてまずあり得ないから
型注釈を書く頻度が多くて面倒くさくないですか？

**デフォルトの名無しさん** · 2016/02/28(日) 12:35:19.07

>>285
面倒くさいけど、結局 Haskell でも分かりやすさ求めてみんな関数の型注釈はちゃんと書くじゃん？

**デフォルトの名無しさん** · 2016/02/28(日) 12:53:49.70

普通のプログラミングならscalaの型推論あんまこまらないけど（foldLeftやfoldの最初の引数に型書かなくちゃいけなくて面倒くらい）
scalazとかになると途端に厳しくなるな
後関数(methodじゃないよ)や値が多相になれないのもキツイ（まぁ普通は困らないけどさ）

**デフォルトの名無しさん** · 2016/02/28(日) 13:18:09.60

自分もscalaにそこまで求めてませんよ。気にはなりますけど。
Java資産を有効活用できるからこそ、有意義な言語なのに、
そこ削ってまで突き詰める必要ないと思いますし。

**デフォルトの名無しさん** · 2016/02/28(日) 13:21:45.18

>>286
すみません、注釈はあまり書かないですね…。
Haskellは勝手に上に推論しないので。
さすがにIOUArrayなどは書きますけどね。

**デフォルトの名無しさん** · 2016/02/28(日) 13:25:15.31

また早とちりしてしまった。
型変数での指定なら、確かに思いっきり書いてますね。

**デフォルトの名無しさん** · 2016/02/28(日) 15:57:21.07

>>288
Scalaの型推論が残念なのはjava資源云々というより
継承ベースの型理論と型推論が相性悪いって感じかと

**デフォルトの名無しさん** · 2016/02/28(日) 18:09:46.42

>>291
自分もどれには同意です。
型を強力にすると、Java資源が使いにくくなる。
それが他のJVM言語が流行らない理由かと。

**281** · 2016/02/29(月) 08:25:02.28

>>282
書けない言語のほうが少ないだろうけど、書きやすい言語がいいなあ…
haskellとか一度触って投げてるし、他は触ったこともないので
とりあえず一度やってみます。

**デフォルトの名無しさん** · 2016/03/01(火) 00:39:50.34

ocaml も haskell も web 書けるけどそれは書けるとは言わない。(そもそも用途が違うけど)

**デフォルトの名無しさん** · 2016/03/01(火) 06:43:55.89

それをいうならScalaもフロント周りはかなり無理があるぞ
関数型はあくまでモデル記述に使うものだよ
F#なんかは明確にそう位置付けられてるね

**デフォルトの名無しさん** · 2016/03/01(火) 11:32:52.73

ツイッターでScala勢がKotlinを警戒敵視し始めてて草生える

**デフォルトの名無しさん** · 2016/03/01(火) 13:35:11.91

フロントはどうせjsで書くんだから、そもそもscalaが踏み込む必要がないやん
まぁscalaJSとかあるけど

**デフォルトの名無しさん** · 2016/03/01(火) 15:39:06.49

>>296
って主に水島さんやん
あの人は言語オタで昔からあんな感じだしな

**デフォルトの名無しさん** · 2016/03/01(火) 15:43:50.60

ScalaはJVMで動いていてjavaのsdkやライブラリ使い放題(実際使うときにはラップするけど)
なのが有利

**デフォルトの名無しさん** · 2016/03/01(火) 16:23:18.56

コトリンは名前がな…
do式的なのあるっけ？

**デフォルトの名無しさん** · 2016/03/01(火) 16:24:34.39

yield構文はサポート予定らしいけど
scalaのfor yieldに相当するものかどうかは不明

**デフォルトの名無しさん** · 2016/03/01(火) 16:54:17.68

わざわざyieldと言うからにはC#やPythonみたいなyieldじゃね
Scalaのyieldなら要らんわ
紛らわしいだけ

**デフォルトの名無しさん** · 2016/03/01(火) 20:19:13.01

まあそもそもscalaのoption型みたいなのないみたいだから
do式っぽいのあってもそんなにうれしくないよね

**デフォルトの名無しさん** · 2016/03/01(火) 20:24:03.06

>>303
いや、optionくらいはあるんじゃね？
数年前にできた言語だぞ？
あってもmapとflatmapなかったら終わってるがそれは流石にあるだろ？