5 ms·

On Erlang's Syntax

49 points by chops 15y ago

waffle_ss 15y 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 https://github.com/josevalim/elixir [1]: http://reia-lang.org/ http://reia-lang.org/ (abandoned; author points user to Elixir now)
- peerst 15y 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.
  - davidw 15y 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.
    - tlack 15y ago
      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)
      - sausagefeet 15y ago
        In C++, yes.
      - davidw 15y ago
        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.
  - signa11 15y ago
    > Syntax is not as important at all. syntax is a language's UI, thoughtful, clean and consistent design matters...
  - deleted 15y ago
    [deleted]
  - waffle_ss 15y 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 http://en.wikipedia.org/wiki/Homoiconic
- waffle_ss 15y 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/530d24dcb173148da2bb5afd79a631aeb1defe75/README.md https://github.com/josevalim/elixir/blob/530d24dcb173148da2b...
- sausagefeet 15y 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 15y 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_ 15y ago
tldr - The user simply reads , as 'and', ; as 'or' and . as being done.
- RichClaxton 15y ago
  That is a really nice summation.
- cpeterso 15y 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.
  - sausagefeet 15y 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.
    - cpeterso 15y ago
      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..
gurraman 15y 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 15y ago
most of it is beautiful <3
jeff_5nines 15y 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 15y ago
Learn Prolog first and it will all make sense.
chops 15y 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 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.

49 points by chops 15y 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 https://github.com/josevalim/elixir [1]: http://reia-lang.org/ http://reia-lang.org/ (abandoned; author points user to Elixir now)

peerst 15y 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.
- davidw 15y 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.
  - tlack 15y ago
    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)
    - sausagefeet 15y ago
      In C++, yes.
    - davidw 15y ago
      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.
- signa11 15y ago
  > Syntax is not as important at all. syntax is a language's UI, thoughtful, clean and consistent design matters...
- deleted 15y ago
  [deleted]
- waffle_ss 15y 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 http://en.wikipedia.org/wiki/Homoiconic
waffle_ss 15y 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/530d24dcb173148da2bb5afd79a631aeb1defe75/README.md https://github.com/josevalim/elixir/blob/530d24dcb173148da2b...
sausagefeet 15y 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 15y 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_ 15y ago

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

RichClaxton 15y ago
That is a really nice summation.
cpeterso 15y 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.
- sausagefeet 15y 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.
  - cpeterso 15y ago
    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..

gurraman 15y 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 15y ago

most of it is beautiful <3

jeff_5nines 15y 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 15y ago

Learn Prolog first and it will all make sense.

chops 15y 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 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.