Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!yale!yale!newsxfer.itd.umich.edu!newsxfer3.itd.umich.edu!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!uucp2.uu.net!world!bobduff
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: OO, C++, and something much better!
Message-ID: <E4s0pz.L5E@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <JSA.97Jan16141937@alexandria> <E4oMBG.62@jvdsys.nextjk.stuyts.nl> <E4p4qH.4A@world.std.com> <JSA.97Jan28183735@alexandria>
Date: Wed, 29 Jan 1997 15:37:11 GMT
Lines: 82
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:244166 comp.lang.smalltalk:50369 comp.lang.eiffel:17946 comp.lang.ada:56790 comp.object:60544 comp.software-eng:53148

In article <JSA.97Jan28183735@alexandria>,
Jon S Anthony <jsa@alexandria> 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
