-
Notifications
You must be signed in to change notification settings - Fork 107
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
Comments
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. |
I accidentally voted twice. I didn't realize you could embed a poll within a GitHub issue |
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.
...this does...
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? |
According to @ljharb (and others) here: #157 (comment) Paraphrasing:
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.) |
@aadamsx you are actually misquoting that quote, and changing the meaning of it.
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. |
@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. |
@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. |
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! |
@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. |
The way you originally phrased it here:
. Breaking the sentence down:
The step I'm trying to accomplish now with this vote to get at what the "community prefers"
Which, according to the voting, I'm going to starting working on. . I think my statement above makes this clear:
. 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) |
@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. |
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 <= |
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. |
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. |
@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 ) |
@mikestopcontinues There's discussion about the differences between Smart and F# in #134 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 |
@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 So, I guess this is to say, my personal recommendation is still to push the F# proposal, but maybe hold back on 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. |
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. |
@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. |
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. |
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. |
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. |
Closing this issue, as the proposal has advanced to stage 2 with Hack-style syntax. |
Due to overwhelming commentary that voting is not the route to take to get consensus, I've taken down the poll.
The text was updated successfully, but these errors were encountered: