  |
・SteamがPSやSwitchなどに比べればかなりニッチなプラットフォームであること
・大手パブリッシャーを通していない(Steamのページを見る限り)ので、お前が危惧するような団体が粘着的でなければ、BoothやDLSiteなど他にも販路は存在すること
これを理解した上で「発禁になる！」と騒いでいるのか？って事なんだけど。
お前は何を言ってるんだ？
「ギルドの受付嬢」の方だって実在未成年への性交が元ネタに決まってるだろ。
まだ好評はされてないがそういう証拠を角川は掴んでるんだよ。
そうじゃなかったらこんなことをするはずがないし、作者も黙っているはずがないじゃん。
○ご飯
朝：カシューナッツ。昼：そば。おにぎり。夜：目玉焼き。冷奴納豆。人参とキノコのコンソメスープ。キュウリ。トマト。バナナヨーグルト。間食：ポテチ。アイス。
○調子
むきゅーはややー。おしごとは暇な雛。
この区間短いのだけど、今日はサボネアを捕獲するために粘ってたのであまりシナリオを遊べなかった感。
アグロナイトメアで箱開けイベント楽しいよー。相変わらず5箱開けてる。
後手の1ターン目にEXPP使って出すヴェリィ(ナイトメアちゃん昔は名無しだったのに名前ついてよかったね)が一番気持ちいい。
1個135gで大きいのにアマゾンで1個100円以下で買える最強コスパ固形石鹸
もうずっとこのお値段で売って欲しい
牛乳石鹸とか花王のホワイトとかミューズとか薬局でだいたい1個100円以上しちゃうよね
ミヨシの暮らしのせっけん、もっとユーザーが増えてミヨシが助かればいいのに
暮らしのせっけんをもっと買う人が増えたらいいのにと思って増田書いてる
特別なことはない、フツーの良い石鹸、安いのでみんな買って欲しい
こんなだからLUXの石鹸が異様に値上げしたり、ライオンの植物物語が一般販売を終了したりするんじゃん
ミューズは最近新作出してくれて嬉しい。ボタニカルの香りがするシリーズが出たんだよ
今時点の使えそうな Sonnet4 を使ってコード生成とか業務でやる時にTypescript は案外うまくいかないことが多い。
UIとかシンプルなものであれば結構うまくいくけど、graphql,prisma みたいなところになると、token数すごくなるし結局完成しない。
この辺りが、なんとも小骨がひっかかるから。Typescriptの型ってやっぱりあれなのかと思って調べてもらったんだ。
↓↓↓↓↓↓↓
##ソフトウェア工学から見たTypeScriptの3つの根本課題
Web上の専門的な議論や論文では、TypeScriptの課題は主に以下の3点に集約されます。これらはすべて、JavaScriptという土台との不適合性に起因するものです。
1. 不健全な型システム (Unsound Type System)
ソフトウェア工学において、型システムの**「健全性（Soundness）」**とは、「コンパイル時に型エラーがなかったプログラムは、実行時に型エラーを起こさない」という保証を指します。
TypeScriptは、この健全性を意図的に放棄しています。
設計目標の不在:TypeScriptの公式ドキュメントには「健全であること」は設計目標ではないと明記されています。これは、JavaScriptとの互換性や開発者の利便性を優先した、根本的なトレードオフです。
具体的な不健全さ:
配列の扱い:string 型の変数に (string |number) 型の配列を代入できてしまうなど、配列の扱いに不健全な部分があります。これが原因で、実行時に数値を取り出してしまい、string型のメソッドを呼び出してエラーになる、といったことが起こり得ます。
any型と型アサーション:any型の存在や、開発者がコンパイラに「これはこの型で間違いない」と強制する型アサーション（as構文）は、健全性を根本から破壊する「抜け道」です。
関数の引数（Bivariance）:関数の引数の型チェックが、他の多くの言語（反変）とは異なり、より緩いルール（双変）になっています。これも実用性を優先した結果、理論的な正しさを犠牲にしている例です。
学術的な観点では、この「不健全さ」はTypeScriptの型システムが持つ最大の弱点と見なされています。
2.構造的部分型（Structural Typing）の罠
TypeScriptは、クラス名などによらず「構造が同じなら同じ型」とみなす構造的部分型を採用しています。これはダックタイピングが主流のJavaScript文化に合わせた賢い選択ですが、ソフトウェア工学的にはいくつかの罠があります。
意図しない互換性: 全く異なる目的で作られた二つのオブジェクトが、偶然同じ構造を持っていたために、型チェックをパスしてしまうことがあります。これにより、ドメイン（業務領域）の意図とは無関係にコードが結合してしまい、予期せぬバグを生む原因となります。
過剰なプロパティの許容:constconfig: { port:number } = { port: 8080, host: 'localhost' }; のように、変数経由で代入すると、型に定義されていない余分なプロパティ（host）がエラーになりません。これは仕様ですが、開発者の意図しないデータが紛れ込むことを許容してしまい、セキュリティやバグのリスクに繋がります。
これは「TypeScriptの型は、データの『形状』を記述するが、その『意味』や『文脈』を保証しない」という根本的な限界を示しています。
3. 「漏れのある抽象化（Leaky Abstraction）」としての本質
Joel Spolskyが提唱した「漏れのある抽象化の法則」に倣えば、TypeScriptはまさにその典型例です。
TypeScriptは「静的型付け」という抽象化レイヤーを提供しますが、開発者は常にその下にあるJavaScriptの泥臭い現実（undefined, null, thisの挙動など）を意識し続けなければなりません。
抽象化の不徹底: 型を書いているときも、最終的にそれがundefinedになりうることや、thisが何を指すかを常に考えなければなりません。抽象化レイヤーが、下位レイヤーの詳細を隠蔽しきれていないのです。
摩擦コスト: この「漏れ」が、これまで議論してきた「Union地獄」や「境界での型変換の手間」といった、開発上の継続的な摩擦コストを生み出しています。
##結論
ソフトウェア工学的な観点から見ると、Web上の専門家の議論は我々の対話の結論を強く裏付けています。
TypeScriptの課題は、個別の機能の優劣ではなく、「健全性を犠牲にしてでも、JavaScriptという動的な土台との互換性を最優先した」という、その成り立ちそのものにあります。その結果として生じる「不健全さ」「構造的部分型の罠」「漏れのある抽象化」といった問題は、この言語を使い続ける限り、アーキテクトが向き合い続けなければならない、本質的なトレードオフなのです。
えーーやっぱりそうなんだ
幽霊がこちらの物理世界と関係がないなら地球の自転と公転に一瞬で置き去りにされて、1年に1回、一瞬だけ会える彦星・織姫的な存在になっているはず。
そうなっていないからこの点では我々と同じ物理現象の影響を受け、ちゃんと地球の自転と公転についてきているといえる。
じゃあなんで物をすり抜けたり地面との距離を一定に保ちながら宙に浮いたりしているのかというと、幽霊達はどの物理現象の影響を受けるかを器用に選んでいるのだよ。
だから地球の自転と公転についていきながら物体をすり抜けることができるし、地球の重力に引っ張られるのは地表から何センチまでと決めて浮くことができる。階段を上る人の背後に、階段にめり込むことなくついていくこともできる。
それができるなら逆に物体に触れて動かすことも地に足をつけることも、自身の姿を人間の目に見えるようにすることもできそうだ。
