Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!pyramid!voder!apple!winkler
From: winkler@apple.UUCP (Dan Winkler)
Newsgroups: comp.sys.mac.hypercard
Subject: Why we decided against graphic fields and typed variables
Message-ID: <7284@apple.UUCP>
Date: 28 Jan 88 19:09:41 GMT
References: <702@PT.CS.CMU.EDU> <19563@felix.UUCP>
Reply-To: winkler@apple.UUCP (Dan Winkler)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 53

The guiding light behind the design of HyperCard and one of the things
I'm most grateful to have learned from Bill is an understanding of the
tradeoff between simplicity and power.  Simplicity is good for three
reasons: 1. People can understand it and therefore use it.  2.  We can
implement it in a clean, correct, fast, easy-to-maintain way.  3. It
feels good.  We love power for one reason: 1.  It lets you do things
you want to do.

Power is useless if you give up simplicity for it.  Complexity ruins
power in three ways: 1. It hides features so well that most people
never find them.  2. It requires a messy implementation which is
guaranteed to be slow, buggy, memory-hungry, and hard to maintain. 3.
It's unpleasant to learn and use so people don't use it for simple, fun
things, which is where a lot of great ideas get started.

Our goal is always to find a simple way of getting a lot of power.  We
begin with the simplest possible method and try using it.  We observe
all the ways it fails and extend it in the simplest way that fixes the
largest number of the worst failings.

These principles led to the choice of the card picture / background
picture model.  It's a model that gives most of the power we want and
it's simple enough for most people to understand.  Bill considered
graphic fields and decided that they were not worth the complexity they
incurred.  They would have been confusing to many people, would have
increased our code size and memory requirements and bug count, would
have made card drawing much slower, and would have cost us time which
we were devoting to other features.  Every feature costs us in these
ways so we have to pick only the ones that are well worth their price.
Users never understand this cost and always think that more features 
are better.  We are against the Swiss-Army-Rube-Goldberg school of
design.  

The reason we decided against explicitly typed variables was entirely a
user interface issue.  Variables actually are typed internally.  If you
write "put sin(5) into x" then I store x as a SANE extended floating
point number.  If you write "put 1 < 2 into x" then I store x as a
Pascal Boolean.  If you write "put 1 + 2 into x" then I store x as a 32
bit integer.  I use typing internally for efficiency and precision but
maintain the illusion that all variables are strings by type casting
them as needed.

It was suggested that variables of type graphic and graphic fields
would be good for animation.  Animation is a feature which is on our
list but which has been deliberately deferred in favor of more
important things until we can devote ourselves to it and really do it
right.  We have some ideas about how to do it, but won't know for sure
until we plunge into it.  Rest assured that when we get to it we will
be very thorough in our search for a clean, simple, powerful, fast,
bug-free way of doing it and that the only thing keeping us from it is
a list of even more important features.

Dan.