Path: utzoo!attcan!uunet!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <474@m3.mfci.UUCP>
Date: 22 Jul 88 16:44:49 GMT
References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 57

In article <60859@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>> >A naive (and not rhetorical) question: what evidence is there to indicate
>> >the degree to which "narrowing the semantic gap" with capability machines
>> >and the like would improve the productivity of programmers or the
>> >reliability of programs, and to which other techniques [fast machines, good
>> >software] achieve the same goal?
> ...
>Not "do you think you'd be better off" or "do you have an analysis that makes
>it 'intuitively obvious' that you'd be better off", but "has anybody compared
>actual implementations of the two approaches, and concluded that, with
>everything taken into account, you're better off with one or the other?"  I.e.,
>taking into account the fact that microcode and hardware is like software in
>that it is possible for it to be buggy (either designed incorrectly or
>implemented incorrectly), and taking into account the time it takes to design
>that system, and....

You are asking for way too much, Guy.  Computer system designers
can't even agree on performance metrics, and performance is probably
the easiest thing to measure about a computer system (as compared to,
say, reliability or programmer productivity).

Even the units in which programmer productivity is usually measured
are suspect -- lines-of-debugged-code per person per unit time????

My intuition is that the practical answer is obvious -- if you have a
machine that is 2x the performance of mine, the prospect for my
environment being more "productive" than yours (without even being
able to quantize the difference) isn't going to help me sell very
many machines.  Since this is a user-perception problem, technical
answers won't necessarily help, either.

But my intuition is also that, for the same reasons that we
instinctively reach for the best tools for the job at hand (C,
assembly, Lisp, Ada, etc.), we would do considerably better as
programmers if the "thing" (including architecture, language, & OS)
executing our code matched our expectations as closely as possible,
and with few surprises.  And further, if it made sure we knew the
nature of whatever surprises occurred, rather than (a C example)
having an array-pointer-out-of-bounds happen to trash a scalar value
that was coincidentally declared nearby.  I don't see higher
performance as a very good means of preventing errors like that.

I think the reason you won't find many academic or formal studies
attempting to quantify the benefits of object-orientation (or other
higher-productivity programming environments) is that such studies
would be fraught with difficulty and expense, and would be unlikely
to yield completely unambiguous results.  Hell, there are still
people who think assembly language programming is better; how would
you prove to them they're wrong?  (If they smoke, too, you'll know
you're in big trouble if all you've got is a rational argument on
your side.)


Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090