Input One, March’s program of the month, is a great example of the kind of simple and brute force programming of the 1980s. This was a time when computers had little memory and their users had to use simple BASIC programming to get things done. The alternative was to buy a cassette tape of programs that took minutes to load even short programs, assuming they loaded at all. For the rest of us, we either typed them in or wrote little programs like this.
As much as I look back on those days with a sense of nostalgia, I don’t miss it. The ZX81 in particular was finicky and often crashed and its membrane keyboard didn’t always register key presses. When I stepped up to a Commodore 64 and later Amiga 500, I never looked back. Programs were in color, more exciting, and generally more usable. Even so, I still enjoy looking back on that little machine I spent three years programming.
That brings me back to this little program. Written in 1984, I was already writing much more complex programs than this one. I can only guess that this was a little test program to try out some idea. In this case, that idea was to impart upon the program a sense of human. As if you were a stranger, the program asks your name and how you are. You answer. That’s it.
As the name implies, the program uses the
INPUT statement to gather the data asked. It uses your name in its response, but now how you feel. Instead, it relates to what you typed by responding to some common words. If you answer with one of the better words, it states that it feels similarly. If not, it hopes you feel better. Of course, you could still feel peachy and Input One will give its melancholy response. It doesn’t know any better because peachy isn’t in its vocabulary.
Once it’s asked its questions, Input One heads off to do what computers do when they pretend they are sentient. Its cute and charming, but it won’t entertain you as it is too short. As noted and like many of my programs, Input One is more of an experiment than practical.
The code itself isn’t the best. The vocabulary test is a simple
IF statement with a string of Boolean checks. First I check if it matches the list and then turn around and do the something with the negative case. It is very brute force and I could have used branching (
GOTO) and some other methods to make the code more flexible. For example, using an array to hold the vocabulary would have allowed me to test against a larger list of words.
Even cooler, it would have been more interesting if I’d thought the program how to learn new words. If I’d asked how the user felt about words Input One didn’t know I could have saved that answer for later. Of course, the ZX81 would eventually run out of memory, but it would still be an interesting exercise. What do you think? Is this something you could write?