ES4の失敗 と TypeScript
※ この文章は、ベータ版です。
JavaScript(ECMA Script)には、静的型付?言語化しようとして
失敗した歴史があります。
その失敗を教訓として活かして、TypeScript が作られたのだと思います。
ES(ECMA Script)4の失敗
ESベースのActionScript3(Flashの開発言語)の仕様をベースに、
静的型付?・クラス・ジェネリックスetcを導入しようと策定されて
いたものの、仕様の機能の取捨選択のコンセンサスが取れず、仕様が
まとまらず、ES4.xは欠番になりました。
ActionScript3自体は、擬似的に静的型付のできる動的型付言語に
みえます。(今でも、言語仕様?やサンプル・プログラムなどはネット
上に転がっています。)
静的型付論者がいて、静的型付の発想から出た機能を提案、実装可能かの
判断のないまま、それらが仕様に盛り込まれた結果、擬似的(な)静的型付の
はずが、静的型付でないと実現できない機能がてんこ盛りになってしまい、
動的型付でも静的型付でも書けるようにみえる、完全に実装無視な
Overview (概要)になっていった感じがします。。。
ジェネリックス:
静的型付でないと無理。
(型チェックのみに利用なら、疑似的(な)静的型付でも可能かも。)
関数(メソッド)のオーバーロード:
静的型付でないと無理。疑似オーバーロードは可能
今までに、動的型付でも静的型付でもある言語は(机上以外で)
登場したことはないです。
Overview(概要)の機能の多くは静的型付でないと実現できない
機能で、ES4自体が動的型付→静的型付しないと成立しない仕様に
みえます。
動的型付のままで行くか、静的型付に移行するか、で、互換性を
維持できない静的型付への移行は、過去のコードを引き継げない
ため、根強い反対にあい、ES4自体、静的型付前提の機能がメイン
であったため、頓挫したように思えます。
後に、静的型付・ジェネリックス以外のES4で予定されていた機能の
うち、クラスetcを盛り込んだES2015(6)が策定、勧告されています。
ECMAScriptの仕様策定は互換性重視です。
(ES6で導入されたclassもシンタックス・シュガー。)
ES4は、型付を強制しない形での緩やかな(動的型付を維持したままのオプション的)
型付導入(見た目は静的型付、中味は動的型付、型アノテーション)なら策定に成功した
かもしれないけど、動的型付→静的型付しようとして失敗した感じです。
「見た目は静的型付、中味は動的型付」な、疑似的(な)静的型付は、以前は
採用言語が(ほとんど?)なかったので、以前はESの標準仕様での採用は難しい
感じでしたけど、TypeScriptが成功してる今なら、ESの標準仕様での採用、
ありえるかもしれません。
疑似的(な)静的型付、では、付加された型は、型チェックのみに利用され、
実行時には無視されます。
動的型付言語のまま、擬似的に静的型付のできる言語はいくつか、あります。
型アノテーションを導入したPython、タイプヒントを導入したPHP。
TypeScript
ES6のスーパーセットになっています。
トランス(コン)パイラで JavaScript(JS) に変換してから実行する
「記述は(オプショナルな)静的型付、実行は動的型付」な言語
です。
疑似的(な)静的型付、といえると思います。
型アノテーションによる型付を強制しない形での緩やかな型付
になっているのが奏功している気がします。
付加された型はトランス(コン)パイラでのコンパイル時の型チェック
のみに利用されています。
(JavaScriptへの変換時に型情報は失われます。コンパイラの
オプションでd.ts(型定義ファイル)を作成して型情報を残して
おくことはできます。)
(TypeScriptのジェネリクスは型チェックのみに利用されています?
コンパイラでJSとして妥当な形に変換されているのかも。)
TypeScriptのES仕様の拡張は、ES4とは違い、JSに変換することを
前提に、動的型付言語であるJSの枠組みを保てる形で拡張されています。
(ES4の失敗の轍は踏まないようにしているようにみえます。)
JavaScriptの動的型付ワールド(互換性)を保ったまま、開発時には
型付できる、のが、TypeScriptの成功の大きな要因だと思います。