[ggregoire]

From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.

[agumonkey]

Completely logical. Java, C, PHP are said to be algol descendants. In two words: curly braces. JS wasn't supposed to but ended up curly because social trends are that strong. Now imagine JS function being the only thing you use, then that language users and designers evolving a syntax for typed js-like functions, rince repeat, you get ML, Haskell, Elm.

In time your brain realigns, depending on how much you appreciate the functional style or not.

[striking]

Not quite. ALGOL doesn't have curly braces, just BEGIN and END blocks.

  BEGIN
  FILE F (KIND=REMOTE);
  EBCDIC ARRAY E [0:11];
  REPLACE E BY "HELLO WORLD!";
  WHILE TRUE DO
    BEGIN
    WRITE (F, *, E);
    END;
  END.

I've heard it said that the languages you mentioned are inspired by C's syntax.

[agumonkey]

Wow, couldn't be more wrong. It's indeed C family (BCPL, B). Thanks a lot for the note.

[mikekchar]

Well, I wouldn't be so hard on yourself. IIRC (and I hope someone corrects me if I'm wrong), algol introduced block scoping. Whether you use BEGIN/END or {/} I think is a pretty minor point.

C has braces to introduce a new scope. The irony is that JS (until recently) didn't have block scope. It just has braces :-).

Now this is where it gets screwy. You are supposed to (but don't have to usually) add a semi-colon on the end of each statement in Javascript.

a = 52;

This has a semi colon because it is a statement. There is another construct called an expression. An expression is anything that can evaluate to a value. An statement can be an expression (the statement "a = 52;" is an example of that because it also evaluates to 52 and is thus an expression). But there are expressions that are not statements. Here is an example of an expression

(5 * 27)

It evaluates to a value, but doesn't do anything so it is not a statement. Usually in computer languages, if "statements" are actually expressions. So you can say

if (1>0) {"Yay"} else {"Boo"}

evaluates to a value ("Yay" in this case), but doesn't do anything in and of itself. The blocks in the braces may contain statements, but the if is an expression, not a statement. Note the lack of semi-colon. Again, presumably because it is an expression, not a statement.

You can try the above in Node and it will indeed return the value "Yay".

a = if(1>0) {"Yay"} else {"Nay"};

In this case the variable a should be assigned the value "Yay", because the if expression evaluates to a "Yay". For some strange reason (that I don't understand), Javascript (or at least Node, when I tried it) does not accept that. It gives you a syntax error. You can not use if "statements" as expressions in Javascript (which sucks quite a bit).

All of this to say that Javascript appears broken to me, no matter what geneology you assign to it :-D. I personally really like programming in JS (or actually CS), but it is a beast unto itself, I think.

I'd welcome comments illuminating this issue if I've made a mistake with the above! As I said, it's easy to do.

[agumonkey]

True but my algol mention was strongly on syntax not semantics (big part of algol contribution).

[fnovd]

>You can not use if "statements" as expressions in Javascript (which sucks quite a bit).

It does indeed, and it leads to some ugly code:

a = function() { if(1>0) { return "Yay" } else { return "Nay" } }()

[ziad-saab]

You can also write:

a = 1 > 0 ? "Yay" : "Nay"

[redtuesday]

Because I really like syntax like Haskell (the type signature is much clearer especially in generic code compared to Java or Scala etc. for example), I'm curious, what is so uncomfortable about the syntax?

[skybrian]

The lack of parentheses around function calls makes it hard for people not familiar with ML-style languages to tell where the function calls are and what the arguments are to each function call.

There is a wide variety of syntax among mainstream languages, but basic function calls are pretty much all the same.

Take a look at Reason [1] for an example of how a functional language (OCaml in this case) can be made more familiar.

[1] https://facebook.github.io/reason/

[eastWestMath]

Or maybe people could just become familiar with ML-style languages? The basic syntax shouldn't take more than an hour or two to pick up.

[skybrian]

Well sure, but you could say the same thing about Lisp.

[eastWestMath]

Well they're both the lambda calculus, Lisp just had parentheses.

[kazinator]

Does lambda calculus have character strings, structures, exceptions, symbols, mutable variables, quoting code as data, macros and three different kinds of object equality?

[ungzd]

Ruby has optional parentheses around function parameters (usually it's recommended to avoid parentheses if possible). Shells have no parentheses around command arguments. These languages are mainstream and no one complains about this.

[kazinator]

Of course, if we adjust "mainstream" so that it refers to that set of languages which have pass-by-value, strictly evaluated arguments, with no implicit currying, then your point is nearly self-evident. :)

[redtuesday]

Yes, I agree, that took me also some time to get used to when I dabbled with Haskell and I looked at more complex programs.

[salimmadjd]

when I spoke with Evan (you can usually meet him at the Elm SF meetup) I believe he said Elm was inspired more by OCaml than Haskell. But since many people might have heard of Haskell more than OCaml, Haskell is a better general answer.

[kinkdr]

The syntax is closer to Haskell than Ocaml.

Foe example types in Ocaml usually start with lower letter.

Also Elm has "Maybe", just like Haskell, instead of "option" of Ocaml.

Also in Elm, like in Haskell you would write "List Sometype", while in Ocaml it is "sometype list".

[masklinn]

Yeah the syntax is clearly Haskell, the semantics are more ML-ish.

[botexpert]

Haskell, ML langs.

[bbcbasic]

Haskell but is very reminiscent of F# with the >> amd |> operators (which I prefer to . amd $). Although you could name them that in Haskell too.

[jmcdiesel]

Yeah, it seems like a step back in readability... It's not at all intuitive and once I figure out what its doing, I can't find a reason for it.. Lisps are hard to read, but there are at least a few reasons for the syntax (not that i like them) ... This just seems... weird and unusual for no reason...

[cnp]

Have you spent much time with it? Like all things, you need to learn before you understand, and then it becomes clear.

[Latty]

I've written a fair amount of Elm, and I still find it awkward. One issue is that I feel like I end up having to go back and add in brackets more than I would with the C-style syntax. I'm not sure if that's just the way I think thanks to being used to that, or an inherent problem.

The main issue really is that I think it's harder to read, as it's less clear what is being used where. The explicitness of the C-style makes it easier to see what goes where.

[jmcdiesel]

Thats kinda the point... with the vast array of languages out there, that are performant and powerful and very well established, why should anyone suffer through the learning curve? what value does the language offer to make that worth the effort?

[eastWestMath]

Well, evaluation in these languages is more transparent. The syntax is basically the lambda calculus, so once you've actually learned the language it makes a huge difference. I'd try reading up on "referential transparency".

[notduncansmith]

One thing that can help with the discomfort is thinking about it as patterns. The = operator isn't for assignment, it's an assertion of equality. Reading the docs carefully helps immerse you in the syntax as well.

[kinkdr]

Haskell

[q3r3qr3q]

Yikes, you should branch out more.