home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / oop / macapp3 / 570 < prev    next >
Encoding:
Text File  |  1993-01-21  |  5.9 KB  |  127 lines
  1. Newsgroups: comp.sys.mac.oop.macapp3
  2. Path: sparky!uunet!munnari.oz.au!uniwa!bilby.cs.uwa.oz.au!usenet
  3. From: Quinn <quinn@cs.uwa.edu.au>
  4. Subject: Re: Defections from BedRock?
  5. Message-ID: <1993Jan22.013645.19546@bilby.cs.uwa.edu.au>
  6. X-Xxdate: Fri, 22 Jan 93 01: 18:03 GMT
  7. Sender: usenet@bilby.cs.uwa.edu.au
  8. Nntp-Posting-Host: eriodon
  9. Organization: The University of Western Australia
  10. X-Useragent: Nuntius v1.1.1d13
  11. References: <1jg1sbINNsrh@morrow.stanford.edu> <1993Jan20.163844.10508@wicat.com> <1993Jan21.173741.7225@netcom.com>
  12. Date: Fri, 22 Jan 1993 01:36:45 GMT
  13. Lines: 112
  14.  
  15. In article <1993Jan21.173741.7225@netcom.com> John Nagle,
  16. nagle@netcom.com writes:
  17. >       This is not correct.  Techniques for producing reliable software
  18. >are known.  Techniques for quality control are well-understood.
  19.  
  20. Very true, however when they are used to produce truly reliable software
  21. the cost does go up dramatically qv Space Shuttle avionics, any other
  22. fly by wire system, nuclear reactor control stuff.
  23.  
  24. One problem with building reliable software is that, to a large extent,
  25. reliability is not saleable.  Take for example Microsloth.  They produce
  26. some of the worst, least reliable software on the Mac and it still sells.
  27. This is strange because to me personally reliability is everything.  I
  28. hate programs taking down my Mac.  [Ergo I don't run any Microsloth
  29. programs.]  Microsloth is living proof that successful software doesn't
  30. need total reliablity.  Perhaps we'd all be better off ploughing more
  31. money in marketting.  [God forbid!!!]
  32.  
  33. >       The Mac, though, is not a good platform for reliable software,
  34. >for a number of reasons:
  35. >
  36. >       - When a program fails in an operational environment, all data as
  37. >         to what went wrong is lost. Properly, failure info should be
  38. >            saved, collected, and used for collecting information on defects
  39. >            and for statistical quality control.  The Mac discards
  40. everything
  41. >            when an error occurs.  (Yes, you can run with a debugger
  42. installed.
  43. >            But this is not particularly useful when a commercial product
  44. >         fails.)
  45. >         Good data collection for a large user population would make 
  46. >            the product quality problem very visible to a vendor.  It could
  47. >            then be fixed, rather than ignored.  With most Macs now 
  48. >            equipped with either a network connection or a modem, such
  49. >            reporting could be made effortless for the user.  
  50.  
  51. Hmmm, nice idea.  Most programmers do implement some form of this
  52. procedure,
  53. especially when talking to beta testers (who usually runs MacsBug).  The
  54. question is whether the organisational effort required to get
  55. this up and running is worth the effort (esp in light of last comment).
  56.  
  57. >       - The system is "brittle", in that incorrect parameters to system 
  58. >            calls can result in system errors.  (This is not true of UNIX,
  59. >         and even DOS is better about this.)  This causes errors to be
  60. >            more ambiguous than they need be.  It's not clearly set out
  61. >         what the entry conditions (the assertions that must be true
  62. >            for the operation to succeed) for each system call are,
  63. >            at least not in the original Inside Mac series.  So blaming
  64. >            the application programmer for not obeying them is
  65. inappropriate.
  66.  
  67. >       - The Mac is not a protected-mode system.  Enough said.
  68.  
  69. But there are advantages to having a brittle system.  The actual
  70. reliability of Mac programs is very high because either a programmer
  71. gets it right or the entire system dies horribly.  There's no middle
  72. ground.  Users just wont put up with regular crashes that take down
  73. the entire system.
  74.  
  75. However in a protected system users are more likely to put up with a
  76. bad application because it only destroys itself.
  77.  
  78. I have a feeling that this is not a rational argument though (-:  Hmm,
  79. we get more reliability by building a less reliable system.  Naaaa.
  80.  
  81. I agree about the documentation.  I think NIM represents a
  82. significant improvement in documentation on the Mac.
  83.  
  84. >       - C, and C++, are not "safe" languages.  Yes, they are popular.
  85. >         But you can't make any strong statements about a C or C++
  86. >            program just because it compiles.  Compare Pascal or Modula.
  87. >         There's an extensive literature on this subject, and that's 
  88. >            enough to say here.
  89.  
  90. No argument here.  C++ is one of the biggest mistakes Apple have
  91. ever made IMHO.
  92.  
  93. >       - The use of "trap patching" results in interdependencies
  94. >            between programs which continually cause problems.  The
  95. >         whole "system extensions" concept is flawed.  Interdependency
  96. >            between INITs remains a serious problem, managed via a 
  97. >            ritual-taboo culture ("don't use X with Y; we don't know why,
  98. >            but it won't work").
  99.  
  100. I don't think anything is going to solve this problem.  The problem
  101. is that INIT are really system extensions and having multiple people
  102. write different system extensions is always going to cause problems.
  103. Not saying that it can't be done better though.
  104.  
  105. >I know I'm going to get hate mail.  Some people worship the Mac.
  106. >I like the box; the esthetics are great, the GUI is excellent, and the
  107. >human factors have been well thought out.  But there's a mess inside.
  108.                                      Ain't this the truth ^^^^^^^^^^^
  109.  
  110. >Major compromises were made to cram the original system into 128K,
  111. >and it still shows.
  112.  
  113. Yep, the amazing thing is that the guys who built in managed to put
  114. enough hooks in for the guys who maintain it to keep it going.  Scary.
  115.  
  116. Let's face it, from a programmer's point of view the Mac is a mess.
  117. But the fact is that no one is going to produce a better machine
  118. *except* Apple because no one else out there has the same commitment
  119. to consistency and ease of use that Apple have shown while developing
  120. the Mac.
  121.  
  122. Share and Enjoy.
  123.  
  124. Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
  125. Department of Computer Science, The University of Western Australia
  126.   -- Waiting for Pink!
  127.