

On Erlang's Syntax - chops
http://ferd.ca/on-erlang-s-syntax.html

======
chops
Note that while I generally like the Erlang syntax, there's one main issue
where syntax quirks come back to bite me: the combination of Erlang records
with a missed line ending. This topic comes up on occasion on the mailing list
and apparently it's a side effect of a change that was made to make Erlang
records a little easier to work with.

In short, if you've got two records in a list, and forget to end the first one
with the comma line ending, the behavior becomes a bit unpredictable.

    
    
      [
       #myrecord{
        field1="whatever",
        field2=123
       }
       #myrecord{
        field1="booyah",
        field3=3.14
       }
      ].
    

That statement would mysteriously return a list with a single element:

    
    
      [ #myrecord{field1="booyah", field2=123, field3=3.14 } ]
    

And all because of the missed comma after the first #myrecord { }.

What's happening can be visualized by the (sort of) equivalent version here:

    
    
      R1 = #myrecord{
       field1="whatever",
       field2=123
      },
      [
       R1
       #myrecord{
        field1="booyah",
        field2=3.14
       }
      ].
       

So you can see that the second #myrecord is overwriting the values in R1,
since you can do syntax like R1#myrecord{ ... } to take the values of R1, and
overwrite them with whatever you need to.

The reason that happens is due to a compiler change a while back to make
record syntax no longer require being wrapped in parens. This is due to having
records with values in them being records, and it makes it easier to access
those records.

For example:

    
    
      Mybook#book.author#author.name
    

Which is an OOP language's equivalent of something like:

    
    
      Mybook.author.name
    

This previously used to be required to be written like this (correct me if I'm
wrong, this syntax is before my time):

    
    
      ((Mybook#book.author)#author.name).
    

Which removed ambiguity. Errors like my first example then would be caught by
the runtime if records were written in the "old" style:

    
    
      [
       (#myrecord{
        field1="whatever",
        field2=123
       })
       (#myrecord{
        field1="booyah",
        field3=3.14
       })
      ].
    

Will generate an invalid function error (still not a great error, but it makes
sense in this regard.

My hope is that this class of error caused by the syntax will be somewhat
minimized if Ericcson decides to merge the erlson[1] project into an official
release of Erlang, replacing the somewhat clunky record syntax with something
a little more "modern".

[1] <https://github.com/alavrik/erlson> \- An object notation for Erlang, but
which in order to be a decent record replacement will need to support pattern
matching.

------
gurraman
I used to dislike the use of different punctuation characters as they make it
"difficult" to re-arrange code. I've, however, grown to love them as they are
very explicit and gives the reader a good indication on what will happen next
(f. ex. an alternate function clause).

All in all, I pretty much love Erlang's syntax. It's the perfect mix of
readability, terseness and structure; and it has that cozy nerd-air about it,
the one that makes you want to sit up all night dishing out code.

------
waffle_ss
Coming from Ruby, I was pretty excited to see Elixir[0] (and before that,
Reia[1]), a language that runs on the Erlang VM but is more approachable for
me syntactically and that adds some interesting features. I think it's worth
checking out for anyone who wants to 'learn them some Erlang' over winter
break.

[0]: <https://github.com/josevalim/elixir>

[1]: <http://reia-lang.org/> (abandoned; author points user to Elixir now)

~~~
peerst
Syntax is not as important at all.

Semantics is important.

If you think about a piece of code you should have AST's in your mind anyway
-- not strings of characters.

~~~
davidw
Disagree completely: the language is there to make programming the computer
easier for me, the human. If I have to parse it in my head, it has failed at
that, at least for 'everyday use'.

In particular, one place where Erlang gets in your way is if you swap two
lines of code, there's a good chance you'll have to check the "ant turd token"
at the end of the line, and change it.

It's certainly not an insurmountable difficulty, but it is an annoyance.

~~~
tlack
Honest question: do you find yourself really thinking about a languages syntax
after you've spent 40-50 hours coding in it? To me it kind of fades into the
background, becomes hard wired in my brain. (I'm not suggesting I'm an awesome
coder or anything of course)

~~~
davidw
Mostly, yes, but the line endings in Erlang fail the "don't make me think"
test. They make you stop and look and make sure everything is in the right
place.

It's not _that_ big a deal, and the language has lots of other great
qualities, so I wouldn't get too hung up on it, but it's not fair to say it's
not irritating.

------
pixie_
tldr - The user simply reads , as 'and', ; as 'or' and . as being done.

~~~
cpeterso
This syntax isn't any less weird than C's _& &_, _||_ , and _;_ operators. :)

Do any C/C++ developers #include<iso646.h> so they can use _and_ , _or_ , and
_not_ as friendly operator names? This seems like a simple step for prettier C
code, but I have never seen it in practice.

~~~
sausagefeet
I've been writing C/C++ before and thought it would be nice to use those forms
of the operators, but having never ever seen C++ code that does I wonder if
I'm setting myself to be made fun of.

~~~
cpeterso
I guess it's a slippery slope. If people _#define and &&_ then someone else
will _#define then {_ and _#define endif }_. Everyone will have their own
silly dialect. In fact, that is not unlike the current state of C++ usage..

------
dugmartin
Learn Prolog first and it will all make sense.

------
jeff_5nines
I up'd this just because 1) I love me some Erlang 'Learn you some Erlang' and
2) I love to see Erlang entries on HN

------
tjholowaychuk
most of it is beautiful <3

