pierson@mist (Dan Pierson) (12/31/88)
In article <eZCUN#34OkqV=eric@snark.UUCP>, eric@snark (Eric S. Raymond) writes: It looks like we agree much more that I thought. >> 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 like C++ too. The only bad thing about it is that it seems so destined to succeed big that reasonable competitors don't have a chance. Also C++ still lacks exception handling which I rate about equal to object orientation as an essential language feature. While this hole will probably be filled eventually, real implementations will lack it for some time to come. Eiffel is very interesting. It's chance of success will probably depend on whether true competitive implementations appear. Unfortunately, I can't name a single proprietary language that's made it big; probably because the entry cost is too high for it to get a critical mass of users. From recent Eiffel postings, it looks like the Eiffel folks are going for a second generation lock-out. They'll let "anyone" license the language design for free (would that include an agreement that FSF would be likely to accept?) but intend to continue developing the language and standard library under their control. This appears to make all "competitive" implementations second-class citizens who get to spend all their time playing catch-up. >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!). Unfortunately I don't normally read comp.lang.c. I just resubscribed yesterday and noticed a number of your postings for the first time. >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. In general, I agree, however note the following from page 41 of the Modula-3 spec: "An unchecked type transfer operation has the form: LOOPHOLE(e, T) where e is an expression whose type is not an open array type and T is a type." Of course, this is only available in an UNSAFE module. The assumtion, straight from Cedar, is that the vast majority of modules are SAFE and that this sort of code can be localized in special modules which are exceptionally thoroughly tested. >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. As a Lisp developer, how can I not agree? >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; I agree, one of the things that most attracts me to Modula-3 is that they succeeded in limiting themselves to a language with a 50 page readable spec. One thing the world does not need is gargantuan languages like Ada that are unreasonably difficult to teach, understand, and implement (yes, I know, and why is Common Lisp so bloated). >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. I agree to the extent that I think Eiffel is one of the worthy competitors of Modula-3 (did I mention that Modula-3 also is an OO language with single inheritance and default methods?). C++ strikes me as the successor of C, and therefore not competive with either language in the design arena; it will win the commercial competition no matter what its merits are. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@multimax.encore.com