4 ms·

Sure, here is one example: error messages. I guess even the author of the article (you?) couldn't come up with a good justification for them. They are truly hor

Sure, here is one example: error messages. I guess even the author of the article (you?) couldn't come up with a good justification for them. They are truly horrendous, cryptic and maddening to figure out. There is just no excuse for a language that's twenty years old to not have reasonable error messages. Strings are a whole story of their own, but simply saying "they're not that important" is just ludicrous if you simply take a look at all the efforts that every single programming language in existence take to make string manipulation fast and extensive. The way the supervisor model is touted as a major improvement is also very disingenuous: you still need to create and maintain the chain of supervisors yourself, and nothing stops you from doing that in other languages. Erlang really has no advantages there. The syntax and multiple separators also makes it very hard just to move code around (think: refactoring). You shrug and say that the beginner just needs to try harder, I'm saying "they won't, they didn't and probably never will". Erlang is an interesting academic curiosity but it's too alien and its creators are too blinded by their own brilliance to even acknowledge these very simple mistakes, so the world just moved on.

davidw 16y ago
> Erlang is an interesting academic curiosity but it's too alien and its creators are too blinded by their own brilliance to even acknowledge these very simple mistakes, so the world just moved on. You said some sensible things up until that point, but kind of go off the rails there. Erlang is most definitely not an academic language, and Joe Armstrong is not a "blinded by his own brilliance" kind of guy at all. Indeed, one of the real problems is that there is enough Erlang code in production (in critical roles) that they can't just go fiddle with the language, correcting some of the obvious uglies.
mononcqc 16y ago
1. Error messages are sometimes cryptic and that is indeed a language flaw. Line numbers would be absolutely fantastic to have and it's a shame they're not there. I can agree on that. Other languages, however, do not uniformly do a better job at being clear when crashing. It's not a unique trait of Erlang to have unfriendly error messages. 2. Strings are important, but not the list type of strings all the time. Erlang, as I mention in the article, has 3 types of strings, and atoms. Jlouis' article had the best arguments for the strings not being that necessary (or rather, too depended upon in general circumstances). See PHP for an example of a language that depends on strings too much for everything. This is also really dependent on the type of application you work with. Telecom software barely needed strings and rather needed ways to handle binary protocols. Some web apps will need them more than others. I might have painted them all with a brush too wide -- working with Erlang brings me to issues where strings are not needed that often and are frequently used as an opaque data type that you just pass on to some other piece of code somewhere else. 3. Yes, you need to create and maintain the chain of supervisors yourself. I am not aware of any AI system good enough to figure out what is alright to have crashing and what isn't, or how to react when problems arise, when to give up on restarting processes, etc. I have my doubts about 'nothing stops you from having them in other languages'. I know Scheme with Thermite had them. What other languages have supervisors, monitors and links that can even work across nodes? 4. Refactoring is a valid point, and there are very interesting tools for that (see Wrangler: http://www.cs.kent.ac.uk/projects/wrangler/Home.html http://www.cs.kent.ac.uk/projects/wrangler/Home.html), but there is more to refactoring than moving bits of code around: handling dependencies, breaking existing functionalities and regressions, etc. Syntax only makes one of all the problems of refactoring difficult. Referential transparency, success typings and all the other tools make it a lot easier. It's not all or nothing here. 5. It's fine that they might never will. Erlang isn't for everyone. I found it maps to my mental model of organizing things very well -- much better than any OO language out there. I can readily accept that for many people, the opposite is true. 6. Erlang is anything but academic at its roots. It was created in industrial setups by computer scientists and engineers with real problems to solve. It's been battle tested for decades and has received academic interest only afterwards and is now enjoying a presence both in the industry and in academia.
gordonguthrie 16y ago
> The way the supervisor model is touted as a major improvement is also very disingenuous: you still need to create and maintain the chain of supervisors yourself, and nothing stops you from doing that in other languages. Erlang really has no advantages there. This is total nonsense. You cannot write your own supervisors in other languages. The supervision tree works because Erlang processes can monitor each other. If you fail, I get sent a message. Error handling or orthogonal to the calling function stack. This is implemented underneath Erlang inside the VM and is baked into the entire run-time environment. The following languages to my professional knowledge do not support that construct: Fortran, Algol, Pascal, C, C++, VB, VBA, Java, Python, Perl, PHP, Ruby, Lisp and Haskell. All of these languages handles errors up the call stack. If you want to write your own supervision trees then you need to implement your own run-time environment with your own custom language on top of it.
- silentbicycle 16y ago
  The only languages where I've seen supervision hierarchies an an explicit design principle have had explicit ports of Erlang's concurrency model, such as ConcurrentLua (http://concurrentlua.luaforge.net/ http://concurrentlua.luaforge.net/).
- billmcneale 16y ago
  > This is total nonsense. Yet, the author of the article himself agrees with me: "Yes, you need to create and maintain the chain of supervisors yourself." > You cannot write your own supervisors in other languages. Now, that is total nonsense. First of all, Turing complete is Turing complete, so your statement is wrong just on this basis. Now if you want to argue that it's easier to maintain such a chain of supervisors in Erlang than, say, in Java, I'll just disagree. You spawn processes (lightweight processes) all the time in Java and monitoring their death is a few lines of code. You just don't need the support of the JVM for that, and going further, I just don't see what JVM support adds for this particular functionality. Hence my point that Erlang doesn't buy you much over traditional programming languages in that area.
  - mononcqc 16y ago
jlouis 16y ago
I'll only take some of these: * Error messages: The current format has two distinct advantages to the experienced programmer: They are Erlang terms and can thus be manipulated easily as such. And they are succinct. I definitely give you that they are not easy to read for the beginner, but for the more experienced programmer, they are actually easy to read. Your critique could be countered by writing a "beginners mode" which transformed the error into a more readable variant. Which isn't that hard to do but it takes resources which are better used elsewhere. * Strings: Most functional languages, be it Haskell, Erlang, Ocaml, Lisp-variants and so on are usually better off with a representation of string-like objects which are symbolic. The reason is that symbolic manipulation is the strength of these languages - exactly as string-manipulation is the distinct advantage of perl. Furthermore the non-academic world in which Erlang was first used, telephony, has very little need for effective string handling, I might add. Not everything needs a string. * Syntax: The syntax makes it harder to move code around, but not very hard. You will find that swapping the order of the last line with something else is a thing you do rarely. Even in pattern matches. At least I don't think it is much of a problem. Yet, I note that refactoring in other languages is not always exempt from similar problems. Changing type in java names in Java requires you to change the constructor call. Moving blocks of code in Python requires you to change their indentation. Hoisting a function out means you must create it. If it really pisses you off you can just write a style where the delimiter is at the beginning of each line and the . is on a line by itself. Then reordering is easy.

davidw 16y ago

> Erlang is an interesting academic curiosity but it's too alien and its creators are too blinded by their own brilliance to even acknowledge these very simple mistakes, so the world just moved on. You said some sensible things up until that point, but kind of go off the rails there. Erlang is most definitely not an academic language, and Joe Armstrong is not a "blinded by his own brilliance" kind of guy at all. Indeed, one of the real problems is that there is enough Erlang code in production (in critical roles) that they can't just go fiddle with the language, correcting some of the obvious uglies.

mononcqc 16y ago

1. Error messages are sometimes cryptic and that is indeed a language flaw. Line numbers would be absolutely fantastic to have and it's a shame they're not there. I can agree on that. Other languages, however, do not uniformly do a better job at being clear when crashing. It's not a unique trait of Erlang to have unfriendly error messages. 2. Strings are important, but not the list type of strings all the time. Erlang, as I mention in the article, has 3 types of strings, and atoms. Jlouis' article had the best arguments for the strings not being that necessary (or rather, too depended upon in general circumstances). See PHP for an example of a language that depends on strings too much for everything. This is also really dependent on the type of application you work with. Telecom software barely needed strings and rather needed ways to handle binary protocols. Some web apps will need them more than others. I might have painted them all with a brush too wide -- working with Erlang brings me to issues where strings are not needed that often and are frequently used as an opaque data type that you just pass on to some other piece of code somewhere else. 3. Yes, you need to create and maintain the chain of supervisors yourself. I am not aware of any AI system good enough to figure out what is alright to have crashing and what isn't, or how to react when problems arise, when to give up on restarting processes, etc. I have my doubts about 'nothing stops you from having them in other languages'. I know Scheme with Thermite had them. What other languages have supervisors, monitors and links that can even work across nodes? 4. Refactoring is a valid point, and there are very interesting tools for that (see Wrangler: http://www.cs.kent.ac.uk/projects/wrangler/Home.html http://www.cs.kent.ac.uk/projects/wrangler/Home.html), but there is more to refactoring than moving bits of code around: handling dependencies, breaking existing functionalities and regressions, etc. Syntax only makes one of all the problems of refactoring difficult. Referential transparency, success typings and all the other tools make it a lot easier. It's not all or nothing here. 5. It's fine that they might never will. Erlang isn't for everyone. I found it maps to my mental model of organizing things very well -- much better than any OO language out there. I can readily accept that for many people, the opposite is true. 6. Erlang is anything but academic at its roots. It was created in industrial setups by computer scientists and engineers with real problems to solve. It's been battle tested for decades and has received academic interest only afterwards and is now enjoying a presence both in the industry and in academia.

gordonguthrie 16y ago

> The way the supervisor model is touted as a major improvement is also very disingenuous: you still need to create and maintain the chain of supervisors yourself, and nothing stops you from doing that in other languages. Erlang really has no advantages there. This is total nonsense. You cannot write your own supervisors in other languages. The supervision tree works because Erlang processes can monitor each other. If you fail, I get sent a message. Error handling or orthogonal to the calling function stack. This is implemented underneath Erlang inside the VM and is baked into the entire run-time environment. The following languages to my professional knowledge do not support that construct: Fortran, Algol, Pascal, C, C++, VB, VBA, Java, Python, Perl, PHP, Ruby, Lisp and Haskell. All of these languages handles errors up the call stack. If you want to write your own supervision trees then you need to implement your own run-time environment with your own custom language on top of it.

silentbicycle 16y ago
The only languages where I've seen supervision hierarchies an an explicit design principle have had explicit ports of Erlang's concurrency model, such as ConcurrentLua (http://concurrentlua.luaforge.net/ http://concurrentlua.luaforge.net/).
billmcneale 16y ago
> This is total nonsense. Yet, the author of the article himself agrees with me: "Yes, you need to create and maintain the chain of supervisors yourself." > You cannot write your own supervisors in other languages. Now, that is total nonsense. First of all, Turing complete is Turing complete, so your statement is wrong just on this basis. Now if you want to argue that it's easier to maintain such a chain of supervisors in Erlang than, say, in Java, I'll just disagree. You spawn processes (lightweight processes) all the time in Java and monitoring their death is a few lines of code. You just don't need the support of the JVM for that, and going further, I just don't see what JVM support adds for this particular functionality. Hence my point that Erlang doesn't buy you much over traditional programming languages in that area.
- mononcqc 16y ago

jlouis 16y ago

I'll only take some of these: * Error messages: The current format has two distinct advantages to the experienced programmer: They are Erlang terms and can thus be manipulated easily as such. And they are succinct. I definitely give you that they are not easy to read for the beginner, but for the more experienced programmer, they are actually easy to read. Your critique could be countered by writing a "beginners mode" which transformed the error into a more readable variant. Which isn't that hard to do but it takes resources which are better used elsewhere. * Strings: Most functional languages, be it Haskell, Erlang, Ocaml, Lisp-variants and so on are usually better off with a representation of string-like objects which are symbolic. The reason is that symbolic manipulation is the strength of these languages - exactly as string-manipulation is the distinct advantage of perl. Furthermore the non-academic world in which Erlang was first used, telephony, has very little need for effective string handling, I might add. Not everything needs a string. * Syntax: The syntax makes it harder to move code around, but not very hard. You will find that swapping the order of the last line with something else is a thing you do rarely. Even in pattern matches. At least I don't think it is much of a problem. Yet, I note that refactoring in other languages is not always exempt from similar problems. Changing type in java names in Java requires you to change the constructor call. Moving blocks of code in Python requires you to change their indentation. Hoisting a function out means you must create it. If it really pisses you off you can just write a style where the delimiter is at the beginning of each line and the . is on a line by itself. Then reordering is easy.