Why Would Ordinary People Want to Program?

  Joe Wilkins       January 23, 2007      Tutorials Developer

Last week’s article was supposed to have been labeled a “Prelude”; hence this one is the real introduction, but first a short note about the responses I received from the first article.

The responses were not numerous, although the ones I did receive were very enlightening and probably represent a cross section of the nearly 1,800 readers who did take the time on the first day it was posted to look at what I had to say about Revolution and what is planned down the road. Much as I had expected, they fell into four categories: newbie Revolution users who are eager to see what I will have to say; those who’ve not yet committed themselves to Revolution and have some HyperCard stacks they’d like to convert; Revolution users - probably more knowledgeable about it than I am; and lastly those who followed my previous antics with HyperCard and are interested in seeing where I will go with this series. They all shared some of their common interests with me, and probably range in age from the very young to the fairly ancient, though younger than me I am sure. Hopefully, when I provide a bit more controversy in my observations, more of you will care to challenge me!

My approach with this series will be to learn by teaching. Fortunately, with my HyperCard background, doing so should prove to be fairly easy. Whether you have a similar background will be immaterial. There are two major claims made by Revolution that I must validate for this series to be truly successful. The first challenge will be to show that existing HyperCard stacks may be easily converted to Revolution stacks; the second will be to determine whether these converted stacks will run on several platforms; and whether a newly created Revolution stack can be turned into a cross platform application that will run on several platforms.

After an overview evaluation of Revolution in Chapter I, I expect to accomplish the first challenge in Chapter II of this series, and start the second challenge in Chapter III. Chapters IA, IIA and IIIA, in each case, will consist of responses to reader questions about the previous chapters. Obviously, I’m not going to complete the second challenge in one or even two weeks, so the new cross-platform Revolution Application will take as much time as it takes. As indicated, alternating Chapters of the Series will respond to Reader Questions about the prior chapter. At this point, I do not know how many chapters will be devoted to creating this new, cross-platform application; but the final Chapter of the Revolution Series will be dedicated to a summation about the Revolution process, and a look ahead at the next series to be presented by me on Macinstruct for the Code Mojo column.

Why Would Ordinary People Want to Program?

I believe that most of the readers of this column will have never even heard of HyperCard; and what with Revolution being so strongly founded on it, please allow me to sidetrack ever so slightly with a very brief description of what HyperCard is and some of the things that may be done with it. That should probably be put in the past tense, since HyperCard is essentially obsolete, dead, and no longer useful to any degree.

Initially, all of us are using computers because we want to be more efficient with the use of our time. We want to do things faster and more accurately than we’ve ever done them before; also, we don’t want to have to do things more than once; certainly not repeatedly. Wouldn’t that be nice? Add to this the fact that each of us is an individual with very different wants, needs, talents and skills. In our exposure to computers to date, most of us have come to realize there are only a few basic things that can be accomplished with computers. If we had the perfect word processor, the most efficient, “perfect” spreadsheet and the absolutely greatest, “perfect” drawing/painting program, we probably wouldn’t need much of anything else. However, as I have mentioned earlier, each of us is an individual and we have individual ways of looking at our problems; so coming up with the “perfect” anything is highly improbable. Maybe “perfect” for us, but not for everyone!

Consequently, numerous attempts have been made to assist us in doing these things as easily and efficiently as possible. These “attempts,” usually referred to as programs or applications, allow us to record our thoughts or ideas and make pictures to enhance or explain them. You know the old saying about the worth of pictures! Over the years, a myriad of fairly good “attempts” have been made in each category. We are, in fact, obsessed with creating these applications. A huge industry has appeared with this sole purpose in mind. Each of us has our own way we’d like to see that “things” are done.

Dozens of so-called programming languages have emerged that allow us to tell our computers what to do and how to do it; mostly just helping us feed a stream of ones and zeros, the machines’ only language, to our computers. You may or may not have heard of Assembler, Pascal, C or C++, and dozens of others, but these languages allow us to write “code” in something that is somewhat akin to english, but a bit more cryptic; this is then compiled/translated into these endless steams of ones and zeros. Don’t forget the word “cryptic,” because much of this written “code” resembles algebraic equations; in fact, much of it is precisely that; done with the full realization that many of the people that would be drawn to writing such “code” would have mathematical backgrounds and would find this approach quite comfortable.

As they did with the computer itself, making Macintosh the only truly user friendly computer from the outset, in the late 80s Apple produced HyperCard, taking this whole process to a new and better level, creating a user-friendly programming language that Apple named HyperTalk, buried deeply inside a use- friendly way to use it that they named HyperCard. With HyperTalk, it is not necessary to learn a new language; only how to arrange the words and learn the meaning given to some special words. With Revolution, things are much the same, with the name of the language now being Transcript. It could have been called Magoo, or anything else, since the name is really meaningless. As far as I can tell at this point, Transcript is almost exactly like HyperTalk, but obviously with extensions since Revolution must do so much more than HyperCard did. One other thing that Revolution provides that only happened with HyperCard over a period of several years: a very good user guide, printed and online in PDF format; and a book written by Dan Shafer, the author of a couple of excellent HyperCard tomes, are all available. Of course, Revolution and its other HyperCard successors have gone through a succession of upgrades since they first emerged subsequent to HyperCard’s apparent demise.

With HyperCard on our Macs, all we need in order to do some pretty amazing things is the English language, some common sense and a little patience learning some special grammatical syntax and the meanings of some very special words. You will find that your fondest dreams have been realized, and that you can now make your computer do exactly what you want it to do, create solutions to your own special problems and even sell them to others to make a profit should you so decide. If you have mathematical problems of any sort, go for it. If your problems are more complex, don’t worry. They will be just as easily resolved. Your only problem in the beginning will be to determine how to approach the solution. Most problems seem enormous when viewed in their totality. Your biggest challenge will be to break the enormity down into resolvable small elements for which you can envision a solution. Actually, this is the same process you would use regardless of the programming language you should chose to use; only seeing a solution and actually resolving the various stages in HyperCard or Revolution will be hundreds of times easier than they would be in any other language you might have chosen to use. I found this to be the case to such an extent that I copyrighted all of my solutions under the name “Easier done than Said”, since I was usually able to solve my problems more easily than I could describe what the problems were or how I was going to solve them.

At one point, there was a controversy in the air as to exactly what HyperCard was. It greatly resembled an electronic rolodex mostly because many of the first examples provided by Apple were, in fact, Rolodex-type things; but it also appeared that HyperCard could be used as a database, what with its capacity to hold, identify, organize, search and edit all sorts of data in fairly substantial quantities. For many Mac users it became the only application they needed on their computers. At least for me it worked that way. I was absolutely fascinated by all of the different kinds of things I was able to do. I even used it to prototype several programs that I eventually rewrote in both FutureBasic for the Mac and Visual Basic for Windows PCs. At that point in time, HyperCard had three drawbacks: It was extremely slow, somewhat difficult to use with color; and it was not cross-platform; the reason I had to rewrite these programs in two different Basic languages. These problems are totally eliminated with Revolution.

Contrasted to HyperCard, which only worked on Macintosh and was limited to black and white displays, Revolution is a write once and run everywhere application, but what does that mean? To keep this very simple, Revolution is “something” you can license and put on your computer, Mac or WinTel, that will allow you to do marvelous things, limited only by your imagination and creative ability; and do them easily with a minimum of head scratching and manual reading. If you have something you’d like to get done on your computer, either just for yourself, or to share or sell to others, you can do it more easily with Revolution than with any other development system available; or, so they say. With this column I will explore all of the claims made for Revolution. Does it live up to my expectations? Is it as great as they say it is, or as it should be in order to follow in HyperCard’s monumental footsteps? In my opinion, Microsoft developed Visual Basic to directly compete with HyperCard. It came so close to copying the kinds of things that HyperCard let its users do that it became the favored development language for a staggering number of PC users. Even though it carried the tag of being just a “Basic” language. Of course, Microsoft never did get it totally right!

The better you know how to use your Mac, the less head scratching and reading you’ll have to do, because Revolution is Mac in its very essence. We’ll get into all of this at a much deeper level later on. Hey, I didn’t say you won’t have to read at all; just that what you do read will make a lot of sense. I will say, at this point, that there have been some really “dumb” things done with the references and screen shots in the User’s Guide in order to create a cross platform engine that caters to Window’s users; namely referring to the Control and Alt keys instead of the Command and Option keys familiar to Mac users; and with screen shots showing only Windows Dialogs and such. This has a way of alienating diehard Mac users; or, at least, me.

This Macinstruct column will eventually cover a great deal more than a series covering only Revolution. Since I’m one of those guys who has always concentrated on being a master of nothing, I’ve tried virtually every programming language that has come down the pike, going back to Fortran 77 that had to be run under a non-Apple operating system called the “UCSD P” system. Then there was the MDS 68k Assembler, Macintosh Pascal, and TML Pascal and all the Lightspeeds; finally HyperCard itself, and a multitude of others in Pascal and a really idiotic language called “C” that got its name because it followed a language called “B” that never got off the ground. I even purchased a book on Macintosh Basic, a language that also never saw the light of day.

Eventually, I discovered FutureBasic II, which has somewhat recently become FB^3 and now 4; that was the end of my search for languages. If I couldn’t do what I needed with HyperCard, I’d do it with FB. The Macs, at that point, were still too slow to handle graphical applications written with HyperCard though the speed bumps could often be ameliorated with pre-compiled External Commands and Functions, something that could be easily done with HyperTalk to speed things up; plus color was awkward at best, something HC never did handle adequately. For sometime everything I did was in FutureBasic, but it is not cross platform. I had tried SuperCard, a HyperCard imitator, fairly early in the game; but it was also not cross platform, so I took a look at Java, a language I had tried prior to discovering FutureBasic. By this time, Java had been dramatically improved over its earlier versions, but for me the learning curve was still much steeper than it would be for a development system such as Revolution, which would enable me to utilize my vast HyperTalk experience. So, that is why I am doing this. I am going to learn Revolution, and I am taking you along for the ride. Oh, did I mention? The only language you need for Revolution is English, plus a little common sense.

What Could People Do With HyperCard?

First a little nostalgia. If you read the prelude to this column you may wish to skip the next three or four paragraphs. HyperCard first made its appearance in the late 80s and I was one of its very biggest fans. For several years, though a licensed architect, I made my living creating HyperCard stacks of a highly sophisticated nature. This was in the era of the Mac SE30 with its dinky little black and white, 9 inch screen and 16 mhz processor; without a built-in hard drive. The programs ran off of 3.5 inch floppy disks. Wonder of wonders! Compared to what Mac users are accustomed today, it was astonishingly slow, but who knew better at that time! The major stacks I wrote were, if you can believe this, for number crunching; a point of sale Invoicing module and a Monthly Statement module. My client was a large blueprint company in the San Diego area. They had been using a DOS program run on a Radio Shack Tandy Computer for all of their accounting functions. It was not ancient, but it was going to have to be replaced with something new shortly, and the business that wrote the software for it wanted an outrageous fee for upgrading that. Plus they had to enter each day’s print orders into the computer from paper records.

Having seen the amazing things I was able to do with my “little Mac” on architectural projects printed out on a wide carriage, dot-matrix Apple Printer using a software package called MacDraft and then, later, renamed Dreams, they challenged me to come up with something that was more cost effective; and this was when they were going to have to pay about $3,000 for each of the Mac SE30s they were eventually going to use. Needless to say, I took the challenge, working closely with their “bookkeeper,” Elizabeth Spence; and, by the time I was able to order and install the Macs and Apple dot-matrix printers they were going to use, I had a working version of the first HyperCard module that let them, for the first time, get away from the handwritten Invoices they had been using for the previous 10 to 15 years.

The very first version, though it did the job and was much, much faster and error free than doing print orders and invoices by hand with a pocket calculator, recorded the information for them, priced it accurately, added the applicable sales tax and stored the results on an account card in the Invoicing Module; then printing an invoice for the customer to take with them. Before we could use the Invoicing Module, the client entered the information for roughly 1,500 of their customers. None of the personnel, except for the bookkeeper, had ever seen any kind of computer before. After the first day they were using this Invoicing Module with no additional assistance from me.

Over the course of several months the Invoicer was expanded and a new module was created into which each of the daily totals was stored for each account. At the end of each day, something that took quite a few minutes at that time, all of the Invoice data for that day was transferred to this monthly Statement Module. It was used to print all of the accounts’ statements at the end of the month. Fortunately, about this time Apple’s first Laser Printer became available, but a standard Apple dot-matrix printer continued to turn out the job invoices while the work was being printed. Not really fast, but it did the job and got the clients out the door in a timely fashion. The following screen shots are of the Account Record Module, which initially because of the memory available on a single floppy disk, had to be allocated to several letters of the alphabet instead of A-Z as the one shown here. Things were greatly simplified as our hard disks replaced the floppies, and got huge with the introduction of gigabyte capacities.

Note the current month’s activity is summarized in the panel left/center; a bank of pop-up menus appear in the right/center panel and two bands of icons for accessing other applications and desk accessories appear above a navigation band of icons at the bottom. An interesting note is that, even though HyperCard did not support color when we started out, such things as the pop-up menus did use the system colors once we had color monitors. That happened rather quickly.

The following screen shot shows another of the pop-up menus in use. Even though the screen sizes increased over the years, the overall size of the modules remained the same but were used at a much larger resolution to save the eyesight of the users. In the beginning, these modules were used with System 6, but these screen shots were taken when used with the last non-OSX system, 9.2.2. No changes ever had to be made because of the computer upgrades and OS changes; we just enjoyed the improved operation. Things that had taken a matter of several seconds with the SE30s, happened almost instantaneously with iMacs.

The following screen shot is of the Invoicer module. Each invoice was started by pressing the Enter Key. This displayed a dialog allowing an account number or name to be inserted. Hitting the Enter Key once again brought the data for that account into the Sold To area. Based on which of the buttons at the bottom were selected, the Menu in the center would change by product; then pressing the Enter Key again would begin the entry of the next invoice line. For the most part, the user was pressing the Enter Key to get things done. All of the prices were kept in a separate Prices module that were picked up when the Invoicer was opened and remained in memory for immediate access. Even with the original SE30s, activity was instantaneous. Printing took a bit longer, perhaps 10 seconds to print most invoices. This improved when we moved to Laser Printers, something that occurred in a matter of a few months. Things were developing fast in those days.

However, speed did get to be more and more of a concern, since the operators were getting faster at using the system themselves; my programming experience at that point was still somewhat limited, but there was a Mac program called Compile-It™ that allowed the ordinary HyperCard HyperTalk scripts to be compiled into External Functions and Procedures. Almost anything that did something within an HyperCard script could be changed from relatively slow moving HyperTalk to extremely fast machine code that didn’t first need to be interpreted by the HyperCard engine. It could just be “run”. Compile-It™ did have a few idiosyncrasies; but, for the most part it was just a matter of blocking out portions of the scripts for compiling and replacing them with the name of the External created by Compile-It™ from the blocked-out code. In most cases the original scripting was left in place, merely “commented out”, so that it could be reused in the event of a bug in the External that was replacing it. Using this technique enabled this series of HyperCard stacks (modules) to continue in use for the better part of 15 years, despite the new models of the computers produced by Apple during that period of time. Before the modules were finally put out to pasture, via a sale of the company to a much larger one that used PCs, the first iMacs were at the front desk of the company; my HyperCard modules continued to work better and faster - much, much faster - than they ever had.

Even today, under the Classic environment, HyperCard stacks work on a Mac running OS X; but with no color and the inability to create programs - stacks - that run natively on the new Intel Macs and on PCs running Windows, it is time to move on. That is where Revolution comes in. I must admit that I was initially turned off by Revolution and its prior HyperCard replacements; mostly by the fact that I had been spoiled. In the HyperCard hay-days, every new Mac arrived with HyperCard pre-loaded and it was free. Revolution is not free. In fact it is expensive, but most good software that doesn’t come from Apple for free IS expensive. However, Revolution offers features that will now make it desirable by most HyperCard devotees. It has reached the stage of development with Version 2.7 in which Revolution has been released as Universal Binary capable. We’ll eventually get into explaining what that means for you.