Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!cat.cmu.edu!ns
From: ns@cat.cmu.edu (Nicholas Spies)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Hypertalk instructional book request
Keywords: hypertalk, book
Message-ID: <3137@pt.cs.cmu.edu>
Date: 28 Sep 88 03:30:57 GMT
References: <3074@ucdavis.ucdavis.edu> <69395@sun.uucp> <17537@apple.Apple.COM> <3077@pt.cs.cmu.edu> <17873@apple.Apple.COM>
Sender: netnews@pt.cs.cmu.edu
Distribution: na
Organization: Carnegie-Mellon University, CS/RI
Lines: 41

Actually, I agree with your book list completely...and for the reason you
gave, namely,
<< If someone out of the "inside track" write a good book then great, but
I'll stick with those on the inside track because they know what is right
and wrong.>>

Although I think the HyperTalk Script Language Reference Guide is a
wonderful step in the right direction, I won't be completely satisfied
until Dan or Bill writes a book as good as "Smalltalk-80: The Language and
it's Implementation" (Goldberg, Robson), for example, or Guy Steele's
"Common Lisp, the Language". This sort of a HyperCard book would be worth
a great deal to its readers as well as its author(s), who would deserve
every penny they earned...

Although Apple's near-term interests are served by treating HyperCard as a
proprietary secret, in my opinion Apple's long term interests would be
better served by creating a solid specification for the virtually inevitable
clones that will grow up. After all, we all agree that the Mac would be the
preferred development machine, right? So what's the problem?

I'm sure there would be 10 times the number of eager HyperCard developers
coming out the woodwork if it ran, as an Apple-inspired standard application
on PC's and workstations, too. Then, too, third-party developers, which have
been a mainstay of Apple's success, could jump in to at least try to develop
native-code compilers for HyperTalk, stand-alone clickable applications, new
HyperCard objects, etc.  Surely this would be a better situation than having
to rely only on the resources of the HyperCard development team for carrying
their remarkable product forward. A HyperCard Virtual Machine should be
defined to allow an orderly, compatible development on many fronts, both
inside and outside of Apple.

...but then again, John Sculley hasn't been asking me for my opinion of
late, and it hasn't seemed to have made much difference!

BTW: Dan, thanks for your extremely helpful info and feedback and as they
used to say: De gustibus non disputandum...

-- 
Nicholas Spies			ns@cat.cmu.edu.arpa
Center for Design of Educational Computing
Carnegie Mellon University