4 ms·
And now, you can even have Erlang without the syntax, a la Elixir. But as a novice, I do not understand people whining and whinging about syntax in language X
by 616c 12y ago
And now, you can even have Erlang without the syntax, a la Elixir.
But as a novice, I do not understand people whining and whinging about syntax in language X or Y. Every language makes choices, and lots of those choices are emphasized by focusing/adapting the syntax to doing those things well. In each language that will be different, and that is the beauty of the diversity.
I cannot image Python without Python ranges, yields, and looping constructs. I cannot imagine Ruby without do blocks and the class structure and sigils and how really Rubinesque (this is a joke) code is for DSLs.
I like what the author of the OP did hear: if you complain the language syntax is ugly, perhaps you do not really see the perspective of the language creator quite yet. This explains how I struggled with different languages I studied in school (C++, then Perl, then Python) and even ones I work with which I hate (VBScript, Windows batch), because even those have logic to them when you keep the goals in the forefront of your mind.
- untothebreach 12y agoI like Elixir more for the consistent APIs, better Strings, and metaprogramming. I don't mind Erlang, but the more I used it, the more I felt the pain of those other issues.
- rdtsc 12y agoThat's great. Use whatever works for you, make you more productive and happy. It is good to have a choice. I feel JVM has been getting newcomers from Clojure and Scala communities. Erlang is doing that too.
- jerf 12y agoI've never proved this formally, but one of the big problems with the Erlang syntax is that it has comma, semicolon, and period as distinct separators, despite the fact that as far as I can tell, they are never ambiguous in the grammar. I've never been able to construct a series of tokens in which the meaning changes based on which of those you use, and it's legal either way. If you can, please, by all means show me (no sarcasm, I really would be intrigued to see it), but I bet it won't be commonly found in the wild either. Beyond that, most of my annoyances are not technically syntax, but I gotta tell you that the above really is a big problem for newbies, and the annoyance never goes away even after you know what you're doing since it always inhibits moving code around. But as Elixir shows, the annoyances really are mostly with Erlang-the-language, not the implementation. Personally I sort of hope the success of Elixir helps the Erlang team take a fresh look at the Erlang language... there are some fixups one could do to Erlang to make it less annoying, too, and I think it could be all done compatibly. (A syntax to import functions from a module... a "match & rebind" operator... unifying the , . ; operators... something to clean up record manipulation... honestly, it wouldn't take much to really polish up Erlang and make a lot of the recurring klunkiness go away, that list alone would have cleaned up huge swathes of my code. A real string type would help too, even if were exactly the same as a binary but with a different type for matching purposes for all I care, because that would clean up a lot of interop issues I had.)
- kungfooguru 12y agoLuckily, for me, most of us who use Erlang do not want the changes you mention in your list :). Except records, which are a pain to nest. Unifying , . ; is the most baffling one to me that I hear all the time. But I'm glad Elixir exists and it is getting more people using BEAM.
- jerf 12y agoI've used Erlang for about 6 years now. The thing is, I haven't used only Erlang for 6 years, so I've never forced myself into cognitive dissonance about the ways in which other languages do things better, or worse, simply failed to be exposed to them. It's a bit sad to see the Erlang community start wearing the embracing its flaws as a badge of pride. It's a short-term solution, but long term it leads to community death. I guess I'm getting out of that world none too soon. There are reasons why it has not become more popular than it has, and if the community is going to chose to embrace them rather than deal with them, well, more power to them. You can do it without me. Which I do not mention as if that's some sort of major threat or anything, because of course it's not. Or if they choose to run around claiming that 6 years of experience just isn't enough to get Erlang, well, more power to you too.
- davidw 12y ago> embracing its flaws as a badge of pride This is something you start seeing here and there when you try and observe advocacy as a neutral observer. I saw the same thing with Tcl a lot: http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-... You have to be willing to confront the ugly truth sometimes. Of course, sometimes that means "yeah, that sucks, but changing it is more pain than it's worth", which does not fix the problem, but is at least honest. I agree with jerf about the "ant turd tokens": they're hard to see, and irritating when you rearrange code. But the rest of Erlang has lots of good stuff, so I just deal with it.
- matthiasl 12y ago> I've never been able to construct a series of tokens in > which the meaning changes based on which of those you > use, and it's legal either way. Here's a series of tokens where switching comma to full stop means different things and both are legal: 1> 1,0. 0 2> 1.0. 1.0 In the first line, the comma is an expression separator. Attempting to use a full stop instead results in a floating point number. f(X, Y) when X, Y -> ok. g(X, Y) when X; Y -> ok. In this case, the guard in f is turned into a guard sequence by switching a comma to a semicolon. Both are legal. Matt