Goのデザインの「客観的な品質」に関するミームがプログラマーパーティーに登場します。 先日、ホンザの言語選択に関する記事で彼に会いました。
言語は客観的に非常に貧弱に設計されていることに注意してください。 [...]また、GitHubによると、GoはHaskellよりもはるかに人気があります。 同時に、Docker、InfluxDB、etcd、Consul、Prometheus、packerなど、Goで作成されたすばらしいプロジェクトがすでに多数あります。
これは非常に興味深い矛盾のセットだと思います。著者はこれに同意しています。
この意見がそれほど一般的でない場合、Goの設計が不十分であると断固として自信を持って議論することは困難です。 昨年、多くの記事とブログ投稿がこの意見の基礎を築きました。 その中には、Goを好まない人々による記事がありました。その理由は、Go を賢く感じさせないか、 根本的に新しいものがないからです。 彼らは、プログラミング言語の設計における特定の進歩を意図的に無視するGoが過去に残っており、そこから最高の言語がはるかに進んでいると確信しています。 そして彼らはそれを非常にしつこく断言します。
このビジョンを持つ人々が囲Goの人気を説明しようとすると、必然的にパラドックスになります。 Goが非常に悪い場合、なぜそんなに人気があるのですか？
そしてこの場合、認知的不協和音と戦うことは非常に困難です。 他の笑されているが人気のある言語とは異なり、囲Goは課されていません。 主にアマチュアや経験の浅い開発者が占めている新しいプラットフォームでは、欠点にもかかわらず、彼はクリティカルマスを獲得しませんでした。 これは、歴史上最も経験豊富なプログラマーの 1つである世界最大のインターネット企業で開発され、分散インフラストラクチャプロジェクトで最初に採用されました。
このパラドックスを回避するために、人々は通常、 すべての愚か者 （残念ながら、プログラミングコミュニティでは珍しいことではないようです）、またはGoの適応に寄与する他の要因があると結論付けます。 しかし、この定義を別の角度から見た場合、実際に良いオプションは通常考慮されていません。
悪いほど良い
これは、リチャード・P・ガブリエルが彼の古典的なエッセイで述べた「悪いほど良い」という現代的な現れです。 その中で、Gabrielはシステム設計の4つの主要な価値を表明していますが、これは矛盾している可能性があります。 単純さ 、 正確さ 、 一貫性 、 完全性です。 さらに、競合する2つの哲学について説明します。正確性と一貫性を優先するMITアプローチと、実装の容易さを優先するニュージャージーアプローチです。
ニュージャージーのアプローチがUnix哲学の事後記述であるかどうかを議論することができたとしても、Goの作成者がその哲学の主要な要素として単純さを明確に促進したことは確かです。 実装の単純さは、言語自体とライブラリの両方で明確に定式化された位置であり、 論理よりも単純さというこの明確な優先順位が言語に組み込まれています。
1990年のエッセイの執筆以来、 コンピューターの世界が劇的に変化したため、おそらくシンプルさが優先事項として認識されるようになりました。
増大するデータ量に対処するために、コンピューティングとストレージは水平方向に拡大し始めました。これに対処する論理的な結果は、よりシンプルなものへの傾向でした。 CORBAや皮肉なことにSOAPと呼ばれる古い文献で称賛されたシステムは、最終的には故障モードのエレガントさが劣る単純なシステムに埋もれてしまいましたが、実装は数桁単純でした。
ソフトウェアの開発方法も変わりました。 膨大な数の企業が主にオープンソース製品に基づいて構築されており、それらに応えて貢献しています。 単純なコードは記述、読み取り、討論、および保守が容易であるため、単純な言語は習得が容易であるという利点があり、その結果、より多くの使用、より多くのライブラリーと貢献者が得られ、長期的に実行可能性と品質が向上します。
これは、単純であることは必ずしも学問領域から初歩主義への逸脱を意味することを意味するものではありません。 Paxosのような複雑なものは、 Raftのような単純なものよりも最終的に劣っています。
品質の性質
単純化の傾向にもかかわらず、プログラミング言語の議論は通常、 MITアプローチの枠内で行われます。 それは非常に成功し人気があったので、すでに気づかず、明白ではありません。
特定のエラークラスの可能性の欠如を正式に証明する複雑な型システムは、実装の複雑さやプログラマの認知的負荷にも関わらず賞賛されます。 これらのシステムを意図的に簡素化することは、意識的な妥協ではなく、常に不完全であると見なされます。
問題は、プログラミング言語の品質を評価するこのトピックには、実際のコードを書く際の有効性と明確なリンクがないことです。
Goのアプローチは、Cから始めて、正しく使用するのが難しいものを捨てて、追加するのに十分な単純または十分な直交性がなくなるまでギャップを埋めることでした。 単純なものから複雑なものまでの連続性に関するよく知られた点である、よく知られた一連の妥協点を取り上げ、実世界での数十年にわたる実際の開発経験に基づいて小さな変更を行います。 これは、システムを構築するための許されないほど簡単なエンジニアリングアプローチです。
もちろん、すべてを単純さの祭壇に置くことはできません。 多くの低レベルのバイトコードおよびアセンブラー言語は簡単に記述して移植できますが、それらのインターフェースはプログラマーが使用するには複雑すぎます。 機能の数と言語のシンプルさのバランスをとる必要があります。
そして、これを正しく行おうとしないシステムには、使用するには複雑すぎるインターフェースがあり、完全性のために単純さを犠牲にするシステムは、正しく使用するには複雑すぎるように実装されています。 スペクトルの複雑な側面にあるシステムは、実際的な理由で不要なアプローチを通じて「正しい」ことをしばしば達成するか、 単に「正しい」ことをするふりをします 。 十分に有用な抽象化は流れ去るので、結果が事前に理解できるように、それらの振る舞いは十分に単純であることが最善です。 エラーには、システムの実装の複雑さに見合った複雑さがあります。
ry審員が囲aboutについて何を決定するかを知るには何年もかかるかもしれません。 言語がどれだけ「良い」かを測定する簡単で明確な方法はないので、これは人気のあるシステムが衰退して死ぬのではなく、人気のあるシステムの繁栄によって最終的に決定されます。 悪役とは異なり、Goの人気はその強さのおかげで成長を続けています。つまり、評価する時間が増えました。 彼の明らかな弱点が本物である場合、それで作成されたシステムが成熟に達するので、私たちは確かに現実の世界でそれらを見るでしょうが、今のところ見通しは非常に良いです。
しかし、私たちが見ているのは、5年前にはニッチにツールが置かれているという恐ろしい状況のために、Goが不可能だったプロジェクトを選択するということです。 Goが最終的に失敗しても、長くなるほど、GoがCで始まり、後者の血統と残りの力を考えると、次世代の言語はGoで始まる可能性が高くなります。それは大成功になるでしょう。