6 ms·

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 stric

by 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.
zimbatm 10y ago
With Elm you don't have to import 80 things and active 10 language extension to get anything done. :p
- bbcbasic 10y ago
  But in Haskell you can get anything done :-)
  - tmptmp 10y ago
    >>But in Haskell you can get anything done :-) Yeah, only if you are willing to spend anything (e.g. insanely large amounts of time) on it :( Please correct me if I am wrong, but for any large project, Haskell actually adds more woes (e.g. laziness induced problems, no good debugging support) than the ones it addresses. The Standard Chartered people had to invent a new language (mu) [1] which doesn't have laziness and the horrors associated with it. BTW, you can get anything done even in (any Turing complete) assembly language too! [1] http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf Edit: added the Standard Chartered example
    - bbcbasic 10y ago
      Was just jokingly comparing Haskell which is general purpose to elm which is for the web only.
    - wyager 10y ago
      >laziness induced problems This is like saying that Java has "strictness induced problems". It's true, but probably disingenuous. Obviously large, well-funded strict object-oriented projects have memory leak problems as well (all browsers). > no good debugging support One generally doesn't require as much debugging support for Haskell, but it's actually quite nice if you follow a debugging process amenable to pure functional languages. People coming from a Java background want e.g. a breakpoint debugger, which doesn't really make any sense at all in a pure functional language; a vastly superior approach is to do e.g. quickcheck-style checking or input/output debugging on pure functions. If your code is impure, you can essentially debug like normal. Bugs in Haskell also aren't the same as most of the bugs in other languages; you never get null pointers, for example. Every bug in Haskell is either a logic bug (which can often be debugged purely, and can be minimized by the careful application of types) or an atotality bug (which can be completely avoided by totality/completeness checking, and dynamic debugging of such bugs is getting much better with the new implicit callstack feature added to recent versions of GHC).
mahyarm 10y ago
Haskell has compile time problems when used in real project (tm) codebase scales and is hard to predict memory or cpu usage due to it's lazy nature sometimes. I have no idea if elm is any better in that case, but both things make me scared to use it in production systems.
- ruslan_talpa 10y ago
  This is a way to introduce space leak detection in your tests http://neilmitchell.blogspot.ro/2015/09/detecting-space-leaks.html http://neilmitchell.blogspot.ro/2015/09/detecting-space-leak... so that you can sleep well and not be afraid of using Haskell in big projects :)
bjz_ 10y ago
> But my understanding is that strictness for Elm was chosen mainly to overcome issues with FRP, which it's now abandoned Laziness also requires you to ship a runtime, which is annoying on the web. Plus it's hard to debug performance problems, and you need more language complexity to allow you to opt-out of it. There are ways to opt-in to laziness in Elm via libraries, which seems to be becoming accepted as the right way to do things these days.
bjz_ 10y ago
> But my understanding is that strictness for Elm was chosen mainly to overcome issues with FRP, which it's now abandoned Laziness also requires you to ship a runtime, which is annoying on the web. Plus it's hard to debug performance problems, and you need more language complexity to allow you to opt-out of it. There are ways to opt-in to laziness in Elm via libraries, which seems to be becoming accepted as the right way to do things these days.
moosingin3space 10y ago
Elm seems to have a much stronger developer UX story than Haskell (just look at how much better its error messages are than ghc's), and the ability to share data models across the frontend-backend border would be awesome -- an end-to-end typechecked stack with easy sharing. With Elm on the server too, you could easily implement server rendering to initialize the page for fast load times.
- deleted 10y ago
  [deleted]

by nilkn 10y ago

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.

zimbatm 10y ago

With Elm you don't have to import 80 things and active 10 language extension to get anything done. :p

bbcbasic 10y ago
But in Haskell you can get anything done :-)
- tmptmp 10y ago
  >>But in Haskell you can get anything done :-) Yeah, only if you are willing to spend anything (e.g. insanely large amounts of time) on it :( Please correct me if I am wrong, but for any large project, Haskell actually adds more woes (e.g. laziness induced problems, no good debugging support) than the ones it addresses. The Standard Chartered people had to invent a new language (mu) [1] which doesn't have laziness and the horrors associated with it. BTW, you can get anything done even in (any Turing complete) assembly language too! [1] http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf Edit: added the Standard Chartered example
  - bbcbasic 10y ago
    Was just jokingly comparing Haskell which is general purpose to elm which is for the web only.
  - wyager 10y ago
    >laziness induced problems This is like saying that Java has "strictness induced problems". It's true, but probably disingenuous. Obviously large, well-funded strict object-oriented projects have memory leak problems as well (all browsers). > no good debugging support One generally doesn't require as much debugging support for Haskell, but it's actually quite nice if you follow a debugging process amenable to pure functional languages. People coming from a Java background want e.g. a breakpoint debugger, which doesn't really make any sense at all in a pure functional language; a vastly superior approach is to do e.g. quickcheck-style checking or input/output debugging on pure functions. If your code is impure, you can essentially debug like normal. Bugs in Haskell also aren't the same as most of the bugs in other languages; you never get null pointers, for example. Every bug in Haskell is either a logic bug (which can often be debugged purely, and can be minimized by the careful application of types) or an atotality bug (which can be completely avoided by totality/completeness checking, and dynamic debugging of such bugs is getting much better with the new implicit callstack feature added to recent versions of GHC).

mahyarm 10y ago

Haskell has compile time problems when used in real project (tm) codebase scales and is hard to predict memory or cpu usage due to it's lazy nature sometimes. I have no idea if elm is any better in that case, but both things make me scared to use it in production systems.

ruslan_talpa 10y ago
This is a way to introduce space leak detection in your tests http://neilmitchell.blogspot.ro/2015/09/detecting-space-leaks.html http://neilmitchell.blogspot.ro/2015/09/detecting-space-leak... so that you can sleep well and not be afraid of using Haskell in big projects :)

bjz_ 10y ago

> But my understanding is that strictness for Elm was chosen mainly to overcome issues with FRP, which it's now abandoned Laziness also requires you to ship a runtime, which is annoying on the web. Plus it's hard to debug performance problems, and you need more language complexity to allow you to opt-out of it. There are ways to opt-in to laziness in Elm via libraries, which seems to be becoming accepted as the right way to do things these days.

bjz_ 10y ago

moosingin3space 10y ago

Elm seems to have a much stronger developer UX story than Haskell (just look at how much better its error messages are than ghc's), and the ability to share data models across the frontend-backend border would be awesome -- an end-to-end typechecked stack with easy sharing. With Elm on the server too, you could easily implement server rendering to initialize the page for fast load times.

deleted 10y ago
[deleted]