Role of popularity in the explainer

[js-choi]

Spinning this out of #206, #200, #203, #205, #167, #100, #116, and #154.

The explainer does not currently explain the role of popularity in its decision making.

TC39 generally does not rely on popularity studies. Popularity of some library or pattern might indicate that there is something worthwhile to investigate, but TC39 representatives generally do not consider it an important factor when considering the best choice for the language. (See #206 (comment) and #215.) Additionally, popularity studies are notoriously unreliable and prone to selection bias. There may be a “silent majority” of developers who would prefer F# pipes—or there may be a “silent majority” of developers who would prefer Hack pipes—but we will never know: all we know is that a lot of people want some pipe operator (and all that meant to TC39 was that pipes were worth revisiting).

To emphasize, it is likely than an attempt to switch from Hack pipes to F# pipes will result in TC39 never agreeing to any pipes at all; syntax for partial function application (PFA) is similarly facing an uphill battle in TC39 (see HISTORY.md). I personally think this is unfortunate, and I am willing to fight again for F# pipes and PFA syntax, later—see #202 (comment). But there are quite a few representatives (including browser-engine implementers; see HISTORY.md about this again) outside of the Pipe Champion Group who are against improving tacit programming (and PFA syntax) in general, regardless of Hack pipes.

This is a frequently asked question. The explainer needs to talk about this in an FAQ section. This issue tracks the fixing of this deficiency in the explainer (lack of documentation regarding usability studies’ role and Mozilla’s prior usability study). Please try to keep the issue on topic (e.g., comments about the popularity of either pipe style would be off topic), and please try to follow the code of conduct (and report violations of others’ conduct that violates it to tc39-conduct-reports@googlegroups.com). Please also try to read CONTRIBUTING.md and How to Give Helpful Feedback. Thank you!

[gulbanana]

If one version of pipes was popular enough to trigger revisiting the idea, and the other is not (I do not know whether this is the case), but only the insufficiently-popular version is considered feasible by implementors, that’s an argument against having pipes at all.

[ljharb]

@gulbanana i don't see how it would be, even in that case. Just because, in your hypothetical, it wouldn't be solving use cases for the majority, it'd still be solving them for the nonzero minority, which would be a net benefit to the language.

To be clear; I don't agree your hypothetical applies here, but even if it did, see above.

[gulbanana]

I'm starting from the position that additions to the language have to overcome some utility bar to be worthwhile. All else being equal, adding new features is bad, because they increase complexity. Maybe TC39 doesn't think that way though.

[ljharb]

@gulbanana i agree with that, but the utility bar isn’t “it must help the majority”. Hack will be useful to a great many programmers; it just won’t be useful in the same ways or to the same group as F# would be.

[voronoipotato]

What evidence do we have for that though? I don't think people will use placeholder pipes at all, you think that they will catch on. Why? Something having more uses, doesn't mean it's easier to use, in fact frequently the opposite is true. #225 . Expressions are expansive, I haven't even seen every expression be talked about and whether it should or shouldn't be valid with placeholders. Can we create classes using placeholders? How do you destructure with placeholder pipes, because {a, b, ...rest} = {a: 10, b: 20, c: 30, d: 40} just gives the original object. I think in principle they sound awesome, and in practice they're going to be super duper confusing because they're totally new. Not bringing this up to hammer it out here, we can talk it out in #225 but what metric or qualities are we using to figure out if it will be useful? Which issue would be best to talk about which expressions should be invalid (if any) with a placeholder pipe?

[ljharb]

Every expression must be valid, period, and will be. With do expressions, every statement will also be valid.

This is already the case with the body of concise arrow functions, and it's fine even though sometimes people write unclear code that has an assignment as the expression.