home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / os2 / advocacy / 3269 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  3.8 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!wupost!cs.utexas.edu!sun-barr!ames!news.hawaii.edu!galileo!tholen
  2. From: tholen@galileo.ifa.hawaii.edu (Dave Tholen)
  3. Newsgroups: comp.os.os2.advocacy
  4. Subject: Re: Portable?
  5. Message-ID: <1992Jul26.151507.14399@news.Hawaii.Edu>
  6. Date: 26 Jul 92 15:15:07 GMT
  7. Sender: root@news.Hawaii.Edu (News Service)
  8. Organization: University of Hawaii
  9. Lines: 67
  10. Nntp-Posting-Host: galileo.ifa.hawaii.edu
  11.  
  12. Pete Skelly writes:
  13.  
  14. > Could it be that you inferred that the discussion had anything to do with
  15. > NT only due to the fact that some of us involved are MS employees.  If that
  16. > is the case, then you're inference is incorrect.
  17.  
  18. No, I inferred it because what other operating system is being written from
  19. scratch in C with portability to non-Intel platforms in mind?
  20.  
  21. > Let me restate what I once said.
  22. > SO WHAT.  Would you put your bank account on the fact that there is a small
  23. > chance that IBM may not introduce any bugs during translation.  What is your
  24. > cut off for acceptable bug introduction?  For an acceptable risk.  As I see
  25. > it, there is a very high probability that any program translated from
  26. > assembly to C will have some bugs introduced.
  27.  
  28. It makes no sense to bet the bank account unless the probability of
  29. introducing bugs is less than 50 percent, and I never said it might be
  30. that low.  All I've said is that it is not 100 percent, whereas the
  31. others have been using terms like "will" and "are", which imply 100 percent.
  32.  
  33. >>>     Actually, the probability statistics were posted by a non-MS
  34. >>> employee.  Have you been reading this thread at all?
  35.  
  36. >> Yes I have been reading it, which is why I know that Phil (you), Pete,
  37. >> and Raymond (all Microsoft employees) have all insisted that translation
  38. >              ^^^^^^^^^^^^^^^^^^^^^^^^ SO WHAT.
  39.  
  40. The so what is because in Phil's earlier posting (see above), he said that
  41. the probability statistics were posted by a non-MS employee.  I have no idea
  42. who he was referring to.  I was referring to the postings from the above-
  43. mentioned people who said that bugs ARE (read 100 percent probability)
  44. introduced.  It's those probabilities that I take exception with.
  45.  
  46. > I suspect most other SE's will agree with the conclusion, that Bugs have a
  47. > high probability of being introduced during translation.
  48.  
  49. An increased probability, yes.  How high it is depends on the talents of the
  50. programmer.
  51.  
  52. >> Actually, in certain circumstances, translation could be easier than writing
  53. >> from scratch, because the algorithm already exists.  Coding a new concept,
  54. >> depending on the complexity of the concept, could be much more time
  55. >> consuming.  I know from my own experience that when I need to do a
  56. >> particular task, it is sometimes faster to use published examples of code and
  57. >> translate into my language of choice rather than attempt to fully understand
  58. >> somebody's word description of an algorithm and then code it from scratch
  59. >> myself.
  60.  
  61. > Let me be clear on this.  Are you implying that OS/2 is one of those
  62. > "certain circumstances"?  If not, SO.  If so, well, the project is big.
  63.  
  64. Parts of OS/2 probably do fall into this category.  Just as an example,
  65. tell programmer A to write a new file system from scratch in C with the
  66. following specifications (insert those for HPFS).  Tell programmer B to
  67. translate the assembly code for HPFS (assuming it was written in assembly
  68. to begin with and has already been debugged) to C.  Which of the two will
  69. likely have fewer bugs?  Depends on the talents of the programmer, but I
  70. wouldn't be surprised if programmer B introduced fewer bugs.  Other parts
  71. probably also fall into this category, but I don't know just how modularized
  72. OS/2 is, though it's hard to imagine an operating system as complex as this
  73. being monolithic rather than modularized.
  74.  
  75. > Taking up someone elses code can be a pain in the *** sometimes, especially
  76. > if their coding style is different from your own.
  77.  
  78. Agreed.
  79.