This is Words and Buttons Online — a collection of interactive #tutorials, #demos, and #quizzes about #mathematics, #algorithms and #programming.

Why Erlang is among the few
true computer languages

Imagine there is something wrong with the water pressure in your house. You have to call the plumber service. They say that there is a guy, who is honest, and capable, and has a PhD in plumbing, but… He doesn’t speak English well. He came from Tajikistan and only speaks fluent Tajik. But it just so happens that you studied Tajik in college, so you say that they send the guy immediately.

When he arrives, you describe the problem (in Tajik), and he gets to work. Soon enough he finds the problem and tries to report it to you, apparently waiting for a reaction. But for some reason he doesn’t use Tajik to report it, he uses English. Which… He doesn’t really know. If you reply (in Tajik) that you don’t understand, he will not switch to Tajik; he will only repeat the same phrase louder.

Which doesn’t help to build a dialog at all.

Nobody knows why he consistently chooses to reply in the language he doesn’t speak well instead of his own. That you do, by the way. It is absurdly irritating, but that’s just how the things work. It’s how they have always been. What he means makes perfect sense in his own tongue, but what he speaks aloud is basically a bad English mixed with professional jargonisms and Tajik obscenities.

This feels somehow like this.

In Tajik:
Бубин, ман наметавонам элементи
шумо барои шумо чоп карда
наметавонам, зеро ин намуди
оператори сменавии сменаи
муайян надорад.






In 'English':
In function ‘int main()’: 19:16: error: cannot bind
‘std::ostream {aka std::basic_ostream<char>}’ lvalue
to ‘std::basic_ostream<char>&&’ In file included from
/usr/include/c++/4.9/iostream: 39:0, from 2:
/usr/include/c++/4.9/ostream:602:5: note:
initializing argument 1 of
‘std::basic_ostream<_CharT, _Traits>& std::operator<<
(std::basic_ostream<_CharT, _Traits>&&, const _Tp&)
[with _CharT = char; _Traits = std::char_traits<char>;
_Tp = Element]’ operator<<basic_ostream<_CharT, _Traits>&& __os,
const _Tp& __x)

Tamserpo [CC BY-SA 3.0 or GDFL], from Wikimedia Commons

Ok, it isn’t about plumbing anymore. It never was about plumbing. It’s about how we communicate with the machine. A programming language is something we use to tell it what to do, but the machine tries to speak back in English when something gets wrong. Computers don’t speak English well, although they are good at processing formal languages. And presumably, the one who writes in a formal language should be able to read it back without a problem. Wouldn’t it be better, if the compiler or interpreter responds in the same language it gets its commands in?

So far the only languages I know that report errors in itself are Erlang, Elixir, and Ocaml. If you know more, please let me know.

Here’s a simple example from “Programming Erlang”:

1> Point = {point, 10, 45}.
2> {point, C, C} = Point.
=ERROR REPORT==== 28-Oct-2006::17:17:00 ===
Error in process <0.32.0> with exit value:
{{badmatch,{point,10,45}},[{erl_eval,expr,3}]}
	

The string in bold is the error message, the rest is just a preamble from the interpreter. Indeed, it isn’t entirely convenient for the casual reader. You have to know Erlang to read its errors. But since you still need to know Erlang to write the code that causes them, it’s fine.

The alternatives are much worse. With informal and non-standardized error messaging you have to know not only the programming language itself but its error messaging Pidgin as well. Every C++ practitioner can confirm that reading STL messages is an art by itself. It takes knowledge, patience, determination, and occasionally a crystal ball to build a firm understanding of a reported problem.

For instance, the error message from above reads as “sorry, I can’t print out an element for you, because its type doesn’t have a << operator.”

Normally, the language is something you can build a dialog in. Programming languages are an unlucky exemption. Historically, it was more important to tell a computer what to do rather than the opposite. When you write a small single-threaded program you can hope that there will be no errors whatsoever so you don’t really need a reporting at all. Error reporting is viewed as an auxiliary feature.

Erlang, however, aims at building highly complex distributed systems. Errors are not only most likely to happen, they are inherent to the nature of the domain. Everything that could go wrong eventually will. And you better have a decent reporting language for that.

The very fact that you can have a dialog, meaning writing code and receiving errors in the same language, makes Erlang not only programming but a true computer language.