Immersed in the Apple ][

by Simon St. Laurent

I've been working with an Apple ][ emulator lately, remembering some of the charms it had that we've largely lost since.



Users of the Apple, or my old Franklin, or many of the other systems out there at the time, had a much more "up close and personal" relationship with the hardware and with the software. I remember my parents talking about a System/360 they'd used in graduate school with punch cards, and wondering how anyone could stand it, when instant feedback from the computer was available right in our den.



Applesoft BASIC and DOS 3.3 were programs, sure, but there was much less distance between me typing at the keyboard and the programs I wrote than there is now between me and any Java program I write. BASIC and DOS intermingled easily, though with a very different vibe than shell scripting has. There's was no compile-link-wait-wait-run-oh-no-recompile-link-wait-maybe cycle. I could type A=1 into the thing, then PRINT A five minutes later and get back "1". Writing programs didn't feel like a separate process from using the computer.



(Logo also felt that way a lot of the time, though it was kind of its own separate environment.)




Typing a program into the Apple ][e emulator



After I ran the program, or broke out of it for whatever reason, I still had access to variables and could see what happened.




Testing a variable in the Apple ][e emulator



Applesoft was my preferred language then, and I've blamed it for years for my spaghetti programming tendencies. Coming back to it, though, I'm not sure I'm right about that blame. Sure, life with all global variables and no named subroutines is probably not a great way to learn if you value encapsulation, but I have to wonder if structured programming and then the current generation of object-oriented development have their own problems. I've seen a lot of strangely thought out encapsulation that I think may be the result of not having worked without it.



They're not so much technical problems as political problems. "Hello World" in Applesoft is simple: PRINT "Hello World". It doesn't even need a line number. In Java, you're trapped into creating an object with a main() routine. It's ordinary to rely blindly on thousands of lines of library code to get simple things done. Applesoft certainly did things for me - even the Monitor environment and its mini-assembler were there to make life more convenient - but it was a much thinner layer, and I could do all kinds of damage to myself if I wanted to. When I first saw the Macintosh, I wondered why anyone wanted a computer that kept them away from the computing.



In looking back and comparing, my programs run about as well as they did then, and debugging, while a different process with a lot more up-front investment, takes about the same amount of brainpower. I was doing different things, certainly, when I was 13, but the games I was writing weren't much less complicated than the odd XML parsers I've conjured more recently. (I wasn't a professional programmer then, and I'm not one now.)



One thing I do remember well was the low frequency of unexplainable crashes. It seems like a 128-level stack limit should have ensured periodic disasters, but it didn't. The commercial software I bought was remarkably reliable stuff, even relative to what I'm running on my iMac today. I don't think I'm ready to chuck Microsoft Word and go back to AceWriter, even if I can get the disk working, but Word sure has crashed a lot more.



I'll be playing with this thing for a while. It's been fascinating reading the old books, which seem a lot easier now, and I need to get back into assembly work. I've been having a great time so far on this tour, and hope to do something useful, if perhaps perversely useful (not a lot of people run Apple ][s any more!) with this thing, and I'll let you know when I have something worth showing.




(I still haven't found bootable DOS 3.3 disks, but I do now have an Apple ][e, giving me a legitimate set of ROMs. Virtual II has been great. Maybe Apple could start throwing in a copy of the old ROMs with every Mac?)





If you only have 64KB to play with, would you rather use J2ME or an Apple ][-like environment?


17 Comments

timharig
2004-07-01 16:36:59
A user command interpreter...
...is one of the things that I really like about the Python distrobution. It is one of the great assesets of /bin/sh. Many times I paste part of my code directly into the interpreter's consol and then check to see that all of the variables are what they should be. I have never had need for a debugger under these conditions. I do not even have to litter my code with internal coherency tests. I with that all interpreted languages would provide the same facilities. Ruby and Perl could really benefit from adding a command shell to their distrobutions as well.
timharig
2004-07-01 16:37:05
A user command interpreter...
...is one of the things that I really like about the Python distrobution. It is one of the great assesets of /bin/sh. Many times I paste part of my code directly into the interpreter's consol and then check to see that all of the variables are what they should be. I have never had need for a debugger under these conditions. I do not even have to litter my code with internal coherency tests. I with that all interpreted languages would provide the same facilities. Ruby and Perl could really benefit from adding a command shell to their distrobutions as well.
timharig
2004-07-01 16:46:06
Something wrong with the cgi code
I am sorry if the parent post appears more then once. There is something wrong with the cgi code that has been providing me difficulty in posting and viewing this entry. Something else is strange, I found this posting in my RSS client but it does not appear if I try to reach it through the weblogs.oreilly.com. The error page generated by Oreilly does not contain the address to send problem reports or even display the URL that I am trying to view.
bazzargh
2004-07-02 03:53:23
A user command interpreter...
plain:
perl -ne eval


fancy:
perl -ne 'BEGIN{print"> "}eval;$@ and warn $@;print "\n> "'


featureful:
perl -de 1


take your pick?

simonstl
2004-07-02 05:30:44
It's not just having an interpreter
It's the way that the Apple ]['s interpreters were integrated with the whole system. They're not an extra feature, wonderful though it may be to have, but the fundamental heart of the system.


Perl and Python are excellent languages, but they tend to be run in their own little boxes. Maybe a "Perl shell" or "Python shell" of some kind would be closer to what I'm thinking of in a more modern context.

timharig
2004-07-02 06:57:08
perl -ne etc is not a real command shell
If you launch python without any options it presents you will a command prompt. The only thing that it lacks for being a more useful shell is command completion.
timharig
2004-07-02 07:04:59
python shell
The python shell is not an added on feature. It works jusk like /bin/sh. It can be used interactively or as part of a batch script. The only differences between the two is that if it is being used from standard input it presents a prompt and a stand-alone variable statement prints itself. Just like Applesoft if I recall correctly. The only thing that it lacks for being a useful shell is the shell dogma that "if the command is not found locally in the interpreter then look in $PATH or a command to take its place." That makes it require calling an exec() or psopen() function to run external programs. As I recall in Applesoft BASIC you need to run LOAD or BLOAD (depending whether the file was basic code or a binary) and then run to execute it. Not much different.


Python shell is otherwise fully capable of performing as a runtime shell just like Bash or Applesoft. If you do not believe me, run "chsh -e /usr/bin/python" sometime. I assume that would work for the perl directives listed above as well.

simonstl
2004-07-02 07:21:37
fair enough
I'm glad it's technically available, though we still seem to have lost something culturally. When I think of "shells", Perl and Python sure don't come to mind. Software that was written specifically to be a shell does.


I'm not sure I've ever worked in an environment where people booted to a Perl or Python shell and worked that way, though that may just be a factor of where I have worked. I can't say I've written _that_ much Perl or Python, but I don't think I've ever used the shell as a tool for writing programs. (Same with various JavaScript command lines.) I'll have to take a closer look.


On LOAD/BLOAD, you did that to load programs into memory, but the editing process for creating Applesoft programs was all done at the command-line. There wasn't much notion of a separate editor - of course, beyond the arrow keys, there wasn't much notion of an editor at all.

bazzargh
2004-07-02 09:07:33
perl -ne etc is not a real command shell
command line completion... and unix pipes, redirection, surely? I was being a bit facetious posting those examples, but neither the 'perl -de 1' or 'python' are useful as shells. Otherwise projects like PySH and PerlSH woudln't exist.


Back on topic, I'm with Simon on this one. I grew up with the MZ80K, ZX81, Acorn Atom... home machines of that era presented you with a blank slate and a programming language, encouraging you to learn. Today even linux is festooned with apps, there are less itches to scratch. To be fair, Apple's iLife is maybe todays equivalent, tools to create "stuff".


Although, I was struck recently by the 'Processing' system, it has that 'hey look what I just made' feel too.
http://processing.org/index.html


I guess I should sign up for the alpha and see if its got a command line...



timharig
2004-07-02 09:21:24
fair enough
If you are not familiar with the shell as a programming environment then you should consider getting a book on shell scripting for the shell of your choice. It sounds like that is exactly what you are looking for. As I have mentioned before Perl/Python lack the syntactic sugar for efficient interactive use.


In many ways a command shell is far more flexible then Applesoft ever could have been. With BASIC, all of the possible commands were set in the interpeter binary. With a shell any program on your system becomes an potential command. A well built Unix distrobution contains hundreds of small utilities that can be useful in shell script for doing varous tasks, accessing information, or controling various pieces of hardware.


I loved Applesoft basic as shell and a command environment. It was were I first gained appreciation for the command line in the first place. It does not however hold a candle to a good Unix shell interpreter for power and flexibility. A Unix shell environment discribes all of the culture and attributes that you have written about in your entry.

simonstl
2004-07-02 09:47:19
now I think you're missing my point
"If you are not familiar with the shell as a programming environment then you should consider getting a book on shell scripting for the shell of your choice. It sounds like that is exactly what you are looking for."


Thanks, but I'm familiar with shell scripting and have plenty of books on the subject. Shell scripting is great, powerful stuff, but it's not the same kind of immediacy you get at the Apple ][ command line. You're not as close to the computer, and your programming and general mucking around aren't nearly as intermingled.


As delightful as I find it that Mac OS X (finally) provides a command-line, the experience of using it with whatever shell I happen to choose is very different than the experience I have of using an Apple ][.


"As I have mentioned before Perl/Python lack the syntactic sugar for efficient interactive use."


That would perhaps explain why I didn't consider them interactive (in use if not in capabilities) in the same sense as the old Apple ][ prompt. The Apple ][ prompt has plenty of inefficiency, but it was also accepted as the primary way to do things, not just an option that might or might not be useful. Like it or not, you had become friends with the interactive prompt.


"I loved Applesoft basic as shell and a command environment. It was were I first gained appreciation for the command line in the first place. It does not however hold a candle to a good Unix shell interpreter for power and flexibility. A Unix shell environment discribes all of the culture and attributes that you have written about in your entry."


Sure, it's far more powerful, way more flexible, etc. It's also a step or two further abstracted from the hardware. That's fine for what it does, but it's not the experience I was celebrating here.


The culture has changed, even among geeks - we aren't as close to the systems as we used to be, and we certainly aren't encouraged to PEEK and POKE around the way we used to be. A lot's been gained over the 20-odd years since the Apple ][ arrived, but I think you're avoiding any acknowledgment that a few things have been lost as well.


If you consider yourself past the Apple ][ experience, that's fine. Just please don't tell me that what I'm really looking for is a Unix shell.

timharig
2004-07-02 10:17:12
now I think you're missing my point
I am missing your point, for the second time now. I fail to understand what you feel has been lost. I am starting to feel like I am just intruding on aesthetics based on your nestagia. I do not feel that I am past the apple ][, I have once sitting here in my office that I still use for various purposes.


I can still still do the equivilent to PEEK, POKE, and (there was a third command that I do not remember in this class.) I just use different semantics such as echo "yes" > /proc/whatever. I agree that the instant gratification was nice but as I have explained it is not gone. I still find occasion to write in assembly. I fail to understand what besides fond memories what you think is missing. I do not perceive that "real" geek culture has changed. There are many non-geeks now among us who want to distance themselves from the hardware and abstract everything but there are still many of use working at the very low level.


I also had very fond experiences with the Apple ][ but I do not mourn their loss like you seem to. I have the same basic mindset using them then as I do now using newer machines now. I have leaned to take the values that I used on the Apple ][ along with me whether it is writing assembly code for the Z80 in my calculater or administrating a multi-processor server.

timharig
2004-07-02 10:21:10
CALL
I remember now PEEK, POKE, and CALL. All just subtly different.
simonstl
2004-07-02 10:37:54
a celebration, not a mourning
"I am starting to feel like I am just intruding on aesthetics based on your nestagia."


I think the impact of how directly we interact with computers goes way beyond aesthetics and nostalgia, but can't say convincing you of that is particularly interesting.


You've had the experience, seem to have enjoyed it, but don't care about the differences between that experience and the technologies you're pushing in this discussion. If you won't acknowledge that there are meaningful differences that aren't just later improvements, there's not very much to discuss.


TylerMitchell
2004-07-04 08:17:20
A user command interpreter...
Funny, as I was reading this item I was thinking about Python too for some reason..


I have some similar (not exactly) nostalgia around my Tandy Colour Computer / TSR 80 / BASIC days. The ability to instantaneously check variables after getting a clean "syntax error line 80" seems refreshing in my mind today.


Speaking of integrating shell-like capabilities, I use this mapping/image analysis program called OpenEV. It's Python-based and uses GTK for GUI. You can go through it, check out all the features and then you start to wonder "how do I extend this thing to task x?". Well, it's refreshing when you simply goto the menu and select Python Shell. Sure enough a full, normal shell, but with all the OpenEV capabilities for image analysis, etc.


Not to start up more talk about shells :) but it just makes me wonder if other languages that do not have shells - how can they completely implemented as shells in other applications. My example is only one, but has made an impact on how any custom scripting languages I may write for one-off applications. Instead we'll use a similar "embed Python shell" approach.


Tyler


MdntTrain
2004-07-06 09:29:09
The Apple II was sexy.
Simon -- I agree with your celebration of the II. Though my reasons have largely been nostalgic, I've recently found myself on various Ebay buying sprees reobtaining Apple II items like what I once owned in 1979-1985. I sorely regret having sold all my original equipment, and thrown out all the software I wrote, including my NWDS Lights & Magix bulletin board that I hosted out of Washington, D.C.


There is indeed something lost in the new computing environments. I liken it to the automobile, where with older cars you can tinker and fix just about anything, and had to to keep them going. It was easy to become familiar with the engine for instance... and too you were not separated from it by so much insulation.. so your experience of the engine was very direct and sensual. Cars today are not so exciting in a raw, sensual way.. though they are far more refined and capable performers.. they are also more *distant* and isolated. One could say the sex has been perfected out of them.


My experience of the Apple II now is like that of the cars above. It is raw, direct, you are speaking with the CPU only a layer or two away, and you can instantly hop down to the lower layers if wanted, controlling hardware directly.. it's like hearing the sexy engine right in front of you, loudly, clearly, every throaty inhalation and firing resonating through you.


~ J

dor
2005-02-10 06:28:15
A user command interpreter...
Does BeanShell of IBM holds this capability too (command shell)?


D. Orbach
booksprice - one book one click best price