Hacker News Reader

Comment by ambrozk | Hacker News Reader

Yep. And the core team has that "happy cult" vibe where they think that if they're (passive-aggressively) polite enough, they don't have to worry about anyone's opinion outside their insular little group. I tried to use it for a little project about a year ago, ran into some problems, and, searching around, found my problems were 1. not unique to me, and 2. were definitely not going to be solved by the language designers, despite a lot of people having the same suggestions. Their attitude is "either you design your app how we'd prefer you to or you don't use Elm at all." This doesn't work in any other technical project, but they think it's going to work for them for some reason.

View on HN

"Happy cult" vibe is exactly how describe that faux-niceness they throw around. Thanks for coining that phrase.

Honestly, the boldness of the opinions is also what makes elm well designed.

I never really used it, but I see plenty of other languages that are perhaps too much driven by consensus rather than vision.

Opinionation is often useful but it's best implemented with an escape hatch of some sort for when you run into a sufficiently weird situation there's not actually a sensible way to deal with it.

I don't particularly mind if a project holds their opinions sufficiently strongly that they mark the escape match big red letters with "BY USING THIS YOU ARE VOIDING YOUR WARRANTY, IF IT BREAKS YOU GET TO KEEP BOTH HALVES" and then tapping the sign any time somebody asks for support with using it, but it should still -exist-.

The escape hatch is Haskell. The only reason Elm exists is to remove escape hatches from Haskell.

The escape hatch of elm is the ports system to interface with javascript.

Ports is explicitly async and therefore only viable for a significantly limited subset of purposes.

This has been discussed at length elsewhere in this thread, on elm related discussion boards, and in multiple articles.

Ports is the -preferred- way to interface with javascript, certainly, and when its inherent limitations aren't a deal breaker, its being preferred is entirely sensible.

It is not, however, an escape hatch in any meaningful way, hence why people were extremely upset when the actual escape hatch was disabled by maintainer fiat.

I guess I am less strict with what I consider an escape hatch. It does not need to be optimal or follow my preferred method IMHO.

Other than performance I do not see any limitation of the async port system. You can call back from the js side. It is an especial way, I agree, but one that keeps the Elm paradigm intact. It is quite clever. It is "different", but I do not consider that a limitation, but a matter of preference.

I think it's also fine to just say no when people ask for an escape hatch. Say, no and tell them use another tool.

Not every tool, has to solve all problems.

But I do think people should spend more time articulating what their tools don't do, rather than what they do :)

What were those problems you ran into?

Reply on news.ycombinator.com