InfoQ interview at BuildStuff 14

The video and interactive transcript is also available on InfoQ’s page here.

Slides for my Craft-Conf meetup talk on DSLs and F#

Don’t learn a syntax, learn to change the way you think

“A language that doesn’t affect the way you think about programming, is not worth knowing.”

– Alan Perlis

In my last post, I outlined the techniques to learning that I picked up from Josh Kaufman’s TEDx talk. I briefly mentioned that one should learn a new paradigm rather than a language with a slightly different syntax (e.g. C# <=> Java, ActionScript <=> Haxe) but didn’t stress nearly enough the importance of doing so.

As the mathematician Richard Hamming once said, that it’s possible for there to be thoughts that we cannot have:

“Just as there are odours that dogs can smell and we cannot, as well as sounds that dogs can hear and we cannot, so too there are wavelengths of light we cannot see and flavours we cannot taste. Why then, given our brains wired the way they are, does the remark “Perhaps there are thoughts we cannot think,” surprise you? Evolution, so far, may possibly have blocked us from being able to think in some directions; there could be unthinkable thoughts.”

– Richard Hamming

but what does this have to do with programming languages, or any languages for that matter?

What we cannot express, we cannot think

BBC went to a remote, unconnected tribe called the Himba, whose colour vocabulary is very different from us in that they only have 5 words for colour.


What they found was intriguing.

The Himba is able to easily identify the square with a different shade of green in this picture:


because they have different words for the two shades of green. For us, this feat is difficult because to us, they’re all green.

On the other hand, because we have two words for blue and green, it is easy for us to spot the blue square from the rest:


For the Himba, who has only one word that describes both blue and green, they struggle to identify the square with a different colour.

The implication is profound, that not only do languages shape our thinking, they might prohibit it.

“The limits of my language mean the limits of my world.”

– Ludwig Wittgenstein

What if the same is true for programming languages?

“Programming languages have a devious influence: they shape our thinking habits.”

– Dijkstra

What if our creative powers are limited by the ideas that can be expressed by the programming language we use?

What if some solutions are out of our reach because they cannot be clearly expressed in those languages? How would we ever discover these unknown unknowns?

Without being aware of the outside possibilities, would we ever become aware of our unconscious incompetence?

I don’t know of any research into the impact programming paradigms have on creativity. From personal experience, my most creative solutions have come from my ventures into non-mainstream programming and database paradigms. These ventures have opened doors in my mind and allowed me to see solutions I couldn’t before.

By contrast, my other learning efforts such as Dart and Haxe has taught me a slightly different syntax for expressing the same ideas that I’m already familiar with. Whilst they can prove to be useful tools for specific tasks, they failed to have the same mind-expanding effect that is far more valuable to my long term career.

On Diversity

We can diversify our ways of thinking and approaches to problem solving by learning new programming paradigms, but that’s not the only way. In fact, some of the most notable people in the field of computer science has come from other disciplines.

For example, Alan Kay was a biologist, and it was the study of biology that inspired him to coin the term objects.

“I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages.”

– Alan Kay

(the fact that we have come to teach and think about OOP in a very different sense to what Alan Kay envisioned is another matter..)

Similarly, Joe Armstrong started out as a physicist.

And Adam Tornhill, a speaker whose work I thoroughly enjoy, has learnt much about programming from his studies in psychology.


We also need diversity in our communities.

There’s a famous Chinese proverb that goes like this,

“three humble shoemakers brainstorming make a great statesman.”

However, this only holds true if each of the shoemakers is able to offer a different perspective and ideas.


In reality, given that the shoemakers have the same profession and gender they probably have a much greater overlap in mindscape.


The result? The shoemakers’ numerical advantage amounts to little when it comes to finding creative solutions. Which is why, in a creative industry like ours,  we need to guard against monoculture.


To summarise, learning a new language within the same paradigm gives you implementation options and trade-offs for the set of approaches that is best afforded by the paradigm.

Learning a new paradigm gives you entire new approaches that you didn’t have access to before, and has a far longer-lasting benefit. Which is why, given the choice, you should learn a new paradigm rather than a new language.





Learn to Learn

Being a responsible speaker, I have started preparing my talk – A tour of the language landscape – for NDC Oslo months ahead of time! When I first came up with the idea for this talk, I asked on Twitter if anyone else thought it was a good idea. Phil made a great point about including some information on how I go about learning a new language.


I came across this TEDx talk by Josh Kaufman a while back and found it useful in helping me formulate a learning strategy that works for me.

Truth about the 10,000 hours rule

In the talk, Josh debunked the often misquoted 10,000 hours rule. When the study was first published, the finding was that it takes 10,000 hours of deliberate practice to reach the top of an ultra-competitive field. But through a collective Chinese whisper the message was warped into ‘it takes 10,000 hours of deliberate practice to be good at something’.

Instead, Josh found that researches suggest 20 hours is all it takes for you to be reasonably good at something so long you make those hours count.


This is important, because for us busy programmers – who, by the way, have a tendency to work long hours – the time to learn new skills is both limited and necessary given how fast our industry moves.

4 steps to learn

Josh proposed these 4 steps to learning anything.


Deconstruct the skill

Most things we consider as skills are actually bundles of skills. The more we are able to break them up into smaller skills the better we can decide which of them actually helps us achieve what we want out of our learning. We can then prioritise the skills that are most useful to us and improve our ability in the least time possible.

For learning a programming language, you can deconstruct most languages into smaller chunks:

  • variable assignment
  • common data types
  • control flows (if-else, loops, recursions, etc.)
  • working with collection types
  • working with strings
  • error handling
  • concurrency

Most introductory books and tutorials follow this structure already.

Learn enough to self-correct

You should first focus on getting to the point where you can self-correct and self-edit as you learn. For learning a programming language, I interpret this point as:

  • know how to compile and run your code
  • able to put simple programs together, and tweak it to start getting a ‘feel’ of it

Again, most introductory books and tutorials follow this pattern already and have you build a Hello World example very early on.

Remove practice barriers

Remove distractions – TV, internet, twitter, etc. – so that you can focus on learning. This can be hard when distractions are all around us and so readily available!

I once heard a story about John Carmack that, before a new project, he’d check in to a hotel with a bunch of good books and literally cut himself off from the outside world for days so he can soak up the ideas and inspirations before starting any work on the project.

I’m not saying that you should do the same, obviously different approaches work for different people. Personally I’m most effective between the hours of 10PM and 2AM because my wife goes to bed early and I’m able to just zone out.

I’m not a heavy Twitter user, or any other social network for that matter, so they’re not a problem for me.

On the other hand, comic-based TV shows is my poison – The Flash, Gotham, Arrow, Agents of SHIELD, etc. To limit the amount of disruption these bring, I binge watch them in one night so I can have the rest of the nights that week for more constructive uses.

Practice at least 20 hours

Josh raised a good point that, for most things you learn, there is a frustration barrier – the moment when we become consciously incompetent and realise how little we know and how much more we need to learn.


It’s not a great feeling as no one likes to feel stupid, and this is often the point where we lose our momentum and derail our hard-earned progress.

Which is why it’s important that we pre-commit at least 20 hours of our time, so that if and when we hit this frustration point we have a good reason to push on since we already budgeted 20 hours anyway.

Set your goal

Before you start investing a minimum of 20 hours into learning a new language, it helps if you could decide what you want to get out of the process. Depending on your situation and needs this could be quite different, e.g.

  • are you looking to move to a different language stack and trying to make yourself employable?
  • are you trying to understand the hype around a new language and see what it’s all about?

Personally, most of my learning is aimed at expanding my horizon and allowing me to see beyond the possibilities and options I have at my disposal with the stack that I work with day-to-day.

Other times I might have specific goals of what I want to be able to do in that new language, for instance:

  • I learnt Dart as a replacement to JavaScript for my web development needs
  • I learnt Elm to be better acquainted with functional-reactive programming (FRP) and with the aim of being able to make games using FRP

Prioritise learning a new paradigm

One mistake that I see many people make is to choose to learn a new language over a new paradigm. For example, making the jump from C# to Java is a relative easy one, but at the end of day you have learnt a new syntax without necessarily taught yourself a new way to solve problems.

Learning a new paradigm on the other hand, fundamentally change the way you see programming and allow you to see new ways to solve problems. From personal experience, each time I ventured into a new paradigm – Functional Programming, Aspect-Oriented Programming, Functional Reactive Programming, etc. – has allowed me to see programming in a new light.

If you’re interested in exploring some less travelled roads, check out these three paradigms recommended by John Croisant.

These two books by Bruce Tate are also a great source for exploratory learning:

7-langs-7-weeks  7-more-langs-7-weeks

And finally, I leave you with a great quote from none other than Alan Perlis.

A language that doesn’t affect the way you think about programming, is not worth knowing.

– Alan Perlis

Happy learning!


Interview with Rik Van Bruggen @ QCon London 2015