Re: newbie can't get exceptions to work!

[Ted Dennison<dennison@telepath.com>]

In article <Pine.BSF.4.21.0104090948440.6359-100000@shell5.ba.best.com>, Brian
Rogoff says...
>
>On Mon, 9 Apr 2001, Ted Dennison wrote:
>False dichotomy. In many cases, terse notation is more readable. 

I didn't say there was a dichotomy, just that terse notation is not the goal,
and thus can't be put forth as a good unto itself, when weighed against other
factors.

>Besides, I imagine English keywords, rather than French, German, Chinese,
>or Hindi, were chosen for some reason. Assume that there are far more

I'd say that if the Hindi words for "begin" and "end" were used, it would still
be a better choice than using a single, practicly 1-dimensional character.


>> Curly-braces look quite a bit like parens at first glance (and sometimes upon
>> further glances too, depending on the font). Being a single chararacter, they
>> are fairly easy to miss with the eye, and are harder for the eye to properly
>> line up with distant lines (thus perhaps cause misapprehension of the proper
>> nesting level). In fact, the impression of pointing in a certian direction
>> causes a mild optical illusion which worsens the problem. Being mostly vertical,
>> they can also get accidentally hidden  behind the mouse pointer or an insertion
>> cursor.

>I've never had these problems, in many years of C, C++, and Java programming. 

I've had every single one of them. The problems lining begin-end blocks up is
particularly nasty when trying to understand someone else's code heavily
indented code, especially those who use less than 3 spaces for indentation.

>I have had the problem of not being able to pick out arrays easily in the
>code of Ada since nothing really stands out in Ada. A good syntax should
>make different things look different. 

Why do you *need* to pick out arrays?

I'd say that a good syntax should *not* point out differences that are of no
consequence to the user. Another good example of this principle is the use of
dot-notation syntax. In Ada MyObject.Field could refer to:
o   A record object with a field named "Field".
o   A pointer that is being dereferenced, which points to the above.
o   An object named Field in the package MyObject.
o   A routine named Field in the package MyObject.

These are all quite different things underneath the scenes, but as long as they
return a value of the correct type the user doesn't really care about that.
That's good for me as a reader, because that hides detail that I don't really
care about in trying to figure out the code in which it appears. If I start to
worry about how MyObject.Field gets its value, *then* I'll go track down its
definition. I take it you don't like this either?

>More BS. Arrays and strings are data, not functions. 

Ahhh, now we are getting into software metaphisics. At a low level, its all just
bits. But we don't (often) read the code in binary. 
At an equally silly high-level, we've got this "black box" program. Somewhere in
the middle, we have concepts like "arrays" and "functions". As our high-level
language source code representation is somewhere in the middle, there is going
to be a certain amount of abstraction. It sounds like you just like a smidge
less abstraction in your source code than I do. As a matter of taste, that's
fair enough. But I wouldn't try to claim that its somehow better that way. That
would be fighting history.


>My recollection is that the last time this was discussed Robert Dewar
>confirmed the statement that there was no discussion of using [] as array 
>brackets at all, the choice of () had to do with the DoD requirements on
>the character set to support (now) obsolete machines. All of this singing

That does seem to sound a bit familiar. Still, every now and then the bread
lands jelly-side-up. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com