🚀 go-pugleaf

In article <4509@xenna.encore.com>, pierson@mist (Dan Pierson) writes:
> In <eWbWj#4OkIf8=eric@snark.UUCP>, eric@snark (Eric S. Raymond) writes:
> >                 The European `bondage-and-discipline' school of language
> >design (the people who brought you Algol-68, Pascal, Modula, Ada, and
> >Modula-2 and are now having yet another try at getting their mistakes right
> >in Modula-3) ...                                                     
> 
> Not to start a flame war over this matter of taste, but a couple of points:
> 
> 1. I personally think that "they" may finally have gotten it right
>    with Modula-3. 

Time will tell. The track record of its predecessor languages is not
encouraging -- each (with the possible exception of Pascal) was touted as
"they finally got it right" and all turned out to be botches of varying degrees
of dreadfulness. I expect Modula-3 will turn out to be more of the same. Wanna
start a pool on the announcement date of Modula-4?

>                   While the standard modules may need a bit more
>    work, neither C nor C++ appeared at birth with complete standard
>    libraries. 

True, though C++ comes close -- after all, it can use C libraries.

>               I think that world really needs a strongly typed
>    language that is powerful, flexible, and efficient enough for
>    production use while remaining portable and simple enough to be
>    comprehensible and implementable. 

I agree. That language is called C++ -- or, if you value "safety" a bit
higher, Eiffel.

>                                      I know it's heresy, but C is
>    neither the most portable language around nor an all-around ideal
>    language.  There are many areas in which a safer language is
>    better.

Again, I agree. That's why I'm watching Eiffel closely.

>            While I'd miss the conciseness of C, I simply don't
>    understand people who feel that being force to adhere to their own
>    type abstractions intolerably cramps their style. 

Ah. Now we come to the crux of the matter. My gripe with the B&D languages
isn't "strong typing" -- I *like* strong typing. I write in ADT style myself
(you must have seen my mildly evangelistic postings on the virtues of abstract
data type programming in comp.lang.c!).

My problem with B&D languages is that they have strong typing *with no escape
mechanism* -- and no way to represent the 'real' machine-level entities needed
for systems programming. And primitive data type sets poorly matched to real-
world application programming on real-world machines.

C's great virtue -- the one that makes me a fan despite its obvious flaws -- is
that for a large class of machine architectures and problems it gets the trade-
off between cleanness of type abstraction and fit of primitives to architecture
*right*. It was brilliant of Thompson and Ritchie to understand those issues as
well as they did; and in teaching that understanding to the world, I think they
advanced language design far more than the B&D languages have.

For another example of similar strengths, consider LISP -- also a `minimalist'
language based on an astute choice about fit-to-architecture; also, like C,
enduring and adaptable because its `open world' type paradigm has left it room
to evolve.

The thing that makes a 'bondage & discipline' language B&D is that there is
*no esacape* from whatever paradigmatic shortsightednesses got built in. Other
characteristic-of-breed problems like impoverished control structures,
verbosity, and the kind of chrome-and-tailfins featuritis you see most
developed in ADA are symptoms of the same basic problem; B&D-language designers
are all by definition arrogant enough to have believed that *their* programming
paradigm, *their* primitive data type set, *their* preferred style of
algorithm representation is the One True Way before which all mere mortals
should bow down in awe.

>                                                      My experience is
>    that all well written programs have a well (but maybe not
>    explicitly) defined set of data types anyway, strongly typed
>    languages simply protect against careless errors using these types.

I agree with this as far as it goes, but `strongly typed' isn't the issue here.
The issue is whether the kind and level of type protection you get is the
*designer's* choice or *your* choice!
 
> 2. "They" are neither European nor the same folks.  The Modula-3
>    design team is more closely related to the people who created the
>    Xerox Parc set of B&D languages which culminated in Cedar.

O.K. Perhaps there's hope for Modula-3 yet. There are some interesting ideas
in the Cedar family, and I agree with your assessment of it. However, I feel
that history justifies a certain skepticism and even cynicism on the issue.

After all...who *needs* another conventional (that is to say, Algol/FORTRAN/
BASIC-descended) procedural language right now? I think it's clear that the
expressive potential of such languages has been pushed to its limit already;
the action now is in second-generation OO languages like C++ and Eiffel, or
in more exotic areas like pure-functional or non-procedural languages.

Perpetrating yet another conventional B&D language on the world seems to me to
be a silly waste of time at best, much like announcing the ultimate buggy
whip when everybody knows automobiles are the coming thing. We already know
how to do better!
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      Email: eric@snark.uu.net                       CompuServe: [72037,2306]
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718