41–50 of 450 posts
Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work. Breaking changes were negligible in the beginning. But I got fed up with rewrit…
Arrogant is the most accurate word to describe Elm and its leadership. I tried to use Elm in production between 0.14 and 0.18 versions and it was fun and mind expanding experience. I'm truly grateful that I've used it because it introduced a lot of functional stuff to me. But I no longer use it myself or recommend it for any serious work. Breaking changes were negligible in the beginning. But I got fed up with rewrit…
isn't this the exact problem that tabs solve?
This post resonates with me. I'm not deeply involved in Elm, I just have an Elm side project (started on 0.17) with roughly 1k lines of code. Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of thought went into it. It's very focused and has great (albeit sometimes non-obvious) solutions for almost everything. However, the leadership style is also what keeps me from recommending Elm to anyone…
Earlier quoted context omitted.
this is, at least, consistent with my experience using elm on a side project. Dropped elm like a hot potato when I hit that wall. frustrating, too, because I was really enjoying the language, and everything about it up to that point. The tooling support for Elm is REALLY solid compared to some other functional compile-to-js languages out there. If anyone is looking for a good functional compile-to-js language, I woul…
My brief experience has been similar. Elm is a dictatorship that could be wonderful if it didn't exist in the realm of messy html/js. I experience an icky feeling of stockholm-syndrome part of the time, and just plain frustration at other times when dealing with Elm. What's infuriating is that I do see the benefit of some degree of strict stewardship. It's just that it's too much in this case.
This post resonates with me. I'm not deeply involved in Elm, I just have an Elm side project (started on 0.17) with roughly 1k lines of code. Do I love Elm? Yes, definitely. It's such a well-designed language. Lots of thought went into it. It's very focused and has great (albeit sometimes non-obvious) solutions for almost everything. However, the leadership style is also what keeps me from recommending Elm to anyone…
Can you put your finger on each of those and why you think they exist? The only one that makes sense to me is the last one if that means, that people can use hacks and use private apis they were never supposed to use?
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. Interaction style and personalities are also not part of the definition of open source; open source doesn't mean nobody is brusque or abrasive. Some communities have additional…
Your suggestion for the problems with this project is "Why don't you just fork it and maintain your own?"
Something seems a bit off in the reasoning. The only reason you can't fork something is that either you don't have all the code, or there is a license problem.
One way not to have all the code is that there is a dependency on specific SaaS server installation, whose source code isn't available. If that's the case with Elm, I missed the coverage of it in the article somehow. I did get the part that the packaging ecosystem depends on a particular server controlled by the Elm project.
1. Well, not a solution for the project, but for some of its unhappy users. The project, as such, perhaps doesn't even feel that it has these problems that require solving.
> For example, if there is a bug in any core library, or something missing, you just have to wait for the core team to fix it, rather than being able to fix it yourself. You might need a performance fix, which can be done using Javascript but not in Elm (lack of destructive updates makes some things very hard to implement efficiently), and again you will be stuck having to explain to your boss “I know this is possibl…
This is one of the biggest reasons why I think ReasonML is better.
> For example, if there is a bug in any core library, or something missing, you just have to wait for the core team to fix it, rather than being able to fix it yourself. You might need a performance fix, which can be done using Javascript but not in Elm (lack of destructive updates makes some things very hard to implement efficiently), and again you will be stuck having to explain to your boss “I know this is possibl…
this is, at least, consistent with my experience using elm on a side project. Dropped elm like a hot potato when I hit that wall. frustrating, too, because I was really enjoying the language, and everything about it up to that point. The tooling support for Elm is REALLY solid compared to some other functional compile-to-js languages out there. If anyone is looking for a good functional compile-to-js language, I woul…