Re: next "big" language?? (disagree)

[The Amorphous Mass <robinson@blue.weeg.uiowa.edu>]

On 8 Jun 1996, Robert Dewar wrote:

> James Robinson said
> 
> "  Frankly, I can't think of anything better.  We looked all over, and
> this is the best there was.  Remember, the problem is not that it fails
> to work as advertized, and it is not that it is unstable or buggy or
> unpredictable.  The problem is that if you try to do something a little
> bit different from what it's designed for it stops being friendly and
> starts being obscure.  By contrast, if I want one of my C libraries
> to do something a bit different, I just go in and modify them."
> 
> This is as wrong as it could be, and basically could only be written by
> someone who has not understood the whole point of data abstraction,
> using the term widely to encompass object oriented programming as well.
> The whole point of abstraction is to make it easier to reuse code.
> C has advantages, particularly in the simplicity of its computing model,
> and simple syntax, but there is a price to be paid for this simplicity,
> and the price is precisely almost complete lack of data abstraction.
> And it is this lack of data abstraction that makes "just go in and modify"
> type programming MUCH harder in C than in any higher level language with
> proper abstraction facilities (Ada, C++, ...)

  Unfortunately, you read in to my statement something that I wasn't 
saying.  I indentified the libraries as "C libraries" because that's what 
they are.  The point was that libraries that I have the source code and 
docs for are much more reusable then libraries (or class hierarchies, or 
whatever buzzword you want to use :-) that are engineered to "to 
everything" but are transparent to me.

  If I were to pick an ideal language, instead of C (which I use because 
it is highly and easily portable, and the language I am most famiilar 
with) I would have said something like "Smalltalk libraries."  In fact 
Smalltalk is a good example of an organizational system that IMO
intelligently handles code reuse:  The whole shebang runs smoothly and 
transparently, and not only are the individual parts are available for 
modification as necessary, they are also broken up into small, clearly 
written routines.  And its much harder to blow up your machine by making 
a small change in Smalltalk code than in C code.  In fact, our second 
choice for a dev platform was VisualAge, but Smalltalk scared away the 
principle programmer (a FORTRAN guy).

> James, if you disagree, then I suspect you just don't have much experience
> with higher level languages, or, if you do, that, as is common with 
> programmers whose primary experience is with C, you have not yet fully 
> understood what data abstraction and the design of abstract interfaces 
> is about (let alone object oriented programming).

  Well since I didn't disagree you will not be surprised to hear that 
although my primary experience _is_ with C, I have been exposed to a 
large number of programming paradigms (including OOP), and I apply as 
many of the lessons of those paradigms to my C code as I can.  Now 
that I'm no longer in school I might actually have time to _learn_ the 
languages I was exposed to (Smalltalk, Prolog, Miranda) and some 
others that have been suggested to me.

> It is certainly true that much of (the worst of)
> C++ code that is around today was clearly written by C programmers who have
> not yet started to understand what C++ is about.

  And the rest was written by C++ programmers who have not yet started to 
understand what C++ is about.  After all, "what C++ is about" is an open 
question.  I certainly wouldn't use it in a course about object-oriented 
programming!

- James                    "Good candidates for exceptions are situations
james-robinson@uiowa.edu   that do not occur under normal circumstances."
                                                        -- Kevin J. Hopps