Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm for the Front End, Right Now

bendyworks.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Elm for the Front End, Right Now

#61

Post by sridca »

nv-vn wrote: post #49
matt4077 wrote: post #29

Earlier quoted context omitted.

> Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me. Until you take your personal style to Github, or coworkers... Evan is doing a pretty good job at managing Elm – in fact I don't know any other language except maybe Swift where the rollout is planned to such a depth.

If coworkers are unhappy with it, they can (and should) make guidelines for acceptable syntax. This is no different than using camel case in Java instead of snake case (or using the $ in identifiers, which is extremely rare). If it's a problem to use it in my code on Github, you can always use somebody else's code or fork mine to change it. Maybe we should use the compiler to force every line to have a comment so we…

This is what I find troubling about Elm.

The creators see it appropriate to enforce their strange preferences with dubious reasoning. The enforcement (in standard Elm format) of a 4-sized tab[1] is just another example.

Like you said I'd not have the language community enforce what is acceptable down my throat, and that conflict of preferences within a team is best solved by making style guidelines instead of having the language community spoon-feed an authoritarian preference.

[1] https://github.com/avh4/elm-format/issues/210

Re: Elm for the Front End, Right Now

#62

Post by ungzd »

skybrian wrote: post #20
redtuesday wrote: post #14

Earlier quoted context omitted.

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?

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…

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.

Re: Elm for the Front End, Right Now

#63

Post by mullsork »

I remember evaluating Elm and ClojueScript as an alternative to ES6 about a year and a half ago. Eventually I had to decide against both as we absolutely needed to render parts of our page server side (Google saying they'll index SPAs is a joke.)

If I'm not mistaken this wasn't possible in Elm back then, and felt uncomfortable or even hard in ClojureScript. Has that changed?

To be fair if I started a new project like the one I'm working at now I'd much rather use server + template for most pages and add interactivity through JS once it boots up.

Re: Elm for the Front End, Right Now

#64

Post by leshow »

sridca wrote: post #61
nv-vn wrote: post #49

Earlier quoted context omitted.

If coworkers are unhappy with it, they can (and should) make guidelines for acceptable syntax. This is no different than using camel case in Java instead of snake case (or using the $ in identifiers, which is extremely rare). If it's a problem to use it in my code on Github, you can always use somebody else's code or fork mine to change it. Maybe we should use the compiler to force every line to have a comment so we…

This is what I find troubling about Elm. The creators see it appropriate to enforce their strange preferences with dubious reasoning. The enforcement (in standard Elm format) of a 4-sized tab[1] is just another example. Like you said I'd not have the language community enforce what is acceptable down my throat, and that conflict of preferences within a team is best solved by making style guidelines instead of having…

I completely agree with you. Evan isn't happy just controlling what packages you can publish that use the native api on package.elm-lang.org, or what you can do in the language since the removal of signals, he wants to control even minute things like whether you use a fucking prime in a function name in your own code. It's ridiculous.

Re: Elm for the Front End, Right Now

#66

Post by kbp »

conistonwater wrote: post #52
thatswrong0 wrote: post #9

Earlier quoted context omitted.

> breaking backwards compatibility for no good reason I'd say reducing weird syntax is a perfectly good reason. How is doing this while offering an easy migration solution in an early stage language a "huge red flag"?

A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28p... ) There's a very good example in C++ of how this caus…

The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.

Re: Elm for the Front End, Right Now

#67

Post by masklinn »

kbp wrote: post #66
conistonwater wrote: post #52

Earlier quoted context omitted.

A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28p... ) There's a very good example in C++ of how this caus…

The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.

In Haskell it's sometimes (often?) used for strict versions of functions e.g. foldl and foldl'.

Re: Elm for the Front End, Right Now

#68

Post by masklinn »

kinkdr wrote: post #44
salimmadjd wrote: post #15

Earlier quoted context omitted.

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.

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".

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

Re: Elm for the Front End, Right Now

#69

Post by susi22 »

mullsork wrote: post #63

I remember evaluating Elm and ClojueScript as an alternative to ES6 about a year and a half ago. Eventually I had to decide against both as we absolutely needed to render parts of our page server side (Google saying they'll index SPAs is a joke.) If I'm not mistaken this wasn't possible in Elm back then, and felt uncomfortable or even hard in ClojureScript. Has that changed? To be fair if I started a new project like…

In clojurescript we have RUM (another lib on top of react) where you can render your HMTL on the server (without using node, just on the JVM). It's also blazing fast and works very well.

Re: Elm for the Front End, Right Now

#70

Post by boubiyeah »

kcarnold wrote: post #42

I really want to like Elm. When I'm writing JS/React code, I sometimes think "this would be so much nicer in Elm!" - especially for architectural issues. But the few times I’ve actually tried doing something in it, I find that the parts of what I want to do that fit cleanly within Elm’s walls are really nice, but the parts that don’t quite fit get hard quickly. Suppose I want to do something with the DOM that doesn’t…

Similar experience, especially if your ambition is to have a very neat application with rich components. Elm elegantly solves 70% of the problems, it's awful at the other 30%.

If we have to use JS via ports (and it has to be asynchronous! dang) to achieve complex things anyway, why not use typescript, which can do absolutely everything you need without the language context and async switch?

Post reply on HN