🚀 go-pugleaf

In article <1993Jan21.173741.7225@netcom.com> John Nagle,
nagle@netcom.com writes:
>       This is not correct.  Techniques for producing reliable software
>are known.  Techniques for quality control are well-understood.

Very true, however when they are used to produce truly reliable software
the cost does go up dramatically qv Space Shuttle avionics, any other
fly by wire system, nuclear reactor control stuff.

One problem with building reliable software is that, to a large extent,
reliability is not saleable.  Take for example Microsloth.  They produce
some of the worst, least reliable software on the Mac and it still sells.
This is strange because to me personally reliability is everything.  I
hate programs taking down my Mac.  [Ergo I don't run any Microsloth
programs.]  Microsloth is living proof that successful software doesn't
need total reliablity.  Perhaps we'd all be better off ploughing more
money in marketting.  [God forbid!!!]

>       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.  

Hmmm, nice idea.  Most programmers do implement some form of this
procedure,
especially when talking to beta testers (who usually runs MacsBug).  The
question is whether the organisational effort required to get
this up and running is worth the effort (esp in light of last comment).

>       - 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.

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

But there are advantages to having a brittle system.  The actual
reliability of Mac programs is very high because either a programmer
gets it right or the entire system dies horribly.  There's no middle
ground.  Users just wont put up with regular crashes that take down
the entire system.

However in a protected system users are more likely to put up with a
bad application because it only destroys itself.

I have a feeling that this is not a rational argument though (-:  Hmm,
we get more reliability by building a less reliable system.  Naaaa.

I agree about the documentation.  I think NIM represents a
significant improvement in documentation on the Mac.

>       - 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.

No argument here.  C++ is one of the biggest mistakes Apple have
ever made IMHO.

>       - 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").

I don't think anything is going to solve this problem.  The problem
is that INIT are really system extensions and having multiple people
write different system extensions is always going to cause problems.
Not saying that it can't be done better though.

>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.
                                     Ain't this the truth ^^^^^^^^^^^

>Major compromises were made to cram the original system into 128K,
>and it still shows.

Yep, the amazing thing is that the guys who built in managed to put
enough hooks in for the guys who maintain it to keep it going.  Scary.

Let's face it, from a programmer's point of view the Mac is a mess.
But the fact is that no one is going to produce a better machine
*except* Apple because no one else out there has the same commitment
to consistency and ease of use that Apple have shown while developing
the Mac.

Share and Enjoy.

Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  -- Waiting for Pink!