Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

attempted voting for pipeline proposal #163

Closed
aadamsx opened this issue Apr 2, 2020 · 25 comments
Closed

attempted voting for pipeline proposal #163

aadamsx opened this issue Apr 2, 2020 · 25 comments

Comments

@aadamsx
Copy link

aadamsx commented Apr 2, 2020

Due to overwhelming commentary that voting is not the route to take to get consensus, I've taken down the poll.

@phaux
Copy link

phaux commented Apr 2, 2020

F# pipeline proposal together with a separate partial application proposal would be much more versatile because you could use the placeholders not only in pipeline, but also in places like higher order functions, callbacks, event handlers, etc.

@nafg
Copy link

nafg commented Apr 2, 2020

I accidentally voted twice. I didn't realize you could embed a poll within a GitHub issue

@aikeru
Copy link

aikeru commented Apr 2, 2020

With all due respect - and I want to see some flavor of the pipeline advanced so much even if it's not my favorite flavor - TC39 is a committee, not a democracy. What meaning does this vote have to the committee? Has the committee endorsed holding a vote to decide which flavor of the pipeline operator will move forward?

If this is the path the committee would endorse, shouldn't this be widely publicized? Have you contacted newsletters, blogs, etc. to solicit more votes from the broader JavaScript community?

Also, I see the partial application proposal mentioned a lot with the F# style. I'd like to remind everyone that pushing the F# style through does not in any way mean getting partial application with it, and that partial application is still at stage 1 and has its own challenges moving forward.
Another point I'd like to make for the proponents wishing for this combination is that you can't use partial application's placeholder in an expression - it can only be used an an argument to a function. IE, this does not work...

5 |> setValue(5 + ?)

...this does...

5 |> setCoordinates(5, ?)

Finally, one last point I'd like to make - shouldn't we resolve the open issues with the F# proposal before trying to push it through?
For example, these issues are still open and seem to affect the F# flavor:
#104
#23
#82
#145
Whether the final proposal will require parenthesis wrapping arrow functions used with the pipeline operator is still an open issue ( #162 (comment) ).
Is the dangling await issue resolved? #83
Can we abandon inline arrows -> for F#? #93
I'm not saying smart doesn't have issues, but the creator of this poll is clearly strongly in favor of F# and of dropping smart, which is why I bring this up.

@aadamsx
Copy link
Author

aadamsx commented Apr 2, 2020

According to @ljharb (and others) here: #157 (comment)

Paraphrasing:

To move forward with this proposal we need to pick a solution shape “that the community prefers”

This vote is an attempt to get JS community feedback, and what better place to do that than the repository for this proposal.

The next step is to take pipes operator consensus and go to the TC39 committee with our proposal, I'm working on this now.

(Also, everyone should know this is not about partial application, it's about pipes, so please don't muddy the waters.)

@aikeru
Copy link

aikeru commented Apr 2, 2020

@aadamsx you are actually misquoting that quote, and changing the meaning of it.

To move forward, this proposal would not just have to pick a solution shape “that the community prefers” - it also has to prepare an ironclad, persuasive argument for why that shape is the only one that will make sense forever (including outlining potential extensions, or which extensions are precluded).

Bold emphasis mine. And respectfully, while you and I want the same thing, no, I do not agree with this being the best place to both solicit that feedback and to publicize it. Look at the watch numbers and stars for this repository (224 and 4.6k respectively). This is not even a tiny fraction of the JavaScript community. If you want community consensus that is meaningful, I think we are talking a large number of thousands.

You're basing your conclusion on what is, as of this writing, 20 votes for F#? That's not a community consensus. That's a single office in a small company.

Also, I'd like to see some additional questions on this - have the participants of this vote used any form of the proposal such as through Babel or in browsers that have implemented it? I'd like to at least see some basic comparisons between the two. Telling people "go read the issues" seems like you're shifting more effort to your audience at a time when you want them to fully participate and engage.

@aikeru
Copy link

aikeru commented Apr 2, 2020

@aadamsx I wish to keep my responses civil and friendly. To that end, I wish you the best in your endeavor. I hope some flavor of this proposal wins sooner than later.

@aadamsx
Copy link
Author

aadamsx commented Apr 2, 2020

@aikeru you said I was misquoting, which is clearly not what I was doing (I said I was paraphrasing), so it was kinda not being friendly to say I was doing something I wasn't.

But that's okay, no hard feelings on my side, and as you said we want the same thing, to get this pipeline operator on the stright and narrow.

@aadamsx
Copy link
Author

aadamsx commented Apr 2, 2020

@aikeru

shouldn't this be widely publicized? Have you contacted newsletters, blogs, etc. to solicit more votes from the broader JavaScript community?

I do not agree with this being the best place to both solicit that feedback and to publicize it.

Please, send me the links to the JS gathering centers you'd like for me to solicit this vote? @anyone, please?

I want to case as wide a net as possible!

@ljharb
Copy link
Member

ljharb commented Apr 2, 2020

@aadamsx #163 (comment) is a correct interpretation of my comment. Community preference for a single solution is always a good thing to have, but is not sufficient. The much more important thing is the ironclad persuasive argument - focus on that before trying to gather aesthetic community preferences.

@aadamsx
Copy link
Author

aadamsx commented Apr 2, 2020

@ljharb

The way you originally phrased it here:

To move forward, this proposal would not just have to pick a solution shape “that the community prefers” - it also has to prepare an ironclad, persuasive argument for why that shape is the only one that will make sense forever

.

Breaking the sentence down:

proposal would not just have to pick a solution shape “that the community prefers” ...

The step I'm trying to accomplish now with this vote to get at what the "community prefers"

... it also has to prepare an ironclad, persuasive argument for why that shape is the only one that will make sense forever

Which, according to the voting, I'm going to starting working on.

.

I think my statement above makes this clear:

The next step is to take this pipes operator consensus and go to the TC39 committee with our proposal, I'm working on this now.

.

Now while I'm working on this proposal, I would like to continue to solicit votes from as many JS congregations as possible, which is why I asked for links to engage the JS community: #163 (comment)

@ljharb
Copy link
Member

ljharb commented Apr 2, 2020

@aadamsx i was replying to your implication that a selection was needed. If the reason for picking one of the options is "the community prefers it", that simply won't change anything. There have to be concrete reasons it's preferred, and a poll/survey isn't useful for that. TC39 does not make decisions based on surveys, polls, or votes.

@aadamsx aadamsx changed the title JS Community Voting for Pipes Operator "Solution" (Open) [removed] Apr 3, 2020
@aadamsx aadamsx changed the title [removed] attempted voting for pipeline proposal Apr 3, 2020
@aadamsx
Copy link
Author

aadamsx commented Apr 3, 2020

@ljharb

There have to be concrete reasons it's preferred

The problem is, the idea is great, and brings JS into the functional era at last, but there is nothing really concrete about the implementation, it's all opinion and preference.

Both F# and Smart have their pros and cons, which is better depends on context, the style you prefer to write code in, how it's used, other features like partial application being implemented, etc.

How can the we move forward when the "right" style depends on who you're asking? It seems the only/best way to reslove this is pitch all the ways this could be implemented to the "committee" and have them decide its fate?

=> By the way are these panelists, that represent various companies, deciding the fate of JS these days? https://www.youtube.com/watch?v=slA06pbTRi4 <=

@ljharb
Copy link
Member

ljharb commented Apr 3, 2020

Keep in mind that “nothing” is a better choice than “the wrong thing forever”. If it’s truly that subjective, then we may want to not advance this proposal.

@aadamsx
Copy link
Author

aadamsx commented Apr 3, 2020

Keep in mind that “nothing” is a better choice than “the wrong thing forever”. If it’s truly that subjective, then we may want to not advance this proposal.

Of course it's not the idea/principle that's subjective @ljharb, it's the implementation.

@szTheory
Copy link

szTheory commented Apr 3, 2020

Just because there are multiple good ways to implement a feature would not be a good reason to block a proposal. It could just mean that you have to pick one. I would take smart pipelines over no pipelines.

@mikestopcontinues
Copy link

@aadamsx a few questions:

Is there anything that would prevent smart from being implemented on top of F#?

If not, the case everyone can agree on is that we submit them as separate, paired proposals. This would also help, because the implementation of the smart placeholder (#) overlaps with the current placeholder proposal (?). So the second proposal would be free to focus on that issue. And the second question:

What's holding us back from making one or both proposals?

If it's time, I volunteer to do as much of the legwork/writing as I can. Pipelines have become invaluable to me, and I want to see them as part of the language. (With placeholders, if possible. :D )

@noppa
Copy link
Contributor

noppa commented Apr 3, 2020

@mikestopcontinues There's discussion about the differences between Smart and F# in #134
AFAIK Smart can be implemented on top of F# if you make x |> expressionWithoutPlaceholder mean "pass x as the argument to the function that we get from evaluating expressionWithoutPlaceholder". It's currently a syntax error in Smart, because with those semantics the presence of # significantly changes how the RHS behaves and it could be hard to parse. Hard to parse for humans, that is, correct me if I'm wrong but I haven't seen anyone say that it'd be hard for a parser.

Personally, I'm skeptical that Smart would advance after F# had been accepted, given that there's a separate partial application proposal that's more general solution to the problem.

@ljharb
I don't think anyone wants to rush half-assed solution out of the door. It's just that, from an outsider's perspective, issues like "community consensus" don't seem to be worked on by anyone and the only possible outcome of this proposal looks to be a permanent deadlock. Lots of people don't want to see that happen and are eager to help move things forward, but don't know how. It's not clear what it'd take to be able to say that "solution X has community consensus", which makes it neigh impossible to help ever reach that goal.

@mikestopcontinues
Copy link

mikestopcontinues commented Apr 3, 2020

@noppa Thanks. After reading that thread, I realize I'm much less a fan of Smart than I thought. The required # have been confounding to me trying to do FP with pipelines. (I thought it was just a limitation of the babel plugin.) I realize now that I would prefer F# with the current placeholder proposal to add in the extra functionality. E.G., if ? adds currying to every function, then you could handle any given pipeline by using it in any function with more than 1 arity.

So, I guess this is to say, my personal recommendation is still to push the F# proposal, but maybe hold back on # until we know the final status of ?.

Would it be helpful to create a thread where we ask for smart-only holdouts to voice their concerns about a later proposal? Then maybe we could reduce objections and get this thing going.

@Pokute
Copy link
Contributor

Pokute commented Apr 14, 2020

Keep in mind that “nothing” is a better choice than “the wrong thing forever”.

I believe that there's a sizeable portion of pipeline operator hopefuls who think that there is no wrong choice between F# and smart pipelines for the end-user experience. From engine implementation / spec / compatibility perspective there might be such a wrong choice, but for those I expect that the proposal process will detect them first.

If a poll on pipeline implementation preference was conducted, I would like to see a mandatory second choice in the selections: smart preference over F#, F# preference over smart, F# or none, smart or bust, neither. If the count for first two selections have a majority then, in the case where both proposals end up with no winner otherwise, the final choice can be made fairly and justly with a coin toss.

I'm hoping that the proposal process will clean up both pipeline implementations to a point where after implementing one, regardless of whichever ends up being chosen, it is recognised as suboptimal forever at worst.

@pygy
Copy link
Contributor

pygy commented Apr 25, 2020

@ljharb why can't the minimal proposal move forward as is (spec'ed in a way that makes it forward compatible with either smart or F#)?

This approach is a figment of the Rust design process, and they use it with great success.

Also, the pipeline is useful for most users, but most critical for FP enthusiasts, and the minimal proposal would fit the common use case for that population.

@ljharb
Copy link
Member

ljharb commented Apr 25, 2020

Establishing that ability to augment it later would help a lot - but there’s still folks who don’t think either one is worth the syntax cost - they have to be convinced, and only meeting a subset of the use cases by intentionally shipping a subset of the semantics doesn’t seem to me like it’d be compelling enough to convince them.

@pygy
Copy link
Contributor

pygy commented Apr 25, 2020

Who are those folks?

Generally, provided the TC-39 thought that adding classes would be a good idea, I knew that promoting this operator would be an uphill battle, but I didn't expect this to last this long.

Imagine classes being derailed by FP folks who think that the objects they create should be immutable. This is what this proposal feels like.

Also, the syntax cost is minimal, and, unlike classes (TC-39: "You won't have to use them if you don't like them". WhatWG: "Hold my beer..."), they are purely local. The rest of the world won't know you use it internally, you can't expose them as part of your API.

@yordis
Copy link

yordis commented Dec 16, 2020

Related to what @phaux said: #167 (comment)

Separate partial application placeholding out of the pipe operator would move the conversation forward. I would propose to keep partial application placeholder out of the spec and decide later about such topic.

@tabatkins
Copy link
Collaborator

Closing this issue, as the proposal has advanced to stage 2 with Hack-style syntax.

@aadamsx

This comment has been minimized.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests