Tencentが開発したAutocodebenchというベンチマークを用いて、各種プログラミング言語がAIモデルにとってどれほど扱いやすいかを検証した結果、意外な言語が上位にランクインした。一般的な予想ではRustやTypeScriptが優位と思われたが、実際にはElixirが97.5%という驚異的なスコアを記録し、C#も88.4%と高得点を獲得している。この結果から、AIにとって優れた言語の条件として、シンプルさ、トークン効率、学習データの量と質、フィードバック機構、そして特に重要な要素として充実したドキュメントとコードとの密接な統合が浮かび上がる。Elixirが高評価を得た理由は、独自のパイプライン記法やパターンマッチング、immutabilityといった言語特性に加え、Hex Docsという統一されたドキュメント生成システムによって、すべてのパッケージが高品質なドキュメントを持つ点にある。コードとドキュメントが同一ファイル内に共存することで、LLMがコンテキストを把握しやすくなり、正確なコード生成が可能になるのである。
プログラミング言語論争の新たな視点
私たちプログラマーは、どの言語が最高でどれが最悪か、どれが速くてどれが遅いかといった議論が大好きですよね。でも、AIにとって最適な言語は何でしょうか。実は、それはポーランド語なんです。いやいや、私たちが話したいのはポーランド語や自然言語のことではありません。プログラミング言語についてです。
さらに明確にしておくと、AI向けに作られたプログラミング言語の話でもありません。NanolangやNerdのような言語はすでにいくつか存在していますが、それらがどれほど素晴らしくても、実用レベルにはまだ到達していません。私が話したいのは、私たちが日常的に使っている実際のプログラミング言語についてなんです。
Autocodebenchは、Tencentが作成したベンチマークで、異なるモデルが異なる言語でどのようなパフォーマンスを発揮するかを評価するために特別に設計されています。彼らの目標は、どのモデルが特定の言語に最も適しているかを把握することでした。でも、私たちは別の方向からアプローチできます。これを使って、モデルがどの言語で最高のパフォーマンスを発揮するかを見ることができるんです。
結果は本当に興味深いものでした。私が最初にこれを見たのは、友人である言語の作者が見せてくれたときで、私たちは二人とも信じられないという顔で立ち尽くしていました。非常に興味深いベンチマークです。非常に興味深い結果があり、それには非常に興味深い意味合いがあります。どの言語が最高だと思っていても、すでにこれを読んでいない限り、ほぼ間違いなく違うはずです。
ネタバレですが、私が望むほどTypeScriptではありません。そして信じられないかもしれませんが、Pythonでもないんです。今日のスポンサーからの簡単なメッセージの後、このベンチマークでトップに立っている言語とその理由についてお話しできるのが待ちきれません。
AIコードレビューの重要性
今日のスポンサーはGraptileです。最高のAIコードレビューツールの一つなんです。この話、聞いたことありますよね。AIはコーディングが得意で、コードレビューはさらに得意だと。分かります。でも今日は少し違うことをしたいんです。チームからの許可も得ていないのですが、彼らがこれで大丈夫だといいなと思っています。放送前にレビューしてもらうので、彼らのやり方次第ですね。
とにかく、これは彼らがAIコードレビューバブルについて投稿したばかりのものです。これは私にとって非常に興味深く、触れる価値があると思いました。なぜなら、他の多くの企業が既存のツールの一部としてAIコードレビュー製品をリリースし始めているからです。CognitionやLinearなどですね。そして私は彼らの見解が本当に気に入っています。
Graptileのベンチマークでは彼らが最高だと言っていますが、これらすべての企業のベンチマークでは、それぞれが最高だと言っています。これについてもう少し深く話さなければなりません。彼らが触れている最初の大きなポイントは独立性です。レビューエージェントはコーディングエージェントとは別であるべきだと強く信じています。私たちは独立したコード検証エージェントの重要性について意見を持っています。何度も要望がありましたが、コード生成機能を提供したことは一度もありません。私たちはコードを書きません。
カワウソは帳簿を準備しません。キツネは鶏小屋を守りません。学生は自分のエッセイを採点しません。今日のエージェントは、問題を見つけて基準を適用する点で、平均的な人間のコードレビュアーよりも優れています。そして、どんどん良くなっています。将来的には、企業のコードの大部分がコードレビューエージェントによって自動承認されることは明らかです。
言い換えれば、人間がチケットを書き、エージェントがPRを書き、別のエージェントがそれを検証、承認、マージするという事例がいくつか出てくるでしょう。これは狂気じみていて、私は決して信じなかったでしょうが、自分でやり始めたんです。
彼らはフィードバックループについて少し話しています。GraptileにはClaude Codeプラグインがあるからです。本当です。プラグインは、コードを書いた後にコーディングエージェントにフィードバックを与えるように設定できます。そしてレビューが来ると、フィードバックがなくなるまで何度も何度もフィードバックに対処します。そして、どこかで曖昧さがあれば、エージェントが人間にSlackで確認を求めます。これってどれだけクールか分かりますか。フィードバックとレビューを受けている場合、特に異なるハーネスや異なるモデルから来ている場合、どれだけ長くエージェントを実行できるか分かりますか。
私はローカルのレビューツールを試しましたが、それほど良くありませんでした。Graptileのコードベース理解は深いです。PRで触れられていない多くのファイルから物事を指摘するのを見たことがあります。なぜなら、コードベースを理解しているからです。これをコーディングエージェントと組み合わせると、想像以上に速く反復できます。
BrexからScaleからPostHogまで、みんなが彼らを使っているのには理由があると思います。彼らは本当に理解しているようです。そして私の経験から言うと、確かにそうです。Graptileは私がバグを出荷するのを止めてくれました。彼らにあなたのバグも止めてもらいましょう。
優れたプログラミング言語の条件
AIにとって最適な言語が何かを判断する前に、優れた言語とは何か、そしてもちろん、AIにとって優れた言語とは何かから始めるべきでしょう。では、優れたプログラミング言語とは何でしょうか。これは本当にシンプルな質問で、誰も矛盾する意見を持っていないと確信しています。優れたプログラミング言語とは何か、どんな理論があるか見てみましょう。
Kotlinが良いプログラミング言語を作るようです。型、型安全性、シンプルな構文、可読性、エラーハンドリングなし、Goよ永遠に、たくさんのトレーニング例、優れたコンパイラ、Apple、美しさ。おお、YouTubeから。YouTubeは実際ここで良いプレーをしています。パターンマッチング。これは私が大好きなものです。良い機能ですね。人間の可読性。シンプルさプラス機能性イコール洗練。どれだけ速いんだよ、ブロ。Rustと呼ばれているなら、良いドキュメント、絵文字対テキストの比率。ほとんどの言語はここで特にひどく苦しんでいます。
変数や値を絵文字として定義できる言語がいかに少ないかに失望しています。非常に残念です。高階型、マクロ、ファンクター、デコレーター、集中化されたツール、標準ライブラリ。興味深い。ここから、人間にとって優れたプログラミング言語を作る一つのことを確立できればと思います。人間がそれを気に入っているということです。
これが実際のところです。悲しいことに、プログラミング言語をもっと意味のある方法で評価できればいいのですが、残念ながら人間はそれを許してくれません。私たちは自分の信念を言語全体に投影し、それらを使って評価するため、測定できる範囲を超えた好みを持っています。
Joelがチャットで言ったように、あなたが好きなら、それは良いワインです。その通り。ですから、私たちにとって良い言語とは何かについて話すとき、当然ながら自分自身の好みがバイアスとして入り込みます。では、次のバージョンの質問、つまり私たちが気にしている質問をしてみましょう。LLMにとって優れたプログラミング言語とは何でしょうか。モデルが特定の言語で優れているようにする特性や特徴は何でしょうか。
シンプルさ、型、LSP、トークン効率、これは興味深いポイントですね。発音もしない単語。簡潔な構文、高い冗長性、それは矛盾している気がします。ベクトル空間、Cスタイルの構文、どれだけのトレーニングデータで訓練されたか、言語におけるトレーニングデータの質、AI内にどれだけのデータがあるか、そして構文がどれだけ具体的で明確か。
ここにはいくつかのテーマが見えています。シンプルさ、トークン効率、トレーニングデータの量、フィードバックメカニズム、つまり型安全性です。他に重要だと思うことはありますか。構文がどれだけユニークか。それは興味深いですね。もう一つ、トレーニングデータにクソみたいなコードがたくさん含まれていないこと。つまり、トレーニングデータの量です。
その下にトレーニングデータの質と書いておきます。Closureです。必須の戻り値型。パターンが他の言語とどれだけ似ているか。均質性は確かに有用な価値だと思います。他のものとどれだけ似ているかということですね。では、いくつかの言語を取り上げて、これらに照らし合わせて、どのようにランク付けされるか見てみましょう。
JavaScriptはシンプルさでE、いいえ。トークン効率では間違いなくいいえ。トレーニングデータの量では、そうですね、これにはたくさんのトレーニングデータがあります。そのトレーニングデータの質は玉石混交。フィードバックメカニズムはゼロ。JavaScriptはおそらくあまり良くないでしょう。トレーニングデータは膨大なので、トレーニングデータが圧倒的に最も重要だと考えるなら、大量にあるし、JavaScriptはかなり良いはずです。ですから、これらをどのように重み付けするかによって、トップ付近か底辺付近かになります。
TypeScriptは全体的に似ています。TypeScriptのトレーニングデータは質がやや高いと主張します。そして、フィードバックメカニズムは非常に重要です。なぜなら、型安全性はコンパイラでチェックでき、モデルにフィードバックを与えることができるからです。それゆえ、TypeScriptの方が良いパフォーマンスを発揮すると予想します。
Pythonは興味深いですね。おそらく最もデータが多く、それを機能させるためのインセンティブもラボから最も多い。なぜなら彼らはPythonをたくさん使うからです。しかし、型安全性については合意がありません。それを行う方法はたくさんあり、すべてがダメです。Pythonにはクソみたいなデータがたくさんあり、フィードバックメカニズムはゴミです。ですから、おそらく玉石混交でしょう。
Javaは間違いなくシンプルさやトークン効率をすぐには達成しません。おそらくかなりのデータ量があります。おそらくまともな質のデータです。フィードバックメカニズムは素晴らしくはありませんが、最悪でもありません。一応チェックされていますからね。確かに。
C++は、トレーニングデータの量以外のすべてでストレートゼロを獲得する唯一のものだと思います。たくさんのトレーニングデータがありますが、シンプルな言語ではありません。トークン効率の面では程遠いです。そのデータの質は滑稽なほど様々で、フィードバックメカニズムは、システムをクラッシュさせたかどうかです。頑張ってください。
Cはおそらくこれらの点でずっと良いでしょう。さて、もう一つ追加します。重要だと思うこと、ドキュメントです。そして、アクセスのしやすさと書きます。ドキュメントがどれだけ良いか、どれだけ簡単にアクセスできるか。
公平を期すために、これまでのすべてにおいて、ドキュメントアクセスの答えはクソです。Cではかなり良いです。C#のコミュニティ、エコシステム、.Net周辺のフレームワークは、世界で最高のドキュメントの一部を持っています。言語が好きかどうかは別として、この点では非常に優れています。
Rubyはどうでしょうか。正直なところ、ドキュメントではRubyはかなり良いです。フィードバックメカニズムでは完全にクソです。トレーニングデータの質では、あまり良くありません。トークン効率では、まあまあです。シンプルさでは、まあまあかもしれませんが、Railsがそれを台無しにしました。まあまあかもしれません。知っていることから判断すると、おそらくPythonやJavaより上ですが、分かりにくいですね。
Elixir、私の愛する言語です。シンプルか、人によります。トークン効率は、まあまあそうですね、おそらくRubyと同様でしょう。トレーニングデータの量は、非常に非常に少ないです。トレーニングデータの質は、少し思い上がって言いますが、私が知っているElixir開発者は皆、私が知る中で最も賢い人たちです。ですから、そのデータの質は非常に高い可能性があります。
フィードバックメカニズムは、クソゴミです。彼らはまだ言語に型安全性を導入しているところです。それにはまだ遠いですが、そんなに遠くもありません。非常に近いうちに来ます。でも、それを理解するツールさえも時間がかかるでしょう。ドキュメントの世界では、素晴らしいです。
Golangは、シンプルすぎるほどシンプル。トークン効率は絶対にいいえ。トレーニングデータの量はまあまあ。データの質はまあまあ。フィードバックメカニズムはゴミ。ドキュメントはまあまあ。
Rustはシンプルさでいいえ。トークン効率でいいえ。トレーニングデータの量はまあまあ。トレーニングデータの質は非常にまあまあ。フィードバックメカニズムは世界クラス。コンパイラから得られる最高のフィードバックです。モデルよりもコンパイラが遅くてもです。ドキュメントは非常に良いです。
ここで言ったことだけから判断すると、Rustがトップ付近にあると推測します。データ量は重要です。だから、TypeScriptもかなり上位にあると推測します。Cもおそらくかなり上位でしょう。Goはフィードバックメカニズムがないことは知っていますが、データとデータの質とドキュメントがかなり助けになるでしょう。C++はトップ付近にはなりません。Pythonは彼らが気にしすぎるから。Rubyは存在して、たくさんあるから。おそらく良い例がたくさんあります。JavaScriptは例がたくさんあるから。Javaは十分な数の例があるから。C++は明らかに最下位付近。
もう一つ何を見逃していますか。そうだ、JSです。ああ、Elixir。うーん。Elixirはここでどこに収まるでしょうか。難しいですね。本能的にRubyのすぐ下だと言いたいです。ElixirがRubyに非常に似ているが人気が低いという性質上。これはすべて理にかなっています。私たちが持っているバイアスと、優れたプログラミング言語を作るものについての考えを考えると、Rustは明らかにトップ付近にあるべきです。C++は明らかに底辺付近にあるべきです。確かに。
驚きのベンチマーク結果
ネタバレですが、これは事前に読んだものです。私はすでにここでの結果を見ており、私たちが予想するものとはかけ離れています。言語ごとの平均でここでの結果を見ると、Claude Opusが1位です。そして、より最近のバージョンを見ると、Claude Opus 4.5 thinkingが圧勝しました。全体として、Opusがこのベンチマークで最高の言語です。5.2をやったようには見えません。そして、彼らがこれを行った時点では5.2 Codexは出ていなかったので、それがどう比較されるかはまだ分かりません。おそらくかなり良いパフォーマンスを発揮するでしょう。
でも、私たちはどのモデルが最高かを見るためにここにいるのではありません。私たちは言語のためにここにいます。それがこのセクションです。これは彼らが用意したすべての問題に基づくスコアです。ほとんどの言語は、185から200の間の似たような数の問題がありました。そして、トップの言語は私たちが予想したものではありません。
私たちはRustとTypeScriptだと思っていました。RustとTypeScriptの数字はそれぞれ、Rustが61%、TypeScriptが61%です。ほぼ同じスコアで61.3%です。私たちが非常に良いと思っていた言語はそうではありませんでした。
でも、Javaのような他の興味深いものがあります。78.7%を獲得しました。Rustよりも意味のある高いスコアです。おかしいですね。C++は74.7%。TypeScriptよりも意味のある良さ。さらにおかしい。そしてC#は88.4%です。
でも、実際に画面を見ているなら、すべての人が見ているわけではないことは知っていますが、私が隠そうとしているものを見逃したかもしれません。私の大好きな言語、私の愛するElixirが97.5%を獲得しました。すごいですね。
Elixirの素晴らしさ
私はこのビデオ全体を、あなたたちを騙してElixirについて少しの間ラントさせるためにやったのでしょうか。ある意味そうです。そして、あなたたちをここまで連れてきたので、それをする権利を得たと思います。だから、今からそれをします。
Elixirは素晴らしいプログラミング言語です。私はそれを心から愛しています。プログラマーとして生産的だと初めて感じた言語でした。その結果、私は非常に生産的になりました。とても生産的だったので、本当にクールなことをたくさんやりました。結局、かなりワイルドなキャリアを得て、会社を始めました。そして今、私はTypeScriptの人として知られています。
でも信じられないかもしれませんが、私の心はTypeScriptにはありません。私の人生はTypeScriptにあります。私の仕事はTypeScriptにあります。私の心は常にElixirにあります。Jose Valimは私の個人的なヒーローです。私はあの人をとても愛しています。彼がいなければ、今日の私というプログラマーは存在しなかったでしょう。
私がElixir Confで行った講演のビデオ全体があります。Elixirがどのように今日の私をエンジニアにしたかについてです。私はこの言語が本当に大好きです。Elixirについて好きなことはたくさんあります。言語そのものについて話します。それがElixirを書くときに体験することだからです。
パイピングのようなもの。とても良いです。ターミナルでやるのとほぼ同じ方法でパイプするだけです。そうすると、変数や関数である前の戻り値を取得し、それを最初の引数として次のものにパイプします。ここでは、文字列を取って、それをグラフェムに分解し、その文字列から各値の頻度を測定します。
ここではEが1回、Iが2回、Lが1回、Rが1回、Xが1回出現していることが分かります。これは、たくさんのランダムな変数を保存してすべてを追跡する代わりに、これを書く非常にエレガントな方法です。これを考える一つの方法は、データが通るパイプラインが、あなたがエンコードしているものだということです。存在するさまざまな値ではなく。
このパターンは非常に強力です。特に、Elixirでできる他の本当にクールなことの多くと組み合わせると。Elixirで私の大好きな機能の一つは、オーバーロードでのパターンマッチングの動作方法です。引数がチェックとして定義された同じ関数を何度も再定義できます。
関数の引数を定義するとき、他の言語でやるように型付けしません。JavaScriptやTypeScriptでは、この関数はオブジェクトを受け取ると言います。それには文字列であるnameと、数値であるageがあります。Elixirでは、マッチする特定の値を定義できます。そして、同じ関数の3つのバージョンがある場合、引数にエンコードされている値に基づいてマッチします。
ここにはフィボナッチ関数があります。フィボナッチ関数は4回再定義されています。この最初のものはゼロとして定義されています。だから、ゼロでfibを呼び出すと、これが最初にヒットします。だからゼロを返します。1で呼び出すと、これがヒットして1を返します。nが整数で2より大きいときにnでそれを呼び出すと、これを実行します。ここでnマイナス1とnマイナス2で同じものを呼び出します。
これらのケースを処理するために関数内でif文を行う代わりに、それらのケースを介して関数を定義しています。そして、ここにフォールバックがあります。これは他のものがキャッチされない場合にキャッチするものです。なぜなら、これが言語とVMによって評価される方法は、一度に一つずつこれらを通過するからです。
呼び出そうとしている関数の値を取り、その値がこれとマッチするかどうかを確認します。マッチしない場合、次のものをチェックします。マッチしない場合、次のものをチェックします。マッチしない場合、この次のものをチェックします。とてもクールです。とても読みやすいです。理解しやすいです。複雑なロジックのために深くネストする必要がなくなります。
そして、これでできる小さなことがたくさんあります。ユーザーがサインインしていない場合、またはユーザーが管理者の場合のチェックアウト関数を再定義できます。チャットで本当にバカなことを言っている人がたくさんいます。静的型付き言語のコンパイラがこれを行えると。Rustはこれを行えると。Haskellはこれを行えると。
はい、Haskellはこのようなことをある程度行えます。でも、このような引数の期待をマッチングするというアイデアは、関数の定義の一部として、関数の内容の一部としてではなく、本当に本当に本当にクールです。そして、このコンセプトに恋に落ちたプログラマーはたくさんいます。面白いことに、Primagenもその一人です。なぜなら、私たちが会うたびに、彼にこれについてノンストップでラントしたので、彼は好奇心からElixirを探求しに行ったのです。
言語の多くの癖は彼には合いませんが、この側面には恋に落ちました。本当にクソクールです。そして、Elixirにはこの種のものがたくさんあります。Elixirに独特な新しい一回限りのものがたくさんあって、モデルが理解するのをはるかに難しくすると思っていました。なぜなら、他の言語のトレーニングデータがこれらのパターンにうまくマップされないからです。
Rubyからのいくつかのアイデアはマップされるかもしれませんが、それほど多くはありません。そして、これをパイプと組み合わせ始めると、特にElixirではすべてが不変であるため、物事は本当にクレイジーになります。すべてが不変値です。それを変更したい場合は、新しい値を作成します。奇妙な言語ですが、私は心から愛しています。とても楽しいです。
ドキュメントとエコシステムの重要性
でも、これらの側面は、AIエージェントのようなツールに使わせるのに良いものではありません。実際、これらはElixirに非常に独特なので、少し傷つくかもしれません。それが助けになる部分もあります。他のもののトレーニングデータを使用できず、それらの間違いを犯すことができないからです。とても違うので。
不変性も確実に大いに役立ちます。でも、最も役立つと思うことは、必ずしも構文や言語やその特性ではありません。その多くはHexだと思います。この事実にまだ馴染みがないなら、Elixirは、C++やRustのように機械語にコンパイルされません。ElixirはErlangにコンパイルされ、Javaの動作に近いVM内で実行されます。
でも、ErlangのVMであるBeamは実際に魔法のようです。Beamでできることは信じられないほどです。今は関連ありません。だから、そのVMがいかに非常識に強力でクールで魅力的であるかについて深く掘り下げたい衝動を抑えます。将来的にそれができるかどうか、コメントで教えてください。このエコシステムをクールにするすべてのことについてただここに座ってラントしたいです。
信じてください。でも、ElixirはBeam上で動作していて、実質的にはただのErlangなので、ElixirはErlangエコシステム全体と、ErlangとBeam VM上に構築された別の言語であるGleamも使用できます。とてもクールです。このエコシステムは素晴らしいです。
でも、ここにいる理由は、Erlangについて話したいからではありません。誘惑的ですが、あなたたちにいくつかのことを見せたいからです。ここにHexで最も人気のあるパッケージがあります。JSON。純粋なElixirで書かれた超高速のJSONパーサーとジェネレーターです。クリックしてみましょう。
ここでは、npmタイプのサイトから期待するすべてのものを見ることができます。オンラインドキュメントにも行けます。なぜなら、Hex上のすべての単一のパッケージがHex Docsサイトを持っているからです。Hex内のすべての単一のパッケージには、ドキュメントが組み込まれています。なぜなら、それを構築するときにドキュメント化するからです。
ソースコードを書くとき、特定の形式でコメントを書くElixirの構文があり、その結果、コードを書くだけでドキュメントが構築されます。コメントすることでドキュメント化します。そして、完成したときの結果は、本当に本当に良いドキュメントです。
チャットでこれがクリックし始めているのが見えます。とても良いですね。すごい。とてもクールです。わあ。そうです、人間にとってクールで、モデルにとってさらにクールなもののもう一つです。デコーダーモジュールを見てみましょう。ここがこのプロジェクトのElixirファイルで、もちろん、JSONをデコードするためのものです。
ここをスクロールしていくと、モジュールドックfalseと書かれています。これは、モジュールドックに直接これを含めないように言っています。だから、これは「直接これのドキュメントを生成しないで」と指定されています。ドキュメントを生成する場所を見つけましょう。おそらくJSON.exです。ここです。
モジュールドック、純粋なElixirで書かれた超高速のJSONパーサーとジェネレーター。見てください、ここにあります。ドックで、入力IOデータからJSON値を解析します。オプションはすべてここで説明されています。そして、仕様で型のこともすでに取得しています。これはすべて、実際に書いているコードのためのものと一緒にソースコード内にあります。
コードとドキュメントは、同じコードベース内にあるだけではありません。一緒に絡み合っているのです。つまり、ドキュメントが簡単にアクセスでき、生成できるだけでなく、さらに重要なことに、これらのドキュメントが最新である可能性が大幅に高く、これらのドキュメントとソースコードの関係は非常に非常に密接です。
それがモデルをこれを行うのに本当に得意にさせるのです。人々がチャットで正しく識別しているように、コロケーションがLLMを動かします。絶対に。コンテキストには素晴らしいです。LLMには素晴らしいです。Tailwindがモデルに良いのと同じ理由で、マークアップ、スタイリング、動作をコロケートするからです。言語における実際の組み込みドキュメント標準は、使用するモジュールを理解して採用するのをはるかに簡単にします。
多くの人がこれはJSDocのようだと言っているのが見えます。いいえ、違います。なぜならJSDocはほとんど使われない標準だからです。誰もJSDocで行うことの実際の良い自動生成器を持っていません。誰も使っていないし、関連性を持つには遅すぎて追加されました。
モジュールドックとHex Docsが魔法である理由は、すべての単一のパッケージがそれらを持っているということです。トップ10をただ見て、これらのすべてを通過すれば、保証します。すべての単一のこれらは、上位6つだけを選びます。さて、すでに自爆しました。最初にチェックしたものの一つはElixir depではなく、Erlang depです。そして、Erlangの人々はドキュメントについてそれほど良くありません。だから、一つ悪いものです。他にいくつの悪いものにヒットするか見てみましょう。
テレメトリーのものを試してみましょう。これは本当に本当に良く見えます。実際。クール。次のパッケージは良いです。CowlibもErlangです。Elixirではありません。悲しい。Erlangのものは悪くなるでしょう。Elixirのものはすべて完璧になります。
ここでベンチに戻ると、Erlangがテスト言語として入ったかどうか分かりません。まだ入っていないと思います。悲しいことに、入っていません。でも、Erlangははるかに悪いスコアを出すと賭けてもいいです。なぜなら、Erlangのエコシステムは、どれだけ狂っていて強力であっても、プログラミング言語が実際に存在する前に始まったからです。
Erlangはとても古くて奇妙です。そして、Elixirはずっと後に出ました。JoseがElixirを作った大きな理由の一部は、言語を良くて保守可能にするもの、後で良いと開発するパターン、そしてできるだけ多くのそれらをElixirに持ち込みたかったということです。
ですから、これらのどれだけが十分にドキュメント化されていないかを見るのは残念でしたが、Elixir depsを通過して問題を見たら驚くでしょう。ええ、再び、すべてのElixirのものは非常に良い状態にあります。Elixirを釉薬し続けるという深い、深い原始的な衝動を抑えます。なぜなら、ここにも他の興味深いデータがあるからです。
Cが他の多くのものと比較して非常に高いスコアを出しているのは何でしょうか。Elixirと同様に、ドキュメントのためのコメントを行うというコンセプトがC#言語に直接あることはほぼ確実です。C#ファイルの途中で、三重にコメントして、書いているコードのセクションを説明するXMLを書くことができます。
いつでもこれを行って、作業中のもののXML定義を行い、同様にコードを生成し、さらに重要なことに、その結果としてドキュメントを生成できます。これらのドキュメントの深さと質は非常に高いです。プログラミング言語ドキュメントだけで新しいモデルをゼロから訓練するとしたら、他のどれよりもC#が得意になると主張します。なぜなら、これらのドキュメントの質は狂っているからです。
でも、ここには他の側面もあります。私たちが必ずしもここで触れなかったもの。トレーニングデータの質は確実に当てはまります。でも、別の似たようなもの、問題に対する解決策がいくつあるか。私がよく使う言語、例えばTypeScriptでは、与えられた問題に対するほぼ無限の異なる解決策があります。
でも、ElixirやCのような言語では、はるかに少ないです。これらのことを行うべき方法は限られた数しかないことを知っていた強力な設計哲学を持って登場した言語、それらのものを良いドキュメントと一緒に提供した言語、それらは非常にうまくいく傾向があります。
私が考えるポイントは全く異なります。正しい解決策を見つけるのはどれだけ簡単か。悪い解決策を見つけるのはどれだけ難しいか。すでに利用可能なコードを理解するのはどれだけ簡単か。外部依存関係とその特定の動作はどれだけ明確か。そして最後のもの、これは型安全性の領域にある種入っていますが、あなたが理解してくれると思う方法で異なります。
私の期待が満たされたときにのみこのコードが実行されることを保証するのはどれだけ簡単か。これらの特性が、モデルが与えられた言語でどれだけ優れているかに本当に影響を与え、形作るものだと主張します。そして、これはすべて理論上のものです。私たちが確実に知っていることではありません。
TypeScriptのような言語では、良い解決策を見つけるのはかなり簡単ですが、正しい解決策ではありません。非常に多くの異なるオプションがあり、正しいものを選ぼうとしてソースに迷い込むのは簡単です。そして、ある場所で一つを選び、別の場所で別のものを選ぶと、時間の経過とともに保守がはるかに難しくなります。
さらに重要なことに、悪い解決策を見つけるのはどれだけ難しいか。TypeScriptでは、簡単です。悪い解決策を見つけるのは非常に簡単です。タブを数回押すだけで、たくさん見つかります。すでに利用可能なコードを理解するのはどれだけ簡単か。これも面白いです。型システムとLSPは素晴らしいですが、カーソルをホバーして型定義を見ることができる場合にのみ役立ちます。
これらのものを見つけるための適切なフィードバックメカニズムをモデルに与えれば、役立ちます。でも、これらを見るためにすべての単一のものにホバーしなければならない場合、またはそれを毎回チェックするためにツール呼び出しを実行しなければならない場合、言語が知りたいことを説明する場合よりもはるかに悪いパフォーマンスになります。
これも興味深いことです。なぜなら、トークン効率はパフォーマンスに直接マッピングされないからです。多くの人々がトークン効率が重要だと考えているようです。私も確かにそうでした。でも、ここを見ると、Cは最もトークン効率が悪い言語の一つで、そのベンチマークで最高のパフォーマーの一つでした。
外部依存関係とその特定の動作はどれだけ明確か。TypeScript開発者として、特にポストインストール地獄に陥ると、物事は厳しくなることがあります。私は現在、Ping Zoom製品、ストリーマー向けのビデオ通話アプリの古いコードベースを移植する作業をしています。それらの古いパッケージが行う奇妙なことの量は恐ろしいです。
そして、モデルに古いバージョンと新しいバージョンの違いを理解させることさえ、本当に本当に厳しいことがあります。そして、私の期待が満たされたときにのみこのコードが実行されることを保証するのはどれだけ簡単か。型安全性と型システムはここで役立ちます。でも、コードが実行される前にこれらの期待が満たされていることを言語自体で保証するほど、あなたを守るものはありません。これは再び、Elixirが例外的によく行うことです。
Elixirでこれらすべてを振り返ると、正しい解決策を見つけるのはどれだけ簡単か。かなり簡単です。悪い解決策を見つけるのはどれだけ難しいか。非常に難しい。なぜなら、公開されているElixirコードが非常に少ないので、公開されているコードのすべては、ほとんどの場合、かなり良いからです。
すでに利用可能なコードを理解するのはどれだけ簡単か。簡単です。イディオムを理解すると、非常に明確な言語です。非常に非常に読みやすいです。特に物事を連鎖させ始めると。再び、いくつかの例です。Elixirでは、値を別の関数に簡単にパイプできます。入力があれば、それをto stringにパイプできます。String.trim、String.downcase、String.replace、そしてString.trim。
確かに、JavaScriptでは、何度も何度もドットを行うことができます。でも、それは値の型が全体を通して一貫しているという前提で、他のことを行う必要がなく、他の引数を渡す必要がないことを前提としています。ここでは、replace関数に他の引数を渡したいです。そして、これが値であり、関数が値に存在するものではないことにも注目です。
input.uppercaseはありません。String.to_uppercaseがあり、それに値を渡します。これは単なる文字列なので、JSでワンライナーとしてこれを書き直すことができますが、本当のことを言えば、それはあまり見栄えが良くないか、非常に読みやすくはないでしょう。
でも、JavaScriptのような言語では、探している結果に到達する前に、これらの値を何度も何度も再割り当てしなければなりません。ああ、これははるかに良い例です。a=3とb=4のようなクエリ文字列を取ります。それを解析し、整数に強制し、結果を計算し、それをフォーマットしなければなりません。
クエリ文字列を取り、URI.decode_queryに渡し、extract_insに渡します。これはエラーがある場合にキャッチするための構文です。次にfn a b Math.sqrt(a * a + b * b)。このインデックスは、JavaScriptで引数を分解できるのと似ています。だから、ここではキーaとbを持つオブジェクトで呼び出されています。そして、これは今、ここでアクセスできる2つの値、aとbです。
そして、その関数はここで見ることができます。オブジェクトを分解しました。aはaで、bはbです。そして今、ここからこれを返します。String.to_integer a、String.to_integer b。URI decodingから解析されます。だから、extract_ins関数は文字列を解析して、それを与えます。そして今、aとbがあります。ins map Math.sqrt(a * a + b * b)。Float.roundに渡します。to_stringに渡します。
私は間違っていました。thenは新しいもので、だから私は馴染みがありません。これは引数を移動するためのものです。ここではそれほど重要ではありませんが、アイデアは分かります。引数がどこに行くかを変えるために、さまざまなインデックスがたくさんあります。最初または最後の引数にしたくない場合は、そのようなヘルパーを使って渡すことができます。それほど重要ではありません。ここでの一般的な流れを非常に簡単に理解できます。
構文を知らなくても、これが何をするかを明確に読むことができます。それは本当に本当にクールです。一方、TypeScriptでは、これを読んで理解できます。でも、はるかに多くの精神的努力が必要です。なぜなら、関数のコア構文がもはや情報の流れを説明しているだけではないからです。関数のコア構文は、値をどのように渡すかの束を定義しています。
この全体を通してすべてのベア値を割り当てなければならないので、コードは、何をしているかと同じくらい、メモリがどのように使用されているかです。そして、これが私が心から愛するElixirの魔法です。トップレベルの関数は、同じ方法でどのようにではなく、何が行われているかを説明しています。
チャットでの良いポイントは、ほとんど疑似コードのように感じるということです。非常にそうです。そして、それが私がそれをクソクールだと思う理由です。なぜなら、他のすべての詳細ではなく、何が起こっているかを非常に明確に説明しているからです。正直なところ、ここでメモリがどのように管理されているかとにかく分かりません。このa rawとb rawの値はいつクリアアップされますか。良い質問です。すべてのthenを削除して、もう少し読みやすくするために5.2を取得しました。
その結果、関数を少し積極的に外部で定義する必要がありますが、それでも非常に読みやすいです。これは本当に良いです。本当に良いです。そして、人々はEffect TSについて尋ねています。これは実際に読みやすいと思いますか。Effectのファンとして言います。ええ、EffectはElixirのようです。パイプさえあります。確かに。
これは以前のトップスニペットと同等です。parse_params query、effect.flatmap p、ネストされたパイプeffect.all a、パイプrequire_param a p、effect.flatmap to_number a。いいえ、Effectを使うべきではないと言っているのではありません。実際、TypeScriptを使っているなら、EffectはTypeScriptをより信頼性の高い方法で構造化する驚異的な方法だと思います。
これの読みやすさとエレガンスには決して勝てません。本当に良いです。本当に良いです。そして、それがモデルがそれをとても気に入っている大きな理由です。コードを読むとき、それが何をしているかが非常に明確です。そして、ここでの最後の部分、外部依存関係とその特定の動作はどれだけ明確か。非常に明確です。なぜなら、ソースコードがバンドルされていて、それと一緒にドキュメントがあるからです。
そして、私の期待が満たされたときにのみコードが実行されることを保証するのはどれだけ簡単か。信じられないほど。なぜなら、再び、パターンマッチングです。ここで、extract_insするとき、a値とb値がある場合にのみこれを行います。異なる値がある場合は、エラーを発生させます。
関数自体の引数が、それがヒットされるべきかではなく、ヒットされることができるかを定義するという事実は魔法のようです。私はここで言うべきことをすべて言ったと思います。C#の世界にもっと深い人が、私がElixirを釉薬し続ける代わりに、C#側でこのビデオの同等のことをやりたいなら、それは本当にクールでしょう。
そして、それをやったら教えてください。ぜひ見たいです。でも今のところ、私が最も愛する言語を釉薬し続ける代わりに、TypeScriptの塹壕に戻る時が来たかもしれません。でも、もしかしたら、もしかしたら、このAI駆動の世界で、Elixirがついに勝つかもしれません。みんながどう感じるか教えてください。
コメント