Kotlinは素晴らしいが、いずれにせよJavaにとどまる理由

どのグループに所属していても、そのグループに留まるのには理由がある。 ジャワ.そして、私はあなたを責めているのではない。間違いなく、この国で最も発達した、普遍的で完全なエコシステムがあるのだから。 企業 の世界だ。この言語には、多すぎず少なすぎずのちょうどいいゾーンにある、うまく調整された機能セットがある。また、新しい機能も徐々にではあるが着実に追加されており、プログラミング界の新しいトレンドにほぼ対応している。

ご存知ですか？ ロンボク島 けど？もしそうでないなら、ぜひ試してみてほしい。もし気に入っていただけたなら、ぜひ試していただきたいものがある。ロンボク語を時代遅れにする、まったく新しい言語だ。その名も コトリン.

Kotlin？Androidの言語のこと？

Android上のKotlinは、Google自身によって祝福され、このプラットフォームにおける事実上の選択言語となった。この記事で取り上げるのはこのことではないが、Androidは私が初めてKotlinに出会った場所である。

私の職場の同僚は、当時最新のアプリを開発していた。 プロジェクトしかし、締め切りは迫っていた。しかし、締め切りが間近に迫っていたため、私は彼が締め切りを守るのを手伝うよう委任された。では、その瞬間にタイムスリップしてみよう。あー、うっさい！みたいな変な言葉を使っている。 ケチャップブランド!?ひどすぎる！

なぜすべての関数の前に "fun "と書かれているのか？まるで、それが何なのかすでに私が知らないかのように。また、私はすでに 楽しい と ジャワ とにかく。リターン・タイプはどこに？最後か？正気か？関数に何かを代入しているのか？意味がわからない！まるで Javaは余分なステップがある！ 待てよ、このメソッドが属するクラスはどこだ？どこに隠したんだ、このケチャップみたいな音は、 ジャワ プログラミング言語を真似た言い訳？そんな。いやいや、そんなことはない。これってグローバル関数？もういい、警察を呼ぶぞ。

ネタバレ》 私は警察を呼ばなかった。好むと好まざるとにかかわらず、Java中心の考え方を別の言語に対応させなければならなかった。でも、そんなに悪いことじゃないでしょう？JVM言語であることに変わりはない。 ジャワ.もしかしたら、クールな追加機能もあるかも？しぶしぶ、私はそのプロジェクトに取りかかった。

余分なステップのあるJava

Javaがそんなに素晴らしいなら、なぜJava 2がないのか？ 冗談はさておき、私はそう考えた。KotlinはJava 2だと思えばいい。新しい構文でも何でも、プロジェクトを完成させるのに十分な量を学べばいい。しかし、それは間違いだった。

ほんの1日か2日試しただけで、私はすぐにKotlinと ジャワ 伸縮性がないのだ。互いに曲げようとすると、必然的にどちらかが真っ二つに折れてしまう。Kotlinはそれ自体で成り立つものであり、JVM上で動くという事実は、プログラマーの立場からはほとんど何の意味もなさないことが明らかになった。(余談だが、KotlinはJVMにトランスパイルすることもできる。 JavaScriptまたはネイティブ・バイナリにコンパイルされる）。

それならプランBだ。実際に、この言語を知ることだ。初めてドキュメントを読むと、ベテランのJavaプログラマーは背筋がゾッとする。例えば
- 前述のトップレベル、別名グローバル・コンテキスト
- 最後に指定されたパラメータと関数の戻り値の型

fun sum(a: Int, b: Int)：Int { {.
   return a + b
}

関数本体は式にできる（等号を使用）

 fun sum(a: Int, b: Int) = a + b

if文は結果を提供できる

 val y = if (x == 1) { {.
 "one"
 } else if (x == 2) { { "1
 "二"
 } else {
 "other"
 }

オーケー、慣れる必要があるね。構文が違うだけだ。Kotlinさん、他に何かありますか？

 value?.method() // nullでなければ実行

ああ、わかった。 if (value == null)あなたのために1点。他には？

fun check(list: List, alternative: Boolean) = when {.
 list is LinkedList -> print("linked")
 alternative -> print("alternative")
 list.size > 50 -> print("大きい")
 else -> print("その他")
 }

うーん、いいね。他の選手がブロックしてきたら避けられるし、便利かもしれない。

 object SingularObject：カウンタ()
 var a = 14
 fun test() = if (a > 10) "more" else "less"
 }

なるほど、これは実際に使えそうだ！一方、Javaでもシングルトンは作れる。こんなにエレガントではないかもしれないが、目新しいものではない。あなたの袖に何かエースはいる？例えば、ヘビーヒッターとか？

 var s：String = null // コンパイルされない、非NULL型

待って...何？

10億ドルの過ち

ヌル・セーフについて心配する必要のないコードベースを想像してみてほしい。すべての参照が実際に意味のあるものを含んでいることを当然と考えることを想像してほしい。ヌル関連の問題はすべて事前に対処されていることを想像してみてほしい。
もう想像しないでほしい。Kotlinのすべての参照は、デフォルトではnull可能ではない。null可能にしたい場合は 意識的に その決断を下す。 明確に に記載されている。 コード:

 var s：文字列？

この時点で、あなたがこのアイデア全体に懐疑的であることは理解している。あなたはnull可能な参照に慣れている。コーディング中も頭の片隅に置いているはずだ。注意しなければならないところを学んだはずだ。まさに私の考えだ。出身は ジャワ確かに最初は変な感じだった。何の意味があるんだ？魔法のように関連するすべての問題が消えるわけじゃない。あちこちに"? "を付け足す必要があるだけで、面倒くさそうだ。

でも、私は言葉の奥深くに飛び込むことにしたんだよね？君のやり方でやろう コトリン.私は、null可能な変数、フィールド、パラメーターをできるだけなくす努力を始めた。例えば、セーフコール"?. "演算子、エルビス"?: "演算子、デリゲートされたプロパティ、"let "メソッドなどだ。

時間が経つにつれて、私はいくつかのクラスが非NULLフィールドとメソッド・パラメーターだけを含むようにすることに成功した。基本的に、クラスがうまくインスタンス化されれば、メソッド本体のヌル性についてはほとんど忘れることができるとわかっていた。それは至福の時だった。時間が経つにつれて、私はこのことをますます評価するようになった。しかし、結局のところ、これをキラー機能だとは思っていなかった、 ジャワ それでもまだ故郷のように感じていた。それまでは...

カムバック

プロジェクトは終わりに近づいていた。私はKotlinをより深く知るようになり、その知識によってコードはますます整理され、読みやすく、簡潔になった。コミット履歴を見れば、肉眼で改善点を確認することができた。しかし、ついにその時が来た。新しい言語への思いがけない思い出とともに、別れを告げ、Kotlinの甘美な快適ゾーンに戻る時が来たのだ。 ジャワ.そう思った。

何かがなくなった瞬間に、そのありがたみがわかるという感覚をご存知だろうか。それが使えなくなって初めて、自分がどれだけ何かに依存していたかに気づく。それは、私が今までの人生で経験したことのない感覚だった。

でコードを書くことに戻った。 ジャワしかし、いくつかの機能が欠けていることに恐怖を感じそうになった。まるで私の脳が無意識のうちに、Kotlinの機能をJavaに間違って後付けしているようだった。実際に何かを実装し始めたときに、この言語では動かないことに気づくという状況を経験した。最良の場合、Kotlinライクに書くことはできるが、かさばるし、読めないし、ボイラープレートが多すぎる。

もちろん、Nullセーフティは私が最も恋しかった機能だ。名前付きパラメータ、ゲッターとセッターの代わりにプロパティ、等号としての"=="と参照等式としての"==="、修飾された "this"、拡張関数、暗黙の単数ラムダ・パラメータ、未使用のラムダ・パラメータに対する"_"、データ・クラス、スコープ関数、その他のKotlin標準ライブラリ関数、演算子などなど。そして、そのすべてがうまく組み合わさっている。それに比べてJavaは...原始的な感じがした。

実際、私はKotlinに完全に乗り換えることを検討し始めた。理論的には、KotlinはJavaと完全に相互運用可能で、既存のプロジェクトにKotlinのサポートを追加するだけで、新しいクラスを書き始めることができる。Kotlin側はJavaと「会話」する方法を知っており、Java側は他の言語と「会話」していることすら知らない。また、バイトコードにコンパイルされた後は、JVMにとっては何の違いもない。

リアリティ・チェック

何を待っているんだ？もしその言語があなたが言うように優れているなら、それを使えばいい！既存のプロジェクトでは使えないかもしれないが、相互運用可能であるべきなのは分かっている。

よし、新しいモジュールにはKotlinだ。それとも？あなたは チーム.彼らに相談し、この新しい言語の素晴らしさを説得する必要がある。え？嫌がっている？学ぶ努力をしたくないだけみたいだね。あなただって最初は半信半疑だったのだから、彼らを責めることはできない。

プロジェクトマネージャーそうだ！彼はきっと、Kotlinが私たちのチームにもたらす大きな価値を理解してくれるだろう。ああ、偉大なことがやってくる！
-いいえ
-待って、どうして？
-チームはそれを知らない。
-彼らは学ぶだろう！
-彼らは学ぼうとしない。
-作ることはできる！
-彼らは学ぶ必要がない。
-それはそうだけど、可能性について考えてみてよ！
-そうだ、まず問題を考えてみたらどうだろう。

伝説によると、あるプロジェクトが存在する。そのプロジェクトは大きく複雑だが、すべての部分がうまく書かれている。開発者全員が、使用されているソリューションについて一致団結しているプロジェクト。新機能がプログラマーのキーボードからスムーズに流れてくる。バグはほとんどなく、修正も簡単だ。

そういうプロジェクトを見たことがありますか？私は見たことがない。いくつかはそれに近いが、ほとんどはレガシーコードの大混乱だ。もしそうでなかったとしても、おそらく将来のある時点でそうなるだろう。別の言語をミックスすることを想像してみてほしい。それはミスを犯す新しい方法を導入することになる。開発者は、自分が何をしているのかを知る必要がある。控えめに言ってもリスクだ。

開発者のローテーションについても考えてみよう。人は入れ替わります。新しい開発者全員にまったく新しい言語を学ばせるのか？いや、それは逆効果だ。そもそもKotlinの開発者を雇うのか？幸運を祈る。優秀なJava開発者を雇うのは十分に難しい。

人々は試した。 私はこの記事の主張のほとんどに同意できないと言わざるを得ない。そこには妥当な批判もあるが、彼らは「Kotlinのやり方」を実際に理解するほどKotlinを使っていなかったのだと思う。この記事のコメント欄の多くも同じように考えているようだ。

しかし、それは問題ではない。あなたのプロジェクトでも、きっとこんなことが起こるだろう。「やってみたけど、気に入らなかった」。時間をかけさせることはできない。再挑戦はさせない。再挑戦させることもできない。そして、現実的な見地からは、彼らが正しいかもしれない。 ジャワ があまりに人気があるので、JVM上で他のものを使うのは冗長に思える。

では、なぜこの記事なのか？

あなたは相当な時間を費やして記事を書いている。どうせ無意味だと言うのなら、なぜ言語を学ぼうとするのだろう？

まあ、無意味だとは思わない。今でもKotlinは素晴らしいと思っている。今でも実際に使ってみたいと思っている（実際にプライベートなプロジェクトでは使っている）。できることなら、Kotlinに乗り換えてJavaの制限を忘れたい。でも、今の現実はそうできない。それを変えたいんだ。

親愛なる読者であるあなたへの私の意図は、少なくとも居心地の良いJavaの快適ゾーンから出る可能性を受け入れることだ。なぜなら、もしかしたら、もしかしたら、あなたも私と同じようにKotlinを好きになるかもしれないからだ。もしそうなれば、Kotlinを知る開発者が1人増えることになる。 マーケット.

続きを読む

Javaに最適なプロジェクトの種類

新興企業のソフトウェア製品開発に共通する3つの課題

トップJava開発者を見つける正しい方法