TypeScript part3

**デフォルトの名無しさん** · 2018/04/26(木) 21:48:23.07

http://www.typescriptlang.org/

JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/

**デフォルトの名無しさん** · 2020/10/11(日) 13:52:30.76

>>595
言語の記述が簡潔。これが一番だな。
パソコンよりスマホ。FLASHよりYouTube。マニュアル車よりオートマ。
人間は楽な方にながれる生き物。

処理に時間のかかるものはライブラリになげてスクリプト言語で記述。
これがこれからの流れだと思う。生産性もあげていかないと。

**デフォルトの名無しさん** · 2020/10/11(日) 13:57:45.46

「ワシもCで苦労したんだから、お前ら若者も苦労せい」
↑
こんな考えの老害が生産性を著しく低下させてる

**デフォルトの名無しさん** · 2020/10/11(日) 14:21:59.35

>>596
綺麗なだけのコードを書くことは実は簡単なんだよ。ただしそれは通常遅い。
だから処理系がそもそも速いって事がコードの美しさを保つ上でも重要ではある。
実際、Pythonから書き換えを迫られる場合はほぼ全て処理速度の問題だろ。

だから、
> 多少トリッキーでも短くて副作用のないコードを書くTS使いに対して、Python界隈は助長で副作用も使う簡易なコードを書く。 (>>593)
これの遠因もそこにある。トリッキーだが短いコードってのは通常、実行速度が遅い。
だからこれを許容出来るのは、速い処理系があるからこそ。
Pythonの場合はそもそも書けない可能性もあるが、書けたとしても遅いから使えない可能性もある。

トリッキーとは言わないが典型的なのは正規表現だ。
今現在正規表現は速いとは言えない状況で、「バックトラックを理解して速い正規表現を書く」という本末転倒なことをやらかしてるだろ。
あれも本来は「糞速い正規表現ルーチン」と「一番分かりやすい正規表現」で済むことでしかない。
ただ、今は現実的にそれが出来ないわけでさ。
同様に、正規表現で書けば至極単純なのを、indexOfやforとかで自前で探索してたりするのもそのため。
処理系の速さがコードの簡潔さ/美しさを下支えするものではあるんだよ。

だからつまり、「単純簡潔で分かりやすいが遅いコード」を許容する為には速度が不可欠で、
Pythonも速度対策すればこの辺が使えるようになって現実的な利用価値が上がるんだけどね。
それ以前に速度なんて考えてないコードばかりだから全体的に糞遅いのかもしれんが。

ただそれ以前に、JSもPythonと比べて難しい言語ではない。
Python界隈の戦略的には「Pythonこそ最易言語」であり、それ以外の意見は認められないのだろうけど、
いわゆるLL言語はどれもこれも簡単だし、大差ない。
JSにおいては「非同期」が無駄に嵌りポイントになってるから、
これさえなくなれば難易度はPythonよりもむしろ簡単になる。（文法が超絶簡素だし）
(ただし、無くなることはないとも思うが。非同期宗教酷すぎ)

**デフォルトの名無しさん** · 2020/10/11(日) 14:40:59.26

>>596
>>598
ちなみにお前は何か勘違いしているようだが、俺はPythonを嫌っているわけでもないし、Cを強いているわけでもない。
そもそも俺はCに苦労もしてない。そう思えるのは、お前がCに苦労しているからだ。

既に言ったが、俺がJSを気に入ってるのは、「手抜きの割には速いから」だ。
速く動かす為にはこう書いた方がいい、と分かっていても、面倒なのが大半で、
どうでもいいところから完全に手が抜けるからいいのだ。
だから「JS」というよりは「JSの処理系の速さ」が好きなのであって、逆にJSが遅くてPythonが速ければ、俺はPythonを使っていただろう。
その程度の話でしかない。
それとは別に、JSも言語的にはかなり面白いので気に入ってはいるが。

なおC、あれは難しいのではなくて、理解するのにPCの物理的構造の理解が不可欠なだけだ。
実はそれを知っている奴は最初からつまずかない。
そして仕様はJSやPythonよりも単純な為、覚える範囲だけなら多分1週間もあれば例のK&Rは読めてしまう。
似ているのは物理で、ma=Fが全ての力学も、最初から理解して使いこなせる奴と、1年経っても全然理解出来ない奴と綺麗に別れたろ。
あれは理解力/思考力の問題だが、とにかく、「理解出来る奴は最初から苦労もせずに理解出来てしまう」というのはCと同じ。

君はCがとても難しくて、若者がPythonしか使えず、Pythonしか使えない自分が置き去りにされない世界を望んでいるのだろうけど、
それはない。
Cは他言語と比べたら「ドハマリする奴は絶対に抜け出せない」だけで、仕様としてはかなり簡単な言語だ。
そして計算機工学なら普通に授業してるし、実際、彼等は普通に使えていると思うよ。
ただ、データサイエンティストみたいな、計算機を使うことが主目的ではなく、単純に計算だけしたい奴等はまずはPythonからだろうさ。
そこもしばらくは変わらないとは思う。
Python使えば生産性が高いと思ってるのはお前が馬鹿なだけ。
生産性が高い奴は、その時々に応じて最適の手法を選択するだけ。
それがPythonならそうだろうし、どうせ速度が問題になると分かり切っているのなら最初からCもありだろうさ。

**デフォルトの名無しさん** · 2020/10/11(日) 14:50:27.97

このクソ冗長な駄文書く奴が簡潔なコード書けると思うかい？

**デフォルトの名無しさん** · 2020/10/11(日) 14:54:59.49

無理だなw

**デフォルトの名無しさん** · 2020/10/11(日) 15:00:02.75

要約するとPythonが憎いってことかｗ

**デフォルトの名無しさん** · 2020/10/11(日) 15:06:05.60

どうでもいいがいい加減スレチ

**デフォルトの名無しさん** · 2020/10/11(日) 15:45:06.69

>>601
ありえないよね

**デフォルトの名無しさん** · 2020/10/11(日) 15:57:00.97

長文書きたいなら別サービスいきゃいいのにｗ

**デフォルトの名無しさん** · 2020/10/11(日) 17:55:24.83

せっかく丁寧に説明したのに今の若者は長文が読めないとかキレ出すのに1票

**デフォルトの名無しさん** · 2020/10/11(日) 18:12:49.10

>>603
お前はCが出来る奴が憎くて憎くて仕方ないのは分かった。

ただ、何度も言ってるが、Cも大して難しくはない。
昔だったらプログラミングなんてしなかった馬鹿連中も最近はプログラミングするようになってきてるから、
大勢の比較的馬鹿から見たら同じ物が難しく見えるだけ。

当たり前だがCなんて昔から変わって無いし、（というか変わらな過ぎだが）
今はIDEのサポートもありネットでも情報を探せるから、昔よりは断然簡単に学べる。
同じ理系学科で比較すれば、脱落率は劇的に改善しているはずだよ。
そもそも昔は１人1台PCでもなく、家で予習/復習すら出来なかったわけでさ。
F12押せばIDEモドキがいきなり出てくる今とは全然違う。

**デフォルトの名無しさん** · 2020/10/11(日) 18:38:20.01

Cの仕様は確かに小さいよ、しかしだからといって小さいイコール簡単な世界じゃない。
メモリパズルしたりガチで役立つマクロ組んだりSIMDで最適化したり未定義動作と戦ったりしてみると良いよ

**デフォルトの名無しさん** · 2020/10/11(日) 18:47:48.52

いい加減にしろ。

**デフォルトの名無しさん** · 2020/10/11(日) 18:57:19.02

マロックできないやつがおりゅってマ？ｗｗ

**デフォルトの名無しさん** · 2020/10/11(日) 19:25:10.03

>>609
未定義動作以外はもちろんやってるぞ。

ただJSでもTypedArrayは導入されたし、メモリパズルや最適化はCだけの話でも無いけど。
むしろそれをやる気がなければ最高速は目指せない。
numjsとか使ってる奴はJS/TSでそれやってると思うよ。

あと、お前もそうだが、最近の若い奴は使いこなす＝全機能を使う、と勘違いしている。
Cのマクロなんて深入りしたら余計に生産性が落ちる。あれはぱっと見て分かる範囲で使うべき物。

プログラミング言語なんてアプリを作る道具であって、道具を使い倒すのが目的ではない。
分かる範囲で使い、希望の動作をするアプリが出来るのなら、それでいい。
全く使って無い機能があったとしても、関係ない。

**デフォルトの名無しさん** · 2020/10/11(日) 19:27:09.39

別にここTSスレなんだからmallocできん奴おってもええやろ。今は細分化の時代だし。

**デフォルトの名無しさん** · 2020/10/11(日) 20:54:24.48

>>609
613読んで気づいたが、別人であったか。

Cにはもうこりごりなら、それもいいと思うけどね。
一応Nodeからffi経由でCのDLLは呼べるらしい。
それなりにオーバーヘッドはあるらしいけども、普通に使ってる分にはほぼ誤差だと思われる。
JSの数値はdouble相当だし、一応32bitのビット演算もあるし、
環境自体がそこそこ速いから、事前準備はJS側でやっても大して問題ないだろう。
単発の演算でオーバーヘッドがでかいのは問題だから、そこを何とかできれば、
科学技術計算からPythonを駆逐できる可能性がある。
ただ、PythonのCのDLLコールも同様にそれなりに遅いらしいので、マーシャリングであればどうにもならないけどね。

**デフォルトの名無しさん** · 2020/10/11(日) 21:21:39.97

>>600
＞C、あれは難しいのではなくて、理解するのにPCの物理的構造の理解が不可欠なだけだ

PCの物理的構造とやらが理解できたところで void (*signal(int sig, void (*func)(int)))(int) なんて宣言を読めるようになるとはとても思えないんだが

**デフォルトの名無しさん** · 2020/10/11(日) 21:58:54.02

>>615
それは慣れだね。
ただ、俺もあの文法はかなり謎で、正直、仕様がよくないと思う。
それはカーニハンも文句言われてて、言い訳は多分ググッたらヒットする。
確か、曰く、この形式ならマクロにしても入れ子でも動く、らしいが、
俺が試した限りはGoみたいな分かりやすい形式でも普通に出来た。

ただ、それ以前に実は当時のCでは関数ポインタをそんなに使わなかった。
正確に言うと、sortとかでは必要とされていたが、単発で使う分には呪文扱いでよく、
勿論熟練者はそれでも使ってたのだろうけど、今ほどカジュアルには使われてなかった。
K&Rでも、「関数ポインタも出来るよ」とさらっと触れられている程度でしかない。

それがJavaで関数ポインタが存在しなかった理由だし、
C#でも最初は採用されなかった理由だ。(C#は確か2,.0から)
当時はOOPで全て行ける、継承すれば関数ポインタを直接扱う必要も無い、と思われていた。（のだと思う）

ただその後、おそらくJSのブレークにより、クロージャ/ラムダの有用性がプログラミング界隈で認識された。
勿論Lisperはそれ以前からずっと呟いていたのだろうが、今も昔もLisperなんて空気だ。
そしてあまりにも感化された連中がClosure言語をリリースする始末。

だから、今のC初心者がいきなり関数ポインタを使おうとしているのなら、
それは確かに昔のC初心者より難しいことをやってる。
ただそれは呪文扱いでいいと思うよ。
自分が望むアプリを作ることが目的であって、呪文使いになることが目的ではない。

まあ確かに、ここ20年でプログラミング回りもだいぶ変わったから、
C言語自体は確かに変わって無いけども、学ぶべきことが明らかに増えてるのは事実だ。
関数ポインタも、OOPも、クロージャも、並列も、昔の学生には必要なかったから。

**デフォルトの名無しさん** · 2020/10/11(日) 22:21:00.46

思ったよりは詳しいみたいだし、その長文書くエネルギーでTypeScriptもっと使い込んで？
批判するならその上で批判して。ここTSスレだから。
使うまでも無いとか技術者らしからぬ事言わないでね。

**デフォルトの名無しさん** · 2020/10/11(日) 22:30:53.12

長い、3行で

**デフォルトの名無しさん** · 2020/10/11(日) 22:42:52.59

>>617
TSについては、今のところ使う予定無いからね。
理由は既に言ったとおり、「スモークテストまでだけの為に記述が増えすぎ」だから。

ただTSは確かに立ち位置は悪くない。
型のおいしいところだけつまみ食いしよう、という意図が明確でいい。
そもそも使って無いから細かい粗も知らんし、批判しようも無い。
JSが糞な点は多々あるけど、それはTSでどうにかなるものでも無いし。

**デフォルトの名無しさん** · 2020/10/11(日) 23:10:58.87

>>616
>C#でも最初は採用されなかった理由だ。(C#は確か2,.0から)

Delegateは1.0からあるよ

**デフォルトの名無しさん** · 2020/10/12(月) 02:32:07.80

スレチは3行もいらん

**デフォルトの名無しさん** · 2020/10/12(月) 06:56:35.72

>>620
確認してみたがどうやらそのようだ。
なんだかんだでC#はマトモだな。

**デフォルトの名無しさん** · 2020/10/12(月) 08:01:12.80

実際のところ、皆さんtsを仕事で使ってたりするの？

**デフォルトの名無しさん** · 2020/10/12(月) 08:49:35.94

うん

**デフォルトの名無しさん** · 2020/10/12(月) 08:51:37.03

使ってるよ。
元々JS使いだから最初は型と戦ってばかりで時間かかって生産性下がって辛かったけど、慣れればむしろ早いし、リリースした後の安心感が段違い。
小規模開発でもこれだから規模が大きいとさらに影響は大きいだろうね

**デフォルトの名無しさん** · 2020/10/12(月) 08:55:55.53

フロントエンドエンジニアやってるけど、React + TypeScriptが鉄板過ぎる
これ以外でUI組む気になれん

**デフォルトの名無しさん** · 2020/10/12(月) 10:31:14.01

サーバーサイドでも使ってる人いるのかな
typescriptとサーバーサイドでググると
サーバーサイドでもtypescript 最高たぜ～みたいな記事出てくるけどほんまかいなと。

Java,や.NET使った上でそう判断してる現場もあるんだろうか。
いま.NETしか経験がないメンバーにtsを習得させるか、思い切ってBlazorに手を出しちゃうか悩み中。

**デフォルトの名無しさん** · 2020/10/12(月) 10:41:40.32

鯖サイドってOSコロコロ変わるイメージ無いんだけど、JVMにしろ.netにしろVMで動かす意味ってあるの？
GoとかRustで良いんじゃ無いかって思うんだが。

**デフォルトの名無しさん** · 2020/10/12(月) 10:56:21.63

>>627
.NET Core使っとけ

**デフォルトの名無しさん** · 2020/10/12(月) 11:29:41.17

Ruby on Rails では、Bootstrap, React だけど、
JavaScript(JS) に、Ruby の式を埋め込む、ERB を使って、JSへ変換する。
a.js.erb

<%= Rubyの式 %>

$( "body" ).append( "<%= j(render partial: 'example_partial') %>" );

こういう書き方で、TypeScript を使えるかな？

**デフォルトの名無しさん** · 2020/10/12(月) 11:39:26.90

>>628
むしろVM使ってるかどうかで言語を選択するケースのほうが稀

**デフォルトの名無しさん** · 2020/10/12(月) 11:47:16.30

>>627
TSに手を出すのとBlazorに手を出すのでは冒険度合いが違いすぎない？

**デフォルトの名無しさん** · 2020/10/12(月) 12:34:06.06

>>632
だよね…
こんなところで聞くことじゃないかもしれないんだけど、
サーバーサイドに記述されてるクラスって、フロントでも使えるの？
それともフロント側でもtypescriptで同じクラスを宣言しないといけない？
Blazorはクラスを共有できるくさくて…それはメリットとしてかなりでかいなあと。

**デフォルトの名無しさん** · 2020/10/12(月) 12:38:53.86

>>628
サーバーは言語何を使うとしても仮想化前提だろ。

**デフォルトの名無しさん** · 2020/10/12(月) 12:49:06.93

>>633
同じ言語だからクラス書いたファイルを両方から参照すれば良くない？
そういう意味でなくてサーバとクライアントでシームレスにインスタンスをやり取りしたいとかであればフレームワークが居るのでは？

**デフォルトの名無しさん** · 2020/10/12(月) 13:00:28.44

>>633
両方同じ言語なら共有ライブラリとしてそれぞれから参照すればいいけど
言語が違ってもOpenAPIみたいの使ってコード生成すればいいから
2度手打ちする必要はないかも

**633** · 2020/10/12(月) 13:15:11.55

ごめんごめん
サーバーサイドはasp.net coreです
OpenApiとやらを使えば、クラスの生成が楽ちんてことね…
しかし二度手間感はすごいあるな…
でもBlazorに手を出すリスクを考えるとまだマシか…

**デフォルトの名無しさん** · 2020/10/12(月) 13:38:59.49

Blazorも使ってるけど、まだ.NET5対応のツール周りが全然だめなんだよね…業務なら素直にTypeScriptでいいと思うよ

**デフォルトの名無しさん** · 2020/10/12(月) 15:15:45.91

over knight blazorくらいになってからが本番。

**デフォルトの名無しさん** · 2020/10/12(月) 15:31:28.54

>>631,634
だよね。
なのに何でJavaとC#何だろ？って思った。

**デフォルトの名無しさん** · 2020/10/12(月) 15:34:05.12

>>634
特に仮想化前提で遅くなるのに何で言語をネイティブコンパイラ言語にしないんだろ？と。
昔は実質C++しか無かったなら仕方ないとして、今なら選択肢はもっとあるのに・・・。

**デフォルトの名無しさん** · 2020/10/12(月) 15:46:11.22

Goのコードは高機能でファットなランタイムに依存している
ランタイムとアプリを分離できないだけで、実質VM言語みたいなものだ
一方、.NET Coreはアプリとランタイムを実行ファイルに全部ぶっこんで配布することも可能
従来のVM言語という線引きは曖昧になりつつある

**デフォルトの名無しさん** · 2020/10/12(月) 16:22:11.38

C#だとジェネリクス関連はJITに任せたほうが速かったりできるし、
.NET CoreはReady to Runでネイティブコンパイルされたコードを同梱することもできるぞ。

**デフォルトの名無しさん** · 2020/10/12(月) 18:07:07.48

あー・・・。
そう言えばC#はネイティブにもコンパイル出来るようになったんだっけ・・・。
C#については納得。

Javaはまあ、コード資産だろうし。

**デフォルトの名無しさん** · 2020/10/12(月) 18:13:15.12

JITについては正直半分くらいしか信じてないんだけど、あり得なくは無いなと思ってる。
Dや一部のC++みたいにコンパイル時実行での最適化とどっちが速いんだろうとか思う。

**デフォルトの名無しさん** · 2020/10/12(月) 18:27:26.57

>>643
ジェネリクスってコンパイル時に解決するものだと思ってた

**デフォルトの名無しさん** · 2020/10/12(月) 18:58:23.00

TypeScript part3

**デフォルトの名無しさん** · 2020/10/12(月) 20:08:52.47

>>645
コンパイル時の方が多少早いけど、cppのジェネリクスもといテンプレートは型の分関数を用意するって愚直な方法をとってるので、バイナリサイズがデカくなる。
型情報も使えないしね。
あと、分岐命令なんかはどっちのほうが頻度高いかとか見て、動的にプロファイル取りながら最適化しつつ実行してるので、JITの方がより良い形になる事もある。

>>646
コンパイル時に解決はしてるけど、ILレベルでは複数の関数が作られてる訳ではなかったはず。
もちろん実行時には、JITで型ごとに関数が生えることもある。

**デフォルトの名無しさん** · 2020/10/12(月) 20:18:21.71

>>648
そゆことね。なるほど

**デフォルトの名無しさん** · 2020/10/12(月) 21:17:35.13

モダンC++対マネージコード：パフォーマンス対生産性
https://www.infoq.com/jp/news/2012/04/native_vs_jit/

**デフォルトの名無しさん** · 2020/10/12(月) 22:34:15.13

>>625
型はトモダチ…！

**デフォルトの名無しさん** · 2020/10/12(月) 22:37:04.59

質問なのですがTypeScriptでC++みたいに関数引数をconstにするにはどうすれば
良いの？

**デフォルトの名無しさん** · 2020/10/12(月) 22:47:48.13

>>648
>あと、分岐命令なんかはどっちのほうが頻度高いかとか見て、動的にプロファイル取りながら最適化しつつ実行してるので、JITの方がより良い形になる事もある。
ﾃﾞﾏくね…？
プロファイル取る手間はタダじゃないし、

**デフォルトの名無しさん** · 2020/10/12(月) 23:49:02.74

>>652
eslint no-param-reassign

**デフォルトの名無しさん** · 2020/10/13(火) 00:53:50.25

Ruby では、1秒で100万回ループすると、

JIT されて、1秒で1,000万回ループされる

**デフォルトの名無しさん** · 2020/10/13(火) 06:14:03.47

>>651
型はトモダチ！(ﾟ∀ﾟ)

**デフォルトの名無しさん** · 2020/10/13(火) 07:33:03.58

>>653
どっかで読んだけどな。
というか、AOTの制限事項として、JITより効率が悪い可能性の一つとして挙げられてるよ。

**デフォルトの名無しさん** · 2020/10/13(火) 17:57:10.11

(´･ω･`) webpack v5 ……

**デフォルトの名無しさん** · 2020/10/13(火) 21:41:54.07

>>654
「Invalid option '--param-reassign'」って言われたつ∀`；)
ESLint: 6.5.1.

ていうかできたとして無差別にconnstというのもそれはそれでC++と違う希ガスorz

**デフォルトの名無しさん** · 2020/10/15(木) 17:16:37.21

webpack@5、めっちゃ破壊的やん…

**デフォルトの名無しさん** · 2020/10/15(木) 17:39:38.69

>>659
お前の目はフシアナか？
https://eslint.org/docs/rules/no-param-reassign

ていうか引数に再代入するガイジなんて必要ないから無差別にエラーで構わんやろ

**デフォルトの名無しさん** · 2020/10/31(土) 19:19:55.76

JavaScriptからTypeScriptへの書き換えｵﾜﾀ＼(^o^)／
JavaScrpit最初に知って一ヶ月で全部書いたから3000行ぐらいだろうと思っていたら
あとでちゃんと数えたら8790行やったorz
実作業4日かかった
ここで4日というのは4日×8Hではなくて4日×24Hの意m（ｒｙ

**デフォルトの名無しさん** · 2020/10/31(土) 19:27:20.93

乙
TypeScriptやってない頃に書いたコードってTypeScriptのこと意識してなくてオブジェクトの形を動的に変えたりしない？
自分がやったときはそのせいでだいぶ時間かかったわ

**デフォルトの名無しさん** · 2020/10/31(土) 19:31:22.31

prototype文で無理矢理classにしていたやつを
さらに基底クラス（にあたるﾌﾞﾂ）の所有でもって継承を表現していたやつの普通のclassと継承への書き換えが苦痛やった、
機械的とはいえ自動化できるほど単純には行かず苦痛やった、
手製イベントのインターフェースが実際何になるのかがぐちゃらけていたので3種類のインターフェースのORで
表現できるとﾜｶﾙまで試行錯誤を要した、
あとはだいたいうまいぐあいに逝けた
とわいえVSCodeの強力なインテリセンスとリアルタイムエラー報告（スクロールバーのところが赤くなるやつ）が無かったら
到底完遂不可能なところやった、、、
webpack使用

**デフォルトの名無しさん** · 2020/10/31(土) 19:34:13.19

おめでとう

**デフォルトの名無しさん** · 2020/10/31(土) 21:54:44.53

ウンコードなJSをTSに変えることで人は強くなるのだ
おまえはまた強くなった

**デフォルトの名無しさん** · 2020/11/01(日) 08:10:24.39

委譲から継承に切り替えたらそりゃ辛いっしょ。
乙～

**デフォルトの名無しさん** · 2020/11/02(月) 00:59:20.76

delegation over inheritance って言うしな

**デフォルトの名無しさん** · 2020/11/06(金) 22:00:05.98

GithubでもTsは定義箇所にジャンプできたりするんだな
強い

**デフォルトの名無しさん** · 2020/11/09(月) 19:43:09.64

今からTypeScriptやるならDenoでいーの？
あっギャグじゃないです真面目な質問

**デフォルトの名無しさん** · 2020/11/09(月) 21:13:08.03

作った本人はデノって発音してるように聞こえる

**デフォルトの名無しさん** · 2020/11/09(月) 21:43:52.92

Denoあんまり詳しくないけど、何やりたいかにもよると思う
Web開発をする分にはまだNodeなんじゃないかな
周辺のツールやライブラリが揃ってるので
CLIツールとかならDenoでいーんでの？

**デフォルトの名無しさん** · 2020/11/11(水) 11:00:58.08

>>669
jsx/tsx でもイケるようになったね

**デフォルトの名無しさん** · 2020/11/17(火) 22:53:14.47

https://ncjamieson.com/prefer-interfaces/
https://github.com/microsoft/TypeScript/wiki/Performance

以前 type 推しの人がいたけどやっぱり interface か…

**デフォルトの名無しさん** · 2020/11/20(金) 14:22:41.76

Announcing TypeScript 4.1
https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/

**デフォルトの名無しさん** · 2020/11/20(金) 21:01:29.75

どんどん複雑になるなぁ
ついていけまへんわ

**デフォルトの名無しさん** · 2020/11/20(金) 21:22:14.83

逆にバージョンアップでシンプルになっていく言語ってあるの？
互換を完全に切るような言語なら可能だろうけど

**デフォルトの名無しさん** · 2020/11/20(金) 21:41:42.91

>>677
Schemeが小さくはなったな
ま、大規模に使われてる言語じゃないから出来る芸当だ

**デフォルトの名無しさん** · 2020/11/20(金) 21:44:46.30

言語機能が増えたからと言って全部使う必要はないしな
たまにどこかで使われてるのを見てあれってなったら調べるくらいで良い

**デフォルトの名無しさん** · 2020/11/20(金) 21:50:47.55

JavaScriptは動的型だけど、動的型は意識しなくても複雑な事が出来てしまう
TypeScriptはそれらに対して何としてでも型を付けたいんだよ
それだけの事
JavaScript自体は何も変わってない

**デフォルトの名無しさん** · 2020/11/20(金) 23:06:21.09

もうaltJS風WebAssemblyコンパイラにして

**デフォルトの名無しさん** · 2020/11/20(金) 23:26:29.58

>>681
つ AssemblyScript

**デフォルトの名無しさん** · 2020/11/21(土) 01:50:51.61

コンパイラ型ほ生産性低いよ。

**デフォルトの名無しさん** · 2020/11/21(土) 04:03:36.16

template literal typesなんていれるから
型レベルSQLとかおかしな事やり始めてるし
https://github.com/codemix/ts-sql

**デフォルトの名無しさん** · 2020/11/21(土) 09:57:45.60

くっそ遅くなりそう

**デフォルトの名無しさん** · 2020/11/21(土) 10:46:50.16

C++並にコンパイル遅くなったりしてね。
実質マクロだから実行時は速いんちゃう？

**デフォルトの名無しさん** · 2020/11/21(土) 10:54:34.52

>>678
あれ小さくなったって言えんの？
r7rs なんて common lispよりでかいじゃん。
コアだけなら小さいだろうけどコアだけじゃなんもできんだろ。

**デフォルトの名無しさん** · 2020/11/21(土) 12:06:56.10

うちのtsプロジェクト、tslintも入れてビルドに10分くらいかかってる。
前に -incremental 試してみてなんかの理由で断念したんだよな。
もう一度トライしてみるか。

**デフォルトの名無しさん** · 2020/11/21(土) 12:34:04.91

スクリプトのメリット完全に失っててワロタ
スクリプトはビルドしちゃいけないんだよ
IDEでパラレルLintするぐらいならいいけどな
ビルドしないと動きませんじゃ本末転倒でなにがなんだか
ビルドするならC#とかGoでやりゃいい

**デフォルトの名無しさん** · 2020/11/21(土) 13:16:27.04

ts-nodeならビルド不要だけど、それとは違う話か
TypeScriptを直に実行できる処理系は今後も現れないだろうな

**デフォルトの名無しさん** · 2020/11/21(土) 13:30:05.02

>>689
＞ビルドするならC#とかGoでやりゃいい
ブラウザで使うのが現実的じゃない

**デフォルトの名無しさん** · 2020/11/21(土) 13:42:58.96

Dart始めました

**デフォルトの名無しさん** · 2020/11/21(土) 14:02:54.86

そもそもスクリプト言語でスクリプト言語向きじゃない大規模なことをやろうとしてるからこれができたわけで、言語のせいにするのは違う
そもそも今のWeb（アプリ）はTS使ってなくてもビルドしてるものばっかりだし

**デフォルトの名無しさん** · 2020/11/21(土) 14:35:34.39

まあ、べつに「スクリプトのメリット」を期待してtsを使ってるわけじゃないしな。
とはいえビルド時間が短縮できるならそれに越したことはないが。

**デフォルトの名無しさん** · 2020/11/21(土) 15:32:21.74

watch使うからビルド速度そんなに気にならないなぁ

**デフォルトの名無しさん** · 2020/11/21(土) 18:31:06.90

>>687
RSR7-smallは5をベースにしてるから、それでなんも出来ないとか言ったら、それまでのSchemeを全否定じゃんw

**デフォルトの名無しさん** · 2020/11/21(土) 18:58:48.16

いっそガチでマクロ入れてくれたら色々捗るなぁ。凄く読みにくくなるだろうけど。
そこまで行かなくとも、（内部的に複数の関数を持つ）関数オーバーロードとか欲しいかも