Yandexに関するScott Meyersのインタビュー。 C ++の現在と未来について

Scott Meyersは最も有名で有名なC ++の専門家の1人であり、「C ++の効果的な使用」と題された一連の本の著者であり、ほぼすべてのプロC ++開発者によって読まれ、エコシステム全体と言語使用の品質に顕著な影響を与えました。



個人的に、私は学生として彼のほとんどのファンになりました.2000年代初頭に彼の本の根底にあるスコットの記事を読んだとき（その本自体はロシアでは翻訳されていませんでしたが、貧しい学生としてアマゾンから英語でお金を持っていますなかった）。



したがって、彼が開発者向けのトレーニングを行うためにしばらく前にYandexに来たとき、私はこの機会に彼と話をするしかありませんでした。 会話は、彼がC ++とプログラミング全般の将来をどのように見ているのか、さまざまな国やさまざまな業界の開発者がどのように異なるのか、そして彼についてです。















C ++ 11/14の2つまたは3つの最も重要な変更は何ですか？



ほとんどのプログラマーが毎日遭遇することについて話すと、変数と、おそらくラムダ式を宣言するのは自動です。 これらは、2つの最も顕著な変更です。



個人的には、並行性のサポートを検討しますが、これは最も基本的な改善であるC ++ではまったくありませんでした。 この機能は、コンパイラの作成者を除いて、プログラマにとってそれほど印象的ではありません。 しかし、一般の人々への影響について話すと、この特定の機能が最大の影響を与える可能性が非常に高くなります。 明らかに、転送のセマンティクスも非常に重要ですが、この観点からは、並列性がもう少し重要になります。



そして、最も議論の余地のある、または有害な2つの変更は何でしたか？



いくつかのことが思い浮かびます。 どちらも、私が非常に合理的と考えるアイデアに基づいています。 しかし、疑問が生じます。それらは正しく適用されましたか？ 1つ目は、一般的にユニバーサル初期化と呼ばれるものです。 彼女のアイデアは、すべてを連続して初期化するための単一の構文を持つことでした。 これを実現することはできませんでした。いくつかのケースでは不確実性があり、リストの初期化を使用できない状況があり、別のフォームを使用する必要があるためです。 つまり、この機能をそのように実装する必要があるかどうかについては、意見の相違があるようです。



非同期と未来が思い浮かびます。 これは実際には素晴らしいアイデアです。 非同期で何かを実行したいと言うだけで、もう考える必要はありません。 しかし、非同期から生じる先物の動作仕様に関しては、多くの興味深いことが行われました。 これを修正するか置き換えるかについて、委員会内で多くの論争がありました。 私は、C ++ 17以降、この機能を置き換えるために新しい機能が導入される可能性があると考えています。



標準化委員会は十分に効率的に作業を実施していますか？



標準化委員会について私が最初に言いたいことは（そして私はその委員ではありません。これはすぐに示される必要があります）、彼らは非常に難しい仕事に直面しています。 素材には非常に深い技術的知識が必要です。 私は、この委員会のメンバーである人々に大きな敬意を払っています。 彼らが行う作業は非常に困難であり、些細なことでも多大な努力が必要です。



一方で、委員会が言語の開発に携わっていることが明らかになり、言語がどの方向に開発されるべきかについて明確な考えを持つ一人または小さなグループではありません。 そして、それは本当に顕著です。 たとえば、アライメントを決定するには3つの方法がありますが、標準ライブラリは非常に少ないです。

一般的に、委員会は、私の意見では、その仕事をうまく行っています。 もちろん、私は彼らにいくつかのことを違うようにしてもらいたいです。 そして、おそらく、彼らは私に何らかの形で委員会に参加してもらい、仕事に参加してほしいと思っています。 これが委員会に対する私の姿勢です。



おそらく、重要な決定を担当する人が1人いる方が良いでしょうか？



私の意見では、委員会は複数の関係者をまとめるための完全に合理的な方法です。 率直に言って、Björnがすべての決定を下す人になりたいとは思いません。 そのような人の利点は、彼が実行できる明確なビジョンを持っていることです。 C ++では、誰もこの役割を引き受けませんでした。これを行うことができる人は知りません。



他の多くの言語と比べるとわずかな違いがあります。C++は膨大な数のプラットフォームで動作するため、多くのコンパイラメーカーと膨大な数のオペレーティングシステムに対処する必要があります。 異なるプラットフォームで動作する4つの主要なコンパイラーがある言語は多くありません。 幅広いアプリケーションを忘れないでください。 特に、C ++が組み込みシステムに与える影響について考え始める場合。 そこでは非常に重要な言語であり、多くの場合、この業界の人たちから見た世界観は通常のものとはまったく異なります。

一般的に言って、私が言ったように、一人の人が彼が放送できる明確なビジョンを持っていたらいいと思います。 しかし、これはC ++ではほとんど不可能です。



他の言語の場合のように、C ++の一部のバージョンでは後方互換性がない可能性はありますか？



下位互換性を破る決定が下される可能性は、事実上ゼロだと思います。 C ++の強みの1つは、まさに優れた後方互換性にあるように思えます。 数十億行のコードが記述されており、その一部は20〜25年前に登場しました。 他の人が貢献したものを保存しないという決定は、コミュニティにとっては大きすぎるでしょう。 だから、これが起こるとは思わない。



C ++は、簡潔すぎて抽象的で、ほとんどSpartanの標準ライブラリであると批判されることがよくあります。 一部の現代言語のような多様性はありません。 このアプローチは正しいと思いますか？



標準ライブラリが小さすぎて、拡張する必要があることに全員が同意すると確信しています。 どうやら、これは歴史的に起こりました。人々が言語に集中しすぎたためです。 彼らは、適切な言語を作成できるようになるとすぐに、優れたライブラリを作成できると考えていました。 そして、私たちはこれらのライブラリを20年間待っていました。 実際、非常に優れたライブラリを含め、そのようなライブラリがあります。 私たちが望むほど多くはありません。 たとえば、C ++がJavaやC＃と大きく異なる理由の1つは、言語の背後に企業スポンサーがいないことです。 ポイントはクロスプラットフォームです。 私たちが持っているのは、図書館を作成し、それを一般の人々と共有するボランティアだけです。 かなり多くの人々がこれを行っており、それを行っています。これは、すべてが少しばらばらになっているだけです。

標準化委員会は現在、これにもっと注意を払っています。 今、私には、さまざまな人々が一丸となって努力し、1）より多くのライブラリを開発しようとしています。 2）誰でも見つけられる1か所ですべての人に適した単一のライセンスの下で、ライブラリを個別の形式（Boost、Microsoft、Facebook、Adobeライブラリなど）で収集する。 これらのプロジェクトの実施にますます多くの努力が費やされています。 しかし、標準ライブラリが小さすぎて、必要な機能がはるかに少ないことは間違いありません。



STLの著者は、標準ライブラリは小さくアトミックである必要があると考えていました。 これは、私たちの時代には基本的なものがないという理由の1つです。 これについてどう思いますか？



標準ライブラリはもっと​​大きく、基本的な機能を提供するはずです。 2014年であり、標準ライブラリには画面に何かを表示するという概念がありません。 グラフィックスの概念はありません-それはばかげています。 インターネットの概念、URL、URIの概念はありません。 このため、ファイルシステムの概念はほとんどありません。 この役割では、標準ライブラリは非常に役立つと思われます。 ところで、これらの問題を正確に排除するために標準化が積極的に機能できる場所がいくつかあります。 つまり、多くの開発者が直面する共通のニーズがあります。 これがすべて標準的な形になり、誰もがそれがどのように機能するかを理解するまでには長い時間がかかります。



C ++には単一のリポジトリが必要ですか？それは表示されますか？



間違いなく便利です。 これが起こるかどうか、どのような形で実装されるかはわかりません。 しかし、これはすでに既製のライブラリを持っている人に近づくという考えと一致しています。 その後、次のように言うことができます。さてさて、今、すべてのライブラリがどこにあるかがわかりました。 そして、誰もがサポートするライセンスの下でそれらを組み合わせることができれば、誰もがそれらを見ることができる1つの場所にそれらを置くことができ、彼らはそれらを検索することができます。それは？ 待って、見て。



C ++を好まないという事実にもかかわらず、C ++を使用しなければならない多くの人々がいます。 大規模なプロジェクトでは、どのような原則で言語を選択する必要がありますか？



おそらく最後の質問に最初に答えます。 10年前には誰もがそう言っていたので、これは面白いです。12年が過ぎ、誰もが制御された言語に切り替わるからです。 そして、それらは本当に非常に重要ですが、誰もがそれらを使用するわけではありません。 C ++は本番環境で非常に重要な言語のままであるように思えます。 ここでの主な目的は、マシンから最大限のパフォーマンスを達成することです。 これがあなたにとって重要な場合、主な競合他社はまだCとC ++です。 そして、C ++はもう少し表現力豊かな言語です。 私はC開発者ではなく、実際に1人でもないことに注意してください。 しかし、私が1人だった場合、デストラクタについて言及するだけで、C ++への切り替えを検討するのに十分です。 単にデストラクタをコンパイルして取得できるようにするためです。 もちろん、これはほんの一部です。



言語の選択についての質問に戻ります。私にとって、この決定はマネージャーまたはシニアエンジニアによって行われるべきです。 設定する目標、ソフトウェアの目的、従業員が自由に使えるもの、既に構築されているインフラストラクチャを考慮する必要があります。 そして、これらすべてを同時に最適化するために試してみる必要があります。 私はこの問題についてアドバイスをしません。私の仕事はC ++を理解し、開発者がC ++をより効率的に使用できるようにすることです。 C ++を使用するかどうかを人々に伝えることは私の仕事ではありません。



C ++がモバイルデバイスでめったに使用されないのは悪いことですか？ それらはすべて、マネージド言語（AndroidのJava、Objective-C、iOSのSwift）で引き続き動作します。 この領域でC ++をより積極的に適用するときですか？



私は、モバイル市場にあまり厳密には従っていません。 私の知る限り、Androidが登場したとき、全員が発表されました。さて、今度はJavaで書く必要があります。 そして、彼らは言いました：さて、今ではバックドアがあります。これにより、C ++で書くことができます。 また、Objective-Cでも同じです。 そして、C ++を使用できるバックドアです。 したがって、母国語を使用できるのは、開発者がモバイルプラットフォーム用に作成する必要があるからです。 この観点から見ると、モバイルプラットフォーム用のC ++プログラムの数はそれほど多くありません。



開発者はこれを主張します。 さらに、モバイルコードの大部分、特にフロントエンドフレームワークがクラ​​ウドで機能するようになりました。 モバイルサービスについて説明する場合、サーバー上で回転しているものを考慮する必要があり、これらのモバイルデバイスにサービスを提供します。 また、C ++の位置は、サーバーファームで非常に強力です-既存のサーバーからの利益を最大化しようとしています。 したがって、C ++は、モバイルデバイスではなくサーバーで引き続き使用される可能性があります。 しかし、そこで使用できない重大な理由はありません。



今日、あなたは最も有名なC ++エキスパートの一人です。 この言語でプログラミングを始めたきっかけは何ですか？



ある意味では、私なしで選択が行われました。 私はずっと前に、1972年にプログラミングを始めました。 私の最初の言語はベーシックでしたが、1972年にはかなり一般的でした。 しかし、1985年に大学院に入学し、コンピューターサイエンスの博士号を取得しました。 大学院生の職務には、一部のコースにアシスタントティーチャーとして参加することが含まれていました。 当然、私はソフトウェア開発コースのアシスタントでした。 このコースを教えた教授は、ある種の通常のプログラミング言語を使いたいと言いました。 そして彼はC ++を選択し、数年後に私はそれを学ばなければなりませんでした。 だから私はC ++を選択せず​​、C ++が主要な言語であるコースに取り組みました。 それは私がそれでプログラムし始めた方法です。



それでも、あなたは自分の人生をこの言語と結びつけることを好みます。



正直なところ、それは事故でした。 最初にC ++を学び、次に企業のクライアントをトレーニングするためにC ++コースが必要な会社からオファーを受けました。 興味深いオファーでした。 私は大学院生でしたが、仕事はたくさんありましたが、お金はあまりありませんでした。 そして、彼らはちょうど言った：あなたはあなたがすでに知っているすべてを書き留めましょう、私たちはあなたにこれのためにたくさんのお金を払います。 私はそれが非常に魅力的に聞こえると答えました。 だから私はC ++を始めました。 それから教え始め、最初の本「Effective C ++」を書きました。 おもしろいです。1991年に妻がこれをどのくらい続けるかと尋ねると、私はこれがプログラミング言語であると答えました。 25年が経過しましたが、まだこれを行っています。 そのような事故。



どのようにして記事から本に移行しましたか？ 記事の作成と本の作成に違いはありますか？



いくつかの違いがあります。 第一に、この本の性質はより広範な資料を網羅しており、第二に、解決しようとしている問題についてより一般的なビジョンを持つ必要があります。 そして最後に、行動するスペースがもっと必要です。 一方、控えめな計画があれば、本を書く必要はなく、記事だけを書く必要があります。 だから、それはあなたがどれだけ言いたいかにかかっている。 さらに、ジャーナルに記事を書くときは、読者の注意を少しの間保持するだけで済みます。 これにはさまざまなテクニックがあります。読者を挑発し、議論させたいと思うようにすることができます。 それはまるであなたがスーパーマーケットで並んでいる人と話しているかのようです。 これは短い会話であり、ここには非常に小さなトリックがあります。 本は、読者とのより長い接触を意味します。 飛行機に乗っている隣人とこの会話をしたいと思います。 あなたは、あなたと矛盾し、あなたと議論し、6時間のフライトであなたを挑発する人の隣に座りたくないでしょう。 私は2冊目の本を書き直さなければならなかった-私はそれが雑誌の記事に似すぎていると感じた。 この50ページを読んだ後、あなたは夢中になり始めます、これをすべて書いた人を憎みます。 だから、2つのことが頭に浮かぶ：ストーリーの範囲を広げ、トーンを上げる。



異なる都市の視聴者に違いはありますか？ どのタイプのオーディエンスに会ったことがありますか？



各国間の文化の違いは顕著です。 どこかで、彼らは話者と議論して質問することを全く恐れていません。 私はアメリカ、イギリス、ドイツでこれに会った。 そこでは、人々は言うことを恥ずかしがり屋ではありません。待って、何らかの間違いがあります。 そして、私は議論、正当化を与えなければなりません。 他の国では、人々は問題を引き起こさないように努め、何とかあなたを怒らせたくありません。 ところで、私の経験では、人を積極的に巻き込もうとすると、これを打破することもできます。 あなたが彼らと2、3日以上過ごすなら、これは特に簡単です-彼らはあなたに慣れます。 リスナーはしばしば自分の意志で私のパフォーマンスに来ます。 彼らが彼らに手を差し伸べることができたら、彼らは非常に賢く、彼らの考えは興味深いことがわかります。 そのため、開発者の考え方、素材の認識、質問の仕方に大きな違いは見られません。 どこへ行っても、本当に面白い仕事をしている非常に賢い人たちとコミュニケーションを取らなければならないことをとてもうれしく思います。 彼らに追いつくことは、私にとって挑戦でもあり喜びでもあります。



今、コードを書いていますか？



いいえ、それほどではありません。 何年も前、私は自分が開発者ではないと判断しました。 私はかつてソフトウェアを開発し、大学院にいたときに多くのコードを書きました。 私はこれを恥ずかしく思っていました。プログラミングについてみんなに話してください。 しかし、これは私の仕事ではありません。 開発者の仕事は製品を生産することだと私には思えます。 これを行うには、ツール、APIを習得し、最終的に生産的な何かをする必要があります。 彼らは忙しすぎて、開発とC ++の世界で起こるすべてを追跡できません。 しかし、私のタスクは、発生するすべてを追跡し、それを記事、書籍、スピーチに変えることです。これにより、開発者は比較的短時間ですべてを実行できます。 だから私はもはや開発者ではなく、プログラミングにあまり時間を割きませんが、恥ずかしがり屋ではなくなりました。 私も自分の仕事が完璧に理にかなっていると思いました。