インタビュー ++
言語の進化について語る Bjarne Stroustrup 氏
Howard Dierking
コンテンツ
ときには、 飛躍的な進化により、エンジニアリングのあらゆる分野が急激に進歩したり、再構築されたりすることがあります。ソフトウェア開発においては、そうした飛躍は C++ プログラミング言語の登場と共に起こりました。この飛躍は、言語そのものに由来するものではありませんでした。C++ 以前から、Simula67 や Smalltalk などのオブジェクト指向言語は存在していましたが、C++ は C プログラミング言語を基に開発されたからこそ (また、既存の C プログラムをコンパイルできたため)、オブジェクト指向という概念をメインストリームに押し上げることができたのです。
C++ は、設計パターンからメタプログラミングまで、ソフトウェアの設計と開発を取り囲む非常に多くの考えに影響を及ぼしました。そのハードウェア プラットフォーム間での移植性と細かい表現力のため、C++ はより速くて小さいハードウェアの分野で不可欠なものとなるに違いありません。
先日、C++ の考案者である Bjarne Stroustrup 氏にお話を伺う機会に恵まれ、言語に対する考えから業界の全体的な傾向、個人的な読書リストに至るまで、多数のテーマについてお話しいただきました。質問の多くは、私のブログの読者からお寄せいただいたものです。質問をお送りくださったみなさんに感謝します。そしてもちろん、Bjarne 氏にお礼を申し上げます。
言語に対する考え
Howard Dierking プログラミング言語は、言語の熱狂的な支持者のコミュニティなどの形で、非常に深いレベルで人々に結び付いています。これはなぜでしょうか。
Bjarne Stroustrup その質問は、コンピュータ科学者ではなく、心理学者や社会学者、あるいは経済学者におたずねになった方がよいのではないでしょうか。私が思うに、私たちが自分のアイデアを表現するために使用している言語は、私たち自身の一部になっています。だからこそ、1 つの言語しか知らない場合、他の言語の支持者が個人的な脅威として映るのではないでしょうか。その場合の解決策は、より多くの言語をよく知ることだと思います。プログラミング言語を 1 つしか知らないのに、ソフトウェアの分野でプロフェッショナルになれるとは思えません。他方で、お金の絡んだ理由もあるでしょう。基本を理解するだけであればプログラミング言語の壁を越えることはできますが、さまざまな実用的なスキルを習得するとなるとそうはいきません。そのため、たとえば私が X という言語とそのツール セットだけを使用でき、あなたが Y という言語とそのツール セットを支持している場合、あなたは私の生活を脅かしていることになります。繰り返しますが、解決策は複数の言語とツール セットを知る (そして基本をしっかり学ぶ) ことだと思います。残念なことに、この解決策では対処できない問題があります。必要最低限の作業を済ませた後で学習に時間を費やすような余裕はない、というのが大方の現実でしょう。とはいえ、これは熱狂的な支持者であることの言い訳にはならないですね。
HD ソフトウェア開発において、IDE はどのような役割を果たすべきでしょうか。また、IDE はどのように言語をサポートすべきでしょうか。
BS 私は IDE を多用していません。私の言語を理解してくれる応答性の高い IDE エディタは高く評価していますが、IDE を使用せずに作業できることが好ましいと考えています。優れた IDE が広く使用され、実際に IDE が言語の一部 (あるいは言語が IDE の一部) になるのであれば、別の意見を持つかもしれません (図 1 を参照)。私にとって重要なのは、コードの移植性です。C++ を使用することで、ソース ファイルのソース コードだけからシステムを理解できればと考えています。人間の使用できるコードとして表せない変換や生成を伴う IDE のメカニズムは、好ましくありません。
.gif)
Figure 1 The IDE Designer as a Language (画像を拡大するには、ここをクリックします)
HD 不要な要素や可読性については、今日の汎用言語における問題として受け止めておられますか。そうである場合、どのような解決策が考えられますか。
BS シンプルな構文は好ましいと思います。ただし、多くの人々が可読性について不平を漏らしているようですが、表現されていることの複雑さに比べると、実際のテキストはそれほどでもないのではないでしょうか。各種の言語で記述されたさまざまなプログラムを把握することや、(オンラインのサポート窓口からはほんのわずかしか支援を受けられないのに) プログラムを表現するために使用されている構造やプログラム自体のロジックをすべて理解することを望んでいる人々が多すぎるのです。自然言語について考えたり、それらを使用したりする場合と比べてみてください。背景を知らないのにシェークスピアのソネットを理解できると思われますか。最初の古英語で書かれたベーオウルフの場合はどうでしょう。おそらく、私たちはプログラミング言語に期待しすぎているのです。多岐にわたるアプリケーションの領域に必要なものをすべて表現できる言語は、特定のアプリケーションを開発する際には必要以上に複雑であると感じられるものです。それでもこうした言語には、無限に増えるアプリケーションに対応できる必要があります。ドメイン固有言語は特定の状況では役に立ちますが、今はまず、多くの言語とその相互作用の複雑性に対処しなければなりません。
HD 汎用言語は、コンポーネント プログラミングやサービス プログラミングなどのアプリケーション設計のアイデアをどのようにサポートする必要がありますか。
BS 汎用言語は、全般的な概念とアプリケーション固有の概念を表現するライブラリの記述をサポートする必要があります。また、ツールの構築を支援し、アプリケーションの各パーツを結び付ける "接着剤" の役割を果たさなければなりません。そのために言語に求められるものは、柔軟性、表現力に富む型システム、良好な基本パフォーマンス、および長期にわたる安定性です。
HD 多重ディスパッチは好ましい機能でしょうか。
BS はい。従来の単一ディスパッチ オブジェクト指向プログラミング言語 (Simula、C++、Smalltalk、Java、C# など) では、実行時まで正確な型が判別されず、乗算や 2 つの図形の交点の検出などの単純な処理を簡潔に表現できません。作成したコード (二重ディスパッチ、ビジター パターンなどに依存する) は遅く、私たちが望むほど管理が容易ではありません。比較した場合、実行時の多重ディスパッチをサポートする言語 (Dylan や CLOS など) の方が優れています。また、コンパイル時の多重ディスパッチをサポートする言語 (C++ など) が有用な場合もあります。昨年、私が教える学生たちと共同で、多重ディスパッチを C++ にクリーンに追加する方法に関する研究論文を発表しました。多重ディスパッチを使用して作成したコードは、これまでのどの手段を利用した場合よりも短く簡潔になりました。また、使用するメモリも減り、実行速度が上がりました (
図 2 を参照)。けれども、こうした成果は C++0x には間に合いませんでした。多重ディスパッチについての論文は、
research.att.com/~bs/multimethods.pdf からダウンロードできます。
.gif)
Figure 2 Multiple Dispatch via Multiple Inheritance (画像を拡大するには、ここをクリックします)
HD 今日の C++ における共変性や反変性についてはどのような考えをお持ちですか。現在の動作は今後の言語のバージョンでは変わると思われますか。
BS それほど変わらないと思います。この領域では、C++ は果たすべき役割を果たしていると思います。あなたは、vector<Apple> を vector<Fruit> に変換するような例を考えておられるのでしょうか。vector<Fruit> が不変でない限り (または、Orange を追加することができなければ)、これは非常に危険です。黙示的な実行時の型チェックがこうした問題に対する有効なアプローチであるとは思いません。
HD メソッド呼び出しではなく、メッセージ渡しを主要な言語の機能とすることについては、どのように考えておられますか。
BS 明示的なメッセージ渡しは好きですが、随分前に、分散システムのコンテキストで使用したきりです。現実的には、幅広い場面で使用できるように、言語やツールでのメッセージ渡しのサポートについて真剣に取り組まなければならないでしょう。これまでそれが行われてきたとは思いません。私が間違っているかもしれませんが。メッセージやメッセージ キューに頼れば、共有やロックにかかわる多くの問題が解決します。C++ 標準ライブラリで実現できればよいのですが、2 ～ 3 年のうちに可能かもしれません。
HD 汎用言語では、多種多様なユーザーを同時にサポートすることと、コードの表現力および設計の簡潔さを向上させることは、本質的に競合するのでしょうか。後者を実現するうえでの言語の役割は、どのようなものでしょうか。
BS 特化を通じて設計を簡潔にできるのは確かです。こうした意味では、競合はあると思います。また、対象ユーザーが少なければ (ユーザー コミュニティが小さければ) その好み (だけ) は満たせますし、そのユーザー コミュニティをコントロールして ("型の理論を研究して、これを使えるようになる必要があります" などと伝えて)、従来の表記や概念から引き離すこともできるでしょう。汎用言語は、多種多様な用途をサポートする必要性に加え、前提や学習背景が異なる人々の大集団に教えやすいものでなければならないという要件からも制約を受けます (基礎については、言語を熟知していない教師のもとであっても高校生が扱えるようなものが必要)。
だからこそ、簡潔なコードを汎用言語で表現できる限りは、汎用言語は簡潔さの向上に貢献できると思います。C++ の場合、非常に簡潔なコードを記述できます。広く利用されている汎用言語なので、そうした例はだれでも入手可能です。また、大勢の人々が目を通せる記事や教科書に取り上げることもできます。特化した言語には、簡潔という長所はあるものの、そうした選択肢はありません。
HD 私たちはアーキテクチャを重視しすぎているのではないでしょうか。
BS 少なくとも私が定義するアーキテクチャについては、そのようなことはありません。それどころか、アーキテクチャは軽視されすぎています。また、構造の原理をほとんど理解しないままに質の低いコーディングが広く行われています。アーキテクチャに関する大きな問題は、多くのプログラマがコードの良さを活かす方法を明確に理解していないことにあると思います。優れたコードを見た際に、そう認識できるだけでは十分ではありません。また、してはならないことを把握しているだけでは不十分です。私たちには明確な規範的ルールが必要なのです。
HD オープン ソース コミュニティは、ソフトウェアの品質、設計、および職業意識に貢献しているでしょうか。それとも悪影響を及ぼしているでしょうか。あるいは、何の影響も及ぼしていないでしょうか。
BS それは本当に難しい問題です。オープン ソース コミュニティが貢献している (コードの品質や関与している人々の職業意識を高めている) ケースや、悪影響を及ぼしている (実に酷い習慣や心構えを教えている) ケース、とても話せないような多くのケースも見てきました。
コミュニティへの全体的な影響がどういう状態にあるのか、どのようなことがオープン ソースの取り組みのレベルを高めているのか、あるいは下げているのか、私には知る由もありません。単純に、私にとってコミュニティは推測するには大きすぎるのです。
言語の傾向
HD 近い将来、動的言語への大きなシフトが起きると思われますか。
BS そうは思いません。りんごとオレンジを比較するようなことがあまりに頻繁に行われています。一般に、静的言語と動的言語のどちらか 1 つを選ぶことができるとは思いません。また、言語はその 2 つのカテゴリにきれいに分けられるとも思いません。すべてとは言いませんが、ほとんどの動的言語は静的に判断される側面を持ちますし、主要なあらゆる静的言語では、値の意味を実行時に判断する必要のあるコードを記述できます。もちろん流行はあり、それについては予測できませんが、多くの現実の言語は、アプリケーションの要件、アプリケーションの領域、または対応できる開発者のスキルに基づいて合理的に選択されるものと考えています。たとえば、Ruby で Java ランタイムを実装しようとは思いませんし、対話性の高いシミュレーション言語を C++ で表現しようとも思いません (その実装とは逆に)。
HD 最終的に void*、variant、object などをすべて取り除くのは適切だと思われますか (図 3 は良い例です)。
BS 原則として、あらゆるキャッチオール オプションを取り除くのは良い考えだと思いますが、実際には、表現するものすべてを完全に分類して必ず詳細に指定できるようにすることでしか、実現できないと思います。たとえば、どんなオブジェクトにも何らかの影響を及ぼすことができるような実関数は見たことがありません。何かを行うとき、自分が操作しているものについて必ず何らかの推測を立てるものです (反例として思い付く最も近いものが、純粋な転送関数です)。C++ の世界における概念に関する現在の取り組み (ジェネリック アルゴリズムの制約と要件) が、ここで役立つでしょう。とはいえ、予測できないニーズに対処するための "明確にはわからないが、何らかのもの" を表現する真に包括的なメカニズムなしには不可能だと思います。
HD 柔軟に型指定された言語に再びシフトする傾向にありますが、ハンガリアン記法をもう一度考慮に入れるべきでしょうか。
BS そうした傾向があるとは知りませんでしたが、柔軟に型指定された言語に向いている作業全体の各部分では増えてきているのでしょう。言い換えると、柔軟に型指定された言語の使用は急速に増えていますが、静的に型指定された言語の使用はまだこれから増える可能性があるのです (私はそう思います)。そして質問への回答は "いいえ" です。ハンガリアン記法は使用すべきではありません。ハンガリアン記法は危険な考え方です。ソース コードはプログラムの意味を反映するべきであり、型システムをまねるべきではありません。ハンガリアン記法の必要性を本当に感じている人がいるとすれば、その人はおそらく開発中のアプリケーションに適していない言語を使用しているのでしょう。
HD 2000 年に、あなたは「C++: A New Language for a New Millennium」というプレゼンテーションを行い、Wrap<T> という概念を紹介されました。これは本質的にはアスペクト指向プログラミング (AOP) です。AOP については概してどのように考えておられますか。また、Wrap<T> パターン (pointcut や advice など) の正規化についてはどのような考えをお持ちでしょうか。
BS 明確な答えを出せるほど AOP に時間を費やしていません。私は、言語でサポートされる ("サポートされない" でも "ツールによってサポートされる" でもありません) 構成 (特に、煩雑でない構成) を好みます。そのため、言語外のツールや非標準のツール チェーンに憂慮しています。C++ テンプレートは、煩雑でない構成に関してはすばらしい成功を収めてきました。標準テンプレート ライブラリ (STL) や組み込みシステム プログラミングでのいくつかの使用例を見てください。柔軟でない階層や設計済みの階層に無理に合わせることなくアイデアを組み合わせることができるという点は、実用的な長所です。ただし、一部の開発者や管理者にとって管理が困難だったのも事実です。また、記述が非常に多くなります。C++0x では、柔軟性やパフォーマンスに影響を及ぼすことなくこれに対処しようという試みがあります。
HD C++ 言語の一部の特性は、意図しない厄介な結果 (マクロなど) を生み出す可能性をはらんでいます。一般に C++ や新しい言語において、その他にどのような意図しない結果が解消されるとよいと考えておられますか。
BS 実際、私が C を使い始めたころ、マクロは厄介な存在だと考えていました。ところがほとんどの人々と同じように、その厄介さとさまざまな悪影響を過小評価していたのです。10 年前に優れた C++ 開発環境がなかった大きな理由は、C のマクロの濫用にあると思います。C++ では、オブジェクトを初期化する方法が多すぎます。また、わかりにくい方法も存在します。これには C++0x の統一メカニズムで対処できればと考えています。前の質問に対する回答で、テンプレートについて言及しました。これは後期の C++ (1985 年より後) で収めた大きな成功でしたが、言語を過度に使用していました。繰り返しますが、C++0x の一部はこうした問題に対処するためのものです。
この数年で私たちが発見した大小さまざまな問題は、互換性の理由から C++ では解決できません。たとえば、宣言構文は必要以上に複雑です。ほとんどの線形表現の方が適切でしょう。同様に、多くの既定の要素に問題があります。たとえば、コンストラクタは既定では変換であってはなりませんし、名前は既定では他のソース ファイルからアクセス不可能であるべきです。リンカの未制御により、たえず問題が発生していました。特に、実装者は互換性のない形式で同様の機能を提供することに喜びを感じているように思えます。
嬉しい驚きもありました。最も目を引いたのは、リソース管理や (例外を使用した) エラー処理に関係する手法でデストラクタが幅広く使用されたことです。私は、デストラクタは良いアイデアであると考えていました。結局のところ、コンストラクタの影響は元に戻す必要があるからです。ところが、C++ を活用するうえでデストラクタがどれほど重要であるかを完全には理解できていませんでした。
HD あなたはご自身の Web サイト上で、「簡潔さは言語自体に求めるのではなく、構築されるアプリケーションに求めるべきだと考えている」とコメントしておられます。こうした考えをまとめたものが、ドメイン固有言語 (DSL) に向かう動きなのではないでしょうか。
BS ほぼそのとおりだと思います。多くの場合、その方向での試みです。場合によっては、成功しさえするでしょう。
HD DSL には概してどのような考えをお持ちですか。また、DSL と汎用言語の関係をどのように捉えておられるのでしょうか。
BS 私は、鳴り物入りで設計、実装、導入されるのに、たいした影響もなく消えていく言語の数に憂慮しています。この間 (つまり通常は多年にわたる開発フェーズの間) に、実際にはリターンがないにもかかわらず、新しい言語によって大量のリソースが消費されています。この現象については、『A Rationale for Semantically Enhanced Library Languages』(
research.att.com/~bs/SELLrationale.pdf) という題名の論文を書きました。私は、ツールや汎用言語によってサポートされ得るライブラリの使用には賛成しています。
私が思うに、DSL は最後の手段であるべきです。最初の手段であってはなりません。DSL は、可能な限り汎用言語や標準的なツール チェーンに根差したものでなければなりません。DSL を実装したり、そのランタイム プリミティブを実装したりするには、汎用言語 (または、最低でもシステム プログラミング言語) が必要です。私が最も望ましいと考えるのは、DSL を少なくとも 1 つの汎用言語に意識的に対応させることです。これにより、その汎用言語で記述されたライブラリを使用して新しい機能を簡単に追加できるようになります。プロフェッショナルは複数の言語を習得する必要があるとはいえ、さまざまな DSL を使用することで積み重なった複雑さは問題になるほどではなかったのでしょうか。また、多くの (ほとんどとは言わないまでも) DSL は、汎用言語に "なりたがっている" ように見えます。
HD C++ の多数の構成要素は、さまざまなハードウェアの多様な定義のために、意図的にあいまいなままにしてあると述べておられます。相互運用性には、これらの構成要素のあいまいさを排除できるほどの向上は見られましたか。
BS "あいまいさ" は適切な表現ではありません。あまりにも多くの要素が、未定義のまま残されているか、実装時に定義されている状況です。もし私が C++ をゼロから再定義できるなら、未定義の動作はなくなり、実装時に定義される動作もはるかに少なくなるでしょう。とはいえ、私はタイム マシンを持っていませんし、今日の分析力を持ってしても、何億ものコードの行を分けることなどできません。
手法とベスト プラクティス
HD 普段どのような処理手法を使用したり、教えたりしていますか。
BS アプリケーションの主要な概念を把握すること、役立つライブラリを特定すること、アプリケーションの概念をサポートするために新しいライブラリを構築すること、アイデアは早く試してみること、早期に統合すること、早期に、そして頻繁にテストすること、設計ツールとしてドキュメントやチュートリアル資料を使用すること、小さなプログラムから大きなプログラムに成長させること (途中で繰り返すこと)、などです。私が今比較的規模の小さいプロジェクトに重点に置いていることがよくわかるでしょう。
HD 言語と開発手法の間には、共通部分や相性があると思われますか。
BS ライブラリ設計を設計/開発手法として捉える限りは、そうだと思います。レベルが高まり続けている (アプリケーションに近づきつつある) 機能にライブラリの構築を通じて取り組むと、言語に対して要求が生じます。この点は誇張しているわけではありませんが、COBOL、C、Java、C++、Python 向けの単一の開発手法があるとも、各言語から最小限のサポート以上のものを得られるとも思っていません。
HD ソフトウェアを開発する際の個人的な経験則はありますか。
BS 主要な概念、ソフトウェアのインターフェイス、リソース (メモリ、ファイル、ロックなど) の管理、エラー処理を重視することです。クラスの適切な不変性の設計や、RAII (Resource Acquisition Is Initialization: リソースの確保は初期化時に行う) は、重要な手法です。
HD アジャイルであると面倒も多いものです。"アジャイル" はあなたにとって何を意味するのでしょうか。C++ はアジャイルをサポートしていますか。
BS 私はその表現を使っていません。あまりに漠然としすぎています。何を意味するにせよ、C++ はもちろんアジャイルをサポートしています。
将来を見据える
HD テンプレート、動的イベント、自己記述コードなどの高度な機能をサポートする一方で、初心者が使用しやすい状態を保つために、言語はどのように進化し得るでしょうか。
BS わかりません。一般的な答えはないと思います。新しい機能は、それらが言語のコンテキストでより効率的な手法をサポートするのであれば重要です。ただし、安定性も不可欠です。C や C++ が力を発揮し続けている理由の 1 つとして、標準委員会によるケアが挙げられます。これは、古い (ときには何十年も前の) コードの有効性を保ち、新しい機能の統合を円滑に進めるための作業です。控えめに言っても、簡単な作業ではありません。新しい機能の導入は、常に成功するとも限りません。標準委員会のメンバーは、初心者への配慮を忘れることがよくあります。統一された初期化、自動キーワード (変数型をその初期化子から推定するため)、テンプレート引数の要件のチェックなどの概念をはじめ、C++0x で計画されている主要な機能の一部は、専門家以外のユーザーが言語をより簡単に使用できるようにするうえで役立つでしょう。
HD 言語のメタデータは、将来のプログラミング言語の重要な土台であると考えておられますか。
BS いいえ。個人的には、メタデータの多用には抵抗があります。
HD CPU のコア数が増え始めた場合、同時実行には根本的な変化が生じると思いますか。C++0x では同時実行の課題にはどのような方法で対処できるのでしょうか。
BS C++0x は、マルチスレッドに適したマシン モデル、ライブラリ構築用の低レベル プリミティブ セット、スレッドおよびロックのライブラリ API などの基礎的な要素を提供します。それ以上のもの、特に、スレッド プール、フューチャ、メッセージ キューに基づくよりシンプルで高レベルな同時実行モデルも提供できればと考えています (おそらく 2 ～ 3 年の間には可能でしょう)。多数のプロセッサへの計算の分散と、それらのプロセッサでのアクティビティのローカライズを自動化 (またはほとんど自動化) する方法を見つける必要があります。この領域には C++ と同様に多くの仕事が残っています。まだ主流のモデルはありません。例として、Texas A&M University の STAPL や Intel の TBB が挙げられます。
HD グラフィックス プロセッシング ユニットでの汎用コンピューティング (GPGPU) についてはどのような考えをお持ちですか。
BS 非常に興味深いですが、私には実際の経験がないので、専用プロセッサを使用するには豊富なスキルが必要だという事実しかコメントできません。
HD ハイ パフォーマンス コンピューティング (HPC) はプログラマに対して最終的には透過的になると予想されますか。さらに、この目標は言語、またはライブラリやフレームワークにとっての目標なのでしょうか。
BS ある程度透過的にはなるでしょう。とはいえ、同時実行を完全に透過的にできるとも、そうすべきであるとも思いません。まず第一に、エラー処理は、プロセッサの可用性、共有メモリ (非共有メモリ)、分散 (非分散)、および待ち時間に応じて大きく異なる可能性があります。必要に応じて透過性を見積もることは、新しい言語、言語の新しい機能、および (私が好む) 新しいライブラリの目標であり続けることでしょう。後者については、基になっている言語でマシン モデルと非常に低いレベルのプリミティブ セットがサポートされている場合にのみ実現可能です。C++0x はこれをサポートしています。
HD C++0x の設計の進捗状況はいかがですか。
BS やっとのことで、完成に近づいています! 少なくとも私はそうであってほしいと思っているのですが、決議が下されるまでは何が起こるかわかりません。完成を前にして、切迫した状態にならないとも限りません。現在の予定では、新しい完全な標準を 6 月の公式発表に向けて決定することになっています。12 ～ 18 か月後に新しい正式な標準が完成するでしょう。間違いなく、私は "標準はどのようにして作り上げるのか、何を基本原則とすべきなのか、正確には何が含まれているのか" という 1 つのテーマで書籍を書き上げることができます。いや、既に書き上げているのかもしれません。
research.att.com/~bs/hopl-almost-final.pdf から入手できる HOPL の論文『Evolving a language in and for the real world: C++ 1991-2006』と、私のホーム ページでタイトルに C++0x が含まれるページを参照してください。研究熱心な方には、Web 上で "WG21" を検索して、ISO C++ 標準委員会のすべての記事 (あらゆる提案が含まれています) を探すことをお勧めします。少なくとも、たいへんな取り組みであることをおわかりいただけるでしょう。広く使用されているプログラミング言語に改良を加える作業は、困難を極めます。特に、多数のツール、言語、およびアプリケーションの実装レイヤでは難しい作業です。私や他の開発者が作成したいくつかのビデオも、オンラインで、または私の C++ のページで入手できます。
書籍と電話
HD 今、何を読んでおられますか。
BS 技術資料では、マシン アーキテクチャについての考えを新たにするために、Hennessy と Patterson を読み直しています。また、人々が質の高いコードを記述するうえで役立つ論文や記事を集めているところです (私が教えているコースのため)。そのような記事を見つけるのは、予想よりはるかにたいへんです。学術論文は非常に専門的ですし、それ以外の論文は、役立ちそうだと思っても根拠に欠けていることがよくあります (ご提案は大歓迎です)。それからもちろん、C++ の標準化に関する膨大なドキュメントを読んでいます。Knuth についての理解を新たにしようとしていたのですが、第 3 巻を持っていってしまった人がいるので、お預けになりました。気晴らしに、O'Brian のオーブリー & マチュリン シリーズを少し読んでいます。科学についての理解を新たにしようと思っており、Richard Dawkins をちょうど読み終えたところです。その他、Rodger の『Command of the Ocean: A Naval History of Britain, 1649-1815』を最近読了しました (今 O'Brian を読んでいるのはそのためです)。
HD あなたは、「コンピュータが電話と同じくらい簡単に使えるようになればいいといつも思っていたが、私の願いはかなった。もはや電話自体の使い方がわからなくなってしまったからだ」と述べておられます。あなたはスマートフォンをお持ちですか。また、スマートフォンはいくらか使いやすくなっていますか。
BS 私は電話が大好きというわけではありません。面と向かい合ったコミュニケーションの方が好きですし、それが難しい場合は書かれた言葉を読みたいと思っています。どんなに高機能な電話も、うまい表現の電子メールにはかないません。私は、ポケットにすっきり収まるスリムな電話を使用しています。その全部の機能は使っていません。音質や信頼性に関する機能には、お手上げです。とは言うものの、私が先の発言をしたころに比べて、ユーザー インターフェイスははるかに使いやすくなってきています。
Howard Dierking は MSDN Magazine の編集長です。