なんか、ライターに優しいブログプラットフォームの最新進化って感じだよね。Wordpressよりもニュースレターにまとめるのが簡単だし、有料プランでマネタイズもしやすい。

そうそう、Mediumは最初は無料でみんながコンテンツを提供してたのに、急に有料の壁を作ってみんなを騙したよね。そこでまだ書いてる人を見ると驚くわ。

おそらく、慣習が影響してるんじゃないかな。ブランドに忠実な人がいて、他の人がやってることに合わせようとする。実際には、どこに投稿しても関係ないし、URLさえあればいいんだけど、そう考えない人もいるんだよね。

作家に報酬を支払おうとする真摯な試みがあったね。これはsubstackとは違うモデルだけど、その理由も分かる。新聞の有料壁と同じように見てるよ。好きじゃないけど、なぜそれがあるのかは理解してる。

読書体験がひどい ブラウザで読んだものは、誰にとっても最高の読書体験を提供することはできないよね。現代のウェブモデルはそれに反してるから。CSSのないプレーンなHTMLページは、ほぼ完璧な読書体験だと思う。でも、ほとんどの人がそれを提供しないんだ。ウェブは著者が注目を競う出版プラットフォームになっちゃったからね。ユーザーがコントロールできるプレーンテキストプロトコルが「誰にとっても最高の読書体験」に近いんだ。ウェブはそうなれるはずなのに、ほとんどそうなってない。長い記事をブラウザで読むのはやめたよ。なぜなら、関連するプレーンテキスト（構造化されたものも含めて）を簡単に抽出して、自分のエディタで読むことができるから。フォントや色、ナビゲーションを自分でコントロールできる場所でね。ブラウザは配信の手段であって、読書環境じゃないんだ。それを読書環境として扱うのは習慣であって、必要ではない。ずいぶん前から、エディタ以外で三語以上のものをタイプするのはやめたよ。もちろん、なぜやらないのかって？エディタには必要なものが全部揃ってるからね—スペルチェック、類語辞典、語源検索、翻訳、ノートへのアクセス、LLM統合など。いつか試してみて、すごく解放感があるから。そしたら、ブラウザで長いテキストを読むのもやめるかもしれないよ。

Scribeっていう代替のメディアフロントエンドをチェックしてみて、こっちの方がずっといいよ！: https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code... https://sr.ht/~edwardloveall/Scribe/ https://libredirect.github.io/

AIやMLライブラリのサポートは確かに重要だよね。最近はバックエンドの仕事でRustやTSを使うことが多いけど、Djangoファンなのにね。

ほとんどいつもRustを選ぶかな。最近、Goで書かれた何かのプラグインを作ったんだけど、Rustも使えたけど、Goの方がしっくりきたんだ。もしうまくいったら、他の人も一つのツールチェーンを持つことに価値を感じるだろうし。主な理由は、必要な時に読めるからだよね。受け手のエコシステムも言語を期待してるし。だから、データサイエンスコミュニティがRやMatLab、Julia、Python、Mojoを選ぶのは、技術の優劣じゃなくて、仲間が使ってる言語によるんだ。

そうだね、もしPythonエコシステムから離れてAIに依存関係を管理させるなら、RustよりもOCamlやF#に全てシフトした方がいいかも。そうすれば、GCや強い型付けの利点も得られるし。

AIと一緒に型システムを強制するのはいいことだと思う理由がいくつかあるよ。- （推測だけど）型付き言語は、ツールを使ってコードを効率的に修正できる速くて良いLSPを持ってる。- 人間がコードを調査したり修正したりする必要が出てきたとき、強い型付けがあれば、スパゲッティコードの中で方向を見つけやすくなるんだ。

使い道は、MLライブラリみたいな低レベルのC++ライブラリをラップする時だけだと思う。あれは再現するのがめっちゃ難しいしね。

Pythonや他の非厳密型言語の問題は、LLMに何かを書かせると、本当に何も壊れてないか自信が持てないことだよ。テストが全部通ってもね。LLMが本番環境で特定のケースでしか実行されないパスを壊してしまう可能性がある。少なくとも、強い型付けの言語ならコンパイラエラーが出るから、ビッグコードベースではそれが譲れないポイントだよ。

SWE-Benchがプログラミングのターゲットベンチマークだから、ほとんどがPythonなんだろうね。

逆のことを感じてるよ。コードがちゃんと動くようにしたいなら、LLMはPythonよりRustみたいな言語の方がずっとマシだと思う。確かに、テストを一つ通すだけで良いならPythonでもいいけど、実際に作ったものを使ってみると、ただ作るだけじゃない何かが必要だって気づく人が多いんだよね。

Rustを書いてみたことある？試したことない人からよく聞くけど、俺はPythonより全然問題ないし、すべてが100倍うまく動くよ。

以前、ICとして働いてたときは、Golangをたくさん書いてた。エンドツーエンドで暗号化されたビデオ通話サービスの大規模なプロジェクトに関わってたんだけど、めっちゃ嫌だった。毎日何度もif err != nilに悩まされて、Rustのことばかり考えてた。LLMを使って数時間経った今、考えが変わったよ。優秀なエンジニアチームを持つ5人のクライアントがいるけど、PythonやTypescriptを使っても一貫した結果が出せないんだ。結局、Golangがシンプルで一貫性があって、トレーニングコーパスにうまく表現されてることに気づいた。普通のプログラム（ファイルの読み書き、ネットワーク、DBなど）を書くなら、特にGolangを選ぶべきだよ。使ったことがないならなおさら。LLMはそれが得意だから、イライラするほどね。 [1] https://jry.io/writing/use-boring-languages-with-llms/

正直、Mojoがこのレースのダークホースだと思ってる。もちろん、すべてのロードマップの目標が達成される前提だけどね。C++並みのパフォーマンス、Pythonの文法、Pythonとの完全互換性、AIとインターフェースするように最初から設計されてる、Zigのようなコンパイル時メタプログラミング、その他いろんな特典があるんだ。だから、GoやRustを褒めるのは自由だけど、AIのためにそれらを学ぶのは、すでに他の言語に堪能ならあんまり良いアイデアじゃないと思う。ちなみに、Lattnerは俺のプログラミングヒーローの一人だから、ちょっと偏ってるかも。

^ 評価されてない返信だね。

言語芸術こそが、私たちの脳を使う唯一の建設的な方法だよね。神経科学が言語は認知的問題解決とは関係ないって主張してるのは無視して。頭や木を切り開いてみて、言葉はどこにあるの？君の心は、言語なしで空間的な問題を解決する電気的なテンソルなんだ。読み書きできる人たちは、数学の王や構文を理解してるのがスーパーパワーだと自分に言い聞かせてるけど、物理学は実際のスーパーパワーを与える気はないみたいだね。

君はバカにしてるけど、モデルは先月よりずっと良くなってるし、トークンコストも下がってるよ！LLMは脳のためのコンパイラみたいなもんだ！/s

トレーニングデータにおけるプログラミング言語のメタテーシスについて書いたよ。ここにあるよ。https://jry.io/writing/use-boring-languages-with-llms/

それに、どんなインタープリターエラーにも、StackOverflowみたいな修正提案がたくさんあるし、モデルは初回のエラーを最小限に抑えるように調整されてるんだ。もっとマイナーな言語ではこれができてない。問題がテスト入力/出力で完全に検証できる場合でも、動作する出力を得るためには、平均してもっと試行回数が必要になるだろうし、もし検証できない場合は、モデルの「注意」が解決策ではなく構文に向かうのは避けたいよね。

トレーニングデータだけが全ての答えじゃないよ。LLMは異なるプログラミング言語への翻訳が得意なんだ。これは、テキスト翻訳システムから派生しているから納得できる。比較的少ない自由に使えるコードがある言語では、いい結果が出てるよ。大きなハードルは、LLMがターゲット言語の一般的な慣用句をコピーしがちなことで、「エンタープライズ」系の言語、例えばJavaやC#だと、無駄なボイラープレートが急増する危険があるんだ。結果が使えるコンテキストウィンドウのサイズを超えてしまって、品質が落ちることもある。

それは、AIにオープンループでコードを生成させる場合には重要だね。おそらく誰かがPythonで君が求めたものに近いものを書いてるだろうから。でも、エージェントがコードを生成して、コンパイルを試みて、詳細なエラーメッセージを見て、そのメッセージに基づいてコードを改善するなら、より高品質な結果が得られるよ。rustcは本当に良い診断を出すし、今はオンラインにたくさんのRustコードがあるけど、PythonやJavascript/Typescriptの方が圧倒的に多いんだよね。

AIを使ってbrainfuckで書けるけど、Pythonでやるのとは同じ結果にはならないだろうな。 https://esolang-bench.vercel.app/

もうGoを使っちゃいなよ。LLMはそれをたくさん見てるし、上手に書けるし、ほぼ瞬時にコンパイルされるし、型付きコンパイル言語の利点も全部あるよ。AIを使って大きなPythonコードベースを作ったけど、LLMは常に引数や辞書のフォーマットを間違えて推測するんだ。ユニットテストやpydanticみたいなものは役立つけど、そういうランタイムエラーのクラス全体を避ける方がいいよ。

確かに、LLMを使ったPythonの経験はほとんどないんだ。でも、プレーンなJavaScriptと比べてTypeScriptを使ったときの出力品質のひどい劣化を見てるから、今Pythonでプロジェクトを始めるなんて考えられないな。

驚くことに、LLMはエージェント的なコーディングタスクにおいてPythonよりも他の一般的なプログラミング言語での推論がずっと下手なんだ。データはこちら: https://gertlabs.com/rankings?mode=agentic_coding

プログラミング言語を作ったんだけど、LLMはそれでめちゃくちゃ上手にコードを書くんだ。トレーニングセットはあんまり関係ないと思うよ。だって、彼らのトレーニングセットに俺の言語が入ってるわけないし！プログラミング言語って、結構共通点が多いんだよね。Pythonは、言語としてはちょっと変わってる気がする。

俺には、これらのLLMはPythonとRustのトレーニングデータが十分にあるように見えるから、Pythonには特にアドバンテージはないと思う。だから、記事が指摘してるように、コンパイル時にミスをキャッチする反復プロセスの方が、ランタイムでキャッチするよりAIには向いてるよね。

それは、彼らが置き換えようとしているElectronアプリよりも怖いものはないかもね。

なんで？12〜18ヶ月で転職すれば、あとは他の人の問題になるよ。

これ、AIが登場する前にもあったんだよ。10年前に誰かがランダムな言語で重要なツールを書いて、残りの俺たちがそれをメンテナンスする羽目になったんだ。なんとかやりくりしたけど。

これには全く同意できないな。多くの雰囲気コードのワークフローのアイデアは「人間はコードを読む必要がない」ってことだから、人間の開発者の使いやすさは関係ないってことになる。でも、このブログ記事は明らかに人間を対象にしてるから、人間の読者の使いやすさはまだ関係あるよ。

AIはロジバンで訓練されてないよ。それに、この文章はほぼ確実に人間が直接読むために書かれてると思う。君が冗談を言ってるのはわかるけど、プログラミング言語に関して何を言いたいのかはよくわからないな。

君はロジバンを使わせようとしてるの？

あ、ロジバンのことは聞いたことなかったな。面白いプロジェクトだね！経験則だけど、言語が思考に与える影響は多くの人が思ってる以上だと思うから、論理的な言語はいいアイデアだと思う。人を「論理的に」考えさせる「トリック」になるかもしれないし！誰か実際に話してくれる人を見つけないと！