“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.”
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.
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.
- TEDx – The first 20 hours – how to learn anything | Josh Kaufman
- Lera Boroditsky – Does language shape thought?: Mandarin and English speakers’ conceptions of time
- Lera Boroditsky – How language shapes thought
- Alex Hillman – Why monocultures suck
- Modelling game economy with Neo4j
- Message broker that links all things
- One liner localization
- Genetic algorithms for tuning monster and trap stats
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong