Being Linguistic About Your Language
The language chooses the solution, Harry.
Currently my life involves pulling apart a monolith. It did us for a few years of operation, but as we start to grow in earnest, it’s begun to become the bottleneck. I’ll leave the lessons learnt from this endeavour to another post; today I want to reflect on the idiosyncratic way this legacy code was written.
An informal definition of legacy code is ‘code I either didn’t write, or can no longer remember writing’ (arguably there are whole disciplines of coding related to narrowing this definition!) The monster I’m wrestling definitely wasn’t written by me. But, like all ruins- it tells a story of the developer civilisation that once built, ran and worshiped it.
One thing that’s clear is that the developers absolutely loathed javascript. They were embedded (read: C’s enough abstraction for me) kids; and so, this isn’t exactly a surprise. But, what’s remarkable is that, despite this, it was still written in javascript. I can only assume they were unable to justify writing a web application in something more low-level!
There’s a beautiful notion within the Python community, and that’s pythonic code. That is- yes you could do it that way, but every Python developer worth their salt would look at you funny. Of course, it’s not something that’s exclusive to Monty’s tribe- they’re just lucky enough to have a language name that supports the suffix.
Languages are a second order of expression. When you express yourself in Scala, the result is shaped not only by your own sentiment, but by the intents and aims of Martin Odersky (and the wider Scala community). To be pythonic is to frame your solution in a way that is echoed by the Python zeitgeist (pretentious word of the day).
Like all art, it follows that if your intent and the intent of your medium are aligned, then you’re probably on the way to creating something magical.
For example: people that leverage the framework and embrace managed memory will have a fantastic time with C#; those that insist in doing their own pointer arithmetic and folding their collection primitives from scratch are likely to wonder what all the fuss is about.
The original developers of my monolith were not javascrophic (or, possibly, nodic?) For example- prototypical inheritance is sidestepped in lieu of an opinionated top-level-object factory, results are returned through function arguments and errors are defined using a system terrifyingly close to the old HRESULT system.
The funny thing is, it’s not bad code- the original authors were good developers. It’s just very surprising; if you go into it with a javascript mindset- then you’re going to do a lot of head-scratching. In fighting the fluency of the language, they’ve ended up creating their own implementation- something that uncomfortably straddles the intent behind more rigidly structured languages and the free syntax of javascript.
Code is read x* more times than it is written (*insert your own statistic here- but it’ll be a large number). Reflecting on the code I’m currently reading, I’m forced to acknowledge that although it’s a well formatted and workable solution- it‘s incredibly difficult to reason about, simply because the way the language is used is jarring to someone who knows it.
So todays lesson? If you’re using a language, try and use it in the way it wants to be used. Once you find yourself twisting it to fit into your solution space- take a moment to ask yourself if a) it’s the right language for the job, or b) it’s the right solution for the language?
