Re: OPES Rules Language

On Fri, 2005/06/10 (MDT), <[email protected]> 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.