From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: OO, C++, and something much better! Date: 1997/01/29 Message-ID: #1/1 X-Deja-AN: 213027722 references: organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-29T00:00:00+00:00 List-Id: In article , Jon S Anthony wrote: >... The idea of "one language for all >things" is every bit as silly as "_the_ theory of everything". True. I don't claim there can be one programming language for all things. I claim that we can do a lot better than we're doing now. I mean, I think it *is* feasible to have a programming language that's suitable for building applications that cover several application areas. And it's necessary: Don't tell me you're using Ada for the "reliable" parts of the program, and Smalltalk for the "GUI" parts of the application -- this implies that you don't care if the GUI parts are buggy. I claim that the main thing that matters for any particular application area is the availability of good (preferably standard!) libraries. The underlying programming language doesn't matter (as much). The "built-in" features of a programming language ought to support the building of highly reusable, reliable application-area-specific libraries, rather than trying to support those areas directly. Given that approach, I think you can get a lot further along the path toward the "ultimate language" than we are now, though I agree we'll never get to the end of that path. >So, it makes a lot of sense to concentrate on working out explicit >well defined interface points between PL semantics where the >"impedance mismatch" is controlled and "easily" managed. Of course >this would require real communication and cooperation between the >various camps - wow, what a novel idea... Shrug. I don't see how this is all that different from what I said above. I mean, you can get rid of the impedence mismatch entirely by making all languages the same. I certainly agree that it would be a good thing if all language designers could agree on some basic stuff (like terminology), but I think it's really too premature to expect that to happen right now. Anyway, look at the actual differences among the various languages in common use. Many of those differences have nothing to do with being suitable for particular application areas or purposes. E.g. Ada is case insensitive, C is case sensitive. It's possible to believe that case sensitivity or insensitivity (or one of several other alternatives) is "better", but it has little to do with the application area. It has a lot to do with the taste and attitudes of the individual programmer. (Oh, boy, I hope I didn't just start a sub-war on the merits of case [in]sensitivity.) Another example: somebody claimed in this thread that Smalltalk's named-notation call syntax makes programs less buggy (than C++, I guess). I've made the same claim for Ada (which makes named notation optional). One can argue about which of these three (or various other possibilities I can think of) is best. But I don't see how this has anything whatsoever to do with whether you're writing GUI-ish code, or hard-real-time code, or whatever. Also, note that by and large, people don't choose languages based on application areas -- they program in the language they're used to, or that they enjoy programming in, or that everybody else uses. >Agreed, but it is pretty trivial compared to the next task up the >ladder: that of having a module's contextual semantics spelled out and >codified as part of its overall semantic description, thereby allowing >at least the possibility of true parts catalogues. Don't hold your >breath... I won't. ;-) >> So I don't buy the idea that you can just choose whatever language is >> best for each module, and then paste them together. Just to clarify: It's certainly feasible to write a 100,000-line subsystem in one language, interfacing to another 100,000-line subsystem in another language. The interface is painful, but it's small enough to be manageable. But you can't feasibly write every other 100-line module in a different programming language. >Then the software biz is never going to get beyond the artisan or >blacksmith stage it's been stuck in for the last 35 odd years. Perhaps it never will. :-) / 2. - Bob