4 ms·

Wow, this is an endless list of apologetic statements trying to paper over Erlang's many deficiencies. "Your first contact will suck but it's not Erlang's faul

Wow, this is an endless list of apologetic statements trying to paper over Erlang's many deficiencies. "Your first contact will suck but it's not Erlang's fault, it's yours". Way to motivate.

mononcqc 16y ago
Bicycles have training wheels to get you going. Erlang doesn't. It might be hard and require effort. I don't know how you learn new things, but it's generally taking me lots of effort: math, sports, music, etc. They're all hard when you first begin. I remember I couldn't ever do anything good on a bass guitar (I started learning with a terrible sense of rhythm, not being able to clap on a 4/4 beat). I thought that music was just too hard, that the notation was too complex and obtuse for the sake of it, that improvising and jamming took some natural skill to get. It doesn't. All it takes is work, lots of it. It's hard because it's different and not something you pick up easily without prior experience. And even once I learned how to play bass (and have been for years now), I can't play drums for shit because it requires an entirely different way to think about music, notation and synchronism. You have to get in a different mindset when you switch instruments, or even just bands. As for sports, mastery takes years. Of course someone in a good physical condition will pick up some of them with more ease than someone not used to many sports, but if you're a trained ice hockey player, the skillset you learn won't apply with the same ease for baseball or basketball when compared to roller hockey or field hockey. You have to go back to some basics. Re-learn how to position yourself, new strategies, discover muscles you hadn't trained before. I see learning new programming languages as something somewhat related -- Languages can do their best to be friendly, but when the concepts behind them just vary wildly (see Prolog vs. C), you'll likely hit a wall. And it will not be the language's fault, but a question of you working hard enough to grasp it. Many languages have similar concepts and could be compared to switching from Bass Guitar to a cello, or from football to flag football. Python and Ruby have different syntaxes, but switching from one to the other is often a question of details. Even going back and forth with PHP is a similar thing. Going from Scheme to Common Lisp isn't as big of a leap as going from Prolog to C. I do believe Erlang (and many functional languages) fit this concept. If you've never worked with them before, you'll be surprised by persistent data structures, the absence of O(1) arrays, message passing semantics, share-nothing ideas, lack of global data, an environment without main loops (or any kind of loops), different ways to handle exceptions, a specific way to package and write applications, lack of namespaces, new syntax, atoms, pattern matching, linked-lists as strings, bit syntax, etc. Of course the first contact will suck if many of these concepts are foreign -- you have to learn from scratch when you likely were very proficient in many other languages. You will be slow, your code might be slow, and everything will look unfriendly. Obviously some languages are suffering from bad design, but knowing Erlang, I don't believe it's one of these. Hence my position on blaming lack of familiarity before syntax or any other reason. You have the right to disagree, but I would like to know your reasons for it if you do :)
- billmcneale 16y ago
  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.
awj 16y ago
Yeah, that's not the tone I got from this at all. There are aspects of Erlang that can be hard to get used to, but it really isn't fair to criticize the language for not conforming to your previous experience.
mechanical_fish 16y ago
Are you feeling a lack of breathless, relentlessly optimistic hype that whitewashes over all difficulties? Isn't that what the rest of the Internet is for? I prefer to be told about the difficult aspects of my tools in advance, rather than having to discover them myself via hours of trial and error.

Wow, this is an endless list of apologetic statements trying to paper over Erlang's many deficiencies. "Your first contact will suck but it's not Erlang's fault, it's yours". Way to motivate.

mononcqc 16y ago

Bicycles have training wheels to get you going. Erlang doesn't. It might be hard and require effort. I don't know how you learn new things, but it's generally taking me lots of effort: math, sports, music, etc. They're all hard when you first begin. I remember I couldn't ever do anything good on a bass guitar (I started learning with a terrible sense of rhythm, not being able to clap on a 4/4 beat). I thought that music was just too hard, that the notation was too complex and obtuse for the sake of it, that improvising and jamming took some natural skill to get. It doesn't. All it takes is work, lots of it. It's hard because it's different and not something you pick up easily without prior experience. And even once I learned how to play bass (and have been for years now), I can't play drums for shit because it requires an entirely different way to think about music, notation and synchronism. You have to get in a different mindset when you switch instruments, or even just bands. As for sports, mastery takes years. Of course someone in a good physical condition will pick up some of them with more ease than someone not used to many sports, but if you're a trained ice hockey player, the skillset you learn won't apply with the same ease for baseball or basketball when compared to roller hockey or field hockey. You have to go back to some basics. Re-learn how to position yourself, new strategies, discover muscles you hadn't trained before. I see learning new programming languages as something somewhat related -- Languages can do their best to be friendly, but when the concepts behind them just vary wildly (see Prolog vs. C), you'll likely hit a wall. And it will not be the language's fault, but a question of you working hard enough to grasp it. Many languages have similar concepts and could be compared to switching from Bass Guitar to a cello, or from football to flag football. Python and Ruby have different syntaxes, but switching from one to the other is often a question of details. Even going back and forth with PHP is a similar thing. Going from Scheme to Common Lisp isn't as big of a leap as going from Prolog to C. I do believe Erlang (and many functional languages) fit this concept. If you've never worked with them before, you'll be surprised by persistent data structures, the absence of O(1) arrays, message passing semantics, share-nothing ideas, lack of global data, an environment without main loops (or any kind of loops), different ways to handle exceptions, a specific way to package and write applications, lack of namespaces, new syntax, atoms, pattern matching, linked-lists as strings, bit syntax, etc. Of course the first contact will suck if many of these concepts are foreign -- you have to learn from scratch when you likely were very proficient in many other languages. You will be slow, your code might be slow, and everything will look unfriendly. Obviously some languages are suffering from bad design, but knowing Erlang, I don't believe it's one of these. Hence my position on blaming lack of familiarity before syntax or any other reason. You have the right to disagree, but I would like to know your reasons for it if you do :)

billmcneale 16y ago
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.

awj 16y ago

Yeah, that's not the tone I got from this at all. There are aspects of Erlang that can be hard to get used to, but it really isn't fair to criticize the language for not conforming to your previous experience.

mechanical_fish 16y ago

Are you feeling a lack of breathless, relentlessly optimistic hype that whitewashes over all difficulties? Isn't that what the rest of the Internet is for? I prefer to be told about the difficult aspects of my tools in advance, rather than having to discover them myself via hours of trial and error.