Re: newbie can't get exceptions to work!

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Mon, 9 Apr 2001, Ted Dennison wrote:

> 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.

When did I do that? Try reading what I wrote, not making up interpretations 
of your own. If two notations are equally readable, but one is terser
than the other, I assume you chose the more verbose one? 

> >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.

I'll be sure not to use a language you design in the future!

> >> 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.

What can I say. Some people learn one language and like it so much that they 
are unable to get past superficial syntactic issues in other languages. 
I've never been much of a syntax fanatic, though I do have preferences. 
Lisp, Forth, Haskell, and others never really caused me pain syntax-wise, 
though I admit getting used to their semantics took a fair bit of work. 
C and Ada are practically the same to me from a syntax point of view. I
suspect you're just used to very few languages. 

> 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.

Poorly indented code in any language doesn't read well, and that includes
Ada.  And 2 spaces works just fine, thanks, though I indent 4 when I have
the choice. 

> >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?

Because I am a programmer. Reading code is just one of those things that I
do from time to time. Given that arrays and functions are different,
programmers who read other people's code need to know what's what when
reading. 

> I'd say that a good syntax should *not* point out differences that are of no
> consequence to the user. 

Can you treat an functions and arrays the same way? Or is there something
about arrays and strings that suggests that they are different? 

> 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?

You take it wrong. However, I wouldn't mind if a different symbol were
used for method invocation in C++, since it really isn't the same thing 
as accessing a field. Also, I much prefer Ada's unification of . and -> 
syntax, since I really don't care in this case. As far as package and
record access, they're pretty close. In a language with first class
modules, records and modules would in fact be the same thing. Cayenne is 
that kind of language. 

> >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.

Thanks for the lesson. This is really deep stuff. You must be really
smart. 

Don't like sarcasm? Don't talk down to your interlocutors.

You typically use arrays as containers. You get slices. You do lots of
things that you don't do with functions. And vice versa. rather than 
pretend that they are the same, I say just accept reality and give them a 
diferent syntax. Of course, Ichbiah didn't have that choice. there was no
discussion, so he had to do what he did. Sure, you can find some advantages 
for this, but it looks like a flaw to me!

> 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.

Sounds like you'd prefer a language where strings, arrays, and functions
all had exactly the same restrictions, or were possibly even just
implemented exactly the same way. Perhaps the untyped lambda calculus is 
what you'd like to program in. As a matter of taste, that's fair enough. 
Etc., etc...

> >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. :-)

But, given that two of the Reviewer Roberts seem to prefer [] (just need 
Robert Eachus for the hat trick :) over () I think it looks more like 
a mistake, or at least a suboptimal choice. Anyone know what Jean Ichbiah's 
take on this is, as in would he have done this if he didn't have to? Pretty 
clearly Niklaus Wirth favors [] ...

-- Brian