On Fri, 2005/06/10 (MDT), <dot(_at_)dotat(_dot_)at> wrote:
Natural language translations of programming language keywords are
generally a bad idea. It bloats the programming language specification
and
reduces the ability of programmers from different countries to understand
each others' work.
I doubt those are the reasons. Specification bloat is a minor technical
problem because the core spec remains the same and only more keyword
tables are added as appendices of sorts. The understanding is not
a big problem for keywords because each programmer can view the program
in the language of their choice (automated translation is easy).
It's better to treat programming languages like
mathematical notation, with a formal intrinsic meaning which is only
suggested by the choice of keyword. Programmers are used to this, so it
isn't a problem.
I agree, but many people are annoyed by the fact that the notation is
using a foreign (to them) language, especially if it is a language of
the country they tend to hate. It is not a _technical_ problem these
days (it used to be when some EU folks could not type certain symbols
like "{" and "}" because of 7 bit encoding conflicts).
In true math, it is a lesser problem because notation is mostly symbolic
or using letters from alphabets that do not belong to current
"world-dominating" cultures. Also, mathematicians tend to be more
reasonable than script kiddies :-).
The question of names defined by programmers (as opposed to keywords
defined by the language specification) is much simpler. If the language
source character set is specified to be unicode, then programmers can
use whatever natural language they like when choosing names. This is
standard practice these days.
This practice _does_ make it difficult for programmers to understand
"foreign" programs though (and no automated seamless translation is
possible for non-keywords). Said that, I think that P/Sieve should be
Unicode-based. I do not remember if Sieve allows Unicode (it was not
a huge problem for them because they did not have variables in the
core of the spec; they will now).
Alex.