winkler@apple.UUCP (Dan Winkler) (01/29/88)
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.
john@felix.UUCP (John Gilbert) (01/30/88)
First let me start off by saying that I LOVE HyperCard, and that I use it a lot for many personal things. I have a background in programming, as well as experience in designing and implementing a language, including three years of direct customer support. This language, in many ways, pales next to HyperTalk, but it has a different (specific) goal, and was concieved long before I ever saw HyperTalk. I did not have some of the vision demonstrated by HyperCard (then). I have spent a lot of time talking with customers, and as a result have made numerous changes to my original intentions. I find this subject extremely interesting, and merely want to fuel the discussion. I have no intention of maligning HyperCard, HyperTalk, Apple, or any of the individuals involved. In article <7284@apple.UUCP> winkler@apple.UUCP (Dan Winkler) writes: >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. 2. It lets you do things you NEED to do. Frequently I would visit customers who just plain thought of doing things I had not fully anticipated. Performance was frequently an issue here too. They had perfectly legitimate things they wanted to do that they could not do reasonably with the tools I had provided. Things essential to their business. >Power is useless if you give up simplicity for it. I can not blindly agree with this. For one thing, simplicity (as well as power) are subjective terms. If I want to do real-time 3d rotation, I would not use HyperTalk. I would trade simplicity for power, simply because I might have experience in the area of 3d animation, and am not afraid to take on new horizons in order to achieve my design standards. I will agree that "the simpler it is, the better I like it". But I will not always be willing to trade power 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. Depends upon whom you are talking about. I applaud Apple's incredible attention to the non-computer (non-technical) person. If you DEFINE complexity as something "...guaranteed to be slow, buggy, memory hungry and hard to maintain", then perhaps we mean two different things. I have a 'C' program here. I won't even say what it does. I will classify the 'C' environment as way more complex than HyperTalk. Now, based on what you know about my program already, would you say that it is slower, more difficult to maintain, or a bigger memory hog, than an equivalent implementation in HyperTalk? Hopefully not with this little amount of surface information. Do you think we run a danger of losing the technically oriented audience because we have traded useful power for simplicity of use? As it is now there are certain things I will not use HyperCard for. >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. And a nobel goal it is! >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. All this is reasonable thinking. It is really a matter of balancing the power and the simplicity. And I can relate to the concern for extra baggage in the code size department. I guess the frustration I run into from time to time is that I use HyperCard quite a bit, and I often reach a point where I stop and think... "Man if I could only....". There are things I do that I still will do in 'C' for this type of reason. But then I use 'C' and I stop and think, "wow, I'm gonna have to do all this preliminary stuff just to get to....". >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. Here's a thought I just know you'll love... Scripting is a option based on the user level setting. Could that be extended to allow for explicit control of the field/variable types at a higher level still? Handle them automatically for those who don't care. Wouldn't that be FUN? HyperScripting! >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. Thanks for your views Dan. I am a satisfied customer, even if I don't have everything I want the first time around! And now, here's a specific problem I have. I (and other users of my stuff) get lost/confused/frustrated sometimes in fields where they hit RETURN in a field that only has one visible line on the card (it should be a one line piece of information). Curtrently, to avoid getting lost/confused (but not frustrated), I make the field a little longer so I can see the cursor or text on the next line below. Anyone have a better way of dealing with this? RETURN is a reflexive sort of thing for many of us, even if we know better. Anyone else want to jump in here? John Gilbert -- John Gilbert !trwrb!felix!john