専門用語の必要性
最初に方程式と訳した者を尊敬する・・・
通じないかもしれないのにな・・・
ただの幸運なバカがたまたま使ってみたら大丈夫だったのか・・・？
それとも・・・訳語の必要性に追いつめられた必死さが切り開いた発明なのか？
用語の翻訳は難しい。ある単語を、長文を費やして、別の言語で説明することは簡単だ。たとえば、方程式は、wikipediaの文章によると、「さまざまな対象の間に成り立つ数学的な関係を記号を用いて等式などの式によって表したもの」となっている。しかし、わざわざ毎回こんな長文を使うのは、甚だ面倒である。よって、我々には、お互いの了解しあえる、短い単語が必要である。
しかし、「等式など」という言葉には引っかかる。方程式は、等式以外も含むのだろうか。方程式の英語の訳語としては、どの辞書でも、Equationであるが、これは文字通り、等式である。考えてみると、方程式が、等式だけを意味するのかどうか、その名前だけでは、いまいち分からない。あるいは、方程式をequationと訳すのが間違っているのだろうか。そう考えると、方程式とは、あまり適切な用語では無いのかもしれぬ。
話がそれた。本来、方程式という言葉を云々する予定はなかった。しかし、用語の翻訳の難しさは理解してもらえたと思う。
用語は必要である。我々は数学を論ずるとき、方程式という言葉を、お互いが了解しているものとして使う。わざわざ、長文を用いたりしない。
しばしば、「技術者は専門用語を使わずに、一般人にも分かりやすく話すべきだ」という批判を聞く。分かりやすく話すべきなのは、もちろんなのだが、専門用語を使わずに話すのは、非常に面倒なのである。例えば、
数学者A、「それでね、この「さまざまな対象の間に成り立つ数学的な関係を記号を用いて等式などの式によって表したもの」Aと、「さまざまな対象の間に成り立つ数学的な関係を記号を用いて等式などの式によって表したもの」Bを使ってだね」
数学者B、「いや、それは計算が甚だ面倒だ。実用に足る近似値は、「さまざまな対象の間に成り立つ数学的な関係を記号を用いて等式などの式によって表したもの」Cでも計算できる」
数学者A、「それでね、この方程式Aと方程式Bを使ってだね」
数学者B、「いや、それは計算が甚だ面倒だ。実用に足る近似値は、方程式Cでも算出できる」
主婦A、「あらあら、お隣の奥さん。ちょっと聞いてちょうだいよ。向こうのスーパーでね。今日はね。「ニワトリという動物のメスが卵細胞や、多少発生（→胚発生）が進んでも見かけ上それがわからない状態で体外（外環境）へ産み出すもの」が安かったのよ！ 「ニワトリという動物のメスが卵細胞や、多少発生（→胚発生）が進んでも見かけ上それがわからない状態で体外（外環境）へ産み出すもの」が！」
主婦B、「あらまぁ、ほんとぉ？ でもねぇ、あいにくと、「ニワトリという動物のメスが卵細胞や、多少発生（→胚発生）が進んでも見かけ上それがわからない状態で体外（外環境）へ産み出すもの」はおととい、たくさん買ってしまったのよぉ。残念ねぇ」
主婦A、「あらあら、お隣の奥さん。ちょっと聞いてちょうだいよ。向こうのスーパーでね。今日はね。タマゴが安かったのよ！ タマゴが！」
主婦B、「あらまぁ、ほんと？ でもねぇ、あいにくと、タマゴはおととい、たくさん買ってしまったのよぉ。残念ねぇ」
このように、共通の用語がない場合、文章や会話は、非常に分かりにくいものとなってしまう。専門用語を廃した結果、よりわかりにくくなってしまうとは皮肉である。
つまり我々には、専門用語が必要である。しかし、方程式やタマゴのように、すでに一般に知られている用語ならともかく、まったく新しい事柄に対する専門用語は、どのように発明すればいいのだろうか。
C++0xの用語
C++0xには、様々な新機能が追加されている。そして、新機能を言い表す、簡潔な用語がある。しかし、その用語は、英語である。C++0xの日本語の本を書くからには、この用語を、どのように表記するかという問題がある。
用語は、一人の天才によって決まるわけではない。もちろん、きっかけを作る人間はいるが、結局、最もよく使われている言葉が、自然に選ばれるようになるのである。
たとえば、"address" という用語がある。現在一般的な訳語は、「アドレス」である。ところが、一昔前のプログラミングの本を開くと、しばしば「番地」という用語が見受けられる。アドレスというのは、音訳である。その発音を自国語の文字で表現する訳しかたである。番地というのは、和訳である。これは、非常にセンスを問われる。
これ以外に、訳さないという選択もある。すなわち、"address"というアルファベットの表記を、そのまま用いるのである。これを、今仮に、「原語」と呼ぶことにする。
音訳、和訳、原語、どれが最適なのかは、一概に決定できない。
C++には、"reference"という用語がある。現在、もっとも広く使われている訳語は、「参照」であると思われる。しかし、私はこれには、少し問題があるとおもう。
int x ;
// a pointer p reference x.
int * p = &x ;
// dereference p.
*p ;
// a reference r reference x.
int & r = x ;
これを日本語に訳すと、どうなるだろうか。
int x ;
// ポインタpは、xを参照している。
int * p = &x ;
// pを参照する。
*p ;
// 参照 r は x を参照している。
int & r = x ;
referenceの名詞、動詞、dereferenceは、すべて参照、あるいは、参照のサ変活用で訳される。これは、どうも分かりにくいと思う。私は、名詞としてのreferenceは、referenceをそのまま使うか、リファレンスと訳してもいいのではないかと思う。しかし、すでに参照という訳語が定着しているのも、また事実である。参照、リファレンス、reference、どれがわかりやすいだろうか。
C++0xでは、ただのreferenceというものはなくなり、それぞれ、lvalue reference、rvalue referenceと呼ぶようになる。単にreferenceと行った場合は、その両方を指す。
ここで、lvalueとrvalueを、左辺値、右辺値と訳すのは、C++においては、適切ではない。C言語ならば、それで正しかったが、C++では、左辺、右辺とは、なんの関係もないからだ。したがって、C++のrvalue referenceを、「右辺値参照」などと言っている人間や書籍は、信用してはいけない。その人は、lvalueとrvalueが何を意味するのかもわかっていないのである。しかし、lvalue/rvalueを、一体どう訳せばいいのだろうか。
音訳すると、エル・バリュー、アール・バリューになる。これはあまりにもひどい。L値、R値と訳すべきか？ これも分かりにくい。
結局、私の考えとしては、lvalueとrvalueとは、そのままアルファベットで表記するしかないように思える。とすると、rvalue参照、rvalueリファレンス、rvalue referenceの、三つの翻訳候補ができあがる。どれがわかりやすいだろうか。
referenceは、まだマシである。lambdaとなると、完璧に新しい事柄なので、非常に難しい。訳語は、無名関数、ラムダ、lambdaのどれかになるだろう。私はlambdaが最適だと思うが、これは畢竟、私が多少なりとも英語をかじっているから、そう思うのかもしれない。英語と数学の知識がまったくない人間にとっては、無名関数が一番わかり易いだろう。さらに、lambda-introducerとなると、さらに難しい。
実を言うと、私は、派生クラス、基本クラスという用語も、気に入っていない。C++では、derived class、base classという用語が用いられる。これを、派生、基本と訳すのはどうも気に入らない。一般にオブジェクト指向では、サブ・クラス(sub class)、スーパークラス(super class)という用語が用いられるのだが、なぜC++では、元々の英語からして、このような用語を使うのだろうか。その理由の一端に、他ならぬBjarne Stroustrup自身が、サブクラスとスーパークラスとで、どっちがどっちだか、よく迷うからという理由があった。これは、本人がD&Eで告白している。
The names derived and base were chosen because I never could remember what was sub and what was super and observed that I was not the only one with this particular problem.
derived（直訳：派生）とbase（直訳：基本）という名前は、私が、どちらがサブで、どちらがスーパーなのか、一度も覚えられた試しがなく、またこの問題のあるものは、私だけではなかったという理由で、選ばれた。
Bjarne Stroustrup, The Design and Evolution of C++, section 2.9
確かに、私個人としても、サブとスーパーはよく分からない。なんとなく、スーパーの方が強そうだから、スーパークラスはサブクラスを継承するものではないか、と思うことがよくある。
してみれば、他ならぬBjarne Stroustrup自身も、用語に困っているわけである。
話を元に戻すと、derived、baseをそれぞれ、派生、基本と訳すのは気に入らないが、少なくとも、どっちがどっちかという疑問を起こすことはないと思う。したがって、これはまだマシな訳語であると思う。
テンプレート周りの用語は、さらに厄介である。例を挙げるだけで、考察はしないが、Instantiation、Two Phase Lookup、Argument Deduction、Depandant Name、等々。テンプレート以外でも、まだ考察すべき用語は沢山あるが、用語の一覧を作るのが目的ではないので、この辺でやめておく。
私の執筆する予定のC++0x本では、これらの用語を使うし、意味も解説する。これは絶対に書く。いやしくもパーフェクトなどと冠したC++0x本で、これらを解説しないという事はありえない。
ついでに言うと、私はパーフェクトなどという本のタイトルも気に入っていないが、それはまた別の話である。タイトルは私が考えたわけではないので、どうか私を責めないでもらいたい。
結論
結局、用語の翻訳には、音訳、和訳、原語をそのまま使うという、三つしかない。今考えているのは、仮に音訳か和訳を使うとしても、必ず一度は、原語を併記するというものである。
ひとつ恐れていることとしては、私は英語を知っているということである。私は無意識のうちに、英語を知っていることを前提にした文章を書いてしまわないかという懸念がある。
私は少なくとも、規格書を読める程度には、英語を知っている。もちろんこれは当然のことで、現時点でC++0xの本を書くとなれば、規格を読めなければならない。個人的に、すべてのプログラマは英語の読み書きが出来るべきであると考えている。もし私が、自分の為にパーフェクトなC++0xの本を書くとするならば、当然、英語で書く。その方が余計な苦労をしなくてすむからである。多くの有名なライブラリは、ドキュメントが英語で書かれている。英語が読めなければ使えない。誰かが翻訳してくれるのを、他力本願で祈るしかない。
ところが、現実はそうではない。世の中には、英語を知らないプログラマがたくさんいる。私はかつて、ある会社の求人の面接に行ったが、
「プログラミングに最も大事なことはなんであると思いますか？」
という問に対して、
「英語です。プログラミングというのは、自分で実装するよりも、むしろライブラリを使うことが多いと思いますが、有名なライブラリのドキュメントは、英語で書かれているものが多いのです。したがって、最も必要なものは、英語の読解力だと思います」
と答えたところ、面接担当のひどく肥満した大阪人の中年のプログラマに、
「ヘェー、そーなん。ボカァ、英語なんてさっぱり分からないんやけど。ナハハハハハ」
と笑われたことがある。現実はそんなものである。
ちなみに、その会社は、関数を使わずmainに全部書けば、一番早くなるとも言っていた。彼らは、コードもCPUのキャッシュを圧迫するということを知らないらしい。ちなみに、その会社は、組み込み系特化というわけでもなかった。
世の中にはこの程度の認識のプログラマが多い。思うに、これは、本人が悪いのではない。参考書が悪いのである。特に、日本語で書かれたC++の本は、たいがい、あまりよろしくない。私は今まで、あまりにもひどい参考書を、腐るほど見てきた。全くの誤解を書いているものもあれば、あるひとつのプラットフォームにおける話を、すべてのプラットフォームに拡大出来るものと信じている本もあった。私の本は、これらの悪書の轍を踏まぬようにしなければならない。あくまで純粋な言語としてC++を解説し、環境依存の話は、できるだけ避け、またどうしても書かなければならない場合にも、環境依存であることを明記するつもりである。
私が書く予定のC++0x本の対象読者は、もちろん日本人のプログラマである。私は英語を知らない日本人に理解出来るように、日本語で書かなければならない。これは英語で書くより難しい。
