Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

I'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.)

    > 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:

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

Neither of those are valid examples of what I meant. In the first, the . is not the function terminator, it's the floating point separator. Same ASCII character, different semantic token. In the second, the comma is not the statement separator, it's the value separator. Again, same ASCII character, different semantic token.

The question is, can you produce a situation in which ; . , are interchangable and valid in their capacity as statement separators.

My compliments for trying though, as I'm aware this smells like goalpost hiking and I do want to be complimentary about what you did. If you read my post again, though, I think it will become clear that this is what I meant all along, but I agree this superficially looks like I'm trying to cheat.

> they are never ambiguous in the grammar

I'm building a grammar for a sleeker Erlang here [1], and it tries to prove just that.

[1] https://github.com/fenollp/kju/blob/master/grammar/Kju.g4

Luckily, 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.

I'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.

> 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-...

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.

Reply on news.ycombinator.com