Path: utzoo!utgpu!water!watmath!clyde!burl!codas!killer!mit-eddie!mit-amt!mit-caf!paul
From: paul@mit-caf.UUCP (Paul Meyer)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: numeration problem
Message-ID: <770@mit-caf.UUCP>
Date: 23 Feb 88 05:26:30 GMT
References: <1372@runx.ips.oz> <7451@apple.UUCP> <3809@batcomputer.tn.cornell.edu>
Reply-To: paul@mit-caf.UUCP (Paul Meyer)
Organization: Microsystems Technology Laboratory, MIT
Lines: 30

In article <3809@batcomputer.tn.cornell.edu> mab@tcgould.tn.cornell.edu (Mark Bodenstein) writes:
>
>In general, I think HyperCard is a great idea, and that HyperTalk has some
>good design ideas and design choices built into it.  I have found actually
>working with it to be disappointing, though.  There are too many "gotchas",
>and there are too many things that should be easy to do but aren't.  It gives
>the impression of being a good draft of a language (and similarly HyperCard
>as a product), but not there yet.
>
>If I got a vote, I would vote for a future version of HyperCard fixing all of
>these design problems, even if previously written stacks no longer worked.  I
>think that this is necessary if HyperCard is to become the tool that it can
>and should be.  I further think it is early enough in the product life to take
>such a step, and will be for some time yet.

	Maybe it would be possible to give a new a new file type to stacks
built in the fixed version of hypercard.  Old stacks would be recognized as
such and the old rules used, but this would allow new stacks to have unlimited
modifications to the "disliked features" (bugs) of Hypercard Classic.
	I do have to agree, though, that while hypercard is a great product,
there are many subtle bug/features that pop up when you least expect them
(like the ambiguity in the 1,"1",one,"one" issue) and many things that should
be easier (like doing something with a "found" object from a script, and sticky
buttons.)  
	On the other hand, hypercard has allowed my to build tailor made 
applications that would have not happened without it. 

					Paul Meyer
					Microsystems Technology Laboratory
					MIT