The Lisp curse, now coming to your ecosystem

LISPの「呪い」、あなたのエコシステムにも到来か！

LISPの「呪い」とは、LISP方言においてライブラリや再利用可能なコンポーネントが非常に少ない理由としてしばしば引用されます。この概念によれば、LISPは非常に強力で柔軟であるため、開発者はカスタムソリューションを簡単に作成でき、その結果、より長い期間、孤立して作業することになります。これにより、しばしば車輪の再発明が行われます。なぜなら、自分の問題を解決するためのコードを作成することは、他人のライブラリ（や考え方）に依存するよりも簡単/速い可能性があるからです。これは、他の多くの言語エコシステムが持つような、中央集権的なフレームワークやライブラリの欠如につながります。時には、孤立して書かれたこの強力で柔軟なコードは、しばしばドキュメントが不足しており、第三者には理解しにくい場合があるとも言われ、他の開発者は自分でモジュールを書くことを好む――そして呪いは続くのです。

はい、この記事はLLM支援コーディングについてです

今週、大規模言語モデル（LLM）の容易さと品質により、既存のフレームワークやライブラリのような抽象化を利用するよりもコードを生成する方が簡単で安価であると主張する人々との間で、いくつかの議論に引き込まれました。確立されたライブラリが信じられないほど安定しており、数十万人の開発者によってテストされ、数千のCIパイプラインに含まれ、そのトピックの専門家によって保守されているという事実を無視するなら、LLMに機能生成を任せる方が、既存のライブラリやフレームワークのインターフェースを学習する（あるいはLLMにこれらのライブラリやフレームワークを統合させる）よりも簡単であるという仮定を受け入れると、Javaのような言語エコシステムにとってどのような意味があるでしょうか？

より多くの孤立、より多くの個人主義、より少ない協力

過去数十年にわたり、多くの人々が協力、集団的な問題解決、そして困難な問題解決という目標を通じて、オープンソースエコシステムの成功に貢献してきました。

前述のシナリオの最初の影響は、オープンソースライブラリを使用する人々が減少し、メンテナーへのフィードバックが減少することでしょう。もし私がワン・ツー・プロンプト、20分待機時間、そして数ドルのトークンで問題を解決できるなら、なぜリサーチに時間を費やす必要があるでしょうか？なぜ他の人々が作ったAPIの決定を気にする必要があるでしょうか？なぜドキュメントを読む必要があるでしょうか？

第二の影響として、新しいオープンソースライブラリの作成は停滞するでしょう。オープンソースを行う上での大変な部分はメンテナンスです。コードの構造化、インフラのホスティング、アーティファクトリポジトリへの公開。バージョニング、後方互換性、スタックを最新の状態に保つこと。コード生成がそれほど簡単で、自分の問題をそれほど迅速に解決できるなら、なぜコードをモジュール化し、世界と共有し、オープンソースプロジェクトが必要とするすべてのプロジェクト管理を行う必要があるでしょうか？生成されたモジュールには必要なものがすべて揃っており、APIは必要に応じて壊すことができ、私のユースケース、私のスタックに正確に調整できます。

これらの2つの効果は、長期的には互いに増幅し合う可能性さえあります。新しいテクノロジーやアプローチを言語エコシステムに統合するためのオープンソースライブラリが少なく提供されるようになれば、人々は自分のソリューションを自分で作成して済ませる傾向がさらに強くなるかもしれません。

暗い見通し

すでに行間から読み取れたかもしれませんが、私はライブラリやフレームワークをコードに追加するのをスキップして、すべてを生成するという仮定を共有していません。私は、ローカルな問題を解決する何百行ものコードを生成するよりも、明確に定義された抽象化を持つ実績のあるライブラリに依存する方が良いです。「ここで生成されていない」は「ここで発明されていない」の別のバージョンにすぎません。それでも、コーディングにおけるLLMは定着すると考えており、このシナリオは何らかの形で到来するでしょう。一部のソートリーダーが現在主張しているほど劇的ではないかもしれませんが、偶然にです。オープンソースの協力はある程度減少し、ソフトウェア開発は現在よりもはるかに孤独なタスクになるかもしれません。

---

---