  |
はてなキーワード:コンパイルとは
最近、SNS上では「BLは性的消費なのにフェミは男性の性的表現を叩くのはダブスタじゃないか？」というスレッドがトレンド入りしていた。
だがこの議論、よく見るとアーキテクチャの層が違う。つまり、話しているプロトコルが合っていない。
オタク文化圏では、「女性が描くBL」と「男性が描く女性向け性表現」を同一のAPIとして扱う傾向がある。
しかし実際には、両者は別レイヤーで動いているアプリケーションだ。
フェミニズムの文脈で語られる「性的表象の問題」は、主に「社会的リソースの不均衡」や「ジェンダー権力の構造」についての議論であって、単なる「表現内容」の良し悪しを審査しているわけではない。
つまり、BLを「性的に描いてるからフェミ的にアウト」と言うのは、仕様書を読まずにバグ報告を出すようなものなのだ。
歴史的に男性中心に最適化されてきた社会システムに、女性視点のパッチをあてて再コンパイルする運動と言える。
だから、「男性と女性を同じように扱うべき」という一般論をそのまま適用しようとすると、互換性エラーが出る。
たとえば「女性の性的表象は抑制されるべきだが、BLはOK」とされるのは、「権力構造上の対称性が存在しない」という前提で最適化されているからだ。
一方、「普通の女性はフェミと違う」「まともな女はそんな主張しない」という定番フレーズが出てくる。
だがそれは多くの場合、ユーザーの気分を和らげるためのUX的演出にすぎない。
実際、ほとんどの人間は制度的優遇（レディースデー、女性専用車両、離婚時の親権バイアスなど）という「プリインストールされた特権OS」の上で動いている。
たとえ本人が「私はフェミじゃない」と言っても、使っているAPIがすでにフェミ思想ベースで動作しているのだ。
つまり、「私は違う」という自己申告は、ただのUIレイヤー上の装飾にすぎない。
平等を掲げるなら、優遇措置をアンインストールする覚悟が必要になる。
だが現実には、多くの人が「平等という概念を口では支持しつつ、既得権のキャッシュを維持」している。
これはエンジニアリング的に言えば、「レガシーコードをリファクタリングすると言いながら結局コメントアウトで誤魔化している状態」だ。
男女平等を“動作保証付き”で実装しようとするなら、既存の社会制度をルート権限で書き換える必要がある。
だが、ほとんどの人はroot権限を持つどころか、ユーザーレベルの設定すらいじる気がない。
もっと根本的に言えば、日本社会の多くの仕組みは、女性優遇をデフォルト設定としてビルドされている。
その構造はあまりにも自然化されていて、誰もコードレビューをしようとしない。
アンチフェミを自称する男性すら、「女性は守るべき対象」という社会的テンプレートを内面化していることが多く、それが構造の永続化を促している。
結果として、「BLは性的消費」「フェミはダブスタ」という批判は、異なるフレームワーク間の非互換問題にすぎない。
BLは「個人の妄想の自由」をレンダリングするローカルアプリだが、フェミニズムは「社会構造の更新」を目指すサーバーサイドのシステム。
同じメソッド名を呼んでいるように見えても、実行される関数の意味がまったく違う。
つまり、「BL＝性的消費」「フェミ＝ダブスタ」という批判構造は、コードのバージョンが違うままマージしようとしている状態に近い。
根本的にAPI設計思想が違うのだから、いくら議論を積み重ねても互換性は取れない。
必要なのは、「どの層で話しているのか」「どの権力構造を前提にしているのか」を明示することだ。
プログラマーって聞くと今の若い人は稼げる業種って思うかもしれない。でも昔は、そのイメージとはまるで真逆だったんだよ。
90年代初頭、日本はバブルの余韻が残ってたけど、IT業界なんてまだオタクの延長みたいに見られていた。NECのPC-9801シリーズがオフィスの定番で、OSはMS-DOS 3.3とか、その後にWindows 3.1が出ておお、マウスで操作できる！なんて騒がれていた時代だ。
もちろんインターネットなんて一般にはまだ普及してなかった。せいぜいパソコン通信。ニフティサーブ、PC-VAN、アスキーネット。回線速度は2400bps。ピーヒョロロっていうモデム音が夜中の住宅街に響いていた。
俺らはそういう環境でC言語やアセンブラを叩いてたんだ。コンパイルに時間がかかるから、トイレに行って戻ってきてもまだ終わってなかったりした。
今みたいにGitHubでコードを共有なんて夢のまた夢。ソースのやり取りはフロッピーディスクで手渡しだ。5インチのぺらぺらのやつな。運が悪いと磁気にやられて一発で飛ぶ。だから俺たちはよくフロッピー神社に参拝とか冗談言ってた。
正社員で手取り20万ちょっと。下請けやフリーランスだともっと安い。今でいうSESの走りみたいな人売りも普通にあった。客先常駐でCOBOLやらされてバグが出れば徹夜。オフィスに寝袋持ち込んで、カップヌードルと缶コーヒーの山を築く。徹夜明けに食う吉野家の牛丼が唯一のご褒美。今みたいにエンジニアは市場価値が高いなんて考え方はなかったからな。ただの駒だよ。
仕事は増えるのに単価は下がる。Windows 95の発売で世の中はインターネット元年なんて浮かれてたけど俺たちプログラマーの現実は泥臭いコード修正の山。Visual Basic 6.0やDelphiが出て「これで開発効率が上がるぞ」なんて言ってたが、結局は納期に追われるだけ。SunのJavaが登場したときも「Write once,run anywhere」なんて夢を見せてくれたけど、実際には動かないアプレットと格闘する日々。
Linuxが台頭してきたのもこの頃だ。
SlackwareやRed HatLinux 5.2をCD-ROM雑誌付録で手に入れて、夜な夜なインストールに挑戦。LILOがうまく動かなくて起動しない、ネットワークカードを認識しない、X Windowが真っ黒。そんな壁に何度もぶつかっては2ちゃんねる（当時はまだ草の根BBSが多かったが）やUNIX USER誌を読み漁って解決する。それが楽しくて仕方なかった。でも金にはならなかった。オープンソースに貢献しても無償の善意で済まされるだけ。Red HatやMySQL ABが上場するまでは、ただのボランティア活動と見なされてた。
今思うと、あの頃は純粋だった。
技術そのものが楽しくて、ASCIIやOh!Xを小脇に抱えて徹夜でコードを書いた。秋葉原でジャンクパーツを漁って自作PCを組み立ててベンチマークの数字で一喜一憂した。
飯代を削ってもSCSIのハードディスクに投資したし、月刊アスキーの付録CD-ROMに入ってたシェアウェアを片っ端から試した。儲けようなんて意識はなかった。ただ、面白いものを作りたかった。
それが今じゃITは完全に拝金主義。コードの美しさより投資家の顔色を見てる。エンジニアもどこが年収高いかばかりで、言語やフレームワークを選ぶ基準が金になっちまった。Pythonが流行るのもAIブームに便乗してのことだし、ブロックチェーンやNFTなんかバブルがはじける前提のネタ探しにしか見えなかった。
もちろん、技術が商業化されて豊かになった面もある。AWSやGCPのおかげで誰でも世界規模のサービスを立ち上げられるようになったし、GitHubやDockerで開発環境も夢みたいに便利になった。だがその一方で楽しいからやるという純粋さはどこへ行ったんだろう。GitHubの草がどれだけ生えてるかが採用基準になる時代。Qiitaに記事を投稿するのも、技術共有じゃなくて転職市場でのポイント稼ぎ。
あの頃には確かに、金ではなく面白さに突き動かされる熱があった。それが今は金の匂いに上書きされてしまったように感じる。
でも稼げなくても、やる価値があった。
今の若いエンジニアたちにその気持ちがどれだけ伝わるかは分からない。
当時「Hello, world.」と表示されるだけのプログラムに、30年前の俺は心を震わせていた。
goを使ってもプロトタイプ程度のことならコンパイルの時間も気になりませんけどね。それなりに大きなプロジェクトでもファイル保存でコンパイルされるのは保存したもの及びそれを使ってる部分くらいだから、全部ってこともないですけど。どこか設定なり間違ってるのでは?
リンクは当然やり直しですが、それだってそんなに時間はかからないですね。
それは別にして、プロトタイプの開発ならpythonでも良いと思います。
が、他の方も書かれているように多数のアクセスがあるAPIだとしたらpythonで耐えられるのかとか、規模が大きくなればpythonなどの言語はむっちゃ面倒なことになります。
アクセスが多いようであれば、c、c++、Go、などへの書き換えを検討しても良いでしょうね。
ただ、ハードウェアのコストって昔と比べると高くは無いから、アップデートが落ち着くまでコンパイル型プログラミング言語にしなくても良いと思います。
提示してる「そうめんでいい」バリアントの発話仕様、あれってコミュニケーション・レイヤーでいうと意味論的優先度フィールドがゼロ初期化されてるパケットなんだよな。
で、そのゼロ初期化パケットが相手の感情OSに到達すると、そこに実装されてる価値評価アルゴリズム（通称Pride-Driven Interaction Protocol）が、受信値を「非積極的承認」としてパースする。
つまり、入力信号の中に“熱量ビット”が存在しないと、即座にException: DEVALUATION_ERRORがスローされる仕様なんだわ。
その例外は通常のtry-catchでハンドリングされず、感情カーネルを通じてフロントエンドの態度・表情UIに直結するから、結果的に「何様だよ」っていう可視化出力が生成される。
さらに、相手の感情モジュールは言語的同値判定じゃなくて意図ベースのベクトル比較を行ってるから、
「そうめんがいい」(積極的選好ベクトル) と 「そうめんでいい」(受動的妥協ベクトル) は、同一文字列近似度99%でも意味論距離が閾値越えしてエラー扱いになる。
これを無視して「ただの晩飯APIコール」だと軽視するのは、TCPレベルのパケットロスを「まぁ届くっしょ」で放置するようなもんで、
通信の確実性よりも自己CPUサイクルの節約を優先する、お前側のシステム設計思想が原因なんだよな。
結局のところ、感情という非決定性システムに対して最適化パラメータ調整を怠ってる時点で、お前の通信モデルは高確率でクラッシュを引き起こす。
もし稼働安定性を確保したいなら、相手のEmotionalAPI Referenceを逆コンパイルして、推奨トークン列を生成するスクリプトを実装すべきだわ。
HTMLコンパイラとは、一般的な「コンパイラ」の概念とは少し異なり、HTML文書や要素に対して新しい文法や振る舞いをブラウザに伝え、拡張するための仕組みを指すことが多いです。例えば、AngularJSのHTMLコンパイラは、開発者が定義したカスタム要素や属性（ディレクティブ）を解釈して、動作を紐づける役割を持ちます。これにより、標準のHTMLにはない独自の文法や機能をブラウザ上で実現できます。
一方、一般的な「コンパイラ」は、人間が書いたプログラムコードをコンピュータが理解可能な機械語や中間言語に翻訳するソフトウェアや処理のことです。この処理を「コンパイル」といい、プログラミング言語で書かれたソースコードを一括で変換し、実行可能な形式にします。コンパイラと対比されるのが「インタプリタ」で、こちらはソースコードを逐次読み解いて実行する方式です。
まとめると、「HTMLコンパイラ」はHTMLの静的な宣言文法を拡張し、新たな振る舞いを実現するものであり、主にフロントエンドフレームワーク（例：AngularJS）で用いられます。一方、「コンパイラ」はプログラムコード全般を実行可能な形式に変換する処理・ソフトウェアです。
https://ja.taiwebs.com/windows/download-html-compiler-2548.html
フロントエンドフレームワークで、新しいHTML要素や属性を作成するために用いる。
そのフレームワークがHTML文書の解析時にカスタムディレクティブやテンプレートを解釈し、動的な振る舞いを紐付ける。
今時点の使えそうな 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という動的な土台との互換性を最優先した」という、その成り立ちそのものにあります。その結果として生じる「不健全さ」「構造的部分型の罠」「漏れのある抽象化」といった問題は、この言語を使い続ける限り、アーキテクトが向き合い続けなければならない、本質的なトレードオフなのです。
Metalの登場以前は、macOSにはOpenGLが、そしてiOSにはOpenGLESがそれぞれ提供されていたが、いずれも高度にハードウェアが抽象化されていることから性能上のオーバーヘッドが大きい。Metalは以下のような理由から、OpenGLよりも優れたパフォーマンスを期待できる[9]。
シェーダーの事前コンパイルおよび最適化や、前もって実行されるステートの結合と評価（Validation）
これらのうちいくつかは、GPUでコマンドを実行するために必要になるCPUのタスクを低減する。そのため、他の仕事のためにCPUを使えるようになり、全般的なパフォーマンスの向上につながる。
つまりバイブコーディングってやつ、AI議論になるとこういう真のプログラマーしか生き残れなくなるだろうみたいなこと言う人いるよね
ちゃんと理解してないと責任を取れないよねとか急に意識高い感じのこと言うじゃん
でもじゃあ世間のプログラマーさんはコンパイルされたものを理解できてるんですか？って思っちゃう
そこはコンパイラーに丸投げだろ？
バグがあったら、いざとなったらOSSのコードを調べてみたいな事やってるバキバキのエンジニアなんて何人いるよ
昨今のClaude Codeの盛り上がりを見て、自分も先週から使い始めた。
使い始めてすぐに、「確かにこれはすごい。開発体験が変わりそうだ。」って思った。でも同時に、「自分が気持ちよく開発するためにAIを使っているのに、AIが気持ちよく開発するための奴隷になってない？」と感じる部分があった。
例えば、自分はWindowsPCを使っているので、WSL上にClaude Code環境を構築している。ClaudeにJavaのプログラムを生成してもらっていたとき、Javaの実行環境はWindows側にしかなかったので、Claudeが提案・実行したコンパイル用コマンドはWSLでは動かなかった。
そこで、Windows側にあるJavaを呼び出すバッチファイルを用意し、「コンパイルする時は、このバッチファイルを使ってください」と、CLAUDE.md に説明を書いた。
このとき、「今の自分って、AIがスムーズに開発するためのガードレール整備しかしてなくない？」って感じてしまった。
確かに、プロダクトを作るスピードは信じられないぐらい早くなっていて、「とにかく早くものを作るためにClaude Codeを使う」と割り切ったら、最高の開発体験を提供してくれると思った。
でも、純粋にプログラムを書く楽しさみたいなものはなくなっている気がした。そのうち慣れてくるのかな。
