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_...
[1] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/dwvw...
[2] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/qf_9...
[3] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/_i-o...
[4] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/H9NG...