OT: Programmers whos first language is not English

[Andy Freeman]

Stephen Horne <intentionally at blank.co.uk> wrote in message news:<2mg47vg08fs23nd4fh8eh9trp3hbkq1jad at 4ax.com>...
> On 14 Mar 2003 12:43:42 -0800, anamax at earthlink.net (Andy Freeman)
> wrote:
> >I've found that the time/energy/etc saved by folks who omit "unnecessary"
> >grouping elements (parentheses, curly brackets, etc.) is dwarfed by the
> >time spent fixing problems due to omitting said "unnecessary" elements.
...
> >It would be okay to omit "unnecessary" parens in a hidden representation,
> >but the display and authored representation should have them.
> 
> We're not discussing something that programmers are meant to read and
> write. We're discussing a marked-up-text format that will be read by
> compilers and programmers editors, but not by people.
> 
> And NO-ONE MENTIONED OMITTING "UNNECESSARY" PARENS.

Really?  If a human sees or writes expressions like
"a + b * c << d | e & 37", we are talking about omitting "unnecessary"
parens.

Yes, such expressions can be well defined and parsed.  The problem is
that the parser's capabilities exceed what humans can reasonably do
in this area.  That expression is almost certain to be "wrong", and
there's nothing that the parser can do to detect the error.  Moreover,
the parser's abilities made the error possible.

Operator precedence has basically been a disaster.

> XML grouping syntax is even more strict than lisp grouping syntax, as
> the parentheses-equivalent is explicit about exactly what it is
> ending.
...
> In the following code, which expression is missing a closing bracket?
> 
>   (a (b)
> 
> For human written code, who cares - you just add the missing bracket
> and its fixed. For automatically generated code, however, it is
> extremely useful to know which part of the generation code - the 'a'
> expression generator or the 'b' expression generator - didn't output
> its matching end bracket.
>
> Now consider the following...
> 
>   <a><b></a>

I've written a fair number of such code generators and that's a lot
of mechanism for a problem that I rarely had and that was very easy
to find/fix when I did have it.  Yes, it's theoretically an issue,
but in practice....

In other words, I think that the costs exceed the benefits.

> |In the beginning, this will be small stuff. The user types a word and
> |the editor highlights it as an identifier rather than a keyword. But
> |instead of simply displaying the word in a different colour, it also
> |uses a different markup when saving. Thus, when you load it into the
> |Thingy-3000 version which has 20,000 new keywords, it knows that the
> |words which happen to be spelled the same as these new keywords in
> |your original file actually happen to be identifiers.

And this is a real problem in what universe?  (On the rare occasions
that I've run into the 30 keyword version, it was easy enough to solve
with a simpler mechanism that scales to an arbitrary number of new
keywords.)

I love power tools, but only the useful ones.  (I also like non-power
useful tools.)

But it's your time, so knock yourself out.