8 ms·

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

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 language i.e. JS that is usable to the point that people are doing professional work in Elm. Also the compiler produces easy to understand messages. Evan has made Functional reactive programming more accessible. I don't think I would have a chance to understand FRP at all without Elm. Elm has inspired other frameworks in Purescript and the development of ReactJS. Sure Elm is not perfect. I found that much of the JS ecosystem not viable in the Elm world, even with FFI due to the purity of the virtual dom. I can't just go and easily chuck an impure calendar control in my code. However despite it's drawbacks I feel the article was a bit strong in putting down Elm, which is sad because I think there are the seeds of some great future languages and ideas in there.

bootload 10y ago
"Evan has made Functional reactive programming more accessible." Agree. [0] [0] Substitute FRP for Subscriptions ~ http://elm-lang.org/blog/farewell-to-frp http://elm-lang.org/blog/farewell-to-frp
mikekchar 10y ago
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 complicated syntax and there are less complicated features. I would would be quite happy to use it in a team that isn't familiar with FP and who wanted to use it for front end code. In fact, although I have yet to do a large project with it, I might even lean toward Elm over JS/CS and React. It just seems a lot more straight forward, with less options available for hanging yourself. But, like I said, generally I agree with him wrt a general programming language. Purescript is a much better fit for that. I thought about trying to write some Elm code on server side, but it just seems like putting a square peg in a round hole. Also, having played with it, the code generation in Purescript seems really, really good. I have no trouble envisioning what it's going to generate for me, which I like.
- 3rwww1 10y ago
  I agree with most of this, but I beg to differ with the last bit : > [writing] some Elm code on server side [...] just seems like putting a square peg in a round hole We are actually writing server-side elm for a living. We mostly have a Scala background and we actually think elm is a pretty great fit for backend code. Agreed, the absence of typeclasses is a limitation of the language. Yes, it means, you can't have a `Set RandomObject` or `Dict RandomObject SomethingElse` (among other things) and that can get pretty frustrating for folks coming from almost any other strongly typed language. However the real question here is not "is this language worthless because of that", but rather "can I overcome that limitation for my specific use case ?". My personal take : - If you are considering a switch from JS to elm (server or client), the point seems moot, as the language features described here are far from being available in JS. - elm suits _some_ server side application very well. Not _all_ server side application.
- 3rwww1 10y ago
  I agree with most of this, but I beg to differ with the last bit : > [writing] some Elm code on server side [...] just seems like putting a square peg in a round hole We are actually writing server-side elm for a living. We mostly have a Scala background and we actually think elm is a pretty great fit for backend code. Agreed, the absence of typeclasses is a limitation of the language. Yes, it means, you can't have a `Set RandomObject` or `Dict RandomObject SomethingElse` (among other things) and that can get pretty frustrating for folks coming from almost any other strongly typed language. However the real question here is not "is this language worthless because of this or that", but rather "can I overcome that limitation for my specific use case ?". My personal take : - If you are considering a switch from JS to elm (server or client), the point seems moot, as the language features described here are far from being available in JS. - elm suits _some_ server side application very well. Not _all_ server side application.
- darkseas 10y ago
  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.
mfukar 10y ago
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 complaint is justified.
- benjaminjosephw 10y ago
  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 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 https://youtu.be/DSjbTC-hvqQ?t=178
  - mfukar 10y ago
    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 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.
seliopou 10y ago
Point of information, it's an undergrad thesis[0], not a PhD thesis. Most of the language is now unrecognizable from that, with the original graphics library residing in this seemingly mothballed repository[1]. [0]: https://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf https://www.seas.harvard.edu/sites/default/files/files/archi... [1]: https://github.com/evancz/elm-graphics https://github.com/evancz/elm-graphics
mambodog 10y ago
Elm has inspired ... the development of ReactJS I don't think that's true. React is a descendant of XHP, and predates Elm. Perhaps you were thinking of Redux?
- boubiyeah 10y ago
  ReactJS introduced virtual DOM before Elm did (Elm first used virtual-dom a lib that was developped quite some time after the release of react, and now uses a new custom implementation) redux was inspired by the "Elm architecture" where everything is global but composed by object/record keys at all levels of the tree.
- Skinney 10y ago
  Elm's virtual dom was inspired by Clojurescript's om, which was based off of React. So yeah, this is not true.
  - iLemming 10y ago
    I've been writing in Clojurescript. To be honest - every time I see a new discussion thread about something new in Javascript-land I can't stop thinking that Clojure and Clojurescript are almost always a few steps ahead of the crowd.
    - Skinney 10y ago
      Used to write in clojure and clojurescript myself. While it's definetly nicer than React, React did come first (om and reagent are just bindings around React. The way om and reagent are faster than React out of the box, is what inspired Elm's vdom module).
slmyers 10y ago
> Elm has inspired other frameworks in Purescript and the development of ReactJS Can you give a few examples? Google is not being helpful.
- john2x 10y ago
  One that comes to mind (for Purescript) are the error messages.
ungzd 10y ago
BTW, why lots of people think it's very wrong and immoral to criticize inanimate pieces of technology in rude and offensive language? Political correctness?
- jrheard 10y ago
  There are people on the other end of the screen who built the technology, and they have feelings :) Being nice is good.
  - canadaduane 10y ago
    And being polite ("nice") makes it more likely that people who don't yet know each other well will receive mutual advantage through collaboration.
  - keithnz 10y ago
    someone posted this to HN the other day https://wiki.lesswrong.com/wiki/Crocker%27s_rules https://wiki.lesswrong.com/wiki/Crocker%27s_rules .. I thought it was quite good, it means sometimes articles like this, with their emotional language gives you information that is useful... IF you refuse to take offense to it.
- adamlett 10y ago
  Whenever you feel the urge to use, or see others using the term political correctness, try mentally substituting it with behaving respectfully. The exercise can be enlightening.
  - lasfter 10y ago
    That doesn't seem like a useful exercise because political correctness does not always equate to behaving respectfully, even if there is overlap (i.e. most respectful behaviour is politically correct and vice versa). I could just as well suggest you mentally substitute the phrase helping the needy with kicking puppies whenever you encounter it.
pdamoc 10y ago
> I can't just go and easily chuck an impure calendar control in my code. Actually, you can... as long as you properly isolate the control. Here is a prof of concept that does just that: https://github.com/fredcy/elm-polymer-calendar https://github.com/fredcy/elm-polymer-calendar
bigtunacan 10y ago
This is no judgement on Elm as I have not used it. I feel like RxJS and Cycle.js both make functional reactive programming quite accessible to JavaScript developers without the burdensome overhead of an entirely new language for the frontend. Have you used these frameworks, and if so could you articulate why Elm would be a better alternative?
fdsaaf 10y ago
> Unfortunately this is an opinionated piece with foul language and it is a bit offensive. Whenever you read "X is offensive", mentally replace it with "I find X offensive". The substitution emphasizes how little being offended ought to matter. Your finding this piece offensive does not create an obligation on the part of anyone else. I am growing very tired of social critics attempting to turn the world into inoffensive mush. We need more articles of this kind. > It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky language I agree that the effort is remarkable. The idea that the strength of the author's effort should somehow shield his work from criticism is antithetical to excellence. It's participation trophy culture. If we're to create great work, we have to understand the difference between good and bad work, and we can't do that if misplaced concern for someone's feelings stops our describing reality as it is.
Moezalez 10y ago
> PhD thesis It was his Bachelor thesis

bootload 10y ago

"Evan has made Functional reactive programming more accessible." Agree. [0] [0] Substitute FRP for Subscriptions ~ http://elm-lang.org/blog/farewell-to-frp http://elm-lang.org/blog/farewell-to-frp

mikekchar 10y ago

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 complicated syntax and there are less complicated features. I would would be quite happy to use it in a team that isn't familiar with FP and who wanted to use it for front end code. In fact, although I have yet to do a large project with it, I might even lean toward Elm over JS/CS and React. It just seems a lot more straight forward, with less options available for hanging yourself. But, like I said, generally I agree with him wrt a general programming language. Purescript is a much better fit for that. I thought about trying to write some Elm code on server side, but it just seems like putting a square peg in a round hole. Also, having played with it, the code generation in Purescript seems really, really good. I have no trouble envisioning what it's going to generate for me, which I like.

3rwww1 10y ago
I agree with most of this, but I beg to differ with the last bit : > [writing] some Elm code on server side [...] just seems like putting a square peg in a round hole We are actually writing server-side elm for a living. We mostly have a Scala background and we actually think elm is a pretty great fit for backend code. Agreed, the absence of typeclasses is a limitation of the language. Yes, it means, you can't have a `Set RandomObject` or `Dict RandomObject SomethingElse` (among other things) and that can get pretty frustrating for folks coming from almost any other strongly typed language. However the real question here is not "is this language worthless because of that", but rather "can I overcome that limitation for my specific use case ?". My personal take : - If you are considering a switch from JS to elm (server or client), the point seems moot, as the language features described here are far from being available in JS. - elm suits _some_ server side application very well. Not _all_ server side application.
3rwww1 10y ago
I agree with most of this, but I beg to differ with the last bit : > [writing] some Elm code on server side [...] just seems like putting a square peg in a round hole We are actually writing server-side elm for a living. We mostly have a Scala background and we actually think elm is a pretty great fit for backend code. Agreed, the absence of typeclasses is a limitation of the language. Yes, it means, you can't have a `Set RandomObject` or `Dict RandomObject SomethingElse` (among other things) and that can get pretty frustrating for folks coming from almost any other strongly typed language. However the real question here is not "is this language worthless because of this or that", but rather "can I overcome that limitation for my specific use case ?". My personal take : - If you are considering a switch from JS to elm (server or client), the point seems moot, as the language features described here are far from being available in JS. - elm suits _some_ server side application very well. Not _all_ server side application.
darkseas 10y ago
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.

mfukar 10y ago

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 complaint is justified.

benjaminjosephw 10y ago
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 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 https://youtu.be/DSjbTC-hvqQ?t=178
- mfukar 10y ago
  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 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.

seliopou 10y ago

Point of information, it's an undergrad thesis[0], not a PhD thesis. Most of the language is now unrecognizable from that, with the original graphics library residing in this seemingly mothballed repository[1]. [0]: https://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf https://www.seas.harvard.edu/sites/default/files/files/archi... [1]: https://github.com/evancz/elm-graphics https://github.com/evancz/elm-graphics

mambodog 10y ago

Elm has inspired ... the development of ReactJS I don't think that's true. React is a descendant of XHP, and predates Elm. Perhaps you were thinking of Redux?

boubiyeah 10y ago
ReactJS introduced virtual DOM before Elm did (Elm first used virtual-dom a lib that was developped quite some time after the release of react, and now uses a new custom implementation) redux was inspired by the "Elm architecture" where everything is global but composed by object/record keys at all levels of the tree.
Skinney 10y ago
Elm's virtual dom was inspired by Clojurescript's om, which was based off of React. So yeah, this is not true.
- iLemming 10y ago
  I've been writing in Clojurescript. To be honest - every time I see a new discussion thread about something new in Javascript-land I can't stop thinking that Clojure and Clojurescript are almost always a few steps ahead of the crowd.
  - Skinney 10y ago
    Used to write in clojure and clojurescript myself. While it's definetly nicer than React, React did come first (om and reagent are just bindings around React. The way om and reagent are faster than React out of the box, is what inspired Elm's vdom module).

slmyers 10y ago

> Elm has inspired other frameworks in Purescript and the development of ReactJS Can you give a few examples? Google is not being helpful.

john2x 10y ago
One that comes to mind (for Purescript) are the error messages.

ungzd 10y ago

BTW, why lots of people think it's very wrong and immoral to criticize inanimate pieces of technology in rude and offensive language? Political correctness?

jrheard 10y ago
There are people on the other end of the screen who built the technology, and they have feelings :) Being nice is good.
- canadaduane 10y ago
  And being polite ("nice") makes it more likely that people who don't yet know each other well will receive mutual advantage through collaboration.
- keithnz 10y ago
  someone posted this to HN the other day https://wiki.lesswrong.com/wiki/Crocker%27s_rules https://wiki.lesswrong.com/wiki/Crocker%27s_rules .. I thought it was quite good, it means sometimes articles like this, with their emotional language gives you information that is useful... IF you refuse to take offense to it.
adamlett 10y ago
Whenever you feel the urge to use, or see others using the term political correctness, try mentally substituting it with behaving respectfully. The exercise can be enlightening.
- lasfter 10y ago
  That doesn't seem like a useful exercise because political correctness does not always equate to behaving respectfully, even if there is overlap (i.e. most respectful behaviour is politically correct and vice versa). I could just as well suggest you mentally substitute the phrase helping the needy with kicking puppies whenever you encounter it.

pdamoc 10y ago

> I can't just go and easily chuck an impure calendar control in my code. Actually, you can... as long as you properly isolate the control. Here is a prof of concept that does just that: https://github.com/fredcy/elm-polymer-calendar https://github.com/fredcy/elm-polymer-calendar

bigtunacan 10y ago

This is no judgement on Elm as I have not used it. I feel like RxJS and Cycle.js both make functional reactive programming quite accessible to JavaScript developers without the burdensome overhead of an entirely new language for the frontend. Have you used these frameworks, and if so could you articulate why Elm would be a better alternative?

fdsaaf 10y ago

> Unfortunately this is an opinionated piece with foul language and it is a bit offensive. Whenever you read "X is offensive", mentally replace it with "I find X offensive". The substitution emphasizes how little being offended ought to matter. Your finding this piece offensive does not create an obligation on the part of anyone else. I am growing very tired of social critics attempting to turn the world into inoffensive mush. We need more articles of this kind. > It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky language I agree that the effort is remarkable. The idea that the strength of the author's effort should somehow shield his work from criticism is antithetical to excellence. It's participation trophy culture. If we're to create great work, we have to understand the difference between good and bad work, and we can't do that if misplaced concern for someone's feelings stops our describing reality as it is.

Moezalez 10y ago

> PhD thesis It was his Bachelor thesis