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 つの番号で識別されました。
ロバートは C ではなく C が開始点であると言っていることに注意してください。よくわかりませんが、特にケンが近くにいる場合は、彼が C を意味していると思います。
しかし実際には、最終的には C から始めることはできませんでした。私たちは、演算子、括弧、中括弧、およびいくつかのキーワードのみを借用して、ゼロから開始しました。 (もちろん、私たちが知っている他の言語からも最高のものを取り入れました。)
いずれにせよ、私たちは今、C の逆を行っており、すべてを分解し、振り出しに戻ってやり直しています。私たちは、より優れた C、あるいはさらに優れた C を設計しようとしているわけではありません。私たちが関心を持っている種類のソフトウェアに適した言語です。
最終的には、C や C とはまったく異なる言語になりました。各リリースはますます異なってきています。
Go 機能リスト
Go における C と C の重要な簡略化のリストを作成しました:
正規構文 (解析にシンボル テーブルは必要ありません)。
ガベージ コレクション (のみ)。
#ヘッダー ファイルがありません。
#明示的な依存関係
循環依存関係はありません。
定数には数値のみを使用できます。
#int と int32 は異なる型です。
大文字と小文字は可視性を設定します。
どの型にもメソッドを含めることができます (クラスは不可)。
サブタイプの継承はありません (サブクラス化はありません)。
パッケージ レベルの初期化と定義された初期化シーケンス。
ファイルがパッケージにコンパイルされます。
パッケージレベルのグローバル式は順序に依存しません。
算術変換はありません (定数は補助処理を受けます)。
暗黙的なインターフェイス実装 (「実装」定義は必要ありません)。
埋め込み (親クラスへのアップグレードなし)。
メソッドは関数と同様に定義されます (特別な場所の要件はありません)。
#メソッドは関数です。
インターフェイスにはメソッドのみが含まれます (データは含まれません)。
メソッドは名前のみで一致します (タイプでは一致しません)。
構築や破壊の方法はありません。
ポストインクリメントとポストデクリメントは式ではなくステートメントです。
事前インクリメントまたは事前デクリメントはありません。
代入は式ではありません。
代入と関数呼び出しが定義された順序で実行します (「シーケンス ポイント」はありません)。
ポインター演算はありません。
メモリは常にゼロ値で初期化されます。
ローカル変数のアドレスを取得することは正当です。
メソッドには「this」がありません。
セグメント化されたスタック。
静的または他の型の注釈はありません。
#テンプレートはありません。 ＃＃＃＃＃＃＃＃＃＃＃＃例外なし。
組み込みの文字列、スライス、マップ。
配列の境界チェック。
この簡略化されたリストと言及されていないトリビアを除けば、Go は C や C よりも表現力が豊かであると私は信じています。少ないほうがいいですね。 それでも、すべてを捨てることはできません。型の動作方法を構造化し、実際に適切な構文を持ち、ライブラリの相互作用を改善するという言葉では言い表せないことを実現する必要がまだあります。
また、スライスとマップ、複合宣言、ファイルごとのトップレベルの式 (ほとんど忘れられていた重要なこと)、リフレクション、ガベージ コレクションなど、C や C にはない機能もいくつか追加しました。等。もちろん同時実行性もあります。
ジェネリックなしでは想像できない
もちろん、明らかに欠けているのは型階層です。これに関して少し汚い言葉を言わせてください。 Go のオリジナル バージョンでは、ジェネリックのない言語で作業することは想像できない、と誰かが私に言いました。以前どこかで述べたように、これは本当に魔法のようなレビューだと思います。
公平を期すために言うと、彼はおそらく STL が C でやってくれることがどれだけ気に入っているかを彼なりの方法で表現していたのでしょう。議論のために、彼に疑惑の利益を与えましょう。 彼は、int リストやマップ文字列のようなコンテナを書くのは耐えられない負担だと言いました。これは素晴らしい点だと思います。 ジェネリックを持たない言語であっても、私はこれらの問題にほとんど時間を費やしません。
オブジェクト指向アプローチ
C や Java から Go に来たプログラマは、型、特に継承とサブクラス化、およびそれに付随するものを扱うプログラミング スタイルを見逃しています。このジャンルに関しては私は素人かもしれませんが、このモデルが非常に表現力豊かであると感じたことはありません。 私の亡き友人アラン・フルニエはかつて私に、学問の最低の形式は分類であると信じていると語った。それで、あなたは何を知っていますか？タイプ階層は分類です。 どのピースをどのボックスに入れるかについて、各タイプの親を含め、A が B から継承するのか、B が A から継承するのかを決定する必要があります。 ソート可能な配列はソートされた配列ですか、それとも配列で表現されたソーターですか?すべての問題がタイプ駆動設計であると信じている場合は、決定を下す必要があります。 プログラミングについてこのように考えるのはばかげていると思います。重要なのは、物事間の先祖代々の関係ではなく、それらがあなたのために何ができるかです。
もちろん、ここで Go にインターフェースが登場します。しかし、それらはすでに青写真の一部であり、それが真の囲碁哲学です。
Python および Ruby プログラマー: 表現力をあまり犠牲にしないので Go to Go ですが、パフォーマンスとパフォーマンスを向上させることができます。同時進行で踊ります。
C プログラマー: 言語を正確に制御するために苦労し、得たものをすべて放棄したくないため、Go に移行できません。彼らにとって、ソフトウェアは単に仕事を完了させるためのものではなく、それを特定の方法で完了させるためのものです。
そこで問題は、Go の成功は Go の世界観を否定するのかということです。私たちは最初から何かに気づくべきです。 C 11 の新機能に興奮している人は、機能がそれほど多くない言語には興味がないでしょう。たとえその言語が想像以上に多くのことを提供してくれることが判明したとしても。 ＃＃＃＃＃＃皆さん、ありがとうございました。
要約
春節の期間中に読んで整理したのですが、内容は濃いですが、口語的な内容でした。しかし本質的に、ロブ・パイクが「少ないほど豊かである」という言葉が意味したことは興味深いものです。 核となる視点は次のとおりです。「Go と C の概念はまったく異なります。プログラマの作業負荷が最小限に抑えられることが期待されています。その少数の機能を接続して組み合わせて、問題を解決できる必要があります。」問題があり、ヒープ関数よりも表現力が豊かになるべきです。」
以上がGo の設計哲学: 少ないほど良い、それはどこから来たのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
