Re: if (c++ && x++); Try again

[John Walker <acad!throop!kelvin>]

Xtech didn't seem to work, so I'll try "us" this time.


Abstract:  Language choice has far less to do with success of software
	   than language designers might wish.  Given this, one tends to
	   be very conservative in choosing a language, since a language
	   collapse can certainly doom a project.  One cannot assume that
	   ambitious and innovative development will, necessarily, be done
	   in the latest, spiffiest language.  Much of the most ambitious
	   numerical code being written today is in FORTRAN.

OK, I have plenty of other things to do, but I just can't stand it
any longer.

First of all, a correction.  Marcs sez, "not even the cyberspace work
is being done in C++ to my knowledge".  This is incorrect; the cyberspace
prototype work was done with Zortech C++.  And just as you seem to be
experiencing, C++ was a contributor to the difficulty of the task.
We did not encounter major problems with Zortech--we seemed to spend
a lot of time wheel-spinning about hierarchies, inheritance, and lots
of other quasi-religious issues (to my mind) rather than writing the
code which is, after the hype is dissolved away, pretty straightforward
computer graphics stuff.  I strongly suspect that the further development
of Cyberspace will be more in vanilla C than C++ just because of a general
feeling of "who needs this shit?".

Lest anybody think I'm biased against C++, I plead the opposite.  My last
complete development effort, CA Lab, was done entirely in Zortech C++,
and I exploited the advantages of the language and immensely enjoyed the
power it conferred.  Had debugger support been adequate, the experience
would have been exemplary.  On the strength of this, I recommended and
continue to recommend that C++ be considered as the primary language
for future development of the AutoCAD product line, offering, as it does,
both easy migration from C and the tools that allow relatively easy
generalisation of code originally developed under restrictive
constraints.

That said, I think one has to step back and clearly distinguish the
genuine advantages of C++ (or any other programming system) which may
result in its widespread adoption, from the trendy language-of-the-month-
club priesthood aspects of whatever language the spotlight is currently
focused on.  We've seen all of these phenomena before in Algol 60,
Algol 68, APL, Pascal, and Modula, and it's clear that C++ is where
it's happenin' today.

I couldn't agree more with Marcs' comments about the distinction between
innovative products and innovative languages and development tools.  Many
of the analysts who wrote about the early success of Autodesk remarked
on how prescient our choice of C was in 1982 and how it let us leverage
our software investment onto a wide variety of machines.  Well let me
tell'ya how that choice was made.  We had originally planned to port our
own language, SPL, in which the original graphics code was developed,
onto the 8086.  When that project seemed to be going nowhere, I started
a rump movement, "the compiler insurgency", with the goal of finding any
existing compiler for any language which had the ability to support a quick
port of our code and future development.  Given the state of personal
computer languages at the time, language candidates were Pascal, FORTRAN,
C, and PL/I (Gary Kildall's marvelous version).  Our original choice
was Pascal, until Greg Lutz discovered that each compile took 5 floppy disc
changes.  We bought a copy of Computer Innovations C, which supported
floating point and had a rudimentary library and would compile WITHOUT
CHANGING DISCS, and the day I got it I ported my high precision math
function library to it and it worked perfectly.  Language selected for the
PC!  At the same time I chose PL/I-80 for the Z-80, and I spent the next
18 months working on the Z-80 AutoCAD in that language.  For much of that
time the Z-80 was the leader in feature development, in part because
PL/I-80 worked better and compiled faster than C, so I was able to spend
more time writing code instead of fighting compiler and library problems.

I am virtually certain that if we'd found a Pascal or FORTRAN equally
suitable to our needs first, AutoCAD would be in that language
today.  Unlike the analysts, I don't think such a choice would have made
much difference to the success of the company.  We're judged on the
performance and functionality of the product; the choice of implementation
language has a lot less to do with that than most language lawyers would
have you believe.  The real components are sound engineering and
responsiveness to user needs and while an awful language can make this harder,
an ideal language does not in any way supplant those requirements.

In all of the programming projects that I seem to be involved in the
entire project is constantly constrained by too little time, too few
talented people, and a limited budget--and that's just as true for
the projects I'm involved in now at Autodesk as in the initial development
of AutoCAD.  Given those constraints, the most clamant of which, time to
market, is driven by your competitors more than the dynamics of your
own project, the person involved in choosing a language tends to proceed
from deeply conservative assumptions.  I assume that in addressing this
group "conservative" does not carry negative connotations--I mean it in
the intellectual sense, valuing the experience of the past and choosing to
build upon it rather than discarding it lightly.

Given how hard it is to build a successful product and make it successful
in the marketplace, and how little that has to do with what language you
program in, opting for a language still unstable in design, not necessarily
available in commercial-quality implementations on all target platforms,
uncharacterised for performance and resource usage, largely based on a
prototype from a single vendor, and expressing a design methodology still
the object of active debate in the language community; further, a language
for which there exists, at present, no large pool of trained users
(and as Bobp is the most recent to discover, knowledge of C helps one
master the arcana of C++ about as much as knowledge of the Roman alphabet
helps in learning Latin).

I'm under the gun, working in the dark, pressured by competition, already
having made a wild technological bet on Xanadu, and they want me to
learn THIS????  I'm not debating the merits of what you've developed or
your belief in how it can accelerate development; I'm just trying to
put myself in a developer's position and react as I would in those
circumstances.

Speaking from very little knowledge of what you've developed or how
feasible this is (but ignorance has never slowed me down yet, so
why start now...), my reaction when faced with something like C++, X++,
etc., would be to see if I could get one or two people to learn it 
enough to wrap an interface around it, creating a black box that one
could communicate with in C with a more straightforward higher level
protocol.  That way I would not have to train everybody on the 
intricacies of the interface library, and by using my own protocol I'd
be able to shield the bulk of my development effort (and my developers)
from the instability I'd anticipate in the interface library coupled, as
it must be, intimately to a rapidly evolving product.  Walling off a
foreign substance has been life's solution for aeons.  Encyst upon it.
Granted, this may not be possible in all cases, but last July I managed
to do this to an entire solid modeler.

In summary, I take exception with little of what's been said in the 
previous comments, but do think that some of the arguments that tend
in the direction of minimising the functionality available in the C
interface or suggesting that all serious work will necessarily be
done in C++ because of the putative productivity gains that will result
may not be grounded in the messy reality of developing a commercially
successful application.

Thanks for struggling through this somewhat rambling argument.


----- End Included Message -----