Introduction

Over the years, I’ve collected a handful of videos that I deeply enjoy and that have had a significant impact on me as a developer. These are videos that I love introducing people to and I’m happy to have the chance to share them with you here. I find them all inspirational in their own ways and they serve as a continuous reminder for me to keep an open mind and to take creative approaches to problems.

A Tour of the Acme Editor

Russ Cox is in the company of men like Ken Thompson and Rob Pike as one of the Plan 9 developers at Bell Labs who were later gobbled up by Google to eventually become part of the Golang core team. He’s also notably responsible for RE2 and the dearly departed Google Code Search. There are very few, if any, people out there who are more qualified to talk about Acme, a fact that becomes abundantly clear as he casually mentions:

When I had to switch to using Unix workstations again in the early 2000s, I missed Acme so much that I ported all the Plan 9 user programs to get it back.

Russ’ passion for the subject matter is inspiring and his meticulous planning and attention to detail makes the video an absolute pleasure to watch. I guess I should backtrack a bit and explain what Acme is. Better yet, I’ll let Russ describe it.

An IDE tries to do everything, Acme takes a different approach. It does provide the editor part but it assumes you’ve already got all the other tools and just want to use them effectively. It lets Unix or Plan 9 provide the development environment and only worries about integration. That is, it does not try to reinvent everything. It integrates the tools that are already on your system and helps you use them more effectively. It fits into the surrounding system (in this case: Unix).

That doesn’t sound so different from Vim, does it? Well… it is. Acme is almost as much a window manager as a text editor and it exposes everything through the filesystem, making it extensible in a way that’s very unique. It’s really a quite different paradigm than those of most other text editors and you kind of need to just see it in action to understand.

Russ’ video inspired me to use Acme for a few months and, although I eventually switched back to Vim, I don’t regret my time with it at all. There are parts of Acme that I still miss to this day and I don’t think that I’ll ever be able to switch away from a window manager based on it (e.g. wmii and i3). I highly recommend that any developer who leans towards minimalism give Acme a try at some point.

Conway’s Game Of Life in APL

Dijkstra famously said:

APL is a mistake, carried through to perfection.

The criticism of the lack of control structures is clear, but it is also true that what APL does well it does very well. It is an inarguably concise and elegant language for dealing with array manipulations as this video makes quite clear. In it, the speaker develops an implementation of Conway’s Game of Life that is essentially a single line.

life←{                                  ⍝ John Conway's "Game of Life".
    ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵  ⍝ Expression for next generation.
}

The importance of exposure to functional programming languages is widely stated, but there are other paradigms out there that get less attention. I really like this video because it reminds me of that and it motivates me to keep an eye out for different ways to approach problems. The implementation from the video could easily be done in numpy and it would be far more concise and efficient than a more naive solution.

The Mother of All Demos

The name “Mother of All Demos” is a relatively recent invention but it really does fit. It’s hard to overstate the importance or influence that Douglas Engelbart’s 1968 computer demonstration has had on modern computing. He introduced concepts like the mouse, graphics, windowing, screen sharing, video conferencing, word processing, bug tracking, version control, and hyperlinks to an audience which would have been primarily familiar with computing via punch cards. Concepts developed for Engelbart’s oN-Line System (NLS) heavily influenced Xerox PARC which, in turn, shaped both the Macintosh and Windows systems.

The demo is almost unbelievably prescient but what I find just as fascinating is how many ideas didn’t catch on yet still seem fresh in a modern context. For example, he introduces the computer mouse in the presentation

And in a second we’ll see the screen that he’s working and the way the tracking spot moves in conjunction with movements of that mouse. I don’t know why we call it a mouse, sometimes I apologize. It started that way and we never did change it.

but also presents a chorded keyboard that seems just as essential to the interaction with the system

I’m so used to working with one hand and this that I can hardly remember what to do on the keyboard.

One device has gone on to become ubiquitous while the other is now an extremely niche tool for hobbyists. Could an audience member at the time have possibly predicted that?

The reason that the chorded keyboard was so useful on the NLS was because it could be used in conjunction with the mouse to specify actions and targets. This was made possible by an integrated graphical and textual environment that is in many ways more advanced than the emulated teletypes that we’re stuck with today (graphical environments exist of course, but it’s telling how much is still done in terminals with minimal mouse support). These components actually remind me a lot of what Bell Labs was trying to accomplish with Plan 9 and I believe that there’s still progress to be made in this direction.

8 Bit & ‘8 Bitish’ Graphics

Mark Ferrari is an artist who worked on many of the iconic LucasArts games from the 80s and early 90s. I grew up playing several of these games, but I was too young at the time to think much about the technological challenges that the developers faced or the creative solutions that they came up with in order to push the boundaries of the hardware that they were working with. Mark is clearly a master of the 8-bit artform and it’s really amazing to see the works that he’s created and to hear him explain how they were designed.

The thing that makes his artwork so compelling is how it was borne out of technological constraints. As Mark puts it:

The most creative work I ever did was done when I just had those 16 horrible colors to do it in.

That line really stood out for me because it’s so relatable. A lot of the software that I’m most proud of was written in the face of severe constraints. I doubt that I’m alone in thinking that.

Even his discussion of art tooling seems to apply well to software development:

I think this is one of the challenges that has been facing our industry for some time is that the resources are so many now. They are so fast, and they replace themselves and render themselves obsolete so quickly, that nobody has the time to do anything but just dabble for a moment in the current resource du jour before it’s gone and they are busy scrambling to learn just the merest proficiency of the next one.

Would you have thought twice about it if I told you that that was somebody talking about JavaScript?

If you don’t have time to watch the video, I highly recommend at least checking out some demos of his work. The way that canvas cycling and palette shifting are employed to create such rich animations is fascinating.