| 16:58 | <jschoi> | We had a brief conversation at plenary during Evan Winslow’s timely presentation about prioritizing bad dead code / good tree shakeability as a language-level design problem. |
| 16:58 | <jschoi> | Chengzhong Wu brought up extension syntax for this-based standalone functions. |
| 16:58 | <jschoi> | I also brought up pipe operator vs. tree-shakeable methods. |
| 16:58 | <jschoi> | Evan Winslow said that he would like to talk with me more about how he sees pipe, etc. fitting in with his vision of improving dead code at the system level, so I’m inviting him to do so here. |
| 16:59 | <jschoi> | (hax (HE Shi-Jun) also responded at this time that Hack-style pipe operator wouldn’t help with fluent chaining, which I didn’t quite understand—he might be referring to how Hack pipes aren’t tacit. But, even if not tacit, Hack pipes still improve the linearity by creating linear chains, which is probably the most important part of fluent chaining?) |
| 16:59 | <jschoi> | Steve Hicks also suggested that the pipe operator just overcome its bikeshedding and just pick an option to help the dead-code problem. And I am all for just ending the bikeshedding, picking something, and presenting it. (I think maybe ## has the most support?) |
| 16:59 | <rbuckton> | F# pipes aren't tacit? Or do you mean hack pipes? |
| 16:59 | <jschoi> | In addition to the bikeshedding, maybe the biggest barriers of for pipe operator was the idea that simple convenience syntax proposals didn’t carry their implementation weight (e.g., “pipe should belong in the future JSSugar layer”). But, if we’re making dead-code elimination a language priority, maybe this proposal could overcome that barrier. |
| 16:59 | <jschoi> | Whoops, yes. |
| 17:00 | <jschoi> | It’s been a while…I fixed it. |
| 17:56 | <Evan Winslow> | I interpreted hax' comment as "pipes aren't close enough to methods to move the needle. They are more attractive to existing function users, not existing class users". I would share that concern... |
| 18:10 | <Ashley Claymore> | fwiw I'm not sure we have the concept of "language priorities". The committee is diverse and represent different stakeholders. |
| 18:11 | <Ashley Claymore> | i.e. I don't think this is any different to agreeing in Stage 1 that the problem is something we want to address |
| 18:25 | <Evan Winslow> | Ashley Claymore: sounds like cross-cutting concerns that might affect many proposals are just up to individual members to advocate for? Is there a canonical list of goals/considerations that delegates typically bring up? |
| 18:26 | <Ashley Claymore> | that is not a list I have seen. Though one does live rent free in my head :D |
| 18:29 | <Ashley Claymore> |
That matches my feeling. A champion group advocates for something and the committee agrees and doesn't object |
| 18:29 | <Ashley Claymore> | and that goes into the notes for that meeting |
| 18:47 | <jschoi> | Ashley Claymore: sounds like cross-cutting concerns that might affect many proposals are just up to individual members to advocate for? Is there a canonical list of goals/considerations that delegates typically bring up? |
| 19:03 | <Ashley Claymore> | yep. though invariants are only the strictest form of 'priority' |
| 19:03 | <Ashley Claymore> | these are the things that won't change |
| 19:03 | <Ashley Claymore> | not which problems we want to see solutions for |
| 19:05 | <jschoi> | She also was going for “Design Principles” too—there’s a section in the explainer for those—but, yeah, you’re right. |
| 19:23 | <jschoi> | Regarding how pipes "are more attractive to existing function users, not existing class users", it's true that pipes address a different style of dataflow. This is something that’s come up a lot: TC39 has been considering three* styles of “dataflow” and procedural programming. JavaScript has long let that three-way style divergence out of the bag. So a perennial question we have is to what extent we should add syntax that encourages one style over others (There’s Only One [encouraged] Way to Do It, or TOOWTTI)—or add syntaxes that improve two or all three styles, perhaps with some overlap (There Is More Than One Way to Do It). If we want to improve tree-shaking with syntax, but we have a limited budget of new syntaxes, then we still face this choice between TOOWTTI and TIMTOWDI (and, if the latter, which ways?). But the fact remains that all approaches are already used in the wild. With that said, we’ve already seen at least one big API (Firebase) that switched from prototype methods to standalone functions—explicitly due to tree shakability. So there may already be an ongoing trend there migrating from one approach to another. |
| 19:23 | <jschoi> | * Actually, there is even a fourth style, tacit/point-free functional programming, which I happen to be a fan of. Tacit FP is what F# pipes, partial function application syntax, and Function.pipe would have encouraged. But several engine implementors have pushed strongly back on it due to concerns about hot-path function allocation, GC, and optimization complexity. This is an example of TC39 (or at least several very important members of it) actually discouraging one of the styles. We still have three styles left to consider. And the pipe operator works with higher-order functions, if you’re willing to attach an explicit call (##) to your HOF… |
| 19:24 | <jschoi> | Anyways, back in 2022, we had a series of articles about these different styles (list of links in https://web.archive.org/web/20230602050536/https://jschoi.org/22/es-dataflow/). No strong consensus was reached from these 2022 discussions other than:
|
| 19:25 | <ljharb> | oh noes, what happened to jschoi.org? |
| 19:25 | <jschoi> | Syntaxes for writing tree-shakeable methods would kind of fall in this overlap too, since it’s essentially an enhancement of the . member access syntax. |
| 19:25 | <jschoi> | I continue to hope that syntaxes enhancing all styles can be considered for implementation, in the name of encouraging tree-shakable code. For example, I think that syntaxes for writing tree-shakeable methods can easily coexist with a pipe operator; they address two of the three different styles. |
| 19:26 | <jschoi> | I used a nice Node-based host called Glitch.com, which got acquihired by Fastly and then killed. I’ve been too busy to update it due to research; I really should, though… |
| 19:40 | <jschoi> | Also Evan Winslow, I literally just saw your Discourse post from January on the "reshaping extensions" thread: https://es.discourse.group/t/reshaping-the-extensions-proposal/2439/24. Big foreshadowing to your talk today… |
| 19:44 | <Evan Winslow> | ^_^ yup. I basically fleshed out that post and turned it into this talk |
| 19:47 | <jschoi> | Oh, dang, and there was even also relevant discussion on https://github.com/tc39/proposal-call-this/issues/10#issuecomment-3765894544. You’re pretty plugged into the related proposals. Sorry for not responding—work has been hectic. |
| 19:51 | <Evan Winslow> | No worries. We all have busy lives! I did want to respect all the discussion history that has already happened so I tried hard to read up on everything I possibly could. |
| 19:54 | <jschoi> | https://github.com/tc39/proposal-call-this/issues/12#issuecomment-3765070082
Looks like you said much the same thing as this back in January. I agree it would be nice to have them all. It’s a matter of pushback from engines due to limited implementation budget and Waldemar’s and Mark Miller’s (reasonable) concerns about stewarding the unified language and pushing against complexity creep. |
| 20:29 | <ljharb> | ah yes, rip glitch |