4 ms·

"People keep telling me it's hard" Shouldn't that be enough to let you know that people at least don't find it to be intuitive?

by crusso 7y ago

Jtsummers 7y ago
No, because no one has ever explained how it's hard. They just keep repeating that refrain, and to date I haven't heard it from someone who spent more than a day with the language or gave it any serious consideration. If people can enumerate the problems with the language (like I've seen or done for other languages), then I'll entertain the complaint. So far the closest thing to a real complaint has been about variables-not-being-variables (in the C, anything can change, sense). But this is 2020, mutable-by-default is a known bad idea so this is hardly novel or a challenge. The other reason I've heard is the lack of loops. If a professional programmer can't handle recursion, they need to go back to basics. I'm not trying to be mean with that one, but recursion is pretty easy.
- rukittenme 7y ago
  I agree with you. Erlang is not as hard as people make it out to be. However... Look at this piece of code: https://github.com/erlang/rebar3/blob/master/src/r3.erl#L32-L58 https://github.com/erlang/rebar3/blob/master/src/r3.erl#L32-... In this example the keyword "end" ends with "", ";", and "." all within 6 lines of each other. In this example the keyword "ok" ends with "" and ";". In this example `Self` "exclamation marks" `Ref`. All of this is easily understood with some experience but you have to admit that `erlang.send(Self, Ref)` is much more easily understood than some symbol that has to be googled. And consider this, a junior dev is going to be overwhelmed with all the syntactic sugar. They're just learning how to define and call functions. All of these issues matter if your goal is to on-board as many hobbyists and juniors as possible. (Which shouldn't be the goal of every language). I'm very happy with Erlang. I don't want it to change.
- Supermancho 7y ago
  I have written a few thousand lines of erlang over the years. > No, because no one has ever explained how it's hard. > recursion is pretty easy. uh, sure. Let's talk about syntactical problems. %% instead of // for comments because legacy+ =:= is === and /= is != , it's legacy+ Macros, atoms and functions are differentiated by context not syntax (?macros do have something). The capital letter variable name is basically an ever changing indicator. PHP $ or perl @ or some consistent indicator would be an improvement+ String handling is terrible, to this day and remember shell:strings(false) because legacy. Screw it, let's hide it in the gotchas of the manual and wait. Some BIFs are named poorly. eg apply instead of "dynamic_call". This is the correct way to look at branching decision syntax: if X < 0 -> negative ; X > 0 -> positive ; X == 0 -> zero end The language doesn't help us with this for no apparent reason, with semicolons almost universally ending up on the end of expressions (sometimes): if X < 0 -> negative; X > 0 -> positive; X == 0 -> zero end + The problems are obviously user hostile and elixir and I magically overlapped. Anything with a trailing + was addressed in elixir which I did not know for sure before writing this list The entire Erlang community response is basically the same (mailing list onward). Any attack on the syntax is either regarded as immaturity or whataboutism so people have just stopped talking about it like when someone gets an unfortunate face tattoo. The problems remain.
- dnautics 7y ago
  I find erlang to be harder to read. Part of that is possibly because it encourages passing modules in non-intuitive way. If you want an example, try spending a day figuring out why erlang's TFTP module won't support PXE booting. You'll give up after about 2 hours because the code shuffles in dependencies between multiple modules. Basically its problems, may be more cultural than syntatical, in that, it grew up in the C era, where you did things the C way. And now, it's 2020. Software development has changed. We have parsers that can make reasonable decisions about when and where statements end (and I don't mean javascript). Documentation is easier to make pretty, bad architecture models (like FactoryFactoryFactories) are understood and we know why they're bad. Code editors are smarter, and little things like "now you have a directory tree on the side of your editor" make a difference to how you're going to architect and organize your code for ergonomics. And Language theory things like "why you might want to not have a string preprocessor" are better understood. In short, time has moved on, and in some ways, erlang hasn't. Luckily, the virtual machine is still fantastic (and getting better).
lostcolony 7y ago
So I noticed a bunch of responses seemed to be missing something you said - "at least don't find it to be intuitive" I will 100% agree it's not intuitive. That said, I think only languages that behave like other languages you already know seem intuitive; the first time you were exposed to (your first language) it wasn't intuitive either. You had to _learn_ it. Learn the concepts, learn the syntax. And I think that's what hurts when coming to Erlang. Most people doing so aren't used to language flavors other than the Algol-C heritage. Certainly, they're not used to the Prolog heritage Erlang is coming from, nor, probably, functional languages, and certainly not actor based ones. It's not intuitive at all; that said, I also don't think it's 'hard'. The language and grammar is quite small and understandable, even if parts of it are things I and many others find faults in. It's just by the time most people encounter it, they aren't used to having to _learn_ a language, but instead are used to being able to just kinda intuit a lot by just looking at it.

"People keep telling me it's hard" Shouldn't that be enough to let you know that people at least don't find it to be intuitive?

by crusso 7y ago

"People keep telling me it's hard" Shouldn't that be enough to let you know that people at least don't find it to be intuitive?

Jtsummers 7y ago

No, because no one has ever explained how it's hard. They just keep repeating that refrain, and to date I haven't heard it from someone who spent more than a day with the language or gave it any serious consideration. If people can enumerate the problems with the language (like I've seen or done for other languages), then I'll entertain the complaint. So far the closest thing to a real complaint has been about variables-not-being-variables (in the C, anything can change, sense). But this is 2020, mutable-by-default is a known bad idea so this is hardly novel or a challenge. The other reason I've heard is the lack of loops. If a professional programmer can't handle recursion, they need to go back to basics. I'm not trying to be mean with that one, but recursion is pretty easy.

rukittenme 7y ago
I agree with you. Erlang is not as hard as people make it out to be. However... Look at this piece of code: https://github.com/erlang/rebar3/blob/master/src/r3.erl#L32-L58 https://github.com/erlang/rebar3/blob/master/src/r3.erl#L32-... In this example the keyword "end" ends with "", ";", and "." all within 6 lines of each other. In this example the keyword "ok" ends with "" and ";". In this example `Self` "exclamation marks" `Ref`. All of this is easily understood with some experience but you have to admit that `erlang.send(Self, Ref)` is much more easily understood than some symbol that has to be googled. And consider this, a junior dev is going to be overwhelmed with all the syntactic sugar. They're just learning how to define and call functions. All of these issues matter if your goal is to on-board as many hobbyists and juniors as possible. (Which shouldn't be the goal of every language). I'm very happy with Erlang. I don't want it to change.
Supermancho 7y ago
I have written a few thousand lines of erlang over the years. > No, because no one has ever explained how it's hard. > recursion is pretty easy. uh, sure. Let's talk about syntactical problems. %% instead of // for comments because legacy+ =:= is === and /= is != , it's legacy+ Macros, atoms and functions are differentiated by context not syntax (?macros do have something). The capital letter variable name is basically an ever changing indicator. PHP $ or perl @ or some consistent indicator would be an improvement+ String handling is terrible, to this day and remember shell:strings(false) because legacy. Screw it, let's hide it in the gotchas of the manual and wait. Some BIFs are named poorly. eg apply instead of "dynamic_call". This is the correct way to look at branching decision syntax: if X < 0 -> negative ; X > 0 -> positive ; X == 0 -> zero end The language doesn't help us with this for no apparent reason, with semicolons almost universally ending up on the end of expressions (sometimes): if X < 0 -> negative; X > 0 -> positive; X == 0 -> zero end + The problems are obviously user hostile and elixir and I magically overlapped. Anything with a trailing + was addressed in elixir which I did not know for sure before writing this list The entire Erlang community response is basically the same (mailing list onward). Any attack on the syntax is either regarded as immaturity or whataboutism so people have just stopped talking about it like when someone gets an unfortunate face tattoo. The problems remain.
dnautics 7y ago
I find erlang to be harder to read. Part of that is possibly because it encourages passing modules in non-intuitive way. If you want an example, try spending a day figuring out why erlang's TFTP module won't support PXE booting. You'll give up after about 2 hours because the code shuffles in dependencies between multiple modules. Basically its problems, may be more cultural than syntatical, in that, it grew up in the C era, where you did things the C way. And now, it's 2020. Software development has changed. We have parsers that can make reasonable decisions about when and where statements end (and I don't mean javascript). Documentation is easier to make pretty, bad architecture models (like FactoryFactoryFactories) are understood and we know why they're bad. Code editors are smarter, and little things like "now you have a directory tree on the side of your editor" make a difference to how you're going to architect and organize your code for ergonomics. And Language theory things like "why you might want to not have a string preprocessor" are better understood. In short, time has moved on, and in some ways, erlang hasn't. Luckily, the virtual machine is still fantastic (and getting better).

lostcolony 7y ago

So I noticed a bunch of responses seemed to be missing something you said - "at least don't find it to be intuitive" I will 100% agree it's not intuitive. That said, I think only languages that behave like other languages you already know seem intuitive; the first time you were exposed to (your first language) it wasn't intuitive either. You had to _learn_ it. Learn the concepts, learn the syntax. And I think that's what hurts when coming to Erlang. Most people doing so aren't used to language flavors other than the Algol-C heritage. Certainly, they're not used to the Prolog heritage Erlang is coming from, nor, probably, functional languages, and certainly not actor based ones. It's not intuitive at all; that said, I also don't think it's 'hard'. The language and grammar is quite small and understandable, even if parts of it are things I and many others find faults in. It's just by the time most people encounter it, they aren't used to having to _learn_ a language, but instead are used to being able to just kinda intuit a lot by just looking at it.