Go の設計哲学: 少ないほど良い、それはどこから来たのでしょうか?-Golang-php.cn

以前、Go コミュニティで知識や経験を共有したとき、次のようなスラングをよく聞きました。「少ないほど良い」「少ないほど良い」「シンプルさへの道」「シンプルさへの道」等

Go の問題や提案について議論するときでも、「less is more」を使って反論したり、議論を支持したりする人がいますが、これは非常に興味深いことです。誰もが非常に興味があるでしょう、それはどこから来たのか、そしてそれは何を意味するのでしょうか？

金文の出典

このような根深いコミュニティ文化概念は、きっと芯のある人が提案したものでしょう。彼は次のように言った著者です:

誰かそれを知っていますか?

彼は Go 言語の父、ロブ・パイクです。

ロブ・パイクは「少ないほど豊かである」というようなことについて何度も言及しており、それは広く広まっている考えです。

次のような機会で共有してください:

2012 年の Go SF カンファレンスで、「Less は指数関数的に」と発言しました。もっと#[1]^{》が共有されました。これは、一般の意見から編集された最初の共有記事です。}
2015 年、dotGo カンファレンスで共有されたのは「
Simplicity is Complicated[2]^{」であり、文化と文化を浸透させ続けました。ビューを共有します。}

この見方のさまざまなバリエーションが業界で広く流通しており、Go コミュニティの独自の「文化」を形成しています。

もちろん、コミュニティからの反応を見ると、賞賛と批判の両方があります。

スピーチの内容

これは、ロブ・パイクの「

Less isexponentially more[3]^{」からの引用です。テキスト部分}@MIKESPOOK[4]^{翻訳、ここでは再構成、整理、引用、図解を行いますので、車輪の再発明はしません。}

以下に示すように:

背景

これは、2012 年 6 月にサンフランシスコで開催された Go カンファレンスに出席した私 (ロブ・パイク) の内容です。スピーチ。

これは個人的なスピーチです。私は Go プロジェクトチームの誰かを代表して話すわけではありませんが、まず、Go を可能にするためにチームが行ってくれたことすべてに感謝したいと思います。

同時に、この講演の機会を与えてくれたサンフランシスコの Go コミュニティにも感謝したいと思います。

Go について私が最も驚いたこと

#数週間前、私は次のように尋ねられました。「驚くべきことですか?」

私はすぐに答えを導き出しました。C プログラマーがオプションの言語として Go を学ぶことを望んでいますが、より多くの Go プログラマーは Python、Ruby から来ており、ごくまれに C から来ているだけです。

私たち (ケン、ロバート、そして私) 自身も元 C プログラマーであり、自分で作成したソフトウェアの問題を解決するために新しい言語を設計しました。

そして他の C プログラマはこれらの問題をあまり気にしていないようですが、これは矛盾しているように思えます。

Go が開発された理由

今日は、私たちが Go を作成するに至った経緯と、Go がその方法ではいけない理由について話したいと思います。私たちはその結果に驚きました。

C よりも Go について詳しく説明することを約束します。C を知らなくてもトピックを完全に理解することができます。

答えは次のように要約できます:

少ないほど良いと思いますか、それとも少ないほど少ないと思いますか?

ベル研究所の物語

これは、比喩としての実話を紹介します。以下のとおり:

Bell Labs は当初、物理研究の 111、コンピュータサイエンス研究の 127 などの 3 つの番号で識別されました。
1980 年代初頭に、私たちが知っている研究が増大しているため、私たちの研究を簡単に識別するには数字を 1 つ追加する必要があると記載されたメモが予定通り届きました。したがって、私たちのセンターは1127になります。
ロン・ハーディンは、世界を本当によく理解すれば、世界を一桁減らして、127 を 27 にすることができる、と半分本気で冗談を言いました。

もちろん、経営陣はそのジョークを聞いていなかった、あるいは聞きたくなかったかもしれませんが、そこには素晴らしい知恵が含まれていると思います。少ないほうがいいですね。理解が深まるほど、それはより暗黙的なものになります。

このアイデアを覚えておいてください。

Go 開発の背景

C コンパイル待機中

2007 年に戻る9 月、私は巨大な Google C プログラム (皆さんが使っているもの) で、些細ではあるが中心的な作業をしていました。

その巨大な分散クラスターでコンパイルするのに約 45 分かかりました。

C の新機能の改善

Google に雇用され、C 標準化委員会に所属している数名が A レポートを作成するという通知を受け取りました。

彼らは、当時 C 0x と呼ばれていたもの (現在は C 11 として知られている) で行われる改良点について教えてくれます。

1 時間のプレゼンテーション中に、すでに 35 の機能が計画されているような話を聞きました。

実際にはさらに多くの機能がありますが、レポートでは 35 の機能のみが説明されています。もちろん、いくつかの機能は小さいですが、レポートで言及する価値があるほど重要です。

#Rvalue 参照など、非常に微妙で理解しにくいものもあります。
#可変引数テンプレート
ユーザー定義リテラル

この時点で、私は自問しました。質問:

C 委員会は、C の問題は十分な機能がないことだと本当に信じていますか?

ロンハーディンの別のジョークで間違いなく、

言語の簡素化は大きな成果をもたらします。機能を追加するだけではありません。もちろん、これは少しばかげていますが、このアイデアを覚えておいてください。

実験的な言語の試み

ただこの C レポートの数か月前に、私自身が 1980 年代に開発したおもちゃのようなコンピューターについてスピーチをしました (YouTube で見ることができます)。同時実行言語。この言語は Newsqueak と呼ばれ、Go の前身です。

私がこのレポートを作成しているのは、Google で働いていたときにもう一度考えた Newsqueak に欠けているアイデアがいくつかあるためです。私は、Newsqueak を使えばサーバー側のコードが簡単に書けるようになり、Google が恩恵を受けることができると確信していました。 it.

実際、I

はこれらのアイデアを C で実装しようとしましたが、失敗しました。C の制御構造を同時操作に結び付けるのは非常に難しく、最終的には実際の処理を理解するのが難しくなります。

私は C にあまり熟練したことがないことを認めますが、純粋な C は今でもすべてを可能にします。あまりにもかさばりそうだったので、このアイデアはやめました。

しかし、C 0x レポートを見て、私はもう一度考えさせられました。私が本当に気になることの 1 つは (ケンとロバートもきっと気になるでしょう)、新しい C メモリモデルにはアトミックタイプがあることです。

すでに過負荷になっている型システムに、このような詳細な記述の微細なコレクションを追加するのは完全な間違いのように感じます。これも短絡的で、今後 10 年間でハードウェアが急速に進歩することはほぼ確実であり、言語を今日のハードウェアにあまりにも密接に結びつけるのは非常に愚かです。

Go Initial Team

レポートの後、私たちはオフィスに戻りました。私は別の編集を開始し、椅子をロバートの方に向けて、重要な問題を伝え始めました。

コンピレーションが完了する前に、私たちはケンを連れてきて何をするかを決めていました。

私たちは C を書き続けるつもりはありません。私たち、特に私は、Google コードを書くときに同時実行性を簡単に記述できるようにしたいと考えています。

同時に、後述する「ビッグプログラミング」の制御も進めていきたいと考えています。

Go 機能ディスカッション

欲しいものとその必要条件をホワイトボードに書き出しました。構文や意味の詳細は無視され、青写真と全体像が思い描かれます。

当時の興味深いメールが今でも残っています。

これは抜粋です:

Robert: 出発点は C で、いくつかの明らかな欠陥を修正し、乱雑な要素を取り除き、不足している機能をいくつか追加します。
ロブ: 「ゴー」という名前です。名前の由来をでっち上げることもできますが、それには十分な根拠があります。短くて綴りやすいです。ツール: goc、gol、goa。インタラクティブなデバッガー/インタープリターがある場合は、それを「go」と呼びます。拡張子は.goです。
Robert: 空のインターフェースはインターフェース{}です。これらはすべてのインターフェイスを実装しているため、これを void * の代わりに使用できます。

すべてを正しく描写したわけではありません。たとえば、配列とスライスのマッピングにはほぼ 1 年かかりました。しかし、この言語の重要な機能のほとんどは最初の数日で決まりました。

ロバートは C ではなく C が開始点であると言っていることに注意してください。よくわかりませんが、特にケンが近くにいる場合は、彼が C を意味していると思います。

しかし実際には、最終的には C から始めることはできませんでした。私たちは、演算子、括弧、中括弧、およびいくつかのキーワードのみを借用して、ゼロから開始しました。 (もちろん、私たちが知っている他の言語からも最高のものを取り入れました。)

いずれにせよ、私たちは今、C の逆を行っており、すべてを分解し、振り出しに戻ってやり直しています。私たちは、より優れた C、あるいはさらに優れた C を設計しようとしているわけではありません。私たちが関心を持っている種類のソフトウェアに適した言語です。

最終的には、C や C とはまったく異なる言語になりました。各リリースはますます異なってきています。

Go 機能リスト

Go における C と C の重要な簡略化のリストを作成しました:

正規構文 (解析にシンボルテーブルは必要ありません)。
ガベージコレクション (のみ)。
#ヘッダーファイルがありません。
#int と int32 は異なる型です。
大文字と小文字は可視性を設定します。
どの型にもメソッドを含めることができます (クラスは不可)。
サブタイプの継承はありません (サブクラス化はありません)。
パッケージレベルの初期化と定義された初期化シーケンス。
ファイルがパッケージにコンパイルされます。
パッケージレベルのグローバル式は順序に依存しません。
算術変換はありません (定数は補助処理を受けます)。
暗黙的なインターフェイス実装 (「実装」定義は必要ありません)。
埋め込み (親クラスへのアップグレードなし)。
メソッドは関数と同様に定義されます (特別な場所の要件はありません)。
#メソッドは関数です。
インターフェイスにはメソッドのみが含まれます (データは含まれません)。
メソッドは名前のみで一致します (タイプでは一致しません)。
構築や破壊の方法はありません。
ポストインクリメントとポストデクリメントは式ではなくステートメントです。
事前インクリメントまたは事前デクリメントはありません。
代入は式ではありません。
代入と関数呼び出しが定義された順序で実行します (「シーケンスポイント」はありません)。
ポインター演算はありません。
メモリは常にゼロ値で初期化されます。
ローカル変数のアドレスを取得することは正当です。
メソッドには「this」がありません。
セグメント化されたスタック。
静的または他の型の注釈はありません。
#テンプレートはありません。＃＃＃＃＃＃＃＃＃＃＃＃例外なし。
組み込みの文字列、スライス、マップ。
配列の境界チェック。
この簡略化されたリストと言及されていないトリビアを除けば、Go は C や C よりも表現力が豊かであると私は信じています。少ないほうがいいですね。
それでも、すべてを捨てることはできません。型の動作方法を構造化し、実際に適切な構文を持ち、ライブラリの相互作用を改善するという言葉では言い表せないことを実現する必要がまだあります。

また、スライスとマップ、複合宣言、ファイルごとのトップレベルの式 (ほとんど忘れられていた重要なこと)、リフレクション、ガベージコレクションなど、C や C にはない機能もいくつか追加しました。等。もちろん同時実行性もあります。

ジェネリックなしでは想像できない

公平を期すために言うと、彼はおそらく STL が C でやってくれることがどれだけ気に入っているかを彼なりの方法で表現していたのでしょう。議論のために、彼に疑惑の利益を与えましょう。

彼は、int リストやマップ文字列のようなコンテナを書くのは耐えられない負担だと言いました。これは素晴らしい点だと思います。

ジェネリックを持たない言語であっても、私はこれらの問題にほとんど時間を費やしません。

オブジェクト指向アプローチ

C や Java から Go に来たプログラマは、型、特に継承とサブクラス化、およびそれに付随するものを扱うプログラミングスタイルを見逃しています。このジャンルに関しては私は素人かもしれませんが、このモデルが非常に表現力豊かであると感じたことはありません。

私の亡き友人アラン・フルニエはかつて私に、学問の最低の形式は分類であると信じていると語った。それで、あなたは何を知っていますか？タイプ階層は分類です。

どのピースをどのボックスに入れるかについて、各タイプの親を含め、A が B から継承するのか、B が A から継承するのかを決定する必要があります。

ソート可能な配列はソートされた配列ですか、それとも配列で表現されたソーターですか?すべての問題がタイプ駆動設計であると信じている場合は、決定を下す必要があります。

プログラミングについてこのように考えるのはばかげていると思います。重要なのは、物事間の先祖代々の関係ではなく、それらがあなたのために何ができるかです。

もちろん、ここで Go にインターフェースが登場します。しかし、それらはすでに青写真の一部であり、それが真の囲碁哲学です。

C と Java が型継承と型分類に関するものであるとすれば、Go は合成に関するものです。

Unix パイプの最終的な発明者である Doug McIlroy は 1964 年に次のように書きました (!):

何らかの方法で庭のホースを蛇口に接続する必要があります。メッセージデータピースを接続する部分的に。これはIOでも使用されている方法です。

これは Go でも使用される方法です。 Go はこのアイデアをさらに一歩進めました。これは組み合わせとつながりに関する言語です。

わかりやすい例は、インターフェイスが結合されたコンポーネントを提供する方法です。メソッド M を実装していれば、それが何であるかは気にせず、適切な場所に配置できます。

もう 1 つの重要な例は、独立して実行される計算を同時実行によってどのように接続するかです。また、珍しい (しかし非常に単純な) 型合成パターン、埋め込みもあります。

これは Go 独自の組み合わせ技術であり、C や Java プログラムとはまったく異なります。

C/Java の大きなプログラミングパターン

関係のない Go の設計について触れておきたいと思います。Go は、大規模な書き込みを支援するために設計されました。プログラムは大規模なチームによって作成および保守されます。

「ビッグプログラミング」と呼ばれる観点がありますが、どういうわけかこの分野では C と Java が主流です。これは単なる歴史上の間違い、あるいは労働災害だと思います。しかし、オブジェクト指向設計で何かができるというのは広く受け入れられている考えです。

私はそれを全く信じません。大規模なソフトウェアには方法論の保護が必要ですが、強力な依存関係管理や明確なインターフェイス抽象化、さらにはそのような豪華なドキュメントツールは必要ありませんが、強力な依存関係管理、明確なインターフェイス抽象化、優れたドキュメントツールよりも重要というわけではありません。そして、これらはいずれも C が得意とするものではありません (Java の方が明らかに優れていますが)。

Go で書かれたソフトウェアが十分ではないため、まだわかりませんが、大きなプログラミングの世界で Go が傑出することは間違いありません。時間がすべてを証明してくれる。

Go が C プログラマに好まれない理由

さて、スピーチの冒頭で述べた驚くべき質問に戻ります:

C を破壊するために設計された言語である Go が、なぜ C プログラマーの心を掴めないのでしょうか?

冗談はさておき、それはGoとCの哲学が全く違うからだと思います。

C は、指先ですべての問題を解決できるようにすることです 。

C 11 FAQ からこの段落を引用しました:

C は、特別に作成された手作業でコーディングされたコードの大幅な増加に比べて、はるかに幅広い抽象化、優雅さ、柔軟性、およびゼロコストの表現力を備えています。

この思考の方向性は囲碁とは異なります。コストゼロは目標ではなく、少なくとも CPU コストゼロではありません。 Go の提案は、プログラマの作業負荷を最小限に抑えることです。

Go はすべてを網羅するものではありません。すべてを内蔵することはできません。実行の細部をすべて正確に制御することはできません。たとえば、RAII はありません。代わりにガベージコレクションを使用できます。メモリ解放機能もありません。

得られるものは強力ですが、理解しやすく、問題を解決するために接続および結合するために使用されるいくつかのモジュールを構築するのに使いやすいです。

これは、他の言語で書かれたソリューションほど速く、洗練され、イデオロギー的に明確にはならないかもしれませんが、確実に書きやすく、読みやすく、理解しやすく、保守しやすくなります。、そしてより安全です。

言い換えれば、もちろん、ある程度単純化しすぎています:

Python および Ruby プログラマー: 表現力をあまり犠牲にしないので Go to Go ですが、パフォーマンスとパフォーマンスを向上させることができます。同時進行で踊ります。
C プログラマー: 言語を正確に制御するために苦労し、得たものをすべて放棄したくないため、Go に移行できません。彼らにとって、ソフトウェアは単に仕事を完了させるためのものではなく、それを特定の方法で完了させるためのものです。

そこで問題は、Go の成功は Go の世界観を否定するのかということです。私たちは最初から何かに気づくべきです。

C 11 の新機能に興奮している人は、機能がそれほど多くない言語には興味がないでしょう。たとえその言語が想像以上に多くのことを提供してくれることが判明したとしても。＃＃＃＃＃＃皆さん、ありがとうございました。

要約

春節の期間中に読んで整理したのですが、内容は濃いですが、口語的な内容でした。しかし本質的に、ロブ・パイクが「少ないほど豊かである」という言葉が意味したことは興味深いものです。

核となる視点は次のとおりです。「Go と C の概念はまったく異なります。プログラマの作業負荷が最小限に抑えられることが期待されています。その少数の機能を接続して組み合わせて、問題を解決できる必要があります。」問題があり、ヒープ関数よりも表現力が豊かになるべきです。」

以上がGo の設計哲学: 少ないほど良い、それはどこから来たのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。