OT: Programmers whos first language is not English

[Andy Freeman]

Stephen Horne <intentionally at blank.co.uk> wrote in message news:<k44u6vc4kg9g7ddiskl2lcstmra5kup87l at 4ax.com>...
> As for the parsing being trivial - it's not exactly rocket science in
> either case, though I admit that LISP-style expressions barely need
> more than tokenising and parenthesis matching. But even trivial
> scanners and parsers are, well, sufficiently non-trivial that writing
> one when theres one already written and available to use seems a bit
> masochistic.

You're looking at the wrong problem.

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.

If there were only binary operators and there were only three of them
and there was a very tight limit on the expression complexity, then,
and only then, would precedence make sense for code written/read by humans.

It took me a while to figure that out, but it sure would be nice if
language designers learned that parsers capabilities far exceed
programmer abilities, and that the latter is a more important
constraint.

It would be okay to omit "unnecessary" parens in a hidden representation,
but the display and authored representation should have them.

> Parenthesis matching (especially with all parenthesised expressions
> using the same pair of symbols) is a much weaker check.

Umm, who said that a lisp-aware editor can only do paren matching?
Even in the 70s, they knew the structure of special forms.  (Paren
matching IS sufficient for lisp expressions.)

This shouldn't be a surprise - other language-aware editors knew about
keywords by the 80s.  (They'd auto-insert "then", "do", "end", etc as
appropriate.)

-andy