home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / oop / macapp3 / 558 < prev    next >
Encoding:
Text File  |  1993-01-21  |  3.7 KB  |  78 lines
  1. Newsgroups: comp.sys.mac.oop.macapp3
  2. Path: sparky!uunet!charon.amdahl.com!netcomsv!netcom.com!nagle
  3. From: nagle@netcom.com (John Nagle)
  4. Subject: Re: Defections from BedRock?
  5. Message-ID: <1993Jan21.173741.7225@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <9301171603.AA56221@chaos.intercon.com> <1993Jan20.163209.10328@wicat.com>
  8. Date: Thu, 21 Jan 1993 17:37:41 GMT
  9. Lines: 67
  10.  
  11. Michael D. Rossetti <mikey@wicat.com> writes of increasing software quality
  12. as being impossibly expensive.
  13.  
  14.        This is not correct.  Techniques for producing reliable software
  15. are known.  Techniques for quality control are well-understood.
  16.  
  17.        The Mac, though, is not a good platform for reliable software,
  18. for a number of reasons:
  19.  
  20.        - When a program fails in an operational environment, all data as
  21.          to what went wrong is lost. Properly, failure info should be
  22.      saved, collected, and used for collecting information on defects
  23.      and for statistical quality control.  The Mac discards everything
  24.      when an error occurs.  (Yes, you can run with a debugger installed.
  25.      But this is not particularly useful when a commercial product fails.)
  26.          Good data collection for a large user population would make 
  27.      the product quality problem very visible to a vendor.  It could
  28.      then be fixed, rather than ignored.  With most Macs now 
  29.      equipped with either a network connection or a modem, such
  30.      reporting could be made effortless for the user.  
  31.  
  32.        - The system is "brittle", in that incorrect parameters to system 
  33.      calls can result in system errors.  (This is not true of UNIX,
  34.          and even DOS is better about this.)  This causes errors to be
  35.      more ambiguous than they need be.  It's not clearly set out
  36.          what the entry conditions (the assertions that must be true
  37.      for the operation to succeed) for each system call are,
  38.      at least not in the original Inside Mac series.  So blaming
  39.      the application programmer for not obeying them is inappropriate.
  40.  
  41.        - C, and C++, are not "safe" languages.  Yes, they are popular.
  42.          But you can't make any strong statements about a C or C++
  43.      program just because it compiles.  Compare Pascal or Modula.
  44.          There's an extensive literature on this subject, and that's 
  45.      enough to say here.
  46.  
  47.        - The Mac is not a protected-mode system.  Enough said.
  48.  
  49.        - The use of "trap patching" results in interdependencies
  50.      between programs which continually cause problems.  The
  51.          whole "system extensions" concept is flawed.  Interdependency
  52.      between INITs remains a serious problem, managed via a 
  53.      ritual-taboo culture ("don't use X with Y; we don't know why,
  54.      but it won't work").
  55.  
  56.        - In theory, an object-oriented environment could encapsulate
  57.          many of these issues.  But the existing OOPs for the Mac do
  58.          not seem to increase the level of safety provided.  This is
  59.      the real OOP issue here.  
  60.  
  61. Many of these criticisms can also be made of DOS, but it's worth noting
  62. that OS/2 (with "Crash Protection (tm)") and NT address many of these
  63. issues.  So does UNIX.
  64.  
  65. I know I'm going to get hate mail.  Some people worship the Mac.
  66. I like the box; the esthetics are great, the GUI is excellent, and the
  67. human factors have been well thought out.  But there's a mess inside.
  68. Major compromises were made to cram the original system into 128K,
  69. and it still shows.  (Compare the Lisa, which had a multitasking, protected
  70. mode OS, in 1982.  The Lisa was a better machine than the Mac; it just cost
  71. too much in 1982, and in fact, the Mac wasn't that useful until Macs
  72. appeared with Lisa-level hardware: 512K and a hard drive).
  73.  
  74. I'd appreciate comments from people who have programmed for a variety of
  75. platforms.
  76.  
  77.                     John Nagle
  78.