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

tc39/proposal-pipeline-operator debate concern #95

Closed
ken-okabe opened this issue Sep 14, 2021 · 4 comments
Closed

tc39/proposal-pipeline-operator debate concern #95

ken-okabe opened this issue Sep 14, 2021 · 4 comments

Comments

@ken-okabe
Copy link

I would like to express my concern on tc39/proposal-pipeline-operator debate.

I am a TS/JS functional programmer, and waiting "pipeline operator" in JavaScript for a long time because it's extremely important for Functional Programming that is essentially algebra.

In algebra, operator is everything, that I can say. In my understanding, most of the TS/JS functional programmer have been using F# style pipeline-operator taking advantage of Babel or TypeScript experimental support.
microsoft/TypeScript#38305

As a functional programmer, I've just waited for landing F# style, and the day before yesterday, I've noticed it's now proceeded in Stage2.

Firstly, I thought it's a good news, but investigating more, I noticed some "Hack-style" is
chosen that so far I had only known mimimal/F#/Smart.

Hack-Style is a nightmare for the most TS/JS functional programmers and can destroy the healthy eco, many are mathematicians and I also admire the Algebra including F# pipeline-operator(F# is a strong functional language).

Yesterday,
@kiprasmel started a new issue that is basically against Hack implementation, and the claimed decision process is very unclear:

tc39/proposal-pipeline-operator#205


Thus, I invite everyone to discuss this Pipeline Operator thing further, and in no way rush into Stage 3.

In particular, I'd like at least the following concerns to be addressed, especially by members of the TC39 committee, especially those involved with pipeline operators, whichever side they're favoring (but everyone else is just as welcome too):

  1. What you just read here - does it make sense, what are the shortcomings you see, what else could be improved and addressed?

  2. Did you read anything new or was literally everything already considered?

  3. Do you have any plans to carefully study the usability of the proposals, just like @runarberg highlighted that the Rust community has done? If no - why, if yes - how, and will it have any impact before we reach Stage 3? Or have you already done this and where can we find the results?

  4. Do you have any concerns that the current proposal is incomplete / half-baked?

  5. Do you have any concerns that if we move forward with the Hack proposal, without including the F#'s |>> operator together at the same time, it could lead to us missing some detail which would prevent |>> (or whatever other token choice for this functionality) from being possible, while the Hack's pipeline operator would already have shipped, and it would be too late to go back?

  6. In general and in this case, do you think a half-baked solution is better than no solution at all -- even if there are ways to implement the solution already (Functors etc.), meaning the half-baked solution isn't necessary -- even after reading this and comments/arguments from other threads linked here -- even knowing the impact that it will have -- even knowing that we've made such mistakes in the past (nodejs callbacks vs promises)?

  7. Do you know any people in the TC39 Committee who have a strong background in functional programming languages, e.g. Haskell, F#, Elixir etc? Did they participate in the discussions regarding Pipeline Operators?

  8. Were there any experts in the FP field invited to participate/help make decisions with regards to the pipeline operator? Did they help? How did the committee handle their feedback, how much weight did it have?

  9. Would it be possible in the future to be more transparent of how exactly the decision was made?

  10. What members of the TC39 committee made the decision, what members were not present (e.g. @littledan because vacation? etc.)?

  11. Do you believe that certain people not being present could sway the decision in one direction or another, why, and how do you make sure both sides are represented fairly and equally?

  12. Is it still possible to switch from Hack's to F#'s proposal? Would you help facilitate the switch if you believed that F# is better over Hack, even if the switch could further delay the landing of pipeline operators, because in the long term it would be worth it?

  13. Would there be a way to collect all information in one place (or at least clearly link to additional resources from the main source of thruth which probably should be the proposal repo README / RFC issue), as opposed to the current situation with 1) the proposal repo itself, 2) @tabatkins gist (!), 3) discourse, 4) @littledan's slides, etc.

  14. What could I or any of the JavaScript community members do to further help with this? For this proposal, and in future ones?


I share his concern or crisis awareness, and most importantly as a JavaScript functional programmer I can't stand watching JS is mathematically disgraced.

This concern is expressed as:

7. Do you know any people in the TC39 Committee who have a strong background in functional programming languages, e.g. Haskell, F#, Elixir etc? Did they participate in the discussions regarding Pipeline Operators?

8. Were there any experts in the FP field invited to participate/help make decisions with regards to the pipeline operator? Did they help? How did the committee handle their feedback, how much weight did it have?

JavaScript is functional programming language, and the pipeline operator is extremely important, however I feel some small group of persons who do not share deep knowledge decide that critical part and destroy the JavaScript that is unacceptable.

I tried to participate the issue, but a few hours ago, @tabatkins closed.

I'm going to go ahead and close this thread; it appears to have run its course, and in any case is filled with unacceptable levels of hostility. As I've said in previous threads here, new information is welcome, or arguments one feels were unfairly passed over. But this repo has three years of arguments on this exact subject already; please review those before asking the rest of us to read twenty-three thousand words in one new thread.

Perhaps, one of the comment is
image

Hack style is a bad proposal that tries to combine two great proposals: F# |> + ? partial application.
For me there's no question. F# is the only way to go. Only people who have never used pipe will prefer the Hack way.

This is so true. 100% agreed.
In fact, "partial application" proposal issue is suggested in @tabatkins gist post page:

https://gist.github.com/tabatkins/1261b108b9e6cdab5ad5df4b8021bcb5#gistcomment-3692618

It's unfortunate that partial application proposal is not mentioned here, since it complements F# pipelines. F# pipelines practically has the burden that partial application as part of F# pipeline proposal is so easily to separate as a distinct proposal that no-one can really object to separating it. Hack-style #-placeholders can not be separated into a separate proposal. Thus I feel like it's unfair to do comparisons where F# pipelines don't additionally have the partial application to help them. It results in a weird situation where the robustness of partial application actually hurts F# pipeline argument.

However, @tabatkins never reacts to these questions.
For functional programmers, this pipleline-operator proposal is bundled with "partial application" proposal, and I observed Hack-style guys know nothing about it.

One of the reason he closed the thread is "unacceptable levels of hostility", but as far as I read, many comments are questioning their programming knowledge level.

I don't know him, but after a research of a couple of hour, he appears to be one of the leader of Hack-style, and I have observed he dominates the place of healthy-discussion avoiding the necessary debate perhaps because of his luck of knowledge, and force to proceed the TS39 level, and consequently could ruin the JavaScript.

We can't hold his autocratic behavior, and I strongly believe we don't have to.
Now, we need to re-open the issue.

I express my concern on tc39/proposal-pipeline-operator debate.

Thank you.

@kiprasmel
Copy link

kiprasmel commented Sep 14, 2021

Actually, it doesn't matter what implementation you, me, or anyone else prefers.

This is not about a particular proposal. This is about the committee in general.

I created a separate issue because to highlight the differences: #96

@ken-okabe
Copy link
Author

I agree with you this is not the place for "preference of implementation".
However, apparently, as you mentioned, in terms of decision process,

Do you know any people in the TC39 Committee who have a strong background in functional programming languages, e.g. Haskell, F#, Elixir etc? Did they participate in the discussions regarding Pipeline Operators?

I share your concern, and something very strange thing has been going on for the one of the most popular programming language.

Having shared such a background, as a third-person who did not join the thread, I observe the entire comments are extremely informative, yes, civil discussion, no CoC violations, and yes, @tabatkins abused the open-process and forced to shut-down our creative discussion for his own interest.

I wish he should withdraw from this issue. I don't think his behavior has been appropriate.

@kiprasmel
Copy link

Exactly. I'm just saying that this is not specific to the current proposal - this is a problem in the TC39 as a whole - no matter the proposal.

Thus it'd probably make sense to discuss this in #96 instead, and later come back to the original issue in the repo, instead of continuing the discussion here, because a lot of context will be missing.

#96

@robpalme
Copy link
Contributor

@stken2050 This is a meta repository for describing how TC39 works. It's not an escalation site for specific proposals so I'm closing this now. There's plenty of time for constructive conversation and I encourage you to continue respectfully in other venues, e.g. Matrix. If there has been a Code of Conduct violation, the contact points are listed here https://tc39.es/code-of-conduct/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants