Path: utzoo!utgpu!attcan!uunet!cbmvax!snark!eric From: eric@snark.UUCP (Eric S. Raymond) Newsgroups: comp.arch Subject: Re: using (ugh! yetch!) assembler Summary: Look into C++ Message-ID: Date: 9 Aug 88 03:21:30 GMT References: <11701@steinmetz.ge.com> <933@esunix.uucp> Followup-To: comp.lang.misc Organization: Cosmic Karmic Recycling Central Lines: 62 In article <933@esunix.uucp>, sedwards@esunix.UUCP (Scott Edwards) writes: > I think that the problem with the current HLL's is that they are not > high enough, I would like a HLL that knows about trees, linked lists, > etc. and how to deal with them, so I don't have to code all of the > normal operations (insert, delete, etc) on them every time I use one. This is one reason the big trend in recent HLL design has been towards languages with lots of facilities for encapsulation of higher-level constructs (like trees, linked lists, etc.). The expectation is that standard libraries for all this stuff will evolve and spread, freeing programmers from constant re-invention of the wheel. The prehistory of this trend goes back to the Simula languages developed in Scandinavia in the mid-nineteen-sixties. But the most influential of the first generation of such languages was undoubtedly Xerox PARC's Smalltalk, first described in '72 and in active development through 1980. Smalltalk pointed the way and established 'object-oriented' programming as a serious alternative to traditional paradigms, but depended too much on a special and relatively rich environment to make a great impact on commercial programming. After 1980 the impetus moved to second-generation languages that set the new object-oriented style in a more accessible context. These could attract the kind of money and talent that would never see Smalltalk; and that wider base could support standard library development in a way credible to people who might have to bet projects on the quality and portability of those libraries. In the case of one of these languages, C++, the process is well along already. Keith Gorlen's OOPS libraries are of said to be of good quality (I haven't used them yet, so can't testify personally) and are publicly available for free. They are, I gather, already starting to be thought of as part of the `standard' C++ environment. And C++ is rapidly penetrating all of C's traditional turf, helped along by AT&T's actions (they've made it clear that the next major UNIX release will include C++), but even more by its *inaction* (the fact that AT&T has not tried to assert any proprietary lock on the language and has encouraged third-party developers to wrrite independent compilers to the design). Then, of course, there's ADA. There are many goal similarities between C++ and ADA; both were designed to graft object-oriented concepts onto an earlier generation of familiar conventional languages. It is thus very interesting to compare the encouraging early successes of the `bottom-up' approach of C++ and the UNIX technical culture in promulgating this new kind of programming with the massive failures and slippages in the DOD's imposed-from-above ADAization program. Part of the problem can be attributed to the fact that, right now, ADA doesn't *have* a technical culture; its constituency was created by fiat rather than enthusiasm. Part of the problem is simply that ADA is overdesigned, too big and complex for most programmers to get a good mental model of. One might say that it suffers from PL/1 disease; except that, unlike PL/1, there may be a good small language screaming to be let out from inside it. ADA's long-term prospects are not good; C and C++, between them, have already captured most of the human energy and interest that night have given it a real future. It remains to be seen if, unlike King Canute, DOD can actually induce the tide to roll back...