Guido への5つの質問/Five questions to Guido

回答 1

これはとてもおもしろい質問ですね。私は自分自身では英語の使用に関して快適に感じ（過ぎ :-）ているので、Google+ で人々の意見を聞いてみました。そこで、この問題には様々な見方があることがわかりました。1 番極端な反応は「全ての人間が英語を習うべきである。」というものでした。言うまでもなく、私はこの意見に反対します！それは母国語やその書き方が英語に似ている人々にとっては簡単でしょうが（例えばオランダ語、私の母国語です）、多くの地域に済む人々にとっては大きなハンディになります。

私はまた、これと真逆の極論も受け入れる気はありません。それは言語のキーワード（組み込みの名前や標準ライブラリなども）そのものを別の（自然）言語でも書けるようにするというものですが、これはコードの共有を殆ど困難にしてしまいます。ですので、全ての Python プログラマーは いくばくかの 英語を学ぶ必要があります-- ですがその言語を喋れる必要はありませんし、書くことさえ出来なくても構いません -- 必要なのは、言語の 1 部である（擬似的な）英単語（if, def, len, dict, None, ZeroDivisionError 等です）と、標準ライブラリで使用されている英単語（例: random, socket, pickle, optparse）をタイプできることです。この例を見れば、例え英語を話す人でも、これらの単語と意味については学ぶ必要があることがわかるでしょう。

メッセージカタログと docstring の具体的な話しに入る前に、Python 3 では Python ソースコードに Unicode が、識別子に対しても使えることを思い出しておいて欲しいです。Python 3 のソースコードは UTF-8 でエンコードしてあると仮定されています。これにより、コメントや文字列に任意の Unicode 文字を使うことができますし、識別子内に Unicode 文字を使用することもできます（詳細については PEP 3131 を見てください）。もちろん、日本語の識別子やコメントを使用すれば、外国人はそのコードを読んだり理解することはできなくなるでしょう。しかしこれでも大丈夫なケースも多くあります -- 例えば、あなたがまだプログラムの学習をしている場合、日本企業のためにプロプライエタリなコードを書いている時、日本人のみに関係するコードを書いている時などです。中間を取って識別子には英語を使い、コメントを日本語で書くこともできます。日本語のユーザーが使用する分には、エラーメッセージを日本語で記述することには全く問題ありません。

次に、プログラマーの母国語で記述された良いドキュメントは重要だと考えます。残念ながら、全ての標準ドキュメントが、全ての言語に -- 又は、良く使われている 10 個やそこらの言語だけでも -- 翻訳されることを期待するのは現実的なゴールではないと思います。Google+ で返事をくれた幾人かは、翻訳を見つけても多くの場合、非常に古いか単純に間違っていると指摘してくれました。よりよい方法はおそらく、地元の方が母国語で、基本を学ぶのに充分な教本を書き（そのような本にふさわしいだけ沢山の高度なトピックも含めて！）より高度な情報の参照先としては英語のドキュメントに任せるという方法です。本の著者は、ドキュメントを翻訳するボランティアよりも、内容を最新に保つモチベーションを持っているものです。

次に、コード内のエラーメッセージについてです。ここでも意見が 2 つに分かれました。一方では「英語に堪能でなければ、”sample larger than population” というようなエラーメッセージが理解できないだろう」と言います。その一方では、「日本語に翻訳したエラーメッセージでは難しいでしょうが、元のメッセージそのものでウェブを検索すれば、プログラムのどこが問題なのか説明してくれる文書をいくつか見つけることができる」という主張です。今までに Python の標準ライブラリにある、よりわかりにくいエラーメッセージをいくつか見てきた（書くこともありますよ！）ので、いくらそのための技術があろうとも（メッセージカタログ等）、沢山の言語用に、役に立つ翻訳を用意するのはとても大きなプロジェクトになるだろうと思います。もしこのようなプロジェクトを始めたとしても、そのメッセージが何を意味するのか調べる目的で Web 検索するという大事な戦略をサポートするために、翻訳を止める方法を用意するか、又はいつでも英語の原文を翻訳に添えて表示するべきだと思います。

最後に docstring です。これは組み込みの help() 関数が出力するテキストの大部分を形成します。ボランティアが翻訳をするとしたら、help() でそれが表示されるので、docstring を翻訳するのが一番有用だと思います。確かに、それらの翻訳文はいつも完璧で最新とは限りませんが、それでも Python のインタラクティブシェルを使用して help() とタイプした時に、テキストが母国語で表示される度に少し嬉しく感じるのではないでしょうか。つまり、もうヘルプメッセージを Google Translate に Copy & Paste する必要がなくなるわけです。(と言っても実は Google 翻訳は技術的な文章の翻訳が不得手です - 訳注 英語から日本語の翻訳も不得手です ;-)

現在のところ、こういったプロジェクトを始めるようなプランはありませんが、これは良いプロジェクトになるだろうと思います。もしやってやろうという方がいらしたら、 python-ideas@python.org 宛に実装のアイデアを送ってもらえれば嬉しいです。（標準ライブラリには gettext というメッセージカタログのモジュールがありますので、問題はどのようにメッセージカタログを管理するか、どのように翻訳を生成するか、どのようにそれらを最新に保つかといった点になるでしょう）

回答 2

これは簡単です -- 私はしばしば reduce() を言語に追加したことを後悔しており、Python 3 では reduce() が built-in では無くなった事を嬉しく思っています。この理由は、reduce() の為に書く必要がある lambda 関数は、しばしばとても分かりづらくなってしまうからです。というのも、引数の 1 つは古い状態を引き渡す必要があり、関数自体の返り値は新しい状態を生成する必要があるという仕様による部分が大きいです。私は、多くの場合、同じことをするためには、伝統的な for loop を使用した方がより分かりやすく、普通はそちらの方が速いことに気づきました！もしあなたが reduce() 無しでは生きていけない体だったとしても、安心してください、それは functools モジュールに入っています。

回答 3

Python 3 への移行を成功させるのに一番大事なのは、人気のある 3rd party ライブラリーを Python 3 向けに書き換えることです。既に Linux ディストリビューションの中には Arch Linux のように Python 3 を選択しているものもありますし、例えば有名なソフトウェアの中でも Blender などはプラグインを Python 3 で書くことができます。また今でもたくさんの 3rd party ライブラリーが既に Python 3 で動くようになっていますが、まだやるべきことは沢山あります。 pypi.python.org から 3rd party パッケージをダウンロードしたら、既にそのパッケージが Python 3 向けに書き換えられているかをチェックしてみてください -- そしてそのモジュールがまだ書き換えられておらず、また、あなたがそれをできるのであれば、移植の手伝いをしてあげてください！(もしあなた自身ではできなくても、作者に対して Python 3 への移植をしてもらえるように、丁寧なリクエストをする分には、誰も嫌な顔はしません :-)

回答 4

間違いなく C 言語（C++ では無く）です。Python は学ぶべき言語のうちレベルの最も高い言語ですが、C 言語は学ぶ価値のある言語の中で最低レベルの言語であり、（アセンブラとは違って）未だに C で書かれているコードはたくさんあります。この 2 つはお互いにうまく補間し合う関係であり、1 番良くできている Python 実装は C で書いてあり、また、たくさんの 3rd party モジュールも C で実装されています。C 言語を知っていれば、プログラミングを極めたと言えるでしょう。さらに低レベルへ行きたければ、自分でハードウェアを作（略

回答 5

現在コンピューターサイエンスの一部になっていない、新しい分野の科学や技術が、直接プログラミング言語の世界に影響を及ぼすことは想像しづらいです。例えば、私は生物学や神経科学、特に知覚に関する科学にとても興味があります。とは言え、知覚について学んだり、それをエミュレートするために、全く新しいプログラミング言語が必要であるとは考えません。はい、おっしゃる通り、脳のハードウェアは伝統的なソフトウェアを動かしているハードウェアとは根本的に異なった構造をしています。しかし、知覚について我々がこれから学ぶべき事が、脳というハードウェアの或る特性に依存するとは考えていません -- 知覚が根本的に依存しているものは、量子の相互作用でもなく、非常に多量の並列ハードウェアでもなく、”Fuzzy 理論” でもないと考えています。単に、たくさんの複雑さがからみ合って脳が働いているのだと思っています。もちろん、まだまだ沢山解明しなければならないことがあります。例えばどのように記憶が保存され、どのように物を認知するのかなどです。

しかし結局、従来の言語を使って実装できる、とても上手にまた複雑なアルゴリズムによって、それらは解決できると考えています -- 我々は今まで、特にプログラミングのパラダイムを大きく変更することなく、沢山のレイヤー、抽象化レイヤーの層を構築する事に成功してきました。

他に人気のある分野としては、ソーシャルネットワークが挙げられます。しかしこれは単純にコンピューターネットワーク上のアプリケーションです。ソーシャルネットワークは人々がビジネスをするやり方を劇的に変えそうですし、社会のあり方自体も変える可能性を持っています。(又は人々が正気に返る前の、単なる一時的な流行りかも知れません。:-) でもプログラミング言語を変えるとは思っていません。

とは言え、コンピューターサイエンスにおける進歩の中には、プログラミング言語の進歩に寄与するものもあると期待しています -- ですが簡単な改善は既に行われており、関数型プログラミングや、パターンマッチングや、アクターベースプログラミングや、その他キャッチーな名前の付いた 1 つのパラダイムそれ自体がプログラミング言語の世界を大きく変えるとは思っていません。進歩は抜本的で革命的なものではなく、おそらく漸進的で進展的なものになるでしょう。次の変化はどんな一歩でしょうか？それはあなた方が決めることです！

Answer 1

This is a very interesting question. Since I am (perhaps too :-) comfortable with English myself, I asked for people's opinions on this subject on Google+. I found that there are many different views. The most extreme answer was that everybody should just learn English. Needless to say I disagree! While this is easy enough for someone whose native language and script are similar to English (like Dutch, my own mother tongue), it would put people in many parts of the world at a big disadvantage.

I also don't want to go to the other extreme, allowing the language to change keywords (and built-in names, and the standard library) itself into another language -- it would make sharing of code nearly impossible. So, all Python programmers will have to learn some English -- but they won't need to be able to speak it, or even write natural language -- they only have to be able to type those (pseudo-)English words that are part of the language (such as if, def, len, dict, None, ZeroDivisionError) and those that are used by the standard library (for example random, socket, pickle, optparse). From the examples I gave here you can probably see that even for English speakers these words and their specific meaning have to be learned.

Before I go into the specifics of message catalogs and docstrings, I want to remind you that in Python 3, you are free to use Unicode in your Python source code, even for identifiers. Python 3 source code is assumed to be encoded in UTF-8. It allows the use of arbitrary Unicode characters in comments and strings, and of Unicode letters in identifiers. (The details are in PEP 3131,) Of course, if you use Japanese identifiers or comments, foreigners won't be able to read or understand your code, but there are many situations where this is not a problem -- for example, when you are still learning to program, when writing proprietary code for a Japanese company, or when you are writing code that is only relevant to a Japanese audience. You might also use a middle ground where your identifiers are English words, but you write comments in Japanese. Certainly using Japanese in error messages is no sin when your program is used by a Japanese user!

Next, I believe that good documentation in the programmer's native language is important. Unfortunately I think that it is an unrealistic goal to expect all standard documentation to be translated in all languages -- or even in the dozen or so languages most spoken. Several people who responded on Google+ pointed out that translations they had found were often severely out of date or even just plain wrong. A better approach may be to have local authors write textbooks in the local language that are sufficient to teach people the basics (and as much advanced stuff as will fit in such a book!), while deferring to the English-language documentation as the reference for advanced topics. Book authors are more motivated to keep their books up to date than the volunteers who might translate the reference documentation.

Then, the error messages that are in the code. Even here my correspondents were of two minds! On the one hand, if you don't know much English, you may not understand what an error message such as "sample larger than population" means. On the other hand, searching the web for that exact message is likely to turn up several explanations of the exact problem in your program, whereas you might not be so lucky when searching for its Japanese translation. Having seen (and written!) some of the more obscure error messages in the Python standard library, I think that getting useful translations into many languages would be a very big project, even though we have the technology (message catalogs and so on) to present the translated messages. Even if we did start such a project, I believe we should either have an obvious way to turn off translations, or maybe always display the English message alongside its translation, in order to support the important tactic of searching the web for a message to find out what it really means.

Finally, docstrings. These make up the bulk of the text output by the built-in help() function. I think this is the area where it makes the most sense to get volunteers to produce translations and use message catalogs so that help() can display them. Sure, the translations may not always be perfect or completely up to date, but still, if you use the interactive Python prompt and type help() you might be a little bit happier every time you see some text in your native language, so that you won't have to copy and paste it into Google Translate (which isn't very good for technical translations anyway).

Now, I don't have a specific plan to get such a project under way, but I think it would be a good project, and if you feel like helping out, I will welcome your ideas for a specific implementation on python-ideas@python.org. (Note that the standard library already has an implementation of message catalogs, the gettext module. So the issue is purely one of how to organize the message catalogs, how to obtain the translations, how to keep them up to date, and so on.)

Answer 2

That's easy -- I have often regretted adding reduce() to the language, and am glad that in Python 3 it is no longer a built-in. The reason is that often the lambda function you have to write becomes really hard to understand, due to the requirement that one of its arguments contains all the old state and it must produce the new state as its return value. I find that the same code written using a traditional for-loop is often much easier to understand -- and usually it is faster too! But if you really cannot live without reduce(), it lives on in the functools module.

Answer 3

The most important thing for a successful transition to Python 3 is porting popular 3rd party libraries to Python 3. While many 3rd party libraries are already being ported, there are always more that still need work. Each time you download a 3rd party package from pypi.python.org, check whether it has been ported to Python 3 yet -- and if not, and if you can, please help doing the port! (And if you can't, it usually doesn't hurt to send the authors a polite request for a Python 3 port. :-)

Answer 4

Undoubtedly C (not C++!). Whereas Python is just about the highest-level language you should learn, C is the lowest-language worth learning, and (unlike assembler) there is a lot of code still being written in C. The two nicely complement each other, and the most complete Python implementation is written in C as well as many 3rd party extension modules. If you know C, you have truly conquered programming. If you want to go lower still, you might as well learn how to build your own hardware...

Answer 5

I find it hard to imagine how a new field of science or technology that is not already part of computer science would influence programming languages directly. For example, I am excited about biological science and neuroscience, especially the science of consciousness. But I do not believe that we need a new programming language to study consciousness or to emulate it. Yes, brain hardware is structured completely differently from the hardware used to run traditional software. But I do not believe that the part of consciousness that we haven't figured out yet depends on specific characteristics of the brain's hardware -- I don't believe that consciousness depends fundamentally on quantum effects or massively parallel hardware or "fuzzy logic". I believe there is just a lot of complexity in how our brain works, and there is a lot still to be figured out, for example in how our memories are stored and how perception works.

But in the end I believe that these are just incredibly clever and complex algorithms that could be implemented just fine in conventional programming languages -- we've been quite successful in building layers and layers of abstraction on top of each other, without changing our programming paradigms much at all.

Another popular new field is social networks. But it is just an application of computer networks. It is likely to innovate the way people do business, possibly the way all of society works. (Or maybe it's just a temporary fashion, before people come to their senses. :-) But I don't see it changing programming languages.

That said, I expect that some developments in computer science will lead to improvements in programming languages -- but the easy improvements have already been made, and I don't believe that any single new paradigm such as functional programming or pattern matching or actor-based programming or anything else with a catchy name can by itself change the field all that much. Improvements will be gradual and evolutionary, not radical and revolutionary. What will be the next gradual change? That's up to you!