読者です 読者をやめる 読者になる 読者になる

M12i.

学術書・マンガ・アニメ・映画の消費活動とプログラミングについて

今のところTypeScriptの使用は時期尚早

JavaScript book TypeScript

このシリーズのRuby本がなかなか内容も濃く好印象だったので、TypeScriptについて気になりだしたときに本書を購入しました。そしてここまでちまちまと読み進めながら思ったのは以下のようなことです:

すくなくともCoffeeScriptよりはよい
わざわざ新しい構文を覚え、コンパイルの手間を惜しまず、実行時エラーの際のデバッグの労を厭わす、手を出すというのですから、よほど目新しいものが好きな人でない限り、動的型付け言語を選択する理由はないでしょう。
Scala.jsより導入の現実性はある
学習コストの点でもファイルサイズの点でもScala.jsの導入に厳しいところがあるのは明らかです。この際PHPPerlしか経験したことのない人びとについては考慮の埒外とするとしても、Java(やC#)+JavaScriptの組わせを地盤とする開発者たちを想定したとき、Scala.jsはTypeScriptに比べてやや敷居が高いように思われます。一方JavaScriptのスーパーセット/互換性重視というTypeScriptの特徴は、学習をしやすくするだけでなく、コンパイルの結果生成されるコード量にも反映されています。何より生成されたJavaScriptは人間の目でもってTypeScriptと対応付けることが可能なレベルにシンプルです。
TypeScriptの静的型付け指向とその実現のための工夫はすごい
集団開発でなくてもちょっとした規模のコーディングをするのであれば動的型付けにはメリットはありません。以前別の機会でも述べたことですが、あらゆる変数と引数には文脈上想定されるデータ型が必ずあります。そしてそうであるならば、明示的に型指定するか自動推論させるのが当たり前なのであって、そうすることで開発者は余計なコードを書かずに済むのです*1。TypeScriptの型に関する仕様の説明を読んでいると、JavaScript互換の静的型付け言語を実現するため*2、同言語の開発陣がとにかく知恵をしぼっていることがわかります。それはもはや「涙ぐましい努力」というべきレベルです。
今のところTypeScriptの使用は時期尚早
種々のメリットにも関わらず、TypeScriptとMaven、TypeScriptとEclipse、あるいは三者を協調させるなど、今日標準的な開発ツールを利用しようとすると問題が起こります。TypeScriptは何しろMicrosoftが推進するプロジェクトなのでVisualStudioによる言語サポートは提供されていますが、Unix/Linuxの世界ではNode.js、npm、tsc、gruntなどをベースにして、MavenやTypEcsを組み合わせ*3、そこから発生するあれこれのエラーを切り抜けつつ作業しなくてはなりません*4。これでは通常の開発は困難です。


結論として「もうちょっと開発基盤がしっかりするまで待とう」ということです。そのような日が来ることを祈ります。

*1:Pythonも含め動的型付け言語における型検証やダックタイピングのためのおびただしい量のチェックコードは、静的型付け言語であればそもそも不要だったものです。この点Javaがバージョン1.5においてジェネリクスをイレイジャで実装することで、結果的に型推論を導入できない進化の袋小路に足を踏み入れてしまったというのも示唆的です。おかげさまでJavaではせいぜいのところダイヤモンド記法のような──型推論でもなんでもない──ただの略記法を導入するが関の山なのです。

*2:個人的にはこの「JavaScript互換」の部分はあえて死守すべきものか疑問に思っています。とくに構文の基本構造を守ることと、動的型付けの特徴を守ることは分離してあたるべきではないかと考えています。

*3:余談ですが筆者の環境──Mac OS X Yosemite(10.10.5)──ではTypEcsはMacPortsでインストールしたnpmを認識できませんでした。この問題はNode.js公式サイトからダウンロードした.pkgファイルでインストールし直したところ回避できました。

*4:もちろん仮にUnix/Linux向けのVisualStudioがリリースされたとしても絶対に利用しませんが。