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