When I listed what I thought of the Great Works of Software, I also offhandedly listed some great works of art: The David, Beethoven’s 5th, and Pride and Prejudice. One of the reasons I think of them as great is because they are old and still relevant. We haven’t lost interest in them, and also, we haven’t lost them.

Pride and Prejudice can be reproduced exactly as it was when it was first written in all the ways we care about, but we could have lost it early on if Jane Austen hadn’t published it. We still have The David after 500 years, but we could possibly lose it forever. We have already lost the first performance of the 5th, but we could make something similar from the music sheets.

In this way, software is most like music. We have source documents, but the real thing is inextricably tied to hardware. We play recordings or perform music just like we run programs—on hardware. The hardware and the performance is big part of what we think the software is. A book is also delivered on hardware, but we don’t consider the paper or the Kindle or the Audible file part of the work.

All of this makes software losable, because if we lose the ability to run the software, we have lost it.

On my list of the five great works of software, three of them are in active maintenance. We still have the other two (browsers and spreadsheets), but the originals by Tim Berners-Lee and Dan Bricklin are frozen in time and harder to run.

VisiCalc was written for the Apple II in 1979. I don’t know if you can run that version, but Dan Bricklin claims that the executable for the PC will still run on modern Windows under DOS (because Microsoft believes New Versions Should be Substitutable). I am sure you could get a DOS emulator even if a modern one can’t run it any more. We haven’t lost it yet.

There is a version of Berners-Lee’s WorldWideWeb client on GitHub, it was written for a NeXT machine. I don’t know how to run it, but there is at least one NeXT emulator that might be able to, so it’s also possibly not lost yet.

It’s not a “great work”, but I have run My First Real Program on a PET emulator because it was small enough to commit to memory. Almost all programs I have written between then and when I started working professionally are lost because they were tied to floppies that I didn’t keep.

The possibly longest continuously running software, Voyager, is very far away, but not lost yet.

A couple of years ago, I wrote about designing a game that is the opposite of Asteroids. Last week, I found raylib, a C library for making games and decided to try making it (I also renamed it Nebulas).

Here’s what I have so far.

• You are a triangle ship in the center of a starfield, which can help with navigation.
• You can rotate (LEFT and RIGHT) and thrust (UP)
• Space is infinite in all directions. You are always at the center of the screen.
• There are nebulas in space around you moving.
• You can go into them and suck their energy into your ship

Here’s a video of my progress so far:

Next

• The color of the nebula is a clue to what power your ship gets from it. (e.g. Red is thrust)
• The color of the ship is which gas you are currently using.
• I will show tanks for each color so you can see how much you have of each gas.

The game is to survive as long as possible, conserving your gases. As long as you survive, you can explore.

I started playing with raylib to make a game that is the opposite of Asteroids. Just to start, I need to be able to draw a triangle that is rotated by some angle around its center, and that’s simple if you understand transformations. Raylib does include a raymath module to do basic vector math, but not specifically what I needed.

So, again, I’m feeling The Unreasonable Effectiveness of Mathematics in Programming. I’m not sure you can make any reasonable game without some transformations.

I just ran into raylib (because I’ve been reading a ton of HN blogs) and it’s making me dream of Programming With the Joy of a Thirteen Year-Old. All I wanted to do when I was 13 was make games and raylib looks like a fun way to do it.

I read the homepage, played a few games, and then read their source. Here’s what I love

1. You write in “easy” C. I searched for pointers and signs of dynamic memory and found none in the simple games I read. I’m sure it’s there in more complex games, but they aren’t making you use pointers just to get started
2. It runs in the browser. It’s C, so it’s expected that it would be cross-platform, but it can also compile to something that runs in the browser.
3. No external dependency philosophy. Dependencies are just future tech debt.
4. No (or very little) magic. It’s just a library. Games are mostly a loop of reading the controller, updating some state, and rendering that state. That logic is very clear in raylib code.
5. Simple games are simple. I played three classic games and then read their source. They were each one file and followed similar logic.
6. There’s is more to it. Once you progress from the simple stuff, it looks to be full-featured with other things you might want in a game library. But, you don’t need to use any of it at first.

I might play around and see where I can get with Nebulous.

The book Thinking, Fast and Slow [amazon affiliate link] by Daniel Kahneman describes our brain as having two thinking systems, a fast one and a slow one. The fast system is automatic and multitasking, while the slow system is methodical and single-focussed. When you are doing something complex, you are usually concentrating your slow system on the main problem, while the fast system can be doing several related (and even unrelated tasks).

This is the main reason I try to memorize and practice several keyboard shortcuts for the programs I use every day. I am trying to get as much of the mechanics of the code editing into my automatic, fast thinking system.

There is a common belief that mousing is faster than keyboard shortcuts, which probably originated with this AskTog article:

We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

This is probably true for the general case and for when the user is learning a new UI. But, the study, Comparison of Mouse and Keyboard Efficiency, suggests that:

[…] for heavily-used interfaces, keyboard shortcuts can be as efficient as toolbars and have the advantage of providing fast access to all commands.

For me, the key is that shortcuts have to be able to be deployed with no conscious thought.

Programming often requires you to keep several interrelated thoughts in your head until you get the code written and working. For example, even for simple web UI blocks, you have to think of the semantic structure of the tags, the layout, and the style. To write that code, you will have to possibly jump through a few files and parts of those files. So, to keep from adding more cognitive overhead, you want to make the manipulation of the editor as automatic as possible.

This is something I think that can never be accomplished with the mouse, but is possible for a small set of shortcuts. That set should be the most common actions that happen while you are actively programming. The goal is to keep your slow system and short term memory focussed on the programming task at hand.

For me, that is:

1. Cut, Copy, Paste, Undo, Redo
2. In-file navigation with arrows and modifiers (including using Shift for selection)
3. Find and multi-file Find
4. Show the current file in the project navigator
5. Open another file, tab cycling
6. Jump to the definition of the identifier under the cursor
7. Comment (or uncomment) the current selection

I do these commands all of the time. I often need to string a series of these commands together. Doing the equivalent without the commands risks engaging your slow thinking system and breaking you out of flow.