This post is about a trick my dad taught me. He’s not a programmer, but he is the best teacher of writing that I have ever known. The trick is this: He will make strange requirements part of a creative writing assignment. Only use two characters, or make everything take place in the same train station. Or write a villanelle.
At first, these constraints just seem annoying. Why can’t I just write a story? Why are you stifling my creativity? Don’t confine me, bro! But there is a huge benefit to artificial constraints: they make you do something you wouldn’t have without them. They cause you to be creative.
No one naturally speaks in villanelles. That means, by definition, if you write a villanelle, you will say something you would not otherwise have said. It works for music too. If you practice an instrument and “just jam,” there’s a good chance that you’ll keep playing the same jam without learning much. But if you have the discipline to practice within an artificial constraint, like a song someone else wrote, or a set of scales, you will learn quickly. Learning and creativity are natural consequences of forcing yourself to make something within an artificial set of constraints, rather than just making the same thing you made before.
What about programming? Artificial constraints can help you grow as a programmer as well. Try writing a program that has no classes that maintain fields at all, only stateless method calls. Try writing a program without your favorite library. Try out a new language.
An important side note here: I’m talking about side projects. At work, do your job. If you go to your boss and say, “we’re rewriting the data access layer in Haskell because artificial constraints are good for creativity!” then she might be unhappy. If, on the other hand, you’re writing some code for fun, you will learn faster if you impose some artificial constraints. Artificial constraints can guarantee that you learn new things, instead of just rehashing things you already know.
This spring, I’m following along with Eric Lippert as he implements the virtual machine layer for playing Zork. He will be using OCaml. I will be using C#, partly because I don’t want to be able to copy and paste from Mr. Lippert’s masterful code, and partly because if I use a a language I don’t know at all to do something completely new, the learning curve might be a little too efficient.
You can follow along at https://github.com/willmurphyscode/CSharpZorkMachine.
In my version, I will be trying very hard to maintain the artificial constraint of having no mutability in the app; that is, of having objects where every method of modifying the object returns a changed copy, rather than editing the object’s internal state. I won’t be able to follow this constraint quite as carefully as the OCaml code does, since C# is not a primarily functional language, but I hope to come close.
The z-machine, as the Zork interpreter is called, has lots of bit twiddling and weird string compression strategies that result from the limited memory of the machines it was originally written for. This is a further artificial constraint, which will force me to learn parts of C# that I will never have to use at my day job. (I look forward to testing out the Immutable Array, for example. I don’t need those very often to write code that updates people’s phone numbers from website forms.)
Also, this is a more technical and less beginner-friendly topic than I usually write about on the blog, so I will be interspersing posts about the z-machine with posts on my more usual topics.
Till next week, happy learning!