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の成功の大きな要因だと思います。