I would rather read my old LiveJournal than look at code I wrote in 1999

I’ve been digging around my machine trying to find any fun old projects I could throw on my GitHub page. What I’m mostly finding is how I get grandiose ideas for programming projects and then abandon them in a week. Some of the programming I did in college is absolutely laughable, but it’s also amazing how many things I’ve started that I’ve completely forgotten about.

I wrote a while ago about Nuke ‘Em, which is a dumb idea for a turn-based strategy game that I’ve chased every time I’ve moved to a new language or platform. I think the closest I’ve gotten to something running is a Ruby on Rails attempt I played with in 2008. But last night, I was digging through some C source code I wrote in 1999, trying to get a web based version of this going, and it was… interesting reading.

Looking at the code, it’s amazing how many ways I was reinventing the wheel, or painting myself into a corner. A few observations:

  • The project was a bunch of C source that would compile into a half-dozen CGI files that would then go onto a web server. When a user went to /user/login or whatever, that would run the login CGI binary. Why didn’t I just write a bunch of Perl scripts or some PHP for this? Well, I guess I already knew C, no use in learning something new and relevant.
  • Actually, some of the pages were generated by shell scripts which had forms where the action was to hit one of the binaries.
  • I doubt anyone would try to do something like use cURL to download the actual login binary, open it in a binary editor, and mess with it, right?
  • There was no templating system for generating web pages in 1999  (that I knew of; there probably was) so I had a routine to glue a head.html and tail.html template at the start and end of each generated page.
  • Part of the decision to do things this way was based on the limitations of my hosting provider, and part of it was price. I’m sure MS FrontPage would have made this all easier, but I think I was unemployed when I was doing this.
  • There is what I think is my first attempt ever at writing a Makefile from scratch. It shows.
  • The whole thing used a series of ndbm databases to store everything, including users, passwords, the map, and pending user turns. This databases were created in the /tmp directory and were world-writeable files. Nobody would think of looking around the /tmp directory of a public web server, so this was totally secure.
  • ndbm (or its predecessor NDBM) was basically like the first NoSQL database ever, sort of. (I would think a garage full of punchcards in random order would be the actual first NoSQL database, but whatever.) Anyway, it wasn’t relational, and didn’t have tables, so each “table” was just another file in the /tmp directory.
  • When you set up the world by creating initial users and making a terrain map and such, you would just run another binary which spat out the configured db files. Only an administrator could do this, because the files were different executables not installed in the hosted web directory. It didn’t check in any way if an admin was running the scripts, but it’s not like someone other than the admin would compile and run the source themselves and overwrite the world-writable files in the /tmp directory, would they?
  • There is a whole science to map-building, how to algorithmically scallop out water and land edges and mountains in some pseudo-random way to make a cool map of a world on the fly. This randomly generated a single-digit number for every square on the map and put that terrain in place.
  • For everything, and especially in the login, parameters like username and password are passed in the URL, because nobody would screw around and pass a bunch of garbage in URL parameters. And there probably weren’t search engines crawling and permanently storing parameterized URLs to do things like delete all users.
  • Oh, that password parameter is sent plaintext. It’s got to match the password in the publicly-readable database in the /tmp directory, which is also plaintext.
  • Players each have money they spend to build armies and buy missiles and stuff. Guess where that number is stored.
  • There is a separate library file (a .c and .h) that is chock full of dumb stuff that isn’t in the standard library, but I’m sure there are 863 different public libraries that do it, and if this was NodeJS or Ruby or Python, it would either be a built-in or it would be an npm/gem/library away. Like why did I write a routine to convert encoded URL parameters into arrays? Why did I write my own routine to convert ASCII strings into integers? Why didn’t I write something to encapsulate database calls, instead of pasting the same dozen lines across multiple files?
  • I don’t know why I did this, but the maximum length of a URL is malloc’ed to a size determined by reading an environment label, and I have no idea where that was set. (!?)
  • Not sure what C unit testing framework existed in 1999, but mine consisted of a file called test.c that ran a bunch of code and printf’ed the results to the console.
  • I never got to the point of putting in the turn-based logic, but my loose notes showed that I wanted to have a cron job that would fire every ten minutes (or whatever) and run a program that evaluated all of the turn moves and calculated out the combat losses and money spent and all that stuff.
  • No source control, of course. Lots of ~ and # emacs files, and lots of files copied with a .backup extension.

Sigh. Okay, a few bits of advice to myself twenty-some years ago:

  • The first is to learn PHP (ugh) or wait a few years and do it all in Ruby on Rails. I know Rails isn’t cool anymore, but it would have been so much easier to build models for all of the basic data types, then scaffold the whole thing, implement controllers for the bits of logic, and take the scaffold views and make them pretty. Of course I still can’t deploy Rails apps on my hosting provider, so that’s another issue.
  • Find public libraries to do the nasty stuff. It wasn’t as much of an option then, but it is now. The rub here is it never feels like I’m building things anymore; I’m just connecting together things that other people have built, and then trying to keep up with when libraries change or break. Having a solid ORM library, a templating engine, and something to deal with session persistence would have saved me a ton of time. (See also using Rails for this.)
  • Break things up into smaller tasks, like as MVPs for each piece. I sort of did this, looking at my notes, but I probably would have went deeper if I had really planned this a bit. I usually do it all seat-of-the-pants, and then get overwhelmed when I have nine different problems going on at once.
  • Think about security first. I know my thought was to have it all use no passwords or plaintext, and I’d lock it down after I got it running. I should have thought about that earlier, so I didn’t paint myself into a corner.
  • Source control, dummy. RCS was a thing then, and I was already using it for my writing. Check in often. It’s free.

(PS, I’ll probably start writing this same dumb game as an Electron app the next time I get bored.)


Changing Gears

I haven’t been writing.  Probably haven’t put word to paper in at least two weeks.  Normally, this would have me freaking the fuck out, going to see shrinks, getting pills, doing exercises, buying books, studying courses, dissecting plot and premise and buying a flashcard system with 20-sided dice and spinners and software designed to Specifically Help You Write Your Novel in 14 seconds or less.  But I haven’t even thought about it.

I have not been writing because I have been coding.

I knew I would get this horrible postpartum depression after I finished my last book.  I knew nobody would buy it, no matter how hard I pimped it out.  I knew I would not be able to get another project going, and I would enter the downward spiral of over-examining all of my thoughts and ideas, mixed with going to the Amazon royalty page every seven minutes to see if anyone bought the damn book.  Same with the lulu royalty page, and the Google Analytics page to see the hits on this site.  That’s become the ritual; it used to be that the first thing I’d check, first thing in the morning, was my bank account site, to see if various checks had cleared and I would be able to scrape together seven dollars for some TV dinners to last until payday.  Lately, the glass pipe has been that site usage dashboard.

I don’t know when I decided this, but right around when I sent off the PDFs and Kindle files for the book, I decided I really wanted to write an iPhone game.  I realize I’m about three years too late to the party, but I felt some sudden urge to dive into one of the game frameworks and write something crazy, or at least do what everyone does and write a tetris or asteroids or pac man clone.  I know nothing about this, but I also know too much.  When I worked at the big S, we spend a lot of time looking at other developer programs and SDKs and tools, and I knew a lot about what didn’t work.  (Side note: there’s nothing more horrible than being locked in a conference room with a dozen middle-aged guys who know nothing about games or social networking sites, who have never played WoW or Mafia Wars and have never signed up for Facebook or twitter, and being forced to come up with million-dollar ideas for patentable games and social networking sites to be produced with no budget and no manpower.)

I downloaded GameSalad and after ten minutes decided that was a stupid system, so I hit the main vein and grabbed XCode and downloaded that giant multi-gig archive of Apple fun.  Then I dove straight in without looking, immersed myself in howtos and tutorials and O’Reilly tomes and FAQs.  I beat that Hello World like it owed me money and got locked into the Cocos2d framework and started that damn Pac Man clone.  Then I found out about tilemaps, and realized it was absolutely imperative to start that strategy RPG for the iPad.

I haven’t checked my royalty crap or web site stats since.  I used to hit facebook constantly, and now I’m barely on there, except to log in and delete a bunch of the bullshit academic lit journals I used to add in some hopes of finding readers.  I’m still on the web, but instead of picking fights with idiot teabaggers, I’m looking up how to output sorted arrays of keys from an NSMutableDictionary.  I have mixed feelings about this; I think my online time makes up some void that results from working from home and not being around people all day.  But there’s also been more than a few times where I thought about following some link to read about the latest idiot trying to run for president or whatever, and I thought, “I could either do this, or I could try to figure out which TouchDispatcher has handlers to read multitouch input.”  The latter wins every time.

I haven’t worked with C in a while.  We mostly use Java at the day job, and there’s some occasional C# and C++ out there, but my usage is limited to finding some function and unfucking the doc comments so the autogenerated API help is readable.  It’s been a long time since I sat down and tried to really hack out any kind of C code, but I realized that it was 20 years ago I started learning C, and it all came back fast.  What was more amazing is how the Objective C stuff gave me crazy flashbacks to 1992, back when I took C490 and we worked on the NeXT.  I spent most of my time in that class beating against Motif and C++ on the Sun workstations, so when I went to the NeXT and used Interface Builder, it was like showing RoboCop to a 14th century farmer.  The Objective C syntax seemed really foreign to me at first, but then I started getting the :s and [s and ]s in the right places.  I also ran into the usual C barrier of “is this a struct or a pointer to a struct or a pointer to a pointer to an object, and is it getting released here or do I need to retain it” stuff, and really hit the wall with it last weekend.  But I think I’m past it, and making some progress.

There’s also a certain nostalgia in writing a game in general.  I spent a lot of time way back when with graph paper, filling in squares to make bitmap fonts or maps of dungeons or designs of sprites.  Back then, there was only 64K of memory, and stuff like pointers did not exist as far as I knew.  (Yes, they did, but not to a 14-year-old in Elkhart, Indiana with no modem.)  Now I’m working with a thousand times the clock speed and 4,000 times as much memory, but the core thought process still remains.  I’ve got a lot more control over program structure than GOTO and GOSUB, but you still need to think about how those damn ghosts run around the maze by themselves.

There’s a small part of me wondering about when I will write again.  I mean, in a practical sense, I keep thinking I need to start a new blog so when I do find out that you can’t dynamically change tiles in an empty CCTMXLayer without crashing, I can write it down and not have to re-research it a month from now.  But there’s that bigger question of if I need to get back on the horse and write more books, and if it’s worth it to write books, and if anyone even reads books anymore, and if I want to write books that people want to read, and a flurry of other bullshit I don’t want to think about anymore.  I still do have the occasional flashes where I see something and think it would make a great short story.  But I’m waking up every morning and immediately thinking about what to code next, and that’s a good feeling.


Nuke ‘Em

Strategy games have been a real albatross around my neck, partly because they push the right buttons in my head that make me obsessively play them until I win, and when I win, it’s too boring and I have to play again at another difficulty level or play another game.  The latest incarnation of this is Catan HD on the iPad, which is a version of the insanely popular German board game Settlers of Catan.  I would love to play that game, but it involves getting together three or four people, so forget it.  (Unless you’re in the Bay Area and want to play.  I would even host games at my house, but nobody’s going to come to West Oakland to play a board game, even if I FedEx over kevlar vests and free gas cards.)  I have wasted a small amount of effort on Catan so far, and it kicks my ass every single time.  I am sure I will spend hours of my precious time trying to google out some strategies and beat the thing, and I am sure once I figure out the secret, I will get bored of it and consider it a waste of five dollars.

But a bigger obsession is trying to write one of these games.  And that all started when I was a freshman in college.  My friend and later roommate Kirk Sluder started a game called Nuke ‘Em on the VAX computers.  It was done entirely by email, and basically, you emailed in your changes, and then Kirk tabulated all of the stuff and emailed back updates.

From what I remember, the rules were something like this:

  1. A player started with X factories (I think it was 4 or 5)
  2. A factory could create a nuke, an ABM, or 25% of a new factory per turn.
  3. In a given turn, you could state your new production and/or decide to nuke another player.  You could also email in some pithy commentary about how you were going to kick everyone’s asses and it would go into the email that was sent out with the turn’s results.
  4. When you nuked someone, each ABM would cancel out one nuke.  I don’t remember if it took just one nuke or four to knock out a factory.  When all of the factories were gone, you were done.  (And now that I think about it, Kirk may have called them cities and not factories.)
  5. There may have been some rules about collusion or inter-country trading, but I don’t remember.

So that was the basic deal.  It was a very low-tech game, and I think we only played one of two rounds before the whole thing got sidetracked by the usual college concerns of getting laid, getting drunk, and occasionally going to classes.  There was also a much more popular and immersive game called Monster that a few people brought over to the VAX – it was sort of a precursor to what later became MUDs, and wasted a lot more time, but offered more immediate gratification.

(I don’t entirely remember how the Nuke ‘Em game went, except everyone else got immediately involved in these skirmishes, while I just stayed isolationist and stockpiled a shit-ton of ABMs.)

Anyway, I think Kirk piddled around for a bit trying to write a more mechanized version of the game in VAX BASIC.  And the next year, when I started learning Pascal, that was my first major goal: to write this entirely automated version of the game, where you logged in and made your changes in some form, and then maybe saw a map or some tally of what was going down.  This was long before the days of the web, like in the fall of 1990, so everything was VAX-based.  This was the first time I really started screwing with the Starlet libraries on the VAX, which were these awesome runtime libraries for doing all kinds of crazy stuff, like drawing menus on the screen.  There were header files (or whatever the hell Pascal used) for every VAX language, so you could use them in Fortran or COBOL or whatever you used.  So I clunked away on that for a long time, but didn’t get anywhere, and gave it up.

I think there have been at least four or five times I have tried to reinvent this game.  I have a bunch of C source code I was apparently working on in the summer of 99, along with some decent notes on the thing.  It was web-based, and had a bunch of CGI pages that were C binaries, which is about the least portable way of doing things. I should probably try to recompile this crap and see if it works, but ten-year-old source code written for linux has a way of not working because every other week, someone decides on making their own free curses library the standard or whatever the hell.  Looking at the code I have, it uses ndbm for its database, and a slightly more complicated system of different terrains on a map, and I wasted a lot of time writing my own libraries to do crap like parse URLs for arguments.  But I didn’t get much working, and gave it up quick.  (Given the timing of this, it was probably an attempt at making something I could use as a sample for finding a job, although at the time, Silicon Alley was giving HTML production jobs to anyone with a pulse.  Except me, of course.)

I also have notes from a 2004 attempt at the same thing, but no source code.  And in 1998, I did an end-run on the whole thing and spent a few all-nighters trying to write a framework for simulator/strategy type games where someone could use that and write a game like Nuke ‘Em in some convoluted scripting language.  The C++ code I have for this is absolutely horrid and does nothing.

And in 2008, when I was trying to learn Ruby on Rails, I started this new version of the game, although it was much more involved.  It was map-based, and the map had little squares with technology levels. Just for kicks, I’ll paste the rules at the end of this post.

Anyway, there is a part of me that really wants to fire up eclipse and start working on this again.  Or maybe learn how to use some iOS framework like GameSalad to make a game that way.  And if I had infinite time and patience, I would.  But given that the rails stuff I wrote in 2008 fantastically crashes when I try to run it because there have been like 19 major revisions to rails since then, it probably won’t happen soon.

Anyway, here’s my rules from 2008.  I think I got the game to the point where I needed to figure out how to implement the AI for robot players before I gave up.


Here’s the rundown on how the game works, but note: everything is
under construction. Everything can be changed. In fact, until things
solidify, entire games could drop off the face of the earth. I will do
everything I can to avoid that, but there’s no guarantee on the
stability of the data at this point.

Also, anything marked with TODO is either something that isn’t implemented,
or something where a decision hasn’t been made yet on how it will work.

Four basic entities are used in the game: Worlds, Cells, Nations, and Forces, as described below.


If Nuke ‘Em was a board game, a World would be the board. Each World contains basic meta-data defining
its structure and behavior, as given by its creator. There can be multiple worlds run by multiple admins, each
with a few or a lot of players. As far as those attributes, here’s a quick list:


The name of the world. It can be simple, stupid, or silly, depending on the admin.
This doesn’t affect play, except maybe that a really hardcore name will scare away the n00bs. And maybe worlds
with really cool names will attract more players.

Cells Across and Cells High

This defines how big the world will be. Worlds are rectangular
grids of squares (sorry, no cool hex graphs like those old-school Avalon Hill games), with each square being a
Cell, which we’ll get to in a second. Obviously, a 1000 x 1000 map is going to be able to host a bigger
game than a 100 x 100, but if you put four players in a 1000-square map, it could take them forever to find each

(There’s also an upward limit on the number of players in a world that can vary. Since players are randomly granted
a 3×3 plot of land, and those grants can’t overlap, you’ll eventually get to a point where a new player can’t find
a clear group of nine cells to start playing. And your mileage may vary when new players are added mid-game, since
current players may have carved up the map by then. TODO: two features that could be added to control this would be
a configurable hard cap on players, and a boolean that can be toggled to prohibit mid-game player addition.)

Turn Length

Nuke ‘Em is turn-based, meaning the world is updated and advanced each period, although players are welcome to mess
around with and adjust their entities as much as they want, to a limit. The length of a turn is measured in minutes.
You could set the turn length to 1440 and have things change each day over the course of months, or set it to 5
for a fairly interactive game that might be over in an evening.

The following are affected by turn updates:

  • Nations’ production is updated on a per-turn basis. Add up the civ of every cell you control and multiply by ten, and that
    revenue is generated each turn. High civ cells mean higher tech factories; more cells mean colony plantations bringing in cash.
  • TODO: Any Forces created by a Nation aren’t available until the next turn. (TODO: maybe this should vary – Rome wasn’t built in a day.)
  • Forces can only move a given distance in a turn.

Anything else happens in realtime, and happens simultaneously between all players.

TODO: At the end of each turn, each player gets an email with a verbose summary of their activities that turn,
and a public summary of everyone’s turn. Private events won’t be in that update (details of troop buildups, etc.)
but very big things will be (two countries nuke each other, Britney Spears shaves her head, etc.) There will also
be a facility for players to enter their own diatribes into the public news, so you can go Hugo Chavez on someone’s, ass.
And the public news is also viewable on the home page.


You’d think the use of nuclear weapons in a game called Nuke ‘Em would be a given, but you can set this to false
and make your world wars Greenpeace-compliant. This is sort of like the designated hitter rule in baseball, and people
will argue a more intimate game on a level playing field, versus giving people instant gratification with the
big guns. Either way, the feature can be toggled on and off by an admin.

World Defaults

A world defaults with a 100 across by 25 high map, a one-minute turn, and is nuclear-capable. Note that a one
minute turn is really damn short.


A Cell is a single unit of land. As for the basic properties, it has an x/y location (0,0 being the upper
left corner), and an ID of the world to which it belongs. It also has the following properties.


When a player moves their forces on an otherwise empty cell, they plant their flag into the ground and its theirs.
If you’re the second person crossing into that cell, if it has no military presence, it is theirs. If it does
have occupying forces, skip forward to the combat section to see how that works out. (TODO: There is no facility
for allied troops to let each other move through their respective lands.) (TODO: there is an issue with being
able to “look” at neighboring cells, and/or cells you once owned.)


Each cell has a type of terrain which, with one exception, is assigned when a World is created. Cell terrain can be
“plains”, “water”, “city”, “desert”, “mountain”, and “nuked”. To a limited extent, terrain dictates how Forces can move.
TODO: Currently terrain is completely random. In the future,
maybe the ability to either load in new maps or use a map constructor would be nice.


A cell’s civ is the level of civilization in that terrain. By default, that equals 1, which is probably the level
of an agrarian community. At the end of each turn, a cell produces resources based on its civ level. (TODO: what
is the rate?) A higher civ also means the forces built in that cell have a higher civ. (TODO: what happens to
civ when a cell changes hands?) (TODO: A nuked cell has a civ of 0.)

If you’re an occupant, you can spend resources to improve a cell’s civ, at the rate of one civ point per $10,000 spent.


A nation basically is a player, and consists of their controlled cells and their forces. It also contains the
gnarly name you chose as the moniker for your country, your email address (for those end-of-turn updates), the
world in which you belong, and any other personal preferences that might come up in the future. There’s one other
all-important property:


Resources are basically money. It’s hard for me to call them anything other than dollars, but you’ll see the $$$ sign
when this is discussed. Not only could it have had some hokey fake monetary unit (gold pieces, Euros, whatever), but
it also refers to the general production ability of your nation, and not just piles of metal or paper. Anyway, cells
make money every turn. And you can spend money to build forces or improve cells. (TODO: a feature to send money
to another nation to pay them off so they won’t nuke you. Or a way to steal money from a nation you destroyed.)


Forces refer to any type of army, navy, or other military unit. Actually, there are exactly three branches
to choose from: “army”, “navy”, or “air force”. (Sorry Marines, I had to stick to the basics.)

TODO: There are also two additional forces that can be created. When a cell is civ 50 or higher, it can create ABM forces.
And there are ICBM forces, which can be created by nuclear superpowers. (More on that in a bit.)


TODO: Not done yet. These are the basics.

When you move forces to a cell that contains another nation’s forces, a battle is automatically started. The basic version of this: your
forces and their forces cancel out. For example, you have an army of 100 with a civ of 10, and you march into a cell containing an army of 50 with a civ level of 10. You now occupy the cell, and your army now contains 50.

This is calculated by lining up each side’s forces, from lowest civ to highest, and when civ is the same, by smallest
to biggest.

Nuclear War

TODO: Nukes have not been implemented at all yet, so everything here is speculation.

My thought on how a nation can go nuclear is this: once a cell reaches a certain civ level, it can now create forces
that have nuclear capabilities. And/or you might have to pay a one-time fee for the first time you ever go nuclear.
So for example, if civ level 100 is nuke, you pay $1,000,000 in improvements on one cell, then you get a “go nuke” link
appears. When you pony up an additional $1,000,000 payment (i.e. the research costs of a nuclear program) that
one cell and any others with a civ level of 100 can now create nuke-capable forces.

This is the easy version of the rules: your nuke-capable cells can create ICBM forces. To make this easier, an ICBM force
has exactly one troop in it, and costs $100,000 to build. It also has infinite range, so it can hit any cell from
anywhere on the map. When you “launch”, you choose a destination cell and press the button. You’ll get a report
that will tell you if the cell you hit was occupied or empty. (And if it was empty, tough shit – you don’t get a refund.)

There is one defense to the ICBM, and that’s the ABM. If a cell is civ 50 or higher, you can build one. (You
don’t need to be nuclear-capable, these are conventional explosives.) It costs
$50,000 and is a similar one-troop setup like an ICBM. You can’t move an ABM; it just sits there until something
bad happens. But when a missile attacks a cell with an ABM in it, one ABM takes out one ICBM. If you build
50 ABMs in one cell, it will take 51 nuke strikes to take it out. TODO: how these fare when a cell is conventionally

If a cell is nuked, everything in it and in the 9×9 surrounding it is instantly killed, even ICBMs and ABMs. Not only that, but for the
rest of the game, the center cell is completely uninhabitable and impassable by anything (except airplanes?)

TODO: I am thinking of making a rule that when a cell falls to an enemy, they take possession of the ICBMs
and ABMs in a cell. They can’t build more, but they can use the ones there.


Wirth nightmare

I don’t remember learning BASIC – I think the start of my programming career just happened.  I mean, they’d herd us off in small groups to the grade school’s two Apple II’s and one of us would be the typist, and we’d enter 10 PRINT “HELLO” and someone would always type 10 PRINT HELLO and wonder why it would return 0.  And we’d eventually learn GOTO and a little math and maybe an INPUT or GOSUB, and after we finished a chapter per week, we got to play some crappy text-based game that made you run a lemonade stand and allegedly teach you some math.  And then I got my own computer, and got more time on those Apple computers, and pretty soon I knew most of the language, but only from a brute force perspective.  I was only interested in writing my own Zork, and had no idea about run-time complexity or how to sort something efficiently, or any of the stuff you were supposed to learn to really program.

And then I learned Pascal.  I think I may have dabbled in it a bit beforehand, but it all came out of a C201 class in my sophomore year, at IUSB, and we had to do all of the usual stuff, like fahrenheit to celsius or julian to gregorian converters.  The one pisser about this class was that IUSB had one shared computer, a Prime 9955, a mainframe the size of a dishwasher that had the computing power of a middle-of-the-road 386 at the time.  But the whole school was wired into it: payroll, registration, gradebooks, and this huge rube goldberg set of programs resided there, and did for years until they finally boat-anchored the thing and managed to get to some unix or NT system in place.  The teacher handed out slips of paper on the first day of class with logins for the Prime, and we all got some cryptic username, like NS837489, and a certain amount of funny money cash balance, because any time you logged out of the system, it told you how much money you “spent”.

This was insane to me, after a year at IU.  In Bloomington, they just started permanent student accounts, in which you paid a technology fee every semester, but in return you got accounts on any of the university machines operated by UCS.  That meant you could spend all day plunking around on a VAX, learning how to program or VAXPhoning strangers or just reading dirty chain mails.  But from a hacker ethics perspective, it meant you could stay up all night trying to hack the VAX C compiler, or learning obscure details about ULTRIX, or writing elisp crap for emacs.  You didn’t get a balance due every time you used a clock cycle, and you didn’t have to worry about your entire world vanishing at the end of the semester when they shuttered your temporary account.

Logins to the Prime only worked well on these TeleVideo terminals straight out of a 1970s bank, and logging in on a PC using Procomm tended to freak things out; you’d hit a cursor key and a stream of garbage would come across your screen, like someone picked up the other phone when you were on a modem.  Also, they used this thing called Sheffield Pascal, which wasn’t optimal, but was nowhere near as bad as the not-visual text editor you had to slog away with, which was roughly like using vi without an escape key.  After suffering through the first assignment, I asked the teacher if I could do my projects on a different system, since we only handed in a printout of our program listing, and he said fine.  I’d log into the VAX down in Bloomington, where I still had my accounts, and do my assignments there.  Okay, the TPU editor wasn’t that much more thrilling compared to working in Eclipse or something, and VAX Pascal had its own issues, but I got through the assignments with no problems.

Here’s the thing that astounds me: I managed to go from not knowing the difference between a function and a procedure to pretty much knowing the full nine yards of how to get around Pascal in a pretty short time.  I mean, a semester is only a few months, and by mid-fall, I was screwing around with my own stuff in Pascal, trying to write a game and messing with the starlet VAX libraries, which let you do cool stuff like ANSI graphics animations and .  It’s so surreal to think this, because now it takes me a month to find my checkbook, and back then I learned this language in not much more than that, and this was when I also took a calculus class and a philosophy class, and Spanish, and worked part-time, and commuted every day, and everything else.

But I knew Pascal wasn’t the be-all, end-all of languages.  Real men used C; I knew that already, and I knew I’d have to learn C to do really cool shit.  And I messed with it, I bought a copy of K&R, and I looked at it, but I didn’t commit.  For whatever reason, I took to Pascal faster, and I used it for whatever little stuff I needed to do.  I started writing crap for Sowder’s utility program, and Pascal was my go-to language at the point.  But I knew I had to learn C.  Unfortunately, they weren’t teaching it at IUSB.  When I took C202, the point where you usually learn C, they got this wise idea to teach us all about object-oriented programming in Modula-2, which was basically a rewarmed version of Pascal that glued enough crap on the side to make it look functionally as useful as C, but with none of the allure.

One of the good things was that the Prime did not have a Modula-2 compiler.  The CS department just got a couple of HPUX servers and a couple of X Workstations, and we all got accounts to shell into the unix machines and whittle away at our code there.  But the workstations were locked away in a different room, only available to people in some advanced class, and they all sat idle all of the time.  And the administrator of the CS machines was this shitheel that would routinely snoop around your home directory and read your email and sometimes delete files if he thought you shouldn’t have them.  He was some right-wing nutjob that got off on security and authority and probably later got a job in the Bush administration administering illegal wiretaps.  Granted, I was being a huge pain in the ass, spending all of my free time downloading games off of usenet and trying to get them to compile, but it always ticked me off that they had these giant-screened workstations that my tuition paid for, and I even worked there, and I had to spend my time plunking away on a Leading Edge Model D, which was like the Yugo of personal computers.

I don’t know when I had time to learn C, but I know that the Modula-2 class was in the spring of 1991, and by the fall of 1991, I was back in Bloomington, taking a 400-level class in C++ and Objective C, and don’t remember a period of time where I seemed entirely overwhelmed by the premise of learning C, at least like I was when I needed to take C311 and had never taken C201 in Scheme, and the thought of taking a class taught by the guy who literally wrote the book on Scheme with almost no knowledge of how it worked gave me panic attacks.  But Unix and C went together like alcohol and bravado, and I couldn’t imagine trying to write any stuff during the infancy of Linux with Pascal.

My last big hurrah for Pascal was this xinfo database I wrote for Sowder’s utils, which was basically a cheap relational database used to keep track of user address information.  Somewhere, I have a piece of lime and cream colored tractor-feed paper with a bunch of handwritten Pascal code, probably from the summer of 1991, from when I was working on that project.  I didn’t have a home computer, and then when a girlfriend loaned me her Mac so we could keep in touch without insane phone bills, I still didn’t have reliable access to the VAX machines because IUSB’s dialups were crap.  So I did a lot of coding on paper, by hand.  I remember a whole Christmas break in 90/91, stuck in Toledo with a different girlfriend at her parents’ place, bored out of my mind, trying to write a chess game on paper, then trying to write a tic-tac-toe game in the primitive BASIC included on my Casio-9000 graphic calculator, which I think had less RAM than a twitter message.  And that’s why I probably learned this stuff so fast – I spent every waking moment thinking of programming, and how I’d build a computer, and how I’d save up money to buy the cheapest Amiga possible, and how I’d get some shareware C compiler and write a ripoff Star Wars video game.

Now, all of this seems alien to me.  I can barely remember any Pascal, and if I had to learn a new language now, I’d hop onto Amazon, buy a couple of the hundreds of books published  on the topic, and read a bunch of tutorials or watch screencasts online.  But it would be nowhere near as fun, and the entire sport of it would be gone, which is probably why I don’t spent much spare time programming anymore.