Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!wuarchive!decwrl!ucbvax!agate!web-4a!c60a-3hu
From: c60a-3hu@web-4a.berkeley.edu (Calvin Cheng)
Newsgroups: comp.sys.apple2
Subject: Re: GS (What you want _requires_ moving closer to the Amiga...)
Message-ID: <1990Mar25.005616.9526@agate.berkeley.edu>
Date: 25 Mar 90 00:56:16 GMT
References: <3508.apple.net@pro-angmar>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: c60a-3hu@web-4a (Calvin Cheng)
Organization: University of California, Berkeley
Lines: 44

In article <3508.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes:
>In-Reply-To: message from alphalpha!toddpw@tybalt.caltech.edu
>
>I didn't take the time to read all of this message but I skimmed it as it
>scrolled by and agree with Todd Whitesel, BASIC is an embarrasment to the
>computing industry but what's embarrasing about it is that it always works
>(99% of the time) is easy and any fool can do it.  DBMaster was written in
>AppleSlop with ML routines thrown in.  It worked good.  Slow but always
>worked.
>
>Me, I hate BASIC for what it teaches people but I love it because I don't
>even need to boot the OS to use it, just turn on my //e (or IIgs) and it's
>going.  I can test something simple without waiting for a recompile, link and
>all the rest of the foolishness.  I personally love Pascal and am developing
>a passion about C but I recognize that BASIC has it's place in life.
>
HyperTalk with HyperCard on the Mac has spurred thousands to produce
interesting stacks. Likewise HyperCard for the IIGS when released should do
the same on the IIGS. What I feel that's needed is not an overall development
of Applesoft but a new structured language+environment that allows the
masses to produce nifty and nice-looking applications that fit their
purposes. The same things can be incorporated into BASIC but only after
serious modifications that actually make not look a BASIC anymore.

The main strength of AppleSoft + monitor is that they are readily accessible.
Unfortunately, GS/OS has become so complicated (code no longer end up in the
same location every time) that quick fixes and patches are no longer
possible. It's much easier to work indirectly via high-level development
tools ie source debuggers etc. For example, u can't just interprete the
result of a memory dump just like that and there are tons of data structures
to interprete. The good old days of simple, absolute code are over.

Last but not least is the instability of system code. THe size of today's
OS and system programs are in the magnitude of hundreds and thousands of
kilobytes. It's impossible to sniff out all the potential bugs for any
single release. The concept of a ROM interpreter is laudable but practically
impossible because of the frequency of system updates. FOr example, when
Apple introduced the IIci, System 6.0.4 on the Mac incorporated a number of
fixes to system tools including those in the ROM. System 6.0.5 with the 
IIfx incorporates a new version of 32-bit QuickDraw but the ROM only contains
version 1.0 instead of the new 1.2 and has to be patched accordingly. The
cost of changing new ROM masks just isn't worthwhile in this instance.
Applesoft by contrast was a mere 10K in size and even so it had been to some
extent been debugged in earlier versions of Microsoft BASIC on other PCs.