The Babel of Polyglot programming

Polyglot cooking

An honorable mention goes to the first person who can translate the following:

Rebus:

• I sextarius lac, et recens totum organicum
• Totum in velit vel empta lyophilized lactic fermenta yoghurt

Procedimento

1. Mettete il latte a riscaldare. La temperatura del latte dovrà raggiungere i 40 ° ma non superarli. Oltre la soglia dei 50 °C causeremo l’inattività parziale dei fermenti lattici. Le yogurtiere che troviamo in commercio raggiungono la temperatura ideale dei 37 – 38 °C.
2. Use a spoon to remove the patina that will appear on the surface
3. Préparer les pots: ajouter dans chaque pot une cuillère à café pleine de yaourt naturel à température ambiante. Ajouter dans chaque pot aussi deux cuillères à soupe de lait réchauffé et remuer-le.
4. In jedem Gefäß hinzufügen Sie die restlichen Milches Quantität zu den füllen
5. Ahora tienes de sellar los frascos y dejar fermentar 8 horas. Por ayudar la fermentación tienes de cubrir los frascos con una manta.
6. Noiz jogurt prest egongo da, jarri hozkailuan dastatzea baino lehen eta 12 itxarotea – 24 ordu. Etxeko jogurt fresko astebeteko epean kontsumitu behar da. Lagundu nahi baduzu, markatu bilgarri-data “eta” poteak orrian.

Languages: Latin, Italian, English, French, German, Spanish, Basque

Read the original at https://www.ideegreen.it/come-fare-yogurt-in-casa-68374.html

The set of instructions just reported above are about a very basic recipe: homemade yogurt. The whole thing basically comes down to:

heat some milk at around 45° C, remove the patina on the surface, pour a mix of the heated milk and some yogurt in small containers, cover the containers and let them rest for 8 hours. Then put them in the fridge and almost another day before you can eat it and taste the full flavor.

Sounds pretty simple, hun?

But did it sound equally simple when you read the recipe at the beginning of the chapter?

You may argue: cool, nice linguistic exercise, but who could be so crazy to write a recipe like that?

Well.. maybe the same kind of person who could decide to:

• write an application in Java
• start adding some classes in Groovy because as the name suggests it’s groovier and because it came handier to write integration tests with Cucumber
• add a support tool in NodeJS because it makes easier to manipulate JSON to create test data against a real server
• write performance tests in Scala
• writes a template for a Perl script because that’s the language required by an external system to create another type of test data

That’s something that really happened to me and I can tell you, I was really not happy about it.

Sometimes there’s no choice, like in that project probably was the case with the Perl template. But more often than not it’s just a call of the code’s author.

Polyglot programming was a big buzz word in 2016. Everyone seemed to sing its praises but I’ve always looked at it very suspiciously. Here’s why:

None can master all these languages and so quality decreases

In the recipe I reported at the beginning of this post there are sentences (in the following order) in: Latin, Italian, English, French, German, Spanish, Basque.

I feel quite lucky: because I was born in Italy and because of my job I was kind of forced to learn at least a second language, English. Also, my native tongue resembles closely others spoken in the surrounding mediterranean countries. On top of that, I chose an high school focused on learning languages so I got exposure to some more of them.

I can therefore speak and write perfect Italian, I believe I know enough of English to make myself quite clear, I found learning French quite natural and because of the resemblance with my native tongue I can understand good portions of Spanish even if I’ve never studied it. I studied instead a bit ancient Latin, that none really speaks and I have an elementary knowledge of German. Basque, that’s completely unintelligible to me but once I get 80% of the rest written in different languages, I’m confident I can handle a single sentence with the loyal support of Google translate.

But understanding the rough idea of a set of instructions is different from being able to appreciate the nuances that are peculiar of any given language. Much more importantly, it also doesn’t automatically imply that I can write the same contents in all the languages with the same level of quality.

Moving to a working context, I’d like to think I can write high quality Java code, considered that’s that is what I spent 10 years of career tampering with. Because over the last 3 years I’ve also played a lot with Groovy, I hope my Groovy code is fine too.

But with Javascript.. until 3 months ago I was barely able to write quite common commands. Understanding a fully fledged framework written in JS? That was out of my reach. Perl, I have vague memories of a course on Operating Systems I did back at my University days where the hands-on part was done in Perl. And Scala, I feel ashamed to admit most of its syntax is obscure to me.

Ask me to modify that recipe or program and I could probably do it. But have it read by an expert in the language and my writing will probably sound just gibberish. Given to a language professor during an essay, my work would probably result in a lots of notes taken with a red pen and a final mark that promises to be pretty disappointing. In the Software Development world that translates to tons of bugs that will come back to chase me and my team.

It’s hard to find people who can modify that recipe

As said, I feel in the super-lucky position to say: yes, I can handle understanding the general idea of that specific piece of code and combination of languages. But things would be completely different if those 5 languages were, for example the following 4: F#, Typescript, Go, COBOL.

In the same way as I would find it very hard to dive into a new project written with 4 languages I’m not familiar with, so I believe it would be extremely hard to find someone with the appropriate knowledge to modify our recipe/project.

With the current extremely aggressive requirements for time-to-market we usually have to deal with and considered how hard it is to hire talents, we should strive to make the transition of anyone in a project as easy as possible.

By introducing this crazy mix of languages we are making the process to find someone suitable for the job almost impossible. We may be lucky and find 1 candidate that ticks all the boxes but what will usually happen is that we’ll have to go through a lot of interviews, deal with a lot of frustration until we decide to settle for lower standards and hire the best person that happens to tick at least 1 or 2 of the boxes. Then patiently wait that that person get up to speed in a decent manner with all the complexities inherent with learning so many complex things at once.

In the meanwhile, you’ve wasted 4-6 months. Is that affordable in your projects? Personally, I’ve never had the luxury to say so.

You are making it harder to find someone happy to invest in all those languages you chose

You’ve already gone through your 10 or 20 interviews, dealt with the initial frustration and realized you must lower the bar and settle for someone who knows 1 of yours languages and is smart enough and happy to learn the rest.

You feel wise, happy with your choice and consider the problem solved just to realize things haven’t actually got any simpler.

You find a great Java purist who swear they will never gets their hands dirty with any other languages running on the JVM because “I could never accept to define all my objects as ‘def’ and all my exceptions treated as unchecked and lose the benefits of compiler checks”.

So you call that JVM guy, hoping that their exposure to both Java and Groovy will help them having an open mind. But their answer is that they are so happy with the flexibility of Groovy that they could never accept to deal with the rigour of Scala.

So you can all another more well rounded JVM guy who likes Java AND Groovy AND Scala. Beware, we are entering fantasy-creatures-land here. But you found it, mention NodeJS and see them politely declining your offer saying: no way, I invested too much of my time and energies learning some mature languages and enterprise patterns that I can’t go back and embrace a lightweight tool like that.

So you try the other approach, call the NodeJS guy telling them you are ready to wait they get up to speed with the 3 other JVM ones. It’s highly probable their answer will be a sarcastic “no thank you, I’m already super productive with my tools, I don’t want to deal with the burden of all the boilerplate the other stuff will require me to do. Define a factory to create a String? Adding tons of getters and setters? Writing 10 lines of codes and having to catch 4 exceptions to call a method by reflection? No thanks, I have better ways to spend my working time. I like to build cool stuff, not all that useless scaffolding that’s supposed to eventually get me there”.

And then you find the unicorn: expert in Java and NodeJS, did some cool stuff in Groovy and Scala for some of their pet projects. You tell them they will also have to do some Perl. And… ‘goodbye’ is the only thing you can tell at their backs while you see them running away screaming ‘the horror’.

Every language you add to your solution is a design choice that adds complexity and so increases the cost of ramping up new joiners to the team. You may be ready to accept those costs but consider if other people, called to join your project, may be interest in the same long term investment.

If you really have to do it the polyglot way, don’t simply throw together some sexy names but try to come up with a combination of technologies that may sound appealing to someone in its entirety.

One sentence may sound nicer in that language, but what about the whole story?

We have all done that. Right in the middle of our essay we felt the compelling need to write that quote in French or in any language that was different from the one used for the rest of the essay. The need may have come from desire to show off or because we truly believed it added something. Sometimes the choice of a language seems mandatory, because a certain concept can only expressed effectively in that language (for example a local saying claims that Icelandic has over 100 words to name ‘snow’). It doesn’t matter. 1 single sentence that stands out in the middle of other 100 can really give that special taste, that special kick.

But when all 100 sentence compete among themselves for the one who stands out the most, than our story, our recipe, our code becomes a mess, where it becomes crazy exhausting to follow the flow.

Maintenance of a software is made for the most part of reading someone else’s code and change that small part that needs to be changed or fixed. Also, usually maintenance work is performed with low budget by people who enters a certain code base for the first time. And because it has been proved multiple times that maintenance makes for at least 80% of the total costs in the entire life-cycle of a piece of software, I don’t think it’s a great idea to make that stage more complex than it already is.

When I’m maintaining your software I don’t care if every single line reads like a verse from a Shakespeare poet. If I read anything that looks like a Frankenstein patchwork created by pulling a verse from Dante, one from Baudelaire and one from your very talented neighbour, I will hate you because you are making my life miserable by forcing me to read something that when taken in its entirety sucks and will take me 5 times more the time I’m given to fix your masterwork.

It’s hard to integrate properly different languages

In the trivial example of the recipe we could say that every sentence lives on its own. Sure, they all concur to build a sequence to progress in achieving a certain dairy goal, but from a linguistic point of view they make sense if read alone. When this happens, the complexity of reading the whole is admittely decreased.

Similarly, if our software is properly organized in well defined and self-contained layers, each one taking care of its own responsibility, we can probably still manage to deliver code that is relatively clear if we stick to choose a separate language per layer.

The problem with this approach is that clarity may be partially safeguarded but what is often still neglected is the complexity and the cost of the integration of different languages based on different assumptions.

My Java code running a Node script will be able to leverage the benefits of garbage collection only for the Java part.

My Groovy code will be able to call seamlessly my Java library because (allow me the imprecise stretch) the first one can be considered a superset of the second but the viceversa won’t be true because of all the ASTs that Groovy introduces.

I won’t be able to use a single tool to track down the source of a memory leak. My JVM profiler will track my code only up to a certain point, and that is for the Java part. Once I reach the NodeJS or Perl part I have to switch to another tool. Which means spending time researching and then learning how to use an additional tool. In any case, I will have to reconcile manually the insights coming from all the different tools. Sometimes that can mean paying for 2 licenses instead of one.

One of the benefits of writing a Java application is that, if properly written, I will be able to run that code on any environment and operating system. That assumption breaks the moment I try to run my Perl code on a Windows machine. Sure, it can be done, but I will have to install other tools to emulate a different systems only to debug a single script.

It’s almost impossible to write a Java application that is not multi-thread. Even when you are not the one spawning new threads, the JVM or the hosting container will do that for you. You need more horse power, you spin up more workers. NodeJS is inherently single threaded. Scalability is achieved following a reactive approach, based on promises and emphasis on pure functions. Good luck at designing a clean architecture that integrates in a sensible and clean way both approaches. Then good luck again at explaining that architecture to someone who’s well versed in only one of the 2 approaches.

I could go on for pages but I think you got the point.

And anyway, you are not doing anything new

What I’ve seen is that usually polyglot programming is just a way to satisfy the ego of the new techie on the block. It may be because they wants to show off their technical skills or because they have to compensate for a boring job. In both cases bringing Babel on earth is not the solution.

Without mentioning that, and here I’m really sorry to break it to you, Polyglot programming is not something new at all. An example? Let’s go back 10 years to 2007 and consider an Ant script that with the support of some bash scripts builds, deploys and spins a J2EE app that thanks to a mix of Java plain Servlets and JSPs+EL serves HTML web pages wired with a Javascript framework of your choice (e.g. jQuery) and styled with CSS that display data previously loaded partially with SQL queries executed thanks to a JDBC driver written in C, partially through SOAP calls exchanging XML data.

People ran away from that, mainly claiming its complexity was getting out of hands.

Don’t try to be cool. Try to be smart and do the right thing. Keep it simple.