Re: Randy's inherent hate of Apple IIs

[nathan@visi.com (Nathan Mates)]

In article <69i71c$l0g@gap.cco.caltech.edu>,
Todd P. Whitesel <toddpw@ugcs.caltech.edu> wrote:
>I have to disagree with this. If you care about protected memory spaces
>when developing a huge project (as I have learned to after doing lots of
>development on unix boxes, as well as bare CPU boards and Apples at home)
>then GNO/ME is _not_ adequate.

   Yes, protected memory is a DAMN nice thing to have when
coding. But, go back and reread Mr. Shackleford's dissing on the Apple
II. Nowhere was the lack of memory protection meentioned in its
drawbacks, only that it was "70s technology" and thus couldn't handle
good code design.  The 65xx can handle good code design just fine, but
it's the memory protection (still lacking in every OS officially
released by Apple until the Rhapsody betas) that can really aid
debugging.

>The last time I was actually playing with LHG I goofed a little and let a
>memory trasher slip in, but it was only triggered by certain GIFs and I
>didn't find it right away. By the time I knew about it, I had no idea
>which change was most likely to have caused it (no version control on
>my Apple yet either, something else I am used to having on unix at work).

   A GNO port of CVS/RCS might be in the works for eventual release--
another quite nice feature, but that's actually doable once someone
spends the time doing so. 

   I've probably done the most work with GS memory trashing detection
and the like of anyone, and it is *certainly* a huge can of worms
adding in proper discipline in programming after years of neglect. My
program 'segfaulter,' in even *very* early beta exposed more peoplems
to fix that I could be spending 100% of my time on the GS tracking down
faults in others's code than ever updating segfaulter. 

   What's segfaulter do? Just a few sanity checks on memory-- it zaps
unused memory and watches to make sure it stays that way. ["If you say
you're done with memory, no second thoughts about using it again."]
Just that alone (not even watching for anyone writing to memory they
don't own) is enough to break a LOT of the common apps on the GS. For
example, GS/OS deallocates drivers from memory at system shutdown,
then calls them a few times for "good" measure. Lots of apps dispose
of memory and then try and use it again. [You don't even *want* to
know how AWGS "works" under segfaulter :]

   In short, enforcing any kind of discipline on the GS, especially
the OS, is a GREAT way to get real familiar with the GSBug screen or
random lockups. I've been told by others that my quick hack of
Segfaulter finds *more* problems than Apple's own inhouse memory
utilities (Scrambler, etc). I've not worked on it for a long time
after becoming very annoyed with spending all my time fixing other's
code and never writing more of my own-- and becoming more and more
convinced that I need to rewrite GSBug, Niftylist, Segfaulter, and
some of my own personal debugging/hacking utilities into one BIG
debugger that was usable.

>Actually, I am tempted to get a IIgs emulator running on my NetBSD setup
>just to make testing LHG less nerve-wracking. I followed a strict policy of
>paranoia reboots and have never had file corruption problems while working
>on LHG, in spite of many crash/trash/hang bugs caused during development.

   During my own development, I've never had a filesystem go bad due
to bugs in my or other's code-- even though I don't always reboot if I
can get the program to continue and quit out. Guess I've been lucky.

>>   Back to the original point of this thread: Apple royally messed up
>>the API of the GS/OS FSTs. And that's *NOT* the fault of the 65xx
>>series, that's not the fault of the language things were written
>>in. That fault is purely on the programmers at Apple.

>You try designing a spec for something you've got meager implementation
>experience with
[snip...]
>I guarantee you you will miss something. Look at the history of the toolbox.
>How many calls have "2" after them or "New" in front of them? Look at the
>history of SCSI. How many false starts and accumulated crufts are in that
>spec now?

   If there is something of an API in the hands of the public, then
things *can* be changed if you have to change it. It's much easier to
tweak code that's written to follow some new document than it is to
disassemble what's existing and hope you got it right. I'd *much*
rather know that things did get changed, and some documentation than
hiding behind "it wasn't right the first N times, so you can't see how
it is now."

   This is why I like things like the unix variants distributed with
full source included-- if something's wrong, YOU CAN FIX IT. It's
total vanity to think that *any* company got everything right the
first time-- Apple, Microsoft (who still hasn't gotten much right at
all... DirectX/D3D is a gawdawful mess: see John Carmack's elegant
rant over it :), Sony, Sega, Nintendo, Claris, Adobe, GNU,
anyone. Programmers are getting very sloppy and/or rushed these days
for most things-- the patch of the week syndrome from places reflects
VERY poorly on them. [That's kinda why I *like* working on console
videogames-- no chance in hell of patching, so you gotta do it right
the first time]

   Rather than programmers being up in ivory towers handing down
priceless works of art occasionally, admit they're human and let
others clean up after them. *Especially* if it's used all the time and
for all practical purposes you'll never touch or update it
again. Basically, stop assuming the public is a bunch of dumb sheep
waiting for handouts, learn that they can actually help you.

Nathan Mates
--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places? -R.A. Heinlein