TypeScript の短所のまとめ

tsugehara toyokazu @tsugehara

@tail_y 普通に大規模開発向きかと思ってたんですが、なんででしたっけ。コンパイル速度が遅いのとモジュール機構がいまいちだからですか？

尾野（しっぽ） @tail_y

@tsugehara 何を大規模と言うかによりますけど「誰が参加するかわからない」「運用が長期に渡る」といった基準で言うと、スコープの巻き上げ挙動、readOnlyが無い、importが無い、enumの不完全さ、コンパイル速度あたりが深刻になってくると思います。

尾野（しっぽ） @tail_y

@tsugehara ああ、あともう１個忘れてました。Haxeは型推論に失敗するとエラーを出すのですが、TypeScriptは型をanyにして、これをスルーします。これも特に大規模開発では事故のもとで、非常によろしくない挙動だと思います。

尾野（しっぽ） @tail_y

@tsugehara どうしても140字だと説明しきれませんが、もっと抽象的なことを言ってしまうとTypeScriptは、今JSが使われている現場（Webページの構築など）で活躍出来るようにする、という思想があるように思え、中規模程度にフォーカスして作っているのではと思います。

尾野（しっぽ） @tail_y

ちょっと聞かれたので、TypeScriptの残念なところをまとめておこう。ちなみに僕はメインでTSを使っているわけではなく、またTS自体バージョンがこれから上がるので改善されるかもしれないポイントも多い。あとゲーム等を作ること想定で言うので、TSには不利な舞台という前提で。

尾野（しっぽ） @tail_y

【TS残念ポイント】コンパイルが遅い。大規模開発では問題になってしまうし、もともと非コンパイルだったJSの代用としても残念な感じ。

尾野（しっぽ） @tail_y

【TS残念ポイント】enumが残念。とはいえ、通常のenumの役割は果たしているので、どっちかっていうと横に並んでいるHaxeのenumがすごすぎて残念に見えてる感じはある

尾野（しっぽ） @tail_y

【TS残念ポイント】関数のオーバーロードが「出来る」。一見いいようだけど、基本的にオーバーロードはバグのもとになりやすい機能で、HaxeやAS3では避けられている。また、判定は自分で書かないといけないのに、typeofの挙動の変さと相まって超残念なことになっている。

Yukiya Okuda / THE GUILD / alumican @alumican_net

判定は自分で書かないといけないオーバーロードってただのJSじゃね？

尾野（しっぽ） @tail_y

@alumican_net 外部から見るとオーバーロードに見えるとかなんとかだったような。

尾野（しっぽ） @tail_y

【TS残念ポイント】型推論が貧弱な上、失敗してもちゃんと失敗したって言ってくれない。黙って型をany（Flashで言うところの*）にする。

池田 泰延 @clockmaker

おや、@tail_y さんが TypeScript を dis ってる!? ちょっと様子見でｗ

尾野（しっぽ） @tail_y

【TS残念ポイント】{}がスコープを作らない。つまり、forで使っているiは、for外の影響を受けるし、２箇所のforはiの２重宣言となる。また、スコープ巻き上げの挙動はJSのあれとほぼ一緒。

尾野（しっぽ） @tail_y

【TS残念ポイント】JSコードと一対一で対応しているので（これは便利なポイントでもあるのだけども）、最適化やインラインは非常に貧弱。最適化特化のJSXに比較しては当然の事、Haxeでもやることを、やってくれないことが多い。

尾野（しっぽ） @tail_y

【TS残念ポイント】importが無い。記述が面倒になるというよりは、これによって、プログラマがパッケージ（モジュール）を切らなくなり、どんどんトップレベルに置き始めるようになるのが問題だと思う。

わかめ@毎日猫がいる @vvakame

@tail_y http://t.co/T8GKJguJmu 一部気になったことがあったのでコードを書いてみました。あと、"Haxeは型推論に失敗するとエラーを出すのですが、TypeScriptは型をanyにして、これをスルーします。" について、サンプルコードとか欲しいです。

尾野（しっぽ） @tail_y

@vvakame あれ、importあったんですか。型について、適当な位置になっちゃいますけど追加しました。30行目からです。 http://t.co/RH8pzc6ZH5

尾野（しっぽ） @tail_y

【TS残念ポイント】について修正。importあるそうです。

わかめ@毎日猫がいる @vvakame

@tail_y あーなるほど、var hoge; と 初期化が同じタイミングじゃないと型推論されなくてanyになる、ということですね。わかりましたありがとうございます。確かにエラーにしてくれたほうが安心できますね。

尾野（しっぽ） @tail_y

【TS残念ポイント】public functionを外部から書き換え可能。

尾野（しっぽ） @tail_y

@vvakame これ、推論失敗してるんじゃなくて、anyを指定したことになっている、って認識のほうが正しいんですかね？他の型推論言語って、こういうのをstringにしてくれるのを型推論って言うような気がするのですが・・・。

尾野（しっぽ） @tail_y

あれ、でもimport の挙動なんか違うような気がしないでもない・・・・。どっちかっていうとtypedefみたいな動きなのか。まあ*指定はどうせimport で使うべきではないので、無くてもいいけど。

わかめ@毎日猫がいる @vvakame

@tail_y 言われてみればそっちのほうが適切な気がしますね…。構文木をあんまり舐め回さなくてすぐさま確定できなければanyだ！的な実装なんでしょうね。コンパイラこれ以上重くなっても困るですけど…。

尾野（しっぽ） @tail_y

@vvakame 重くなっても困るので、型推論を強化する方向が無理だとしても、確定できなければ「anyだ！」より「なんですか？」って出てくるほうがいいですよね。バージョンアップでそうなってくれることを祈る感じですが、今あるコードが大量に死ぬから入れない可能性も…。

わかめ@毎日猫がいる @vvakame

@tail_y めっちゃ同意です。1.0までだったらどんな暴挙にでてもさほど怒られないと思うので頑張っていただきたいです…。