KotlinとPragmatism / Pragmatism in Kotlin

Transcript

1. KotlinとPragmatism 2026年09月08日 Kotlin 15周年記念イベント せきね じゅん @jsoizo
2. 自己紹介 関根 純 せきね じゅん 経歴など いくつかの事業会社で開発に従事したのち、 現在は株式会社コドモンで働いています。 kotlin-csvのメンテナ。Kotlin Fest登壇予定です。 愛知県出身、都内在住。ディズニーとサッカーが趣味 X, GitHub: @jsoizo 2
3. Pragmatism??? 3
4. Kotlin 1.0リリース時のブログ 4
5. ゴール Pragmatism = 実用性 は、Kotlinを語るうえでは欠かせない特徴です。 ただ、“実用性” と言われてもその解釈には幅があるのではないでしょうか。 このトークを通して、 公式ドキュメントや過去の情報、リリースや実装方針を見ながら、 Pragmatismの定義や、どう言語機能に落とし込んでいるかを考えてみます。 ※ あくまでKotlinにおけるPragmatismの “私の解釈” にすぎないです。 みなさまがどう感じているかなどは懇親会でお話できたら嬉しいです 5
6. 今日話すこと 1 Kotlin言語は何を実用的と考えて作られたか 2 Pragmatismがどう現れているか 3 現代 (KMP, Agentic Coding) でも変わらないか 6
7. 2011年のブログから With Kotlin, we’re building upon the many years of experience creating development tools for different languages, and hoping to provide a language which is productive enough for today’s environment and at the same time simple enough for every programmer to learn. One thing to note: since we’re a development tools company, we’re building firstclass IDE support for Kotlin in parallel with the language itself. ―― Hello World - The JetBrains Blog 7
8. 2011年のブログから First and foremost, it’s about our own productivity. Although we’ve developed support for several JVM-targeted programming languages, we are still writing all of our IntelliJ-based IDEs almost entirely in Java. The IntelliJ build system is based on Groovy and Gant, some Groovy is also used for tests, there is some JRuby code in RubyMine, and that’s it. We want to become more productive by switching to a more expressive language. At the same time, we cannot accept compromises in terms of either Java interoperability (the new language is going to be introduced gradually, and needs to interoperate smoothly with the existing code base) or compilation speed (our code base takes long enough to compile with javac, and we cannot afford making it any slower). ―― Why JetBrains needs Kotlin - The JetBrains Blog 8
9. 2011年のインタビュー記事から 当時 Twitterが採用するなど 勢いのあったScalaを明確に意識していた “We’ve looked at all of the existing JVM languages, and none of them meet our needs. Scala has the right features, but its most obvious deficiency is very slow compilation,” said Dmitry Jemerov, JetBrains development lead, on Friday. JetBrains wants the object-oriented Kotlin language to be safer than Java, statically checking for pitfalls such as null pointer dereference, and more concise than Java. Another goal is to make it simpler than its “most mature competitor,” Scala. ―― JetBrains readies JVM language Kotlin - InfoWorld 9
10. Androidの制約に面して And Kotlin would have been a whole lot easier to design and develop if not for the Java interop, Maven integration, and Android compatibility! It would definitely be more elegant in many ways. But elegance, though highly appreciated, is not the primary goal here – the primary goal is being useful. And the less our users have to relearn, reinvent, redo from scratch, and the more they can reuse, the better. ―― Kotlin 1.0 Released: Pragmatic Language for the JVM and Android - The JetBrains Blog 2010年台前半のAndroid APIはJava 6,7相当。Lambdaもdefaultもない。 KotlinではJava 6バイトコードのままそれらを言語側で埋めた。 && 1.0.2でメソッド数が64Kを超えないよう削減も行われた。 10
11. 当初のKotlinの指すPragmatismって？？ プログラマが実務で生産的に仕事を進められることを優先する 1. Javaエコシステムとの高い相互運用性 2. 少ないコードで、安全かつ生産的に書ける 3. 言語だけでなく、ツールチェーンを含めた開発体験を重視する 4. 現実的なコンパイル時間 5. 理論的な美しさや機能の強力さより実際の使いやすさ 11
12. Pragmatismは境界に現れる 境界 = Pure Kotlinな部分とJava部分 先述の通り、Kotlinの言語設計はJavaとの相互運用性の容易さが重要で、 Javaとの相互運用の境界部分に、Pragmatismを見出すことが出来る。 KotlinではJava資産を容易に使えて、 JavaからはKotlin資産をJava資産のように使いたい。 12
13. 例: Platform Type こういうJavaコードがあったとして、 アノテーションがないことでNullを返しうるかが分からない // @Nullable String getName(); Kotlinから、Java由来の型についてnullabilityを確定させずに扱える。 自体は （ // javaObj.name String! Platform Type val a: String = javaObj.name val b: String? = javaObj.name ）として解釈される 13
14. 例: Platform Type Kotlinの仕様上、Java由来の型をすべて T? として扱うこともできた。 が、Java APIを利用するたびにnullチェックが必要でコードが冗長になる。 Javaコードの仕様を把握していて、 null が返らないと判断できるなら String として受け取れる。 一方で、 null の可能性を排除できないなら String? として受け取ればよ い。 Javaとの境界を実装する人に、安全性と認知負荷のトレードオフを選択でき る余地 を残している。 14
15. 例: コレクション型のヒエラルキー Scala(2.13以降)の場合 — java.util とは独立した型階層 scala.collection (2.13以降) IterableOnce +- Iterable +- Seq +- Set +- Map java.util ✕ 実装関係なし Collection +- List +- Set Map ( ) 独立 import scala.jdk.CollectionConverters._ javaApi.process(xs.asJava) // コピーではなくラッパーを1枚かぶせる 不変性を型で保証できる。代わりに境界では変換が要る。 15
16. 例: コレクション型のヒエラルキー Kotlin(1.0)の場合 — 宣言はKotlin、実体は java.util kotlin.collections (コンパイル時) Collection +- List / MutableList +- Set / MutableSet Map / MutableMap javaApi.process(xs) // java.util (実行時) = Mapped types Collection +- List +- Set Map ( ) 独立 変換なし。java.util.List そのものが渡る シグネチャはどちらも java.util.List 。 16
17. Kotlinのアプローチ • List は read-only であって immutable ではない ◦ 変更メソッドが見えないだけ。実体が ArrayList のこともある • Javaから見れば java.util.List — read-onlyでも add が見える ◦ map の結果は ArrayList 。Javaから add が通る 不変性を型で保証することより、Javaの資産の再利用を優先した。 不変性が重要ならば kotlinx-collections-immutable を使えば良い。 17
18. 15年経ってのPragmatism KMPの時代となり、Kotlinが動く環境はJVMやAndroidだけではなくなった。 境界がJavaからその他のプラットフォームにも広がっただけ。 We are going another way: providing a common language for all platforms while enabling creation of common libraries through seamless interoperability with platform code. ―― Kotlin/Native Tech Preview: Kotlin without a VM - The JetBrains Blog allows developers to share code across platforms while retaining the benefits of native programming ―― Kotlin Multiplatform Is Stable and Production-Ready - The JetBrains Blog 18
19. Pragmatismは境界に現れる part2 境界 = Pure Kotlinな部分とそうじゃない部分 が増えている • expect/actual — 共通コードとプラットフォーム実装の切り替え点 • cinterop / external宣言 — KotlinからプラットフォームAPIを呼ぶ • Swift export — プラットフォーム側からKotlinを呼ぶ 19
20. expect/actualにみるPragmatism KMPがサポートするプラットフォームにはエコシステムが出来上がっている • Apple → Foundation / UIKit / Swift・Objective-C libraries • Linux → C / POSIX libraries • Web → JavaScript ecosystem これらを無視して、Kotlinのために同等のAPIやライブラリを ゼロから作り直すのは現実的ではない。 expectで共通宣言、actualで各プラットフォームのライブラリに委譲する ことで、既存のエコシステムを活かしながら共通化をはかる。 20
21. Pragmaticなものをうまく使うために 相互運用性を高めるかわりに、 境界をまたいだ整合性や一貫性は開発者の実装により担保して。 という思想であると解釈。 プラットフォーム間での共通化はどの程度にするか？ どこが安全性を壊しうるポイントであり、いかに安全にするか？ が、Kotlinプログラミングにおいて重要な設計ポイントとなる。 21
22. Agentic Codingの時代において 先に示したPragmatismの解釈はそのままに、これらの重要度が上がる。 2. 少ないコードで、安全かつ生産的に書ける 3. 言語だけでなく、ツールチェーンを含めた開発体験を重視する 4. 現実的なコンパイル時間 開発体験の主語が人 (およびIDE) からエージェントに移るので、 ツールチェーンやビルド速度など、変化・強化が求められている。 22
23. 見守っていきたい 1. Language Server Protocol • IDE/エディタやエージェントと言語解析エンジン間の標準化 2. Agent Client Protocol • コーディングエージェントとIDE/エディタ間の標準化 3. Kotlin Toolchain • 軽量でagent friendly(?)なプロジェクト管理 23
24. まとめ Pragmatism = 実務で生産的に仕事を進められることを優先する • Javaとの相互運用、ツールチェーン、コンパイル時間など 「現場で使えるか」を美しさより優先して設計された • そのスタンスはJavaとの境界に現れる (Platform Type, collection)。 相互運用に有利な既定を選び、厳密さは境界の実装者に委ねる • 現在でもかわらない。境界はJavaからプラットフォーム全体に広がり、 Agentic Coding時代には開発体験の主語が人からエージェントに移る 24