I’ve never formally trained to be a programmer, outside of occasional conference workshops and a week of XSL tutorials. In some ways, that’s terrible, because it’s taken me about thirty years to learn what some friends of mine appear to have learned in four. I’ve written some code that goes way beyond spaghetti, though fortunately the worst of it was probably when I was 15.
On the bright side, when I look past my many mistakes, I can see what I learned from a large number of various different experiences, and the pieces they helped me see. It’s a little easier to tell this story through the parts than it might be through a formal curriculum.
- My parents’ FORTRAN books
- I was reading computer books—dry ones—before I even got to play. I have vague memories about program structure, but mostly I learned that knowledge sticks better if it includes hands-on work, and not just a book.
- Sinclair ZX81
- 1K of memory! The sheer thrill of seeing my creations on screen was amazing. I had just enough logic to get things done, and leave myself puzzled. The Sinclair community seemed focused on making great small things. I learned simple logic in BASIC and that sometimes it takes a hack to get things done.
- Applesoft BASIC
- After Sinclair BASIC, Applesoft seemed vast. Much of what I did was transfer what I’d done on the Sinclair (itself a lesson in platform-shifting). As I settled, I started writing larger and larger programs, eventually forcing myself to restructure everything into subroutines…with global variables, of course.
- 6502 Assembly
- I knew there was more than BASIC. My early adventures with assembly language were mostly about graphics, and didn’t work all that well, but I picked up two key things: recursion and the importance of registers.
- Logo
- I’m not sure which Logo it was, but it was a tiny language and still capable of doing fun things. That in itself was enough of a lesson.
- Typewriter
- My spaghetti code frustrated me with endless debugging. I put the computer away for a couple of years and bought a typewriter. Apart from patience, I learned that my brain felt different when I stopped programming. The “Return” key at the end of every thought disappeared, and I was able to step back a little from formal logic. Knowing that my brain felt different ‘on programming’ has helped me deal better with programmers and non-programmers ever since.
- HyperTalk
- I returned to programming with HyperTalk: an object of derision or worship, depending on who you talk with. For me, it was proof that a friendly object manipulation language can do great things, until you hit the wall where your logic is more important than the provided objects.
- Pascal
- This was a brief excursion, but gave me a path into the inside of the Mac, a view of how these crazy graphical interfaces fit together, and a chance to shift from GOSUB with global variables to much neater method calls.
- HTML and CSS and XML
- Everything I learned about program structure, even in HyperTalk, went out the door. They aren’t programming languages, but they support a common set of structures I use everywhere. It turned out that decorating trees and handling events would be at the heart of my work for decades…
- Perl
- Perl taught me the power and terror of regular expressions. It definitely reinforced my impatience, laziness, and hubris. CGI had its flaws, but it gave me first contact with building a server system that could interact with clients.
- Java
- Java seemed like the right answer to all my object-oriented dreams, and was also the place many of my fellow XML developers had chosen. Somehow, though, text processing in Java taught me that programming against the grain of a language is difficult, and that it makes sense to choose a language based on the tasks I want to perform.
- JavaScript
- At first I mistook JavaScript for HyperTalk with a heavy C accent: an object manipulation language. Over time, though, I’ve realized that JavaScript takes everything I’ve learned from the other languages (except Erlang’s processes!) and puts it in one place.
- Ruby on Rails
- Ruby offers even more flexibility and style options than JavaScript. (See Understanding Computation if you want a sense of how far you can push it!) It was kind of the opposite of Logo, a chance to try everything. Rails taught me about the magic of metaprogramming, but also that trusting magic can be difficult.
- XSLT
- XSLT was my “this isn’t really a programming language” experience. I bounced off of it. When I went back to it, though, it taught me to relax, and let the data structures drive the processing through templates. Realizing that XSLT was like a giant pachinko game, with data falling through filters, transformed the way I look at programming.
- Erlang
- Erlang felt like coming home. All the pieces I’d learned from these various other experiences came together. Recursion and registers met the event-based approaches I’d been using in JavaScript and XSLT, and the pachinko data flows move beautifully through the functions in what remains a small language.
- Elixir
- Elixir, my latest adventure, feels like it’s combined all of these lessons. All the power, processes, and flow of Erlang are there, but there’s much more robust text handling, metaprogramming through macros, and more that builds on Erlang’s strong base. It feels just a little larger.
Those are the high points of the journey. I keep marveling that my time in 6502 assembler was useful when I came to Erlang. I finally get the “why” of JavaScript: The Good Parts on returning to JavaScript after working in Erlang and Elixir.
It’s been long and slow: may your path be faster. Just remember, though, that whatever environment you encounter will likely teach you something you’ll need later.
As you’ve passed through languages and environments, what pieces surprised and stuck with you?