Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!orville.nas.nasa.gov!fouts
From: fouts@orville.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.lang.misc,comp.lang.smalltalk,comp.lang.c++
Subject: Re: Software ICs (long! was Re: C++ vs Objective-C)
Message-ID: <3323@ames.arpa>
Date: Sat, 7-Nov-87 14:55:30 EST
Article-I.D.: ames.3323
Posted: Sat Nov  7 14:55:30 1987
Date-Received: Mon, 9-Nov-87 07:07:40 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <3179@ames.arpa> <1662@ppi.UUCP>
Sender: usenet@ames.arpa
Reply-To: fouts@orville.nas.nasa.gov.UUCP (Marty Fouts)
Lines: 74
Xref: mnetor comp.lang.misc:876 comp.lang.smalltalk:413 comp.lang.c++:564

Dynamic binding / Late binding has been around for as long as
programming languages;  (Well, at least as long as Lisp.)  There really
isn't any need, other than marketing hype to invent a new name for it.
You don't really achieve anything except confusion by picking a catchy
name for a technical concept.  Dyanamic libraries have also been
around as long as dynamic bindings, and have been sited as one of the
indirect causes for the lack of acceptance of Lisp by programmers
outside of the A/I community.  By being easy to modify, partially
because of the ability to dynamically bind functions, Lisp became a
true Babel of dialects, making code sharing more difficult, not less,
until the recent effort at Common Lisp.  (Thank you Guy Steele et.
al.) 

I agree that if you include dyanamic binding as one of your conditions
for calling something a software-IC, than you have limited the class
of libraries you are discussing, but I strongly disagree with
obscuring the difference by giving it a marketing name; and I doubt
that it is a fundemental difference.  Dynamic binding is a function of
run time environment implementation which is shared by Basic, Lisp,
and most object oriented languages.  Programming in Basic certainly
isn't going to make me more efficent (;-)

You seem to confuse several important topics in programming language
design, and appear to be using one feature to answer a problem in a
different  area of program design.  For example, late binding does not
solve the issue of problem domain by itself.  As a user of a matrix
library, I don't care if I bind at compile time or execution time to
your matrix multiply routine, I care if it multiplies matrices stored
in the data structures I am using.  You can make me explicitly
remember that MXMTRI multiplies triangular matrices and that MXMSQ
multiplies rectangular matrices and make my life a little harder, or
you can use type overloading and a generic package to let me just use
MXM.  As long as you have supplied an algorithm to multiply the
matrices in the form I store them in, it doesn't matter if this second
mechanism is done statically, as in ADA or dynamically, as in
SmallTalk; what matters is that you implemented it.  The problem of
problem domain is to supply a sufficently rich library of routines to
meet my application needs in a way which allows me to easily access
the correct routine.  Either a correctly implemented Ada package or
SmallTalk type hierarchy would work.

The example of the automobile design is one of programming
methodology.  Static language proponents claim that this same early
design/late design concept can be implemented using stepwise
refinement and rapid prototyping, while dynamic language proponents
claim that it can be accomplished using dynamic stepwise refinement
and dynamic rapid prototyping.  I've had about equal success with
either approach, one being better for some problems the other for
different problems.

I would like to take a moment to clear up an ambiguity about hardware.
My point about hardware design wasn't about the power of the hardware
being designed, but about the design process, which is what we are
discussing.  Almost all of the performance improvement in computers
has come as a result of changes in the realization media which allow
for smaller component areas and faster clock speeds.  It still takes
as long to design a computer of a particular level of complexity as it
ever has. (BTW Moore's law, as you quote it is wrong.  Twenty 
years ago, typical chips had a few hundred gates, now they have tens of
thousands.  This is a 100 fold improvement, not a million fold.)

My point about productivity wasn't that you hadn't defined it and I
could, but rather that it is meaningless to talk about geometric
versus arithmatic growth of something which can't (or at least hasn't)
been quantified.

I'm the one who said magic, and I will continue to say magic, when I
hear geometric productivity improvements.  I agree that language
design features, such as generic packages, operator overloading,
dyanmic binding, are useful and belong in a good programmers tool kit,
along with large libraries of reusable code, incremental compilers,
source level debugs, and source code management tools.  I just try to
point out that these features have been around for a long time, have
been used extensively in some areas, and haven't lived up to
"geometric productivity improvments".