What did you first think of the Erlang syntax

Chat / Discussions
,
21

Don’t forget to mention and/or vs andalso/orelse. Not an inconsistency, but I think it is something that may raise an eyebrow or two for the newcomers.

Why on earth are there two of each? To a newcomer, it might at first appear that they are really equivalent, that you can either use and /or but have to parenthesize the arguments, or use the unwieldy andalso/orelse (which take a while to “stick”, too) and omit the parentheses.

Later they learn that andalso/orelse are short-circuiting and and/or are not, and may even realize that that has some consequences when using them to end a recursion loop. But who on earth even needs non-short-circuiting operators, why do they even exist?

(Today, after it was explained to me one day, I know that and/or are really functions, erlang:'and'/erlang:'or', meaning their arguments have to be evaluated, both of them, before passing them in, whereas andalso/orelse are not functions but language constructs.)

6 Likes
22

and and or are the oldest ones, perhaps already present in OTP R1.

That is probably why Richard Carlsson and the HiPE group suggested that Erlang needed andalso/orelse. I don’t remember in which release we added them. Obviously we could not remove and and or.

In addition to those more obvious boolean operators, there are also two language constructs that are allowed at the top-level of guards. One is , which is an AND operation (in a guard, it is not noticeable whether it is short-circuiting or not):

foo(A) when is_integer(A), A > 0 ->
    all_is_good.

Probably less well-known is ;, which behaves similar to orelse:

bar(A) when is_integer(A), A > 0; is_atom(A) ->
    all_is_good.

This is equivalent to:

bar(A) when is_integer(A), A > 0 ->
    all_is_good;
bar(A) when is_atom(A) ->
    all_is_good.

My own rules for which operators/functions to use are the following:

  • Never used and. (I have yet to come up with a real-world use case where I would need a strict AND in Erlang.)

  • In guards, use , and ; if possible. Otherwise use andalso/orelse.

  • In function bodies, use andalso and orelse.

  • Use or if you need a strict OR operation.

Use cases for a strict OR are rare, but not as rare as use cases for a strict AND. Here is one example I can think of:

foobar(A, B) when (A rem 8 =:= 0) or (B rem 8 =:= 0) ->
    at_least_one_integer_divisible_by_8.

That is, A and B must both be integers, and at least one of them must be a multiple of 8.

UPDATE: I wrote “short-cicuiting AND” when I meant “strict AND” in the paragraph where I recommended against using and’.

UPDATE: I wrote “short-circuiting OR” when I meant strict OR.

11 Likes
23

Already happening with EEP 49, erlang is likely soon to get:

commit_write(OpaqueData) ->
    maybe
        ok ?= disk_log:sync(OpaqueData#backup.file_desc),
        ok ?= disk_log:close(OpaqueData#backup.file_desc),
        ok ?= file:rename(OpaqueData#backup.tmp_file, OpaqueData#backup.file),
        {ok, OpaqueData#backup.file}
    end.

I sure wouldn’t mind both a |> and a <| being added, with different priorities (<| binding tighter) basically defined like:

`|>`(value, func) -> func(value)
`<|`(func, value) -> func(value)

Then could use it like:

something(blah) ->
  blah
  |> another_function(42) <| a_trailing_thing() <| perhaps_another(6.28)
  |> that_output_goes_here(with, these, args)

Which would basically execute like:

that_output_goes_here(
  another_function(blah, 42, a_trailing_thing(), perhaps_another(6.28)) % Depending on how you want to bind `<|` I guess
  with,
  these,
  args
)

Yeah there is some inconsistency with the (very old) standard library, perhaps it’s about time to make a V2 that makes everything consistent? Mostly delegates to the older/current v1 version but renames as necessary?

6 Likes
24

Yes, I just saw that EEP-49 is moving forward, very exciting!

2 Likes
25

There is a difference between ; and orelse in the case of errors in guards. The orelse means just ONE guard so if you get an error in the LHS then the whole guard fails, while ; actually gives you 2 guards so an error in the LHS just means that the RHS guard will be tested.

5 Likes
26

One reason for this inconsistency is that the language and libraries evolved and ideas and thoughts HOW things should look changed along the way. And when we got (legitimate) complaints we did suggest “ok, we will fix it up” but then then we got must louder screams saying “NO NO don’t change it as it will crash our system”. So they remained. :smile:

5 Likes
27

Erlang needs a Rust-like backwards-incompatible versioning system that allows everything to work together regardless, definitely doable. ^.^

1 Like
28

I can definitely feel that :expressionless:

1 Like
29

Funny story time! At least, I always think it’s funny retrospect :

My first encounter with Erlang was in 2007 I believe. I had wanted to setup ejabberd to provide a secure IM for the company I was at. I don’t remember why, but I had to get into the source code to make a hack or two for what I needed. At the time I was all about Perl. Upon opening up an erl source file in my editor my immediate thought was “And they say Perl is ugly!” :rofl: :see_no_evil:

Now, I knew at the time Erlang was powerful, I didn’t quite grasp how powerful, but none the less knew it none the less. I dismissed the language because of the syntax! How young and foolish I was! Can you believe that? It’s like dismissing a rolls Royce because you don’t like the paint job! Or rather, the paint job isn’t “familar” to you.

I then moved on to a few OO languages thinking, these sleek looking languages would solve all the problems I ever faced with Perl! Wrong again!

Then along came Elixir, this provided what I needed to at the time to get into functional programming, I still thought Erlang syntax was odd and assumed I’d never be interested. Wrong again!

I had become more and more interested in Erlang and in languages period. I happened upon an article written by @rvirding on syntax, this got me to thinking, I started to think more about why something is the way it is in language and more importantly perhaps, why it isn’t. I then ended up on an article about syntax by Fred Hebert as well. Things just kept clicking.

I looked at some Erlang again and what I saw was quite different from what I had saw a few years before and definitely over a decade ago. What I saw and came to appreciate was simplicity. What’s more, I realized it’s only syntax. That’s it. Bottom line. I love Erlang syntax now. There’s always a thing I wish wasn’t like this or like that, but I feel that way in every single language I’ve ever tried or used in anger. What’s more I’ve sat down a few times and tried to think long and hard about how I could really improve upon it without doing away with that simplicity… I haven’t been able to yet :slight_smile: Every time I sat down to do this, I just ended up with Erlang, and probably a worse version (syntactically).

Now I think Perl is ugly at least in comparison to Erlang :slight_smile:

I suppose the moral of the story is :

  1. Look beyond the wallflowers.
  2. Everything is strange until it’s not.
  3. Beware of familiarity.
  4. Relish simplicity.
  5. Let go and learn.
8 Likes
30

This right here. Any new syntax will take a bit of time getting used to, but after that initial hurdle syntax will be the least of your problems anyway.

One of the most tired lines often repeated by self-appointed Elixir evangelists (people who most likely never worked with it professionally but for some reason want to start holy wars) is that the syntax is “much more familiar than Erlang’s”. It’s such a weird and circular argument. Sure, it looks familiar, but only if you’re already familiar with it!

6 Likes
31

Yeah, I think you’ll find folks like that in any community, I don’t think it’s specific to Elixir, but I have seen it, so I understand it, in fact I’ve battled it! I still do!

I’ve also seen the same with Erlangers from time to time, though the arguments change a little bit on the surface, they’re still some what the same.

The truth of the matter I believe is we’ve forgotten what this is all supposed to be about and it most certainly is not about making code look pretty. That’s a bonus if you can make that happen, if you’re lucky. We’re so irrational, zealous, and lost.

I so wish Joe was around so I could talk to him more about the make it beautiful part of his classic saying : Make it work, then make it beautiful and if you really have to, make it fast… I’ve always felt that beautiful part is WAY deeper than aesthetics. Don’t get me wrong, symmetry matters at a certain point, but simple in and of itself is beautiful and is IMHO way more important :slight_smile:

The battle I constantly face, no matter whom I’m working with : We spend way too much time focusing on how things look vs how they work and this leads to bug ridden software and makes the world a worse place to live in.

There’s definitely one place I never see this though, in Erlang/OTP itself :slight_smile: There’s true pragmatism going on, look at the @bjorng and OTP’s decision on the assignment op (if you will) that will be used for the implementation of EEP-49. Some of us thought <- would be nicer, and maybe so… but they chose simple and I appreciate that so much. True pragmatism. :clap: :clap: :clap:

5 Likes
32

Yeah, definitely. The poster people of this phenomenon is probably the RIIR (Rewrite It In Rust) crew. People who actually write Rust or Elixir are probably too busy writing awesome new programs instead of arguing in Youtube comments why do is much better than ->. Once one gets over the initial threshold much like you did, it matters very little for actual problem solving anyway.

5 Likes
33

It’s a part of my work that I really enjoy, creating the simplest and thus most elegant solution for a problem. It’s an artistic and creative process :slight_smile:

6 Likes
34

IMAO

It’s just syntax, RTFM and get over it! By now I know quite few languages with different syntaxes and that is seldom the major problem of using them, it’s the semantics and how you build systems with them where the real problems lie. They are the difficult bits.

Simple consistent syntax is always a big win. My KICASS principle (Keep It Consistent And Simple Stupid). :smile:

One benefit I have found is that having different syntaxes makes it much easier to keep track of which language you are using and how it works and not get mixed up. Erlang is Erlang and C is C and never the twain shall meet.

11 Likes
35

It was actually Robert’s comment similar to the above (on Devtalk) that prompted me to get Programming Erlang and to start reading it :lol:

Personally I am reserving judgement for now about the Erlang syntax (I still haven’t finished the book) but wanted to quickly comment on this:

Chill Robin - it’s just a language :lol:

People are allowed to have preferences, and people are allowed to value some things over others. That really is ok. If syntax doesn’t matter to you, that’s awesome… but it does matter to some people… and that’s cool too. It would be a boring world if we all thought the same or were carbon copies of each other :upside_down_face:

Personally I think syntax is just one aspect of something people usually lump together - and that is the overall feel of a language. Syntax usually goes hand in hand with other things, like how natural a language feels or how effortless it is working with it.

Ruby is a prime example here, for many people it just ‘feels’ right. Not only does it (for those of us who love it) look beautiful, but it just feels so natural when using it - where things you think might work, usually do. It’s kind of hard to explain unless you’ve used the language yourself but it’s something Rubyists often say is missing from other languages.

So generally I don’t think syntax preference is just based on how syntax looks - it’s usually much more about how something works, and how natural it feels (even if that means how natural it feels to that person depending on how they’re wired).

4 Likes
36

I loved it at first sight. My wife told me that I got some strange tastes but she married me.
And as I said on devtalk, the talk of Todd Resudek which claims it’s time to embrace Erlang, end comfort me down this path.

4 Likes
37

I hope I didn’t come across as unchill, I’m not hating on Elixir or Rust or any other language, I think they all have their merit. My point was exactly that, “it’s just a language”. A bit of syntax that won’t take more than a couple of hours to learn for pretty much any language, and that matters very little for the actual problem solving at the end of the day.

4 Likes
38

When I first saw it I thought “oooh nice, it’s so concise! A few symbols I’m not immediately grokking but I get the gist”

3 Likes
39

As one teaching Erlang for more than 10 years now, I chose the language because it is simple and rather small. I checked at the time also Haskel, Scala, Go (was still infant), and Clojure. I never regretted for choosing Erlang.
From the responses of the students during the years, at first it looks “odd” to them, but later, when they are more familiar with functional programming concepts in general, and Erlang as a language, they really appreciate its simplicity and elegance. Of course there are issues to correct and change, but the overall experience of a first time user is positive here.

4 Likes
40

You did a bit unfortunately Robin (it’s best to avoid making any kind of remark that might be construed as disparaging) but yes, I would certainly agree with the notion that unless we created it, languages are more or less inanimate objects (so definitely not worth getting personal over) and that views about things like syntax are very subjective and will vary from person to person - but that’s not to say we shouldn’t discuss such topics.

We know syntax is of significance here because we often hear people say that it put them off or scared them away from Erlang - and so it probably wouldn’t hurt to try to understand why that might be because it is (or appears to be) such a common occurrence. Normally I would just argue that it’s different strokes for different folks, but if it’s something that impedes adoption to the extent that we think it might be, then it could be worth exploring or, as mentioned below, trying to dispel - even if that is through conversations like this.

Hence I was hoping this thread might achieve a number of things:

  • Show people that others felt similarly to begin with but later found they liked it
  • Show people that others liked it from the get go
  • Show people that syntax doesn’t really matter to some
  • Show people the reasoning behind some of the design choices
  • Maybe help identify specific areas of confusion
  • Maybe help highlight ways to help with some of the above

A bit of syntax that won’t take more than a couple of hours to learn for pretty much any language, and that matters very little for the actual problem solving at the end of the day.

I think this is true when either you don’t really care/mind syntax or when you don’t have much choice - but what if you do? What if there are two languages that are otherwise equal but you prefer the syntax and how one language feels over the other? What if there’s a big enough difference in that feeling or that it’s so commonly held that one language continually loses out to the other?

I think for a long time the benefits of Erlang helped people push past any issues they had with syntax. Thankfully, a lot of people have been saying that once they did that they actually really liked the syntax - so hopefully we’ll hear more stories like that in this thread! :003:

But it still could be worth exploring, and I imagine it has probably been discussed many times before in the Erlang community - but a fresh pair of eyes is never a bad thing and as I mentioned in my previous post, it may not just be syntax - it could be a whole range of interconnected things. Of course it’s totally up to the core team and members of the community to decide whether it’s something that deserves time and effort… but if the goal is to grow the Erlang userbase, then I think things like this are always worth discussing and none of these topics should, if within reason, be off-limits :blush:

4 Likes