まともにモジュール化設計もできていない保守不能糞コードの設計者を「エリート様」と皮肉って、「バカな私は、シンプルさを求めたScalaを使う」と言う記事。
センスに溢れて「いいぞーもっとやれー」と応援したくなってしまいました。
では、ここで真面目に補足もしておきたい。
シンプルに書くのはバカにはできません
シンプルに書けるよう設計するというのは、実は相当難しい。
以前紹介した「ReadableCode」なんて書籍が書けてしまうくらい、可読性を高く、可能な限り多くの人が保守できる設計というのは実はかなり難しい。
では逆に「シンプルにしていない者こそバカ」と言い切ってる。
タイトルに反してScalaはバカ向けなのか？
もちろんここの「バカ」は 「Coboler のようなエリート様」と対比するための皮肉なのは百も承知だが、それを脇に置いておいたとしても、Scala を真面目に理解してそれらしく書くのはきっとバカには無理じゃないかと思う。
よく入門書として使われている、コップ本 なんかは有名なのだが、これもなかなかの厚さを持っている。
つまり学習コストはそれなりに高い。
- JVM システム同様に、オブジェクト指向を強要する
何を今さらと言われるかも知れないが、業界で働いていても「オブジェクト指向の3点セットは？本質は？」で躓く人は結構多い。
技術ブログ書いてたり、勉強会行く人間には「何を今さら」なレベルなのだが、現実問題一つのハードルと考えていいハズだ。
まして Scala は Java よりもオブジェクト指向が徹底している。 - 関数型の思考もそれなりに要求する
関数型の思考で最たるものは、「関数」が第一級オブジェクトであるという考え方だ。
「関数というオブジェクトを作成して、定数、変数、引数、返値にしたうえ、その先で実行できる」という事を理解すること。
実は JavaScript もその意味では関数型なのだが、この思考も一つのハードルになる。 - 豊富なコレクションメソッド
どちらかというと関数型言語の真価の一端といった方がいいかもしれないが、
Scalaコレクションメソッドメモ(Hishidama's Scala collection method Memo)
使いこなせ…というのは酷だとは思うが、何かに触れ「そういやこんな事ってできたような…」と思って調べようと思えるくらいの全容把握にどれくらいかかるか？
基礎レベルですらこれだ
また、省略可能な規則の把握、DSL の設計等も含めて、果たしてそれがバカにできる事だろうか？
それにより、海外の企業向けソーシャルを行っていた Yammer （現Microsoft傘下）は、Scala の採用をやめてJavaに移行し始めた。
言語としてのScalaは興味深い特徴を持っている。しかし、とても複雑な言語でもある。 Scalaがもたらす概念や実装に加えて、自然なScalaを書こうとする文化がある。これを突き詰めるとある時点でベストプラクティスが現れる。それは、コミュニティを無視することだ。 後になって気付いたことだが、私はScalaを学ぶこと(教えること)の難しさと重要さを低く見積もりすぎていた。というのは、Scalaの経験のある開発者を雇うのは不可能だからだ。これは思ったよりも遥かに大きな問題だ。
内容は 2011 年のもので、今と情勢が違うのは間違いないが、要するに
- 学習コスト高くて、きちんと使うのはなかなか難しい
- そもそも Scala エンジニアは数が少なすぎて雇えないから、チームの習熟には余計にコストがかかる
という話だ。
求人を見ると Scala エンジニアの募集は速攻で見つかる。国内なら尚更だ。
逆を言えば
それだけ Scala が使えるエンジニアが足りてない
という事の裏返しとも言える。
バカでも使えなくはないScala
正確にはこう言うべきかもしれない。
Java っぽく書こうと思えば書けるし、関数型っぽく書けると言えば書ける。
とも書く、書いて動かすだけなら、(静的型の割には)凄まじく自由に書ける。
しかし、使いこなそうと思ったら、本にして人を殴り殺せそうな量の仕様を把握する必要がるということだ。
でもやってみればそこまで恐れる程でもないよ？
とってつけた（ホントそう）ようで申し訳ない。散々脅しておいてなんだが、言うほど怖い話でもないんじゃないかと思う。
要は、毛嫌いせずにやってみればきっと気に入る言語だってレベルの問題でしかない。
学習コストといっても、言語使用の数は Ruby の学習コストとそう変わらない。
むしろ静的型の制約が入る分、Ruby より楽かもしれない。