Path: utzoo!utgpu!attcan!uunet!cbmvax!snark!eric From: eric@snark.UUCP (Eric S. Raymond) Newsgroups: comp.lang.misc Subject: Re: Bondage and Discipline Languages Message-ID: Date: 29 Dec 88 23:54:57 GMT References: <3300001@uxg.cso.uiuc.edu> <4509@xenna.encore.com> Organization: Golden Apple Gotterdammerung Promotions, Inc. Lines: 106 In article <4509@xenna.encore.com>, pierson@mist (Dan Pierson) writes: > In , 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