Re: Randy's inherent hate of Apple IIs

[toddpw@ugcs.caltech.edu (Todd P. Whitesel)]

nathan@visi.com (Nathan Mates) writes:

>As I've said elsewhere, GNO/ME is a more than adequate substitute, and
>as it's gotten the development time, it should continue to get
>supported.

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. Sure there is masochistic hacker factor, but
for a lot of us it is just another headache that we don't miss very much.

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).
Since my only test for it is to view a specific picture and look for snow,
I'm really not motivated to go hunting for it directly until I allocate the
time to do serious source code review, and that project was to wait for my
eventual ownership of a Second Sight board, which might happen before the
Y2K cataclysm, you never know.

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.

>   Face it, Randy. This is bullshit being propagated by you to justify
>your blind worship of Macintosh, Inc. You're coming up with statement
>after statement which is just being shot down ("The 65xx can't do good
>code design" "The 65xx can't run compiled code" "FSTs were anything
>but bad code design") by the truth and facts. There comes a point
>where your blind devotion to Macintosh Inc causes all reason to escape
>from your brain, and you're just making yourself look silly. All your
>silly reasons bashing everything but Apple show that you *do* have a
>hate of the hardware, simply because you cannot admit that Apple
>messed up here.

Actually Nathan, I think you're the one who looks siller in this paragraph.
You are oversimplifying Randy's position -- those statements are all quite
valid if you put them in the context "by modern standards of desktop systems"
which would imply 32 bit arithmetic, source bases like GNU, and stable
published APIs or at least efforts toward them.

By describing the Apple II in terms of criteria which is regularly used to
evaluate the Mac and its competition, Randy isn't "hating" anything or being
"devoted" to anything. He _is_ using a frame of reference that is vastly
more common today than the "well, it's doable in principle on a ][+"
attitude that is more typical of us long time Apple II supporters.

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

I find your use of the word "fault" inappropriate, as if it were the
result of a deliberate choice because they _could_ have done a better
job had they been sufficiently committed to the future of the Apple II.

You try designing a spec for something you've got meager implementation
experience with; then iron out all the holes, justify to your boss why
you have to spend time on and add code for visionary features that have
no chance of being battle tested until it's too late to change them,
and on top of all that make zero mistakes so every future revision is
merely extensions, never replacements.

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? (It's no wonder lots of peripheral developers want to overthrow
SCSI with things like FireWire.) Look at the history of the unix API, even.

The most correct input primitive ever devised, select, did not exist until
BSD sockets made it a necessity. Even today, however, you can't block on a
child process (using wait) and incoming I/O (using select) and pending
asynchronous I/O (using SIGIO) and SYSV IPC primitives (using semop) all at
the same time; no, you must kludge it with nonblocking I/O.

(To anyone who's wondering about threads, please don't get me started.
Threads are heroin for programmers. Like trainspotting, you could do a movie
about them where both the pro and con factions agree it's a good film.)

Todd Whitesel
toddpw @ ugcs.caltech.edu