What’s Better - a Spanner or a Paintbrush?
15 Nov 2021 - Estimated reading time: 3 mins
AKA my programming language is better than yours
I’ve never heard a plumber and a decorator argue the relative merits of their respective tools. Perhaps that’s because they have clearly different purposes: I don’t fancy painting a door with a spanner, any more than tightening a radiator with a paintbrush. Painting <-> paintbrush; radiator <-> spanner. Different jobs, different tools.
Jack of all trades
Programming languages aren’t like that. Maybe it’s the pesky convenience of Turing completeness, which means the tools of our trade can all do everything - at least theoretically. In programming, a spanner really can be used to paint a door. There are no sharp edges delineating language applicability; instead we have fuzzy boundaries that change over time. Of course, just because you can, doesn’t mean you should.
Let’s take an example.
Say we need some statistical summaries of longevity data. How might we do that? Well, Wikipedia says “R is a programming language … for statistical computing”. That sounds like a good fit; let’s use that1.
So now we have our model, and it’s running nicely on our laptop. Others get to hear about it, and demand grows. We could say “clone the git repo and run it”, but that doesn’t exactly score highly on the usability front. An app would be more convenient.
How do we do that? Well, R has a nice UI framework called Shiny for building that sort of thing. Sorted. Users love it, and want to extend it: that one dashboard now needs to become a multi-page web app. What do you do? You could try to do it with Shiny, but now you’re really pushing into the grey edges of suitability. Full on, multi-page web apps aren’t Shiny’s thing. Something like Angular might be more appropriate. And, actually, we should back up a little. When you built the Shiny app, how did the users access it? How did you test it? Deploy it?
That’s perhaps a little contrived as an example, but it illustrates the point. Other examples abound; data ingestion and validation is a good one. What to use for that? SQL? C#? R? Something else?
What’s missing? Oh, yeah, people
If you’re a modeller or data scientist reading the example above, you probably started out comfortable. And then got a bit uneasy when it got to Angular and deployment. If you’re a developer, you’re likely the exact opposite.
The example focused on language choice. We do it all the time: wrestling about which technology is best, with strong advocates vociferously promoting their preferences. It’s not limited to us at Hymans - it’s rife across the industry, as David Heinemeier Hanson2 observed:
…this is all just a battle to the death, and there’s going to be one framework and there’s going to be one programming language that is left standing. Programmers are really drawn into that horse race.
David Heinemeir Hanson - Software Contrarian
Interestingly, we rarely consider the people dimension as a first order concern. It’s all C# / R / Python / React / Angular /…. and rarely ever skills / background / preferences. DHH again:
"One of the things for example is that Ruby is loosely and dynamically typed, and some people simply have their brain wired in such a way that that is an offense to their sensibilities right? And I respect that because I feel the same way about statically typed languages."
The summary being: people are different. Who’d have thought?
Software is an increasingly diverse endeavour. 25 years ago, developers built apps and handed them over to ops to deploy on physical servers. Now we have UX designers, front end developers, back end developers, data scientists, site reliability engineers and more. Those physical servers are being washed away by cloud hosting: infrastructure is now code. That’s a Cambrian explosion of digital skills. Even within the roles we might associate with writing applications, there are practical and cultural differences. Developers, grounded in symbolic logic, object orientation, frameworks, automated testing and the likes. Modellers, with a mathematical/statistical background for whom numbers and distributions and functions and linear algebra underpin their thinking framework3.
R is a procedural, dynamically typed, REPL based language. C# is object oriented, statically typed and ahead-of-time compiled. The R ecosystem is well served with statistical utilities; the dotnet ecosystem similarly with application frameworks. Very different experiences.
Different tools for different jobs, requiring different skills. Different tools for different people.
3 simple questions
3 is the magic number, and handily proves useful here. When contemplating any task, we need to ask 3 questions:
- What is the problem we’re trying to solve?4
- How might we solve it, i.e. what tools do we have available?
- Who is doing the work? i.e. what skills/background/preferences do they have?
Let’s play a game to illustrate that. Here’s a selection of problems, tools and people. How would you put them together?
We’re edging into comedic possibilities, but it does illustrate the point:
- Forrester paints a door with a chainsaw
- Decorator cuts down a tree with a paintbrush
Looked at that way, it seems faintly ridiculous that we might expect any tool - including a programming language - to be universally applicable. Turing completeness is interesting theory. Practice, as always, is rather different. And I can’t imagine ever paying a decorator to do anything with a chainsaw.
In all endeavours, we need to find the sweet spot among problem, tools and people. Meatloaf is wrong here; 2 out of 3 is bad.
But but but…
What about the downsides? Surely it would be easier if everyone just used the same stuff? I hope, by now, you agree the folly in that argument. As DHH says, people’s brains are wired differently. It’s flawed thinking to ignore that. Polyglot programming does have costs; there’s no doubt about it. It’s not a free for all5.
But as Fred Brooks said, there is no silver bullet. Treat anything advertised as such with the disdain it deserves.
Equally, we should embrace diversity. As a modeller, you’ll improve your thinking skills by trying some C#. Or maybe F#. Same for a developer looking at R or Python. The Pragmatic Programmer recommends learning a new language every year. Decorators might not use chainsaws, but they have more than paint brushes in their armoury.
If we all apply the 3 golden questions then we stand a better chance of getting past language top trumps and solving problems well. It doesn’t stop us having favourites. And it shouldn’t: diverse advocacy is good. But it has to be constructive and lead to better outcomes.
Building software is a socio-technical discipline. We can’t ignore the ‘socio’ part; it’s people who wield the tools and get the work done. And people are different.
1. And we do: R is already a go-to choice for statistical work here.
2. AKA DHH, creator of Ruby on Rails
3. None of which is universal obviously. Some developers are more comfortable with functional programming than object orientation for example.
4. Actually, it’s surprising how often we don’t put enough emphasis on this one either - but that’s a topic for another day.
5. More on that too, perhaps, in a later post.
On-demand event
Together, using technology to build better financial futures
This blog is part of our Better Futures 100 series: tech campaign. To find out more, watch our on-demand event here.
0 comments on this post