On Erlang's Syntax

by chops • 15 years ago

49 21 15 years ago

waffle_ss3• 15 years ago

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• 15 years ago

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.

davidw2• 15 years ago

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.

signa11• 15 years ago

> Syntax is not as important at all.

syntax is a language's UI, thoughtful, clean and consistent design matters...

waffle_ss3• 15 years ago

Well according to the Elixir docs it does make a bit of difference in terms of homoiconicity[0] (that famous Lisp property of code=data, data=code), which makes meta-programming easier.

Also, would you rather code brainfuck or C using pointers (both being semantically identical)? ;)

[0] http://en.wikipedia.org/wiki/Homoiconic

waffle_ss3• 15 years ago

I just realized that the Elixir README file has been trimmed quite a bit. There used to be a good overview of the language there. Here is a commit that has a lot more info on it: https://github.com/josevalim/elixir/blob/530d24dcb173148da2b...

sausagefeet3• 15 years ago

Erlang syntax might look weird at first, if coming from Ruby/Python, but I think you're giving up too early. Yes, Erlang looks different, but after an hour of playing with it you come to realize one important thing: the syntax is weird but there is an incredibly small amount. Relative to languages like Python and Java, Erlang has a small syntactic footprint. Relative to C++ you need a logarithmic graph.

gordonguthrie• 15 years ago

I came to Erlang from Ruby and it did look wierd. But now after 7 years Ruby looks odd :)

I really struggle just reading Ruby now - and it was my main language for a couple of years.

Writing Ruby - nae chance...

pixie_• 15 years ago

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

RichClaxton• 15 years ago

That is a really nice summation.

cpeterso2• 15 years ago

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.

sausagefeet3• 15 years ago

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.

gurraman• 15 years ago

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.

tjholowaychuk• 15 years ago

most of it is beautiful <3

jeff_5nines• 15 years ago

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

dugmartin• 15 years ago

Learn Prolog first and it will all make sense.

chops• 15 years ago

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.

On Erlang's Syntax

Related Stories