アカウント名:
パスワード:
VBの次には証拠にもなくTypeScriptを作ってるようだが・型が自慢のくせに、整数と実数を区別しない。・"any"型が山盛りで、ただの回りくどいJavaScriptでしかない。・nullについて厳密なのはモダンだが、Save Navigation(foo?.bar?.hoge()みたいなの)が無い。・パターンマッチが無く、レガシーなswitch()のみ。・普通の関数とアロー演算子の関数で、"this"が指すものが変わりややこしい。・ろくなテンプレートライブラリが無い。reactやvueに頼らざるえない。で、別のAltJSである「Elm」に惨敗。
TypeScriptも消えていく運命か。MSは言語作るのむいてないんじゃない?
まず大前提として、TypeScriptの目標は「JavaScriptに型をつけた言語」、言い換えれば「TypeScriptのコードから型を取っ払うとJavaScriptになる言語」です。
> ・型が自慢のくせに、整数と実数を区別しない。JavaScriptは整数と実数を区別しない言語です。必然的に「number型」という区別しない型をつけるしかありません。
> ・"any"型が山盛りで、ただの回りくどいJavaScriptでしかない。anyは原則としてリターンされるオブジェクトの型が一定にならないものに対して使われている型です。また、型がしっかりしているものとanyがまぜこぜになるとanyになってしまうという特徴があ
>> ・型が自慢のくせに、整数と実数を区別しない。>JavaScriptは整数と実数を区別しない言語です。>必然的に「number型」という区別しない型をつけるしかありません。
えっ・・・
有れば便利だと私も思うし、演算を展開したり、代入時にチェックルーチン組み込めば可能なんだろうけど、コストパフォーマンスが悪るすぎだろうねぇ。
JavaScriptにトランスパイルする以上、JavaScriptの数値型から大きく離れるとロスが増えるのでは。
型の挙動を揃えるための処理を毎演算毎に行う必要があるのは当然として、その上で元の型での演算にJITされるのを期待するってーのは無責任だし、かと言って多数のJavaScript実行環境でうまくJITされるようメンテし続けるのもコストが半端ない。WebAssemblyとかなら対応してれば高性能だろうが対応環境が縛られてしまう。
数値型細分化は分が悪いととして避けるのは何ら不思議ではない。
実行時にjavascriptとして動く以上は「Numberではない数値型」は非プリミティブ型となってしまい、パフォーマンスはNumberよりかなり劣ると思われる。実数型より遅い整数型を使いたい需要はほとんどないだろう。
JITによって局所的に整数演算コードが吐かれるのを期待することは非効率だが不可能ではないし、asm.jsに対するV8エンジンも当初はそっち系だったとかなんとか。不可能ではないけど遅くなるリスクを十分打ち消すにはコストが見合わないだえいうねぇ……本気で速度欲しけりゃそっち系出力するしかないけど、互換性が大分低いし。出力の可読性も低い。
パフォーマンスがよくなるケースはあってもほかが酷くてメンテコストも高く、そのくせ需要が大きいわけでもない。そりゃ積まんわな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
MS系技術はどうなってるの (スコア:-1)
VBの次には証拠にもなくTypeScriptを作ってるようだが
・型が自慢のくせに、整数と実数を区別しない。
・"any"型が山盛りで、ただの回りくどいJavaScriptでしかない。
・nullについて厳密なのはモダンだが、Save Navigation(foo?.bar?.hoge()みたいなの)が無い。
・パターンマッチが無く、レガシーなswitch()のみ。
・普通の関数とアロー演算子の関数で、"this"が指すものが変わりややこしい。
・ろくなテンプレートライブラリが無い。reactやvueに頼らざるえない。
で、別のAltJSである「Elm」に惨敗。
TypeScriptも消えていく運命か。
MSは言語作るのむいてないんじゃない?
Re: (スコア:1)
まず大前提として、TypeScriptの目標は「JavaScriptに型をつけた言語」、言い換えれば「TypeScriptのコードから型を取っ払うとJavaScriptになる言語」です。
> ・型が自慢のくせに、整数と実数を区別しない。
JavaScriptは整数と実数を区別しない言語です。
必然的に「number型」という区別しない型をつけるしかありません。
> ・"any"型が山盛りで、ただの回りくどいJavaScriptでしかない。
anyは原則としてリターンされるオブジェクトの型が一定にならないものに対して使われている型です。
また、型がしっかりしているものとanyがまぜこぜになるとanyになってしまうという特徴があ
Re:MS系技術はどうなってるの (スコア:0)
>> ・型が自慢のくせに、整数と実数を区別しない。
>JavaScriptは整数と実数を区別しない言語です。
>必然的に「number型」という区別しない型をつけるしかありません。
えっ・・・
Re: (スコア:0)
有れば便利だと私も思うし、演算を展開したり、代入時にチェックルーチン組み込めば可能なんだろうけど、コストパフォーマンスが悪るすぎだろうねぇ。
Re: (スコア:0)
JavaScriptにトランスパイルする以上、
JavaScriptの数値型から大きく離れるとロスが増えるのでは。
型の挙動を揃えるための処理を毎演算毎に行う必要があるのは当然として、
その上で元の型での演算にJITされるのを期待するってーのは無責任だし、
かと言って多数のJavaScript実行環境でうまくJITされるようメンテし続けるのもコストが半端ない。
WebAssemblyとかなら対応してれば高性能だろうが対応環境が縛られてしまう。
数値型細分化は分が悪いととして避けるのは何ら不思議ではない。
Re:MS系技術はどうなってるの (スコア:1)
実行時にjavascriptとして動く以上は「Numberではない数値型」は非プリミティブ型となってしまい、パフォーマンスはNumberよりかなり劣ると思われる。
実数型より遅い整数型を使いたい需要はほとんどないだろう。
うじゃうじゃ
Re: (スコア:0)
JITによって局所的に整数演算コードが吐かれるのを期待することは非効率だが不可能ではないし、
asm.jsに対するV8エンジンも当初はそっち系だったとかなんとか。
不可能ではないけど遅くなるリスクを十分打ち消すにはコストが見合わないだえいうねぇ……
本気で速度欲しけりゃそっち系出力するしかないけど、互換性が大分低いし。出力の可読性も低い。
パフォーマンスがよくなるケースはあってもほかが酷くてメンテコストも高く、
そのくせ需要が大きいわけでもない。そりゃ積まんわな。