Kotlin and Conceptual Backporting

Kotlin on Android!

いやーめでたいね。諸事情で当分仕事では使えなそうな気配だが、それでもめでたい。どのくらいめでたいかというと Steve Yegee が思わず blog を書いてしまうくらいめでたい。

余暇で Kotlin をかいたあと仕事の古い Java に戻ると色々なフラストレーションを感じる。これは必要な痛みだと思う。以前に感じていたよりはっきりとした形でダメさを識別している。昔々 C++ が一番得意だった頃に C 言語をやらされたときのことを思い出す。あるいは元気だった頃の Java をしばらくさわってから C++ をさわったとき。最近だと Haskell 入門してから Rx をさわるとかも。

相対的に新しいものをさわってから古い世界に戻ると、古い世界に足りないものがはっきりとわかる。だからできる範囲で新しい世界のツールを backport しようとする。(古い例: C 言語でオブジェクト志向、Emacs でリファクタリング) そうした conceptual backports には不自然なものも多いけれど、古いテクノロジを新しい世代に引っ張っていくのは基本的にこうした backports でもある。

保守的なチームで働いていると新しいテクノロジを仕事で使う機会がなかなか来ないけれど、くじけずたまには新しいものを触っておかねばなあ。そして新しい概念をちまちまこっそり backport していきたい。


ソーシャルメディアなどをみているとなぜ Go なり Swift なりを採用しなかったのか企業政治残念、みたいなことを言ってる人がちょこっといるけれども、おまえら Android アプリのコード書いたことあんのかあるいは Android 本体のコード読んだことあんのか、と思う。なぜ Scala, Groovy じゃないのか、というなら百歩譲ってわからなくもないけれど。I/O 中はついウェブをしてしまったせいで無駄に精神衛生を損ね反省。

なおなぜ Scala や Groovy や Clojure じゃないのかは、まあ一通り試せばわかります・・・自分も Groovy でいいのではと思っていた時期がありました・・・ NYTimes が一時期 Groovy を使っていた(2014)けど, 遅くてやめた(2016)という話を思い出した。わかるよ。Java とっくに飽きたけど Groovy も思ったより厳しかったよな・・・。