|Ease/Dis-ease of Keystroke Programming|
Message #1 Posted by Howard Owen on 30 Dec 2005, 2:00 p.m.
I know some would say our obsessions with calculators is evidence that our minds are a little "diseased".
That has certainly been true of me for the last couple of weeks. I have been caught and held hostage by a little electronic/mechanical device known as an HP-42S. I have been so enchanted with the little beast, that I have cranked over 1000 lines of calculator language in pursuit of the perfect embodiment of "YATZ," the game I use as a vehicle for learning about programming the old machines in my collection. It's certainly arguable whether I need so many lines to play that stupid (but fun) little dice game. But I want to use the features of each platform to the fullest extent possible. On the 42S, that means graphicl representations of the dice and scorecard, and that means lots of binary data. The initialization routine (not run every time) therefore takes over five hundred lines all by itself. The core of the game is currently at 530 lines or so, and will go higher before I'm through.
At that level, I've run into some scalability problems that I thought I'd share with this forum. Before getting into these, I have to praise the ergonomics of the 42S again. Program entry is very nice on this machine. The keystroke sequences you need in order to access common programming, matrix manipulation and alphanumeric functions is very regular and logical. It usually takes two to three keystrokes at worst to access the function you need.
The pickboard style of alpha entry is an example of this. Press [SHIFT] [ENTER] to get to alpha mode, or enter it via any function that can use or requires alphanumerics, and you see a menu of the uppercase alphabet spread over six keys. To get an upper case letter, press its menu key, then the key for the letter - two keystrokes. To get lowercase, press shift (orange key) before you press the letter key - that's three keystrokes. Since there are 6 menu keys and at most five letters per alphabet range, there is always a blank key in the letter pick menu. Pressing these always gives you a space. Less common letters are accessed from a secondary menu which you get to by pressing an arrow key at the main pick-board. You still only have three keystrokes on average, but it's not as straightforward and takes a little longer.
That lash up is a little awkward to describe but a breeze to use once you learn it. In fact. I find it to be the easiest system for alpha entry I know of, second to the qwerty keyboard that is burned into my synapses by a lifetime's use. The rest of the functions of the 42S are similarly well thought out, and I find I can crank code on the machine at nearly the speed of (careful, deliberate) thought.
But what I can't do is keep more than about five numeric labels and their meanings in my mind while I'm thinking about how to do some tricky piece of coding. Four labels I can manage, but five blows me out of the water. This is partly because numbers are not names, and partly because I can see at most two lines of code at a time in the calclator's display. "But the 42S has six character named labels!" I hear you protest. Yes. but multicharacter labels (and single character ones after "J") are global on the 42S. This means that after a certain point, they clutter up the XEQ and GTO menus to the point where the nice, easy structure is overwhelmed. In a program the size of YATZ42, however, numeric labels just don't cut it. So I've replaced many numeric labels with alpha globals. I may switch them back after I have the whole thing debugged.
A related problem has to do with the limited window on the program provided by the two line display. Often one section of code depends on one or more widely seperated other bits of code. You can't see the two sections side by side in that two line window. These all conspire to make that sort of coding difficult. I've adopted two different strategies for dealing with this. When the program was smaller, I would print it out to an HP 82240B printer. That was slow, but it worked. Since the program has grown larger, I've tended to print to INPRT running on an HP48GX instead. This is much slower, and requires extra transfer and conversion steps to get a listing in a form in which it can be viewed in an editor on the PC screen. Then, as I make changes, the version on the calculator and the one on the PC drift slowly apart, until the work of remembering which changes I've made recently exceeds the inconvenience of generating a new listing.
Finally, there's the fact that data - variables, registers, flags and the stack - are all global on the 42S. This makes it harder to have two significant apps loaded at the same time without collisions. I know the registers are accessible in a matrix called "REGS." and that you can rename and replace this matrix, thus giving you a way to implement local registers. But that doesn't work for named variables or the stack, and what if you bomb having made your local copy of REGS? There's no ON ERROR construct.
So there you have three barriers to scalability of keystroke programs on the HP42S. There are workarounds for some of them, but no outright solutions. Clearly, the machine wasn't designed to scale up very far. The programming model was born on smaller machines, and makes more sense when applied to smaller problems. But that raises an interesting question: is there value in extending keystroke programming to larger environments, meaning ones with a lot more memory and processor speed? It seems certain to me that just dropping the 42S environment down in the middle of such resources would be a dismal failure. The language and architecture would, at the very least, have to change to account for the deficiencies outlined above.
What sort of changes do you think might be necessary to acheive success in the larger environment? Here's my list:
- Real local scopes - local names should be possible, for labels variables, stacks and so forth.
- Two-way I/O - this to facilitate program editing off the calculator. Bonus points: make program editing on the PC transparent through to the target machine.
That's it. The points, few as they are, beg another question: how can you implement them without screwing up what is nice about keystroke programming? This is really the original question restated: whether keystroke programming can be scaled up at all, or should,
Edited: 30 Dec 2005, 2:26 p.m.