Hacker News Reader

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.

I don't think the response was as simple as "No, you can't have that because I don't want to". Reading the discussion about removal of this feature on Github there seems to be a few more points made that the author alludes to: https://github.com/elm-lang/elm-compiler/issues/985

Also, It's worth noting that Elm does have a BDFL. Evan makes the call and, as I'm sure a lot of python folks would agree, that setup means that the language is going to remain consistent, clean and well defined. This might be frustrating, but is part of keeping a strong design philosophy that directs the language. In that context, is it really a valid criticism?

Evan actually addresses this issue directly by talking about the different communities with different aims. He says that having these different communities with different design decisions makes the whole scene a lot stronger[1]:

> if you go back a year so on the mailing list you'll see a lot of people talking about type classes "when are we going to have this in Elm?", "we need this", "this is the most important thing", and a language came out that had different priorities and all the people who wanted that kind of feature started using that language and so now that's not to say one of the communities is making a better choice than the other, it just means we can all experiment with a different philosophy and way of thinking and do well."

[1] https://youtu.be/DSjbTC-hvqQ?t=178

It was exactly one comment from evancz, which says: "I don't want to readd this feature...I think it makes sense to continue discussion in this issue if you think there are valid use cases". Here [1] is the actual feature request.

The existence of a BDFL is irrelevant. This rejection is frustrating whether it comes from one person, or a committee, a peer, whatever, because it is arbitrary and unjustified. The feature wouldn't compromise the design philosophy nor its consistency. "I don't want this" is not a design philosophy, and neither is "your use case is invalid".

The use case is actually solid. Writing readable, maintainable code which is conceptually easy to understand in the span of a few paragraphs, like in the blog post.

[1] https://github.com/elm-lang/elm-compiler/issues/1283

PS. I'm certain evancz has a reasoning behind his wish to keep the feature out of Elm. He just doesn't communicate it, which makes the decision seem arbitrary.

When he removed the feature it was after consulting the community (https://github.com/elm-lang/elm-compiler/issues/985).

It has a dictator for life, but given the article doesn't seem like the B is earned yet :P

The "B" is never earned. In OSS it's usually as ironic as the "D".

Many languages with "BDFL"s have many contributors to core functionality. Elm does not seem to. For open source projects, that's pretty much a death sentence: although I appreciate Evan going off and solving hard problems with beautiful solutions, he can't do all the major work alone and expect to have a healthy, growing, open source project.

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.

Can I ask if you have found any equivalent to the Elm Architecture in Purescript?

I have looked at Elm, and Purescript and now Bucklescript, but I have not yet seen, or wired up myself, something like the Elm architecture.

I should probably buckle down and learn the wiring I need myself, but I have been finding the typing a little tough.

Yep, there are several.

[0] https://github.com/paf31/purescript-thermite

[1] https://github.com/alexmingoia/purescript-pux

[2] https://github.com/slamdata/purescript-halogen

Purescript Pux looks to be what you're looking for https://github.com/alexmingoia/purescript-pux/

I've made https://github.com/agrafix/purescript-apparch

> it got me to start thinking about what I wanted in a functional language that compiles into JS

I investigated Elm just after the 0.17 release, decided I was fine with it but didn't really love the language. I've since moved to investigating F# and the Fable compiler. While it's unlikely that someone who prefers Purescript would prefer an ML derivative, I feel I should mention it for other people reading the thread from the front page and prefer having imperative escape hatches.

The Ocaml to JS compilers (Bucklescript/js_of_ocaml) also produce nice js output but my background with Clojure has left me enjoying the benefits of being a functional language that's part of a larger ecosystem and I'm comfortable enough with .net core to be willing to treat F# as a viable language outside windows.

I agree with most of this, but I beg to differ with the last bit :

> [writing] some Elm code on server side [...] just seems like putting a square peg in a round hole

We are actually writing server-side elm for a living. We mostly have a Scala background and we actually think elm is a pretty great fit for backend code.

Agreed, the absence of typeclasses is a limitation of the language. Yes, it means, you can't have a `Set RandomObject` or `Dict RandomObject SomethingElse` (among other things) and that can get pretty frustrating for folks coming from almost any other strongly typed language.

However the real question here is not "is this language worthless because of that", but rather "can I overcome that limitation for my specific use case ?".

My personal take : - If you are considering a switch from JS to elm (server or client), the point seems moot, as the language features described here are far from being available in JS. - elm suits _some_ server side application very well. Not _all_ server side application.

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

   Elm has inspired ... the development of ReactJS

I don't think that's true. React is a descendant of XHP, and predates Elm. Perhaps you were thinking of Redux?

ReactJS introduced virtual DOM before Elm did (Elm first used virtual-dom a lib that was developped quite some time after the release of react, and now uses a new custom implementation) redux was inspired by the "Elm architecture" where everything is global but composed by object/record keys at all levels of the tree.

Elm's virtual dom was inspired by Clojurescript's om, which was based off of React. So yeah, this is not true.

I've been writing in Clojurescript. To be honest - every time I see a new discussion thread about something new in Javascript-land I can't stop thinking that Clojure and Clojurescript are almost always a few steps ahead of the crowd.

Used to write in clojure and clojurescript myself. While it's definetly nicer than React, React did come first (om and reagent are just bindings around React. The way om and reagent are faster than React out of the box, is what inspired Elm's vdom module).

BTW, why lots of people think it's very wrong and immoral to criticize inanimate pieces of technology in rude and offensive language? Political correctness?

There are people on the other end of the screen who built the technology, and they have feelings :)

Being nice is good.

And being polite ("nice") makes it more likely that people who don't yet know each other well will receive mutual advantage through collaboration.

someone posted this to HN the other day https://wiki.lesswrong.com/wiki/Crocker%27s_rules .. I thought it was quite good, it means sometimes articles like this, with their emotional language gives you information that is useful... IF you refuse to take offense to it.

Whenever you feel the urge to use, or see others using the term political correctness, try mentally substituting it with behaving respectfully. The exercise can be enlightening.

That doesn't seem like a useful exercise because political correctness does not always equate to behaving respectfully, even if there is overlap (i.e. most respectful behaviour is politically correct and vice versa).

I could just as well suggest you mentally substitute the phrase helping the needy with kicking puppies whenever you encounter it.

political correctness does not always equate to behaving respectfully

Could you provide an example of when it doesn't?

"safe spaces" in Universities.

I see no use of the term political correctness.

For example, mocking masculinity/men, white people, Conservative people, etc is all "politically correct". I would not call it respectful to call Trump voters deplorables or to belittle issues that men face, but it's certainly not politically incorrect.

I think I see what you mean, but in my experience, this is not how most people understand or use that term. Wikipedia backs me up on this:

The term political correctness (…) in modern usage, is used to describe language, policies, or measures that are intended primarily not to offend or disadvantage any particular group of people in society.

Yes. Generally, tone policing in HN gets stronger with the passage of time. Many comments in here complain about the tone without even touching on the point.

Here's how I see his point.

He came to Elm expecting a Haskell for the web. Elm has the completely opposite philosophy of keeping things simple, even if it means extra boilerplate.

I can understand OP's frustration, but if he watched a few of Evan's talks (like this one https://www.youtube.com/watch?v=DSjbTC-hvqQ), he would realise his expectations about Elm are wrong. Also, he forgot that Elm (just like any other open source project) doesn't owe him anything. That's why many people take an issue with his tone.

In summary, Elm's target audience are JavaScript developers. It's developers who want their apps to be more robust and easier to refactor than in plain JavaScript. Sure, type classes are useful but they also increase complexity. Evan wants to see if there's a better solution and the Elm community generally accepts that.

> He came to Elm expecting a Haskell for the web

No, I don't think that's true. He came to Elm hoping there would be some useful ways to create abstractions in the language (that doesn't necessarily mean there has to be typeclasses. in fact, the whole article his him pursuing an alternate method of abstraction), and besides creating a function there really is none in Elm.

You must resign yourself to write the same boilerplate over and over. It is impossible to keep any large Elm project DRY.

and who cares? fork the project and add the feature yourself. when I buy banana yogurts at the supermarket, I don't write to the yogurt company asking to change the flavour if I don't like it. I just buy a different brand of yogurt. Elm is even free as in free beer and free speech!

There is a limited interaction between yogurt buyers and yogurt makers that solely consists of buying or not buying stuff. There is more interaction between programming language creators and programmers and indeed between programmers about their tools.

Analysis in depth is a useful thing for not only the creator who is likely to already understand the trade offs he has made but for other current and potential users of the language.

> Also, he forgot that Elm (just like any other open source project) doesn't owe him anything. That's why many people take an issue with his tone.

We can't take issue with his tone by appropriating information about Elm's direction in an ex post facto manner. The guy - whatever guy - is a newcomer to Elm, picks it up, see an obvious deficiency, asks (quite politely, I might add) about a feature addition, gets a dismissive answer. That's the context. We can't apply Evan's* rationale behind the reply here, because the OP never had the chance to have it revealed to him to the extent of his interaction.

I'm surprised I have to point this stuff out. However understanding we may be, surely we can see why anybody is frustrated with being dismissed like this?

* Apologies, but I don't actually know Elm's author's last name.

Is Elm open source? If so, couldn't the author implement the feature themselves? If the maintainer doesn't want it, then idk, fuck off? Nobody said he had to use it. When did open source turn into "Do whatever random people tell you to do, for free"? Talk about entitlement....

> Is Elm open source? If so, couldn't the author implement the feature themselves?

Yeah!

Just create and maintain your own damn dialect of a language!

It's OPEN SOURCE, that means you automatically know and are an expert in anything it involves!

It's 2016, we can stop with that meme now.

As I said in my post, I understand OP's frustration. I understand that he expected more consideration for his efforts to learn the language and his suggestions for improvement.

The deficiency was only in his eyes though. Evan and the Elm community are fully aware of the type classes thing, because it's been mentioned by many people. He just doesn't see it as something that requires an immediate solution.

To summarize: I understand OP's frustration. At the same time, Elm (just like any other open source project) doesn't owe him anything. If you open a pull request or an issue you are not guaranteed a resolution in your favor. Ranting will help you vent but that's it.

> Many comments in here complain about the tone without even touching on the point.

Then we'll either have to change all those commentators, or the original author – since one of the arguments against faul language is that it distracts.

I can't speak for it being immoral, but basically, using rude and offensive language tends to undermine rational discourse. If your purpose is get at the truth, then it is prudent to avoid such language.

However, a lot of writing (academic, journalistic, what have you) has "getting at the truth" as only one of its goals among many, including "expressing my feelings," "attacking someone else," "playing with poetic language," "sounding smart," etc.

"Evan has made Functional reactive programming more accessible."

Agree. [0]

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

> I can't just go and easily chuck an impure calendar control in my code.

Actually, you can... as long as you properly isolate the control. Here is a prof of concept that does just that:

https://github.com/fredcy/elm-polymer-calendar

This is no judgement on Elm as I have not used it.

I feel like RxJS and Cycle.js both make functional reactive programming quite accessible to JavaScript developers without the burdensome overhead of an entirely new language for the frontend.

Have you used these frameworks, and if so could you articulate why Elm would be a better alternative?

> Elm has inspired other frameworks in Purescript and the development of ReactJS

Can you give a few examples? Google is not being helpful.

One that comes to mind (for Purescript) are the error messages.

> Unfortunately this is an opinionated piece with foul language and it is a bit offensive.

Whenever you read "X is offensive", mentally replace it with "I find X offensive". The substitution emphasizes how little being offended ought to matter.

Your finding this piece offensive does not create an obligation on the part of anyone else. I am growing very tired of social critics attempting to turn the world into inoffensive mush. We need more articles of this kind.

> It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky language

I agree that the effort is remarkable. The idea that the strength of the author's effort should somehow shield his work from criticism is antithetical to excellence. It's participation trophy culture. If we're to create great work, we have to understand the difference between good and bad work, and we can't do that if misplaced concern for someone's feelings stops our describing reality as it is.