12 comments

[ 3.0 ms ] story [ 35.8 ms ] thread
Why would you want your compiler to give you error messages in code? That's like AutoCAD drawing you a picture when it can't complete a command.
A more fair comparison might be AutoCAD showing errors like intersecting surfaces visually, rather than spitting out a list of "bad coordinates".
This is such utter nonsense. I've programmed professionally in both C++ and Erlang and while there are situations where Erlang might shine, there are issues where it completely loses to C++, namely, cases where you need a lower level of abstraction. I don't see people writing video and audio codecs in Erlang as there are no real abstractions for SIMD and no latency guarantees. Erlang supports concurrency in its virtual machine, but no support for real parallelism (e.g. you can't control when context switches occur, or finely control flow control in general). While I was programming in Erlang, I loved aspects of the language, but found Erlang apologists who didn't really understand native programming to be insufferable.
This comment doesn’t seem to be a response to anything in the article, which is talking primarily about input and output languages (output here meaning error messages) of compilers. The article does not compare anything about C++ and Erlang beyond compiler error messages.
Right my point is that the article cherrypicked a single thing and made a general claim about Erlang being a "true computer language" which is what I take umbrage to.
Language is something you can conduct a dialog in. In most of the computer languages you can't.

I'm not saying that C++ (or any other) is in any way inferior to Erlang because of human-readable error messages. But this property to communicate back and forth in the same language is definitely interesting.

Right but if you make the language as natural as possible for the human, you introduce layers of abstraction that make it difficult or impossible to understand what's happening at the machine level.
The error message in every language requires that the programmer know the language themselves.

‘bad_match’ error in erlang is as much of a enigma to a C programmer as is a ‘bad operator’ in C to a python programmer.

It is not the error message that makes erlang valuable, rather a synchronous state machine for a single process that is completely independent of every other process which stops errors from propagating to other unrelated processes.

Well, both GCC and Clang now can report errors in JSON format, for further processing. But it is more about machine processing, rather than of inability to speak English. Ironically, OCaml, which mentioned in the article, recently put some effort to improve error messages, to be readable for human. And more improvements will come in the future releases.
And both things are good news!

OCaml human-readable messages are brilliant! And machine-readable Clang output is very promising, too.

The problem with C++ is that template expansion doesn't do any validation of the parameters at all. It just keeps going until it generated as much code as possible and only afterwards does it report a large error on the nonsensical code it generated.