aqqnucs 2026-01-08 | 親コメント | トピック: Cが最良だ(2025) (sqlite.org)

いや、しかも文章そのものも書かれたのは7年前なんですね? その後ろに内容を付け足しながら、2025年に一部更新された感じみたいですが……🤦

 
aqqnucs 2026-01-08 | 親コメント | トピック: Cが最良だ(2025) (sqlite.org)

タイトルが刺激的すぎますね。元の記事を見れば、なぜ C が SQLite の開発に最も適しているのかについて書かれた文章だと分かります。皆さん、どうか怒りを鎮めてください

 

これは本当にDOOMですね。

 

皮肉ですね。AIの支援を受けるために書くドキュメントが、収益を吹き飛ばしてしまうなんて..

 

Tailwindに限らず、UIライブラリやフレームワーク全般に当てはまる話のように思います。AIは抽象化を理解せずに、全部作れてしまうので……

 
wahihi 2026-01-08 | 親コメント | トピック: Cが最良だ(2025) (sqlite.org)

さまざまな開発状況に適した言語を使う、そういう判断ができることが重要なのであって、特定の言語が常に優れているかのように、ああいうタイトルを付けるのは、思考のレベルが中卒だ……

 

とても印象的な文章でした。おかげで楽しく読めました!

 

私もChatGPT登場前にTailwind UIを購入した後、有用に活用していた経験があります。

AIの発展によってビジネスモデルが破壊されるのは避けられないと思いますが、オープンソースのエコシステムに貢献する企業が一社ずつ揺らいでいくのは残念ですね。『伽藍とバザール 2.0』の時代では、伽藍が勝つことになるのかと思ってしまいます。

 
m00nny 2026-01-08 | 親コメント | トピック: Cが最良だ(2025) (sqlite.org)

Cの最大の長所は、「コンピュータはビット列である」という本質にそのまま触れている点にあると思います。Cの単純な哲学と過激な reinterpret casting によって、ユーザーはほとんどの場合、それがどのような機械語に翻訳されるかを把握できるという魅力があります。あらゆる言語から呼び出せるのはCだからではなく、呼び出し可能なのはABIであり、Cでは単に入出力がどのようなビット列なのかを予測しやすい(あるいはそうであるべき)からなのでしょう。常に実装可能性について議論するときにも、これがチューリングマシン上で不可能なのか、それとも今使っている言語やフレームワークで不可能なのかを区別することが重要だと思います。

 

Tailwind のサイトを見てみると、スポンサーとして一番上に Cursor がありますね。
AI企業からスポンサー支援を受けているのに、AIのせいで収益が減っているという皮肉ですね……。
ともかく、うまく乗り越えられることを願っています。

 

再インストールを勧めてくるソフトで動かせば大丈夫です

 

https://support.logi.com/hc/en-us/…

ガイドが出ました。ちくしょう!!!!!!

 

インターネット接続ができないと水が出ない浄水器を思い出しますね。

 

ああ、自分だけじゃなかったんですねwww いやもう、親指ボタンの動作を返してくれぇぇぇぇ

 

あのドゥームじゃなかったのか

 

ああ、お願いだから会社にこの記事を見つけられませんように

 

その記事のコメント欄に、さらに面白い内容がありますね。

emerge - insights : com.google.Gmail を見ると、オレンジ色の言語ファイルが 151MB(24.56%)を占めています。

Emerge Toolsのsize analysisを使って主要なメールアプリのバイナリ構成と容量の無駄が発生している箇所を比較分析してみた

[0] Fastmail

  • 比較対象の中で 最も小さいアプリ
  • オーディオファイルの最適化だけでも アプリサイズを約20%削減可能
  • アプリ構成の 71%がバイナリ
  • X-ray 可視化を見る

[1] Gmail

  • 容量増加の主な原因は ローカライズファイル
  • アプリ構成比: バイナリ 60%ローカライズ 24%
  • X-ray 可視化を見る

[2] Outlook

  • バイナリのシンボル除去(strip) によってかなりの容量削減が可能
  • アプリ構成比: バイナリ 65%ローカライズ 14%
  • X-ray 可視化を見る

[3] HEY

  • 重複排除 + 画像最適化 だけで 約15%の容量削減が可能
  • アプリ構成比: バイナリ 45%アセット 27%
  • アセット比率が通常より高いと指摘
  • X-ray 可視化を見る

[4] ProtonMail

  • 画像最適化と重複排除だけで 約30%削減可能
  • アプリ構成比: バイナリ 58%アセット 14%ローカライズ 7%
  • X-ray 可視化を見る

追加事例: Spark

共通の結論

  • 分析されたほぼすべてのアプリで 少なくとも20%以上の「簡単な」容量削減ポイントが見つかった
  • X-ray 可視化で 赤色は重複ファイル を意味する
  • 多くのチームが アプリ容量の監視をまったくしていないことが一般的な問題
 

100%正確であるためには、ある意味では読心術の領域になるのでしょうが、
99%正確であるためには、統計の領域になるのでしょうか。
大きな課題ですね。

 

Opus 4.5 に1行のコードを直すよう頼んだら、そのコードの上にあった設定コードを10行ほど勝手に消していて、なぜ消したのかと聞いたら、ただ意味のないコードだと思って消した、と…。