6 ms·

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_4EX4dP

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 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 Luke's criticisms. Fair enough, it's a reasoned critique and those are definitely issues that would affect users. I found the critique informative and useful. I don't use Elm though I've watched with passing interest for a while. Now I feel there are gotchas or expectations I should be aware of if I'm considering using it, about the way the project is heading. But I felt it came off way more entitled than I'm comfortable, mainly when Luke starts moralising, placing ethical obligations upon Evan. That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person".

hombre_fatal 7y ago
> That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person". I mention this in my top-level comment, but here's Rich Hickey of Clojure responding to similar assertions: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/ https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au... > Clojure was not originally primarily a community effort, and it isn't primarily one now. That has to be ok. The presumption that everything is or ought to be a community endeavor is severely broken. A true community respects the autonomy of its participants, else it degenerates into a cult of need/want. The people who write these "I'm leaving X" posts must know they have disproportional power in such a tiny pond. Imagine writing the same post about Javascript or Java because you thought it was supposed to be a democracy or something. Nobody would even read your post.
- a_c 7y ago
  Oh, I was knee jerked into replying this thread and didn't realised the same comment was made!
- pd-andy 7y ago
  > The people who write these "I'm leaving X" posts must know they have disproportional power in such a tiny pond. This is what I find so disappointing and likely why many "thin-skinned" users come out to defend the language when posts like this come out.
- lolc 7y ago
  Let's take Java as a point of reference, since you brought it up. Imagine the JDK were opinionated about which authors were allowed to write packages that use FFI. And people wanting to use it would be instructed to build a relationship to said authors to get their code blessed to use FFI. It is wholly inconceivable. I'm sure you'd see quite a few "Leaving Java" posts over it.
  - deleted 7y ago
    [deleted]
  - hnbroseph 7y ago
    your scenario isn't all that different from how the jdk authors view the use of internal classes, like sun.misc.unsafe.
    - lolc 7y ago
      Here's what Oracle says[0]: "Technically, nothing prevents your program from calling into sun.* by name." And I don't think I ever accessed sun.* when writing Java. So the example seems both ill-suited and far-fetched to me. One of the first things I did in Elm was writing a tiny JS snippet to get a missing piece from the browser. It was something I needed and my site wouldn't have worked without it. I later switched to the Elm implementation once that became available. Now given the stated goals of the Elm project, I will be unable to repeat this. Which means I expect I'd be stuck if I again wanted to access the browser API before the Elm people got around to implement that part. And that wholly changes my view of the project. I'm using Elm for a toy project. If I'm blocked, I go do something else. What a pity though. [0] https://www.oracle.com/java/technologies/faq-sun-packages.html https://www.oracle.com/java/technologies/faq-sun-packages.ht...
- mellow2020 7y ago
  > Nobody would even read your post. Is there anything factual in the post you take issue with?
a_c 7y ago
Reminds me a comment made by Rich Hickey https://news.ycombinator.com/item?id=15425632 https://news.ycombinator.com/item?id=15425632 Quoting top comment: “The presumption that everything is or ought to be a community endeavor is severely broken.” I believe in the BDFL model but can see history repeating itself. Being open source doesn't mean everyone is equal, and it shouldn't
- palerdot 7y ago
  I think you are missing the whole point of this discussion and it is no way similar to the Cloure/Rick Hickey incident. No one is asking for disproportionate say in language design. Everyone agress on that. The problem with Elm is their messaging about their production readiness, luring people to try things out for critical production systems and then pull the rug out from under in the name of 'this should be the right way to do things; you are doing it wrongly', when people are already neck deep with their solutions in their production systems. As an aside, there is no way we can compare Clojure to Elm, as the former is unimaginably brilliant in giving access to the host/target platform (JVM) so that people can get all the benefits of the battle tested libraries of Java/JVM. This Elm saga is completely the opposite. Elm core team is trying so hard to prevent people from using more tested and stable solutions from the JS world without offering them an alternative.
fxtentacle 7y ago
The article's criticism about the 0.18 to 0.19 issues is spot-on, but I agree with you that the author comes off as feeling entitled. The reason why Elm is fun to work with is that it's Evan sharing his hobby project with you. And that's it. There is no support, no long-term maintenance, no implied warranty, nothing. Still, it works for me :) and it is Open Source in the way that I can fix bugs myself, if I have to. One of the reasons why I chose to not do open source myself is because of people like the author here. You give someone free source code for a useful tool and they'll come back and ask for you to fix their issues. For example, I once patched a Heroku buildpack because I needed it to work. Due to how GitHub works, my fork was public. A while later, Heroku linked to it. And then I started getting a lot of messages from whiny entitled pricks. Apparently, they thought that it would be my duty to provide support to them. For free, of course, because it's open source... I'm pretty sure Evan had a similar experience and that's why Elm comes with no support, no warranty, and no way for you to influence it.
- Talanes 7y ago
  If something is just your personal, no-pressure, hobby project, maybe don't convince people to implement it in production?
  - foldr 7y ago
    People have to take responsibility for their own decisions about what to use in production.
- afiori 7y ago
  personally I believe this is dependent on the marketing. elm market itself as production ready and reliable. that should mean that existing projects will not be scrapped by design. I mean, this is even worse than python 2/3 I would totally be on elm side if the project came with a "not ready for long term investment or production" with it. even in the real world this makes a difference. if I tell you that you can freely camp for the winter on an empty lot and invite some friends for free I cannot just evict you because I found someone who would pay. (in the real case likely you would sign a contract where you renounce this right). similarly a project that invite users to use it loses some rights in term of calling others entitled when they raise some expectations
klntsky 7y ago
Great talk indeed. I feel like it might be helpful to online communities to add a real "intent" field to their posting forms, like here in this video: https://youtu.be/o_4EX4dPppA?t=2489 https://youtu.be/o_4EX4dPppA?t=2489
asdfasgasdgasdg 7y ago
> That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person". But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. I mean, it's open source. You have no contract with the maintainers and so there is no real entitlement to any specific behavior. Hell they could have the compiler try to detect whether you're someone who engages in wrongthink and refuse to work for you if so, and you'd have no legal right to complain. On the other hand, it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs who have a habit of doing this. So, I won't be using Elm, and that's probably for the best both for me and the Elm core maintainers.
- jlokier 7y ago
  > But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. But that is asking for work! That's a great example of "why don't you just... $TRIVIAL" where $TRIVIAL = "turn off the restrictions", as if there is no consequent problem for the upstream author to have to figure out how to achieve the design goals of the project afterwards, or manage the explosion in issues with modules that may potentially emerge, or who knows which other concerns (I'm just throwing out some guesses; don't take them seriously.) It's a great example of what Evan describes in the video, of a seemingly trivial request whose potential complex consequences are not seen by the requestor, but are seen and must be dealt with by others; and of conflicting priorities. Essentially it is a request to the author: "I ask that you spend time to revise your design to figure out how to allow my module's techniques to keep working at the same time as achieving the design goals of Elm going forward, and reverse your design decision that you have already made". > I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. You have not blocked them. As many commenters have pointed out, you don't have to wait, you can fork. You can fork quietly if you don't want social issues from making a big noise, as vast numbers of developers do with a vast numbers of projects. If the upstream author is not making it easy for the downstream module author, perhaps requiring the downstream author to maintain a patched version of the compiler and persuade other people to use the patch, tough. There's isn't and shouldn't be any moral obligation on the upstream to screw their design goals to accomodate that particular downstream author. I've had to maintain patched Linux kernels for a project. I didn't resent Linux upstream for that. I didn't complain that I needed to patch the kernel. It was just part of the cost of doing my project. It limited what I could expect to do, but I went into it informed of what to expect. > it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. I agree. It's more than prefer for some. A certain slice almost demands it and makes life hard for any author who does not provide. For which the word is "entitlement". Unfortunately that slice has a subslice who wants something self-cancelling: A non-paternalistic project that talks with them at length patiently, accomodates most requests no matter how varied and contradictory, yet still produces a coherency of design, magic-sauce artefact for them, preferably on a regular release cycle with QA, with nobody's time and personal needs covered. In other words, what they want isn't always feasible, yet they still demand it from individuals (often via emotional pressure), rather than start their own projects. > Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs I agree wholeheartedly. And that's the advice given to Luke by an Elm developer in 2018! :- https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i... Sounds like Luke chose to ignore the advice, then was angry 1.5 years later. I think it can be argued that the person ignoring the advice is the one who creates the later problem for themselves. > If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. I think that comes under excusing abuse by saying it's inevitable that someone will do it. Public rage-posts about someone's work are still abuse if the basic problem is that the other person didn't do what you wanted them to. What we should have, in a "good" world, is that people like Evan should be able to produce their projects in relative peace without abuse. If people don't like the project, in the "good" world people know what to expect and are free to start their own alternative. I think the Evans of the world lose in our current world, no matter what they do. If they are less paternalistic, they will have both an ever-increasing workload until they step down, and the project will not fulfil their design wishes so it's much less rewarding.
henriks 7y ago
I guess your perspective on these "gotchas or expectations" changes depending on how invested you are in the language. I worked on an Elm project that ended up fairly large. We started at 0.14, and each version upgrade became progressively more difficult because of changes made to the language and to the runtime. Some of the changes were understandable, such as wanting to change the direction of the platform by dropping FRP, while others were not, such as disallowing inline operators, or dropping methods from the standard library just because the BDFL decided he'd prefer for people to do things differently. 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.

hombre_fatal 7y ago

> That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person". I mention this in my top-level comment, but here's Rich Hickey of Clojure responding to similar assertions: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/ https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au... > Clojure was not originally primarily a community effort, and it isn't primarily one now. That has to be ok. The presumption that everything is or ought to be a community endeavor is severely broken. A true community respects the autonomy of its participants, else it degenerates into a cult of need/want. The people who write these "I'm leaving X" posts must know they have disproportional power in such a tiny pond. Imagine writing the same post about Javascript or Java because you thought it was supposed to be a democracy or something. Nobody would even read your post.

a_c 7y ago
Oh, I was knee jerked into replying this thread and didn't realised the same comment was made!
pd-andy 7y ago
> The people who write these "I'm leaving X" posts must know they have disproportional power in such a tiny pond. This is what I find so disappointing and likely why many "thin-skinned" users come out to defend the language when posts like this come out.
lolc 7y ago
Let's take Java as a point of reference, since you brought it up. Imagine the JDK were opinionated about which authors were allowed to write packages that use FFI. And people wanting to use it would be instructed to build a relationship to said authors to get their code blessed to use FFI. It is wholly inconceivable. I'm sure you'd see quite a few "Leaving Java" posts over it.
- deleted 7y ago
  [deleted]
- hnbroseph 7y ago
  your scenario isn't all that different from how the jdk authors view the use of internal classes, like sun.misc.unsafe.
  - lolc 7y ago
    Here's what Oracle says[0]: "Technically, nothing prevents your program from calling into sun.* by name." And I don't think I ever accessed sun.* when writing Java. So the example seems both ill-suited and far-fetched to me. One of the first things I did in Elm was writing a tiny JS snippet to get a missing piece from the browser. It was something I needed and my site wouldn't have worked without it. I later switched to the Elm implementation once that became available. Now given the stated goals of the Elm project, I will be unable to repeat this. Which means I expect I'd be stuck if I again wanted to access the browser API before the Elm people got around to implement that part. And that wholly changes my view of the project. I'm using Elm for a toy project. If I'm blocked, I go do something else. What a pity though. [0] https://www.oracle.com/java/technologies/faq-sun-packages.html https://www.oracle.com/java/technologies/faq-sun-packages.ht...
mellow2020 7y ago
> Nobody would even read your post. Is there anything factual in the post you take issue with?

a_c 7y ago

Reminds me a comment made by Rich Hickey https://news.ycombinator.com/item?id=15425632 https://news.ycombinator.com/item?id=15425632 Quoting top comment: “The presumption that everything is or ought to be a community endeavor is severely broken.” I believe in the BDFL model but can see history repeating itself. Being open source doesn't mean everyone is equal, and it shouldn't

palerdot 7y ago
I think you are missing the whole point of this discussion and it is no way similar to the Cloure/Rick Hickey incident. No one is asking for disproportionate say in language design. Everyone agress on that. The problem with Elm is their messaging about their production readiness, luring people to try things out for critical production systems and then pull the rug out from under in the name of 'this should be the right way to do things; you are doing it wrongly', when people are already neck deep with their solutions in their production systems. As an aside, there is no way we can compare Clojure to Elm, as the former is unimaginably brilliant in giving access to the host/target platform (JVM) so that people can get all the benefits of the battle tested libraries of Java/JVM. This Elm saga is completely the opposite. Elm core team is trying so hard to prevent people from using more tested and stable solutions from the JS world without offering them an alternative.

fxtentacle 7y ago

The article's criticism about the 0.18 to 0.19 issues is spot-on, but I agree with you that the author comes off as feeling entitled. The reason why Elm is fun to work with is that it's Evan sharing his hobby project with you. And that's it. There is no support, no long-term maintenance, no implied warranty, nothing. Still, it works for me :) and it is Open Source in the way that I can fix bugs myself, if I have to. One of the reasons why I chose to not do open source myself is because of people like the author here. You give someone free source code for a useful tool and they'll come back and ask for you to fix their issues. For example, I once patched a Heroku buildpack because I needed it to work. Due to how GitHub works, my fork was public. A while later, Heroku linked to it. And then I started getting a lot of messages from whiny entitled pricks. Apparently, they thought that it would be my duty to provide support to them. For free, of course, because it's open source... I'm pretty sure Evan had a similar experience and that's why Elm comes with no support, no warranty, and no way for you to influence it.

Talanes 7y ago
If something is just your personal, no-pressure, hobby project, maybe don't convince people to implement it in production?
- foldr 7y ago
  People have to take responsibility for their own decisions about what to use in production.
afiori 7y ago
personally I believe this is dependent on the marketing. elm market itself as production ready and reliable. that should mean that existing projects will not be scrapped by design. I mean, this is even worse than python 2/3 I would totally be on elm side if the project came with a "not ready for long term investment or production" with it. even in the real world this makes a difference. if I tell you that you can freely camp for the winter on an empty lot and invite some friends for free I cannot just evict you because I found someone who would pay. (in the real case likely you would sign a contract where you renounce this right). similarly a project that invite users to use it loses some rights in term of calling others entitled when they raise some expectations

klntsky 7y ago

Great talk indeed. I feel like it might be helpful to online communities to add a real "intent" field to their posting forms, like here in this video: https://youtu.be/o_4EX4dPppA?t=2489 https://youtu.be/o_4EX4dPppA?t=2489

asdfasgasdgasdg 7y ago

> That came over to me as "you are obliged to do a lot more work that I want you to do, on your own time and personal cost, and to stop developing the project according to your own vision or you are a bad person". But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. I mean, it's open source. You have no contract with the maintainers and so there is no real entitlement to any specific behavior. Hell they could have the compiler try to detect whether you're someone who engages in wrongthink and refuse to work for you if so, and you'd have no legal right to complain. On the other hand, it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs who have a habit of doing this. So, I won't be using Elm, and that's probably for the best both for me and the Elm core maintainers.

jlokier 7y ago
> But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. But that is asking for work! That's a great example of "why don't you just... $TRIVIAL" where $TRIVIAL = "turn off the restrictions", as if there is no consequent problem for the upstream author to have to figure out how to achieve the design goals of the project afterwards, or manage the explosion in issues with modules that may potentially emerge, or who knows which other concerns (I'm just throwing out some guesses; don't take them seriously.) It's a great example of what Evan describes in the video, of a seemingly trivial request whose potential complex consequences are not seen by the requestor, but are seen and must be dealt with by others; and of conflicting priorities. Essentially it is a request to the author: "I ask that you spend time to revise your design to figure out how to allow my module's techniques to keep working at the same time as achieving the design goals of Elm going forward, and reverse your design decision that you have already made". > I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. You have not blocked them. As many commenters have pointed out, you don't have to wait, you can fork. You can fork quietly if you don't want social issues from making a big noise, as vast numbers of developers do with a vast numbers of projects. If the upstream author is not making it easy for the downstream module author, perhaps requiring the downstream author to maintain a patched version of the compiler and persuade other people to use the patch, tough. There's isn't and shouldn't be any moral obligation on the upstream to screw their design goals to accomodate that particular downstream author. I've had to maintain patched Linux kernels for a project. I didn't resent Linux upstream for that. I didn't complain that I needed to patch the kernel. It was just part of the cost of doing my project. It limited what I could expect to do, but I went into it informed of what to expect. > it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. I agree. It's more than prefer for some. A certain slice almost demands it and makes life hard for any author who does not provide. For which the word is "entitlement". Unfortunately that slice has a subslice who wants something self-cancelling: A non-paternalistic project that talks with them at length patiently, accomodates most requests no matter how varied and contradictory, yet still produces a coherency of design, magic-sauce artefact for them, preferably on a regular release cycle with QA, with nobody's time and personal needs covered. In other words, what they want isn't always feasible, yet they still demand it from individuals (often via emotional pressure), rather than start their own projects. > Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs I agree wholeheartedly. And that's the advice given to Luke by an Elm developer in 2018! :- https://github.com/gdotdesign/elm-github-install/issues/62#issuecomment-415860947 https://github.com/gdotdesign/elm-github-install/issues/62#i... Sounds like Luke chose to ignore the advice, then was angry 1.5 years later. I think it can be argued that the person ignoring the advice is the one who creates the later problem for themselves. > If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. I think that comes under excusing abuse by saying it's inevitable that someone will do it. Public rage-posts about someone's work are still abuse if the basic problem is that the other person didn't do what you wanted them to. What we should have, in a "good" world, is that people like Evan should be able to produce their projects in relative peace without abuse. If people don't like the project, in the "good" world people know what to expect and are free to start their own alternative. I think the Evans of the world lose in our current world, no matter what they do. If they are less paternalistic, they will have both an ever-increasing workload until they step down, and the project will not fulfil their design wishes so it's much less rewarding.

henriks 7y ago

I guess your perspective on these "gotchas or expectations" changes depending on how invested you are in the language. I worked on an Elm project that ended up fairly large. We started at 0.14, and each version upgrade became progressively more difficult because of changes made to the language and to the runtime. Some of the changes were understandable, such as wanting to change the direction of the platform by dropping FRP, while others were not, such as disallowing inline operators, or dropping methods from the standard library just because the BDFL decided he'd prefer for people to do things differently. 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.