Light at the end of the tunnel

Short story: because I’m lazy.

Long story is a bit more nuanced. It involves everything from how many hours there are in a day, how shiny the distractions are and having enough excuses to learn stuff.

The right tool for the job

Possibly the biggest reason why I try out new technologies, get super excited, but then never learn them properly is the Use The Right Tool For The Job mantra I’ve lived by ever since I stopped being a teenager and became bored of religious wars.

At the end of the day, the client doesn’t really care what technology you use, your users don’t care about the technology either. They care about a working product that is maintainable, expandable and gives them a good price/performance ratio.

Now look at my life:

  • Hey, can you make us a complex business-like website on MySQL? – Sure! -> django
  • Hey, we need a glue layer between a bunch of services! – Awesome! -> node.js
  • Hey, I need a script to munge this data into that data. – Hooray! -> python
  • Hey, can you do X with websites for us? – Yep! Finally something algorithmic, I can use Haskell \o/

Oh wait … except I can’t use Haskell.

I’m charging you decent money for this, and I’m not really productive in Haskell yet. I can make some cool things with it, but it takes twice or thrice as long as using tools I’m familiar with. Of course you don’t want to spend that kind of money to fund my pet learning subject.

For no obvious gain of course.

I could just as easily do it in some other language. Except it would be cheaper to create, easier for you to maintain and I’d spend more time on the problem than battling an unknown tool. But it wouldn’t be as cool!

Yeah … oh and what’s that? The best tool for the job happens to be a library that only works in Java? Great.

And the vicious cycle just keeps repeating itself.

Because I never know enough Haskell, Haskell never becomes the right tool for the job. There would have to be a very very good reason that goes beyond “I love Haskell! It is the coolest language since forever!” to make me use Haskell on a paid-for project.


Right, but I could just learn Haskell in my own time couldn’t I? Then I’d know it well enough and suddenly it would be the right tool for the job and everyone would live happily ever after.

Well, no.

I’ve tried that:

  1. Learning me a Haskell
  2. Raining datatypes
  3. A message from your future self
  4. Collatz, Haskell and memoization
  5. This Haskell is wrong, why?
  6. Lychrel numbers

Certainly not a lack of trying to learn Haskell. And I’ve learned a lot, don’t get me wrong. It is most certainly my favourite language for implementing algorithms.

But at the same time, I still haven’t fully figured out monads and doing IO or anything actually too much useful … it just doesn’t come together.

I mean, there’s so many things to learn. So many things to do. There isn’t enough time in the day to work on everything and learn everything that I want and love and find interesting.

As unfortunate as it may be, Solving The Problem mostly comes higher on my list of priorities than Learn This Cool New Way Of Solving The Problem.

Enhanced by Zemanta

You should follow me on twitter, here.

Get 10 of my best articles and talks

Leave your email and over the next few weeks I will send you the best material I've written since 2010.

  • raiph

    I recall this combinations of issues — a tool you don’t know seldom being the “right tool for the job” and advanced tools taking a long time to learn to become a tool you know — from the early stage of my career in programming. I think it’s getting steadily more important because of competition. I recall reading several blog posts expressing this sentiment this year alone.

    I got excited about a wide range of languages in the 80s (smalltalk, lisp, ML, prolog, snobol, icon, beta — you name it I was checking it out). Then had to buckle down and get stuff done on the web in the 90s. What did I use? Perl of course. It didn’t have the reach of the ultra high level languages but it got the job done.
    Fast forward another decade or so. I am now watching the maturation of a language that deliberately addresses this problem (and many others — it’s nothing if not amazingly ambitious). Most people think it’s vaporware or otherwise irrelevant, but I’ve been watching it for 12 years and I can see it’s finally entering the home stretch.
    That language is Perl 6. think Larry Wall (Perl’s author) had the right idea in 2000 and is now close (a year or two) from delivering a new Perl that is radical about cleaning the language up, making it something similar to but more approachable than Perl 5, and radical about bringing advanced programming to the masses, by basing the language and its runtime on key characteristics of ultra high level languages (Haskell is a favorite).
    A good learning envelope for mere mortals (excellent docs, excellent REPL, etc.) doesn’t yet exist, but it’s clear that Perl 6 has tremendous range — it’s still easy (easier) to learn to do easy stuff yet the language smoothly incorporates ultra high level stuff. It may not be appropriate for your needs, or at least not yet, but I urge anyone reading this to visit the #perl6 IRC channel on freenode (eg via, explain what you need or want to see in a language, and hear what those on channel have to say about what Perl 6 has to offer.