Imagine there is something wrong with the water pressure in your house. You have to call to the plumber service. They say that there is a guy, who is honest, and capable, and has a Ph. D. 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. It is absurdly irritating, but that’s just how the things work. It’s how they always been. What he speaks in is basically a bad English mixed with professional jargonisms and Tajik obscenities. It looks something like this:
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)
Ok, it isn’t about plumbing anymore. In fact, 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 formal language should be able to read it back with no problem. Wouldn’t it be better, if the compiler or interpreter would respond in the same language it gets its commands in?
Somehow the idea seems not all that agreeable without a Tajik plumber.
So far the only language I know that reports errors in the same language you write code is Erlang. If you know more, please let me know in the comment section below.
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 would 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 was always 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.