181–190 of 450 posts
I haven't used Elm, so I have no horse in this race. But I feel like I've been hearing these stories for a while, that it started out as an interesting and useful language but kept having features removed in new versions. Since it's open-source, and apparently there are existing projects in older versions of Elm that would effectively be held hostage by these feature removals, I'm amazed there hasn't been a (well-kno…
They could call it pine.
Earlier quoted context omitted.
This kind of leadership gave us Go. It's not necessarily bad. If everyone gets their way with the language specs, then all languages will look like a weird dialect of C++ :)
You'll find examples on both sides. Rust is a great example of a successful language growing in the open.
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.
Earlier quoted context omitted.
Yep! If people used tabs, then everyone can display it how they like and these stupid discussions wouldn’t be necessary. Alas, for some reason the world has rallied behind spaces. Sigh.
It doesn't really solve the problem. How do you format this code with tabs: function name(arg1, arg2, arg3 The other issue is with maximum line length. If you have a maximum line length of 80, do tabs count as 2 spaces, 4 spaces, or 8 spaces towards meeting that line length? Using spaces ensures that it at least looks consistent, independent of your tabstop settings.
So in this case:
function name(arg1, arg2,
arg3
Or you live with misaligned arguments (its a bit of a smell imho to have so many arguments that you need to split them over many lines, although it for sure does happen) and just use tabs for both.
My main point is that with tab, each individual has some control over their preferences, even if not perfect for alignment, while with spaces everyone has to live with the standard and nobody has control over their preference. That is, tabs is "mostly people get what they want", spaces is "nobody gets what they want unless they happen to want the style guide imposed on them". The former seems a lot better to me!
I feel quite uncomfortable hitching my wagon to a single developer who owes me nothing.
Elm wasn't the right language/community for this author and that's ok, not everything is for everyone. I use and love elm as something to write my side projects in. It has a zen like appeal for many reasons: - No runtime exceptions in practice, so you are developing against the compiler and almost never need to manually test what you're writing - Very opinionated about how to do most things. There's usually just one…
May I ask, how are you doing i10n?
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
Why not? The OP claims that his opinions are explicitly mentioned in accepted definitions:
> some of which are explicit in accepted definitions of the term
If the OP is going to make that claim, why should we not expect to be able to find validation for his assumptions in a written definition of open source?
For me, the best thing I got from this critique was the link to this 2018 talk by Evan: The Hard Parts of Open Source, https://www.youtube.com/watch?v=o_4EX4dPppA I found Evan's talking style really entertaining and enjoyable, and I totally relate to the first part about "why don't you just..." and "have you thought about delegation..."! The HN comments here are near uniformly negative towards Elm and supportive of L…
What really ended up bugging me was the patronizing "we're doing this for your own good" response given to every reasoned attempt to question these choices. In the end, Elm definitely had lots of excellent ideas, but I'm happy I don't need to deal with it any longer.
Earlier quoted context omitted.
the last thing i want is to get into drama with developers of a project, so if my choices are to give up and leave or fork and face drama, then i'll give up and leave. how that affects the Open Source status of a project is irrelevant, this is simply not a project that i could use, and thus for all intents and purposes, for me at least, it's a project that can't be forked.
If you fork quietly, you can avoid the drama. Just do your thing and don't respond to anyone (in any forum) who isn't reasonable and civil. Don't start drama, don't feed drama.
there have been hostile forks in projects before, even those that eventually had a good ending. egcs for example.
i was part of such a forked project too. it wasn't meant to be hostile, and the drama was limited to the project leaders, but it happened, and feelings got hurt.
not everyone is willing to take that risk.