New pattern matching doc
Brian Goetz
brian.goetz at oracle.com
Fri Jan 15 18:45:21 UTC 2021
Back in August
(https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-August/002342.html),
I posted something about how we should engage on this list, because we
fell into one of the classic traps:
> So, what happened is what always happens on mailing lists -- I put out
> a multi-page writeup reflecting hundreds of hours of research and
> incorporating years of discussion, and 99% of the discussion was a
> too-loud, back-and-forth thread on a relatively uninteresting corner
> case on the subject of whatever happened to be the first
> strongly-stated opinion.
And that this common phenomena has a bad side-effect -- it crowds out
valuable discussion:
> The result is that we didn't have a substantive discussion on the
> other 99% of the proposal, and some folks may even have been
> intimidated by the back-and-forth (see, for example, Tagir's comment:
> https://twitter.com/tagir_valeev/status/1293931093066997761) and held
> back on their feedback. I would be very unhappy if we missed out on
> Tagir's feedback because we had made the environment inhospitable
> because of a long back-and-forth on a less important topic.
So I proposed some guidelines:
> Let me reiterate some guidelines for discussion, that hopefully will
> keep us from finding ourselves in this corner too frequently. I've
> said all this before, but its good to repeat once in a while.
>
> - Be aware that syntax discussions always suck up the oxygen. Once
> the syntax discussion starts, it is unlikely any substantive
> discussion on the more important issues will take root. (With the
> right model, the right syntax can be found later; the wrong model
> can't be saved even with the best of syntax.) So please, save these
> until you're confident that you -- and everyone else -- have said what
> have to say about goals, models, success metrics, and the like first.
>
> - Be mindful the shape of the reply chain. The best discussions
> usually have wide but shallow trees, where many people comment, but no
> reply-chain goes too long. The worst are usually long and narrow.
>
> - Lead with uncertainty. Things usually start on the wrong foot if
> we lead with "X is wrong" or "You should do it Y way instead." Better
> to ask rather than tell; there's a good chance that the proposal
> author has already spent a lot of time thinking about the problem and
> may already have considered X or Y, or there may be bigger-picture
> issues that have motivated the proposed direction.
>
> - The trivial crowds out the substantial. We all have a tendency to
> "I'll just reply quickly with the trivial stuff", because that's easy
> and we're busy. But very often these things tend to dominate the
> discussion. Probably best to try to cover everything in your first
> draft (or ask questions if you're stuck) rather than send the trivial
> comments first.
Unfortunately, this current thread is bordering on ticking all these boxes.
We're now deep in a sub-thread on translation (which I even asked we not
talk about now), which isn't really even about translation, but really
seems to be about lobbying for a preferred form of expression in the
user model:
> pattern method decompose itself nicely to tuples + two new keywords match and no-match.
So please (everyone, not just Remi): can we just start again here? This
document reflects a deep statement about the role of pattern matching in
the language. There will be ample time to discuss how it is surfaced,
but until we have a shared understanding of the model and where we're
going, I don't think it makes sense to talk about how it is expressed or
implemented. (Trust me, I've thought about these things too.) There's
a method to my madness here; this is a big topic, and I want to nail
down where we're going before we talk about how we get there. Shared
understanding first.
If you think this direction is all wrong and this direction is complete
garbage, it's OK to say that (constructively), but otherwise, please,
we're off the trail, and I would like to get back on -- and get ALL of
us on together.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210115/56f0fcd4/attachment-0001.htm>
More information about the amber-spec-experts
mailing list