Re: Descriptive exceptions
Alf P. Steinbach wrote:
* Eugene Gershnik:
Alf P. Steinbach wrote:
* Eugene Gershnik:
Let's just say that many people disagree with your position with
regards to the language of error messages. Myself I would prefer the
UN to proclaim English as the only language on Earth starting from
tomorrow but this has little chance of happening ;-)
Good that we agree on an ideal, then, but as I understand it you see
some practical obstacles that I don't. What would those be?
I've worked with very bright programmers outside US who while nominally
understanding technical English had trouble parsing even the simplest error
message.
Note that the problem isn't just understanding the message.
It's writing it to begin with. I've worked with a lot of people
who had an acceptable passive level of English, but who were
unable to write it in a way that others would understand.
I also had to work with a big software development organization in
a G7 country where virtually nobody spoke English and the keyboards even
didn't have English letters on them (we talked through translator). The
things you describe like English being lingua franca etc. are only true in
some places.
I concede that this, although improbable, is within the realm of
possibility. Programmers who don't speak English would have a hard time
understanding C++ keywords or keywords in just about any programming
language, standard library identifiers,
Keywords and standard library identifiers are just that:
keywords. While one would prefer that they don't contradict the
native, non-programming use (whence the complaints concerning
std::remove), on the whole, they do have special meanings, and
"while" in a C++ program doesn't have exactly the same meaning
as "while" in an English sentence.
FWIW: I've seen people who use a series of #define's:
#define tantque while
#define si if
#define sinon else
// ...
Thirty or more years ago, there was some believe in some circles
that this made the language easier for people who didn't
understand English. (Doubtlessly from the same people who
believed that understanding English made Cobol code readable.)
Today, the only times I've seen it done was as a joke. (One of
the groups I worked with at Siemens had developed something
along these lines in the local Baverian dialect. The idea
wasn't to make it easier for Baverians to understand, but to
make it almost impossible for non-Baverians to understand. And
there was never any question of it being used in production
code.)
documentation, books (most of
which are in English),
Most of which have, in fact, been translated, at least into
French and German. It may also surprise you to know that C++ is
taught in both French and German universities. In the local
language. A good passive knowledge of English is generally
important if you want to stay abreast of the latest
developments, but that's not what is asked of most programmers;
most programmers are in fact asked to use time-tested
techniques, in order to reduce risk.
tools, and so on, and could not easily ask for
help in e.g. this group, or attend seminars, or look up source code
examples on the net, or whatever: an Herculean struggle. But, within
the realm of possibility.
It's probably impossible to keep up to date with the latest
developments in C++ without at least a fluent reading knowledge
of English. It's very possible (and I know more than a few
people who do it) to know enough C++ to use it effectively in
large projects with only a passing knowledge of English. (I've
known at least one very competent developer who didn't know a
word of English, but that's rather an exception.)
In the rare case of a project with programmers who don't speak English,
it would be advicable to not use English. :-)
And as James Kanze noted else-thread, for an in-house project the
language employed for logs etc. can just be the national language,
although there is the problem of textual representation, and the problem
of then constraining the possible reuse of parts of the system.
It's always a cost-benefits trade-off. Everyone where I
currently work understands written technical English without too
much problem. They still understand French better, however, and
write it with considerably more ease. So they are more
effective in French. Given that we are a purely French company,
with only agents (no development) in other countries, and there
are no plans to change this, using English would represent an
additional cost, for no immediate benefits.
Of course, we could be bought out tomorrow by some international
bank which would require all of our messages to be in English.
But then, we could also be bought out by some company which
would require all of our software to be written in Smalltalk or
in Java, or which would require all of it to run under Windows,
or who knows what else. We can't possibly prepare for all
possible eventualities. So we decide which trade-offs to make
only on the concrete possibilities we do know. (Which do change
in time: five years ago, Solaris was it; today, I also have to
take Linux into account; five years ago, I could assume a
maximum of four hours difference in timezones on the client
machines---since then, we've added clients in New York and
Tokyo.)
Then in a big organization, even if your developers all
speak decent English your error messages will be seen by
your support folks in different countries.
So far we haven't discussed messages presented to the user (what the
user reports to support), and I fail to see the relevance to the earlier
discussion, or to C++. Perhaps better discussed in a general software
engineering group. But yes, that is a problem with messages presented
to the user, necessarily in the user's national language.
It depends on the user. For a US firm selling in Europe, it's
not unreasonable to make fluent English a requirement for
support people. In our case, we can probably assume better
English from our users (all highly trained professionals trading
on international markets) than from our developers.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]