From: petesk@microsoft.com (Pete Skelly)
Subject: Re: Portable?
Date: 29 Jul 92 21:48:01 GMT
Organization: Microsoft Corporation

In article <1992Jul26.151507.14399@news.Hawaii.Edu> tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:
>Pete Skelly writes:
>
>> 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.
>
>No, I inferred it because what other operating system is being written from
>scratch in C with portability to non-Intel platforms in mind?

Well, then, You're jumping to conclusions.  There was no serious 
comparison made.

>
>> 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.
>
>It makes no sense to bet the bank account unless the probability of
>introducing bugs is less than 50 percent, and I never said it might be
>that low.  All I've said is that it is not 100 percent, whereas the
>others have been using terms like "will" and "are", which imply 100 percent.

Well, then, words like "will" and "are" should be stricken from the language.
There are very few things that are 100% true.  Or maybe, in time, you'll
change your view of what words like "will" and "are" imply when implied in
real world contexts.
Frankly, Trying to prove someones argument wrong by picking one their wordings
in the extreme cases means that you don't have a strong platform to stand on
yourself.  Or, if you are just trying to fan a flame war, I can respect that.

>
>>>>     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.
>
>The so what is because in Phil's earlier posting (see above), he said that
>the probability statistics were posted by a non-MS employee.  I have no idea
>who he was referring to.  I was referring to the postings from the above-
>mentioned people who said that bugs ARE (read 100 percent probability)
>introduced.  It's those probabilities that I take exception with.
>

By getting so hyper about this "ARE" issue, you seem to be, mmm, what
was that phrase, "Grasping At Straws".
Okay, so, for the sake of this thread, and so you'll get off of this
"ARE" issue, go back and do a global replace of all offending "ARE"s with
"have a high probability of being".

Now if you have any exception with real issues, argue those, instead of
this "ARE" garbage.

>> I suspect most other SE's will agree with the conclusion, that Bugs have a
>> high probability of being introduced during translation.
>
>An increased probability, yes.  How high it is depends on the talents of the
>programmer.
>
>>> 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.
>
>Parts of OS/2 probably do fall into this category.  Just as an example,
>tell programmer A to write a new file system from scratch in C with the
>following specifications (insert those for HPFS).  Tell programmer B to
>translate the assembly code for HPFS (assuming it was written in assembly
>to begin with and has already been debugged) to C.  Which of the two will
>likely have fewer bugs?  Depends on the talents of the programmer, but I
>wouldn't be surprised if programmer B introduced fewer bugs.  Other parts
>probably also fall into this category, but I don't know just how modularized
>OS/2 is, though it's hard to imagine an operating system as complex as this
>being monolithic rather than modularized.

Programmer A is doing Top Down design, while programmer B is doing 
bottom up design.  Programmer A can take into account the archetectural
quirks of a number of different systems.  Programmer B is going from an
archetectural spec for a limited number of systems.  In B's case, translating
to C may not be that difficult.  Translating to C for another processor
or system may be.  It's the hacks introduced in doing that that can cause
problems.  In addition, in 'B's case, you have two programmers working on
the project.  One who wrote the assembly, and 'B'.  The assembly coder may
not have had the same objectives as B, and B may have to hack around
some stupid performance things.  Given that A and B are equal programmers,
I'd suspect that B would have a far worse time of it.

>> Taking up someone elses code can be a pain in the *** sometimes, especially
>> if their coding style is different from your own.
>
>Agreed.

Let's kill this thread (i.e. This'll probably be my last post on
this thread unless something interesting comes up).

petesk@microsoft.com
My Opinions.

Xref: sparky comp.os.os2.advocacy:3085 comp.os.ms-windows.advocacy:1485