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.
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."
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.
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.
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 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.
[0] https://github.com/paf31/purescript-thermite
> [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.
[0]: https://www.seas.harvard.edu/sites/default/files/files/archi...
Elm has inspired ... the development of ReactJS
I could just as well suggest you mentally substitute the phrase helping the needy with kicking puppies whenever you encounter it.
Could you provide an example of when it doesn't?
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.
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.
Being nice is good.
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.
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.
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.
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.
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.
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.
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.
Agree. [0]
[0] Substitute FRP for Subscriptions ~ http://elm-lang.org/blog/farewell-to-frp
Actually, you can... as long as you properly isolate the control. Here is a prof of concept that does just that:
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?
Can you give a few examples? Google is not being helpful.
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.
It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky language i.e. JS that is usable to the point that people are doing professional work in Elm. Also the compiler produces easy to understand messages.
Evan has made Functional reactive programming more accessible. I don't think I would have a chance to understand FRP at all without Elm. Elm has inspired other frameworks in Purescript and the development of ReactJS.
Sure Elm is not perfect. I found that much of the JS ecosystem not viable in the Elm world, even with FFI due to the purity of the virtual dom. I can't just go and easily chuck an impure calendar control in my code.
However despite it's drawbacks I feel the article was a bit strong in putting down Elm, which is sad because I think there are the seeds of some great future languages and ideas in there.