7 ms·

I really like the look of Elm --- to me it seems to hit the sweet spot of being enough like Haskell to be awesome while also being understandable by humans. It

I really like the look of Elm --- to me it seems to hit the sweet spot of being enough like Haskell to be awesome while also being understandable by humans. It also fixes some of the rougher edges of the Haskell syntax; I vastly prefer Elm's record syntax to Haskell's, for example, which apart from being much cleaner and obvious also avoids some of the more common Haskell namespace traps. The one piece I'm really looking for is server-side Elm, though. I've love the ability to write both my client and my server in Elm. I know there are some projects to allow Elm via node.js but they're still quite rough. (Is anyone looking into transpiling Elm to Standard ML, so that it can be compiled to fast native code with MLton? Because that'd be, like, really cool.)

tunaoftheland 10y ago
Agreed! While I do tell myself "right lang for the right job", I've come to the conclusion that I am lazy. :) So if Elm can run on Erlang/OTP like Elixir, that would be an interesting option for the webdev space. I don't even know if something like that is feasible, but I wonder someone's thought of such a thing?
- david-given 10y ago
  I hadn't thought of BEAM. Apparently it's on the roadmap. https://news.ycombinator.com/item?id=11916096 https://news.ycombinator.com/item?id=11916096
nilkn 10y ago
Why not just use Haskell for the backend? It's really not much harder than Elm, and it's considerably more flexible and general. Of course, it's lazy, not strict, and you're totally right that records in Haskell suck. But my understanding is that strictness for Elm was chosen mainly to overcome issues with FRP, which it's now abandoned. So I'm not sure if that difference matters anymore.
- david-given 10y ago
  There's several reasons, one of the simplest (but not the most trivial) being that I can't share code between the client and the server. For example, data validation. I did a tonne of programming on GWT back in the day, and this was something it actually did well. Most of the other reasons boil down to Haskell not being Elm --- they work in different ways and solve problems differently. There's always going to be impedance mismatch between the two. (Do I solve this problem with monads or with state-mutation functions?) This is going to use up valuable problem-solving bandwidth which I'd rather spend making the project more awesome.
  - platz 10y ago
    > Can't share code between client and server The question was about using haskell on the back end. Also, previous attempts at sharing client and server code in other langs are sophmoric at best. In reality, there will always be a boundary that requires differences in front end and back end code. > Haskell is not Elm Doesn't answer the question, circular reasoning at best.
  - deleted 10y ago
    [deleted]
  - bbcbasic 10y ago
    > Haskell is not Elm A service isn't a client though. They work in different ways and solve problems differently
    - phamilton 10y ago
      They also, sometimes, solve the same problem. (Cited example: data validation) There's value in sharing code between client and server. It may not outway the costs, but there's definitely value in doing so.
      - bbcbasic 10y ago
        Yes true. There is the option of ghcjs on the front end, so you can do both in Haskell. And ghcjs is very close to cbc. I think it even emulates the threading model.
corysama 10y ago
> while also being understandable by humans. A famously good aspect of Elm is it's error messages. Very learner-friendly. https://twitter.com/id_aa_carmack/status/735197548034412546 https://twitter.com/id_aa_carmack/status/735197548034412546 http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compiler-errors-for-humans http://elm-lang.org/blog/compiler-errors-for-humans
- mdadm 10y ago
  That's freakin' awesome. Now I wish gcc or clang would have something similar :(
methehack 10y ago
I wouldn't say it's understandable by all humans yet. I've had this experience where just when I think I'm grokking it, I hit a line of code that makes me cross-eyed and I can't find any traction at all and it's basically impossible to look up help. This is a combination of the maturity level of the project and also the documentation, but I get a distinctly not-quite-there-yet feeling with it (to be fair it is < 1.0). While elm has come a long way and has some great ideas, but I'm not 100% comfortable using it for something real yet. I'm also not convinced by the cross-component communication / tree of components story yet. That still feels awkward to me. Not to turn this religious or anything, but tbh the static typing which feels like such a strength within a component, feels like it's in the way between components and results in some boilerplate, verbosity, and overly tight coupling. Really not trying to troll here -- I want to love it. YMMV.
- oblique63 10y ago
  > [static typing] feels like it's in the way between components and results in some boilerplate, verbosity, and overly tight coupling Just curious, is this with regards to Elm / ML-style static typing specifically, or were you talking about it in combination with languages like C#/Java/etc? I'm an elm noob, but I've been using F# for a good while, and its ML style of static typing is almost like the exact opposite experience of working with things like Java. Significantly less code, less boilerplate, and more expressive[0][1]. For example, one of the coolest features of F# that really showcase this, are type providers: https://channel9.msdn.com/Blogs/Seth-Juarez/Type-Providers-in-F-with-Tomas-Petricek https://channel9.msdn.com/Blogs/Seth-Juarez/Type-Providers-i... With them, you can leverage F#'s type system to automatically infer the structure and type of any external data source. Which means practically zero boilerplate or "ORMs" needed for things like reading-from/writing-to databases, making web api calls, parsing json/xml, or even interfacing with packages from entirely different languages like R [2]. So static typing can definitely have a lot of cool/practical benefits besides just catching bugs that make life easier, while still maintaining the flexible/lightweight feel of languages like python. However languages like C++ and Java have definitely seemed to have given it a bad name for a while, and haskell's whole tie-in with abstract math hasn't historically made it very accessible for us average programmers to notice all the tricks it has up its sleeve. Elm is still young and I'm a total novice to it, but after working in F#, I'm definitely sold on it and like where it's going. [0] https://fsharpforfunandprofit.com/series/why-use-fsharp.html https://fsharpforfunandprofit.com/series/why-use-fsharp.html [1] https://skillsmatter.com/skillscasts/4971-domain-driven-design-with-scott-wlaschin https://skillsmatter.com/skillscasts/4971-domain-driven-desi... [2] https://www.youtube.com/watch?v=_BOST3W88-Y https://www.youtube.com/watch?v=_BOST3W88-Y
wyager 10y ago
>while also being understandable by humans. I don't understand how one can understand Elm and not understand Haskell, unless the expectation that Haskell is difficult makes people's brains shut down without even trying. Most of the ML-esque concepts that make Haskell "hard" to read if you come from a C/Python/Java/etc. background (ADTs and pattern matching, application by adjacency, etc.) are present in Elm as well. > I vastly prefer Elm's record syntax to Haskell's, Are you familiar with Lenses? Classy lenses in Haskell provide a slightly less sexy but more powerful system of structural typing.
- galfarragem 10y ago
  Elm looks like a simplified and specially a rebranded Haskell, a "functional language for humans". This could work wonders as marketing strategy but there is still a remaining pain point blocking Elm aspiration to become mainstream: community management. There is plenty of room to improve there.

tunaoftheland 10y ago

Agreed! While I do tell myself "right lang for the right job", I've come to the conclusion that I am lazy. :) So if Elm can run on Erlang/OTP like Elixir, that would be an interesting option for the webdev space. I don't even know if something like that is feasible, but I wonder someone's thought of such a thing?

david-given 10y ago
I hadn't thought of BEAM. Apparently it's on the roadmap. https://news.ycombinator.com/item?id=11916096 https://news.ycombinator.com/item?id=11916096

nilkn 10y ago

Why not just use Haskell for the backend? It's really not much harder than Elm, and it's considerably more flexible and general. Of course, it's lazy, not strict, and you're totally right that records in Haskell suck. But my understanding is that strictness for Elm was chosen mainly to overcome issues with FRP, which it's now abandoned. So I'm not sure if that difference matters anymore.

david-given 10y ago
There's several reasons, one of the simplest (but not the most trivial) being that I can't share code between the client and the server. For example, data validation. I did a tonne of programming on GWT back in the day, and this was something it actually did well. Most of the other reasons boil down to Haskell not being Elm --- they work in different ways and solve problems differently. There's always going to be impedance mismatch between the two. (Do I solve this problem with monads or with state-mutation functions?) This is going to use up valuable problem-solving bandwidth which I'd rather spend making the project more awesome.
- platz 10y ago
  > Can't share code between client and server The question was about using haskell on the back end. Also, previous attempts at sharing client and server code in other langs are sophmoric at best. In reality, there will always be a boundary that requires differences in front end and back end code. > Haskell is not Elm Doesn't answer the question, circular reasoning at best.
- deleted 10y ago
  [deleted]
- bbcbasic 10y ago
  > Haskell is not Elm A service isn't a client though. They work in different ways and solve problems differently
  - phamilton 10y ago
    They also, sometimes, solve the same problem. (Cited example: data validation) There's value in sharing code between client and server. It may not outway the costs, but there's definitely value in doing so.
    - bbcbasic 10y ago
      Yes true. There is the option of ghcjs on the front end, so you can do both in Haskell. And ghcjs is very close to cbc. I think it even emulates the threading model.

corysama 10y ago

> while also being understandable by humans. A famously good aspect of Elm is it's error messages. Very learner-friendly. https://twitter.com/id_aa_carmack/status/735197548034412546 https://twitter.com/id_aa_carmack/status/735197548034412546 http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compiler-errors-for-humans http://elm-lang.org/blog/compiler-errors-for-humans

mdadm 10y ago
That's freakin' awesome. Now I wish gcc or clang would have something similar :(

methehack 10y ago

I wouldn't say it's understandable by all humans yet. I've had this experience where just when I think I'm grokking it, I hit a line of code that makes me cross-eyed and I can't find any traction at all and it's basically impossible to look up help. This is a combination of the maturity level of the project and also the documentation, but I get a distinctly not-quite-there-yet feeling with it (to be fair it is < 1.0). While elm has come a long way and has some great ideas, but I'm not 100% comfortable using it for something real yet. I'm also not convinced by the cross-component communication / tree of components story yet. That still feels awkward to me. Not to turn this religious or anything, but tbh the static typing which feels like such a strength within a component, feels like it's in the way between components and results in some boilerplate, verbosity, and overly tight coupling. Really not trying to troll here -- I want to love it. YMMV.

oblique63 10y ago
> [static typing] feels like it's in the way between components and results in some boilerplate, verbosity, and overly tight coupling Just curious, is this with regards to Elm / ML-style static typing specifically, or were you talking about it in combination with languages like C#/Java/etc? I'm an elm noob, but I've been using F# for a good while, and its ML style of static typing is almost like the exact opposite experience of working with things like Java. Significantly less code, less boilerplate, and more expressive[0][1]. For example, one of the coolest features of F# that really showcase this, are type providers: https://channel9.msdn.com/Blogs/Seth-Juarez/Type-Providers-in-F-with-Tomas-Petricek https://channel9.msdn.com/Blogs/Seth-Juarez/Type-Providers-i... With them, you can leverage F#'s type system to automatically infer the structure and type of any external data source. Which means practically zero boilerplate or "ORMs" needed for things like reading-from/writing-to databases, making web api calls, parsing json/xml, or even interfacing with packages from entirely different languages like R [2]. So static typing can definitely have a lot of cool/practical benefits besides just catching bugs that make life easier, while still maintaining the flexible/lightweight feel of languages like python. However languages like C++ and Java have definitely seemed to have given it a bad name for a while, and haskell's whole tie-in with abstract math hasn't historically made it very accessible for us average programmers to notice all the tricks it has up its sleeve. Elm is still young and I'm a total novice to it, but after working in F#, I'm definitely sold on it and like where it's going. [0] https://fsharpforfunandprofit.com/series/why-use-fsharp.html https://fsharpforfunandprofit.com/series/why-use-fsharp.html [1] https://skillsmatter.com/skillscasts/4971-domain-driven-design-with-scott-wlaschin https://skillsmatter.com/skillscasts/4971-domain-driven-desi... [2] https://www.youtube.com/watch?v=_BOST3W88-Y https://www.youtube.com/watch?v=_BOST3W88-Y

wyager 10y ago

>while also being understandable by humans. I don't understand how one can understand Elm and not understand Haskell, unless the expectation that Haskell is difficult makes people's brains shut down without even trying. Most of the ML-esque concepts that make Haskell "hard" to read if you come from a C/Python/Java/etc. background (ADTs and pattern matching, application by adjacency, etc.) are present in Elm as well. > I vastly prefer Elm's record syntax to Haskell's, Are you familiar with Lenses? Classy lenses in Haskell provide a slightly less sexy but more powerful system of structural typing.

galfarragem 10y ago
Elm looks like a simplified and specially a rebranded Haskell, a "functional language for humans". This could work wonders as marketing strategy but there is still a remaining pain point blocking Elm aspiration to become mainstream: community management. There is plenty of room to improve there.