🚀 go-pugleaf

Michael D. Rossetti <mikey@wicat.com> writes of increasing software quality
as being impossibly expensive.

       This is not correct.  Techniques for producing reliable software
are known.  Techniques for quality control are well-understood.

       The Mac, though, is not a good platform for reliable software,
for a number of reasons:

       - When a program fails in an operational environment, all data as
         to what went wrong is lost. Properly, failure info should be
	 saved, collected, and used for collecting information on defects
	 and for statistical quality control.  The Mac discards everything
	 when an error occurs.  (Yes, you can run with a debugger installed.
	 But this is not particularly useful when a commercial product fails.)
         Good data collection for a large user population would make 
	 the product quality problem very visible to a vendor.  It could
	 then be fixed, rather than ignored.  With most Macs now 
	 equipped with either a network connection or a modem, such
	 reporting could be made effortless for the user.  

       - The system is "brittle", in that incorrect parameters to system 
	 calls can result in system errors.  (This is not true of UNIX,
         and even DOS is better about this.)  This causes errors to be
	 more ambiguous than they need be.  It's not clearly set out
         what the entry conditions (the assertions that must be true
	 for the operation to succeed) for each system call are,
	 at least not in the original Inside Mac series.  So blaming
	 the application programmer for not obeying them is inappropriate.

       - C, and C++, are not "safe" languages.  Yes, they are popular.
         But you can't make any strong statements about a C or C++
	 program just because it compiles.  Compare Pascal or Modula.
         There's an extensive literature on this subject, and that's 
	 enough to say here.

       - The Mac is not a protected-mode system.  Enough said.

       - The use of "trap patching" results in interdependencies
	 between programs which continually cause problems.  The
         whole "system extensions" concept is flawed.  Interdependency
	 between INITs remains a serious problem, managed via a 
	 ritual-taboo culture ("don't use X with Y; we don't know why,
	 but it won't work").

       - In theory, an object-oriented environment could encapsulate
         many of these issues.  But the existing OOPs for the Mac do
         not seem to increase the level of safety provided.  This is
	 the real OOP issue here.  

Many of these criticisms can also be made of DOS, but it's worth noting
that OS/2 (with "Crash Protection (tm)") and NT address many of these
issues.  So does UNIX.

I know I'm going to get hate mail.  Some people worship the Mac.
I like the box; the esthetics are great, the GUI is excellent, and the
human factors have been well thought out.  But there's a mess inside.
Major compromises were made to cram the original system into 128K,
and it still shows.  (Compare the Lisa, which had a multitasking, protected
mode OS, in 1982.  The Lisa was a better machine than the Mac; it just cost
too much in 1982, and in fact, the Mac wasn't that useful until Macs
appeared with Lisa-level hardware: 512K and a hard drive).

I'd appreciate comments from people who have programmed for a variety of
platforms.

					John Nagle