| 17:32 | <jschoi> | Yeah, TabAtkins, thanks for continuing to engage with him and others—I’ve been really busy myself, so I haven’t been able to work much on outreach or updates myself. 😔 |
| 20:25 | <TabAtkins> | And now I'm back to just closing issue threads because the participants refuse to stay on topic and instead keep relitigating the core question. :/ |
| 20:26 | <TabAtkins> | Should have done that one weeks ago, but I know Kevin personally and wanted to keep things friendly, but good lord I do not have time nor interest to engage in dueling essays where every point was brought up and addressed last year. |
| 20:29 | <TabAtkins> | (if he has made novel points I missed them in the screenfuls of text that each post of his produces) |
| 20:29 | <jschoi> | Insofar that we have already addressed many points of argument that people keep perseverating over, we should add an FAQ section or an FAQ document that summarizes positions, so we could simply point to them every time something gets brought up again. I’ve meant to do this for a year now, but I just haven’t had time. My apologies about this—maybe if I had done so earlier, we would have had you deal with a few less circular threads. |
| 20:29 | <TabAtkins> | I doubt it. ^_^ |
| 20:33 | <shu> | at least stare decisis have entered people's vocabularies recently |
| 20:34 | <TabAtkins> | ah yes, the "stand your ground" rule |
| 20:34 | <shu> | though i guess in this case it's more like res judicata than stare decisis |
| 20:47 | <jschoi> | “Stare decisis” (n.): The act of staring decisively at each other, without budging. |
| 21:20 | <rkirsling> | this has truly been a depressing proposal, sociologically speaking |
| 21:22 | <TabAtkins> | huh, for some reason I can't hide Kevin's latest response in https://github.com/tc39/proposal-pipeline-operator/issues/238#issuecomment-1178231937 (but could hide his earlier ones) |
| 22:09 | <ljharb> | TabAtkins: sometimes i see no "hide" link present, especially when the anchor link points to that specific comment - i usually click the timestamp of another comment and hard-refresh |
| 22:11 | <TabAtkins> | Ah, that was indeed the problem. How confusing. Thanks! |
| 22:22 | <rbuckton (PTO: 7/5 - 7/16)> | Have we ever tried to quantify how much of the ecosystem prefers Hack-style vs. F#-style? It's unfortunate that much of the early negative response was so vitrolic, but I still wonder if Hack-style was the right direction. This proposal constantly feels like it's being pushed uphill. |
| 22:26 | <shu> | do you plan to hire Pew? |
| 22:28 | <rbuckton (PTO: 7/5 - 7/16)> | No, no budget for that |
| 22:33 | <jschoi> | For what it’s worth, I view reconciliation with call-this syntax to be a much greater obstacle to pipe operator compared to its syntax particulars like Hack/F#—or the choice of the topic, for that matter. (That is, Jordan’s prior condition to pipe’s advancement to Stage 2 that a this-binding-or-calling syntax also “eventually” advance, and the fact that we have some strong opposition to any such this-binding/calling syntax.) This is one of the two topics that the pipe incubator was chartered to discuss, and we might have some time this plenary to discuss it. But if pipe fails to ever reach Stage 4, it’s going to be because of that critical issue. |
| 22:34 | <jschoi> | That is to say, Jordan will probably always block Stage 4 for pipe unless call-this or something like it reaches Stage 3 or 4, as he essentially warned when it reached Stage 2 way back c. 2017. And (someone else’s words) “the default is that neither proposal advances, and I’m fine with that,” so to speak. I suppose I can sympathize with gatekeeping [what’s left of] the core language’s simplicity, even if I shed one tear doing so. :’) |
| 22:35 | <rbuckton (PTO: 7/5 - 7/16)> | I am still, and probably always be, in favor of F#-style + PFA, even with the limitations regarding yield and await. |
| 22:40 | <jschoi> | I can certainly sympathize, though my perspective is colored by my Clojure heritage. Speaking of which, there’s always Elixir style. Or Clojure’s operator-all-the-pipes-they’re-all-just-macros style (->, ->>, as->, cond->, etc.), heh. |
| 22:56 | <rbuckton (PTO: 7/5 - 7/16)> | I can certainly sympathize, though my perspective is colored by my Clojure heritage. Speaking of which, there’s always Elixir style. Or Clojure’s operator-all-the-pipes-they’re-all-just-macros style (->, ->>, as->, cond->, etc.), heh. this. |
| 22:58 | <rbuckton (PTO: 7/5 - 7/16)> | At least both Hack-style and F#-style are explicit. Hack-style with a topic, F#-style with x |> F meaning F(x) (plus PFA explicit placeholders). |
| 23:00 | <rbuckton (PTO: 7/5 - 7/16)> | And I still feel if you're using |> to do simple expressions like a + b, you're holding it wrong. Its the wrong tool for the job. |
| 23:01 | <jschoi> | Yeah, I agree about Elixir style. Anyways, all of these things are different ways to deal with the dichotomy between unary functional languages and n-ary functional languages. Something like a unary–n-ary functional impedance mismatch, to varying degrees. |
| 23:02 | <ljharb> | i suspect pipeline is the right tool for the job any time you have something complex to pass into a function, or a function call's return value to pass into a function. |
| 23:04 | <rbuckton (PTO: 7/5 - 7/16)> | i suspect pipeline is the right tool for the job any time you have something complex to pass into a function, or a function call's return value to pass into a function. x |> % + 1 examples are the ones I think are a poor use. |
| 23:05 | <ljharb> | sure. but i don't think those are at all the only ones that support hack |
| 23:05 | <rbuckton (PTO: 7/5 - 7/16)> | I'd much rather have do {} or a let..in syntax for those cases. |
| 23:06 | <ljharb> | personally i have a bunch of examples that would work equally well in either style, and a bunch of examples where hack avoids creating a bunch of extra arrow functions, and close to zero examples (but nonzero) where F# is simpler |
| 23:10 | <jschoi> | I think complexExpr |> % + 1 is contrived insofar that you could always replace it with complexExpr + 1. It’s because + is a fairly loose operator. In contrast, complexExpr |> % ** 2 may not be so contrived, since otherwise it probably would have to be (complexExpr) ** 2 with parentheses—and now imagine tacking on more and more (syntactically tight) operations… |
| 23:17 | <jschoi> | Function calls are a very syntactically tight operation, involving circumflex operators. It is for that reason that it is quite inconvenient to write and to read deeply nested function calls. But this is also generalizable to deeply nested “syntactically tight operations”, of which function calls are a subset. + expressions don’t fit as well in that set, but there are other ones that do. (And there’s also prefix operations like await and -—even though they are syntactically loose, they also mess with writing and reading when applied to deeply nested expressions due to reading order switching between LTR and RTL.) Both F# pipes and Hack pipes try to solve all these problems, in their own ways (e.g., veryDeeplyNestedExpression |> negate vs. veryDeeplyNestedExpression |> -%. |