TypeScript part4

**デフォルトの名無しさん** · 2022/02/07(月) 13:36:19.77

>>70
ははは
ならその素晴らしい数千行の銀行システムを売り込んできたら？

**デフォルトの名無しさん** · 2022/02/07(月) 13:40:37.88

途中までの思想はわかるけど、数千行銀行はちょっと無理だと思うよ……

**デフォルトの名無しさん** · 2022/02/07(月) 13:46:02.77

とはいえ分割単位次第か

**デフォルトの名無しさん** · 2022/02/07(月) 13:58:43.68

>>72
今は俺はJavaを殺すのはWeb系だと思ってるよ。
何処かが「もうこれWeb系でよくね？」として試しにやってみて成功したら、一気に流れると思う。
開発/運用コストが1/10～1/100だろうから、
金銭面しか評価出来ない文系馬鹿が仕切ってる日本の銀行とかは一気に導入だよ。
マジな話、みずほ銀行が作り直すのならマイクロサービスでやれば面白いとは思ってる。
まあ現実的には病院や自治体から導入で、銀行は最後尾だろうけどね。

>>73
それは発想の方向の違い。
単発サービスで3,000行程度に留まるところまでサービスを分割する。
できるできないではなく、3,000行程度になるまでひたすら分割するだけ。

実際、DBに対して単に読み書きするだけなら、200行程度で書けるでしょ。
だから最悪、1,000行程度までのマイクロサービスに分割しろ、と言われても普通に出来てしまうんだよ。

**デフォルトの名無しさん** · 2022/02/07(月) 14:09:33.83

>>75
そういう意味なら納得です

**デフォルトの名無しさん** · 2022/02/07(月) 14:10:07.39

素晴らしい！
ひとりの天才の出現によって金融系システム従事者が超難度システムのメンテから解放されるんだね
私はもしかすると時代の転換点を最も近いところから目撃してしまったのかもしれない

**デフォルトの名無しさん** · 2022/02/07(月) 14:19:47.08

>>69
lodash compose かな
まぁあれはあれで前立腺イキな気持ちよさはある

**デフォルトの名無しさん** · 2022/02/07(月) 14:20:45.58

>>77
みずほ社員２０万人「ﾀｽｹﾃ・・・ﾀｽｹﾃ・・・」

**デフォルトの名無しさん** · 2022/02/07(月) 14:27:40.67

ちゅーかなんでみんながみんなクソデカカチカチシステム作る前提なわけ？
適材適所って言葉を知らんのか

**デフォルトの名無しさん** · 2022/02/07(月) 14:43:03.87

>>78
lodash有りならlodash/fpにそのままズバリpipeもあるし、部分適用もお手の物やん

**デフォルトの名無しさん** · 2022/02/07(月) 14:51:15.15

>>80
だって小さいシステムなら誰でも作れるじゃん
それこそPHPやPerlでも構わな・・・くはない死にたくなるけど、まぁやってやれんことはない
っぱエンジニアは20万人月回してこそ1人前でしょ

**デフォルトの名無しさん** · 2022/02/07(月) 14:55:26.17

それにしてもマイクロサービス万能論者って久々に見た気がするわ
サービスを分割すればするほどサービス間の連動の管理が難しくなってそれはそれでうまくいかないぞ
というんでモジュラーモノリスだとか色々回帰論が出てきて今となっては「やっぱり銀の弾丸はなかったね」が常識で通じる時代になったと思ったんだが…

仮に30万行のシステムがあったとしてそれを3000行に分割したら単純計算で100個に分割できるわけだ
100種類のサービスを間違いなく連動させるのがどれだけ大変なことなのか
ちょっと甘く見過ぎてる感じがするね？

**デフォルトの名無しさん** · 2022/02/07(月) 15:01:35.38

>>61
>Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、
>鯖でやる事なんて大して無いんだよ。

どんだけ無知なんだよww
流石にこのレベルで偉そうに語られると相手するのが恥ずかしくなる

**デフォルトの名無しさん** · 2022/02/07(月) 15:02:48.84

>>82
TS開発者全てを20万人月扱うスーパーマンにするなw

**デフォルトの名無しさん** · 2022/02/07(月) 15:13:48.61

>>75
相手がボロ出すまで同じ事繰り返すだけの自演おじさんなんて相手しなくて良いよ。おじさんの話の内容見てても読解力もTS理解度も足りてないんだし

**デフォルトの名無しさん** · 2022/02/07(月) 15:26:53.69

DDD的な話はわりとまともなこと言ってるけど
コード例を出さないからTS固有の問題なのか使い方や作り方の問題なのか判別つかないね

**デフォルトの名無しさん** · 2022/02/07(月) 15:33:02.79

銀行みたいに堅牢性や永続性が最重要のシステムをTSで作るわけないけど
変化に対する柔軟性に重きを置くシステムならサーバー側でもTSは有力な選択肢だと思う

UnionやIntersectionのおかげでFunctionalなDDDがやりやすいってのが一番の理由
JavaみたいにOOPベースのDDDやるならTSを選ぶメリット感じない

**デフォルトの名無しさん** · 2022/02/07(月) 16:02:48.76

>>87
それだよねぇ。長い文章書くわりに具体的な内容無いもの

**デフォルトの名無しさん** · 2022/02/07(月) 16:15:52.59

>>83
> 30万行のシステム
これがそもそも間違いなんだよ。
銀行なんて最終的には通帳に記入する内容、つまりは「日時と金額と取引相手」だけ管理出来てればいいんだぞ。
最初から綺麗に作れば、何をどうやっても30万行なんてならんよ。

無駄に膨らんでる理由は、過去のコードを除去出来ない点にある。
だけどそれは新規に書く部分には関係ない。
だから現実的には携帯みたいに2G->3G->4G->5Gと徐々に載せ替え、過去の口座も徐々に新鯖に載せ替えて、
古いコードは丸ごと捨てていけば良かっただけの話。
「メンテする」というのがかなり難しいから、「新規に書いて古いのは捨てる」の発想。
実際Web系はこれに近いでしょ。
実は本来はOOPもこれ（モジュール単位で入れ替えてアップグレードしていく）だったのだが、
何故かひたすらメンテする思想になってしまってるが。

一応言っておくが俺が言ってる行数は、71の言ってる「システム規模」、つまり自前で書くコード規模な。
3rdパーティのライブラリやフレームワーク等、他人が書いてて既に動くことが確定しているコードは含まない。
まあこれを誤解しているレスは今のところ無いと見ているが。

**デフォルトの名無しさん** · 2022/02/07(月) 16:16:36.07

あと俺は別にマイクロサービスが良いと思っているわけではない。
俺が言ってるのは、（という程は言ってないが）
「コードを書いて捨てる前提なら、メンテナンス性も可読性も必要ない」って事だ。
ここが逆転の発想なんだよ。
元々これらが必要だったのは、
初心者あるあるの「半年前に自分が書いたコードが読めない」「規模が大きすぎてコードを追えない」を回避するためだ。
後者については大体10,000行程度が限界だと昔から言われてるから、単純には、

・半年で開発を終了出来ない規模以上の開発は、可読性が高いコードでないと無理。
・10,000行を越える規模の開発は、一人では無理。よって他人にも読めるコードを書け。
・作り直すにしてもどうせ同じようなコードを書く事になるから、メンテした方が生産性が高い。

というわけでこれが大正義とされていたわけだが、実際は、

・そもそも可読性の高さなんて初心者には分からない。
・メンテ性を上げるために間接参照挟みまくってるコードは、余計に分かりにくくなる。
・Web系はそもそもそんなに大規模にならない。(DBとJSに切り出した時点でほぼスカスカ）
・Web系は仕様自体がガンガン追加されるので、古いコードをありがたがってメンテする意味がない。
　（新しい仕様を使った機能は新しく書くしかない）

なので、「依存しない」ではなく「依存先を適切に選んで単純なコードを書き、ハズレだったら捨てる」と割り切ってるのがWeb系。
具体的にはJSONもそうだろ。toJSONはJSON形式に依存する大前提で、JSON形式が捨てられれば立ちゆかなくなるコードだ。
しかし、JSONが使える限りは至極単純なコード、JSON.stringifyとJSON.parseで終われる。
そこを完全コンストラクタを呼び出すコードを全クラス分I/O層に置け、というのは、理屈は分かるが、無駄手間でしかない。
それがJavaにおいては正義だ、というのもまた事実なのだろうけど。
でも実際それがJava界隈の糞な所でもあるよね。
関数ポインタが使えないという言語の問題を継承をこねくり回したデザインパターンで誤魔化して糞コードにしてて、
しかもそれを自覚出来てないところとかもね。

**デフォルトの名無しさん** · 2022/02/07(月) 16:17:21.79

だから他人から言われた大正義を信じるのではなくて、それは何の為なのか、
どこまで依存していいのか、何に依存してはいけないのか、
コードはどの程度メンテする予定で、可読性はどれくらい必要なのか、
ちゃんと自分で考えて丁度良い点を目指さないと駄目なんだよ。
Javaにおいては20年後に他人がコードを読む前提だから、間違ってもこんな事は言われないはずだけど、
Web系においては、20年後も動いているコードなんて存在しない前提でも全く問題ないんだよ。
だからJavaの常識はJavaの世界向けにチューニング済みであって、それをWeb系に持ち込んでも失敗するだけだよ。
まあそれでもやるのは自由だけど。

**デフォルトの名無しさん** · 2022/02/07(月) 17:00:21.50

> 最初から綺麗に作れば、何をどうやっても30万行なんてならんよ。

ガラパゴス日本村のおらが法のスパゲッティをシステム化するんだからしゃーない
30万のif文がおんどれらを襲う

この国の映し鏡である金融システムをリファクタするには、まず老い腐った政治家どもを晒し首にして
もう一度ﾄｷｮを焼け野原にするところからやり直さなきゃいけないんだよ

**デフォルトの名無しさん** · 2022/02/07(月) 17:13:31.69

>>93
おまいさん以前Linux板あたりに居なかったか？

**デフォルトの名無しさん** · 2022/02/07(月) 18:19:58.29

>>94
いたよ。あそこは楽しかったね。

**デフォルトの名無しさん** · 2022/02/07(月) 18:34:04.56

>>95
だな。相変わらずで何よりだ

**デフォルトの名無しさん** · 2022/02/07(月) 21:20:10.49

>>58
そういえば
> fromJSON
ではなくて、reviver関数な。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse

> getFullName(h) じゃなく
> h.getFullName() みたいにしたかったのに
> みたいな
あと、出来る/出来ないで言えば、これは出来るよ。勿論禁じ手だが

Object.prototype.getFullName = function(){return this.firstName+this.familyName;};
var h = {firstName:'Java', familyName:'Script'};
h.getFullName(); // "JavaScript"

とか。問題は、JSはこれを行うように設計されてるのに、事実上使えない点で、
プロトタイプ拡張がもうちょっとローカルに出来る仕組みが導入されたら言語としては面白くなるとは思うよ。
(俺は知らないけど、)prototype.js時代は楽しかっただろうとも想像出来る。
それぞれのclassをちゃんと整備する方が正道ではあるのだけどね。

**デフォルトの名無しさん** · 2022/02/07(月) 21:40:15.30

一応訂正。enumerableとwritable消しときます。

Object.defineProperty(Object.prototype,'getFullName',{value:function(){return this.firstName+this.familyName;}, configurable:true});

**デフォルトの名無しさん** · 2022/02/07(月) 21:51:28.00

>>97
へー、reviver初めて知ったわ、サンガツ

いやープロトタイプ汚染なんて30年ぶりに思い出したよ
Goのレシーバをsyntax砂糖で自動でmethod生えるような文法の方がいいと思う

**デフォルトの名無しさん** · 2022/03/05(土) 02:42:31.37

https://twitter.com/uhyo_/status/1499759388462297096
uhyo_の上から目線が年々悪化している
発表でも口調からそれが感じられる
相手を思いやらずくさすハラスメント人間がTwitterのTSコミュニティ作ってるのは最早害悪では

会社のSlackでこんなのやられたら何人か辞めるでしょw
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2022/03/05(土) 07:10:18.34

直接本人に言えよ

**デフォルトの名無しさん** · 2022/03/05(土) 08:26:19.33

売られたケンカは買ってこそ江戸っ子よ

**デフォルトの名無しさん** · 2022/03/05(土) 10:57:55.53

>>100
ぼくがきにいらないからあいてをつぶす
ゆとりだね

Webなんだから普通に競争すればいいだけ
お前がもっと良いコミュニティを立ち上げれば人が離れて過疎って殺せる
それが出来ないのなら「ぼくのさいこうのこみゅにてぃ」を勘違いしてるお前らゴミゆとりの問題

**デフォルトの名無しさん** · 2022/03/05(土) 11:00:21.82

喧嘩売ってるだけのやつは粛々とNG

**デフォルトの名無しさん** · 2022/03/05(土) 13:37:44.83

>>100
相手にしなけりゃいいじゃん

よく知らない人だけどツイート見れば自己満論破厨なのは明らか
この手の人にまともな議論は通用しないからね

**デフォルトの名無しさん** · 2022/03/06(日) 03:59:56.58

>>103
そんなこわいせかいはやだッピ

**デフォルトの名無しさん** · 2022/03/06(日) 07:16:43.23

>>106
56してしまえば笑顔になれるよ

**デフォルトの名無しさん** · 2022/03/06(日) 10:45:25.91

>>106
> 相手を思いやらずくさすハラスメント人間がTwitterのTSコミュニティ作ってるのは最早害悪では
つまり、「相手を思いやって腐す事のない優しい人がTwitterのコミュニティを作るべき！！！」と思ってて、
それが大正義なんだろ。やってみればいい。

でもそれではWeb上のコミュニティは成り立たない。
その程度も分からない馬鹿が、しかも全く関係ないここにその話を持ち込む事も馬鹿げてる。
だからお前も死ね、でしかない。

ただいずれにしても、ゆとりはベースの価値観が違うから、非ゆとりが立ち上げたコミュニティで安寧を得る事はないよ。
だからゆとり向けコミュニティはゆとりで立ち上げないと無理だ。
Qiitaとか素晴らしく上手く立ち上がってる所だと思うけど、5chとは根本的に違うし相容れないでしょ。
好きなところを使えばいいが、「今ある場所を俺好みに変えよう」というのは傲慢だし原住民を馬鹿にしてる。
それすら理解出来ないからこんな無関係なところで悪態つくわけでさ。

まあでも元気があるならまずは自分で立ち上げてみるべきだよ。
それで客を奪えるのならそれが正義だし、優勝劣敗でよりよい方向に発展するのが正しい姿で、
Webはこれが割と厳密に守られてる構造だから、この点は素晴らしい。
だから文句があるのならまずはやってみる事だ。
そしてまずは、「そうなってる理由がある」事を理解すべきだ。

**デフォルトの名無しさん** · 2022/03/06(日) 10:52:15.05

じいじ、ゆとり教育はとっくの昔に終わったんやで

**デフォルトの名無しさん** · 2022/03/06(日) 10:56:05.27

なにこの気持ち悪いやつ

**デフォルトの名無しさん** · 2022/03/06(日) 10:58:33.29

コードは短く読みやすく書きましょうって教わらなかったん？

**デフォルトの名無しさん** · 2022/03/06(日) 11:03:19.14

>>109
いや5chの雰囲気が変わりつつあるのはゆとりが流入してきてるからだろ（勿論数年前からだが）

中高生で5ch見てるようなら本気でヤバイから止めた方がいい
大学生でもまだ止めておいた方がいい
社会人で、ある程度社会についても知り、デタラメな陰謀論とかも自分の頭で判断つくようになってから、ならありで、
実際これが大半だから、現時点での新規流入組はほぼ全員ゆとりだと思うが。

**デフォルトの名無しさん** · 2022/03/06(日) 11:23:08.54

>>111
ちなみにお前らはそう習ったのか？それはどこで？

**デフォルトの名無しさん** · 2022/03/06(日) 11:28:44.61

ゆとり以前ってどんだけ前やねん

**デフォルトの名無しさん** · 2022/03/06(日) 11:53:24.67

じぃじ・・・

**デフォルトの名無しさん** · 2022/03/06(日) 12:05:40.95

>>114
俺の感覚では2013、つまり9年前だ。
そしてここ数年が5ch上のゆとり人口密度が最大で、その後脱ゆとり世代の流入が始まる。
だから現時点で(ゆとり的価値観では)ここが快適だと思えないのなら、そりゃそもそも無理なんだよ。
そして俺らにとってはお前らの存在自体が不快だって事だよ。
嫌いな場所にわざわざ来て悪態つくとかどうかしてる。

ただ、そうなってしまう理由も俺には分かるんだけどね。
ゆとりは「優しい」事が第一だから、相手の意見を否定する事は「害悪」で、まともな議論場なんて整備出来ない。
だからQiitaは(あれはあれでいいとは思うが、)「否定を全否定」してる構造になってるだろ。
あれがゆとり的価値観の世界で、twitterはそうじゃないから、そりゃ無理だよ、って話だよ。

**デフォルトの名無しさん** · 2022/03/06(日) 12:10:29.85

気に入らないなら新しいの作れって考え方
ウェブ系だと普通なのか？それってDIYっぽくない？
それに利用者からしたらぽんぽん新しいもの出されてトレンドが変わるのは迷惑でしかない
今あるものをより良くしていこうという考え方の方がいいと思うな

**デフォルトの名無しさん** · 2022/03/06(日) 12:27:11.95

>>116
感覚だけでレッテル貼るんだ……

**デフォルトの名無しさん** · 2022/03/06(日) 13:42:08.14

>>117
> ウェブ系だと普通なのか？
Web系ではなく資本主義/自由主義経済において普通。会社だって気に入らなければいくらでも起業しろ、でしょ。
Web系においてはこれが割と厳密に守られてて、Webサイトは自由に作れるし、起業する奴も多い。
(Webサイトも広告貼るならただの集客業《＝ITチンドン屋》でしかない)

> 今あるものをより良くしていこうという考え方の方がいいと思うな
基本的にはこれは社会主義の思想。国で素晴らしい物を一つ作れば十分、という事だから。
ただしこれは現実的に出来ない。だから資本主義が社会主義を圧倒してる。
理由は簡単で、
・「素晴らしい」の定義が人によって全く異なる --- (A)
・そもそも何が「素晴らしい」のか、まだそれを見てない状態で想像出来る奴はほぼ居ない --- (B)
だからめいめいが「オレオレさいきょうの○○」を作りまくる資本主義の方が、社会主義より『結果的に』繁栄する。
ただしその時点で国としてのインフラ(教育/交通/電力等)が全く整って無い場合、
インフラの整備はほぼ全員の国民にとって「素晴らしい」事は明白なので、トップも実際にそれをやる。
だから社会主義/共産主義/独裁主義の方が国としてのスタードダッシュは速いし、歴史的にもそう。
ところがインフラを整えた位のところで、次に何をすべきかが分からなくなって失速する。
だから国としては独裁→自由主義にうまく衣替えするのが一番効率がいいのだが、
独裁してインフラ整備した連中はその時点で『大成功』してるつもりだから、その権力を絶対に離さない。
(実際はその独裁者の才覚によるものではなく、誰がやってもその状況なら大成功するわけだが)

**デフォルトの名無しさん** · 2022/03/06(日) 13:42:30.55

で、Web上のコミュニティについては、

・ゆとりは基本的に許容範囲が無茶苦茶狭い。ちょっとでも不満があったらそれは駄目だと見なす

ので、上記(A)に引っかかって、結果的にコミュニティを上手く成立させられてない。（と見える）
(B)については確率の問題であり、ゆとりも母数は相当数居るのだから、問題ないはず。
現状、Webインフラは既に整備済みだから、「オレオレさいきょうの○○」を作る方が効率がいい。
仮に国有5ch、国有Twitterとして、それぞれ「この方針で行く」なんてやっても社会主義同様停滞するだけ。

そもそも何かしらの場があって、そこに居ついている人にとっては、そこが十分に「素晴らしい」場所なんだよ。
それを「俺がそう思うから」で変更するのは、元々居た人にとっては「素晴らしい」点が失われる事にもなりかねない。
これを防ぐために、並立させた状態で好きな方を選べ、がforkで、基本的にGitHub等もこの方針でしょ。

馬鹿ゆとりにも分かるように言えば、

・ゆとりにとっての快適は、上の世代にとっては不快

だから結果的にそれなりに住分けてる。この事実をちゃんと考えろ、という事。
いずれにしてもtwitter上のコミュニティなんて、勝手に宣言してるだけだし、
気に入らなければ自分で作って競争すればいいだけだろ。
ただ、>>100程度の馬鹿ではこれは出来ないと思うけど、という話。

>>118
100は典型的ゆとり価値観だぞ。
ここは匿名なのだから、自分が何者かは自分の書き込みで示さなければならない。
ゆとりらしい書き込みをしたからゆとり呼ばわりしてるだけ。
これが悪いとは俺は1mmも思わない。
(そうされたくなければそういう書き込みをしなければいいだけ)

**デフォルトの名無しさん** · 2022/03/06(日) 15:28:00.88

>>120
お前ここ初めてか？力抜けよ。

**デフォルトの名無しさん** · 2022/03/06(日) 15:42:42.98

>>107
>>121
ゆとりを56してしまえば笑顔になれるよ

**デフォルトの名無しさん** · 2022/03/07(月) 07:16:36.13

こんなやつが暴れてる5chではコミュニティが育つわけもないよなぁ

**デフォルトの名無しさん** · 2022/03/07(月) 07:34:46.32

ぼくのかんがえたさいきょうのこみにゅてぃ以外みとめません！

**デフォルトの名無しさん** · 2022/03/07(月) 13:09:46.84

>>123
なら出ていけばいいだけだね。それでこちらも助かる。
俺はゆとりが全員死ぬのを望んでいる。

というかね、ゆとりは相変わらず『俺様が絶対正義』だと思っているようだが、
そもそも「価値観の違いによるストレス」は相互であり、相手も(符号が違うだけで)全く同じストレスを受けてる。
自分達が一方的に被害者だってことにはならない。お互いに被害者であり加害者だ。

(つかなんでお前らが被害者ポジションマウントを気取るのかさっぱり分からないが、
ネット見過ぎてゴミクズ韓国人がデタラメ言ってるのを真に受けて戦法を学んだつもりなのか？
まあひろゆきが議論上手に見えるようだから実際その程度の頭なのかもしれんが)

**デフォルトの名無しさん** · 2022/03/07(月) 13:10:25.20

この辺、ちょっと考えればすぐ分かるはずなのに、ゆとりは全く考えようともしないから気づけない。
馬鹿ゆとりにも分かるようにくどいが言い直すと、
ゆとりが「上から目線ガー」と感じてるのなら、
ゆとり以前の世代は「なんで下の者にこんな言われようされないといけないんだ？」と思ってる。
上司は友達でも同僚でもない。
勘違いしている奴も中にはいるが、大半は職責を正しく全うしてる。

そこで「もっとフレンドリーにやった方がいい」というのなら「提案」になるが、
当たり前だが「上司と部下」で既に上手く回ってる組織でそれをやっても嫌われる。無茶言うなでしかないからだ。
だから「フレンドリーな会社を作って、そっちの方が上手く回る(=利益が出る)ことを示し、
優勝劣敗の原理により『上司と部下』の会社を廃業に追い込む」というのが正しい自由主義経済での解決法だ。
くどいが、元々成立していた会社を「ぼくのさいきょうのかいしゃ」に変更する事ではないんだよ。

なんでこんな事になってるかというと、そもそも「ぼくのさいきょうのかいしゃ」は実際ただの勘違いが多く、
大半の場合はろくでもない結果にしかならないからだ。
ただ、中には上手く行く事もあるし、そういうのはえてして当初は「無茶だ」としか思えないから、
そういう成長の芽を潰さないために「ぼくのさいきょうの○○」を作る自由は保障されてる。
これが自由主義経済。

ゆとりは昔から「同僚や先輩にお願いするべき事項を、上司に振る？！？！」と言われているが、ここは相変わらずだろ。
ゆとりの「上から目線ガー」はゆとり以前の「何故俺がこんな…」の裏返しでしかない。
お前らがストレスを感じるのであれば、お前らも十分ストレスの原因になってる。
だから棲み分けが妥当なんだよ。

**デフォルトの名無しさん** · 2022/03/07(月) 13:11:19.93

さて本題100、実際そいつがどれ程かは知らんが、俺から見れば普通なんだろうなとは思う。
でもそれが平均的ゆとりにとって看過出来ないストレスで無理なら、
同様に無理だと思ってるゆとりも大勢居るはずだから、そいつらと共にもっと「優しいコミュニティ」を立ち上げればいいだけ。
そしてそれで上手く行けば、他コミュニティも学んで優しくなるところも出てくる。これが自由主義経済。
こうなればゆとり価値観の勝ちでいい。

ただまあ、一般的にWebコミュニティは優しいだけでは上手く回らない。
塩対応には必ず理由があって、お前らは「人格ガー」って事にしたいのだろうけど、大半はそうではない。
まあその辺はやれば分かるし、やらないと分からないので、やってみればいい。
それで上手く行けばよりよい物を得られ、全体に利益がある。駄目でも損失はない。これがforkの良いところだ。

(forkの場合はそのままの現行と一部改造した新規の構成のため、失敗しても現行は無傷で、プラス方向にしか進化しない。
現行を直接変更する「改善」だと、「改悪」される事もあり、マイナス方向に進む場合もある。
つまり、自由主義経済は進化の方向がデタラメで速度も遅いが、プラス方向にしか進化しないため、長期的にはなんだかんだで成長する。
対して社会主義だとスタートダッシュは速いが、「改善」の難易度も段々高くなるため、
ある程度以降は改善改悪を繰り返し、長期的には停滞してしまう。
これが社会主義が資本主義に負けた根本的な理由。
だから俺達はやっぱり自由主義的にforkで行くしかないんだよ。
『自分が大正義だ』と思ってる限りforkなんて効率が悪すぎると思えるだろうが、それは傲慢でしかない。
正しかったかどうかは結果《＝多数の支持》で判断されるべきであって、お前の思想に合致してるかどうかではないから。
《というかパヨクが根本的にずれてるのはここで、『俺様が絶対正義』だと自信持ちすぎてるからあんなことになる。
そしてゆとりにもこの傾向はあるよ。これは自覚した方がいい》)

**デフォルトの名無しさん** · 2022/03/07(月) 13:12:24.61

5chでtwitterの悪口を言っても何ら生産性がない。
文句があるのならまずはやってみる事だ。お前もコミュニティ立ち上げ宣言してみればいい。
それで上手く行けばよし、駄目なら駄目で、何故塩対応してたのかが分かるだろうさ。
だからいずれにしても君には利益があると思うけど。

あとついでに聞きたいんだが、なぜゆとりは5chに拘るのだ？
5chなんてゆとり以前の世代「ゆとりにはついていけねえ…」の巣窟だ。
ゆとり以前からあるんだから当然だが。
いずれにしても、ゆとりにとって快適な場所にはならないよ。
(5chの連中を見下したり馬鹿にしたりするのも自由だけど、それを5chに来て言うのは頭がいかれてる。
まあそれ以前に、twitterの悪口を5chで言うのも頭がいかれてるが)

既に言ったがQiitaがゆとり価値観の場所で、
「Qiitaに掲示板機能付けてくれ」が「5chを使う」よりお前ら的には正しい解のはずだ。
もちろんQiitaはそれが出来ないと分かってるからやってないのだが、
それでも「ゆとり価値観の掲示板」を何処かに作らない事には、お前らの安寧の地はないと思うけど。

**デフォルトの名無しさん** · 2022/03/07(月) 22:53:54.14

TypeScriptもついに4.6か
翻ってウチのNuxtプロジェクトときたら未だに4.2にロックイン
Nuxt 3になれば何とかなると待って信者が祈りを捧げて早幾年
未だβのまま
そもそもbreaking changeに耐えられる品質でもない

この型無し糞ゴミ採用した奴●してやりてえわ
そもそもVueコミッター全員●したい
早く潰れろ

**デフォルトの名無しさん** · 2022/03/07(月) 23:53:20.52

.NETやってるけど快適

**デフォルトの名無しさん** · 2022/03/08(火) 05:55:37.35

つまり言語作者が同じTSも快適って事か

**デフォルトの名無しさん** · 2022/03/08(火) 08:51:42.58

jsファミリーに期待するな

**デフォルトの名無しさん** · 2022/03/08(火) 12:40:02.06

やはりRustのみが縁なき衆生をお救いくださるのである（過激派

**デフォルトの名無しさん** · 2022/03/18(金) 11:45:07.12

node_modulesの下のコードが静的エラー出して鬱陶しいです
typescriptの開発者って静的エラー消さずにパッケージ出荷しちゃうんですか？

**デフォルトの名無しさん** · 2022/03/18(金) 11:57:30.55

excludeしろ

**デフォルトの名無しさん** · 2022/03/27(日) 17:58:36.93

TSはもしかして例外あんまり使わないんですか？

**デフォルトの名無しさん** · 2022/03/30(水) 14:38:24.60

みなさんどういう単位でファイル分割されてますか？
1ファイル1クラスのphpと違って自由だから逆に迷ってしまいます
ベストプラクティスないかググっても見つからず…

**デフォルトの名無しさん** · 2022/03/30(水) 14:47:13.20

どうでもいいので好きにすればいい
そもそもスクリプト言語ではそんなガチガチにこだわらないほうがいい
スクリプトは雑で汚くてもいいから小さいシステムをサクッと作るための道具だから

**デフォルトの名無しさん** · 2022/03/30(水) 15:27:58.67

>>137
教科書的な正解が欲しいならGitHubでTypeScriptコンパイラかVSCodeのソースを見ればいい
機械的な基準ではなく、意味のある単位で適当に分けていることがわかる
身も蓋もないことを言えば、十分に頭の良い人間の裁量でケースバイケースで判断するのがベストだ

**デフォルトの名無しさん** · 2022/03/30(水) 15:33:36.80

>>137
普通にクラス単位で分けるし、型（関心事）とその周辺関数郡で分割するかな。あとは1ファイルをなるべく小さく保つ。改修で膨らむ可能性があるから。
個人的には1ファイル250行超えたら危機感持つ。

**デフォルトの名無しさん** · 2022/04/18(月) 21:22:21.94

>>137
なるべくファイル数は少なく保つ
微塵切りの千切りファイルで見通しを悪くしてはいけない
classは使わない
十分に小さく参照等価なfunctionを組み合わせる
どうせ改修で膨らむほど使われないから。
個人的には1ファイル250行未満なら危機感持つ。

**デフォルトの名無しさん** · 2022/04/22(金) 12:41:47.72

初心者です
serverlessってフレームワークを使ってるんだけど、規模小さいコードなのにビルド始めるとesbuildが16Gメモリ使って完了までくっそ時間かかる
業務用のソースだから晒せないんだけど、一般論的に言ってこの最適化オプションはハマりやすいので注意、みたいなのってあります？

**デフォルトの名無しさん** · 2022/04/22(金) 15:45:27.64

ここよりフロントエンドのフレームワークのスレで聞いたほうが良いと思うな

**デフォルトの名無しさん** · 2022/04/26(火) 21:25:48.15

JSファミリーの仕様のごちゃごちゃ加減が酷い
なんでこれが流行ったんだ

**デフォルトの名無しさん** · 2022/04/26(火) 21:27:37.78

他の言語が取って変わろうとするたびに、
javascript側の仕様更新による延命がうまくいったせいで、
ごちゃごちゃな歴史を引きずったまま、いまでもゾンビのように君臨してるパターンか
フロントのフレームワーク、JS一択なのが酷い

**デフォルトの名無しさん** · 2022/04/26(火) 21:37:42.76

ブラウザがまともにサポートしてるのがそれだけだったから仕方がない
もし最初に軌道に乗ったブラウザスクリプトがVBだったら今頃VBが流行ってたよ

**デフォルトの名無しさん** · 2022/04/26(火) 22:16:40.32

ありえんわ
勘違いもはなばなしい
なんだかんだ（古い文法を除けば）JS/TSの文法はプログラミング正統派として読みやすい
だから未だに使われ続けている

**デフォルトの名無しさん** · 2022/04/26(火) 22:16:58.75

と思いたいんだね

**デフォルトの名無しさん** · 2022/04/26(火) 22:23:32.66

実に華々しい勘違いですね

**デフォルトの名無しさん** · 2022/04/27(水) 09:19:38.83

いや、鼻々しい勘違いでいた

**デフォルトの名無しさん** · 2022/04/27(水) 09:21:46.08

でも、TS様のおかげでJSの酷さがかなり軽減されていると思る
勿論、TSスレだから媚びを売ってるだけだ

**デフォルトの名無しさん** · 2022/04/27(水) 20:19:12.60

interfaceのほうがコードきれいになるな
typeは便利だが良くない発明だ

**デフォルトの名無しさん** · 2022/04/28(木) 21:43:14.60

interfaceできれいになるような糞コード書いてるのが問題なのでわ？

**デフォルトの名無しさん** · 2022/04/28(木) 21:53:14.86

クソコードって|とか&使ってる馬鹿なコード
unionって今どきＣ言語かよ

**デフォルトの名無しさん** · 2022/04/29(金) 05:07:46.33

まあC++使えない奴は、大抵何させてもたいしたこと無いけどなw

**デフォルトの名無しさん** · 2022/04/29(金) 05:15:00.80

う、うん…(´・ω・｀)

**デフォルトの名無しさん** · 2022/04/29(金) 05:37:28.64

ヨシ！

**デフォルトの名無しさん** · 2022/04/29(金) 05:57:49.75

このスレやべーやつ住んでるな。ワッチョイつけなかったからこんなもんか

**デフォルトの名無しさん** · 2022/04/29(金) 08:07:44.25

次世代言語スレから何か流れてきてるだろ

**デフォルトの名無しさん** · 2022/04/30(土) 02:13:26.17

C++を使うにはCの知識も当然必要だがな

**デフォルトの名無しさん** · 2022/04/30(土) 11:22:16.98

オーバーロードがもうちょいマシだったらなと思う

**デフォルトの名無しさん** · 2022/05/10(火) 11:41:45.53

　　　　 ,―彡 ⌒ ミ―､
　　　〈　〈|　´ん`　|〉　〉
　　　　＼　ヽ＿／／
　　　　　/　　　　　 /みんなで
　　　　 /　　　　　 /ホモセックス

**デフォルトの名無しさん** · 2022/05/30(月) 21:44:48.53

バカが書いたTypeScriptってマジで糞だな
って思ったけどJavaScriptだったらもっと糞になってたんだよなって思って心の平静保ってる

**デフォルトの名無しさん** · 2022/05/30(月) 21:47:51.98

それ言ったら賢い奴が書いたらCでも何も問題ないんだが
言語が縛ってるのは所詮馬鹿対策でしかない

**デフォルトの名無しさん** · 2022/06/29(水) 20:00:27.28

質問です。

type t = (a: string) => string;
const f: t = (a) => false;
console.log(f('x'));

で false のところで、
Type 'boolean' is not assignable to type 'string'.ts(2322)
になりますが、
・type t = ... を書き換えてはいけない
・const f の実装を
　const f: t = (a) => <string><unknown>false;
　のように書き換えてはいけない
・// @ts-ignore
　を使ってはいけない。
という縛りで、例えばですが、
type t = (a: string) => string;
overwrite type t = (a: string) => string | boolean;
const f: t = (a) => false;
console.log(f('x'));
のように同名の型のまま戻り値の定義を書き換えるということはできるのでしょうか？
（overwrite type...は、そんな文法は無く、仮想の方法です。）

また、型定義と型指定部分だけ書き換え不可としたら、普通は、
<string><unknown>false;
// @ts-ignore
どちらで乗り切るのでしょうか？

**デフォルトの名無しさん** · 2022/06/30(木) 01:29:29.02

>>165
普通はfの型をtにしないと思うのだが、どういう意図があるの？

**デフォルトの名無しさん** · 2022/06/30(木) 07:51:24.33

>>165
>のように同名の型のまま戻り値の定義を書き換えるということはできるのでしょうか？
型定義を後付けで変更できたらいろんな前提がひっくり返る気が
そんなことが必要な状況が想像できないけどコードの臭いがプンプンする

**デフォルトの名無しさん** · 2022/06/30(木) 09:29:37.43

ライブラリの型が間違ってるとか？
質問あるあるだが、抽象化も大事だが、具体的な状況も書き添えると回答してもらいやすくなると思うよ
そもそもの質問がずれてるとかもあるからね

**デフォルトの名無しさん** · 2022/06/30(木) 11:29:36.59

>>165
です。ありがとうございます。
実際のケースでお話しします。
・ライブラリの型を利用している。
・ライブラリの実装をそのまま真似ている。（実装は変えられる。）
・anyは使わない方針。
の状況です。
【型定義（サードパーティ）】
declare const visit: { <V extends Node>(tree: Node,test: Test<V> | Array<Test<any>>,visitor: visit.Visitor<V>,reverse?: boolean): void }
export = visit
declare namespace unistUtilIs {
type TestFunction<T extends Node> = (node: unknown,index?: number,parent?: Parent) => node is T
type Test<T extends Node> = TestFunction<T> | null | undefined }
【実装（大部分省略）】
import visit from 'unist-util-visit';
import { Node, Data } from 'unist';
　function visitX(node: any): void {
　　if (!node.type) return;
　}
　return function transformer(tree): void {
　　visit(tree, (node: Node<Data>) => node.type === 'xxx', visitX);
　};
ここで、function visitX(node: any)　の Unexpected any. を消すのに難儀しています。
function visitX(node: Node<Data>): void {
にすると、
visit( の部分で
No overload matches this call.
Overload 1 of 2, '(tree: Node<Data>, test: any[] | Test<Node<Data>>, visitor: Visitor<Node<Data>>, reverse?: boolean | undefined): void', gave the following error.
...
と怒られます。極端な話、サードパーティの定義の方をいじらないと解決しないかもと思った次第です。

**デフォルトの名無しさん** · 2022/06/30(木) 12:31:53.04

5chだと読みづらいからts playgroundなりcode sandboxなりに書いて欲しい

**デフォルトの名無しさん** · 2022/06/30(木) 12:53:38.41

>>165　です。
すみません。かなり省略して、改行も削除しました。
伝えたかったのは、以下です。
https://tsplay.dev/WJyrDm

**デフォルトの名無しさん** · 2022/08/26(金) 00:55:54.58

Recordとmapped typesの使い分け方が分かりません
Record<Key, Value>と{ [key: Key]: Value }ってinterchangeableな気がするんですが、
どっちかにしかできないことがあったりするんですか？

**デフォルトの名無しさん** · 2022/08/26(金) 08:07:49.83

mapped の方が柔軟

type X = { age: number, name: string }

これは Record では定義できないだろう

**デフォルトの名無しさん** · 2022/08/26(金) 08:46:09.94

Recordはキーがいくつかの既知の値のみに限られる場合に使う
{ [key: Key]: Value }だとキーが何でも入っちゃうでしょ

**174** · 2022/08/26(金) 10:07:43.28

限られるというより、必ず既知のキーを持っていることが保証されるというべきか
record.knownKey のような既知のキーによるアクセスがタイプセーフになり、コード補完も効く

**デフォルトの名無しさん** · 2022/08/26(金) 10:18:44.77

微妙にインデックス型とmapped typeがごっちゃになってて話をややこしくしてる気がする

**デフォルトの名無しさん** · 2022/08/26(金) 22:54:52.76

>>173
それはただのオブジェクト型だと思うが

**.NET MAUI HighScool** · 2022/11/03(木) 11:06:25.02

もしかしてTypeScriptってC#で良いのでは？
静的型付け言語だしオブジェクト指向だし作った人も一緒

**デフォルトの名無しさん** · 2022/11/03(木) 11:18:14.22

C#でいいならわざわざ同じ人が新言語作らないだろ
ヘルスバーグはMS内では神みたいな扱いらしいから、自分で意味ないと思ってる仕事なんかやらないよ

**デフォルトの名無しさん** · 2022/11/03(木) 11:27:45.04

TypeScriptが解決してる問題をC#が全て解決出来るか考えてみれば？

**.NET MAUI HighScool** · 2022/11/03(木) 11:38:56.77

>>180
できてるじゃん

**デフォルトの名無しさん** · 2022/11/03(木) 12:08:35.27

or型というのかunion型というのか忘れたけど、C#にはなくない？
type a = b | c

(C#にもこの機能欲しい）

**デフォルトの名無しさん** · 2022/11/03(木) 12:23:54.28

JavaScriptに静的型付けの恩恵を与えるために作られたのがTypeScript
C#でそれは出来ないでしょ

**.NET MAUI HighScool** · 2022/11/03(木) 12:26:39.11

>>183
C#が静的型付けじゃん

**デフォルトの名無しさん** · 2022/11/03(木) 12:29:42.91

C#ではJavaScriptに静的型付けの恩恵を与えられないでしょ

**.NET MAUI HighScool** · 2022/11/03(木) 12:39:42.87

>>185
なんで？

**デフォルトの名無しさん** · 2022/11/03(木) 12:47:16.05

>>186
君はC#がJavaScriptに静的型付けの恩恵を与えられると思ってるの？

**デフォルトの名無しさん** · 2022/11/03(木) 12:57:24.44

>>182
これについてはTypeScriptが便利というよりは、JSのやり方に合わせるために必要となっているものだと思う
C#では型が条件によってコロコロ変わるような設計は普通しないから、nullabilityさえ指定できれば多くの場合十分

**.NET MAUI HighScool** · 2022/11/03(木) 13:04:33.62

>>187
いや別にJavaScript使う必要なくね？

**デフォルトの名無しさん** · 2022/11/03(木) 13:12:15.66

>>189
それは論点のすり替えでしょ

**デフォルトの名無しさん** · 2022/11/03(木) 14:21:47.63

代数的データ型は静的型付け言語にもあるよ。
最近のC#でも出来るけど記述量が多い。F#なら比較的楽に書けるけど。

**デフォルトの名無しさん** · 2022/11/03(木) 15:50:32.38

typescriptが実行時型安全まで保証してくれたらもう他の言語いらんのよな
REST APIというかJSONとの相性もマックスバリューだし
世にはびこっている型なし糞言語を全て地獄に葬り去ってほしい

**デフォルトの名無しさん** · 2022/11/03(木) 16:11:11.85

>>191
union typesは静的型において一般的な直和型とはかなり違ってて癖が強い
値が型持ってないからね

**デフォルトの名無しさん** · 2022/11/03(木) 16:27:43.63

>>193
まあそれはそうか。型ガードベースだもんね。
別に型が一致してなかったとしてもメンバさえ合ってれば雑代入しても問題ないし。

**デフォルトの名無しさん** · 2022/11/03(木) 18:23:11.89

>>192
型をバリデーションライブラリから生成すると捗るよ

**デフォルトの名無しさん** · 2022/11/03(木) 20:49:50.25

>>195
おっ　zodmanか？

**デフォルトの名無しさん** · 2022/11/03(木) 20:56:17.04

interface/classからjsonschemaを生成して、それを型ガード関数で使うってのが鉄板。

**デフォルトの名無しさん** · 2022/11/03(木) 21:05:34.21

>>196
すまねぇsuperstructなんだ。すまねぇ。

>>197
AJVはコードサイズデカくね？

**デフォルトの名無しさん** · 2022/11/03(木) 21:36:19.22

コードサイズは気にしたことがないがスキーマ手書きは面倒臭いからやだなあ。

**デフォルトの名無しさん** · 2022/11/03(木) 22:05:24.52

RestAPIの型チェックはio-tsっていうライブラリつかってバリデーションしてるな。
実行時コストがあるけど、自分は業務アプリがメインなんで変な結果で次に進まない方が大事。

**デフォルトの名無しさん** · 2022/11/03(木) 22:38:04.12

>>199
ZodとかSuperstructとかはtypeで型書くのとほぼ同じくらいの手間でバリデーションと型が生成されるからすげー楽だよ。

**デフォルトの名無しさん** · 2022/11/03(木) 22:52:51.54

うーん、俺はやっぱりTypescriptで書いた型そのまま使える方が楽だわ。

**デフォルトの名無しさん** · 2022/11/04(金) 15:37:16.21

HighScool君は納得して帰ったのか

**デフォルトの名無しさん** · 2022/11/04(金) 23:24:08.39

superstruct と zod ならどっちがええのんか？

**.NET MAUI HighSchool** · 2022/12/16(金) 16:55:41.78

C#だとvar型でも何ら問題無いと思われてるのにTypeScriptのanyはなんでTwitterでネタにされるんでしょうか？
私もあまりvar型使いませんが公式とかvar型使いまくってるしTypeScriptでany使っても何ら問題なさそうなのですが…

**デフォルトの名無しさん** · 2022/12/16(金) 17:30:57.27

コーディング時にvarは右辺で型が決まるけどanyは決まらないからかな

**.NET MAUI HighSchool** · 2022/12/16(金) 18:26:46.45

>>206
決まらないんですか？
ではvar型ではなくdynamic型と言うことなのですかね

**デフォルトの名無しさん** · 2022/12/16(金) 21:33:55.14

そもそもvarは正確には型じゃないだろ

**デフォルトの名無しさん** · 2022/12/16(金) 21:58:06.83

var型はないな

型の堅牢性などを享受するためにTypeScriptを使用しているはずなのに、anyを持ち出せばそれが途端に失われるから絶対に使わない方がいい
そして確かにanyはdynamicに近いものと考えて良い

**デフォルトの名無しさん** · 2022/12/16(金) 22:10:24.90

TypeScriptに対する理解が浅いのはともかくC#の理解もそんな程度だったのかこのコテ

**.NET MAUI HighSchool** · 2022/12/17(土) 00:18:30.36

>>208
型推論型だろ
>>210
何いってんだこいつ？

**.NET MAUI HighSchool** · 2022/12/17(土) 00:22:25.11

dynamic型は次の値を入れたらその型に変わる
例えば
dynamic x="おはよう"
dynamic x=123
でも大丈夫なわけ
anyは型の再代入ができないって見たけど？これdynamic型なの？

**デフォルトの名無しさん** · 2022/12/17(土) 00:38:58.67

>>178程度の理解のヤツに何を説明しても無駄よ

**デフォルトの名無しさん** · 2022/12/17(土) 00:50:14.95

>>212
流石にこれは触っちゃいけないレベル

**デフォルトの名無しさん** · 2022/12/17(土) 00:55:05.65

anyはまさにJavaScriptの元々の変数の扱い様そのもの。

**.NET MAUI HighSchool** · 2022/12/17(土) 01:46:39.51

>>213
TypeScriptはC#以下だったってわけか
理解

**デフォルトの名無しさん** · 2022/12/17(土) 01:54:57.82

目的が違うんだよ。C#ではTypeScriptのようなことは出来ない。
良い意味でも悪い意味でもJavaScriptのスーパーセットかつトランスパイラである必要があるんだから。
ただTypeScriptが将来C#でやってることを概ね肩代わりすることは可能だったりはするんだけどね.netライブラリをそのまま動かすように改変していくことも障害は少ない。

**デフォルトの名無しさん** · 2022/12/17(土) 02:13:01.40

そいつにかまうなよ
あちこちの言語やフレームワークスレに乗り込んでは意味不明な喧嘩売って
C#マンセーMAUIマンセーしてるだけの荒らし

**デフォルトの名無しさん** · 2022/12/17(土) 03:00:17.54

再代入と型は関係ないだろ
見た感じC#も満足に使えてないじゃん

**.NET MAUI HighSchool** · 2022/12/17(土) 04:20:14.04

>>219
どこが？
dynamic型知ってる？

**デフォルトの名無しさん** · 2022/12/17(土) 08:49:17.76

>>211
まぁ初心者なら便宜的に型だって覚えときゃいいよ

>>212
型の再代入って何？
値の再代入とは違うの？

**.NET MAUI HighSchool** · 2022/12/17(土) 11:38:05.95

>>221
値は型があってたら普通は再代入はできる
ただ型があってなかったらできない
dynamic型は型があってなくても再代入できる

**デフォルトの名無しさん** · 2022/12/17(土) 12:01:06.61

>>222
それをC#では型の再代入って呼ぶの？

TypeScriptでは変数をletで宣言すれば値を再代入できる
変数がany型ならどんな型の値でも代入できる
変数をconstで宣言すれば型が同じであろうと再代入できない
>>219の言ってるのはそういうこと

**.NET MAUI HighSchool** · 2022/12/17(土) 12:25:09.54

>>223
そういう決まった名前無いけどdynamic型は型を変えれるからそう言ってる

**.NET MAUI HighSchool** · 2022/12/17(土) 12:25:55.57

つまりletがvarでanyがdynamicってことか

**デフォルトの名無しさん** · 2022/12/17(土) 12:32:09.45

ここでもバカ晒してるのかよw

**.NET MAUI HighSchool** · 2022/12/17(土) 12:38:11.73

>>226
何いってんだこいつ？

**デフォルトの名無しさん** · 2022/12/17(土) 12:56:35.19

>>225
説明の仕方が悪かったか

C#の
dynamic x = "abc";
x = 123; //OK
に相当するのは
let x:any = "abc";
x = 123; //OK

var y = "abc";
y = "def"; //OK
y = 123; //NG
に相当するのは
let y = "abc"
y = "def"; //OK
y = 123; //NG

変数の型を推論に任せるときは型指定を省略する

**.NET MAUI HighSchool** · 2022/12/17(土) 14:07:48.19

>>228
なるほど理解したサンクス

**デフォルトの名無しさん** · 2022/12/17(土) 18:19:24.77

なんでぽまいらはC#の話をしているんだ？

**.NET MAUI HighSchool** · 2022/12/17(土) 18:58:14.82

anyはネタにされるけどvarはネタにされないなと思ってさ
まぁ勘違いだったんだけどね

**デフォルトの名無しさん** · 2022/12/17(土) 19:14:45.81

なぜanyがネタにされたり忌み嫌われたりするのかはその機能だけ見ても分からんだろうね
言語特有の背景を理解してこそ
https://qiita.com/uhyo/items/aae57ba0734e36ee846a

**デフォルトの名無しさん** · 2022/12/17(土) 20:38:09.95

any無しはJSONの扱いが面倒臭過ぎるんだよなあ
必要に応じて型のランタイムチェックを入れてキャストできる機能さえあれば格段に便利になるんだが

**デフォルトの名無しさん** · 2022/12/17(土) 20:55:50.21

ユーザー定義型ガードで足りると思うが

**デフォルトの名無しさん** · 2022/12/21(水) 14:23:05.41

JSONだろうがanyを許すな。Zodとか使うのだ

**デフォルトの名無しさん** · 2023/01/03(火) 23:03:14.80

pythonを書いていると型縛りが馬鹿らしくなる

**デフォルトの名無しさん** · 2023/01/03(火) 23:51:28.97

JavaScriptを書いていると型縛りが馬鹿らしくなる
みんながそう思ってたらTypeScriptは生まれてこなかっただろうね

**デフォルトの名無しさん** · 2023/01/04(水) 00:03:33.25

型なんて要らねーとか言ってるのは、ほぼ1人でコーディングしてる奴
まぁ、実際1人でなら要らないかも知れない
これが複数人でコーディングする事になると、他人が実装した関数にどんなデータを渡していいか全然分からない
その為にTypeScriptがある

**デフォルトの名無しさん** · 2023/01/04(水) 00:08:02.09

型がない方が縛りプレイだろ

**デフォルトの名無しさん** · 2023/01/04(水) 00:44:19.33

JavaScriptは引数の数すらチェックされない上に暗黙の変換にundefined/null/NaNと昔はブロックスコープもなくてバグの温床てんこ盛りだったからやろ

intとかStringとかのベーシックな型を書きまくつてるコードを見ると欠陥言語だなと思う

**デフォルトの名無しさん** · 2023/01/04(水) 09:28:28.37

>>239
縛り方を間違うと死ぬからな

**デフォルトの名無しさん** · 2023/01/04(水) 10:15:30.84

Flow「…」

**デフォルトの名無しさん** · 2023/01/04(水) 11:23:06.77

パラメタ名・変数名で型がわかるようにしとけば大概は済む
引数の個数をテキトウに呼ぶ奴がいたら、それはそんな作り方する方がおかしい

**デフォルトの名無しさん** · 2023/01/04(水) 11:53:32.34

そういう開発者にのしかかる煩わしさを軽減するのが型の役目だろうに

**デフォルトの名無しさん** · 2023/01/04(水) 16:13:02.47

コーディングルールの運用で型限定するのも
コンパイラにまかせて型限定するのも
少なくとも js に限って言えば前者の方が手間は少ない

**デフォルトの名無しさん** · 2023/01/04(水) 16:35:42.97

本気で言ってるのか・・・？

**デフォルトの名無しさん** · 2023/01/04(水) 16:38:46.50

>パラメタ名・変数名で型がわかるようにしとけば大概は済む

よく事故るのは受け渡すオブジェクトのメンバーの有無だったりするけどそれには無力だな。

**デフォルトの名無しさん** · 2023/01/04(水) 16:48:19.89

大概、おおむねって話よ
よほど便利だろうから、こういう言語が生れたのだろうし全否定するわけではない
あと、処理系が変数の型を把握できても、しかるべき名前でないと、開発者に分かりにくい場合がある
自作でもこれなんだっけ？紛らわしいなって、結局名前弄ったり、名前って大事

**デフォルトの名無しさん** · 2023/01/04(水) 16:56:26.80

型付けはあった方が良いけど、肝心の成果物がしょーもないことは多々あるな
最近まで参画していたアプリはすげー健康なブスだった

**デフォルトの名無しさん** · 2023/01/04(水) 17:01:25.31

開発途中で型の変更が必要になったとき安全に漏れなく修正できるメリットとかは無視できないんだけど
今までそういう経験がなかったんだろうか

**デフォルトの名無しさん** · 2023/01/04(水) 17:46:37.74

そういうのはどのみち影響しそうな箇所を全部見て確認しなきゃいけないから、値に型があることはそれほど重要じゃないと思う
それよりも代入により生じる依存関係を静的に追跡可能であることが重要で、その点では型があることで飛躍的に静的解析の精度が上がる
ただ、そのためには静的解析しやすい作りになっていることが大前提だ
動的型畑の人って概してオブジェクトと連想配列の区別が曖昧で、静的型に馴染んだ人からすると信じられないような型安全もクソもないコード書くからな
それを根本的に改めないなら型なんて大して役に立たん

**デフォルトの名無しさん** · 2023/01/04(水) 18:22:26.69

>そういうのはどのみち影響しそうな箇所を全部見て確認しなきゃいけないから、値に型があることはそれほど重要じゃないと思う
その影響しそうな箇所の把握に型があるのとないのでは大きく正確性や効率に差が出てくるでしょって話

**デフォルトの名無しさん** · 2023/01/04(水) 22:43:59.04

まぁRubyやPHP出身の低能にそもそも型書かせるのが難しいという意見には同意
根本的に教養・学が足りないから、どうしようもない
もはや言語仕様で救えないレベルの話である

**デフォルトの名無しさん** · 2023/01/04(水) 22:52:50.06

動的型畑の奴が一概にバカとは思わないが、オブジェクトの全プロパティ舐めて値を書き換えたりするコードが突如出現したりして面食らう
根本的に思考回路が我々とは違うのだなと感じる

**デフォルトの名無しさん** · 2023/01/04(水) 23:21:22.18

ｸｽｸｽ

**デフォルトの名無しさん** · 2023/01/05(木) 10:41:34.55

>240
>暗黙の変換

これが諸悪の根源

**デフォルトの名無しさん** · 2023/01/05(木) 21:34:07.80

JavaScriptは信用できない、JavaScriptは危険。

だからJavaScriptを撲滅しようとした時代があったんだよな。

JavaScriptそのものは書くものではなくて、使うものに変化した。

**デフォルトの名無しさん** · 2023/01/05(木) 22:57:13.13

JSを半端に知ってるやつこそそう言うけど、地雷がたくさん埋まってる以外は悪い言語じゃない。TypeScriptも今となっては薄いラッパーに過ぎないし

**デフォルトの名無しさん** · 2023/01/05(木) 23:01:32.86

何作るかによるな
んで、Typescriptでしょーもないもの作ってる奴はかなり多い

**デフォルトの名無しさん** · 2023/01/06(金) 00:04:22.96

動的型付けでしょーもないもの作ってる奴の方が圧倒的に多い事実

**デフォルトの名無しさん** · 2023/01/06(金) 16:55:41.96

jsもperlも卒業しろよ

**デフォルトの名無しさん** · 2023/01/07(土) 02:08:56.86

TSも卒業してrust書け

**デフォルトの名無しさん** · 2023/01/07(土) 14:15:02.15

ビルドが遅いからヤダ

**デフォルトの名無しさん** · 2023/02/02(木) 13:12:52.48

(　　)y-~~ (　 >)y-~~(　>-)y-~~( >-< )y-~~ ｳﾏｽｷﾞﾙ・・

**デフォルトの名無しさん** · 2023/02/27(月) 18:54:27.47

男卒業してTSしろ

**デフォルトの名無しさん** · 2023/03/12(日) 13:16:33.47

return this.#instance!;
https://github.com/denoland/showcase_chat/blob/970c56fbb229f00805c0f3b0adde6f4232446a3e/helpers/loader.ts#L36

! って何なんや？

**デフォルトの名無しさん** · 2023/03/12(日) 13:55:58.57

nullとかundefinedじゃねーよって意味

**デフォルトの名無しさん** · 2023/03/12(日) 21:52:14.15

undefinedっていらなくない？
全部nullと同等にしてほしいわ

**デフォルトの名無しさん** · 2023/03/12(日) 23:18:21.71

>>267
助かった
記号はググりずらくて困ってたわ

**デフォルトの名無しさん** · 2023/03/12(日) 23:38:13.62

>>269
次また困ったら解読アシスタントに貼り付けるといいよ
https://typescriptbook.jp/code-reading-assistant#eJzT11d43DgZjFa_WL74xaq1jxtnPm7qfty0-XHznsfNnY-bJj1tXfq0a_bjxumPG5c9bux_3LjgcePUx40tXEWpJaVFeQolGZnFesqZecUliXnJqYrWAJnzL3Q

**デフォルトの名無しさん** · 2023/07/30(日) 19:53:15.24

しーん