Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!psinntp!howland.erols.net!surfnet.nl!sun4nl!stuyts!nextjk!jvdsys!jerry
From: jerry@jvdsys.nextjk.stuyts.nl (Jerry van Dijk)
Subject: Re: OO, C++, and something much better!
Followup-To: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
X-Newsreader: TIN [version 1.2 PL2]
Organization: * JerryWare HQ *, Holland
Message-ID: <E4qK3C.C9@jvdsys.nextjk.stuyts.nl>
References: <JSA.97Jan16141937@alexandria> <dewar.854209015@merv> <32EB753C.678B@jmpstart.com> <E4oMBG.62@jvdsys.nextjk.stuyts.nl> <E4p4qH.4A@world.std.com>
Date: Tue, 28 Jan 1997 20:40:23 GMT
Lines: 77
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:244273 comp.lang.smalltalk:50418 comp.lang.eiffel:17972 comp.lang.ada:56831 comp.object:60567 comp.software-eng:53162

Robert A Duff (bobduff@world.std.com) wrote:

: >Isn't this whole discussion futile since programming languages are just
: >tools, and not every problem looks like a nail ?

: No, no, and no!  A language is not "a tool".  It is a *collection* of
: perhaps-related tools.

Oops, did I accidentily kick a hobby horse here ? :-)

If you mean that any language design reflects a choice of 'features'
based on a certain model, I agree. However, from a practical point of
view, only few of us are in the position to design our own languages so
are forced to pick one of the toolboxes pre-filled by the shop.

:                                                                   To me,
: that's what this debate is about.  I *really* want Ada's type safety (at
: compile time, in many cases) and Smalltalk's flexibility and simplicity.
: I want both.

Yep. Me too. And while we are at it, lets add Eiffel style pre- and post
conditions too.

But, to put it in a style too often seen, even here on c.l.a.: "please,
tell me where to download" :-))

: Don't tell me, "If you choose the hammer, you can't have the wrenches."
: I think it's technically feasible to have both.  I think the idea that a
: programming language is a single tool, take it or leave it, as is, is
: bogus.

Not bogus, just practical.

: >... But I have developed a banking application in which the
: >presentation- and application layers were written in Smalltalk, while
: >the functional- and interface layers were written in Ada.

: OK, that's an OK answer, given the current state-of-the-art, but there
: are serious costs to interfacing between the two.

In practice its not that bad, at least, we didn't have any real problems
with it. A lot of interfacing code can be generated from specs by writing
a relatively simple parser-based tool.

:    I claim that it's
: possible to design a programming language that supports both at the same
: time, without the interfacing difficulties.

I admit I do not know enough of language design to argue against the
possibility. But common sense than begs the question: why has such an
obviously superior language not been designed already ? At least, I'm
not aware of it.

< now searching for my flame-proof email shield :-) >

: So I don't buy the idea that you can just choose whatever language is
: best for each module, and then paste them together.

Because of a) the effort to add extra interfacing code and b) the
performance penalty ? Added to the expectency that someday the ideal
language will be born ? For that are the arguments I can distill from
the above. 

However, from a practical point of view, there are far better arguments
against such a mixed language solution: manning two or more development
teams, the complexity of maintaining different but related development
enviroments, extra tool costs, etc.

In some situations the benifits of a mixed language solution outweight
these disavantages, in other situations they don't.

Jerry.
-- 
+----------------+-------------------------------+
| Jerry van Dijk | Consultant, Ordina Finance BV |
|    Team Ada    |        Haarlem, Holland       |
+----------------+-------------------------------+
