To learn a programming language, you must either
- Write a compiler for language
- Write programs in the language
A handful of canonical first-programs have risen in the past few years. TODO lists and Blog Engines are popular because they’re easy enough to start and difficult enough to cover a non-trivial swath of a language’s ecosystem such as documentation, packages/modules, build systems, package manager, support network, and so forth. They also generally require integration with a database, which at least in most OO languages can lead to understanding at least one major framework and consequently that framework’s abstractions, typically ORM-y, for interacting with a database. This is all good stuff.
We choose first-programs such as these because they feel productive and non-wasteful. At the end, we may have something that we will actually use. Perhaps someone else will use it. We sometimes bridge what we know with what we want to know: “I will rebuild my years-old Java app in Erlang.” Or we are ambitious and think “As my first program, I will write a peer-to-peer multicast semiotic real-time high-frequency-trading low-latency chat server with transactional semantics and fault-tolerant properties.”
All of these are valuable and valid.
When I started learning Go, I started with the Go Tour, “How to Write Go Code”, and the FAQs. I documented my learning. I picked through the language spec and Effective Go and at that point needed to stop reading and start coding. But what to build?
Gemmer is a stupid program. In short, it accepts an artist and song name and uses the lyrics of that song to suggest new names for your Ruby Gems. It’s the most impractical and useless thing I’ve ever written, if one defines practical and useful as “something that myself or others will use in service of a real problem.” You should know that “bacon” is taken, but “harpoon” is currently available.
Here’s the thing: I had a lot of fun writing it (Ice Cube’s “No Vaseline” lyrics still make me laugh), and I covered a fair amount of ground in the Go ecosystem beyond the contents of the Go Tour:
- io (file and http)
- command line flags
- custom Sort types
- unit testing
- xml and json marshaling/unmarshaling
- Resources such as http://golang-examples.tumblr.com/ and https://gobyexample.com
- How to read / use Go’s package documentation
- A somewhat manicured list of projects at http://code.google.com/p/go-wiki/wiki/Projects
- Gowalker and Gosearch
Silly programs are not a waste of time. In fact, I’d argue that they create an environment conducive to early-stage learning because of the liberation that comes with knowing that the only point is to learn. The one significant downside is that we require critique in order to grow, and a program such as this, tossed into the void, will likely not encourage such feedback. That’s OK, though, because these silly getting-started programs are first steps that help build an understanding of the ecosystem which you apply to future, more serious projects.
Fun and joy are essential ingredients for learning. If TODO lists and Blog Engines are your thing, great. If not, I encourage you to dispense with the notion that programs should be useful and important. If you’re writing code, you’re probably learning, and that will be more valuable than the binaries you produce.