プログラミング言語 Scala 11冊目 [転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
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の連載記事、各々で開かれた勉強会の資料などがあります。 今のままでは絶対に普及しない
仕様とライブラリの大掃除を行ってカオスを脱しない限り ナウなヤングにバカ受けと話題のScalaを勉強しようと思ったけど、なんだこの言語
仕様から文法からとんでもない煩雑具合に見える
これって脳に回復不能なダメージを与えるんじゃないか？引き返すべきか？ 最近スレ伸びなすぎワロタ
Scalaはもうやめたの？みんな今は何をしてるの あとはJavaにcase classとパターンマッチさえあれば完全に用無しだね
まあ今のJava8と比べても色々犠牲にしてカオスに飛び込むほどの魅力がScalaにあるかというと
一般的な感覚では割に合わないだろうね 型推論すらないJavaにいくらラムダがついたところでまったく食指は動かないなぁ… Java8使ってて不満なのは通常使われるデータ構造が関数的じゃないところかなぁ。
構文の煩雑さは心頭滅却して我慢できないこともないが。 Javaは標準のコレクションライブラリーが不便すぎて泣く 一度Scalaを堪能したらもうJavaには戻れない 不人気な言語採用すると保守のコストが上がってしまうんだよね
Javaなら10年後でも普通にいる
しかしScalaは果たしているのかどうか…
近年いろんな言語出て来てるけど無意味な競争で何れ元に戻る未来しか見えない Scalaぐらいまで普及すれば気にするほどのことでは
言語の将来なんて誰も読めないんだし
今、COBOLerやFORTRANerを探そうとしたら苦労するでしょ？ COBOLやFORTRANなんか経験無くても誰にでも使えるよ
オブジェクト指向になると誰でも簡単にというわけには行かないが、
ドカタワールドの偉大な発明である「Javaの姿をしたCOBOL」スタイルを採用すればJavaでも難易度は低い
もちろんScalaでもCOBOLのようなコードは書けるけど、そういう形で普及させることに意味があると思う? >>18
本屋に行けばわかるけど全然ない
今のままだと一部で使われて10年後に何それ状態だと思う >>18
CやCOBOLはそれぞれ確実に普及した時期があったからね
それを経て今は活躍の場を縮小し各分野に特化して地位を確保してる
Scalaにそれができるかと言ったら無理と思う
Java採用すれば技術者は数多な訳だし >>20
プログラミングの本なんて今はamazonでポチる時代だからねぇ
コップ本なんて特にクソ高いから本屋になんて置けないよね… >>21
そのJavaもCOBOLなどと同様の流れになってきてるしね
安い技術者を確保したいという経営者目線に技術者が乗っかる必要はないよ
乗っかったところで安く使われるだけ >>17-18
JVM に寄生する中途半端な言語もどきだから
バージョンアップの具合によっては一発で消えるべ >>23
マイナーな言語でもそれでなきゃいけない分野があるならマイノリティになるのは美味しいが、
問題はScalaじゃなきゃいけない分野というのが特に無いことだよ
マイナーな言語の利用を、生産性の向上だけを理由にして正当化するのは難しい >>25
生産性の向上だけって、他に何があるの？
やっぱり経営者目線で語ってるだけじゃん
技術屋はそういう目線に乗っかる必要はないんだよ
どこでもいいから安くてもいいから雇われたい、ってのならJavaでもPHPでもやってれば？
技術屋は興味のある言語を好きなだけ勉強すれはいい
その勉強に割くリソースがもったいないとか言い出すのならそれは技術屋に向いてないから
別の業種を探せってこと >>26
その技術とやらが「Scala言語に詳しい」だけじゃあまりにも弱すぎる
で、それで何ができるの? と考えるのは経営者に限ったことか?
そんなもん学会の研究発表でも突っ込まれるぞw >>27
Scalaスレに来てScalaは覚えても無駄だからやめとけってネガキャンする奴らって
結局何が言いたいんだろう？
リソースの無駄ってことなのかなぁ？ 言語が普及するかは市場が決める
それは上流の各SEにその権限あるわけだがネット時代とはいえ本屋にろくにないからどう思ってるか気になってね
俺は本はネットよりまとまって入門に必須と思ってるからさ >>29
だから何が言いたいのかな？
「わざわざ」ScalaスレにきてScalaを貶めようする動機って何？ >>30
貶めるつもりはないそれは誤解
言語を学ぶ上でいくつかに絞る材料としてScalaの展望どうなのと思って聞いただけ
それは勉強した人間に聞くのが一番早い
SEやってる人間が大半で現場の採用推移とか肌で感じてるだろうし >>30
普及しない理由を言ってるだけであって、Scalaを貶めてるわけでもないし
覚えるなと言ってるわけでもないだろう
普及率とその言語を覚えるべきかどうかは別問題じゃなかったのか?
普及率にコンプレックス持ってるのは君自身じゃないのかな >>31
だったら>>17みたいなレスは不要だよね
>>32
だったら>>27みたいなレスは不要だよね 一つ余談だけどかつてDelphiという言語と統合環境が存在した(今も存命w
当時のVCと比べてVBよりも遥かにGUIの生産性が高くライブラリの敷居も低かった
今のC#の開発環境が当時あったと考えてもらえばいい
しかし残念ながら認知度や先行きの不透明性から生産性の低いVB敷居の高いVCが採用され淘汰された
認知されていくこと本が出回ることは今でも重要と考えてる根拠ね >>33
外から見ると参考書が皆無で劣勢
じゃあ中にいる人間なら根拠を持って反論するかなと思って Scala最近よく聞くけど、
開発案件とかあるの？
なんか、普及にはまだまだ時間がかかりそうな気がする。 PlayFrameworkの開発案件がほんの少し流れてる
これはJavaでも開発できるんだが、Scalaを採用している所の方が多いようだ
Scalaのフレームワークはほとんどないから、
従来のJavaのフレームワークたちに勝てれば、もしかしたら時代が来るかもな TypeSafeはreactive programming/systmを推してるな。
穿った見方をすると、Scala単体の魅力がそこまでじゃないってのが
まあわかってきて、次なるネタとしてリアクティブを推していって、
（Scalaである必然性はそこまでないけど）Scalaならライブラリあるし
みんなやってるからScala使いましょうみたいなマーケティングに
シフトしている気がするな。
Javaがサーバーサイドに転換したときと同じ気配を感じる
Javaの転換は（普及という意味では）潮流の変化にうまく乗って
成功だったと思うがScalaはどうだろうかね Sparkみたいな特定の小さなドメインに限れば勝機はある
「オーバーヘッドの比較的少ないスクリプティング言語」という位置付けなので
Scalaでないといけない必然性は全く無いが そろそろTypesafeも逃げるかもな
そうなれば完全に終わり scalaってscalaなんたらとかscaなんたらみたいなライブラリ名多いよな
だから何って訳じゃないけどさ キラーアプリがないとね
あれだけなんだかんだ言われてるRubyだってRailsのおかげで現状のシェアなわけだし
playも悪くはないんだけど、ここそこにこなれてない感が拭えない部分があるからなー Playはimplicit多すぎ型にうるさすぎ
Scalaに必要なのはASP.NET MVCやSpringみたいな素直で普通なフレームワークだよ implicit は慣れれば別にどうってことないし、型にうるさいのは型安全を目指してるんだから
当たり前の話
それよか貧弱なi18n対応とか、validation がそこかしこに散らばってるのとかそういう
部分だと思うけどなー それ以前になんでScalaを選択するのと聞かれたときに説得力のある根拠を用意できない Playのバリデーションは各フォームのエラーメッセージの順番を保持しない
入力項目の数だけviewにfor文を書くはめになって、俺の怒りが有頂天になった
>>55
それはどんな言語でも一緒じゃね？ 選ぶ理由なんて「好きだから」でいいよね
node.jsとの2択になったとき「Scala好き。JavaScript嫌い」で押し通したし ☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。 ２０１５ 給料ランキング一位だったから覚えようと思うんですが
javaの知識無しでscalaの学習しても問題ないですか？ 問題ない
javaの知識が必要な部分が出てきたらその都度学習すれば良い 実務で使うつもりならJavaできないと全く意味ないし
教養としてならHaskellやったほうがいい 実務で使いたいならそういう方向に誘導する力は必要だろうね
力とは別に権力だけじゃなくて、実行力とか説得力とか「Scalaに対する熱い心」とか
色々あると思うよ >>59
ある
Javaを倒し踏み越えることが出来ぬものがScalaに挑んても何の益もない >>63
hrog.net/2015102624991.html >>59
Javaの方が汎用性高いからJavaからやったほうがいい
Scalaは新しいモノ好きな会社が手を出してる段階だから単価高いだけで数年で他と一緒になる
もしくは消えてる可能性もある
まだ情報多くないからScalaからやるのは時期尚早 たかが開発言語ごときがスキルセットの重要な位置を占めてる時点で、Scalaみたいな意識高い系ワールドはまだ早い
いくつかメジャーな言語を経験して、言語なんてどうでもいいと思えるようになったらおいで JavaやらないでScalaやっても楽しさはわからないだろうしね
Javaやってなにこれめんどくせーと感じるようになって、node.jsとかスクリプトやってなにこれ
型欲しいーって感じるようになって、それから来ると楽しさが分かるようになるんじゃないかな
どっちにしてもScalaを実務でやるには自分で主体的に動けないとなかなか機会はないだろう
から、給料目当てでやってるうちは意味ないだろうね 尖ったものを現場で使いたいなら、俺の技術で会社をリードしてやる、くらいの強烈な主体性が必要
それがなければ、新しいものを使える環境へ入ったとしても
技術的な裁量を持てず言われたとおりにやるだけでCOBOL工と何も変わらん
もしくは技術評価部門(笑)という名の社内ニートが関の山 >>69-70
Scalaの給料が高いという記事についても、
X Scalaが使える→給料高い
O Scalaを使おうとするぐらい主体性があり技術力もある→給料高い
なんだよね、きっと
俺は「何使ってもいいよ」って言われたときはScalaを推すぐらいの程度だけどねｗ >>72
初期はRubyOnRailsでやってScalaに移行ってのが実は一番合ってるのかもね
ScalaはJavaエンジニアよりはむしろRubyなどのスクリプトエンジニアからの移行の方が
抵抗が少ないって言うしね いつまでもC言語とかC++のような低レベルで危険な言語が普通の開発で
使われつつけている現在の状況が改まらない限りは、世の中は安全に
ならないし、プログラミングの生産性も低いままだ。 高級言語とやらは安全と無責任を取り違えてるだけだべ >>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 …はだめですよね、はい 09:40
〜18:10
放送中 ScalaMatsuri 2016 1日目 メイントラック
lv249050979 10:00
〜18:00 ScalaMatsuri 2016 2日目 メイントラック
lv249051017 仕事でscala使ってるところって型クラスとかバンバンなん？
optionモナド便利とかimplicit最高とかで満足してるレベルの人は厳しい？ それでjava8と比較したうえでメリットがまさると判断したんならいいんじゃね？ >>182
型クラスバンバンはライブラリ製作者じゃないかな
仕事で使うならそこまでバリバリに使わなくてもいいとは思う 自分が型クラスを定義してやる事は殆どないと思う
たまにフレームワークやライブラリが型クラスのインスタンスを要求する事があるからそんときに
implicit val fuge = new TypeClass[Fuge]{...} みたいな事やるくらいかな
型クラスおじさんがいる現場は知らないです 好きにやっていいそうだからいっそScalaとSparkを導入したいが、
全く新しいこと知らないカスSIerで自分以外にメンテできる気がしない >>186
好きにやっていいとはいえ、仕事なんだからオワコンScalaを選んだ理由は必要だろ。
それが相手が納得できるように説明できるならいいんじゃない？ 本当に終わるんなら理由として十分かな
下手に長生きされたほうが面倒くさい Sparkでなんとか話題を保ってるけど、正直Scalaが普及の足を引っ張ってる感しかないな
データ分析はJavaかPythonで新定番が出てきたらあっという間に消えると思う >>186
COBOLだってメンテされてんだ
お前が作ったものが会社にとってどうしても必要だというならScalaプログラマぐらいちょっと本気で
探せば見つかるレベルなんだから心配すんな python はほんとやめて欲しい
java は言わずもがな 結局マクロは頓挫したの?
ダメならダメで綺麗さっぱり削除してほしいな
またゴミが増える experimentaじゃなくって正式にscala標準になるってのがscala.metaってだけ
つかマクロ使ってるライブラリがバリバリあんのに削除したらそれこそオワコンになるのでは
>>191
scala祭りが盛況だったのにオワコン化にすんなよ。。
つか大企業が普通に使ってるのになんでオワコンオワコン言ってる人がいんのか理解できん アンチだろ
枯れた言語だしjavaが機能的にscalaに追いつかない限りオワコンにはならないと思う ビッグデータというとPythonが浮かんでくるがこれじゃあかんのか？
そもそも企業がビッグデータを解析するってなったときは、
いちいちコードなんて書かないで、AzureみたいにGUIでぱぱっとやる方向に進んじゃうんじゃないか？ ビッグデータというかその基盤を作るために使われてるね
あくまでJVMがどうしても必要なときのベターJavaとしての選択なのであまり広がりはない
実際にデータ解析する人が使うのはPythonとRだよ >>202
Scalaの花形は基盤領域だよ
Webアプリでも大量のメッセージのストリーミング処理や大規模バッチ処理
Javaが進んでる分野だからね
カジュアルなWebのスクリプトとして使うには面倒臭すぎて割に合わんよ sprayみたいなかなり早くて軽いREST APIなのもあるじゃん
特にあのルーティングの定義は他の言語では中々難しいし(HListとマグネットパターン) 確かに単純なwebアプリを作るとかだとたしかにruby使えよって思うな
重いバッチ処理があるとか
非同期ですぐレスポンス返す必要があるとかだね>scala
playはformのバリデーションの型付けがとにかく面倒で 簡単なものつくるにしてもrubyとかだと固まらない粘土で像つくってるみたいで不安が拭えない勢 フロント寄りのところは固めたそばから変わるからほとんど意味無いけどね
奥の方の頻繁に変わらなくてスループットが重要なところに使うのが正しい >>206
Rubyは粘土で作ってる感じ
作り上げてもすぐ変形しそうだけど、逆に言えば変更には柔軟
Scalaは型枠を作ってそこに材料を流し込む感じ
かっちり作れるけど変更するときはうまく型枠を変形する技術がいる ruby は言語自体は好きだけど周りのツールとかが面倒くさいんだよな 「変更のしやすさ」は色々あってフロント側の変更は型安全なところが面倒だけど
逆にビジネスロジックで少し変更がしっかりとコンパイルエラーになるからむしろ動的型付けより
変更が楽に感じる 同意
フロントでフォームを型付けしたりとかはガチの阿呆 >>211
ビジネスロジックなんてテスト書くの必須なんだから動的静的はあまり関係ない気がする
どちらかというとスループットの方がScalaのメリットじゃないか そもそも静的型や関数型の堅牢性のメリットが得られるほどビジネスロジックが複雑な分野でScalaが使われてるかっていうとね
Web系ばっかりで、スループットくらいしか恩恵がないのが現状
業務系のドカタITは自動テストなんてまず無いし業務ロジッククソ複雑だし頻繁に更新しないし論理的な正しさが最重要だしで
まさに静的型の関数型言語向きなんたけど >>213
なんかいつもの動的型付けvs静的型付けになるけど型は証明だけどテストはそうじゃなくてテストが全部網羅してるわけではないので安心感が違うというか
例えばDBのあるcolumnがnot nullになった場合にOption[A]をAに変えればいいけどこの影響を全部テストでカバーできるかっという不安 >>213
テストはどっちにしても必須なのは同意だけど、書かないといけないテストの量が段違いやん？ アドテクやってないお前らがアドテクで使われてますって喧伝しても滑稽なだけなんだが アドテクってビジネスロジック複雑なのか?
スループットが重視される好例としか思えないんだが バッチ処理なんかは結構複雑
逆にスループットはそこまで求めてない
>>219
実際うちは使ってるわけで >>221
え？バッチ処理こそ速度命だろ
そもそも時間がかかるからバッチに回してるわけなんだし 開発と運用が簡単だからリアルタイム性が必要ない処理を安易にバッチにするというのはドカタITじゃ珍しくないよ というか、計算機資源をうまく使うためのバッチは、常套手段でしょ。 scalaはバッチ処理にはかなり重宝してるわ。
ある程度速いし、コレクションメソッド山ほどあるし、並列化も超簡単だし、ジャバも呼べるし >>222
リアルタイム性は重要じゃないので言語の速度（という言葉は正確じゃないけど）はんな重要じゃなくて
いかに並列にするかスケールするかとかの方が重要
時間は早いに越したことはないけどデータウェアハウスなんか使う場合はIO待ちの方が多いしね scala2.12-の新しいのが一向に出て来ないのは何でなんでしょうか？
詳しいかた教えて下さい。 >>230
まだScalaでAndroidやってんのｗ >>231
コトリン使えってこと？
コトリンってscalaの劣化版じゃないの？ Android+Kotlin流行りそうだし、Javaに次ぐJVM言語の座は1年後にはKotlinになってそうだなｗ Scalaの劣化というより改良といっていいと思う
Scalaと違ってまともな取捨選択のセンスがあるってだけで十分乗り換えるモチベーションになるよね Kotlinはbetter Javaの領域をまったくはみ出していないという点では、Scalaとは別物だろう >>236
具体的には?
一般的なScalaらしさってほとんどは言語仕様ではなくあのカオスな標準ライブラリによるもので、
implicitを除けば大部分はKotlinの範囲で問題なく実装できると思うが そのカオスな標準ライブラリでimplicitめっちゃ使われてる(collectionや型クラス)のでむずくね？
型消去対策が最初からしっかりしてるのはいいところ
後 委譲用の構文があるのはいいよね scala の for 式に相当するものとパターンマッチがあればあんまり文句はないが… scalaは十分に枯れているので
androidではなくサーバーでkotlinを使いたいとは思わない 言語仕様はscalaで、VM言語じゃない言語が欲しい。近いのはrustかswift？ Scalaパズルは固定レイアウトかぁ
逆引きレシピも半額だね 出版社的には前からkindle半額セールあるみたいなので、今後は考慮して買うしかないね。 >>243
翔泳社全点半額セールってことで早速購入したけど、電子書籍って微妙に扱いづらいな >>248
読み物はそうやけど
マニュアル系は紙のほうがよくね？ 逆だろ
マニュアルは検索性能が大事だから電子媒体の方が強い 電子書籍は形式によって読みにくかったり検索しにくかったりするので当たりハズレがある
紙書籍で読みにくい書き方・編集・構成のものは電子書籍になっても読みにくい
紙書籍は一度通して読んでればだいたいどの辺に欲しい情報が載ってるか分かる
一度通して読むのは初めて学習するときくらいしかないがパソコンの脇に置いておいてもすぐ探せる
利点は電気機器を使えない場所でも読める。欠点は場所を取る、持ち運びに重い。
また複数のジャンルにまたがる情報が必要なときその分だけ紙書籍を揃える必要があり糞邪魔
紙書籍は通して読むのでなくリファレンスマニュアルのような字引きとして使うには邪魔で不便
検索機能のある電子書籍のほうが便利な場合が多い（もちろん前述のとおり書籍の形式次第だが)
数千ページを１つのPDFやHTML1ページにまとめたタイプとか俺としては使いにくいので嫌い
電子書籍サイトの専用アプリで閲覧するとき同時に２冊以上を展開できないタイプもあったりするので
電子書籍で読む場合は形式等を十分に考慮するべし Kindleの固定レイアウトは勘弁
検索もできないし、マーカーも引けない
Kindle版のScalaパズルがそれ たまにはGroovyのこと思い出してあげてください。 swift がサーバーサイドに入り込んでくるっぽいな
scala は java のおかげで地位は確保できるだろうけど Goとかマジで持て囃されはじめてて引くわ
Rust, Swiftの方がマシだ go は if err !＝ nil 書くゲームだからな。
optionモナドに慣れてる人間からしたら我慢ならん。あとGenericsがないせいで事実上リストの高階関数が作れないのも終わってる。モダンの欠片もないロクでもない言語だわ Android用のGroovyそのまま使えてメッチャ楽なのに
何でみんな使わないんだろ？
Android開発でscalaとか正気の沙汰じゃないと思うけど >>259
静的なOptional/Nullableに慣れてる人からすると
scalaのモナドを動的マッチングするのもかなり我慢ならんけどね >>260
GroovyとJavaとかRubyとかPHPを比較するならわかるけど
Scalaと比較するのは方向性からして間違ってない？
Scalaを選択した人が求めているものはGroovyにはないと思うの（逆もしかり） >>261
静的なOptionて何？
おれはfor式で複数のモナドをまとめて扱えてハッピーくらいにしか思ってない人間なんだけど >>263
Scalaを選択してしまった大半の人が求めているのはLightweight Java
まあ実際使うと全然Lightweightじゃないことを思い知るんだけどね Groovyって型書けるんだな。。
今後新規で泥アプリの開発することあったらKotlinとどちらを採用するか悩むな
Scalaで書けるならそれが一番良いのだけれど >>266
scala でAndroidは環境整えたりライブラリアノテーション有功にしたりがとにかく面倒。
それ以降は快適そのもの…と言おうと思ったがコンパイルが面倒 >>265
それはないわ
関数型というオブジェクト指向とはまったく違うパラダイムを前面に押し出してるのに
Better Javaだと思い込んで選択してるんだとしたら、それはただの調査能力不足かと >>265
あんだけ関数型を前面に押し出してるのにそう思う奴いねーだろ 型クラスのインスタンスはScalaではtraitのサブクラスのオブジェクトだから
それに対するコールは動的バインディング（＝動的マッチング？）になるって事では？
仮想関数の呼び出しコストすら看過できない
めちゃパフォーマンスクリティカルなシステムを組まれているお方なのかなと ガチな方の関数型には動的ディスパッチなんか無いからな
速度云々じゃなくて不確定な振る舞いが存在するのが問題なんだよ haskellで instance で自分でモナド型を宣言して使うのって実質的に動的バインディングと同じじゃない？
virtualメソッド呼び出しの何が問題なのかもイマイチ分からんのだけど >>265
少なくとも自分はJavaより強力な型システムを求めて辿り着いたわ
Better Java的な使い方にとどまるならGroovyを選んでたと思う >>267
最近泥Scala環境見直しけど、以前に比べると環境構築自体は大分楽になったと思う
確かここを参考にしたはず
https://tanoshiilife.wordpress.com/2015/12/16
Scaloidも便利なんだけどハマりどころが多い気がする
まあ、コンパイル時間の問題は解決しないけどなー >>273-274
haskellとかだと、コンパイルリンクした時点で、
実行時に呼び出される関数が確定してるって意味でしょ
たとえ自分で宣言したモナド型であってもね >>277
いやそうだろうけど、haskellでも多相にできるんだから、その型を使う側からしたら振舞いは不確定じゃん？
というかその不確定さが多相、多態性の売りなんじゃない？
scala でもコンパイル時にチェックはしてるんだから変なメソッド呼び出しにはならないし >>278
scalaはAnyがあるので、haskellと違って型推論だけで判断してません
型のマッチングは動的になってる 型が強いと言う理由でscala使ってる人たちは他の言語使ってるのかな？
型を中心に見た静的型付けの関数型言語としてはかなり微妙だと思うんだけど >>280
webアプリ作るとかだと他に選択肢あるっけ？ >>281
OCamlとかHaskellとか。手抜きがしたいならF#。
Webは書けない言語のが珍しいんじゃない？ F#はセンスいいよな
あれJVMで使えたらいいのに >>279
理論上そうだけどまともなプログラマーなら Any で型指定することなんてまずあり得ないから
scala の型が強いって思ってる人いるのかね？ >>284
いないならこっちの早とちりだった。
>理論上そうだけどまともなプログラマーなら Any で型指定することなんてまずあり得ないから
型注釈を書く頻度が多くて面倒くさくないですか？ >>285
面倒くさいけど、結局 Haskell でも分かりやすさ求めてみんな関数の型注釈はちゃんと書くじゃん？ 普通のプログラミングならscalaの型推論あんまこまらないけど（foldLeftやfoldの最初の引数に型書かなくちゃいけなくて面倒くらい）
scalazとかになると途端に厳しくなるな
後 関数(methodじゃないよ)や値が多相になれないのもキツイ（まぁ普通は困らないけどさ） 自分もscalaにそこまで求めてませんよ。気にはなりますけど。
Java資産を有効活用できるからこそ、有意義な言語なのに、
そこ削ってまで突き詰める必要ないと思いますし。 >>286
すみません、注釈はあまり書かないですね…。
Haskellは勝手に上に推論しないので。
さすがにIOUArrayなどは書きますけどね。 また早とちりしてしまった。
型変数での指定なら、確かに思いっきり書いてますね。 >>288
Scalaの型推論が残念なのはjava資源云々というより
継承ベースの型理論と型推論が相性悪いって感じかと >>291
自分もどれには同意です。
型を強力にすると、Java資源が使いにくくなる。
それが他のJVM言語が流行らない理由かと。 >>282
書けない言語のほうが少ないだろうけど、書きやすい言語がいいなあ…
haskellとか一度触って投げてるし、他は触ったこともないので
とりあえず一度やってみます。 ocaml も haskell も web 書けるけどそれは書けるとは言わない。(そもそも用途が違うけど) それをいうならScalaもフロント周りはかなり無理があるぞ
関数型はあくまでモデル記述に使うものだよ
F#なんかは明確にそう位置付けられてるね ツイッターでScala勢がKotlinを警戒敵視し始めてて草生える フロントはどうせjsで書くんだから、そもそもscalaが踏み込む必要がないやん
まぁscalaJSとかあるけど >>296
って主に水島さんやん
あの人は言語オタで昔からあんな感じだしな ScalaはJVMで動いていてjavaのsdkやライブラリ使い放題(実際使うときにはラップするけど)
なのが有利 yield構文はサポート予定らしいけど
scalaのfor yieldに相当するものかどうかは不明 わざわざyieldと言うからにはC#やPythonみたいなyieldじゃね
Scalaのyieldなら要らんわ
紛らわしいだけ まあそもそもscalaのoption型みたいなのないみたいだから
do式っぽいのあってもそんなにうれしくないよね >>303
いや、optionくらいはあるんじゃね？
数年前にできた言語だぞ？
あってもmapとflatmapなかったら終わってるがそれは流石にあるだろ？ nullable型ってのはあるけど
コレクションライクなscalaのoptionとは大分違う印象 nullableは言語に組み込むC#方式だね
flatmapみたいな醜いノイズがないのはいい むしろScalaはなんでoptionalを言語に統合しないんだろうな
Haskellにないものは間違ってるみたいな変なコンプレックスがあるんだろうか >>306
>flatmapみたいな醜いノイズがないのはいい
flatMapはただのメソッドなんですけど。。
つかflatMapがなかったらモナドになれないので
for{
name <- nullable
age <- nullable
}yield User(i, j)
みたいなのできないじゃん(これはモナドじゃなくてアプリカティブだろってつっこみはなしで)
>>307
逆に組み込む必要がよく分からない Null型を特殊に扱わないほうがいい
本当はNullは型だけあってインスタンスのnullはないほうがいいけどjvm上で動く言語なのでそれはできないし >>306
flatMap のどこがノイズなんや？
むしろ必要としか思わないが >>308
val name = nullable
val age = nullable
val user = name?.let { age?.let { User(name, age) } }
この例に限って言えばnameやageが2回出現してしまってるしletというノイズも入ってて美しくないけど、
実際には単純な if (x != null) x.hoge() else null のパターンの方が圧倒的に多いんだから
そういうときにもいちいちflatMapを唱えるのは冗長だろう
型名が何でもかんでもOptional[〜]になっちゃうのもスマートじゃない >>310
if 1発で書けるんならね？
map と flatmap の良さは合成するモナドの数が多い時に for 式が使えることなのにそれは例が悪すぎるだろ >>310
Optionだけを考えてるからそう思うだけだよ
モナド全てが統一的に扱えることによる便利さの方を取りたいね >>308
>本当はNullは型だけあってインスタンスのnullはないほうがいいけどjvm上で動く言語なのでそれはできないし
界面でNull非許容にして実現してるJVM言語はあります
>>311-312
Option(Maybe)はnullのハンドルを強要するだけの型だよ
モナドでなくとも推論で排除してくれるなら十分
モナドを扱う＝高度な技術とでも思ってるなら大間違い >>313
Option(Maybe)はnullのハンドルを強要するだけの型だってことくらい誰でも知ってるし、
モナドを扱う＝高度な技術とはだれも言ってない
イマイチどの発言に対しての反論なのか分からん。null 推論してくれる言語ってのも具体的に何か書いてくれ >>310
なんか勘違いしてね
その下の例ならflatMap使わないというかむしろ使えない
mapのパターンじゃね？ ceylonの事ならnull自体は存在しちゃう
そうじゃなくてScalaのNothingみたいにAnyRef型のサブクラスでinstanceがない
Null型があればいいんだけどjavaとの互換性考えるとインスタンスのnullは必要になっちゃわね？ あとflatMapって名前が嫌なら>>=って記号もscalaZとかにはあるべ >>318
>>= は演算子の優先順位の関係でやや使いにくいんだよなぁ >>317
nullを想定しない前提のjvm上の言語ならあるよ
もちろんffi部分でOptionなどを使わないと大変な事になるけど Scalaを使うプロジェクトがあまり増えてないからScalaの技術者が増えない
Scalaの技術者がいないからScalaを使うプロジェクトも増えない 意識高い系のおもちゃで終わった感がある
日本に登場するのは早すぎたかもな Sparkも一時期祭り上げられたけど結局みんなPythonっていうね Scalaって技術書ほとんどないよな
洋書は結構あるけど
和書がこれだけ少ないと流行らない Scalaパズル読んだけどこの先Scalaを使うことを考え直したくなる本だった
完全に破綻してるんだなこの言語 海外は新しい言語にすぐに飛びついて試したりするから早い段階からScalaを検討し始めた
GoogleやFacebookがオープンソース化したSwiftに関心を持ってるらしいし
日本は前例主義でどこか実績のある言語にしか興味がない
新しい言語について説明する書籍も早い段階で出てきたりしないし
海外で普及し始めたころに海外で出回ってる書籍の日本語翻訳本を出したり
遅すぎるんだよ IT後進国ｗｗｗｗ国民はスマホでソシャゲとLINEｗｗｗｗｗ
没落不可避ですわ >>327
ScalaやっててがScalaパズルの例とかが問題になる所は殆どないから安心しろ
scalaで困るのはsbtがとっつきにくいとかコンパイル糞遅いとかそういう所
>>326
書籍ならコップ本とscala逆引きがれば十分じゃないか
ネット上で情報はいくらでも転がってるし、なかったらtwitterなりgitterなりで聞けば大抵答えてくれるぞ
なんかたまに流行らない言うてるのはなんなんだ
毎週勉強会が開催されてたまに大きなイベントも開催されてて大企業も使ってるんだから十分流行ってるだろ 2016年4月プログラミング言語人気ランキング
ttp://pypl.github.io/PYPL.html >>333
Swiftの1/3もあるってすごいやん！ M4がやっと出ましたね。
いつ頃2.12リリースされるんでしょうか？ 夏頃だろうね
ってか2.12ってなんか目玉機能あったっけ？
Java8対応なんてJava->Scalaの呼び出しが便利になるぐらいしか意味ないと思うんだけど 言語としては面白いよねscala
コードを読むのがパズルみたいで頭の体操になる
実際仕事では絶対使いたくないけどね >>337
パズルだと思ってるうちは仕事では使いたくないだろうな
他の言語と同じでイディオムを覚えれば普通に仕事でもいけるんだけどね scala普通にパターンマッチとコレクションとcase classが便利くらいの理解で仕事でもいけるゾ Programming in Scala, Third Edition
http://www.artima.com/shop/programming_in_scala_3ed
コップ本原書は、2.12対応した第3版が出たようだ。
紙の本は、5/2に出荷するとのこと。 C++はハマリどころが多いだけでそれほど複雑ではない
Scalaはハマリどころが多い上に概念が本質的に非常に複雑 c++はマルチパラダイムだけどそれぞれ別々だがcに引っ張られる、
scalaはpi計算で統合してるがJVMに引っ張られるってやつでは。 Scalaが実際複雑か否かは別として
C++が複雑じゃないって言う人の主張には説得力が感じられない implicit関連は複雑だと思うけど
後はあんまり複雑だとは思わない lvalueとかrvalueとかcopyコンストラクタとかmoveコンストラクタとか 便利な機能を付け足して行くと複雑怪奇になるパターンか。 >>342は、馬鹿なくせにすべての機能を使いこなさないといけないと思ってる馬鹿
お前程度の知能の奴にしたら、ほとんどすべての言語に複雑な概念が含まれてるんじゃないか？
お前に理解できる言語なんてほとんどないからもうプログラミングやめちゃいなよ？ for文の代わりによくわからない面白関数を使うとコードが綺麗になって好き よくわかってない関数を使ってコードが綺麗になったとか言っちゃう子怖い scalaだとfor式にしてもfor文にしても flatMap,map,foreachの糖衣構文だから
for {f <- fuge} みたいに一つしか呼び出してないんなら普通のメソッド呼び出しの方が綺麗になるかもね scalaってperlと同じ匂いがするんよ
scalaしか関数型を触った事ない人がぐちゃぐちゃ書いてる感じが >>353
そうか？
Scala使う人間はHaskellも読めるって感じの人が多い印象だな、俺は
そういう人がScalaを使う理由としては、Javaの資産が大きいようだ >>354
むしろHaskell使ってscalazまで使い込んでる(読み込んでる)人間は
重いし汚いって印象だとおもうんよ… >>355
何を言いたいのか分からん
印象論でScalaを貶めたいだけならスレ違いだからどっか行った方がいいぞ >>356
scalazみたいなゴミ使ってまでFPするくらいなら
素直にHaskell使った方がマシ
って主張が読み取れたよ >>357
Haskellだけで閉じた世界で片付くならそれでいいけどね
Javaの資産は大きいのさ >>358
お前がHaskellerじゃないのに意見してる事は分かった プログラマには清濁併せ呑む寛容さが必要
言語設計や記述が如何に綺麗だろうが
どうせ実装しているロジックは泥臭いんだろ？ そんなこと言い出したらScalaなんて使わずJava8で良いって話になっちゃう
プログラマ集めるのもScalaよりよっぽど簡単だぞ 実際Java8で良いって話でしょ
Scalaじゃないとダメだって理由でScalaを使っている人なんているの？
無論Java8で良いとJava8が良いは同じじゃない じゃあ資産とか引き継ぎとか諸々考えたらJava8の方がいいし、
しがらみが無いならHaskellの方が優れてるので
Scalaはウンコってことじゃん Scalaは関数型言語の要素を持ったオブジェクト指向で副作用もバンバンする
Haskellと比べるのはおかしいせめてocamlとかだろ
Java8でいいじゃんって言われてもパターンマッチもないし全然比べられないよ 仕事ならScalaなんか使って他の誰にもメンテできないもの作って自分のケツをいつまでも拭き続けるくらいなら
Javaでもいいから新しいものを作って後は丸投げの方が楽しい 仕事でscala使ってる所なら周りがメンテできるよ 日本語版WikipediaのScalaのページのノートの部分にはScalaが関数型言語扱いに疑問を抱いてるコメントがあるね ・手続きが透けて見えるRuby系の構文のため、見た目があまり宣言的じゃない
・インフラ周りやWebでBetterJava的に使われることが多く、
いかにも関数型らしい使い方(業務モデルの記述みたいなの)は少ない
・オブジェクト指向言語として高機能すぎて、設計がOOに引っ張られやすい
・結局Javaのライブラリに頼るのでイミュータブル何それ状態
こんなところかな >結局Javaのライブラリに頼るのでイミュータブル何それ状態
これはあまりないな〜
大抵の事はscalaのライブラリでできるし
javaのライブラリを使う時もscalaでラップしてimmutableっぽく使うのはそんなに大変じゃない >>369
> ・手続きが透けて見えるRuby系の構文のため、見た目があまり宣言的じゃない
Ruby系ってなんじゃらほい？ブロック構文のことかい？
だとしても、それと手続きが透けて見えるとはまったく関係のない話だと思うが 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
； Playでブラウザ閉じたらログアウトされるの何とかならないの？
いくらRESTって言っても限度があろう >>376
というかセッション情報をメモリに入れたりredisとかに入れる事は普通に出来るよ github.com/t2v/play2-auth それはcache使ってるから避けたい
いつ何が消えるかわからないし、そもそも容量の少ないメモリに情報を入れるのが気持ち悪い いやこれ使えるキャッシュは選べるよ
Redisを使ってもおけ redisってなんだと思って調べたらばっちりの仕様だった
こんなのあったのか Scalaに興味を持つような奴らやその周囲ではRedisなんて常識の一つだが、
その辺のSES企業にいるエンジニアもどきは技術について驚くほど疎いよ Web系じゃなければ普通に知らないでしょ
お前らSparkとか分かるのか? Webは技術としてはわりと狭い分野だけど、
情報のネタと媒体が同一というアドバンテージのせいで自分達がITの全てであり最先端であるかのように錯覚しやすい 380だけどweb業界に入る前はAWSって何状態だったし
立ち位置によって常識が違うのはしょうがないと思う Scalaを使うプロジェクトがかなり増えてきたな
C#を追い越しそうな勢いだ 【悲報】俺氏、Scalaの提案を上司に断られる
理由「Scalaは難しすぎる。出来ない人でもわかる言語じゃないと仕事では使えない」 太平洋戦争の敗因の一つ
日本のゼロ戦は、米国の戦闘機3機分に匹敵したが、
運転するのに要する学習時間が、500:50時間だった
だから、パイロット500人が死んだときに、運転できる人がいなくなった Haskelみたいにそもそも概念が高度なのとは違って、本質的でない難しさだからね
過去の設計ミスの歴史でゴミだらけになってカオスになってるだけだから正当化のしようがないんだよな 使っちゃいけないゴミが大量に散らかってるから、
単純に「分からない?だったら勉強しろ!」では済まないのがScalaの難しいところ
チームで適切にGoodPartsを共有できてさえいればそれほど難しい言語ではないが、そこへ至るまでのコストは相当に大きい
GoodPartsだけを抜粋したサブセットを定義してドキュメントとして公開してくれたら業務でも導入しやすくなると思う 君はじつに馬鹿だな
上司でもわかる言語を選択しなかったのが失敗だ >>396
Swing APIとかいうdeprecated入り確実の糞の山 どうでもいいが出来ない人でも分かる言語なんかないと思う どうでも良くないが出来ない人でも分かる言語なんかない(確信) >>397,398
そんなライブラリ部分なんてどうとでもなるだろ
切り替え手順なんていくらでも転がってんのに
もっと言語として使っちゃいけないゴミを挙げてほしいわ XMLリテラル…ゴミというか、普通にみんな避けてるか xmlリテラルは俺も浮かんだがそもそも誰も使っていないという
昔のscalaの紹介記事だと宣伝されてたけど Scalaって短いコードが正義だとばかりめちゃくちゃやってない？
短いのは良いけどそれが他人に読めないようではゴミだと現場でもリーダブル・コードでも教わったけど、
それの真逆を行ってる気がする そもそも実用言語じゃないからねこれ
研究用の実験言語 実装を読み解かないと挙動が分からない時点で
読みやすさを論じる価値がない
「読み解くくらいなら自分で実装したほうが早い」
って思えるくらいの粒度ならシンプルな方がいいんでは？
別にゴルフやってる訳じゃないんだから
短く書くのは分かりきっている部分で
そこを冗長に書いたところで読みやすくはならない 記述の抽象度が高いのと暗黙的なのとははっきり区別して考えるべき
Scalaは関数型としてはそれほど抽象度は高くないかわりに後者による省略が目立つ 具体例を上げてもらわんとなんとも
暗黙の型変換の多用はうんちだけど カッコの省略は超大事
Rubyのブロックのような書き方はある意味衝撃だったからねー
あれを捨てるのはさすがにできない
Swiftもそうだしね 文法については、コンパイル時間が伸びなければ簡略化取り入れてもいいけど、
セーブするときはフォーマッターで;付きに整形したい派 >>410
fuge.method(hoge)を fuge method hoge みたいに書ける奴？
あれないと演算子を定義する時に演算子オーバーロード用の構文が必要になるよ >>413
騙されるな
結局、単項演算子や結合順序の問題があるから演算子オーバーロードには特殊なルールがある
それを「命名規約」と呼ぶことであたかも特別扱いではないかのように見せ、ブロガーを欺いている 演算子については、メソッドと演算子を統一的に扱うというアイデアに固執した結果、かえって複雑になっている感がある
あの「命名規約」が美しいとはあまり思わないな >単項演算子
単項演算子はユーザーがあんまり定義しないし
結合順序は末尾=がつくの以外はそんなに気にしないっしょ scalaって借金管理(こっちが貸してる方)のシステムを書くのとか得意ですかね？
数十件の利息、延滞金をミスなく計算したいので、型がしっかり(？)してて、
ライブラリ豊富そうだなと思い、聞いてみました。 そういうのはテストをどれだけちゃんと書くかが全てだから正直あんまり関係無い
Scalaはある程度バグの許容されるWeb系の連中が多いので、関数型最強ウェーイみたいなのをあまり真に受けない方がいい むー。
非プログラマな職場で
自分しかテストやらチェックできないので、
普段使ってるrubyよりかは
型チェックされるし、自前のguiがあるという点でいいのかなーと、思ってました。
というか、本音はコップ本を前に買ったままだったのでscala使いたかっただけなのかもしれない…と気が付きました ScalaでGUI作ってる奴なんて日本で100人もいなさそう 誠に遺憾ながらそれもそれで100人が200人にはなるかなという代物 まさか、このスレで、オススメされないとは思わなんだ。
日頃scalaと向き合ってる人からの忠告なのでありがたく参考にさせてもらいます。
一番得意なruby(jruby)で、テストをしっかり作ってやってみます。 GUIやる時点で選択肢は相当に狭められるからね
Web系ならまだしも Scalaはあんまり宣言的じゃないから、関数型らしいロジックの見通しの良さがあんまり感じられないんだよな
良くも悪くもRuby系 オブジェクト指向と関数型の良いとこ取りした、銀の弾丸に今最も近い言語でしょ？
Rubyみたいなハチャメチャ言語と比較されてしまう程度の言語なの？
IDEはeclipseしかないの？ オブジェクト指向と関数型のいいとこ取りとしては今はF#がそれに近いかなあ
Scalaは無計画に便利そうなもの全部ブチ込んで混ぜただけのカオス DDD界隈だと人気らしいじゃん？
もしかして、Javaが中途半端なラムダ式導入しただけでScalaは洋梨オワコンなの？？ >>428
Ruby と書き方は似てるからねー
メソッド引数のカッコ省略とか return 省略とか、Ruby のブロック構文とそっくりな書き方を
できるところとか
だから Scala は Java より Ruby から入る人の方が多いんじゃね？と言われるぐらい
Ruby から入る人の方が多いからかどうか知らないけど、eclipse はあまり使われてない感じ
IntelliJ の方がどちらかというと有名かな
あとは Emacs(やVim、Sublime）＋ensime とかね（これも Java から入る人が少ないことと
関係してそう） 括弧省略あるんですね 幻滅しました
誰が書いても似たようなコードになるPythonが至高だと思ってます
でもPythonのOOPってちょっと変なのが残念
実行速度遅いのも残念だし、型なし君なのも残念
Scalaこそが人類を救済の地に誘う神の導き手だと信じていたのに、幻滅しましたよ >>433
そういうカッチリ書く系の人は Java と親和性が高いんだろうね
Scala は Ruby との親和性が高いから Ruby と比べられるんだろうね javaのOptionalが、Kotlinくらいにもっと手軽に使えたらよかったのに
英語ってさ、記号が少ないからどこに何があるか瞬時に判別しづらいんだよ
だから象形文字としての記号は、コードリーディングに置いて非常に重要だと思う
大して違いもない一時の書きやすさ（幻想）のために
おかしな省略記法があるのは本当によくないとおもう
Scalalintとか、標準コーディングスタイルとかで禁止にして然るべきだわ Pythonの思想に共感する人はF#の方が合ってるよ
C#の実用性とML系の宣言性の高さを継承しつつ、
OCamlの使いづらさをPython風のシンタックスを取り入れることで改善した理想的な言語 >>435
そこはバランスだよねー
ひどすぎると APL になっちゃうし >>436
そうなんだ
でもF#使ってる案件なんて聞いたこともない
使えなきゃ結局ただのオナニーだよね
>>437
APLって初めて聞いた
ひでえ糞言語もあるんだな、サンキュー javaとscalaがクラス(optionalとoption)でkotlinが演算子(エルビス式)だっけ。
エルビス式も深くネストされたオブジェクト中に出てくるとなんか読みにくいんだよね。
慣れてないだけかもしれんけど。 ここらで一つ最強言語が出てくれんかね
マルチパラダイム（OOP + 関数型）
記法はCベース
型あり
型推論あり
インデント強制
The Zen of Pythonベース
たったこれだけの簡単なことがなんでできないんだ？
Scala作った奴もJava作った奴もPython作った奴も
俺以下の無能なのか？ >>440
Python ってラムダがものすごい書きにくい印象なんだけど
Haskell もインデント強制ではないし、もしかしてインデント強制と関数型は相性が悪い？ >>441
Pythonのラムダ糞だよね
中途半端なOOPも糞
普通list.lengthなのにlen(list)みたいな書き方できない
Pythonも結局の所糞なんだよ
どいつもこいつも糞だらけでイラつく >>442
その程度の知識で糞呼ばわりしている君も糞 >>443
糞なもんは知識量に関係なく糞なんだよ、屑が
おまえもPHPみたいになりたいのか？ >>445
俺はいつでも冷静だよ
君みたいに無意味なレスしてくる糞に対しては別だけどね MSってこういう新しいプログラミングモデル広めるの上手いよな
理論と実用性のバランス感覚が絶妙 三 ギ そ 三 ,ｨ/ｲ,r'" .i!ｌi,il i､ﾐ',:;;;;
三. ャ れ 三 ,. -‐==- ､, /!li/'/ l'' l', ',ヾ,ヽ;
三 グ は 三 ,,__-＝ﾆ三三ﾆヾヽl!/,_ ,_i ､,,.ｨ'=-､_ヾヾ
三 で 三,. ‐ﾆ三＝,=＝‐ ''' `‐゛j,ｪﾂ''''ｰ=5ｒ‐ｫ､, ヽ
三. 言 ひ 三 .,,__／ . ,' ﾝ′ ￣
三 っ ょ 三 / ｉ l,
三. て っ 三 ﾉ ..::.:... ,_ i ! `´' J
三 る と 三 iｪｧﾒ`'7rｪ､,ｰ' i }ｴ=､
三 の し 三 ﾉ "' ￣ ! '';;;;;;;
三 か て 三. ｉヽ,_ﾝ J l
三 !? 三 !し=､ ヽ i ,. ・オブジェクト指向+関数型
・遅延ストリームと言語内DSLによるコレクション操作
・リアクティブプログラミング
プログラミングモデルについてはMSの影響力は実際大きいよ
尖ったものを大衆化する設計のセンスは評価されていい Scala と Java が共に jvm 上で動くように、C# と F# は cli ( .NET ) 上で動く兄弟言語で、
.NET 案件なら F# を使っている人もいそうだが 実体は闇
>>440 は C ベース記法を除けば F# が当てはまるな
The Zen of Python の解釈次第だが ウェーイな連中ばかりのScalaと違って、
F#は金融系とかのお硬いシステムの込み入ったロジックを見通しよく記述するための言語だからな
あまり表に出てくるようなものではない >>440
じゃあ、自分で作ればいいじゃない。
>>440は俺以下の無能かな？ Scalaってノイズが多くて見通し悪い割には大事なところ省略してて理不尽なエラーが多いんだよな
JVMで動くML系言語の決定版があればScalaなんか完全に用済みなんだけど >>459
具体的にどういう理不尽なエラーが起きたの？ そもそも省略ってなんだろ
暗黙の引数とか？
起こるのはコンパイルエラーだけど 総合的に考えて、やっぱScalaが最強言語ですよね？ カレーライスとラーメンと焼き肉を混合したら最強の料理だろうか?ということだな 最強言語Scala
SPEED DEMON の C
Webならしょうがないからhtml/css/typescript
科学計算ならしょうがないからpython
以上。
他の言語全部要らんでしょ
なんか異論ある？ ゲームは？組み込みは？
後お前がいらないって言われたがってる？ 2016年6月プログラミング言語ランキング
ttp://redmonk.com/sogrady/2016/07/20/language-rankings-6-16/ Scalaスケーラブルプログラミングの第3版でるみたい。 >>474
ををぉいいですね。
2.12対応かなぁ 技術書ってえらく高いから僕みたいな低所得者は何冊も買えないんですよ
火を灯すべき爪ももうないです 図書館に入れてもらったら。
ただ、版が変わったからってあんまり入れてもらえないかも。
学生ならACMの学生会員になると、おそらく年間$19で
Safari, Books24x7で扱ってる英語書籍の一部が講読できるような気がする。
http://www.acm.org/membership/student/
カタログ
http://learning.acm.org/books/ebooks_catalog.cfm
オライリーのsafariで9月に入れ替わる予定のやつ
http://learning.acm.org/safariswap.cfm 南蛮毛唐の言葉なんてわかるわけないだろ・・・・・・・・・・ こういうこと言う奴って
普段どうやって変数などの名づけしてるの？ google先生やweblio先生に単語を英訳してもらってる クラス名や関数名や変数名は、全て連番で付ける
Excelに名前対応表を作って、それで管理する
面倒な翻訳も意味の通じない南蛮毛唐の言葉も必要ない、最も効率的な方法よ >>488
それだと補完が効かないし
機能変更があった場合に名前の修正まで必要になる
本質的でないdiffはコミットしてはいけない
こんな常識も知らないのか？ 釣りにしては針がでかすぎて面白くないし、本気だとしたら病院直行レベルだし staticおじさんと同じ感じがする
40代以上なのは確定 static以外使うな、ラムダ使うな、変数名はエクセルで管理←new 変数名を連番でつけられるのは勘弁ですな
ネタであることを願いたい >>486が>>483に対する皮肉かと思ったら同一人物かよ…
そもそも機能に変更があったら変数名変えるだろ
それで頻繁に変数名の変更が入って困るようなら機能分割に失敗してる 補助コンストラクタでval変数の初期化は出来ないのでしょうか？
Hoge(int i){
/*
処理
*/
//定数初期化
}
Hoge(int i,int j){
/*
処理
/*
//定数初期化
}
のような事をしたい場合どうすればいいですか >>497
もちょっと具体的に書いてくれないと何がしたいのか不明 >>498
javaのソースで言うと
private final Foo foo;
private final Bar bar;
public Hoge(Foo foo,Bar bar){
this.foo=foo;
this.bar=bar;
}
public Hoge(){
LocalDate date=LocalDate.now();
this.foo=new Foo(date);
this.bar=new Bar(date);
}
のような事をしたいです ScalaとPHPだったら、やっぱりPHPだよね？ >>500
全然適用範囲が違うので、ケースバイケースだと思う >>500
言語としての適用範囲が違うから、比べるのは難しいと思うよ いくら過疎ってるからってそんな馬鹿を装ってまで盛り上げようとしなくていいんだよ >>499
こんな感じかなぁ…
class Hoge(f: Option[Foo] = None, b: Option[Bar] = None) {
val date = LocalDate.now
val foo = f getOrElse { new Foo(date) }
val bar = b getOrElse { new Bar(date) }
} >>505
すみません
一つ大事な事忘れていました
上のコンストラクタはpkg privateです
private final Foo foo;
private final Bar bar;
Hoge(Foo foo,Bar bar){
this.foo=foo;
this.bar=bar;
}
public Hoge(){
LocalDate date=LocalDate.now();
this.foo=new Foo(date);
this.bar=new Bar(date);
} >>506
それぐらいなら private[pkg] でもつけておけばいいんじゃね？ 不変クラスのsetterも、
prop_=
と言う名前で付けるのが普通ですか？
それともsetPropですか？
val newObj=oldObj.prop=value;
と書くのと
val newObj=oldObj.setProp(value);
ではどっちが一般的ですか？ >>508
setXXX は Scala ではほぼ使われない >>510
あぁ、immutable クラスね
それなら copy メソッドを使うのが一般的かな >>511
内部ではコピーメソッド使うけど、メソッド名はどうするべきかを知りたい コピーメソッドってpublicだったんですね
デフォルトコンストラクタがprivateなのでコピーメソッドもprivateにしたいのですが、出来ますか？ >>512
まんま copy
>>513
その辺は Scala のマニュアルを読もう >>514
copyメソッドを用意すればいいんですね
copyをprivateにする方法はよく分かりませんが、privateコンストラタに関することでこんなツイートを見つけました
https://twitter.com/nisshieeorg/status/193709695373025280
しかし、Hoge.applyはpublicになっています
コンパイラの仕様が変わったのでしょうか >>515
なんかやりたいことが散漫になってるみたいだから、ひとつずつ片付けて行こうな
いっぺんに全部を解決しようとしても虻蜂取らずになるだけだよ >>516
はい
今やりたい事をまとめると、
・case classのデフォルトコンストラクタに対応するapplyメソッドをprivateにしたい
・case classのcopyメソッドをprivateにしたい
です >>517
case class は普通の class にメソッドを追加しただけのものだから、case class で追加されるメソッドが
気に入らないなら自前で普通の class を書けばいい >>518
大変そう
呼び出さないように気を付ければ何とかなるか
OOP的には駄目だろうけど >>519
その程度でやめられる程度の >>517 条件なら、小難しいこと考えずに >>517 なんてなかったことにすればいい >>519
圧倒的高生産性を誇るPHPを使えば、それは解決しますよ json4sダウンロードしたんですがjarがありません
どうやって使うんですか？ sbtって何て読むの？
サバト？
酢豚？
シビツ？ 使い方分からね
大量のフォルダ全部パスに追加しないといけない？ eclipseにjar追加したいだけなのに何でこんな複雑になっているんだ 他によさそうなライブラリねーし
現存のエクリプスプロジェクトにjson4s追加する方法どこにものってねー あー眠い
JSONライブラリってどうやって作るん？ sbtそんなに難しいかな
よく分からなくても使えるツールのような気がするけど
mavenとかgradleとか触ってこなかった人だと分かりにくいか？ jsonが何か分かってれば自分で作るのも簡単だと思うけど
汎用的なライブラリを作るなら大変だけどさ
まあ、車輪の再発明なんてオススメはしないけど
つーか今ググったら普通にjson4sのjar転がってるじゃないか mavenもgradleも知らなかったけどsbtは全然わかった 何かよく分からなかったので自作しました
obj→strだけでいいので意外と簡単に出来ました WEBならJSONのパースは必要ないから楽
文字列リテアルは分岐なしで全部Unicodeでエンコードすれば簡単に出来た
http://nemiruku.com/onpad/s/ih2ZgMfbmLE
//import json.Json._;
println(obj("a"->1,"a"->arr(1,2,3,4,5,"a",obj("a"->null))).jString);
>{"\u0061":1,"\u0061":[1,2,3,4,5,"\u0061",{"\u0061":null}]} 最近サカラ本体もスブティーも、全然バージョンうｐしてないな
ChatworksもScala化に大失敗したらしいし
死んでしまった言語なのか？ Spark知らないのか?
データ分析はScalaがビジネスITの世界でツールとしてまともに認められている唯一の分野だというのに > データ分析はScalaがビジネスITの世界でツールとしてまともに認められている唯一の分野だというのに
どこの世界線の話だよ
ポジトークすぎうち笑
Scala終わったか〜
Java8にラムダ登場しちゃったし
クソ重いコンパイラに謎の文法学び直してまでScala使う必要ないもんな JavaのラムダとScalaとにどんな関係が？
それこそアンチScalaのポジトークだろうが バカか？
Javaでも十分簡潔に書けるんだから
複雑怪奇で激クソ重い失敗言語使う必要ねーんだよ
どっかのScala導入失敗倒産企業のポジトークもいらねえんだよ javaのあのstreamやoptionalで簡潔に書けてると感じるならそれでいいんじゃないですかね…… > Javaでも十分簡潔に書けるんだから
これは一流のジョークですね 簡潔って言っても数行の違いだし、ロジックを考える時間と比べたらタイプする時間なんて誤差みたいなものだし、
そもそもIDEで書くんだからなおさら誤差は小さくなるし
わざわざ読むのも書くのも慣れてるJavaを飛び出してScalaに行く理由ってほぼないと思うよ >>552
ボンゴレ
Javaユーザに対するコンプレックスの糞から生み出された
勘違いした便茶モドキの低学歴ども
それがScalaer > わざわざ読むのも書くのも慣れてるJavaを飛び出してScalaに行く理由ってほぼないと思うよ
まぁ、Java屋って保守的な人が多いみたいだからね
ScalaはむしろRubyなどのスクリプトから入る人が多いみたいだしね
そういうスクリプターは好奇心旺盛な人が多いみたいだし ちょっと特殊な書き方を知ってるだけで
できることは大差ないのに
なぜか偉そうなScaler
案の定、バージョンうｐにも見捨てられ
使った企業は性能問題に苦しめられ
見事にオワコン java→C#に行ったらC#が便利すぎてjavaに戻りたくなかったけど色々あってJVMじゃないといけなかったからScala始めた そんなあなたにはKotlinがおすすめ
C#やTypeScriptに近い、OOP+Fな言語としては非常に素直で普通なデザイン > C#やTypeScriptに近い、OOP+Fな言語としては非常に素直で普通なデザイン
KotlinにFな部分なんてそんなないよね
型クラスとか使えないし 型クラスは別に関数型関係ないでしょ
Scalaのあのノイズまみれの実装で型クラスと呼んでいいんなら、
implicitの代わりに明示的にインスタンス渡せばいいだけだし > 型クラスは別に関数型関係ないでしょ
アドホック多相は関数を扱う関数型言語では欠かせない存在でしょ
> implicitの代わりに明示的にインスタンス渡せばいいだけだし
中置演算子とかで使えなくなるじゃん >>560
言ってる意味がわからんな
普通に引数に関数渡したらいいでしょ
むしろ型のコンテキストなんかに頼るより関数型らしいと思うけど > 普通に引数に関数渡したらいいでしょ
もしかしてアドホック多相とか知らない？ >>563
知ってるなら実質同じだとわかるはずだけど? >>564
関数が関数を呼んで、みたいな深い部分で多相を使いたい場合、関数をずーっと持ち回るの？
アホらしいよね、それ >>565
Haskellの場合は型として持ち回らなきゃいけないし、Scalaの場合はimplicitで持ち回らなきゃいけない
それほど大きな違いはないと思うよ? >>566
型が分かってればそれと結びつく関数は持ち回らなくていいよ？
本当にアドホック多相分かってる？ あと、多相を使う関数が複数あったらどうするの？
関数ごとに渡す関数が増えていくよ？
Kotlinは関数型言語なんかじゃなくて、Better Javaを目指してるんだから
Scalaと方向性が違うんだよ
Scalaを貶めたい目的のためにKotlinに多大な期待をかけるのはやめてやれよ >>567
結局implicitで受ける時点で静的に解決するんだから一緒だよ
本当に分かってる? 関数型は同じような動作をする関数は見た目同じように見えることが重要だからねー
Future の map だって implicit で ExecutionContext を受けるけど、使う側としては map で
すんなり繋いでいけるのが大事だよね
これを map に変な引数を明示的に与えてたらそれはただのオブジェクト指向だよね 関数をファーストクラスとして扱う言語なんて、JavaScript でも Ruby でも C# でも色々あるんだけど
こいつらは関数型言語としては扱われないよね
Java は今まではこの辺が激弱すぎたので Kotlin みたいなのが出てきたと思うんだけど、立ち位置と
しては上に挙げた言語と似たようなもんだよね
Scala はもっと意欲的に関数型言語としての機能を入れてるから関数型言語として扱われてるわけで
そもそも目的が違うとしか言いようがない
Kotlin あるから Scala 不要！なんてこの辺の事情が分かってないとしか思えないし、逆もまた同様だね C#に馴染みがあるというからよく似ているKotlinを勧めただけで、
Kotlinが関数型言語だともScala不要だとも言った覚えはないけど、急に変なものimplicitで受信しちゃったのか?
JVMの制約のため型パラメータだけで実装を解決できない以上は単なる引数省略でしかないわけで、
implicitの煩雑さ分かり難さをペイするほどのものかというと微妙だと思うよ >>572
だったら Kotlin スレでやればいいのに
わざわざ Scala スレでアンチが暴れてる最中に言ったらそりゃ誤解されるよ
アンチじゃないなら以後は Kotlin スレでよろしく 議論というより煽り合いに近いしちょっとアンチ風のこと言ったらボコだたきで他スレ誘導とか怖いですぅ アンチがいるってことは人気があることの裏返しだね
本当にオワコンならアンチすら来ない WEB+DB vol.94 が出た
特集は、Scala, Groovy の対抗馬となる、JVM上で動く、Android用言語、Kotlin
JS/HTML/CSSで、デスクトップアプリを作る、Electron
Kotlinは静的言語で、Scalaに似ている。
ついでに、Kotlinも勉強すればいい Scalaで簡単なバッチアプリくらいなら作れるんだけど
これでどっか雇ってもらえる？
今のSIガイジ土方ブラックペチパー（4年目 みなし残 手取18）から逃げたいんだけど 普通に転職活動してみれば良いじゃない
雇うか雇わないかを決めるのは我々ではない ということは、あなたのいるべき場所はそこだってことなんでしょう いじわるしないでクレメンス
いじめは職場だけで十分メンス ひとりで活動する気力ないなら転職エージェントがいるサイトにでも登録して手伝って貰えば。
成功報酬で年収の3割ぐらいキャッシュバックあるので、それなりに後押しはしてくるよ。 >>586
ちな来年29（笑）
高卒ニート歴ありキモオタコミュ障彼女いない歴＝享年
趣味筋トレ
書き出してみたらヤベえわ
雇われるンすかね？ 2年以上やれば、時給千円から、1,200円ぐらいに上がっているはずだろ。
引き留め価格
もし千円のままなら、他社と価格差があるから、転職できる
>>578
のWEB+DB vol.94 を買えば？
クライアント側のKotlin, Electron をやれば、サーバー側のPHP経験も生きてくる 今さらKotlinなんかねーだろ
名前が弱そうだし 逃げたいからって理由だと結局おんなじ様なところに戻ってくる可能性が…
何がやりたいって強気に言い続ける方がいいんじゃないかと もしかしてScalaよりKotlinの方が強いの？
あっちの方が少ない文法とJava互換が高いように見える
Scalaってオワコンだったのか？ Kotlinで解決できるScalaの大きな欠点の一つは、
Scalaで作ったライブラリをJavaから利用するのが難しいこと
Java向けに別途ラッパーを作るというアホみたいな作業が発生する 2.11.8からピタリと動かなくなったな
コンパイルが早くなるなんて噂もあったのに
完全にオワプロか >>596
ちゃんとチェックしてる？
2.12はRC段階だったけど、今日に正式リリースのタグは打たれてるぞ？ >>599
配布できる品質じゃないってことはわかった どういう理屈なんだろう
まあ、オワコンだろうが何だろうが使えるものは使うけど みんなORMなにつかってる？
よかったら選定理由も教えて欲しい RC2からバイナリ互換らしく、リリース前にライブラリ揃えられるよう歩調あわせるのに時間取ってたのかな？
Available Projects for Scala 2.12
https://github.com/scala/make-release-notes/blob/2.12.x/projects-2.12.md リリース直後にgithubのissue立ててる感じかな。
前もって突っついてはない雰囲気。 2.12出たのに盛り上がってないどころか噂すら聞かない
オワプロ（終わったプログラミング言語）なのか？ Java8対応を喜ぶのなんてエンタープライズ寄りのところだけだろ
そもそもそれに該当するユーザーの絶対数がほとんどいないし、
そういう分野は情報発信にあまり積極的じゃない じゃ連中は誰も喜ばないうｐだてを必死にやってたのか
おまいらの本音はさっさとコンパイル速度直せよゴミって感じ？ スレに書き込まないけど、結構使ってる
二度とjavaには戻りたくない def * = (id.?, name, address) <> ((Client.apply _).tupled, Client.unapply)
と言うソースを見つけたんですが、
id.?、<>、Client.apply _
はどういう意味ですか？
<>はタプルのメソッドだと思うのですがどこにも載っていませんでした Scala が糞というより、このライブラリを書いた奴が糞だと思うな
記号を使いすぎると死ぬよ、といういい例だわ でもスカラ界隈のおじさんたちはみんな *<:==ミ みたいな記号使いまくって関数型とか言ってるんでしょう？ まあScalaに限らず関数型ユーザー全般に言えることだな
昔から他人に理解されないのが当然と思ってるから可読性に対する意識がゼロ
Javaにすらラムダがある時代なんだからいい加減次のステージに進む時期 演算子で顔文字作るのがカッコいいとされる文化じゃなかったの >>623
そんなことはない
flatMap の代わりに /: を使うことは悪手だとされている すまん、flatMap じゃなくて foldLeft だな じゃあ@deprecate付けてプルリク送ったれよ
ググれないキーワードだらけで何が可読性だ
結局オタクしか使ってねえじゃん applyとかfoldとかふわっとした抽象的で意味不明な単語が多いのも関数型の特徴
C#あたりは割と名前を工夫して一般向けにしてあるけど どなたか
http://i.imgur.com/KW7Rzr6.png
この赤枠の部分の文字の色を変更する設定がどこにあるか
教えて頂けないでしょうか？ >>632
ideaスレがなかったので・・・お助けくだしあ たぶん idea使ってる人が一番多いのはAndroid studioスレだろうなあ
そいで、そこは breadcrumbs というものらしい
おれもそこの色を変えたいと思ってるが設定に見当たらない なるほどー
確かにAndroid開発はidea一択な上、人多そうですもんね
で、おかげさまでできましたよ！！
まさしくパンくずでした
Editor > Colors > General > Editor > Breadcrumbs
で、色変更できました
（verはCE 2016.3）
マジでありがとうございます。 >>635
idea2016.2.5やAndroidStudio2.2だと
Editor > General > Appearance の下にShow breadcrumbsってのあるだけで色変えられないんだわ
2016.3で変わったみたいだね
おれもidea2016.2.5は2016.3にバージョンアップしてみるよ >>127を見てお隣さんを確認したら
Haskellで書かれたtensorflowは
かなり関数型らしいコードに仕上がっていた
https://github.com/tensorflow/haskell/
言語仕様レベルの強制縛りプレイって実は合理的だったんだな それTensorFlowがHaskellで書かれてるんではなくて言語バインディングや
ツリー組み立ててC++へ投げるだけだから関数型らしいコードにならないほうがおかしい となると
関数型らしいコードというのは
机上の空論でしかないのか？ お前の思考自体が関数型らしくない
まずは関数型らしさという概念明確にを定義せよ 参照透過でない言語が
表面だけHaskellっぽくする利点って一体何だろう。 その疑問はHaskell関係なくScalaの存在意義自体を否定している いやscalaは別にhaskellっぽくないと思うが
そもそも関数型言語の殆どが純粋ではないし Intellijのデバッガ使いにくい。みんなどうしてるんだろ Takashi Hiroki @TakashiHiroki
6m
相場を予想するということ - Dance with Market
相場の予想が外れると、ツイッターなどで悪態をつかれたり、揶揄されたりする。非常に不愉快だが仕方ない。予想をするというのは、そういうことだ。
予想が外れて批判されるのが嫌なら、予想をするのをやめるか？予想しないなら、インデックスファンドでいい。ロボットアドバイザーでいい。AI（人工知能）でいいのだ。
それでも僕らは予想する。考えるということだ。考えなくなったら人間ではない。人間は考える葦である、とパスカルは言ったが、逆に言えば、考えるから人間である。
AIは考えない。人間の知能を学習して考えるようで考えない。演算、計算をするだけである。
僕らは人間の頭で考えるから間違える。逆に言えば間違えるから人間である。間違いや失敗を恐れるべきではない。
朝、オフィスに行って一番初めにすることはBloombergを起動することだ。Bloombergを立ち上げると最初の画面に「今日の名言」が表示される。
それを読むのが一日にスタートである。昨日相場の予想を外し、最悪な気分で朝を迎えた僕が、今日一番初めに目にした言葉はこれだった。
https://cdn.goat.at/blog/user/3kSA3gsY/contents/5M6VWP24/public/image/20341131129546.png
予想を外して散々叩かれるかもしれない − そんな不安を抱えながら、今日も明日もその次も、僕は「マーケット」というピッチに立ち続ける。 TwitterはScalaを捨ててNode.jsに移ったそうです。
http://www.utali.io/entry/2017/02/24/170000
オワコン化が著しい件
どうすんのよA: [0.092202 sec.]B: [1.169472 sec.] netflixだと、BFFがnode移行したときに、バックエンドはpolygotのままとか発表してたけど、
twitterはあんまり全体の発表しないからか、しょっちゅうscala捨てたって言われてるイメージが。
元はrubyだっけ？ APIサーバーもnodeか。
外部からのapiの利用が多くてjsonだからnodeだとメモリ効率良いってあるけど、
単に重量VMの問題でjvmか.netのVM避ければ良い問題だったかも。 つまりjvmは高速化に貢献するものではなく
むしろ足を引っ張るだけのデブだったと >>648-651
https://www.reddit.com/r/programming/comments/5st3dy/all_of_twitters_mobile_web_traffic_thats_like_a/ddjgi5a/
>necolas ←Node.js採用について最初にツィートしたTwitterのエンジニア
>Hi, I'm the author of this Tweet. Twitter's API continues to be implemented on the JVM.
TwitterはScalaを捨ててません（少なくとも現在は）
http://kmizu.hatenablog.com/entry/2017/03/22/233335
> 1. Twitterは最近（ここ数ヶ月）にScala CenterのAdvisory Boardにjoinしている
> 2. 置換えたとされるFinagleのコミットが最近でも活発である
> 3. そもそも引用元ツイートで一言も、Scalaを捨てたに相当する表現が見られない APIってSPA始めると、おんなじサービスに対して公開APIと内部APIの他にBFFのAPIが増える場合があるんだけど、
今回SPA始めたので、BFFのAPIをnodeで作って他のは変更してないってことでいいのかな。
APIってだけだと良く分からんね。 >>648
あぁ、そのページ、タイトル詐欺ってことで炎上中だから
Scala捨ててないし >>656
自分で考えることを放棄して「リンク先ぐらい嫁」ｗ
信じたい情報だけを信じる
惨めだな >>655 >>657
http://echo.2ch.net/test/read.cgi/tech/1488608741/275-276
英語を全く読めないからまともな判断が出来ないんだろ?
自分の考えと称して妄想するのではなくGoogle翻訳を使う事を勧める。
TwitterのエンジニアがTwitter's APIはJVM上のままだと書いている。 そりゃ動いてるだろうさ
どんな最新最先端の現場でも
Java1.2とかStrutsとかPHP4とかCOBOLとか
動いてるだろうよ
バカなのか？ ここまでくると病気なんだろうな
早めの受診をオススメしないといけない コンパイルは檄遅、暗黙のウンチャラでコードはカオス
採用したChatw●rkはボロボロ、
採用したTwitterもボロボロ、挙げ句捨てる準備に入った
ロートルHaskellにすら勝てず、Kotlinに負け、Java8に負け・・・
もう終わったんだよScalaは。 コンパイルが速くなったら起こしてくれ。
それまで寝てるから。 scala-armとかbetter.filesみたいな便利系のライブラリもっとないかな >>666
どうでもいい
Scalaなんか選択肢の一つに過ぎない
他のプラットフォームなら他の言語使うわ Struts2が危険である理由
https://www.scutum.jp/information/waf_tech_blog/2017/03/waf-blog-046.html
Scaler「チャンス！行くぞPlay！シェアを奪うんだ！」
SIer「Spring^^」
SIer「JSF^^」
SIer「Struts1^^」
Scaler「…」 Javaのガチガチなコンサバ系がScala+Playに移るなんて普通に考えてありえないわな
Scala+PlayはRailsとかそっちと適用分野がかぶるんだから PlayよりももっとコンサバなWebフレームワーク無いの？
Javaに慣れたチームに勧められるようなやつ >>671
Kotlin + Spring Boot 周回遅れかつサゲマンジャップがScalaに目を付けた時点で
終わりは見えていた
ジャップランド土人の呪いの法則だよ https://twitter.com/kmizu/status/848574448642834432
自分は今も2chの（一部スレの）アクティブユーザーですが、
2chが決定的に衰退したのって、たぶん2chブラウザのAPI制導入したあたりで、
この前後でスレの速度が一気に落ちたのが記憶に残っています。
---
Kotlin貶してるのは… DBが扱えるパッケージだっけか。どんなところが使いづらいん？ twitterに捨てられ
採用したchatw○rksは運気が下がり
Kotlinにすら負けた
Scalaよ、どうしてこうなった？ どうしてもクソもそもそも実用言語じゃないからなこれ
研究用の実験言語に一体何を期待してたんだ?
Kotlinを生み出しただけでも実験言語としての役割は十分に果たした >>683
Twitterには捨てられてないんだよなぁ
クライアントがscalaからnodeになっただけで KotlinはただのBetterJavaだからなー
Scalaとは土俵が違うとしか しかしプロダクションで使ってる例のほとんどは実際にはScalaをBetterJavaとして使ってるわけだからな
ビッグデータ関係なんかだとほんとにただのLightweight Javaとしか扱われてない Lightweight Java
なおコンパイル速度 Sparkみたいなのだとスクリプト一行の処理粒度が数GBとかとんでもなく大きいからな
仮に一行実行するごとにsbtのクリーンビルドをかけたとしても問題にはならない >>690
Scala製のオープンソースプロダクトを漁ってみたら?
どれもJavaと変わらないような使い方してるよ scodecをもっと楽々使えるようになりたいのに資料が少なくてつらい
数学への理解がある人は割と簡単に扱えてるんだろうか ライブラリ事情を知りたいからよく使ってるのを列挙して教えて欲しい スレ一覧で目に留まったから言語そのものを貶しに来たような書き込みばかりに見えるんだけど
まともに取り合ってくれる人は居るんだろうか まともに取り合うつもりはあるけど他人に助言とかできるレベルではないなあ、自分は ここらへんは特によく使う
better-files enumeratum scala-arm timeforscala scala-java8-compat
使いこなせるようになりたい
cats shapeless fs2 each mouse spire kind-projector kittens futiles Scalaの書籍って本当に少ないな
世間の浸透度を表しているようだ 似たような本だしても売れる状況があるといっぱい出てくるよね。
アンドロイド公式みたいなのは強いねえ。
ただspark絡みは増えてるんじゃないかな？ まあこれから新規でAltJavaやるならKotlin一択だろうね
完全に終わった kotlinは大企業がバックアップしているのがデカいな
Scalaなんていつ消えるかわからないものなんて怖くて使えない >>703
使ってもないくせになんでScalaスレを見てるんですかね？ scala資産がある以上そんなにすぐ消えたりせーへんで
正直web上に情報溢れてるし
英語ならScala関係の本いっぱいあるから本がないとか言われても日本語の本がないってだけでしょとしか phpとかいう真性ゴミ屑言語を見たまえ
あんなゴミですら、悪貨は良貨を駆逐する
いわんや強力なバックの突いたkotlinなら尚更だ どう考えてもScalaの方が悪貨だろ
つまりワンチャンあるで phpがrubyやpythonを駆逐したのか？
と言うか最近のphpが悪い言語とは思えない 書きたいとも思わないけど
アンドロイドはkotlin一強になるんだろうけど
サーバーサイドの資産をkotlinでもう一度作り直すのがいいとは思えない
Scalaでさえconcurrentのライブラリのコアはjava資産に頼っているのに
(Future, akka actorの裏側はExecutorService 特にfork/joinフレームワーク) >>708
最近のphpが悪い言語じゃないだなんて、目が腐っとるで
ウンコにウンコ足し続けてるウンコオブザウンコだぞ
常識的に考えて、クライアントサイドとサーバサイド、両方同じ言語で書きたい＝kotlin最強伝説になるだろ
だいたい、Scalaのどこにサーバサイドの資産があるねん > クライアントサイドとサーバサイド、両方同じ言語で書きたい
こんな幻想を持ってる時点でお察しだわな >>709
ScalaにはPlayがあるだろ
javaより書きやすいし ScalaにはまともなORMがない
これはサーバサイド言語としては致命的 クライアントサイドで使うScalaってサーバーサイドよりも絶滅危惧種じゃないか
Scalaで作られたアプリとか聞いたことないぞ >>714
なんでそんな人間がScalaスレ覗いてるの？ JavaでPlay使ってるからScalaのコードを読まざるを得ない
Playには興味があるがScalaにはそれほど興味がない >>716
Play使ってるなら素直にScala使えばいい
Play自体がScala前提なんだから >>717
申し訳ないがお断りする
もう使い始めて3年以上経つけど、Javaで思い通りのこと全部書けるので
そんなことよりクライアントサイドのScalaの話してくれ >>718
だったらScalaスレなんて覗かないでJavaスレで生息していればいい
わざわざ使わない言語スレでヘイトスピーチしてる暇はないはずだ 興味がないだけで嫌いではないし、読む必要があることはもう伝えたよな・・・
何で叩かれてるのかわからん。どうしてそんなに攻撃的なんだ > Javaで思い通りのこと全部書けるので
もう新しいことを覚えられないstaticおじさんなんやろなぁ・・・ scala使える環境でわざわざjava使うとか理解できん…
今すぐ仕事を代わってくれ
状態管理もgetter/setterとStreamとtoListを書く作業ももうたくさんだ >>709
akka
java apiも一応あるけど >>716
javaでplayとか非同期あたりめちゃくちゃ書きにくくない？
ていうかクライアントサイドをScalaはないていうのは別にみんな異論はないと思うけど
>>712
scalikejdbc結構おすすめだよ 非同期はJava8に比べて特筆するほど書きやすいってことはないだろ
一方KotlinはC#系のasync/awaitを導入し、非同期に関しては既にScalaを完全に抜き去った >>722
Playではgetter/setterなんか書かない
Streamを嫌がる気持ちはわからんが、toListなんかScalaでも書くんじゃ
>>725
確かに昔は非同期処理が書きにくかったが、2.5でCompletionStageが来てからそうでもなくなった
＞クライアントサイドをScalaはないていうのは別にみんな異論はないと思うけど
そうだよね。あるなら見てみたかったが、仕方ないね コンパイル速度遅すぎ
インポリジット可読性悪すぎ
だいたいこの辺が悪かった
もう取り返しがつかない Googleによる死亡宣告と週末感漂うスレの空気は今は亡きDartを思い出すな >>730
そうか？KotlinはただのBetter JavaでScala（やClojure、groovy）とはコンセプトがまるで違うんだから
「ふーん、そうなんだ」って思ってるよ
終末感（の誤字だと思うが）は一部のアンチScalaが煽ってるだけじゃん >>731
Clojureやgroovyみたいなマイナー糞オタク専用言語にまで落ちぶれるのか
関数型とは何だったのか >>732
コンセプトが違うという言葉だけでなぜひとくくりにしようとするんだろうね
世界は２択にあふれてるという思想の持ち主なんだろうか Scalaやgloovyのいらない機能を削ってスリムにしたのがkotlinやからな >>735
お前にとって要らないんならお前が使わなければいい、それだけの話
そしてお前にとってこのスレはもう必要ないから見なければいい まあこれまでAltJavaの筆頭として持ち上げられてたのは事実だし、
そういう提灯に釣られて手を出した人が殆どなのも事実だろう
今後は企業も引き上げてくからエコシステムとしての進化も大幅に鈍化し、
これまでのようなスピード感のあるイメージも失われていくよ さすがにDartみたいに打ち上げすら叶わなかったゴミと一時期でも日の目を見たScalaを一緒にするのは失礼
あえて例えるならcoffeeが近いかな
そういえばあれもライバルがGoogleのお墨付きをもらったことが最終死亡宣告となったな そう
つまりalt javaはkotlinに軍配が上がったのさ Alt言語なんてこんなもん
本家の言語にはない何らかの提案がなされ、それが本家の言語に吸収されたら
kotlinやtypescriptみたいにバックが付かない限りお役御免になる
別に今回だけじゃない
そのうちさようならscalaみたいなタイトルのエントリーが出てきて、
しがみ付いてると老害扱いされる日が来るんじゃないか このスレにScala書く人間が居ないから
実態の無い偏見ばかりがゴミのように積み上げられていく >>738
coffeeのライバルってts?
ES.next+型のtsと、シンタックスシュガー入れただけのcoffeeって言うほど競合してるか？ >>743
Alt系を使いたがるのは何となく流行ってるからやってみた的な連中が多いから、言語の性質とか関係ない
RailsTypeScript使おうとする基地外もいたりするし >>742
そりゃそうさ
ただ叩きたいためだけにわざわざ嫌いな言語のスレを覗いてるような奴らなんだから デカめのミドルウェアとかScalaで書かれてるし当分は廃れる心配ない気がする >>726
for yield式あるから確実に書きやすいと思うけど
と言うかasync awaitを実現するっぽいライブラリあるけどこれじゃダメなん？
https://github.com/scala/async
内部的にはfor yieldだけど >>738
ああ、tsとcoffeeの関係は近いかもな
でもウンcoffeeほど酷いとも思わないけど、
まぁでもScalaもこれで終わりか >>734にとって要らない機能って具体的に何？
暗黙の型変換については要らないと思うけど他は思いつかない
>>746
とりあえずakka-actor, akka-stream, akka-httpがあるから
サーバーサイドでkotlinがscalaの代わりになるの先になりそう kotlin
アンドロイドでjavaを書かせられるって苦痛から解放されるのは本当に素晴らしいんだけど
Function22を取り入れちゃうくらいにはScalaをパク..もとい参考にしていながら
言語的に退化というか昔風なのがちょっと残念 日本のPGの9割を超えるバカジャップ土方が
Scalaを扱えるわけないだろ
Javaですらラムダ式は可読性が下がるから禁止
メモリ効率を考えてstaticとか言ってるのに
Kotlinがちょうどいい案配なんだよ
それでも糞バカジャップランド土人はゴミみたいなコード書くんだろうが >>751
ほらね、Scalaをけなしてるのってこんなんばっか Scalaのオブジェクト指向と関数型のハイブリッドは最高に便利だと思うけどな
まだ時代がScalaに追いついていないだけだろう Scalaが避けられてるのはライブラリのカオスさであったり記号やimplicitの過度な使用による可読性保守性学習性の低下のためだよ
ScalaのコンセプトにNoが突きつけられてるわけじゃない あとはJavaとの互換性がそれほど高くなく、境界を意識したFFI的なコードをしばしば強いられることであったり、
文法に一貫性が乏しくて直感的に通りそうなコードが例外的に通らなかったりするケースが多いのも嫌われる大きな要因かなと思う >>754
モダン言語なんて大抵そんな感じやし
Scalaじゃないと出来ないことなんてほぼない >>758
プログラミング言語なんてチューリング完全である限りはどれも一緒だよ optionalをコンパイル検知できたらよかったのにね
optionalインスタンスの生成もったいないなって思っちゃうもの
やっぱkotolinの勝ち？ JITで最適化されるさ（適当）
真面目な話jvm言語でそこらへんのオーバーヘッド気にしないだろ
Scalaなんてサーバー側が主なんだし
そこが気になるならkotolinなんか選ばすにRustでもやっとけ >>761
そもそも何でもかんでも自分でoptionalに包まないといけないのがメンドクサ・冗長
その冗長さをなくすのが目的じゃなかったんかワレ？と思うわけなのですよ Optionalでなかったら必ず値か入っているのか?というと全然そんなことはないわけで
nullのある言語に導入するには極めて筋の悪いやり方
そもそも実用目的じゃなくてモナドを作ることが目的なので言っても仕方ないことだけど、
それを考えなしにそのまま真似しちゃったJavaは痛すぎる Optionaalがモナドなので、他のモナドとの組み合わせたときに威力を発揮するものだから、
単体では面倒くさい部分が目立つだろうね
たとえば、List[Optional[T]] を Optional[List[T]] に変換するなんてのも他のモナドの変換と
同じように統一的に扱える、みたいなね JavaのOptionalは何がしたいのかガチで意味不明
非nullの保証もStreamとの互換性もないとか頭おかしいわ 今まで相手にさえしてなかったJavaをも叩き出してびっくり
皆さん衰退の恐怖を楽しんでいらっしゃるようで何より 一体何と戦っているんだ。。
>>764
ん？ Option型は値がないかもと云う状態を表す型だし
プログラマが指定するのは当たり前じゃない？
>>766
Option型(maybe)の便利さとOptionをモナドとして扱える事の便利さは別じゃない？ >>770
Scalaではあらゆる型が元々デフォルトでoptionalなんだからいちいちOptionalと書くのは冗長
逆にRequiredなら分かるけど、Scalaの仕様だとOptionalにはモナドとしての意義しかないよ >>771
>Scalaではあらゆる型が元々デフォルトでoptional
あらゆる型がnullableって事？
それならAnyRef(javaでいうObject class)の派生型だけで基本型はnullableじゃないよ
モナドとしての意義っていうのがわからない
maybe型の利点はコンパイラが値がない場合のチェックをプログラマに強制できる点だけど
これはScalaでも享受できる
モナドインターフェースとしての利点は
List(Option(1), Option(2)).sequence => Option(List(1, 2)) (本当に要求しているのはアプリカティブだけど)
みたいな汎用的な関数を使える事だと思うが通常のScalaプログラミングではこの利点は享受できない >>772
多分
val hoge:Option<String>=null;
みたいな事も出来るし、
val foo:String=null;
みたいな事も出来るって言いたいんだと思ふ
nullを代入しないようにマが気を付けないといけない >>773
> val hoge:Option<String>=null;
これは直接nullを束縛しない限りは型チェックで引っかかるでしょ
val s: String = null
val hoge: Option[String] = s
はエラーになるんだから >>774
val hoge:Option<String>=null;
じゃなくて
val hoge:Option[String]=null;
だった
エラーにならないぞ
val s: String = null
val hoge: Option[String] = s
がエラーになるのはString→Option[String]の暗黙の変換は行われないから
nullが入る事が確実でも代入不可能 >>775
直接nullを束縛しなきゃいいだけでしょ
そんなことをする理由もないし >>775
話がずれていってる気がするが仮に暗黙の型変換を用意しても
implicit def stringToOption(str: String) = Option(str)
だから
val s: String = null
val hoge: Option[String] = s
でhogeはNoneになるよ >>776
しなきゃいいで済むなら静的検査は要りません
静的関数型信者にあるまじき発言である >>778
何らかの lint 使え
大体の lint に null 使うなってのがある 静的関数型信者ならScala使わなくね
nullについてはjavaとのFFI考えるとしょうがないし文化で縛るしかないかな まぁjavaのライブラリがnull返しそうならOptionでくるめばいいし >>780
kotlinは仕組みで実現しましたが
あげくscalaはkotlinに負けましたが >>782
Kotlinは土俵が違うでしょ
JavaVM上で動く、ということしか共通点がない >>783
Kotlinと被らない土俵っていったら関数型信者の自慰グラミングかな? >>784
関数型信者とまでけなす人間がわざわざScalaスレを覗いてる方がよっぽど気持ち悪いわ >>785
いつから信者が蔑称になったんだ
俺は一時期は信者と呼ばれるレベルでScalaに入れ込んでたよ >>784
そのあとに「自慰グラミング」とか言ってるじゃん
荒らすことに夢中で日本語レベルまでおかしくなったか >>787
Kotlinと被らない土俵というのを具体的に示してほしくてあえて刺激的な表現を用いた
気分を害したなら謝罪する
Scalaの(Kotlinと被る範囲の)ベターJavaとしての面を否定することは、
これまでのScalaの小規模ながらも確かにあった流行の歴史の大部分を否定することになると俺は思うけど、どうだろう? >>788
謝罪した直後ですごい煽り満載の文ぶっこんで来たな 「ベターJavaとしての面を否定」ってどれのことだろう なんでアンチがScalaスレにいるのって論調でいろんな人に噛み付いてる奴、
ちょっと具体的に突っ込まれたり疑問を言われたりすると黙っちゃうね >>790
「モナドとか難しいこと考えなくてもScalaは使えるよ！書きやすいJavaとしてScalaは十分便利だよ！」
こういう紹介の仕方に見覚えはない?
君はこれをアンチだと言ってるんだぜ
俺をアンチ呼ばわりしてくれてもかまわないけど、その後でいいから今一度胸に手を置いて考えてみて欲しい >>782
FFI時にOptionで包めばいいじゃん（いいじゃん）
for式あるし Optionがただのデータ型だから使いやすい
Seq(Option(1), None, Option(2)).flatten => Seq(1, 2)とか簡単にできるし
個人的には単なるmaybe型を言語が特別にサポートするのが嫌いだなぁ
まぁScalaはScalaで標準でアプリカティヴないのが大いに不満だけど
負けたって何の事？
逆に普通のwebアプリでScalaからKotlinに移行するメリットとか特に感じないんだけ Javaですらstatic付けまくりの手続き型にウンコモリモリ大将軍な糞バカジャップランド土人に
Scalaなんて扱えるわけなかったんだよ
kotlinならあるいわ
いやないか、だってバカジャップだもんな
static付けちゃうもんな、バカジャップ 日本の大半のプログラマにScalaが使いこなせないだろうということは同意だけど
static自体をそこまで毛嫌いしてる理由はなんだ？ 言葉を選べば内容に同意してもらえるかもしれないのに、わざわざ自ら
内容の信憑性を貶めるのには何か理由があるのだろうか？ 屁こき虫のジャップランド土人はペェールかペチプァ〜でも使ってろってこった >>800
KotlinはBetter Java、Scalaは関数型の機能充実で住み分けすれば何の問題もない 純粋に関数型として売り出すのはScalaには正直厳しいんじゃないかな
実用プログラミングにおける関数型の最大の売りはモナド遊びでも公開関数でもなくその宣言性の高さ
所詮は手続き型ベースの構文で、バリバリ宣言的プログラミングするにはロジックの見通しが悪すぎるよ >>802
Java VM上で動くという点はやはり大きいよ
ライブラリ不足で困ることはまずないからね >>803
Scalaではそもそも関数型のメリットを広く訴求することが難しいということだよ
既存の関数型マニアだけでは実用的なエコシステムを構築するには全く開発リソースが足りない
宣言性の問題は言語の本質的な素性の問題だからライブラリや新しい機能を追加すればよいというものでもないし 初めは宣言型で書いて次第に関数型へシフトしていけるのはScalaの強みじゃないかな
チームの習熟度に応じてプロダクトを発展させていけば
メンバーの技術力向上に繋がったりするよ
お金の余裕が無いとそうそうできないけど
関数型への理解は後の宣言型で組むコードにも役立つ知識だと思う はてぶの特集見たか？
あそこにKotlinが載るようになったんだぞ？
一度でもScalaなんか載ったことあったか？
そういうことだよ 関数型プログラミングについても(Scalaで満足しているのであればの話だが)そもそもKotlinでだいたい問題無いからな
大きな違いはimplicitが無いくらいじゃないの
それも一般的にはむしろ大きなメリットと捉えられるだろうし関数型に必要な機能というわけじゃない このスレでKotlinの話しだす人の目的がよくわからないな
俺はKotlinも大好きだよ せいぜい航海関数が使いやすけりゃそれで十分なんだよな
あとはヌル安全
関数型なんて大仰なこといって、これくらいしか使ってないだろ実際おまえらさんも
つーことは、さ、つまり、わかるよね？ >>808
JVM最強決戦でScalaは負けて、Kotlinが勝った
話題にするには十分な理由だろう？ >>810
でもなぜかKotlinを推す人間は糞ジャップとかいう汚い言葉を使ってるんだよな
糞ジャップはPerlかPHPしか使っちゃいけないはずなのにさ サーバーサイドならScala圧勝なのは変わらん
クライアントならKotlinの方が良いけど
似たようなものだから使い分けろ 勝った負けたってそんなに大事な視点なのかな？
本質を見誤っていると思うのだけど なにをもって勝ちと言ってるのかな？
これからAndroidではKotlinが主流なるからシェアで負けるってこと？
シェアが増えれば勝ちで勝ってるほうがいいならScalaはJavaやPHP等々に負けてるわけだからそっちやればいいのに >>813
じゃあ完全負確塵屑糞尿吐瀉物ペチプーでも使ってりゃええねん
>>811
使っちゃいけないなんて、僕は思わないな
でも、それくらいしか使いこなせないだろ、って連中は多いだろ
日本のIT（笑）なんて韓国以下、最近まで土食ってたイン土人にすら劣ってるし >>815
やっぱりこいつかって感じだね
もうこのスレでやたらKotlin推してる人間は疑ってかかった方がいいね こういうのが建設的な議論もせずに私怨で言語を貶して粘着し続けてるんだから2chは魔窟だわ
そりゃあ知識も逃げていくわけだよ 知識どころかユーザも逃げてしまったな
ああKotlin ぶっちゃけ、KotlinにはScalaみたいなスター性みたいのが感じられないんだよな
Scalaやってますって言われたらｵｵｯってなるけど
Kotlinやってますって言われてもｱｯﾌｰﾝ程度じゃん
でもこれが初心者でもとっつきやすさに繋がっていいってことなのかな
わかるやつおらん？ スター性って要するに習得難易度が高いって意味？
難易度に見合ったメリットとか独自性がないと簡素な言語に流れるのは当然だなあ
Scalaが爆発的な人気を得ることはないだろうなと思ってるが少数精鋭でいいとも思ってる >>822
書いてる俺カッケー感だよ
KotlinはなんかJavaがすっきりした程度だけど
Scalaだとｳｵｵってなるじゃん >>823
早く追い越してくれ
動的型のゴミオモチャはPythonだけで十分だ
屁臭いペチプーも詐欺師ルビーも公害粗大ゴミのペェ〜ルも
全部要らん
書いてるやつほんとにマウスで殴り殺してやりたい >>825
ぜひやってくれ
そして社会から消えてくれ >>824
そうかなあ
implicitを使ったトリッキーなパターンを生産するたびにｳｪｯってなるわ >>828
implicitはアドホック多相専用にしちゃえばそこまでｳｪｯってならないよ アドホック多相という単語にｳｪｯってなっちゃった僕はどうしたらいいですか？ >>831
ファ！？
こんなんだからお前らはコトリンに負けたンゴよ！ 1ヶ月間衰えぬことを知らない中学生の勃起チンポのようなコトリンと
1ヶ月ぶりにレスがついたと思ったら死にかけの爺の老害レスばかりのスカラ
どうしてこうなった その煽り癖コミットログに滲み出るからやめたほうがいいよ その煽りtwitterでやってれば
2chにScala使いなんてそもそも少ないんだから >>839
大規模案件に使われてて需要があるのか？ Scalaを採用する企業の年収が高いという落ちでは 棒チャットのあれ、チャットのアレが日本語化して大変そうだな
せっかくゴミ屑のペチプァ捨ててScalaにしたのに
ペチプァのサゲマンっぷりはすごいな 大企業だから大規模案件を起こせて
社員の年収も高いって考えても
常識的におかしくないな それ半年以上前から言ってるよね
本当なのかな
てかもはや
早くするのが遅すぎたね
Kotlin・・・ KotlinがAndroid公式言語になってから
すっかりScalaの勢いが衰えたな 途中送信してしまった
https://scala.epfl.ch/
https://typelevel.org/
https://www.scala-exercises.org/
コンパイラ開発やマルチプラットフォーム、マルチスクリーン、プログラミングパラダイムにドキュメント整備
いろんな方向へ発展していてたまに覗くと面白い 現実を見てない空盛り上がり
そんなこと言ったらペェチプァだった盛り上がってますわ すまん。仕事でイライラして難癖つけるだけのレスしちまった。
無視してくれ。 Javaはうんざりしてるので違うことやりたいと思う人にKotlinより
Scalaの方が良い点はなんだろう。
自分はScalaからKotlinに引越中だけど…。 ちょっと基本的な質問。
val a = Array("a","b","c")
a(0) = "ABC"
val は更新不可だと思ったんだが、フツーに通ったんですよ。
こりゃいったいどういうことですかね。
ちょっと不思議でして。 コップ本第3版のp.061の真ん中あたりの説明だと思うんですが、
いまいちわかんないんですよね。
ポインタ的なアレすかね。 >>857
a は Array というコンテナを他の値に変更しちゃだめだと言ってるだけで、コンテナの中身を変更
しちゃだめだとは言ってないから
コンテナの中身も変更不可にするためには、変更不可コンテナを使わないとだめ あ、なるほど、変更不可コンテナがあるんですね。
ありがとうございます。
ちょっと別件で一個、ベテランの書き方を聞いていいですか。
具体的には、PaizaD006とかなんですが、文字sがkmの場合、mの場合とかで数値を適当に求めるパズルなんですが、
関数言語っぽく書くとどうなるんでしょうか。
var ans = 0L
if ( s == "km") {
ans = n * 1000 * 100 * 10
} else if ( s == "m" ) {
ans = n * 100 * 10
} else if ( s == "cm" ) {
ans = n * 10
}
println(ans)
動くは動くんですが、もっと関数型っぽい書き方があるのではないかと思いまして。 Paizaの問題を具体例出して答えるのはまずい気がする
パターンマッチングで調べるといいよ Project AmberのおかげでますますScalaちゃんが用済みになるね
やったね！ Kotlinに負けGoに負けRustに負け、勝ってたはずのJavaにすら負け
檄遅低脳コンパイラと
オタクのマウンティングのための糞記号祭りで
何もかも失ってしまったね
後に残るはPHP並の負債のみ
悲しいなぁ PHPという糞の山にScalaとかいう糞を混ぜ込んだ究極糞大山のSlackのパ●リはどうなりましたか？（凍え） コンパイル速度はdottyさんが何とかしてくれんじゃなかったっけか sbtが蛇足だった
ScalaCheckはよかった（今もあるが） >>868
それ3年くらい前から言ってない？
ドッティはドコッティ？ ドッティはドコッティ？
これは流行る
糞ペチプァにすら負けたドッティはドコッティ？ 自分の発言に自分でウケてやがる
アルツ一歩手前の症状だな いつの間にかverupしてるな
そして全く話題にならんという JavaのObject ArrayをscalaのArrayに変換する方法を教えてください。
Arrayには数値が入っていますが、Object型だとscalaでの計算に使用できず困っています。
Javaとの相互運用は色々と癖がありますね……。 実体が java.lang.Integer[] な java.lang.Object[] を Array[Int] として扱いたいって意味なら
こんな感じでできる
val javaArray: Array[Object] = Array(new Integer(2), new Integer(3), new Integer(5))
val scalaArray: Array[Int] = javaArray.map(Int.unbox) >>884
返信ありがとうございました。目的はお察しの通りです。
下記のエラーで通らないようです。
missing argument list for method unbox in object Int
Unapplied methods are only converted to functions when a function type is expected.
java.lang.Objectなのは間違いないですが、java.lang.Integer[]かどうかの確認も厳しいです。
インタプリタの出力はObject = Array(数値1、数値2、……）という状況です。
Javaは型の確認や変換関係がドロドロですね……。
pythonやC#から比べると難易度高いです。 最後の2行みたいな事は火種にしかならないのに
どうして書いちゃうんだろうねえ >>887
3日ほど進捗なしで心が折れてます。
getClass（）でclass [Dと出るのでArrayかつDoubleのobjectのようです。
APIにはjava.lang.Objectと書いてあるのですが。
何をやってもvalue ×× is not a member of Objectと出るので
死にたくなってきました……。 とりあえずこんな風に書いてみてObjectの実体が何なのか調べてみたら
val javaArray: Array[Object] = Array(new Integer(2), new Integer(3), new Integer(5))
val objectTypes = javaArray.map(_.getClass.getName).distinct.mkString(", ")
println(objectTypes) ひょっとしてこう書けば解決する話なんじゃないの
javaArray.map(Double.unbox)
それと『計算に使用できず困ってる』ってアバウトすぎてよくわからないよ >>889
ありがとうございます。
value map is not a member of Object
でエラーになります。
関数の元は下記です。
https://www.unidata.ucar.edu/software/netcdf/java/docs/ucar/netcdf/RemoteAccessorImpl_Stub.html#toArray(java.lang.Object,%20int[],%20int[])
1次元配列で戻すと書いてありますが……。 [Dはjava.lang.Double[]じゃなくてプリミティブ配列のdouble[]だよ
ScalaだとArray[Double]として変換なしでそのまま使える
まあわかりにくいよな… val obj: Object = accessor.toArray(arg0, arg1, arg2)
val array = obj match {
case double: Array[Double] => double
case _ => throw new InternalError()
} >>892
変身ありがとうございます。Object=Arrayとあるので
私も当初はそう思ったのですが、toListや配列を反転させるreverseすら通らないです。
error: value reverse is not a member of Object
下のサイトにあるような、object型配列ではないかと推測します。
https://ameblo.jp/gdgd-programmer/entry-12182237268.html あ、キャストはいるから>>893みたいにしてね
てか問題箇所のコード片貼ってもらった方が早いかな… >>893
返信ありがとうございます。
error: object java.lang.reflect.Array is not a value
とエラーが出るので、
今回の対象はjava.lang.reflect.Arrayに該当するのでしょうか。
調べてみます。 import java.lang.reflect.Array を消せ >>897=893
通りました！ObjectがArray[Double] に変わって
計算できるようになりました。
3日苦労したのが嘘のようです。
非常に助かります。ありがとうございました！ Javaにかぶせたのが間違いだったな
LLVMにしとけばよかったのに scalaでforやwhileを使わずに、下記の計算をする方法、
あるいは行列用のライブラリってありますか？
1. ListやArrayの範囲指定（内容ではなく座標範囲）して抽出や計算
⇨位置指定して演算したい、画像や行列、ベクトルを想定
2. ListやArray同士の四則演算
⇨配列をベクトルや行列として取り扱いたい
pythonのnumpyやmatllab、Rのように、行列演算でscalaを使いたいと考えています。
何かお勧めがありましたらご教授いただけると嬉しいです。 調べると、ND4jやBreezeでしょうか。
後はSparkのデータフレームとか。 linear algebra libraryで調べて自分に合ったの探したら >>899
scala-nativeというものがあってだな Javaのインフラに乗っかれたのは大きかったと思うけどね
ファイルIOくらいScala側で用意して欲しいけど ファイルIOはbetter-filesが来てから何も困らなくなったな
たしかにこういうのは標準であってほしかった scalaの可視化ツールって何を使ってますか？
zeppelin かplotly辺りでしょうか。
plotlyはpytonやRと違い、
local版が見当たらないのが難しいですね。 cala用のjupter notebook やzeppelinは実質的にwindowsはインストール不能ですね。
vegasもレイアウト調整困難で可視化関係は色々厳しいです。 sbt のjarフォルダを絶対参照で書く方法ありますか？
jarが分散してるので統一したいです。 IntelliJでScala書いてるとVisual Studioの素晴らしさが身にしみるわ… 以前、>>893さんにJavaのobject型からScalaへの型変換について教わりました。
下記がその時のコードです。
val result = object_ match {
case double: Array[Double] => double
case _ => throw new InternalError()
}
printで見る限りは Object = Array(91.0, 470.0, 4.0……とでるので
Double型と推定しますが、一部はそうではないのかInternalError()が出て困っています。
型を調べて変換する方法があればご教授いただけると幸いです。
よろしくお願いします。 自己解決しました。
Object.getClass
Class[_ <: Object] = class [F
と出たのでFloatと仮定して
case float: Array[Float] => float
と書き換えた所、通りました。
本来なら下記のように併記して、どのタイプでも処理可能にしたいのですが、
配列がArray[Any]になってしまいますね……。
val result = object match {
case float: Array[Float] => float
case double: Array[Double] => double
case int: Array[Int] => int
case _ => throw new InternalError()
} すみません。誰か教えてください。
Seq なり Array なりデータが 100 件あるとして、先頭20件だけとかコピーしたいんですが、どうしたらよいのでしょうか？ val result =array .slice(0,20) シンボルリテラルって何のためにあるの？
使いどころがイマイチわからん scalaでコンパイラ 2.11, 2.12 みたいにバージョンでライブラリまで分けられてしまうクソ仕様いつまで続くんかな。 せっかく世間から見捨てられて実験場言語に戻れたんだからもう好きにさせてやれよ
Scala本来のあるべき形に戻ったんだよ > せっかく世間から見捨てられて
なんでそう思ってる人がこのスレを覗いてるんですかねぇ… ベターJavaの地位が揺らいでしまって何が実用面で
アピールポイントなのかよくわからん Spark用ネイティブ言語としての地位はあるでしょ。
他はKotlinに取られたようだが スカラップさあ・・・そんなニッチな需要しかないくせに
カンスーがどうのモナモナどうの偉そうにするつもりかい？ バージョン間で互換性ないのってimplicitのせい？ 互換テストをロクにやってないから保証できないだけ
今のScalaには新機能の開発を続けながら十分なテストを行うだけのリソースは無いし、
もはやそれを求められる立場ですらない 互換性のために
旧世代の糞APIを残し続けるJavaみたいなんも
それはそれで良くないよね バイナリ互換はMiMaでチェックするだけしゃないの？
そもそも非互換の変更を行う前提で、x.y.zのyが変わる時はバイナリ互換を維持しないって明言してるんだから
リソース云々とか一体なんの話をしてるのとしか そしてドッティでまた切り捨てるんだろ
もうペンペン草も残らねえな 知り合いが関数型言語とかモナドがとか言ってるけど
それならScala選ぶ意味わからんし
実用的な開発にどう意味があるのか説明ないし。 関数型を学ぶ効能としてよく言われる「コードが綺麗になる」というのはガチ
Javaに戻っても副作用のない小さな関数の組み合わせでコードを書くようになる
もっとも、プログラミングの地力を上げるためと割り切るならHaskellの方がいいけどね
ScalaだとJavaと同じように書けてしまうから矯正ギプスとしては効果が薄いし 関数型のキモは「汚いコードを一箇所に閉じ込める」だからな
そういうライブラリが用意されているか、プロジェクト内でそういう汚い部分を一手に引き受ける人がいれば有用
そうじゃないなら汚いコードがあちらこちらに蔓延して、関数型のメリットはないわコンパイルは遅いわで
何の役にも立たない
結局は人を選ぶ言語ってこと
誰でもそれなりに書けるPHPにはかなわない mapとreduceはデータ整形で非常に便利
これだけで使う価値はあった それだけならJavaScriptでも使ってろ
あと、やたらとreduce使いたがるのは手続き型脳から脱却できてない証拠 このところの 5ch が重かったり鯖落ちしたりというのは
5ch 自体の問題やネットワークの問題もあるが
実はアホの山下謹製専ブラ Jane Style 4.00版のせいだと判明した
これのTLS対応に欠陥があり、毎回フルハンドシェイクを行って鯖の負荷を増大させていた
その他にもツッコミどころ満載のクソソフトなので
使っている人を見かけたらすぐにゴミ箱に捨てるように言ってほしい 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
2581E >>945
再帰とreduce(fold)ならならreduceの方が良いと思うけど、何と比べての話？ Scalaに興味を持ち始めたはいいが今からならdottyの方がいいのか？ なんで今更Scala?
さすがにお勧めできないからKotlinにしとけ
今のScalaは既存資産のメンテで辛うじて生き残ってる状態なのに、今更互換性を捨ててリセットするという最悪の決断によって完全消滅は決定的になった
やったことないんならまずはKotlinの範囲だけでも十分に目新しいはずだから、Scalaに手を出してみるのはその後でいい Sparkとかあのへんは絶対dottyにはついてこなそうだから、ただでさえ虫の息の開発リソースが更に分裂することになる
さすがにPython3のようなリセットを乗り越える体力はもうScalaには残されてない >>954
KotlinやるならHaskellやOCamlだろ
Scalaに来るような人たちは関数型目的なんだろうから、Kotlin勧めるのは的外れだよ >>954
>>956
関数型自体の地は既にあって、マルチパラダイム的に設計するのにそれらしい言語が欲しいのよ
それぞれ十分な機能を持つと考えてった結果F#かScalaかみたいな状態で訊いた次第 >>957
だったらScalaでいいんじゃないかな
さすがにF#とScala比べるんならSclaaの方がいいし F#、速度以外はベターOCaml感あって今後に期待してるけどな
Scalaは今後に期待が出来なさそうなのがキツい >>958
それはこの目的ならF#とScalaではScalaだし、現行ScalaとDottyなら現行Scalaという解釈で構わないか？ >>960
何がしたいのかによるだろ
普通にアプリ(Web, クライアント, スマホ)作りたいんならF#は普通にC#資産が利用できるから悪くはない
ScalaはJava資産の活用とか言いながらJavaとあんまり相性良くないから、
死屍累々のScala専用のライブラリやフレームワークの残骸を集めて回るという反吐の出る作業になる
大規模分散処理とかやりたいならScalaはまだまだ強い >>961
何をしたいかについては既に書いたが"マルチパラダイム的な設計をする"だよ
実務よりはひとまずファンユースという認識をしてくれて構わない(自分も慣れてない言語を実務投入はしないでしょ)
F#については迷う要素が無いから既に触ってるけどScalaはDottyってのがあるらしいってなったから訊いたの >>962
Dottyはそこまでおすすめはしない
情報が少ないので自分で地雷踏んでも解決できる程度じゃないと
（そういう人間がここに書き込むとも思えないので） 人間の仕事を楽にするためのプログラムで苦しむ馬鹿ドMがおるってマ？
ドッティはどこに向かってるッティｗ 童貞サカラボーイズ
今日も引きこもってドッティと共にどこに向かってるッティ！ｗ >>965
だいたいどういう立ち位置か分かった
ありがとう 立ち位置も糞も
もう棺桶に両足突っ込んであとは寝るのを待つだけ状態ッティｗ 必死リンクだけ書いて何か言ったつもりになっている奴っているよな。
とにかく俺の言う事が気に入らないもんだから
何とかして俺のレスを無効化してやりたいのだが、
かといってどこにツッコミ所があるのか具体的に指摘出来ないし
俺と正対して論破出来る知識も自信も無い、
何より自分の無知を曝け出す結果となって
かえって自分が周囲の嘲笑の的となってしまうのが怖い。
そこで、とりあえず無言で必死リンクだけを付けておく事で
「こいつイタイなｗ晒し上げｗ」と必死に周囲に印象付けようとする。
具体的指摘を伴わない無言レスアンカーなら
自分の勘違いだったところで自分はちっとも傷付かずに済むからな。
肝心のどう“イタイ”のかについては周囲にお任せ。
きっと読んだ人それぞれが頭の中で勝手に考えてくれるさ！！
俺には、無言レスアンカーからは
「ママ、こいつをやっつけてよ！」という悲痛な叫びが聞こえてくるね。 何が言いたいんだこいつは
必死リンク貼られるのが嫌でごちゃごちゃ言ってるようにしか見えんのだが ただでさえガイジみたいなコンパイル速度と関西型原理主義ガイジどものせいで虫の息だったのに
Kotlinの登場で完全に息の根止められたな
今さら何がドッティだよｗ
完全にオワコンッティｗ あぁ、必死リンク貼られるとただの荒らしだとバレるのが嫌なんだな
わかりやすくて失笑 バレてるのはサカラボーイズが糞サカラプロジェクト負債の敗戦処理に苦しんでることだけだぞ http://mevius.5ch.net/test/read.cgi/tech/1530664695/66
こんなこと書いてるようじゃ、荒らしと見られちゃうもんね
そりゃ必死リンクを必死に嫌がるわけだわ、あんな長文まで書いてｗ 過剰反応
必死な長文
自分に興味が向いてると思い込む
中身空っぽなクソレスにツッコミ欲しがる
妄想ストーリーを展開 ScalaでOpenCV使ってるんだけど
Matに入ってる画像のpixelを直接いじりたいんだけど
val pxl = mat.get(y, x) <=Array[double]
なんだけど
mat.put(y, x, pxl)
ってやるとCannot be appliedって出る。
Array[Double]じゃなくDouble*をよこせって言ってるみたいなんだけど
Double*ってなに？
教えて なんとなくscala がいいなと思って参考書購入し読み始めたけど、
先行き不安な言語なのですか？ >>980
先行きは不安というか明確に「ない」
今のScalaは一時期Apacheの金でアホみたいに生産されたビッグデータ系フレームワークのメンテの為だけに生かされてる
dotty移行でめでたく既存資産もゼロになって、Closureと同等くらいのマニア言語の一つになる ClosureとClozureとClojure間違えられ過ぎでしょ もっといろんな分野で使われてるし資産価値ゼロは言い過ぎだと思うけど待ちくたびれた感はある なぜ資産価値ゼロみたいな極論にぶっ飛ぶのか
基本ライブラリに密結合してるようなコードは移行がめんどくさいだろうけど
大抵のアプリケーションは機械的に置き換えて終わりでしょうに なぜ機械的に置き換えて終わりでしょうにみたいな極論にぶっ飛ぶのか
基本ライブラリに密結合してるようなコードは移行がめんどくさいだろうけど
そんな破壊的な変更繰り返すカス言語は他の言語に置き換えて終わりでしょうに Scalaがオワコンみたいに言ってる人いるけど、
そもそも始まってすらないじゃん。 Javaの有料化でScalaへ一斉に移行するだろうな 移行ツールも提供されるんじゃなかった？
非互換部分はコンパイルエラーになるだろうから
Pythonみたいな酷い事にはならないと思うけどね。 JVMも込みだから言語だけ替えてもなにも変わらん。 少なくとも今のところScalaを置き換えられるような言語は見つかっていないわ 見た目はF#, Swingの方が好き
(letがすっきやねん) >９８９さん
Javaの有料化？
そんな予定があるのですか？ ∧,,,∧
( ・∀・) 1000ならジュースでも飲むか
( )
し─J このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1099日 16時間 54分 45秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
