Why I Waste Time Learning Obscure Programming Languages
The Functional Programming Cult
As a novice functional programmer and armchair advocate of functional programming amongst my friends, I am occasionally asked why I spend time, the valuable asset that it is, learning obscure languages. It is unlikely that I ever write Clojure in my day job, and if I start a company, I certainly wouldn't choose Haskell. So why, in this void of practicality, have I invested the last year in these languages?
In those conversations, and in this post, I use the concrete examples of Haskell and Clojure (at the risk of isolating functional programming to those two languages in the mind of my listener), but by no means are they the one true way. Many words have already been written about the particular merits of functional languages; I won't reiterate prior discussion on that topic. There are merits and faults to any programming paradigm and more qualified people have already discussed them elsewhere. Instead, I will discuss my own reasons for investigating these languages.
Swimming: A 10,000 Hour Sport
In a former life, I was a competitive swimmer. Myself and my teammates trained ~20 hours a week, 50 weeks a year. Swim meets (i.e., competitions) were held perhaps once a month, and most swimmers would swim 6-8 events over the course of the weekend; accumulating anywhere from 500-1,500 yards or meters (more if they suffered through the mile on Friday evening).
Our day-to-day training, of course, was nothing like the competitions we worked towards. Practices ranged from 5,000 - 10,000 yards on a daily basis, and we spent copious amounts of time on technique and form, drills, and hypoxic sets (breath-control training).
Why, if the end result was a 200 meter sprint, did we expend so much time and effort on seemingly unrelated forms of training? The answer is common to sports, music, and any other activity in which the expert level performance is so drastically different than the novice's: We were stretching ourselves in many different, but interconnected areas that, during a race, all contributed to a quality performance.
The Competitive Programmer
Programming, like swimming, is a 10,000 hour class of activity. The novice is so completely unrecognizable from the expert as to render comparison useless.
Limiting oneself to programming in one or two languages, in the same family, at one level in the stack, is like showing up to practice each day and only swimming the events you plan to compete in. Peak performance is limited by such a narrow approach. The expert athlete strengthens their body with a wide range of interconnected exercises. To become an expert programmer [1], one must stretch his or her mind.
Haskell and Clojure, by being so completely different than the C-family of languages most programmers have been exposed to, are a fertile landscape in which the aspiring developer can stretch their mind. Is every concept learned from these languages going to be applicable in the programming version of a competition (e.g., interview, day job, or startup)? No. But by struggling with the paradigm shifts of these languages, your capacity as a developer will grow. I guarantee it.
This is by no means limited to functional languages. Other pursuits, like understanding memory management in C, diving deep into an assembly language, and exploring declarative programming in Prolog, to name a few, are all similarly beneficial in their own ways.
Many developers want to acquire skills that will make them a better prospective hire. That goal, by itself, is good. But if all pursuits are limited to the practical in order to meet a prospective employer's exact requirements, you surrender the opportunity to stretch your mind further by learning the impractical.
[1] This is speculation on my own observations of other people -- I am not an expert programmer.