From: petesk@microsoft.com (Pete Skelly)
Subject: Re: Portable?
Date: 26 Jul 92 09:04:59 GMT
Organization: Microsoft Corporation

In article <1992Jul25.224915.15078@news.Hawaii.Edu> tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:
>Phil Lafornara writes:
>
>>> So?  In case you missed the earlier part of this thread, it all started when
>>> the implication was made that NT is less buggy than OS/2, because NT was
>>> coded in C, whereas portions of OS/2 were translated by hand from assembly
>>> to C.
>
>>     You must have missed the earlier part of this thread.  I started
>> it.  It had nothing to do with Windows NT.  Nothing.
>
>I said that "the implication was made".  Perhaps you didn't intend to imply
>it, but I certainly inferred it, and I'm confident that many other readers also
>inferred it.

Could it be that you inferred that the discussion had anything to do with
NT only due to the fact that some of us involved are MS employees.  If that
is the case, then you're inference is incorrect.  In any case, when you come
across someone pointing out potential flaws in an OS that you want to support,
the first line of business is to find out from the creators if those flaws
are valid and if they can be corrected.  It's dangerous to ignore such
flaws.  Then, after you are sure that such flaws don't exist, you can
flame to your hearts delite.

>
>>      This whole thread was started in response to the periodic postings
>> of "when Portable OS/2 comes out."  I questioned that, and asserted
>> that IBM would be introducing new bugs into the code when they did
>> the translation.  End of story.
>
>And I asserted that the probability of introducing bugs was increased, but
>not 100 percent.  Once again, you're using "would be" as though it was
>absolutely guaranteed that portable OS/2 will be buggier than "something
>not translated from assembly" (insert Windows NT here if you feel that it
>has been implied).

Let me restate what I once said.
SO WHAT.  Would you put your bank account on the fact that there is a small
chance that IBM may not introduce any bugs during translation.  What is your
cut off for acceptable bug introduction?  For an acceptable risk.  As I see
it, there is a very high probability that any program translated from
assembly to C will have some bugs introduced.

>
>>> If Microsoft can deliver a product with fewer bugs in less time, more power
>>> to them.  But if their programming is as bad as their probability
>>> statistics...
>
>>     Actually, the probability statistics were posted by a non-MS
>> employee.  Have you been reading this thread at all?
>
>Yes I have been reading it, which is why I know that Phil (you), Pete,
>and Raymond (all Microsoft employees) have all insisted that translation
              ^^^^^^^^^^^^^^^^^^^^^^^^ SO WHAT.
>of assembly into C *WILL* contain more bugs than C code written from scratch.
>Once again, I state as I have all along that translation provides an
>opportunity to introduce bugs, thus for programmers of equal talent the
>probability is increased, but the probability is not 100 percent, and a
>good programmer could potentially translate assembly into C with fewer bugs
>than an average C programmer writing C from scratch.

I suspect that Phil and Myself (I can't speak for Raymond) are talking
from the perspective of software engineers, no MS employees.  I suspect most
other SE's will agree with the conclusion, that Bugs have a high probability
of being introduced during translation.

As for other factors involved, remember that the code to be translated is
on the order of 1 million lines for OS/2(as an example).  That will be split
between many people.  That means the code needs to be integrated (also a common
source of bugs).  There will be a distribution of programming talent over the
complete job, meaning that a GREAT programmer may not work on all the pieces.

All these mean a higher probability of bug introduction.  In addition, 
performance hacks will probably be introduced to make up for the loss of
performance due to C function calls,etc.  These can cause bugs when ported
to other hardware.

>
>Actually, in certain circumstances, translation could be easier than writing
>from scratch, because the algorithm already exists.  Coding a new concept,
>depending on the complexity of the concept, could be much more time
>consuming.  I know from my own experience that when I need to do a
>particular task, it is sometimes faster to use published examples of code and
>translate into my language of choice rather than attempt to fully understand
>somebody's word description of an algorithm and then code it from scratch
>myself.
Let me be clear on this.  Are you implying that OS/2 is one of those
"certain circumstances"?  If not, SO.  If so, well, the project is big.
You probably won't have the archetects rewriting the code.  You probably
won't have the same programmers who wrote the code in the first place
translate it.  The new programmers need to understand the Assembly, then
possibly re-design it to fit in C better, etc.  Not an easy job.  Taking
up someone elses code can be a pain in the *** sometimes, especially if
their coding style is different from your own.


petesk@microsoft.com
Not speaking as a MS employee, but as a Software Engineer..