Jo Rabin is a fractional/interim CTO, coach and advisor with a passion for practical innovation. He’s been involved at the beginning of several technologies, including claiming to have sent the first email while mobile – in 1985. He’s led the development of the Reuters Forex Trading product (USD 2Tn/day) and invented the international standard for news, NewsML. Jo also headed Reuters efforts in mobile, however, infected by the start-up bug, he then spent some years being a start-up founder, CTO, advisor and CTO-in-Residence at Telefonica’s accelerator, Wayra.
Back in the day (the day I was working on Web standards), I thought about “what makes a good standard?”. And “If one were to write XML over again, what would the main considerations be?” and similar musings.
Since then, I have realised that thinking about this is extensible to other domains. And especially the choice of programming language/environment. Most recently, this has been churning around again in the form of discussions of Citizen Engineering and low-code/no-code. Distinct topics that seemingly inevitably get blended together like an afternoon of children using Play-Doh, and ending up with an ugly greyish, brownish mess.
Low-code, no-code
The key point about low-code/no-code seems to me to be the contradictory notion that it’s not the nature of the code itself that matters all that much, it is the remaining 90% of what it takes to write sound, reliable, extensible, maintainable applications, and those concerns are primarily the same, irrespective of what programming language, or diagrammatic representation you may choose to use.
If low-code/no-code is a part of citizen engineering, then let’s focus on the engineering part, not the coding part.
Teach kids to code
The same is true of “Teach Kids to Code” I feel. A well-intentioned effort to prepare children for a digital world, undoubtedly, but misconstrued as being something to do with teaching them Python, or worse still, Excel.
Not that Python is bad, but that what we are trying to teach is surely algorithmic thinking, being on the lookout for unintentional errors, input validation and the like, rather than the syntax of any particular language.
Of course, the paradox here is that teaching those things can’t be done in the abstract, so you have to teach a concrete syntax, it’s just that the point is not to learn the syntax, except inasmuch as you have to know enough syntax to access the underlying concepts.
Choosing a language
So back to the point, at last. Even given the above, choice of programming languages and tools is a strategic decision for any organisation. I do get quite impatient at the laissez-faire school that says “let your teams choose”.
That seems to me to be based on the idea that the choice is primarily down to personal preference of the squiggliness of the brackets, the presence or absence of semi-colons and a personal aesthetic choice of indentation style or the desire of the engineer concerned to learn something new, because it’s cool, because it’s to their economic advantage, or both.
All of this is strongly argued over, of course, but in my view misses the point.
A strategic choice
Choosing your language technologies (and you’ll probably have more than one, but hopefully no more than a handful) is a strategic choice.
You are going to live with it for a while. Your team is going to maintain the code of long-forgotten colleagues. But more than that, it’s a pragmatic and economic decision; you’re going to want to recruit from a broad pool (skill needs to be widespread), and you’re not going to want to pay a king’s ransom for the team you do recruit … competent Java programmers are cheaper than their Scala cousins.
No language can be all things to all people. Indeed, the qualities you seek may be in tension with each other. If all we wanted was being easy to learn, we’d only have tricycles, but no one will win the Tour de France on a tricycle, mastering the skills necessary for the specialised bike is required to win.
Here is a not-completely-random list of qualities. It’s up for debate and your choice as to how you weight the various things for your various use cases:
Language qualities
- Safety – Reduces the likelihood of unintentional things. Type safety. Defaults are less damaging, variables in local scope, private accessors etc.
- Accessible – Easy to learn, can get up to speed quicky, fewer side effects and hidden-features
- Legible – Is it easy to understand what you did yesterday, is it easy for other people to? (*)
- Suitable – Matched to the domain, extensive library support etc.
- Maintained – Ongoing development path, matches tomorrow’s environment
- Widely used – Easy to get staff with a relevant level of skill, competency
- Effective – Once at a skill level, is it easy and straightforward for professionals to use?
- Efficient – Conservative use of resources
- Powerful – Does it have features that save time, without compromising accessibility
- Testable – Encourages repeatable testing through language features or extensions
- Extensible – Allows systematically adding features (is operator overloading a good or a bad thing anyway?).
Coda
Just when you thought there must be enough languages to suit every taste, well, you find you were wrong.
Like in everything else, machine learning blows the cobwebs and assumptions out of everything. Did you hear about Mojo, for example? Faster than C, compatible with Python, they say. Worth a quick read as to why its inventors invented it.
Another question to ponder is what part existing programming languages play in a world where ChatGPT writes our code for us …
(*) Call me Canute, but I have a terrible problem with Regular Expressions, which exist without regard to readability and unintentional side effects and are altogether like putting a chainsaw in the hands of a six-year-old. If you depend on them in live code and haven’t written a wall of tests, you may have been better off writing a simple parser in many cases.
***
CTO Craft Conference is BACK! We’re already planning the next London conference for 7-8 November. Remember, our first conference was a sell-out, so pre-register now to be the first to hear as soon as tickets go on sale.
If you’re not a member of the free CTO Craft Community, what are you waiting for? With over 10,000 global technology leader members, you’ll get exclusive access to Slack channels, conference insights and updates and other valuable content.
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.