スプリングの方向性について冗談を言ってたんだけど、アプリがボイラープレートのメインメソッドと何十行かのアノテーションだけになるんじゃないかって。実際にそれを目の当たりにしたことがあって、db2からrabbitmqに更新を送るアプリがあったんだけど、アプリはアノテーションによる設定だけで、通常のスプリングのメインメソッド以外はJavaコードが全くなかったんだ。

本当に不思議だよ。どうして他の人たちがもっと良いものを作っているのに、わざわざ劣ったものをデザインするのか理解できない。理由は何だろう？言語全体との一貫性？でも、それってそんなに重要なのかな。特定のコンパイラの部分に手をつけたくないだけなのかな？

Javaが実証済みの機能を使ってるとはあまり感じないな。例えば、チェック例外を使ってるけど、あれは実証済みの機能には見えない。C++はチェックなしの例外を使ってるし、ほとんどの人気言語もそうだ。Javaはチェック例外を選んだけど、今では開発者にほとんど無視されてる。これは完全に失敗だと思う。ストリームもいい例だね。コレクションのための関数型APIを作るのはかなり簡単なのに、彼らは簡単な並列化のためにストリームをデザインすることにした。これが非常に複雑な実装につながって、めちゃくちゃ難しくなった。今までこの機能の使い道に出会ったことがないし。だから、非常に稀な機能のためにデザインをめちゃくちゃ複雑にしちゃった。モジュール…笑。グリーンスレッドがどう機能するか見てみよう。ほとんどの言語はもっとシンプルなasync/awaitアプローチを採用してるし、グリーンスレッドを実装してる言語はごく少数だね。

それはちょっと恐ろしいね。フレームワークの設計者たちが、言語がアプリのロジックを表現するには力不足だと感じて、自分たちのカスタムな動作を上乗せしたってことだから。明確なコードは、誰が見ても読みやすく理解できるように努力すべきだし、受け入れられるコードは、技術について少し知っていて、IDEのサポートがあれば理解できるべきだよ。ゴミコードってのは、実際に動かさないと理解できないコードのことだね。メタデータに基づいてフレームワークのロジックを使って、ものをつなぎ合わせてるから。

OpenJDKはそんな風には考えてないよ。彼らは、自分たちが提供する機能は他の言語からの影響を受けているにしても、せいぜい軽いものであると思ってる。傲慢からではなく、実用的な観点からね。他の言語の機能をそのままJavaにコピー＆ペーストするのは、フランケンシュタインを作るようなものだから。例えば、Javaはラムダ構文があって、ラムダが必ずコンパイル時に何らかの「関数型」として解釈されなければならないという点で、ちょっとユニークなんだ。関数型とは、正確に1つの未実装メソッドを定義するインターフェースのこと。JVM上で動くScalaを含むほとんどの言語は、ラムダを関数として記述する型階層を作っていて、Scalaの場合はコンパイル時に自動的に「ボックス」や「キャスト」することもある。つまり、Javaのアプローチは独特なんだ（私の知る限りでは）。当時、他の言語のように機能を実装する代替提案もあったけど（BGGA提案）、それは拒否された。君のコメントの核心的な問題はこれだね。「洗練された」と「エレガント」とは何かを定義してみて。簡単そうに聞こえるけど、言語の機能は非常に異なるメロディに合わせて踊ろうとしていて、一人の人にとっての「エレガンス」は、別の人にとっての「フランケンシュタインの怪物」なんだ。同じことは「美しさ」や「魅力」にも当てはまるけど、もし大雑把に言うなら、ほとんどの人が「魅力的な」言語については大まかな共通理解を持っていると思う。そういう言葉に当てはまるメインストリームの長期的に人気のある言語は知らないし、それは本質的なものだと思う。言語がメインストリームであるためには、非常に安定している必要がある。単に言語Xでクールな新しいおもちゃを作っているだけではなく、多くの金や目が関わるプロダクションコードを書いているから、そのソフトウェアが動き続けることに本当に依存しているなら、安定性が必要不可欠なんだ。安定性があると、手枷が付くことになる。『非推奨』を使うのは極めて控えめにしなければならないし、基本的には使わないべきだよ。それには後続の影響がある。新しい機能をテストすることもできないから。今のところ、from future import ...のようなシステムの上で本当に繁栄している言語は見たことがない。それには理由がある。エコシステム全体が未来の機能を採用して、もしそれが壊れたら同じような頭痛を引き起こすか、そうでなければ、そういう機能を使わないかおもちゃのようなものにしか使わないから、導入から得られる経験はほとんどない。言い換えれば、Javaがフランケンシュタインなら、JavaScript、C#、Python、Ruby、Scalaも同じだよ。そうならざるを得ない。私は、特にそれを防ぐことに100%焦点を当てた言語のコアデザイン原則を見てみたい。これまで見たことのない、言語自体のバージョン管理に関する極端なアプローチだね。どんなものかはわからないけど、ここで見たい努力をした言語は思い出せない。このために必要なことのほんの一部を挙げると、* 言語自体がバージョン管理されていて、すべての以前のバージョンが言語仕様の一部として維持され、将来のコンパイラによってもメンテナンスされ続けること。少なくとも長い間、できれば永遠に。 * すべてのソースファイルは、どのバージョンの言語を使っているかを示す必要がある。 * コアライブラリもバージョン管理されていて、別々に。新しいバージョンは古い言語バージョンに対して書かれるか、古い言語バージョンのソースから使える。 * システムのコンパイラやツールは、基本的に「プロジェクト」レベルの粒度で動作する。個々のソースファイルをコンパイルすることはできない。できる場合は、その行為によって一時的な無名プロジェクトが暗黙的に示されることが仕様で説明されている。 * すべてのバージョンには移行ツールが付属し、言語バージョンX用に書かれたソースを自動的に言語バージョンX+1に「更新」し、問題を引き起こす可能性がほぼゼロのものを自動的に適用し、自動更新ができない非推奨の使用法を明示的に修正するようにプログラマーを導く。 * 言語は本質的に「ファサード」をサポートしていて、バージョンYのライブラリがバージョンX（XはYより古い）のAPIを、Yのデータ構造を使って公開できるようにする。これにより、バージョンXのコードベースとバージョンYのコードベースの間で相互運用が可能になる。その言語は、「エレガント」、「シンプル」、「メインストリーム」、「真剣なプロジェクトに適している」、「実際に良い」という、他では不可能な仕事を管理できるかもしれない。

その通り。著者はたぶんSpringや、他の依存性注入フレームワークに触れたことがないんじゃないかな。アノテーションを使うことで、全く違う方法で物事を進められて、たくさんのボイラープレートを省けるんだ。アノテーションには少なくとも9/10をあげるよ。（このレベルの知識があると、記事の他の部分には興味を失っちゃうけどね。）

評価がめちゃくちゃだね。Jshellが6/10？基準は何？

わからないけど、魔法みたいな機能をあまり使わないプロジェクトで働いたことがあって、正直言ってそれは悪化したと思う。設定クラスと@Inject Config config;があるアプリの代わりに、巨大な*Configクラスがあったんだ。それぞれに@Bean public fooProducer(FooConfig config, BazProvider provider, BarProvider barProvider, SoapClient soapClient) {...}みたいなメソッドがたくさんあった。どうやって作られたか知りたい？クラスのコンストラクタの使用例を探してみて。魔法の@Injectや@Autowiredのアノテーションは、それよりも悪くないと思うんだ。

リストは全体的にかなり単純化してるけど、アノテーションについてはその通りだね。必須の個人的エピソード：私はJavaの専門家じゃないけど、99年からJavaに関わってて、数年前に厳密にJavaのチームに移動したんだ。紹介の際に、私のパーティートリックを見せようと思って、一日で擬似「wolf3d」を実装したんだ。いつものように、Javaの開発者たちはJavaでグラフィックスやユーザー入力ができることにちょっと感心してた。今ではそれがほとんどの人にとって非常に珍しいからね。承認をもらった代わりに、彼らにSpringの一日深掘りをお願いしたんだ。結局、基本的なHello Worldプロジェクトが提示されたんだけど、それはほとんどが… 空のクラスだった。文字通り、class Foo {} EOF! もちろん、これらの空のクラスにはクラス宣言の上に少なくとも5行のアノテーションがあったし、最終的にはフレームワークを正しい方向に押しやったけど、マジで、私はその週ずっと気持ち悪かった。

いや、これめっちゃいいね！

モジュールに対する嫌悪感、なんでそんなに強いの？このスレッドの皆がほぼ一様に嫌ってるみたいだけど、理由がわからない。

これを作ってくれて本当にありがとう！

ありがとう！これ、元の投稿に入れるべきだよ。

彼がアサーションはプロダクションコードに見られないと言ったのにはかなり驚いた。ほんとにそうなの？私はあまりJavaを書かないけど、Cのコードではアサーションを（プロダクションコードで）常に使ってるよ。関数に2、3個のアサーションが含まれるのは珍しくないし。

これをキーワードにすることの利点は、標準関数にするのと比べて何なの？

「前のバージョン [のJava時間] がどれだけひどかったかを過小評価するのは難しい。」 元々のJava Timeクラスは、Javaにとって最後の瞬間の追加だった可能性が高い。明らかにC言語のtime.hを直接コピーしたものだ。Javaチームがこんな会話をしていたように感じる。「やばい、1ヶ月後にJava 1.0を出荷するけど、時間関数を含めるのを忘れた！」 「ああ、どうしよう！何かしなきゃ！」 「そうだ、Cのtime.hを移植しよう！」

私の中では、Javaは1.5でコレクションとジェネリクスが追加されてから本当に使いやすくなった。コレクションがなかった時は、本当に面倒だった。でも、追加された後も、コレクションから取り出すときには、元の型にキャストしなきゃいけなかった。それもまた大変だった。ジェネリクスが「正しく」実装されていないという議論は知ってるし、問題にも直面した。でも、彼らがあることに本当に感謝してる。

例外に関する批判には完全に同意するよ。ストリームの中で例外が必要になると、めちゃくちゃになる。全体的に君に同意する。例外がないよりは、少し冗長でもずっと良い。古いループを小さなストリームで整理するのが好きだし、同じことをもっとコンパクトで読みやすく表現できる。彼が言ってる並列の利点が実際に使われているのを見たことがないのも正しい。

今日はちょっとJavaでコーディングできるよ（だって、ほら、GPTと仲間たちがいるからね！！ :) ）GPT大好き。ほんと素晴らしいツールだよ。ChatGPTが登場する前は、医療の経験なんて全然なかったんだ。GPTと仲間たちのおかげで、今は医者になったよ。自分のクリニックも開業したんだ。

だから、Pythonのconcurrent.futureパッケージを使うときにJavaを思い出すんだ。

元々のビジネスプランは、Javaをネイティブに実行するCPUを売ることだったんだ。それは速くなるはずだった。そのアイデアはひどく失敗した。

そうだね、モジュールはエンドユーザー向けじゃない、少なくともほとんどはね。

モジュールは大きく壊れたから-10だね。

例えば、モジュールシステムの主な「顧客」はJDKそのものだ そうそう、TFAに書いてあったけど、「一般的なアドバイスは、モジュールは（あるべき）JREの内部詳細であり、アプリケーションコードでは無視されるべきだ」と。だから、なんで「主な顧客」でない人たちにそれを見せる必要があるの？