🚀 go-pugleaf

In article <enea.2582> sommar@enea.UUCP(Erland Sommarskog) writes:
>On type conversions: (Explicit or not?)
>  The key word here for me is data abstraction. Even integer to integer
>may be wrong.

Had I known you were referring to data abstractions we would have been in
agreement long ago.  I absolutely agree that they are extremely useful.
The Pascal derivatives, unfortunately, do not implement them either.  That
is one of the advantages I had in mind when I said earlier that Ada has some
good points.  CLU is another excellent language which has this feature.

>Array-index checking:
>If you write checks yourself, that seems like a source of error to me.
>More brutely said, it sound like the NIH syndrome...

If you* wait for the compiler or runtime system to tell you when you make a
mistake, that's lazy, perhaps even irresponsible programming to me.  If you
understood what you were doing, you would have reasonable confidence in your
code.  This does not mean that such checks are not useful, but a heavy
emphasis on them suggests such programmers don't know what they are doing.
Again, I am not maligning array checks -- I am saying that programmers
should understand their own code!

[*"You" in this paragraph is the "generic" form.  It does *not* specifically
refer to ES.]

>On "knowing what he's doing"
>Yes. But he should get as much support as possible from the language. Thus,
>the compiler should suspect any input.

Not the compiler -- THE PROGRAMMER!  The compiler can't help much when user
enters data the program isn't prepared to handle.  In fact, it can't even
recover.  It can only blow up.  Programmers should make reasonable checks to
insure the data conforms to expectations, BECAUSE COMPILERS CAN'T.

>> [A programmer is simply a translator]
>
>Not really. Your Russian interpreter doesn't need to have a full notion
>of what you are talking of as long as he gets the words right.

And how do you suppose he gets the words right if he doesn't understand what
he's saying?  Does "The vodka was good but the meat was rotten" ring a bell?

>What have this to with C? Well, a powerful language with good possibilities
>abstracting the data is a help here to see: "What is to be done?". 
>Does C have the good devices for this? I doubt. Strong type checking is
>a must here, I believe.

Wonderful.  You have just constructed a "straw man" to tear down.  You could
as easily have complained about C's lack of pattern matching ability, or the
fact that it has no backtracking.  My comments were never designed to defend
C for all applications, nor do they assert that improvements could not be
made.  They do not even assert that C is better than every other language.  I
do intend to say that C can be very useful as a tool to a programmer who takes
the time and effort to use it correctly, and those who condemn it as a
language are unjustified.

>Erland Sommarskog       
>ENEA Data, Stockholm    
>sommar@enea.UUCP        
>                   [I blame no one, but the comment is deleted, again]
--
Doug Pase   --   ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu.csnet