6 ms·

> It would appear that you misunderstood what I said. Could be. The point of the paragraph after this seems to be self-evident (if an abstraction is unavailabl

> It would appear that you misunderstood what I said. Could be. The point of the paragraph after this seems to be self-evident (if an abstraction is unavailable, then you use a lower-level alternative). If that was what you meant, then I agree...and I don't think I needed to have read SICP to know that. ;) > This was because the community leaders/ members were often quick to dismiss any suggestions/ complaints offered instead of patiently exploring them. I would describe this particular issue as having been "patiently explored to death." Here are several links demonstrating this: [0] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_8L-AL6EJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_... [1] https://www.youtube.com/watch?v=oYk8CKH7OhE https://www.youtube.com/watch?v=oYk8CKH7OhE [2] https://github.com/elm-lang/elm-compiler/issues/1039 https://github.com/elm-lang/elm-compiler/issues/1039 [3] http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorphism-or-typeclasses http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorph... > Elm not facilitating the use of sufficient level of abstractions [...] I had never got the impression that the Elm community was going to fix those problems any time soon. [...] Indeed your characterizing of this thread as talking about some `spooky "abstraction wall"` is a testament to that. This quote characterizes Elm as not having "sufficient level of abstractions" and that these are "problems" that are not being "fixed." My reference to the "abstraction wall" is also a direct quote from a previous comment. [4] All of these quotes frame personal preference as objective fact. It's like saying Java is "broken" because it does not support manual memory management, which no one seems "interested in fixing" by adding `malloc()` and `free()` to the language. Plenty of people would (rightly!) be upset if Java introduced `malloc()` and `free()`, thus breaking the invariant that everything is garbage collected. Likewise, there are many happy Elm users, myself included, who think Elm would be substantially worse if it moved toward the abstractions that PureScript embraces. The fact that Elm doesn't is a benefit from our perspective, even if it's a drawback from yours. Neither of us have "wrong" preferences. There's no universally correct answer here. We can both go about building Web applications in our languages of choice. This distinction may not matter to you, but to someone wondering whether Elm is worth looking into, there's a big difference between "I am inevitably going to hit a wall" (which is not true) and "not everyone agrees with Elm's design decisions" (which is of course true). [4] https://news.ycombinator.com/item?id=14877406 https://news.ycombinator.com/item?id=14877406

sridca 9y ago
The level of abstraction a programming language provides is a verifiable fact. At what minimum level a programmer is comfortable working with is a personal preference. If Elm’s type system is not sufficient to provide that level of abstraction it is certainly a problem to me that has not been resolved in the language. For all we know, other people may have different preferences; some may be content working with vanilla JavaScript and some even with assembly instructions. I don’t think anyone denies this, and you seem to be defending something that was never challenged. As for Elm’s approach to dealing with discussions of this nature, out of the four links you had provided the last three were unilateral messages (the Github issue in particular is locked to collaborators with only a message from Evan). As for the Google Group thread it perfectly demonstrates the feeling I have had with the Elm community. Paul Chiusano (who had the same problem as me) in that thread finally got frustrated due to lack of patience and exploration among the participants; it is quite odd you would use this as a demonstration of the Elm community patiently exploring something. His exact words: What I find frustrating about this is that when conversations get ugly, the actual issues are not given sufficient attention and people just end up responding to the general unpleasantness and the labels being tossed around. I still feel like we have not really gotten to the bottom of things, but I don't have much hope that this thread will get us there and would rather just drop it for now like Joey suggests.
- rtfeldman 9y ago
  At what minimum level a programmer is comfortable working with is a personal preference. [...] I don’t think anyone denies this, and you seem to be defending something that was never challenged. Since it sounds like we're in agreement on this being a matter of personal preference, I'm happy to move on. :) Paul Chiusano (who had the same problem as me) in that thread finally got frustrated due to lack of patience and exploration among the participants; it is quite odd you would use this as a demonstration of the Elm community patiently exploring something. Paul wasn't frustrated due to a "lack of patience and exploration among the participants," he was frustrated that "let's be patient and explore this further" was the outcome of the discussion--instead of the outcome he wanted, which was getting his feature requests being prioritized higher. I'll break it down. First, here is a quote from Evan's first response in that thread: [0] Since very very early on, type classes have been requested by Haskell programmers. My opinion is that these features create serious accessibility problems in Haskell, even for people such as myself who came to Haskell already knowing Scheme, Standard ML, and OCaml. I was three years in to Haskell before Monad Transformers were clear to me. So I have always looked at these things not just as features to be implemented, but unsolved design problems. How do we present these ideas in a way that is super simple? How do we grow our community in a smart way? A question to think about for type classes is, what is the best way to reuse variable names? Type classes, implicit arguments, and module functors all answer this question, but each comes with some unfortunate tradeoffs. My view here is that there is no need to rush. When our community collectively needs this kind of feature, we will be in a much better position to evaluate the trade-offs between these approaches for the problems we are facing in practice. Some things to note: 1) He asks specific questions to invite exploration. "What is the best way to reuse variable names? How do we present these ideas in a way that is super simple? How do we grow our community in a smart way?" 2) He explicitly calls for being patient with that exploration: "My view here is that there is no need to rush." Following this are a bunch of posts which include a mix of discussion about these questions and a debate about prioritization. Paul then posted: [1] This is turning into an interesting discussion and I'm very tempted to wade in, but honestly, I'd just like an answer to my earlier question about timeline for the non-controversial features. He's being incredibly clear about this: he found the exploration interesting, but was more interested in knowing Evan's timeline than participating. Fair enough. At this point we can rule out the conclusion that Paul "finally got frustrated due to lack of patience and exploration among the participants" - because he stated, in no uncertain terms, that despite being tempted by an interesting discussion, that's not what he wants. What he wants is an answer about the prioritization of his feature request. Evan responded, and Paul responded back: [2] Okay, thanks for the reply. And I appreciate all the hard work you are putting into Elm! [ ... ] Here's something to consider when prioritizing work [ ... ] Features like HKP + rank-N types / typeclasses are like an investment in the whole community, and they can have huge leverage. So he's not interested in participating in the discussion, or in directly answering the questions Evan posed at the start of the thread, but he still wants Evan to accept his feature request. I get that, but I'm not sure how the person who is essentially saying "I do not want to participate in a patient exploration with the community, I think these features should be added as soon as possible" can be held up as supporting evidence for the notion that the Elm community is closed to patient exploration. Later, about 50 posts deep in this thread, an Elm community member named Sean finally got frustrated with how someone else named Jonathan was advocating for his (and Paul's) point. Sean quoted Jonathan's comment that "I find it very hard to believe that you have all the requisite understandings and yet still reject these ideas" and responded by saying "And this is exactly the sort of condescending stuff that puts people off the Haskell community. As soon as someone doesn’t agree with you, you question their ability. Lovely." [3] Jonathan responded "So I think we have our answer-- no, you don't even understand what you are rejecting. Brilliant." This obviously heated exchange was what led Paul to write what you quoted, which I'll re-quote with additional context of Paul's comment: [4] Jonathan, I share some of your frustrations but I think you should be much more careful in how you say things. [ ... ] Sean, whether or not you think your characterizations of Jonathan are accurate, I think some of your comments were unhelpful and uncharitable toward Jonathan. [ ... ] What I find frustrating about this is that when conversations get ugly, the actual issues are not given sufficient attention and people just end up responding to the general unpleasantness and the labels being tossed around. So he's frustrated that this heated exchange got in the way. The rest of what you quoted was: I still feel like we have not really gotten to the bottom of things, but I don't have much hope that this thread will get us there and would rather just drop it for now like Joey suggests. As Paul made extremely clear in the quote from earlier, what he's talking about here is that he wants Evan to accept his feature request. He's not saying he felt there was insufficient exploration; in fact, he thought that exploration was "an interesting discussion and I'm very tempted to wade in" - his objection is that the discussion's outcome - "be patient; this is an unsolved design problem and we need to gather more real-world data points before we can solve it" - was not the outcome he wanted. To recap: 1) Evan calls for patient exploration 2) Some patient exploration happens 3) Paul comments that the exploration has been interesting, but it's not what he wants. Really what he wants is a timeline for when the features will be prioritized. 4) Much later in the thread, two commenters get upset at one another. 5) Paul expresses frustration that their getting upset is distracting the thread from what he wants, which is to get his feature request accepted. Hopefully this clears things up. :) [0] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_8L-AL6EJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_... [1] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/dwvwD7yYX68J https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/dwvw... [2] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/qf_9ETPgsvoJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/qf_9... [3] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/_i-opQnpgCcJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/_i-o... [4] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/H9NG31Q6ONIJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/H9NG...

sridca 9y ago

The level of abstraction a programming language provides is a verifiable fact. At what minimum level a programmer is comfortable working with is a personal preference. If Elm’s type system is not sufficient to provide that level of abstraction it is certainly a problem to me that has not been resolved in the language. For all we know, other people may have different preferences; some may be content working with vanilla JavaScript and some even with assembly instructions. I don’t think anyone denies this, and you seem to be defending something that was never challenged. As for Elm’s approach to dealing with discussions of this nature, out of the four links you had provided the last three were unilateral messages (the Github issue in particular is locked to collaborators with only a message from Evan). As for the Google Group thread it perfectly demonstrates the feeling I have had with the Elm community. Paul Chiusano (who had the same problem as me) in that thread finally got frustrated due to lack of patience and exploration among the participants; it is quite odd you would use this as a demonstration of the Elm community patiently exploring something. His exact words: What I find frustrating about this is that when conversations get ugly, the actual issues are not given sufficient attention and people just end up responding to the general unpleasantness and the labels being tossed around. I still feel like we have not really gotten to the bottom of things, but I don't have much hope that this thread will get us there and would rather just drop it for now like Joey suggests.

rtfeldman 9y ago
At what minimum level a programmer is comfortable working with is a personal preference. [...] I don’t think anyone denies this, and you seem to be defending something that was never challenged. Since it sounds like we're in agreement on this being a matter of personal preference, I'm happy to move on. :) Paul Chiusano (who had the same problem as me) in that thread finally got frustrated due to lack of patience and exploration among the participants; it is quite odd you would use this as a demonstration of the Elm community patiently exploring something. Paul wasn't frustrated due to a "lack of patience and exploration among the participants," he was frustrated that "let's be patient and explore this further" was the outcome of the discussion--instead of the outcome he wanted, which was getting his feature requests being prioritized higher. I'll break it down. First, here is a quote from Evan's first response in that thread: [0] Since very very early on, type classes have been requested by Haskell programmers. My opinion is that these features create serious accessibility problems in Haskell, even for people such as myself who came to Haskell already knowing Scheme, Standard ML, and OCaml. I was three years in to Haskell before Monad Transformers were clear to me. So I have always looked at these things not just as features to be implemented, but unsolved design problems. How do we present these ideas in a way that is super simple? How do we grow our community in a smart way? A question to think about for type classes is, what is the best way to reuse variable names? Type classes, implicit arguments, and module functors all answer this question, but each comes with some unfortunate tradeoffs. My view here is that there is no need to rush. When our community collectively needs this kind of feature, we will be in a much better position to evaluate the trade-offs between these approaches for the problems we are facing in practice. Some things to note: 1) He asks specific questions to invite exploration. "What is the best way to reuse variable names? How do we present these ideas in a way that is super simple? How do we grow our community in a smart way?" 2) He explicitly calls for being patient with that exploration: "My view here is that there is no need to rush." Following this are a bunch of posts which include a mix of discussion about these questions and a debate about prioritization. Paul then posted: [1] This is turning into an interesting discussion and I'm very tempted to wade in, but honestly, I'd just like an answer to my earlier question about timeline for the non-controversial features. He's being incredibly clear about this: he found the exploration interesting, but was more interested in knowing Evan's timeline than participating. Fair enough. At this point we can rule out the conclusion that Paul "finally got frustrated due to lack of patience and exploration among the participants" - because he stated, in no uncertain terms, that despite being tempted by an interesting discussion, that's not what he wants. What he wants is an answer about the prioritization of his feature request. Evan responded, and Paul responded back: [2] Okay, thanks for the reply. And I appreciate all the hard work you are putting into Elm! [ ... ] Here's something to consider when prioritizing work [ ... ] Features like HKP + rank-N types / typeclasses are like an investment in the whole community, and they can have huge leverage. So he's not interested in participating in the discussion, or in directly answering the questions Evan posed at the start of the thread, but he still wants Evan to accept his feature request. I get that, but I'm not sure how the person who is essentially saying "I do not want to participate in a patient exploration with the community, I think these features should be added as soon as possible" can be held up as supporting evidence for the notion that the Elm community is closed to patient exploration. Later, about 50 posts deep in this thread, an Elm community member named Sean finally got frustrated with how someone else named Jonathan was advocating for his (and Paul's) point. Sean quoted Jonathan's comment that "I find it very hard to believe that you have all the requisite understandings and yet still reject these ideas" and responded by saying "And this is exactly the sort of condescending stuff that puts people off the Haskell community. As soon as someone doesn’t agree with you, you question their ability. Lovely." [3] Jonathan responded "So I think we have our answer-- no, you don't even understand what you are rejecting. Brilliant." This obviously heated exchange was what led Paul to write what you quoted, which I'll re-quote with additional context of Paul's comment: [4] Jonathan, I share some of your frustrations but I think you should be much more careful in how you say things. [ ... ] Sean, whether or not you think your characterizations of Jonathan are accurate, I think some of your comments were unhelpful and uncharitable toward Jonathan. [ ... ] What I find frustrating about this is that when conversations get ugly, the actual issues are not given sufficient attention and people just end up responding to the general unpleasantness and the labels being tossed around. So he's frustrated that this heated exchange got in the way. The rest of what you quoted was: I still feel like we have not really gotten to the bottom of things, but I don't have much hope that this thread will get us there and would rather just drop it for now like Joey suggests. As Paul made extremely clear in the quote from earlier, what he's talking about here is that he wants Evan to accept his feature request. He's not saying he felt there was insufficient exploration; in fact, he thought that exploration was "an interesting discussion and I'm very tempted to wade in" - his objection is that the discussion's outcome - "be patient; this is an unsolved design problem and we need to gather more real-world data points before we can solve it" - was not the outcome he wanted. To recap: 1) Evan calls for patient exploration 2) Some patient exploration happens 3) Paul comments that the exploration has been interesting, but it's not what he wants. Really what he wants is a timeline for when the features will be prioritized. 4) Much later in the thread, two commenters get upset at one another. 5) Paul expresses frustration that their getting upset is distracting the thread from what he wants, which is to get his feature request accepted. Hopefully this clears things up. :) [0] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_8L-AL6EJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_... [1] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/dwvwD7yYX68J https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/dwvw... [2] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/qf_9ETPgsvoJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/qf_9... [3] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/_i-opQnpgCcJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/_i-o... [4] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/H9NG31Q6ONIJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/H9NG...