プログラミング・IT・英語・数学とか

英検1級、TOEIC満点(990点)、セキュリティスペシャリスト、DBスペシャリスト、ネットワークスペシャリスト。英語とITとか。いろいろ試してみたことを書いていきます

KotlinとScalaの違い (部分的な翻訳: Kotlin vs Scala: Which Problems Do They Solve?)

はじめに

KotlinろScalaって何が違うんだろう?って思っていろいろ探してみたところ、英語の記事があってわかりやすかったので、役に立ちそうな部分だけ部分的に翻訳してみました。1語1語訳していくと大変だし、ざっくり知りたい人には必要ないかなと思うので、けっこう省いて日本語にしてます。

時間がない人は、この記事の最後の方の「まとめ」部分だけを読んだら良いと思います。

間違いなどあったらごめんなさい。間違いを指摘してただけると助かります・・・。

そして、ぜひ原文もご参考にしてください。 

元記事

https://superkotlin.com/kotlin-vs-scala/

KotlinとScalaの違い

Javaに立ち向かえるような2大言語をあげるとしたら、ScalaとKotlinが挙げられるのではないでしょうか。少なくともJVMアプリケーションを使おうとしたときには、この2つがまず検討されると思います。

ScalaとKotlinは「Javaをより良くする」という目的のもと作られていることは同じですが、その方法はとても異なるものでした。

まず、Scalaは学者たちによって考え出されています。それに比べて、Kotlinはソフトウェア会社で作られています。Scala関数型言語や異なるプログラミングパラダイムを1つの言語に入れてみようという考えのもと作り出されており、一方、Kotlinは現実の問題を解決することに重きをおいており、コンパイル時間を短くしたりツールの充実などを図っています。

Scalaのすごいところは、JVM上で動く、新しい静的言語を作ることが可能だと証明したところにあります。その後、かなりの時間が経ってからKotlinが出現し、その頃にはJVM上で走る新言語を考えることよりも、実用的に使えることをより重要視するようになっていました。

以下では、KotlinとScalaを比較していきますが、技術的な機能ではなく、使い方の面で比較をしていきます。まず、2つの言語の機能の概要を見て、その後、何のために作られた言語なのか、に焦点をあてて見ていきます。

Javaの何が悪い?

KotlinもScalaJVM上で走るため、Javaとよく比較されます。では、Javaにはなにか悪いところがあるのでしょうか?

Javaは「一度書いたらどこでも使える」という売り文句で、またたく間に世に広がりました。

おそらく、世界で一番使われているプログラミング言語Javaでしょう。世界中の企業で使われ、大学のコースでも広く使われています。

Cより成長しC++よりきれいな言語であるJavaですが、最近では他の言語に遅れをとっています。C#と比べて劣ると言う人も多くいます。

「もっとJavaが生産性の高い言語だったらいいのに、」「もっと楽に楽しく使える言語だったらいいのに」と思う企業やプログラマーは多いことでしょう。また、Javaの言語仕様上の制約があり、その制約のために批判があるのも確かです。しかし、だからと言って、そう簡単にJavaを変えることはできません。世界中ですでに広く使われているために、悪い部分があっても根幹部分を変えることができないのです。(いきなりJavaそのものを変えたら、いままで作ったものが動かなくなってしまいますから)

KotlinとScalaの主な違い

オブジェクト指向

Javaオブジェクト指向の言語ですが、Java内のすべてがオブジェクトというわけではありません。例えば、intなどはプリミティブ型です。ScalaとKotlinではすべてがオブジェクトであり、オブジェクトとしてアクセスできます。

また、ScalaとKotlinは他のプログラミングパラダイムを取り込んでいます。Kotlinは主にオブジェクト思考ですが、普段のプログラミングで便利であろう機能を他のプログラミングパラダイムから取り込んでいます。

関数型プログラミング

 Kotlinは関数型プログラミングのすべての機能をサポートしているわけではありませんが、ラムダ式高階関数などの関数型プログラミングの機能をサポートしています。たとえば、以下の機能をサポートしています。

  • ユーティリティークラスを作ってメソッドをまとめなくても、関数だけを作るだけでOK。
  • Kotlinはstatementsではなくexpressionsを定義できるので、ifの結果などを変数に格納することができます。
  • varではなくValを使えばイミュータブルなデータを作れます。finalなどの修飾子は必要ありません。

Scala関数型プログラミングパラダイムオブジェクト指向プログラミングパラダイムの両方をサポートしています。Scalaを作った目的はまさにそれでした。Haskellで見られるカリー化、メモ化、Partial application、type classesなどのほとんどの機能を持っています。このような機能はKotlinやJavaにはありません。

Javaとの相互運用性

KotlinはJavaで動くことを考えられて設計された言語

KotlinはJavaとの相互運用性があるように作られた言語です。さらに言えば、Javaとの相互運用性を高めるための機能も意図的に実装されています。たとえば、JavaからKotlinのコードを簡単に呼び出せる仕組みも備わっています。ですので、レガシーなアプリケーションはJavaで開発し、新規開発はKotlinでする、ということも可能です。

AndroidでKotlinがこれだけ人気があるのは、KotlinがJava 6(現在のAndroidJavaバージョン)と相互運用性があるからでしょう。

Javaとの相互運用性が高いのは偶然ではなく、そもそもJetBrains社がKotlinを設計するときに当時のJavaの状況を加味して設計していたからです。どうしたらKotlinをもっと使いやすくできるかを考えて設計されています。その結果が、バイトコードの構成という点にまとめられます。そして、この点が、CordaがScalaではなくKotlinを選んだ理由の1つになっています。

ScalaJavaで動かすことは可能

より簡単にデプロイできるように、ScalaJVMプラットフォームで動くように作られました。しかしながら、相互運用性は一番の目的ではありませんでした。これは、技術的な話になり、言語の機能に関わる話になりますが、例えば、Scalaを動かすためにはJava 8が必要です。

これを踏まえると、ScalaJavaを行ったり来たりしながらの開発は難しく、Scalaの想定されたユースケースではありません。すでにあるJavaのコードベースをScalaから使えるかといえば、それは使うことはできますが。

関数型プログラミングオブジェクト指向プログラミングをサポートするために、Scalaでは互換性も犠牲にされています。もし、Scalaの高度な機能を使おうとすると、Javaでは何もできなくなってしまいます。もしできたとしても、Javaプログラマーはどのようにそれを使っていいのかはわからないでしょう。

哲学の違い

成功を収めている言語の多くは、明確な目的と、その言語がどうあるべきかというはっきりとした哲学を持っています。もちろんのこと、KotlinとScalaも例外ではありません。Kotlinはより良いJavaになることを目指し、ScalaJavaを超えた言語を作ろうとしていました。

Kotlinはより良いJava

Kotlinはすでに当初の目的は果たしたと言えるかもしれません。なんと言っても、KotlinはJavaの他にAddroidの開発言語として正式にサポートされた最初の言語になったのですから。それはつまり、JavaコミュニティがKotlinを気に入ったということ、そして、KotlinはJava開発者にとって受け入れやすいということを意味します。

Kotlinは実用性の高い言語であり、Java開発者にとっても親しみやすく、生産性を高めることができる言語です。基本的には、Javaのような言語にしようとしていますが、その上にC#やさらにはScalaの機能を取り込んでいます。Java開発者が欲しがるようなラムダ式や基本的な関数型プログラミングの機能、そしてプログラミングを楽にしてくれるsmart castingやnon-nullable typeの機能を追加されています。これにより、いままで冗長に書いていたコードを簡潔に書くことができます。

Kotlinでは関数型プログラミングがある程度サポートされていますが、それは手続き型/命令型プログラミングをより簡単にするためだけのものしかサポートされていません(例えば、個々の関数は独立して第一級オブジェクトとして扱えます)。Kotlinはフォーマルな関数型言語になろうとしているのではなく、シンプルであることを優先しています。

ScalaJavaを超えようとしている言語

ScalaはKotlinとはまったく別の目的を持っています。Scalaの目的はJavaより強力な言語、Javaでできないことができる言語、を作ることでした。

Scalaでは、オブジェクト指向プログラミングに加えて、高度な関数型プログラミングもサポートされています。そのためにScalaは複雑になり、学んだり使ったりするのが難しいという評判がつくようになりました。もちろんこれは言語自体に問題があるのではなく、単純に、多くのことができる言語であるために多くのことを学ぶ必要があるのです。

もちろんこと、正しく使えばメリットは大きいですが、正しく使わなければメリットは出なくなります。Scalaでは複数のプログラミングスタイルが存在し、どのスタイルがベストなのかは混乱のもとにもなっています。これにより、開発コストは高くなり、Scala開発者の収入も高水準であり、あなたの立場が開発者なのかそれとも開発者を雇う企業なのかによって、これは良い点にも悪い点にもなります。

言語を囲む世界

コミュニティ

Scalaの方が大きいコミュニティを持っています。言語の良し悪しは別にして、Scalaの方が長く存在しているのですから、もしかしたらそれは当然のことなのかもしれません。唯一、これが当てはまらないのはAndroid開発でしょう。Kotlinの人気の高さは、2017 Google I/OでのKotlin発表の様子からも明らかでしょう。

Kotlinのネイティブライブラリーがあまり充実していないことは、Javaとの互換性を取ることによりいくらか軽減されているでしょう。しかし、堅牢なKotlinライブラリーはScalaJavaのようには十分開発はされていません。

ドキュメント、学習しやすさ

どちらの言語もドキュメントは充実しています(古かったScalaウェブサイトも今では最新にアップデートされています)。Scalaを使う際には、まず開発者をトレーニングして、Scalaに慣れさせてから自身の開発スタイルを学習させる必要があります。Java開発者に数日ほどのトレーニングを受けさせれば、Scalaが使えるようになると思ってはいけません。そもそもJava開発者は、関数型プログラミングが何かも知らないかもしれませんから。それほどScalaJavaとは違うのです。

Kotlinは学びやすい言語であり、また、さらに実際に動かしてみることはさらに簡単です。オンラインの実行環境もあり、そこにはサンプルもあり、さらにJavaコードをKotlinに変換することもできます。なので、JavaでやっていたことをKotlinでどのように実装したら良いかがすぐにわかります。

ツール

ScalaとKotlinはどちらも静的型付けであり、コンパイル時チェックと静的分析ツールを利用できます。理論上は、どちらも同じポテンシャルを持っていると言えるでしょう。しかし、現状、Kotlinの方がツールは充実しています。名の知れたプログラミングツール開発会社であるJetBrains社がKotlinの開発元であることを考えると、驚くことではないでしょうが。ドキュメントについてはScalaが劣っているというよりは、Kotlinのドキュメントが素晴らしすぎるといったところでしょう。

以前は、Scalaの公式ウェブサイトではEclipseをベースとしたIDEを提供していました。今では、IntelliJScalaブラグインを使うことが勧められています。

一方、KotlinはすでにIntelliJ IDEAとAndroid Studioに組み込まれており、Eclipseにもプラグインが用意されています。さらに、IntelliJ IDEAには前述の変換ツールとオンラインでアクセスできるサンプルがあり、Javaのクラスを簡単に変換してKotlinをインタラクティブに学習することができます。もちろん、スタンドアローンコンパイラーを使い、自身の開発方法に合わせてKotlinを使うこともできます。

まとめ

Kotlinは開発工程の全体を見据えて作られた言語を言えるでしょう。ある機能が必要かどうか、コンパイラーの速度にどのように影響を与えるか、ツールを作ることが難しくなるだろうか、など、各設計がどのように開発のエクスペリエンスにインパクトを与えるかを考えて作られています。

Scalaは実用性を第一として考えられておらず、それとは別の目的(Javaより強力な言語、Javaでできないことができる言語を作ること)を持っています。ScalaC++に似ていて、とても豊富な機能が詰め込まれています。しかし、これが全員にとって使いやすい言語かというと、そうとは言えないのではないかと筆者は思います。

Javaよりも良い言語を求める人たち、そして、Javaに満足しきれなかった人たちの2種類の人たちがScalaを使い始めました。前者のほとんどはScalaに満足していますが、後者はScalaの複雑さに困惑させられることになります。それは当然のことで、ScalaJavaからは別物なのですから。そのような人たちにはKotlinがより良いチョイスとなるでしょう。