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

41–50 of 218 posts

Re: Elm is Wrong

#41

Post by mikekchar »

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…

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.

Re: Elm is Wrong

#42

Post by mikekchar »

hawkice wrote: post #31
the_duke wrote: post #24

Earlier quoted context omitted.

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.

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 polymorph…

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.

Re: Elm is Wrong

#43

Post by mfukar »

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

Re: Elm is Wrong

#44

Post by mfukar »

chillitom wrote: post #21

Such aggressive tone, no need, very off putting and unconstructive. If I was considering employing the author and came across this article I'd be seriously put off despite the fact he clearly knows a thing or two.

> very off putting and unconstructive

One of those is irrelevant and the other one is false.

There's a lengthy, clear description of a problem, with a use case, leading up to a feature request...how is all of that "unconstructive"?

In fact, what's definitively unconstructive is the way the feature request is closed: dismissing the use case as invalid, despite the fact there's a description of the rationale behind it in the comments.

Re: Elm is Wrong

#45

Post by mfukar »

prepor wrote: post #17
the_duke wrote: post #7

Earlier quoted context omitted.

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…

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

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

Re: Elm is Wrong

#46

Post by dwenzek »

logicallee wrote: post #34

Leo Tolstoy on War and Peace: "I decided to write a detailed story about events surrounding the French invasion of Russia, and the impact of the Napoleonic era on Tsarist society, as seen through the eyes of five Russian aristocratic families; since I haven't used the language before, for kicks I decided to do it in Swahili. This blog post will summarize why I hate Swahili and why it's totally unsuitable for writing…

I agree.

The post's tone is a bit harsh and could be more respectful. After all, there is no consensus for type classes, [ML's modules being an alternative](https://existentialtype.wordpress.com/2011/04/16/modules-mat...)

Nonetheless, the post is interesting and worth the reading because it raises true questions. For instance, I was surprised to learn that adding a field to an extensible record was no more a feature.

Re: Elm is Wrong

#48

Post by ccapndave »

Despite the abrasive tone of this article, it is true that Elm misses a convenient level of abstraction (whether that be type classes, module functors or whatever).

I spent the first few weeks of my first Elm project fighting against the language, trying to emulate type classes, build abstractions, do things like I would in other languages and generally having a bad time. Eventually, and with slightly bad grace, I conceded to the current limitations of the language and did things the Elm way, accepting that sometimes things are bit boilerplatey and cumbersome.

Now my second large Elm project is currently in its first round of QA, and the difference to similar projects in Angular or React is striking. There are no (and I mean ZERO) runtime errors that have popped up during testing. When QA find a bug, its instantly clear exactly where in the codebase the problem is, and usually simple to fix. So far most serious issues have ended up ultimately being consequences of a poor choice of design/modelling that, when fixed, has ended up in a higher quality overall codebase.

Yes, things could be better, and I'm sure they eventually will be. We would all like the kind of abstractions you talk about in your article, but in my real-life experience it turns out that you don't need them to write powerful and high quality code.

And hey, when these kinds of abstractions do arrive I'll just refactor my code, and know that the compiler will tell me when its done. Imagine doing that in Javascript.

Re: Elm is Wrong

#49

Post by seliopou »

chenshuiluke wrote: post #16

What's a good alternative to Elm?

For nearly half a decade, you have been able to compile OCaml[0] to JavaScript with js_of_ocaml[1]. For a comparison of writing native bindings for both Elm and OCaml (and some TodoMVC code that uses them), check out elm-d3[2], and ocaml-d3[3]. elm-d3 predates the virtual-dom library and was therefore the first Elm library to provide a direct interface to HTML. It also predates the removal of signals in 0.18, so it needs to be ported. Been having some difficulty with that. I've had the native code blessing to publish it for a couple years, but never have.

[0]: http://ocaml.org/

[1]: http://ocsigen.org/js_of_ocaml/

[2]: https://github.com/seliopou/elm-d3

[3]: https://github.com/seliopou/ocaml-d3

Re: Elm is Wrong

#50

Post by seliopou »

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…

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/archi...

[1]: https://github.com/evancz/elm-graphics

Post reply on HN