chuq%plaid@Sun.COM (Chuq Von Rospach) (10/31/87)
I've found an interesting inconsistency in hypercard. Fortunately, it works to my advantage, but it gave me some consternation before tracked it down, so I thought I'd warn folks about it. I have a multi-background stack that I want to put in a certain order. To do this, I've created a background field on each stack called "Key-Index" and I put a value into this that tells the sort command what order to put the cards. If I then do a: Sort by background field "Key-Index" everthing is fine. The fun comes with find. While sort will use "Key-Index" on the cards from both backgrounds, I've found that "find" doesn't cross to the next background -- it will ONLY find on cards with the same background as the card I am currently on. As an example, I'm looking at card 1, background one. "Key-index" is "foo-bar-1". There are two cards subsidiary to this, and they both have a "key-index" of "foo-bar-2". if I try: find "foo-bar-2" in background field "Key-Index" fails. However, if I use: go to first card with background "Background 2" find "foo-bar-2" in background field "Key-Index" It works fine. As it happens, this is just fine for my stack, but the behavior is non-intuitive and I thought I'd warn folks. Anyone want to hazard a guess why sort and find work differently on the same field? chuq --- Chuq "Fixed in 4.0" Von Rospach chuq@sun.COM Delphi: CHUQ
kurtzman@pollux.usc.edu (Stephen Kurtzman) (11/02/87)
In article <32530@sun.uucp> chuq%plaid@Sun.COM (Chuq Von Rospach) writes: >I've found an interesting inconsistency in hypercard. Fortunately, it works >to my advantage, but it gave me some consternation before tracked it down, >so I thought I'd warn folks about it. > >I have a multi-background stack that I want to put in a certain order. To >do this, I've created a background field on each stack called "Key-Index" >and I put a value into this that tells the sort command what order to put >the cards. If I then do a: > > Sort by background field "Key-Index" > >everthing is fine. > >The fun comes with find. While sort will use "Key-Index" on the cards from >both backgrounds, I've found that "find" doesn't cross to the next >background -- it will ONLY find on cards with the same background as the >card I am currently on. > >As an example, I'm looking at card 1, background one. "Key-index" is >"foo-bar-1". There are two cards subsidiary to this, and they both have a >"key-index" of "foo-bar-2". if I try: > > find "foo-bar-2" in background field "Key-Index" > >fails. However, if I use: > > go to first card with background "Background 2" > find "foo-bar-2" in background field "Key-Index" > >It works fine. > >As it happens, this is just fine for my stack, but the behavior is >non-intuitive and I thought I'd warn folks. > >Anyone want to hazard a guess why sort and find work differently on the same >field? Chuq, I have banged my head against the find command and I suspect the following: When you use sort by field "foo" hypertext looks for a field named "foo" on each card. When you use find "xyz" in field "foo" hypertext appears to translate the name "foo" into a field number based on the characteristics of the current card. It then uses the field number to search each card, regardless of the background type. It is my guess that your field "Key-Index" has a different number on different backgrounds. If you look at the definition of the find command you will notice that the field specification is given as a field number. I would like to take this opportunity to restress the point I made in an earlier posting. Namely, that hypertext's attempts at correcting mistakes can cause non-intuitive results. In this case, "find" is defined to work with field numbers. Specifying a field name should be an error since, as your case illustrates, a field name can be ambiguous -- you can give the same name to every field on every card in your stack. Many years ago when I was learning how to program for the first time, the school gave students the option of using a compiler that would automatically "correct" program syntax errors or a non-forgiving compiler. The school thought that a correcting compiler would free the student from worrying about syntax errors and allow the student to concentrate on programming logic. I learned quickly that the correcting compiler would more often than not "correct" my program in the wrong way. Since it never informed me that it found any errors, I would be faced with a program that compiled and gave me erroneous results. The effect was to turn my syntax errors into logic errors -- very rough on a student struggling to understand the concepts of programming. I switched to the non-forgiving compiler and had a much easier time learning because it helped me classify my errors more accurately. The students that used the correcting compiler seemed to have a harder time trying to figure out what the programming language was supposed to do -- and they almost always wrote programs that contained syntax errors. The moral of this story is: compilers that correct errors rarely work as well in practice as in theory. They may help to produce a program that runs and does something, but they as often as not produce unintuitive results. This neat correction ability in hypertext will make it easier for the first time programmer to write a script that does something. But just think about it -- if experienced programmers such as Chuq and myself are perplexed by the operation of seemingly simple hypertext commands, what will be the first time users' reactions be. Our experience gives us, if nothing else, perseverance in the face of non-intuitive results. A first time user will just be frustrated and perhaps a little pissed that he was suckered into the hype about hypercard being easy to learn. Now, for some bad news, Apple has 3 choices concerning hypertext. 1) Leave it in its current non-intuitive state, perhaps with further enchancements, without adequate definition. 2) Leave it as it is, perhaps enchancing it with features requested by the users, but release a complete definition of it. And 3) redefine the language so that it works in a more intuitive, less-hostile fashion. Choice #3 would break all the stacks that rely on the current non-intuitive behavoir -- thus it is unattractive from a commercial standpoint. Choice #2 is what must be done. Unfortunately, the definition will be ugly since either the design decisions and/or the product marketing decisions that have led to the current incarnation of hypertext appear to have not been well thought out. Choice #1 is probably what Apple will do. I have little hope for the improvement of hypertext because it appears that the language was implemented as a series of hacked enhancements to an initial design concept, with little attention payed to producing an efficient and consistent programming language. This perception finds some support in the description of the hypercard development process as documented by Danny Goodman in the October, 1987, MacWorld article "The Two Faces of Hypercard." In the section subtitled "Watching HyperCard Grow", Goodman writes: "Once the language was working, I'd leave Bill samples of my scripts. He'd add new features to HyperTalk or revise existing features so that an operation that had required a 15-line script count be accomplished with a 1-line command. "That willingness to change, however, kept all of us on our toes. At one session after the features had supposedly been frozon for a couple of weeks, I met with Bill and his chief HyperTalk programmer, Dan Winkler. They asked my opinion about which of several ways to write HyperTalk functions in scripts made the most sense. I offered my opinion, which seemed to jibe with what they both wanted to do. The Dan said, "You know, if we go that way, then user-definable functions shouldn't be that hard to do." After a ten-minute exchange in programming Greek between Dan and Bill, Dan was at work making the changes to his HyperTalk code, and Bill was literally jumping up and down, smiling like a kid who was about to get a new toy." This hardly portrays a well-thoughtout approach to the design of the hypertext language. And it does not bode well for future Hypercard development.