インタビュー：ブライアン・カーニガンとアラン・ドノヴァン

今年、アラン・ドノヴァンと共同執筆した古典作品「Cプログラミング言語」の著者であるブライアン・カーニガンは、「The Go Programming Language」という本を書きました。特に、本は言語自体の作成者による厳密な制御の下で作成されたためです。 英語版の本の電子版は今日のみ公開されます。いくつかの譲渡の理由は、本の初版の不正確さの修正でした。 2016年3月までにロシア語への高品質の翻訳が期待されています。



興味のあるすべての読者の注目を集めて、スラッシュドットの本の著者との最近のQ＆Aセッションを翻訳してください。



数週間前、全員が共同作業である「The Go Programming Language」という本について、アラン・ドノヴァンとブライアン・カーニガンに質問する機会がありました。 スラッシュドットは、最も人気のある読者の質問を選択し、それらに対する回答を受け取りました。



Donovan / Kernighan ：面白くて挑発的な質問をする時間を割いてくれなかった皆さんに感謝します。 残念ながら、すべてに答えることはできませんでした。 さらに、私たちは誰もGo言語開発チームのメンバーではないため、当初は、将来の計画に関する質問やユーティリティについて詳しく話すことに対して、より信頼できる答えを出すことができませんでした。

OpenGLとLockOSThread

OpenGLのようなライブラリを正常に動作させるために頼らなければならない「厳しい」ハックを確認したときに、Goの使用を停止しました。 これを修正する予定はありますか？



Donovan ：問題の核心は、OpenGLのような多くのCライブラリが暗黙的にコンテキスト情報を保存するために呼び出しスレッドの識別子を使用することです。 これは、グローバル変数をコンテキスト情報の保存に安全に使用できる場合、マルチスレッドが標準になる前にAPIの設計が作成されたためです。 他の場合、この設計の使用は、各呼び出しへの追加パラメーターの転送を節約できるため、利便性の問題にすぎません。



Goを設計するとき、 スレッドローカルストレージ（TLS ）のアイデアは、「 離れた場所でのアクション 」と呼ばれるものを配置する傾向があるために拒否されました。 （ちなみに、私たちはこのことについて本で書きました）。 GoにTLSが存在しないことは「機能」と見なされるため、「修正」する予定はありません。 しかし、CのGo依存TLS依存ライブラリをGoでより良く動作させる機会があります。同僚のDavid Crawshawが最近パリで開催されたDotGo 2015でこのことについて話しました。

パッケージのバージョン管理が無視されるのはなぜですか？

バージョン管理パッケージが無視されるのはなぜですか？ あなたはまだあなたのソリューションが好きですか？ Goを使用すればするほど、この瞬間は言語のアキレス腱を思い出させます。 ソフトウェアは数十年前から存在し、その開発は継続的な進化です。 Goのインポートシステムでは、バージョンまたは「ヒント」を指定できません。「go get」コマンドでもこれは許可されません（ただし、一般的なバージョン管理システムはすべてサポートされます）。gopkg.inなどのさまざまなハックが発明されました。 また、他の言語のパッケージマネージャーがこの問題を多かれ少なかれエレガントな方法で既に解決しているため、問題が何であるかは明確ではありません...



Donovan ：Goは大きなプログラムを作成するために設計されたものであり、このコンテキストではバージョン管理が難しいことはよく知られています。



約10年前、Googleはアセンブリシステムにバージョン管理を導入する実験を行いました（Rob Pikeなどによって設計されました）。 ダイヤモンドの依存関係の問題が原因で失敗しました。これは、多くの人が古典的なバージョン番号の問題だと聞いていると思います。 4つのパッケージA、B、C、Dがあり、AはBとCに依存し、BとCは両方ともDに依存するとします。これはdiamond依存関係です。 著者BがパッケージDのバージョン1のみが適切であり、著者Cが少なくとも同じパッケージDのバージョン2を必要とする場合、不可能な一連の制限が適用されます。 運がよければ、「古い」と「新しい」の両方のバージョンのDでAを「ビルド」できますが、多くの場合、動作しません。 この実験の後、Googleは自動バージョン管理に二度と手を加えませんでした。



現在のバージョン管理の方法はシンプルですが「手動」です。パッケージの各バージョンを独自の名前（「D1」、「D2」など）を持つ独立したエンティティとして取得し、理想的には各パッケージのバージョン数を制限します-に。 そのため、Googleではバージョン管理が優先事項ではありません。



しかし、この8月、多作のDave CheneyがGoのパッケージのバージョン管理スキームを提案したため、このアイデアが将来発展する可能性があります。

Goでのエラー処理

Goは、他の言語のエラーを処理する非常に異なる方法です。 大規模アプリケーションのコンテキストにおけるJavaと比較した、このアプローチの長所と短所について教えてください。



Kernighan ：全体として、Goは明示的なエラー処理を強く推奨します。 標準ライブラリの関数はほとんどすべて、関数の値とともにエラーステータスを返します。コードはこのステータスを使用して何らかの処理を行う必要があります。 エラーを無視することはできません。 この点で、GoはJavaに似ており、エラーをキャッチまたはスローする必要があります。 ただ何もすることはできません。 はい、これは小さなワンタイムプログラムの場合は不便ですが、大きなプログラムの場合は本当の救いです。 そして、これらの言語はどちらも「正しいこと」を行い、それぞれ独自の方法で行います。



それらの違いは、例外の使用です。 Goには例外メカニズムがないため、すべてのエラーを1か所で処理する直接的な方法はありません。Javaのtry/catch



では可能ですが、 defer



はエラー処理の場所を「修正」するのに役立ちます。 これはすべて、Javaコードをもう少しコンパクトにすることができることを意味します（これに関してのみです！）。しかし、おそらく、何が間違っていたかについて正確な情報を提供できないという犠牲を払っています。



Goの本では、エラー処理のトピックに多くのスペースが割り当てられています。 ほとんどの例では、エラーを無視するのではなく、適切にエラーを処理する方法を示しました。これにより、結果の例が少し長くなりました。



Donovan ：私はたくさんのJavaコードを書きましたが、私の経験では、「良い」エラー処理は両方の言語で等しく困難です。 ただし、Goを使用すると、エラーを新しい情報で補足するかどうかに関係なく、ほぼ同じコードを記述する必要があるため、スローするときにエラーメッセージを補足する構文上のコストが削減されます。 対照的に、Javaはtry/catch/throw



ブロックを書くことを避けたいtry/catch/throw



思うので、プログラマはあまりにも頻繁にエラーをスローします。 言語の使用における小さな違いについてのそのような実際的な知識が、仕様を読むことから決して収集できないことは面白いです。

フィットメントゴー

Goの使用を推奨する（または推奨しない）シナリオとプロジェクトはどれですか？



Kernighan ：Goは非常に優れた汎用言語であり、新しいタスクにGoを使用することに障害はありません。 ネットワーキングや他の競合タスクを伴うプログラムで最もよく見られるようです。 ゴルーチンは非常に便利で効果的なものですが、この言語はまた、メモリを共有するためのより伝統的なアプローチをうまくサポートしています。 実践では、Goのようなネットワークで作業するための新しいコードを書く人がいることが示されています。 個人的には、以前はC、Java、またはC ++に頼っていたタスクのいずれにも使用します。



また、Goはスクリプト言語としての認識を獲得し、大規模なPythonスクリプトの潜在的な代替品になりました。 これは少し驚くかもしれません。スクリプト言語は、高速で動作する必要があるときに、急いで何かをすばやく「投げる」ために非常に便利だからです。 「スローイン」コードが型エラーや、静的に型付けされた言語でもっと早く検出された可能性のある他のエラーで落ち始めると、問題は後で起こります。 Goは、1行の行をAwkに置き換えません。10行または100行のプログラムのPython、Perl、またはRubyを置き換えませんが、タスクが少し大きく、より深刻になると、型の安全性と効率の組み合わせには確かに少し多くの作業がかかります。

Goを使用する理由

ガベージコレクター、複数ディスパッチ、Common Lispなどの高レベル言語での極端な抽象化、およびAdaやHaskellなどの低レベル言語でのセキュリティ、コンパイル段階でのエラー検出、可読性と速度を愛する私のような人にとってリストされている2種類の言語と比較して、Goを使用する利点は何ですか？ Goは本当に何をもたらしますか？



Kernighan ：実際、Adaと特にHaskellは低レベル言語とあまり似ていません。また、Haskellは通常初心者には手の届かないところにあります。 しかし、申し分なく、それはすべてのピッキングです。 Goには、希望する品質の両方のリストに記載されているすべてのものがあります（もちろん、私の声明の妥当性は批判される可能性があります-「 極端な抽象化 」の意味に依存します）が、便利で効率的な方法で並行性も提供します。フォーム; いくつかの種類のアプリケーションでは、これは深刻な利益をもたらします。



Donovan ：Goは、Common Lisp、C ++、Java、Pythonなどの言語に比べて非常にシンプルに見えます。 マクロ、テンプレート、クラスローダー（ClassLoader）、メタクラスはありません。 これらの機能-これは、PLオタクのように、新しい言語で最初のプログラムを楽しく書くときに急いで遊びますが、大規模に移行した場合にのみ意味はありません。 C ++ STL、Lispの非衛生マクロ、またはPythonの__call__メソッドの過剰な使用のデバッグに費やしたかなりの数日間の不愉快な日々を思い出すことができます。 Goの設計では、各問題を解決するためにお気に入りの「濁った」言語機能をグループ内で使用することよりも、大きなコードベースの単純さ、均一性、認識がチーム全体にとってより価値があると規定しています。

潜在的な行く

Goには、現実の世界でどのような深刻な可能性がありますか？ ApacheやPHP、Python、Rubyなどの既存のオープンソースWebスタックを置き換える上で、Goの可能性をどのように見ていますか？



Kernighan ：神が宇宙を創造するのに6日間しかかからなかった理由は、彼が以前の遺産に対処する必要がなかったからです。 現実的に言うと、どのプログラミング言語も、大きなコードベースを完全に置き換えることはできません。 Goは、多くの場合、新しいプロジェクトや、とにかく既存のシステムを書き直す予定の場所に適しています。 さらに、外部関数インターフェース、特にCライブラリを介して既存のコードに便利なインターフェースを提供できますが、他の人のコードベース全体を大規模に置き換えることは考えにくいです。



ドノバン ：Goが別の言語やライブラリを取り除くのを助ける可能性は低いとブライアンに同意しますが、それは決して彼の目標ではありませんでした。 むしろ、Goは魅力的な代替手段です。 Goの人気の大部分は、標準ライブラリコンポーネントよりもわずか数個のツールを使用して便利なWebサーバーやその他の分散システムを簡単に作成できることにあります。 標準ライブラリは最近作成され、さまざまなシステムを作成する専門家が関与していました。そのため、アプリケーションの開発の最初のステップにはApacheなどのサードパーティサーバーやRailsなどのフレームワークは必要ありません-もちろん、Goにも同様のフレームワークが存在しますが。

Goの公式IDE？

Go用の公式のクロスプラットフォームIDEが開発されていますか？ 経験から、大衆の間での言語の適応は、Googleが提供するAndroid Studio IDEなど、すばやく簡単に使用を開始できる特定のツールセットによって大幅に加速できることが示されています。 Goの予定はありますか？



ところで、GUIについてはどうでしょうか。C++を「降りて」、インターフェースを備えた生産的なデスクトップアプリケーションを開発する機会がようやく得られるのはいつでしょうか。



Donovan ：良いIDEはGoを試してみたい新しい人々を引き付けるのに有利に働くことに同意しますが、私の同僚と私は徐々にVimやEmacsのような非常に伝統的なエディターを使用することに気付きました。 、崇高なテキスト、そしてAcmeでさえ、ほとんどの人がIDEとして考えるものではありません。 注目すべきイニシアチブはJetBrainsからのもので、今年はIntelliJ IDEAでGoプラグインを開発するチームを結成しました。これにより、誰でもGoで書かれたプログラムを他の言語と同じくらい簡単に構築、テスト、デバッグ、リファクタリングできます。



GUIのクロスプラットフォームライブラリについては、 GXUIやShinyのような興味深い実験が既に行われていますが、標準的なソリューションはまだ存在していません。

GoはJavaを置き換える必要がありますか？

GoはAndroidの開発プラットフォーム/言語としてJavaを置き換える必要がありますか？



Donovan ：GoogleのGo開発者は、Goを使用してAndroidおよびiOS用のアプリケーションを作成できるように積極的に取り組んでいます。 興味があれば、GopherCon 2015でHana Kim（Google）の講演をご覧ください 。 しかし今、これは単なる実験であるため、Brownが前述したように、Goの目標は既存の大規模なコードベースを置き換えることではありません。

安全なパフォーマンス

Gnu + LinuxツールチェーンをGoに書き換えると、Cが何十年も提供できなかったセキュリティを提供できます（BASHとOpenSSLの最近のバグを意味します）。 そのような労力のわずかな部分でさえ、Androidのセキュリティを追加します。 1.5のパフォーマンスとライブラリのロードは、実行可能ファイルのサイズを小さくするのに役立ちます。 Linuxベースの再構築に関心のある動きはありますか？



Donovan ：Goは、言語にランタイムセキュリティと簡単なシステムコールインターフェイスがあるため、またコードが迅速に実行されて効率的に動作する静的な実行可能ファイルにコンパイルされるため、この種のユーティリティに適しています。 ただし、ここでも移植性について心配する必要があります.Goプログラム自体は簡単に移植できますが、Goランタイムは少数の重要なターゲットプラットフォーム用にのみ設計されており、その数はgccおよびglibcのサポートよりもはるかに小さくなっています。



私はそのようなプロジェクトを知りません。

tEoPS

プログラミングの方法を学ぶ方法については多くの本が書かれていますが、プログラミングの方法について語るのはほんのわずかです。 ブライアン、あなたの本「プログラミングスタイルの要素」は本当に古典的ですが、私の学生は例を読むのに苦労しています（Fortran 66とPL / Iについてです）。 それらを更新する希望はありますか、またはおそらく別の本がありますか？



Kernighan ：Bill Plagerと私がThe Programming of Programming Styleで使用した言語は、長い間使用されていない（PL / 1）か、強く進化している（Fortran）ため、今日の本のコードはほとんど読みにくいですが、ほとんどのルールは優れていますスタイルはまだ有効です。 ビルと私は一度にCの本のバージョンを書いたが、物事は遠くまで行かなかった。 問題の1つは、ルールの例を見つけることが難しいことでした。 もう1つの問題は、実際のプログラムが以前よりもはるかに大きく複雑になっていることです。そのため、そのような本で使用できるコードフラグメントを見つけて選択することは非常に困難です。 したがって、この本が更新されることはほとんどありません。



他の本に関しては、Josh BlochとScott MeyersがそれぞれJavaとC ++で優れたコードを記述する方法に関する優れた本を書いています。 もっと広く言えば、私は常にSteve McConnellのPerfect Codeが好きで、毎年Fred BrooksのMythical Man-Monthを読んで彼を新鮮な目で見ました。 読む価値のある本のリストはこれに限定されません。 特定の環境やプログラミング言語に関する作品を読んでみてください。

今日の世界のC位

伝説によると、C言語はオペレーティングシステムの開発用に作成されました。 時間が経つにつれて、C ++は「大規模」プラットフォーム用のOS開発ツールとして置き換えられ、前身の組み込みシステム（最大8ビットプロセッサを使用し、256バイトのメモリを必要とするもの）と「大規模」システムのドライバーのみを残しました。 Cにとって、今日の設計上の決定Cとして合理的と思われるものは何ですか？また、現在のタスクに合わせて何を変更するのですか



Kernighan ：覚えておいてください-言語CはDennis Ritchieの仕事の成果です。 私は彼と一緒に本を書いたばかりだと断言します。 デニスは優れた作家であり、プログラマーほど悪くはありませんでした。



これらすべてにより、Cは組み込みシステムとドライバーのプログラミングで非常に人気があり、効率が重要であり、ハードウェアレベルまで下がることができます。 言語の利点の1つは比較的安定していることであるため、今日Cを変更する試みは非生産的なソリューションになると思います。 真剣に、//を使用したコメントのような小さな機能を除いて、ほとんどのプログラマーは1988 ISO標準で提示された形式でCを使用するという疑いがあります（確認することはありません）。 C99とC11の標準は、プログラマの日常業務であまり変化しません。

本を書く動機。

私は興味があります-なぜGoについての非常に多くの本が存在するのに、もう1つ必要なのですか？ 「Goプログラミング言語」は「Go Programming Blueprints」や「Go in Action」とどのように異なりますか。実際には同じ目次を持っていますか？ 別の本の意味は何ですか-別の「Cプログラミング言語」を手に入れたいのですが、Golangについてですか？



Kernighan ：伝道の書12:12で述べたように、「たくさんの本を作るのに終わりはありません」。別の本の必要性についてのあなたの質問は非常に古い話題であるとあなたにほのめかします。



誰かが本を書くとき、彼は常に彼が前任者よりも「より良い」成功することを信じています（または少なくとも心から期待しています）-私は否定的なことを意味するのではなく、新しい本の組織が、例、説明、および記述スタイルは、読者がこの本を役に立つと思うようなものです。 これは、アランと私がGoプログラミング言語で達成しようとしたことです。 Cに関する私の本と同じくらい有用であることが判明した場合、それは素晴らしいことですが、そのような成功を目指しません。



囲aboutに関する既存の本をいくつか見ただけでした（そして、これらはあなたがリストした本ではありませんでした）が、実際には、アランと私は意識的にそれらを読まないことに決めました-私たちが自分の本に取り組むために座ってすぐに見出しを見さえしませんでした、他の著者から無意識に何かを借りたくなかったからです。



Donovan ：私にとっての動機は、Goを学び始めたときに読みたい本を書くことでした。これは、言語とそのライブラリだけでなく、言語設計の原理を明らかにし、その高度な機能を探求し、典型的なトラップ、および言語自体のスタイルと美学も反映しています。



K＆Rとの比較はそれ自体を示唆しています-同じくらい影響力のある別の技術書は知りません。 これは、インターネット世代以前の最も重要な言語の教育ガイドであるだけでなく、その言語への参照であり、その仕様の事実上のものでした。 今日、もちろん、Go Tour、Godoc、およびThe Go Language Specificationが提供されています。これらはすべて、携帯電話から直接利用できます。 ライブラリはより大きく、ユーティリティはより重要です。 言語に関する現代の本は完全に異なるものに焦点を当てているはずであることが判明したので、私たちはそれがすべて一緒に収まる方法を試しました。