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

Elm is Wrong

reasonablypolymorphic.com

Post reply on HN
Print view View original

61–70 of 218 posts

Re: Elm is Wrong

#61

Post by b123400 »

I have some similar thoughts when trying out Elm.

Every function that a language support/does not support shapes the ecosystem, and that is arguably as important as the language itself. With Elm, decision making is done by a small group of people and they can be quite opinionated.

I started when 0.15 is out, amazed by how beautiful FRP can be, then it is gone now. I cannot add / remove fields from dictionary, I cannot have multi-way if. My code base is still simple, so I can get around it, but I really enjoyed the good old FRP style. In JS, you can definitely choose your favourite frameworks, but in Elm, there is no alternative, there is only a single HTML framework `elm-lang/html`, if they decide to drop FRP, you cannot escape! This also means choosing Elm is also choosing to follow Evan, you are betting on a person.

I hope things getting better someday, we will have a standard JS interop that allows people to make their own 3rd party frameworks in Elm. Competition makes things better.

Re: Elm is Wrong

#62

Post by benjaminjosephw »

mfukar wrote: post #43
bbcbasic wrote: post #26

Unfortunately this is an opinionated piece with foul language and it is a bit offensive. Sandy should take into account that Elm is created by one person pretty much (‎Evan Czaplicki) who created it in his PhD thesis and has been maintaining it since. So it's someones baby still, and they might be offended. It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky lan…

I think it's valid criticism. There's a (excruciating) description of a use case, (valid) attempts to build a solution, and reaching the point where someone tells you "No, you can't have that because I don't want to" - whoever that may be - is understandably frustrating. Especially when the facility in question solves a real PITA of a problem. Now, the author was obviously venting, he even admits it. Nonetheless, the…

I don't think the response was as simple as "No, you can't have that because I don't want to". Reading the discussion about removal of this feature on Github there seems to be a few more points made that the author alludes to: https://github.com/elm-lang/elm-compiler/issues/985

Also, It's worth noting that Elm does have a BDFL. Evan makes the call and, as I'm sure a lot of python folks would agree, that setup means that the language is going to remain consistent, clean and well defined. This might be frustrating, but is part of keeping a strong design philosophy that directs the language. In that context, is it really a valid criticism?

Evan actually addresses this issue directly by talking about the different communities with different aims. He says that having these different communities with different design decisions makes the whole scene a lot stronger[1]:

> if you go back a year so on the mailing list you'll see a lot of people talking about type classes "when are we going to have this in Elm?", "we need this", "this is the most important thing", and a language came out that had different priorities and all the people who wanted that kind of feature started using that language and so now that's not to say one of the communities is making a better choice than the other, it just means we can all experiment with a different philosophy and way of thinking and do well."

[1] https://youtu.be/DSjbTC-hvqQ?t=178

Re: Elm is Wrong

#63

Post by tom_mellior »

glenjamin wrote: post #57

This post starts off with an abstract goal - "use a custom type as a dict key", and then goes off down a rabbit hole trying to create typeclasses and make it work. This is despite prior knowledge that Elm has chosen not to implement type classes. The line from Evan, Elm's creator, has always been along the lines of "show me a concrete actual use-case that you can't do without typeclasses", this article fails to clear…

> The line from Evan, Elm's creator, has always been along the lines of "show me a concrete actual use-case that you can't do without typeclasses", this article fails to clear that fairly low bar.

Translation: "I will never add typeclasses."

There is no concrete actual use-case that is impossible to implement without typeclasses. What typeclasses make possible is an abstraction over concrete actual use-cases. That is, you can always solve individual concrete actual problems with boilerplate. Typeclasses "only" give you the possibility to write that boilerplate once and for all and reuse it for every concrete actual use-case.

Evan seems to think that that's not worth it, which is a valid opinion to hold. But it would be a bit more honest to come out and say it like this.

Re: Elm is Wrong

#64

Post by boubiyeah »

I don't believe in Elm one bit. it's been 4 years guys. I follow its developement (it's not a hard thing to do after all, it's a snail pace) because its creator is intelligent and there are a few nice things in it.

But as a practical platform to build real apps? No way. I mean you can build apps with any tech, so of course people will try and succeed with it; but it's just a bad choice.

Elm is impratical because you can't do anything with it. I loathe directing attitudes in that field where everything moves fast (http://www.martinfowler.com/bliki/EnablingAttitude.html).

Its creator is a bit on the control freak side and far more of a backend dev than a frontend dev. The reactive framework (the Elm architecture) is full of boilerplate and anything that was not forethought will have to be a metric ton of more boilerplate or delegated to javascript via asynchronous ports (if you have to hide the crap away in JS land because it's impossible to do in elm, somehow it's not elm's problem). The elm community is minuscule and not always great, doesn't embrace new approaches (the ones who do don't stay for long as it's so frustrating) they're more like robots repeating "wait for Evan to tell us how to do that. If Evan didn't say anything yet, you are taking big risks" or "Evan is working on this particular problem, just wait 2 years"

Meanwhile we can build apps real fast with typescript, which in version 2.0.3 is a very capable and more than typesafe enough language.

bucklescript/Reason might be a good alternative to the very closed Elm ecosystem too if like me you like ML.

I think where elm shines is as a simplistic language and sanitized environment to teach people programming. That's about it. It's still in a state of a "research language" (and it's good at it), but is not being marketed as such.

Re: Elm is Wrong

#65

Post by sjrd »

srparish wrote: post #36
chenshuiluke wrote: post #16

What's a good alternative to Elm?

Language wise scala.js[1] with cats[2] or scalaz[3]. The FRP story there is unfortunately more complicated. 1| https://www.scala-js.org/ 2| http://typelevel.org/cats/ 3| http://scalaz.github.io/scalaz/

You can go with the Diode [1] library for an Elm/Redux-like architecture. And with that you don't need to all the way down to cats or scalaz (although you sure always can if you want to).

[1] https://github.com/ochrons/diode

Re: Elm is Wrong

#66

Post by pka »

darkseas wrote: post #60
mikekchar wrote: post #41

Earlier quoted context omitted.

Yeah I read this a few weeks ago and was similarly put off. I will give him one thing: it got me to start thinking about what I wanted in a functional language that compiles into JS, which ultimately steered me towards Purescript. I think fundamentally he's correct, but the point that he is missing is the intended audience of Elm. He was not it. Elm is much easier to grasp than Purescript, for instance. There is less…

Can I ask if you have found any equivalent to the Elm Architecture in Purescript? I have looked at Elm, and Purescript and now Bucklescript, but I have not yet seen, or wired up myself, something like the Elm architecture. I should probably buckle down and learn the wiring I need myself, but I have been finding the typing a little tough.

Yep, there are several.

[0] https://github.com/paf31/purescript-thermite

[1] https://github.com/alexmingoia/purescript-pux

[2] https://github.com/slamdata/purescript-halogen

Re: Elm is Wrong

#67

Post by mfukar »

benjaminjosephw wrote: post #62
mfukar wrote: post #43

Earlier quoted context omitted.

I think it's valid criticism. There's a (excruciating) description of a use case, (valid) attempts to build a solution, and reaching the point where someone tells you "No, you can't have that because I don't want to" - whoever that may be - is understandably frustrating. Especially when the facility in question solves a real PITA of a problem. Now, the author was obviously venting, he even admits it. Nonetheless, the…

I don't think the response was as simple as "No, you can't have that because I don't want to". Reading the discussion about removal of this feature on Github there seems to be a few more points made that the author alludes to: https://github.com/elm-lang/elm-compiler/issues/985 Also, It's worth noting that Elm does have a BDFL. Evan makes the call and, as I'm sure a lot of python folks would agree, that setup means t…

It was exactly one comment from evancz, which says: "I don't want to readd this feature...I think it makes sense to continue discussion in this issue if you think there are valid use cases". Here [1] is the actual feature request.

The existence of a BDFL is irrelevant. This rejection is frustrating whether it comes from one person, or a committee, a peer, whatever, because it is arbitrary and unjustified. The feature wouldn't compromise the design philosophy nor its consistency. "I don't want this" is not a design philosophy, and neither is "your use case is invalid".

The use case is actually solid. Writing readable, maintainable code which is conceptually easy to understand in the span of a few paragraphs, like in the blog post.

[1] https://github.com/elm-lang/elm-compiler/issues/1283

PS. I'm certain evancz has a reasoning behind his wish to keep the feature out of Elm. He just doesn't communicate it, which makes the decision seem arbitrary.

Re: Elm is Wrong

#68

Post by houli »

darkseas wrote: post #60
mikekchar wrote: post #41

Earlier quoted context omitted.

Yeah I read this a few weeks ago and was similarly put off. I will give him one thing: it got me to start thinking about what I wanted in a functional language that compiles into JS, which ultimately steered me towards Purescript. I think fundamentally he's correct, but the point that he is missing is the intended audience of Elm. He was not it. Elm is much easier to grasp than Purescript, for instance. There is less…

Can I ask if you have found any equivalent to the Elm Architecture in Purescript? I have looked at Elm, and Purescript and now Bucklescript, but I have not yet seen, or wired up myself, something like the Elm architecture. I should probably buckle down and learn the wiring I need myself, but I have been finding the typing a little tough.

Purescript Pux looks to be what you're looking for https://github.com/alexmingoia/purescript-pux/

Re: Elm is Wrong

#69

Post by pka »

b123400 wrote: post #61

I have some similar thoughts when trying out Elm. Every function that a language support/does not support shapes the ecosystem, and that is arguably as important as the language itself. With Elm, decision making is done by a small group of people and they can be quite opinionated. I started when 0.15 is out, amazed by how beautiful FRP can be, then it is gone now. I cannot add / remove fields from dictionary, I canno…

PureScript!

Re: Elm is Wrong

#70

Post by b123400 »

pka wrote: post #69
b123400 wrote: post #61

I have some similar thoughts when trying out Elm. Every function that a language support/does not support shapes the ecosystem, and that is arguably as important as the language itself. With Elm, decision making is done by a small group of people and they can be quite opinionated. I started when 0.15 is out, amazed by how beautiful FRP can be, then it is gone now. I cannot add / remove fields from dictionary, I canno…

PureScript!

I tried Halogen for a while and found it too complicated. I need to create a type with 6 type params (something like `ParentComponentSpec s s' f f' g p`) for embedding a child component! Also, most of the operations are wrapped in monad, which ultimately bring me back to the procedural way of thinking.
Post reply on HN