Harry R. Schwartz

I’m often impractically enthusiastic about adopting new technology. When presented with a new programming problem to solve, my first instinct has traditionally been to cram as much novelty into the exercise as possible.

I might say something like, “Time to write my first compiler! What a great opportunity to learn Idris!” This will inaugurate a period of profound frustration, followed by neither a working compiler nor proficiency in Idris.

I don’t think this “change everything at the same time” strategy has ever worked for me.

The lesson here is that to avoid changing more than one big thing at a time. The big things I’m thinking of here are languages and problem domains, but I kinda suspect that this applies to directed learning in general. You’re unlikely to get useful feedback if you’re changing more than one big variable at the same time.

That’s why I wrote Blueprint in Ruby. Ruby’s not a good choice if you want to implement a performant interpreter, but I’m quite proficient with it. If the alternative is struggling to implement an Scheme interpreter while relearning C—accomplishing neither—then it’s a pretty good solution.

It was the biggest step I could successfully take to improve myself, and the next time I want to implement an interpreter I’ll feel capable of trying it in a new language.

I want to emphasize that this doesn’t necessarily reflect poorly on either the languages or the problems. An Erlang implementation of the Raft protocol might make a lot of sense, but if you don’t have experience in either Erlang or distributed consensus protocols then you’re probably setting yourself up for failure. First master one, then try them together.