Live data from Hacker News

Why I’m Leaving Elm

lukeplant.me.uk

241–250 of 450 posts

Re: Why I’m Leaving Elm

#241

These posts (and HN comments) really make me wonder if adopters of fringe languages are always going to be thin-skinned developers who get emotional when they realize they won't be part of the language's design decisions. That "On Whose Authority" rant about Clojure complains about the exact same things. And I'll refer to Rich Hickey's response: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au... . Elm in…

> most people would agree that user packages shouldn't be able to invent yet more custom operators I'm actually curious why; I have yet to see people actually abuse operators outside of C++, and those were in the standard library …

This can be a problem in Haskell, where you can find a library using some operator like +>>* that you haven't seen before, imported from one of its 30 odd globally addressed modules, which may just be re-exporting other modules.

Hoogle/google rarely help with such operators, so finding any documentation is often an exercise in frustration, scanning through library after library for one declaration.

Re: Why I’m Leaving Elm

#242

Earlier quoted context omitted.

> most people would agree that user packages shouldn't be able to invent yet more custom operators I'm actually curious why; I have yet to see people actually abuse operators outside of C++, and those were in the standard library …

https://www.haskell.org/arrows/syntax.html has entered the chat

Hah, you beat me to it.

Re: Why I’m Leaving Elm

#243
post #64

Earlier quoted context omitted.

I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions. That is acknowledged in the article. But the fact is that you can BE open source without doing the things that make open source WORK. [...] Elm users who are not happy should f…

> Why should unhappy Elm users do this instead of going to a language+environment that they don't have to fork to get something usable for them? Of course they can do that, but then they are not Elm users, which makes them off-topic to the question of what Elm users should do to move forward as Elm users. > requires a lot less energy and commitment. We don't actually know that for sure without looking at the size of…

It still makes them not practising elm users. Who have a voice and a say within the community.

Re: Why I’m Leaving Elm

#244
I used Elm in 0.18. I actively campaigned for its use. After 0.19, I actively campaign against it.

Back when I chose Elm, ReasonML and ReasonReact was not around. That is what I would choose instead now. I am currently stuck with an Elm 0.18 app that I'll need to convert to React or bucklescript-tea.

Elm's leadership and as a result the community around it is super arrogant and toxic.

Re: Why I’m Leaving Elm

#245

Earlier quoted context omitted.

I don't see anything about making a fork in the linked GitHub issue. (The word "fork" appears once elsewhere, in an unrelated context in a different comment.) The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly co…

The comment immediately before rtfeldman's references patching the compiler for this project, which is an implied necessity if js code is to continue to be used. It's essentially a soft-fork, and that is what rtfeldman is objecting to.

Thanks, fair enough although rtfeldman appears to be responding to spookeylukey about divergent design goals, while it's norpan who is talking about maintaining a locally patched compiler.

I still see no objections to maintaining a fork or local patch from rtfeldman. Just "if you go against our explicit design goals don't expect us to want to merge it upstream for first-class support".

TBH a locally patched compiler sounds like not a huge deal to me. I have lived with locally patched GCCs before :-)

But maybe I'm unusual. I surprised someone, once, when they found some code not working and I suggested they look at their compiler source for the cause. Their response: "Wow, I hadn't ever thought of the compiler as something that might have a bug, let alone read and modify it".

Re: Why I’m Leaving Elm

#246
post #78
post #64

Earlier quoted context omitted.

I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions. That is acknowledged in the article. But the fact is that you can BE open source without doing the things that make open source WORK. [...] Elm users who are not happy should f…

Because every single one of these posts is "I like Elm, I don't like Evan('s style of leadership)." All of these leavers could've maintained that fabled community fork they want with the features they want if they all got together.

And if it worked, they either A) split the userbase in half and make Elm LESS likely to be useful or B) get most of the userbase and make Elm totally irrelevant.

Forking a language isn't like forking a tool. Forking gcc doesn't make C any better or worse. Forking C (if you could) would make the C worse.

Re: Why I’m Leaving Elm

#247
post #215
post #87

Earlier quoted context omitted.

If you're using/contributing to a open source project that is famous for it's non-community development and BDFL leadership style, it should come as no surprise when that continues. That's pretty much the central thesis of the article. With detail and examples on exactly what the leadership problem is and why it causes challenges for users. The call for "If you're not happy you should fork the code" comes because thi…

> the leadership problem It's only a problem for the ones who misunderstand the model. It's not a problem, it's by design. It's explicitly setup so that Evan has the final say in everything. > What I mean by "work" is that it leads to successful projects. By a variety of metrics for success. I'm always interested in hearing what metrics people are using for "success", so do please list them so we can be on the same p…

> And yet any attempt to do so is described by them as knifing Elm in the back.

Do you have an opinion on open source communities that threaten and seek vengeance against their own forks?

Re: Why I’m Leaving Elm

#248
post #59

Earlier quoted context omitted.

Agree. I'm gonna be honest and say I haven't finished the entire article so author might have elaborated further after, but I got a chill when reading the following passage: > The second is that if you advertise something as Open Source, there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term. It seems the "common set of assumptions" is around that pe…

> I continued reading and found bunch of more passages where the authors understanding of open source seems to be incorrect. The author is one of the "core team" members of Django[0]. So, it is safe to say that whatever assumptions he has about open source is not a fantasy and cannot be compared line-by-line to a text book definition of open source. [0] - https://lukeplant.me.uk/personal.html

[deleted]

Re: Why I’m Leaving Elm

#249

Earlier quoted context omitted.

> most people would agree that user packages shouldn't be able to invent yet more custom operators I'm actually curious why; I have yet to see people actually abuse operators outside of C++, and those were in the standard library …

This can be a problem in Haskell, where you can find a library using some operator like +>>* that you haven't seen before, imported from one of its 30 odd globally addressed modules, which may just be re-exporting other modules. Hoogle/google rarely help with such operators, so finding any documentation is often an exercise in frustration, scanning through library after library for one declaration.

How does Hoogle not help with such operators? Hoogle can search over all packages in the Stackage package set and can also be installed locally to look over all the dependencies of your project.

Re: Why I’m Leaving Elm

#250

These posts (and HN comments) really make me wonder if adopters of fringe languages are always going to be thin-skinned developers who get emotional when they realize they won't be part of the language's design decisions. That "On Whose Authority" rant about Clojure complains about the exact same things. And I'll refer to Rich Hickey's response: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au... . Elm in…

I've watched Elm since its inception when Evan was posting about his experimental FRP project on r/haskell. (Yep, Elm actually started as a functional reactive programming language. That was before The Elm Architecture was developed and all that terminology was thrown out.)

As the project has developed, I have certainly wished Evan had taken a different and more open approach to leadership. I think Elm could be 10x as big as it is right now if he had aggressively encouraged community involvement instead of trying to lock the language down so much.

That said, it's completely mystifying to me how Elm is surrounded in so much drama, and it seems implausible and unreasonable to attribute it all to Evan. In the early days, it started getting hate from some hardcore Haskellers who felt that it needed more sophisticated language constructs. They would have converted it into PureScript, which clearly has never gained any widespread traction either -- perhaps less so than Elm despite all the drama. This is probably one of the earliest sources of conflict where Evan went against what a vocal minority wanted. Since then, it seems to have just snowballed, with the Elm team getting more locked down and vocal users becoming more and more upset about not being involved.

At the end of the day I don't really know what to make of it. Elm would not be Elm if Evan had listened to all the aggressive requests to make Elm more like Haskell. It would still be stuck in FRP-land and 99% of web developers wouldn't be able to make heads or tails of it.

What I will say is this. I have written some internal tools in Elm, and it's one of the best languages I've ever used for web development. It's a revelation of what the web ecosystem could look and feel like in a parallel world. Years later, I would still pick Elm for such projects because nothing else comes close from certain perspectives. I can always go get the normal experience with TypeScript and React. Elm is what I choose for self-contained applications where I don't need and don't care to deal with all the general chaos of the web world. And, personally, I doubt Elm would be this way if the early naysayers had gotten what they wanted.

Post reply on HN