プログラミング言語Dartの「方向性」はやっぱり正しい

遅ればせながら(?)、Dartについて考えてみました。そしてソフトウェア開発のこれからを考えた場合、Dartの「方向性」はやっぱり正しいという結論になりました。

Googleは、もう少しちゃんとDartの意義を伝えた方がいいと思います。ほとんどの技術者に「同じような言語がまた一つ増えた」ぐらいにしか認知されていないのではないでしょうか。だから文法や機能不足など、表面的なところばかり批判されて、イマイチな印象になってしまっているように思えます。まだドラフトでバージョン0.04です。今の段階では機能不足や、さまつな仕様の欠点を論じるのではなく、言語のビジョンに注目するほうが正しく評価ができると思います。

なぜDartの方向性が正しいのか、まずその前提から書いていきます。

プログラミングの分野

プログラミング言語は、分野により向き不向きがあります。それをごちゃ混ぜにして議論しても仕方がありません。ここでは便宜上ソフトウェアを「基盤系・学術系」「組み込み系」「一般アプリケーション」と３つに分類します。あくまで説明を分かりやすくするための分類なので厳密ではありません。

基盤系・学術系など

• OS
• 言語処理系
• ファームウェア
• ミドルウェア
• 高度ライブラリ
• 科学技術計算
• 人工知能
• データマイニング
• 他、高度なアルゴリズムを必要とするソフトウェア

組み込み系

• 家電
• 医療用機器
• 産業用機器
• 専用ゲーム機
  など

一般アプリケーション

• 個人向けアプリケーション、ゲーム
• 法人向け、教育機関向け、官公庁向け、組織内アプリケーション
  など

多くの割合を占める「一般アプリケーション」

「基盤系・学術系」は重要ですが、ソフトウェア全体の開発ボリュームで考えると小さいですし、従事している団体や個人も限定的です。高度な知識を持った人にしか開発はむずかしい分野だと思います。
「組み込み系」はそれなりに従事しているプログラマの人口は多そうですが、ハードごとに事情が違い特殊なため、ここでは言及しません。
そしてソフトウェア開発で一番大きな割合を占めるのが「一般アプリケーション」です。多くの職業プログラマが従事することになる分野です。
そして当面はDartはこの分野をターゲットにすることになると思います。

オブジェクト指向ベースの言語が「一般アプリケーション」にはなじむ

基盤系・学術系などのソフトウェアには関数型言語が有効な場合が多いかもしれません。開発する人が優秀で数学的思考のスキルが高い場合はなおさらだと思います。

でも一般アプリケーションは、ヒト・モノ・コトをモデリングしシステム化する場合が多く、特にビジネスロジックの部分はオブジェクト指向ベースで考える方がしっくりくるのです。だって、実社会はオブジェクトとその連携で成り立っているんだもの。ビジネスロジックのソースコードは実社会の動きを表現したドキュメントですから、数学的な考えに置き換えて短く書くより、実社会をそのまま落としこむ方が自然で理解しやすくメリットが大きいのです。

もちろん関数型のアプローチが有効に使えるケースがあるでしょう。だからオブジェクト指向ベース言語で関数型も使えるハイブリッド言語が一般アプリケーション開発には現実的な解だと思います。
並列処理など複雑な処理の対処は基盤部分（フレームワーク）に集約し、ビジネスロジックは実社会をオブジェクトでシンプルに表現することが適切だと思います。フレームワークとビジネスロジックのプログラミングは頭の使い方が異なりレイヤーも違います。（この辺はまた後で整理しよう）

「文章」に例えてみます。どちらがよいというわけではなく、どちらが適切かは状況によりますね。

1. 短く簡潔だが、高度な学識がないと難しい文章
2. 多少冗長だが多くの人が読み書きしやすい素直な表現の文章

どちらが関数型言語で、どちらがオブジェクト指向言語・手続き型のメタファかは言うまでもありません。

私は関数型言語を深く理解しているわけではないので認識が間違っているかもしれません。でも概念では、大きく外してはいないと思います。

アプリケーション開発は覚えなきゃいけないことが多すぎ

現状はクライアントアプリはJavaScriptやObjective-C, Java, Flash(ActionScript)など、サーバ側はJava, Ruby, Python, Perl, PHPなどの組み合わせによる開発が一般的です。（Microsoft系は違うかもしれませんが全く書く気が・・・）。言語に加えHTMLやCSSなどもあります。それは多くの人にとって覚えなければならないことが多すぎて「アプリケーション開発は複雑で敷居が高い」と感じさせる原因になっています。いくつもの言語をマスターした人は「言語なんか覚えてしまえば簡単」と考えがちです。でも大半のプログラマにとって一つの言語を使いこなすようになることは大変なことなのです。ましてや、思想の違う言語ならなおさらです。
ソフトウェア開発をシンプルにするためには、クライアントとサーバの同一言語化はとても重要な要素なのです。

ソフトウェア開発のこれから

基盤系などは処理スピードが重要な場合も多いので、C,C++なども相変わらず使い続けられますし、Javaや関数型のプログラム言語や、もしかしたらGo言語なども使われるようになるかもしれません。

そしてあらゆるアプリケーション系は、これから「クラウド＋HTML5（もしくは、その後継）」に集約していくと思います。この大きな流れは着実に進んでいくでしょう。
クラウドに関しては自前サーバを捨ててクラウドへ向かえ！PaaSとSaaSでオールOKだよね？でも書きましたので、そちらも合わせて読んでください。
そう、これからはHTML5とクラウドに最適化した言語である必要があります。

スマートフォンアプリもHTML５へ

iOSやAndroidが全盛ですが、それすらもHTML5に置き換わっていく可能性が高いと思います。
Googleの最終目標はAndroidではなくChromeOSであることは有名な話ですが、AppleもHTML5のことは認めていたと思います。

カメラやGPSなどのデバイス制御の仕様もHTML5に追加されています。処理速度も向上していますし、オフライン用のクライアントアプリも作れます。ネイティブアプリでなくてもHTML5だけで実現できることは多いのです。

それにHTML5で作ればiOSであれ、AndroidであれWindows PhoneであれPCであれ、同じプログラムを利用でき、同じタイミングでリリースできます。工数が少くなれば安いコストで、早くサービスを作れます。そのエネルギーを付加価値や品質に注ぐことができれば、よりよいアプリにできるでしょう。開発者にとってもユーザにとってもメリットは大きいのです。

AmazonがKindleアプリをHTML5で作ったことも、その流れのさきがけです。もちろんAppleの制限から逃れるための苦肉の策ということはありますが、新たな道を開くきっかけになったことは確かです。

iCloud.comはWeb OSへ進化する。そしてアプリもHTML5へ

iOS5からiCloudが利用できるようになりました。そしてiCloudはWebでも管理できるようになっています。このiCloud.comはもう見た感じiOSそっくりではないですか？ これは将来"iCloudOS"などとよばれるものに発展していくように思えてなりません。そして未来のiPhoneやiPadのOSはiOSでなくChromeOSのようなWebOSになっていても何の不思議もありません。もしかしたらジョブスの残した置き土産の中に最終形としてあるんではないかと想像したりもしてみました。もしそうなればiCloudOSのアプリはHTML5で作れるようになっているでしょう。

Webアプリケーションのこれからの形

Webアプリケーションも、これからはサーバ側でHTMLを生成するタイプは減っていきます。もう既にクライアントアプリとサーバが連携する形式が普及しつつあります。コンテンツ(記事)を生成したり、検索エンジン向けのWebページを生成するアプリなどについての必要性は残ると思いますが、このへんは他にもいろいろあるので別エントリーで書くつもりです。

クラウド＋HTML5時代のWebプログラマは、クライアントアプリとサーバのバランスを考えながら実装できなければなりません。だからクライアントとサーバが同一言語の方が何かと効率的なのです。

「キー言語」としてのJavaScript

サーバ側はデファクトスタンダードな言語は存在せず、言語を選択しなければなりません。でもクライアントがHTML5になれば、クライアント側は必然的にJavaScriptになります。サーバ側の言語の置き換えは可能ですが、クライアントのJavaScriptを他の言語に置き換えることは難しいでしょう。アプリケーションを作るにはJavaScriptが必須となり、JavaScriptは鍵を握る「キー言語」と言うことができるかもしれません。そして代替の言語が主なプラットフォームに普及するまで、この時代は当分続くでしょう。

HTML5アプリをネイティブアプリに匹敵させるコンパイル型言語

速度向上中のJavaScriptですが、どうしてもネイティブアプリと比較すれば多少のモッサリ感は否めません。今後もどんどん改善されていくでしょうが、できればネイティブアプリと同じようにコンパイルして、速度的に全く劣らない仕組みがあれば完璧です。GoogleはまずChromeにDart専用ランタイムを乗せることによって、ネイティブアプリに全く遜色の無いアプリを先行して実現しようとしています。これは将来的に訪れる全WebOS化に向けての布石です。でもChrome以外のブラウザがDartを実装してくれるかはわかりません。だからJavaScriptにもコンパイルできる必要があるのです。

クライアントとサーバを同一言語にするメリットは想像以上に大きい

言語マニアでもない限り「サーバとクライアントが同じ言語だったらいいなぁー」と一度は考えたことがあるのではないでしょうか？その感覚は素直で正しいです。複数の言語だと、文法で混乱したり、しばらく使わないで忘れることも出てくるでしょう。学習コストや調査する時間もバカになりません。そういう思考中断の積み重ねが、プログラミングへの集中力を欠いて生産性にも大きく影響します。一つの言語に集中する方が生産性はあがりますし、ノウハウも蓄積しやすいのです。サーバとクライアントで同じクラスやチェックロジックを共有できれば、かなりDRYですっきりします。それにクライアントとサーバが同じ言語であることを利用した新しい効率的な開発手法が出てくる可能性も高いと思います。

これからプログラミングに入門する人にとっては、なおさらサーバとクライアントが同じ言語の方がとっつきやすいでしょう。できるだけ敷居は低くしたほうが、プログラミングの参入障壁が低くなり、アプリケーションのアイデアや付加価値を生み出すことへと比重が移ることになります。たくさん言語を覚えることがプログラマの目的ではないはずです。

サーバとクライアントで同じ言語を使うには

現状だとサーバとクライアントで同じ言語を利用するには以下のような方法があります。

1. GWTの利用
   サーバ側はJavaでGWTを使い、JavaからクライアントのJavaScriptを生成する
2. フルJavaScript
   サーバ側にもJavaScriptで実装されたnode.jsなどを使う
3. CoffeeScriptなど
   JavaScriptにコンパイルできるCoffeeScriptなどを利用する

個人的にはどれもすっきりする解決策でなく、中途半端に思えます。

1. GWTはサーバサイドJavaが前提でJavaアプリの複雑さが残る

GWTはサーバサイドJavaが前提条件で、クライアントサイドのみのアプリは想定していません。それにJavaアプリケーション独特の取っ付きづらさ、扱いづらさ、複雑さがあります。私はJavaの経歴が一番長いですが、Ruby(Rails)に触れてからは、そういう複雑さにとても違和感を覚えるようになってしまいました。

2. JavaScriptは自由すぎ、エンタープライズでの利用は難しい

サーバもクライアントもJavaScriptを使うことは現時点では現実的な選択肢だと思います。しかしJavaScriptは書き方が自由すぎてトリッキーなことがやりやすく、複数人での開発にはあまり向いていません。コールバックの多用でソースが追いづらくなったり。それにJavaScriptはクラスがなく実装者任せの擬似クラスになってしまいます。

これらのJavaScriptの欠点は少なくともエンタープライズといわれる領域で使うためには、かなりのマイナス要素に思えます。

3. CoffeeScriptはいい線いってるが

Node.js＋CoffeeScriptを使えば、クライアントでもサーバでもCoffeeScriptでプログラムすることができます。JavaScriptに比べ、シンプルでclassも利用できるのでいいと思います。でも出力されるJavaScriptを意識しながらつくらなければならず、実行時にはやはりJavaScriptの知識が必要になります。jQueryなどが利用できることも、場合によってはデメリットにもなると思います。知らない人は結局jQueryも覚えなければならなくなるからです。jQueryなどのライブラリはjavascriptとはいえ、ほとんど別文法の「お作法」を覚えなければなりません。また別のJavaScriptライブラリを利用すれば、それも覚える必要が出てきます。結局JavaScriptの技術を取り入れやすい柔軟性が逆に敷居を高くする原因になってしまいます。その点がシンプルではありません。

文法は好みの問題。それなら人口の多いプログラミング言語ライクに

文法は見慣れてくるとなじむので、致命的な欠陥がなければなければ、書き方はあまり大きな問題ではありません。もちろんシンプルでないものは大きなマイナスポイントです。私はRubyのend構文を最初見た時は「なんだこれ」と思いましたが、慣れてくると良く思えてきました。文法は個人の好みなので、細かいところにこだわってもしょうがないと思います。

ちなみに私はC,C++を経てずっとJavaがメインでしたが、その後Rubyをしばらくやってました。今はサーバ側はJavaやRuby, Google App EngineではPythonを必要に応じて使い分けています。クライアント(ブラウザ)側はFlash(ActionScript)を経て今はJavaScript一択です。ちなみに言語的にはやっぱりRubyが一番好きですね。

TIOBE人気プログラミング言語ランキングを見ると、Dartに文法的に近いJavaやC系, Javascriptが大きな割合を占めていることが分かります。それはDartが多くの人にとってなじみのある書き方ということになります。言語の学びやすさという点では、全く新しい記法やマイナーな記法よりは、大きなアドバンテージになります。 多くのプログラマは積極的に新しい書き方を覚えたいわけではありません。その言語が感覚的にわかりやすいかどうか、とっつきやすいかどうかがアーリーマジョリティに受け入れられるためにはとても重要な要素なのです。そして頭のよい人達に絶賛されたとしても、アーリーマジョリティに受け入れられなければ普及することはありません。

TIOBE Programming Community Index

エンタープライズの領域を狙うGoogle

Googleはコンシューマだけでなくビジネス（エンタープライズ）の領域を狙っています。今はSIerが担っている部分です。IT業界ではエンドユーザ向けのサービスを提供している会社が花形で目立っていますが、実際はビジネス取引の大半は地味なBtoB(会社と会社の取引）で成り立っています。そのパイを狙うのは当然のことです。大人数での開発は、自分が作るだけでなく、プログラムを他人に引き継いだときにメンテナンスしやすいかどうかも大切です。平均的な人にとっても敷居が高すぎず理解しやすいことが重要になってきます。

Web系やエンタープライズ系の両方で利用できる言語

Web・スマートフォン系アプリとビジネス（エンタープライズ）系のアプリの両方で使いやすい言語であれば、普及しやすくなります。人材のスキルも有効活用できます。そのためには小規模でも大規模でも対応できる言語仕様でなければなりません。大規模開発では型指定など、ある程度の「硬さ」が有効に働きます。型指定があれば、仕様も明確に伝えることができますし、コード補完も正確にできるのです。型の概念があればScalaのような「型推論」もできると思います。まだDartに「型推論」はないようですが、いずれ出来るのではないでしょうか？ 逆に小規模開発では型指定よりLLライクに柔軟に書きたい場合が多いかもしれません。ようするに全部のアプリケーションに対応するには、ある程度の硬さと柔軟さを併せ持っていなければならないのです。

いろいろ考えると新しい言語を作った方が手っ取り早い

それでは、何でわざわざ新しい言語にしなければならなかったのでしょうか？
今まで書いたことを元に条件を書き出してみます。

1. エンタープライズ分野のアーリーマジョリティにも受け入れられやすい文法
2. オブジェクト指向ベースで、関数型とのハイブリッド型
3. 大規模でも小規模でも使えるように静的型付けなどの適度な固さ、柔軟さを合わせ持つ
4. “キー言語”JavaScriptの機能を包括していて、JavaScriptに効率よくコンパイルできる
5. 専用ランタイム用にもコンパイルでき動作速度をネイティブと同等にできる
6. そして必須条件「シンプルで簡単である」

これらの条件を満たす言語は何かと考えたときにジャストフィットする言語がなく、新しい言語を作る方が早いと考えたのでしょう。現状を考えた場合、ゼロから作り直すというアプローチは正解に思えます。

そして他にも２つの大きな目的があると思います。

真の目的はGoogleのプラットフォームへの誘導と、開発者を思う気持ち

大きな目的の１つは、やはりGoogleのプラットフォーム(Chrome, ChromeOSやApp Engine)にDartをネイティブ実装し、「他の環境でJavaScriptとして動かすより、こっちが早いよー」と言って誘導することです。もちろんDartはオープンソースで他のプラットフォームでも取り入れれてかまわないというスタンスでしょう。ほとんどのプラットフォームに組込んでもらえれば、JavaScriptの完全置き換えも夢ではありません。どっちにしてもGoogleには有利に働くでしょうから。

でもそんな野望だけでなく、「Dartはアプリケーション開発を効率化し、開発者を楽にするポテンシャルがある」というGoogle技術者達の熱い想いがあってリリースされたのだと信じています。

総合力で新しい言語を普及させる可能性が一番高いのはGoogle

影響力の強いクラウド(PaaS)とブラウザの両方のプラットフォームを持っている組織は、やはりGoogleです。ChromeとAppEngineのコラボは強力です。App EngineでもDartはいずれネイティブにサポートされると思います。新しい言語を普及させる力があるのは、強力なプラットフォームを握っているGoogleがやはり本命です。

Dartが普及するかどうかはGoogleのマーケティング次第

もちろん方向性が正しいからって普及するかどうかはわかりません。Googleのマーケティング次第だと思います。Googleの数々のプロジェクト失敗は一般人の気持ちが分からないことが大きいと思います。高尚な思想はうまく伝えないと一般人は理解できません。もっと噛み砕いてキャッチーにシンプルに伝えないとまた失敗するかもしれません。

私はセンスがありませんが、思いつくコピーをあげてみます。センスのある人いいのを考えてください。

クライアントとサーバのプログラミング公用語 “Dart”
エンタープライズもウェブ開発も、もっと手軽にシンプルに。

コピーではありませんが、Railsが「15分で作るブログシステム」とか「１０分で作るRailsアプリ」などが普及のきっかけになったようにアーリーマジョリティに普及させるためには、そういうシンプルなメッセージがないと難しいと思います。

Dartはまだまだこれから

他の言語と比べるとまだ機能不足な点はまだあると思います。でもまだドラフトでバージョン0.04ですよ。「型推論」などの有用な機能はこれから徐々に実装されていくでしょう。

良いものでも、みんなが「様子見」を続けたら普及しません。良いものは少しでも普及するようにブログを書いてみました。非力でもやらないよりはマシです。Dartがいいと思った人は今後注目して、少しでも広まるアクションをしていきましょう。