Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!bbn.com!cosell
From: cosell@bbn.com (Bernie Cosell)
Newsgroups: comp.sys.amiga
Subject: Re: Difficulty in programming
Message-ID: <56964@bbn.BBN.COM>
Date: 5 Jun 90 11:40:22 GMT
Sender: news@bbn.com
Lines: 39

I think you people are missing part of the point.  Granted that
programming for a really flexible GUI on a multitasking machine has
some inherent difficulties.  NONETHELESS, AmigaDos has a bunch of what
I think are bad design decisions that make it a *lot* harder than it
should have had to be.  [NB: I can't compare this to programming either
the PC or the MAC [I understand that the latter is a REAL nightmare!],
but only to programming on 'big' systems... I didn't get my Amiga as
the king of small machines, but rather as the smallest 'real' machine,
and so I evaluate NOT in contrast to the other little boxes, but as a
small incarnation of a BIG one...]

1) the absence of resource tracking.  This decision pollutes the Amiga
at every level.  It makes msot routine programming tasks a (relative)
nightmare, since you have to be anal-retentive to a degree I find a
constant nuisance.  Freeing locks, closing open files, freeing memory,
etc, etc.  It makes interrupt-handling code a mess, it means that it is
hard to get rid of a runaway program...  altogether a loser.

2) Having the sender be the 'owner' of messages.  Having a
message-passing paradigm within the operating system is a lovely and
clever idea.  Having messages be the 'property' of the *sender* was a
serious mistake: again, making programs more complicated, making it
overall much more likely that the machine gets screwed up, etc.  The
problem is that, as with resource tracking, this decision makes it
unnecessarily difficult to clean up a process, and also means that the
code has to be uglified to have wait's to make sure that everything
that was sent gets replied to.  A different plan (which we happen to
use in a system here and works out just fine) is to have the current
holder of a message be its owner, and so be responsible for freeing it
(or forwarding it, or whatever the recipient wants to do with it).  It
means that you can just "send it and forget it", instead of having to
ensure that you wait for the reply before you exit your process.
Instead of treating the reply as a REAL reply, just treat it as an
*independent* message going in the reverse direction... means that if
the requestor is gone, for whatever reason, the replier can just
discard the message and the system happily hums along... nothing lost,
no gurus, no nothing..

   /Bernie\