Why do we avert to divert?
Most of programming languages look like ugly mixtures of keywords and math operators. Sometimes those keywords are abbreviated or twisted in other way, sometimes they look like words from human language, but in most cases they are taken from English and almost never from any other language. Why?
Almost every language has a sarcastic phrase like "Speak English", "Mluv česky", or "Pričaj srpski", which is used to not very politely tell someone to speak more understandably. But when it comes to programming, you can only "speak English". It has an absolute supremacy and nobody questions it. Sometimes, when you work on a local project such as government-related website, your developer team might decide to use local language for naming methods, classes and properties, and for writing documentation. Many other people would tell you that it's a wrong decision, because it makes your code less reusable. But regardless of the language you choose for naming conventions and writing documentation, the bare bone language of built-in commands and statements in your code is still English, and there is usually no other option, because the language itself almost never provides it.
Imagine a fundamental
if ... else statement written like
wenn ... sonst,
als ... anders, or
ako ... inače, not to mention languages with alphabets like Greek or Cyrillic. It would look like a joke, wouldn't it? But when you think about it, why would it look like a joke?
Artwork by Hervé Hubert
Reasons and excuses
Back in time, when every byte mattered in terms of disk space, programming code used to be stored using ASCII set, consisting of 128 characters. Therefore there was a room for just 26 English letters, and the rest of ASCII codes remained for commands, digits, and the most necessary symbols. Programming languages were averagely more low-level than today, meaning that there were less of interpreter layers between the human-written code and the raw binary stream read by CPU's, which were much slower and every interpreter layer had its footprint on performance. If you are either designer or front-ender, you'll know that the same text in English usually takes less space than almost any other language.
The second reason is that English has relatively simple grammar. For example, it has only nominative case, unlike German which has four of them, or Slavic languages which mostly have six or seven, or Finno-Ugric group with up to tremendous 18 cases. Because of this relative straightforwardness, English sounds less ugly when simplified as programming language, because elsewhere you'd need to at least differentiate between nominative and accusative when you send an argument to a method.
Finally the third reason is trivial, but probably the most important. Programming was invented in the UK. Its foundations were laid down by Charles Babbage and Ada Lovelace in the 19th century, and by Alan Turing during and after the Second World War. Furthermore, the first widely used home computer was Clive Sinclair's legendary ZX Spectrum, which used to start every session by launching an interface for BASIC, the first popular programming language.
But things have changed meanwhile, haven't they?
Some of programming languages which are used nowadays were found by non-Anglophone people. My article is not the first on this subject, and many other articles will mention that PASCAL was invented by a Swiss guy, PHP by a Dane, Python by a Dutchman, Ruby by a Japanese guy and so on.
Now, imagine if one of these people was a bit like Mozart, the first big composer who dared to challenge the supremacy in Italian language in his pieces. So, for example, instead of PHP "echo" we would have "ekko". Would anyone bother learning Danish to be able to understand this? Of course not. But then, how would the history of classical music look like if Mozart still clinged to Italian like his contemporaries did? And speaking of Danish, back in 19th century philosophers across Europe did bother to learn it because of Søren Kierkegaard.
So yes, things did change since the Cold War, but hardly in the right direction. In many aspects it is unfortunately quite the opposite, and it doesn't apply just for programming. We only fool ourselves that we live in the world of diversity. We actually rather live in the world that tries to silently annihilate diversity by making it easier for us to ignore it. Translator apps bring us closer because they make our communication easier, but they also give us a helping hand that doesn't really help us, only spoils us.
Get back to your subject Luka
Of course I am not an exception either. I'll keep naming my methods and props in English like everybody else, because other people need to be able to read my code. The same goes for documentation, Git messages and everything else. But at least I don't want to say that something is right if it's wrong, and saying that something is wrong is the first step in making it better. This of course sounds like something that someone already said, most likely also in English.
Well actually there is a point, and there is also an "action item", to use the word from Scrum and more generally from the management discourse.
Many programmers are big chess fans. Two among Alan Turing's associates at Bletchley Park were also famous chess players - Hugh Alexander and Stuart Milner-Barry. Well, you'd notice that chess terminology is a beautiful example of Babylon tower in terms of language variety. When a bishop makes a long diagonal move, it is called "fianchetto", which comes from Italian. When a pawn from e5 takes a pawn that just got from d7 to d5, it's called "en passant" and it comes from French. And a situation in which it would be the best for the current player to skip the move is called "zugzwang", which is of course a German word, same as "zeitnot", which means that time on your chess clock is running up.
Since my time is also running up, I'll ask you is there a better English word for any of these chess terms? No, there isn't. So here is the action item. Developers across the world, let's infuse our programming languages with something exotic from our native languages. Give yourself this challenge. If the English is invincible in the role of potato, then let's at least spice the potato with some salt, pepper, and diversity.
const bookTitle = book && book.bookData && book.bookData.synopsis && book.bookData.synopsis.introduction ? book.bookData.synopsis.introduction : '';
As you see, it resembles the ladle. And as you might guess, kutlača code is not something very nice. It's used when you need to access a deeply nested member of an object, while not being sure which if its parent keys exist or not. Maybe there was a time that you had to use either big or small kutlača, because your code could otherwise throw an error. But there are several ways to avoid it, only that's not the subject of this article.
So, feel free to start describing to this sort of code as kutlača, but also try not writing such code.
If you have questions, or just want to know more? Please contact Luka Stanisavljević.