Live data from Hacker News

Elm is Wrong

reasonablypolymorphic.com

31–40 of 218 posts

Re: Elm is Wrong

#31
post #17

Earlier quoted context omitted.

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

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

Re: Elm is Wrong

#32
post #28

As someone who's written a language, the need to have a personal approval from a founder before being published to the site stuck out to me more than the typeclasses. I'd argue in favor of it, so long as the review is done in a timely process. I can understand wanting a smaller number of high-quality, reviewed libraries that are tested and shouldn't break.

The restriction only applies to native modules (modules that ship with Javascript): https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9...

I think understanding the why is also important here. Native modules exist essentially for side effects. A bad native module undermines all the safety Elm provides.

Re: Elm is Wrong

#33
First, let me say that I think Evan has done amazing work with Elm, and Elm is a very interesting language on several fronts. It is a positive contribution to the world, especially the idea that error messages can be great and compilers and type systems are tools.

That said, I agree 100% that the ability to form abstractions is a critical part of any language that hopes to become a tool that larger teams and projects can adopt. Without type classes and convenient mutability, I don't see Elm achieving widespread adoption. (That said, it could gain those features in the future.)

I've been working on a language inspired to some degree by Elm but also by my experience teaching Haskell. Haskell has amazing expressive capabilities and type safety, but the unfamiliar syntax is a hurdle that many people don't care to jump. To that end, we've designed Crux to have much of the expressive power of languages in the ML/Haskell family, while being as familiar and lightweight as JavaScript or Python. The idea is that it's something you can pick up easily but it can grow with you and your project.

Some articles on the design thinking: https://chadaustin.me/tag/crux/

The website: http://cruxlang.org [It's a preview!]

Re: Elm is Wrong

#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 about Tsarist Russian society - or, I would say, anything else. Swahili is awful and needs to die."

Seriously, how can people write blog posts like this? You decided to code up a new project in a totally new language, and are here to tell us why that new language is awful. Really? Really? It's not like this is uncommon. People make these blog posts all the time! What's with this?

-------------------

EDIT: I got downvoted, but look:

>A few weeks ago, on a whim my friend and I decided to hackathon our way through an app to help us learn how to play guitar. In a stroke of inspiration, we decided to learn something new, and do the project in the Elm programming language, about which I had heard many good things.

>Consider this post to be what I wished I knew about Elm before deciding to write code in it. Since I can’t send this information into the past and save myself a few weeks of frustration, it’s too late for me, but perhaps you, gentle reader, can avoid this egregious tarpit of a language where abstraction goes to die."

It doesn't take "a few weeks" to learn a programming language!!!

Re: Elm is Wrong

#35
This post is way too angry. The problem it describes is legitimate, but still just a problem to be fixed.

Having the language maintainer need to bless packages with native bindings is strange, though. Tag the packages so that people know they use native bindings, then people can decide whether or not to trust them. You cannot build an ecosystem through one person.

Re: Elm is Wrong

#37

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…

"Evan has made Functional reactive programming more accessible."

Agree. [0]

[0] Substitute FRP for Subscriptions ~ http://elm-lang.org/blog/farewell-to-frp

Re: Elm is Wrong

#38
post #2

>I have complaints about Elm after using it during a quick hack session.

> the language is an unsurmountable pile of poorly-thought-out and impossible-to-compose new ideas on top of the least interesting pieces of Haskell For a Haskell programmer, what he tried to do (use typeclasses) is extremely common. It's some of the most basic stuff you can do. Elm is clearly modeled after Haskell, and absolutely fails to maintain the basic patterns that Haskell users take for granted.

The thing is Javascript programmers are the target audience for Elm not Haskell programmers. I can understand the frustration if you're coming to Elm with a Haskell mindset.

Re: Elm is Wrong

#39

What's a good alternative to Elm?

Depends on what you're looking for. Keep in mind that the OP came to Elm with a Haskell mindset. Elm is simpler than Haskell (yes, at the cost of some boilerplate).

If you program in JavaScript and you want a language with no runtime exceptions, go for Elm. If you want type classes, go for PureScript.

Post reply on HN