home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / os2 / advocacy / 3419 < prev    next >
Encoding:
Text File  |  1992-07-30  |  2.8 KB  |  61 lines

  1. Newsgroups: comp.os.os2.advocacy
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!news
  3. From: wader@watson.ibm.com
  4. Subject: Re: Portable?
  5. Sender: news@watson.ibm.com (NNTP News Poster)
  6. Message-ID: <1992Jul30.233933.28094@watson.ibm.com>
  7. Date: Thu, 30 Jul 1992 23:39:33 GMT
  8. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  9. Nntp-Posting-Host: wades.watson.ibm.com
  10. Organization: IBM T.J. Watson Research Center
  11. Lines: 48
  12.  
  13. In  <1992Jul29.214801.13081@microsoft.com>  petesk@microsoft.com (Pete Skelly) writes:
  14. > >Parts of OS/2 probably do fall into this category.  Just as an example,
  15. > >tell programmer A to write a new file system from scratch in C with the
  16. > >following specifications (insert those for HPFS).  Tell programmer B to
  17. > >translate the assembly code for HPFS (assuming it was written in assembly
  18. > >to begin with and has already been debugged) to C.  Which of the two will
  19. > >likely have fewer bugs?  Depends on the talents of the programmer, but I
  20. > >wouldn't be surprised if programmer B introduced fewer bugs.  Other parts
  21. > >probably also fall into this category, but I don't know just how modularized
  22. > >OS/2 is, though it's hard to imagine an operating system as complex as this
  23. > >being monolithic rather than modularized.
  24. >
  25. > Programmer A is doing Top Down design, while programmer B is doing
  26. > bottom up design.  Programmer A can take into account the archetectural
  27. > quirks of a number of different systems.  Programmer B is going from an
  28. > archetectural spec for a limited number of systems.  In B's case, translating
  29. > to C may not be that difficult.  Translating to C for another processor
  30. > or system may be.  It's the hacks introduced in doing that that can cause
  31. > problems.  In addition, in 'B's case, you have two programmers working on
  32. > the project.  One who wrote the assembly, and 'B'.  The assembly coder may
  33. > not have had the same objectives as B, and B may have to hack around
  34. > some stupid performance things.  Given that A and B are equal programmers,
  35. > I'd suspect that B would have a far worse time of it.
  36. >
  37. > >> Taking up someone elses code can be a pain in the *** sometimes, especially
  38. > >> if their coding style is different from your own.
  39. > >
  40. > >Agreed.
  41. >
  42. > Let's kill this thread (i.e. This'll probably be my last post on
  43. > this thread unless something interesting comes up).
  44. >
  45.      I agree on killing this thread - this seems to have become an
  46. issue better suited to <pick any appropriate> software process-related
  47. newsgroup.  Possible lumping of design scope and implementation decisions
  48. may be a hidden assumption here, which could make this discussion
  49. as futile as it has become frustrating.
  50.  
  51. Just an opinion ( can't help it . . . using "design" always
  52. gets me going ;).
  53.  
  54. > petesk@microsoft.com
  55. > My Opinions.
  56. >
  57.  
  58. Wade R. Boaz
  59. TJ Watson Research Center, Hawthorne
  60. wader@yktvmh.vnet.ibm.com
  61.