Elm is Wrong - Hackdot

Re:Elm is Wrong by the_duke on Wednesday November 09, 2016 @12:53AM (#12906519)

The post is opinionated and a bit aggresively worded.

But his(/her?) major complaint is valid: lack of type classes, which completely kills essential composability and generic properties of Haskell. And the module system doesn't offer MLs features to make up for it (signatures).

This means that Elm requires boilerplate for things that are elegantly handled by type classes.

You may also look at Purescript [1], a more complete Haskell inspired language compiling to Javascript.

Haskell is a complex language. So I'm not necessarily saying that Purescript is a good choice for the average developer unfamiliar with functional languages.

Elms 'lack of features' makes it easy to pick up. Especially if you aren't familiar with FP. But Elm is TOO simple.

[1] http://www.purescript.org/

[ Parent | on HN ]

Re:Elm is Wrong by prepor on Wednesday November 09, 2016 @01:36AM (#12906759)

You can do everything that you can with typeclasses without them. In fact GHC compiles Haskell into GHC core, where are no typeclasses.

See http://okmij.org/ftp/Computation/typeclass.html

[ Parent | on HN ]

Re:Elm is Wrong by the_duke on Wednesday November 09, 2016 @01:44AM (#12906799)

Quote from the second paragraph:

> Knowing what TEDIOUS JOB GHC is doing for us helps us appreciate more the convenience of type classes.

Thanks for the link though, I think I read it a few years ago.

[ Parent | on HN ]

Re:Elm is Wrong by hawkice on Wednesday November 09, 2016 @02:02AM (#12906912)

In truth, it's a balancing act. More than a few Haskell libraries are more tedious than Elm code (I've written upwards of 8,000 lines of production Elm but have been doing Haskell for much longer) because they're so intensely abstract.

Without typeclasses, that simply doesn't happen. I'd say 90% or more of Haskell typeclass usage is pointless, and maybe half of what remains is simple to replace with simpler polymorphism or no polymorphism.

For instance, almost everything here:

https://wiki.haskell.org/Typeclassopedia

is replaced, in Elm, by just having an explicit module reference, so Maybe.andThen instead of andThen. No joke, that replaces essentially all of it, except some stuff that's not used that often.

[ Parent | on HN ]

Re:Elm is Wrong by mikekchar on Wednesday November 09, 2016 @03:17AM (#12907657)

You're way more experienced than me in this, but it seems to me that anywhere you're going to be replacing polymorphism is going to result in more typing. If you know the module that you want, then it is trivial, but the point of type classes (IIUC) is to write generic functions that can act on a variety of types.

To replace the non-trivial cases is going to require pattern matching, it seems. If your types change, then you are going to have to update things in multiple places.

But, like you said, it's not the end of the world. In many cases the intent will probably be clearer. Still, I'd rather have type classes than not.

[ Parent | on HN ]

Re:Elm is Wrong by hawkice on Wednesday November 09, 2016 @04:45AM (#12908651)

Typeclasses aren't bad, that's for sure. I kinda want something as flexible as typeclasses and derive generic but no where near that complex. A big part of me says I could do well with just promising some JavaScript really really meets a type signature. Ports are great for side effects but I there might be room for this for pure functions?

[ Parent | on HN ]

Re:Elm is Wrong by tempodox on Wednesday November 09, 2016 @07:17AM (#12909617)

You can do everything you can do in Haskell also in assembler. Haskell compiles down to assembler, where there is no Haskell.

[ Parent | on HN ]

Re:Elm is Wrong by mfukar on Wednesday November 09, 2016 @03:28AM (#12907791)

Yes, you can, and the resulting code is an unreadable, unmaintainable mess after two weeks.

[ Parent | on HN ]