4 ms·

Meanwhile the JS world has been waiting for 10 years for this proposal, which is still in stage 2 https://github.com/tc39/proposal-pipeline-operator/issues/232#

by bapak 1y ago

Meanwhile the JS world has been waiting for 10 years for this proposal, which is still in stage 2 https://github.com/tc39/proposal-pipeline-operator/issues/232#issuecomment-2784879225 https://github.com/tc39/proposal-pipeline-operator/issues/23...

wouldbecouldbe 1y ago
It’s really not needed, syntax sugar. With dots you do almost the same. Php doesn’t have chaining. Adding more and more complexity doesn’t make a language better.
- EGreg 1y ago
  It’s not really chaining More like thenables / promises
  - wouldbecouldbe 1y ago
    It looks like chaining, but with possibility of adding custom functions?
    - bapak 1y ago
      It's chaining without having to vary the return of each function. In JS you cannot call 3.myMethod(), but you could with 3 |> myMethod
      - cyco130 1y ago
        It requires parentheses `(3).myMethod()` but you can by monkey patching the Number prototype. Very bad idea, but you absolutely can.
        senfiaj 1y ago
        You can just add extra dot: `3..myMethod()`.
      - EGreg 1y ago
        Not only that In chaining, methods all have to be part of the same class. In C++ we had this stuff ages ago, it’s called abusing streaming operators LMAO
- bapak 1y ago
  Nothing is really needed, C89 was good enough. Dots are not the same, nobody wants to use chaining like underscore/lodash allowed because it makes dead code elimination impossible.
  - pjmlp 1y ago
    K&R C was good enough for UNIX System V, why bother with C89.
    - boobsbr 1y ago
      K&R C was the apex, we've just been going downhill since.
      - lioeters 1y ago
        This but unironically.
- troupo 1y ago
  > With dots you do almost the same. Keyword: almost. Pipes don't require you to have many different methods on every possible type: https://news.ycombinator.com/item?id=44794656 https://news.ycombinator.com/item?id=44794656
- te_chris 1y ago
  Dots call functions on objects, pipe passes arguments to functions. Totally missing the point.
- Martinussen 1y ago
  When you say chaining, do you mean autoboxing primitives? PHP can definitely do things like `foo()->bar()?->baz()`, but you'd have to wrap an array/string yourself instead of the methods being pulled from a `prototype` to use it there.
- chilmers 1y ago
  I'm tired of hearing the exact same arguments, "not needed", "just syntax sugar", "too much complexity", about every new syntax feature that gets added to JS. Somehow, once they are in the language, nobody's head explodes, and people are soon using them and they become uncontroversial. If people really this new syntax will make it harder to code in JS, show some evidence. Produce a study on solving representative tasks in a version of the language with and without this feature, showing that it has negative effects on code quality and comprehension.
  - robertlagrant 1y ago
    Presumably it's up to the change proposers to produce said study showing the opposite.
  - 38 1y ago
    [dead]
- purerandomness 1y ago
  If your team prefers not to use this new optional feature, just enable a PHPStan rule in your CI/CD pipeline that prevents code like this getting merged.
- hajile 1y ago
  Chaining requires creating a class and ensuring everything sticks to the class and returns it properly so the chain doesn't blow up. As you add more options and do more stuff, this becomes increasingly hard to write and maintain. If I'm using a chained library and need another method, I have to understand the underlying data model (a leaky abstraction) and also must have some hack-ish way of extending the model. As I'm not the maintainer, I'm probably going to cause subtle breakages along the way. Pipe operators have none of these issues. They are obvious. They don't need to track state past the previous operator (which also makes debugging easier). If they need to be extended, look at your response value and add the appropriate function. Composition (whether with the pipe operator or not) is vastly superior to chaining.
lacasito25 1y ago
in typescript we can do this let res res = op1() res = op2(res.op1) res = op3(res.op2) type inference works great, and it is very easy to debug and refactor. In my opinion even more than piping results. Javascript has enough features.
avaq 1y ago
Not only have we been waiting for 10 years, the most likely candidate to go forward is not at all what we wanted when the proposal was created: We wanted a pipe operator that would pair well with unary functions (like those created by partial function application, which could get its own syntax), but that got rejected on the premise that it would lead to a programming style that utilizes too many closures[0], and which could divide the ecosystem[1]. Yet somehow PHP was not limited by these hypotheticals, and simply gave people the feature they wanted, in exactly the form it makes most sense in. [0]: https://github.com/tc39/proposal-pipeline-operator/issues/221#issue-999806278 https://github.com/tc39/proposal-pipeline-operator/issues/22... [1]: https://github.com/tc39/proposal-pipeline-operator/issues/233#issuecomment-928217657 https://github.com/tc39/proposal-pipeline-operator/issues/23...
- lexicality 1y ago
  Am I correct in my understanding that you're saying that the developers of the most widely used JS engine saying "hey we can't see a way to implement this without tanking performance" is a silly hypothetical that should be ignored?
  - avaq 1y ago
    They can't implement function application without tanking performance? I find that hard to believe. Especially considering that function application is already a commonly used (and, dare I say: essential) feature in the language, eg: `Math.sqrt(2)`. All we're asking for is the ability to rewrite that as `2 |> Math.sqrt`. What they're afraid of, my understanding goes, is that people hypothetically, may start leaning more on closures, which themselves perform worse than classes. However I'm of the opinion that the engine implementors shouldn't really concern themselves to that extent with how people write their code. People can always write slow code, and that's their own responsibility. So I don't know about "silly", but I don't agree with it. Unless I misunderstood and somehow doing function application a little different is actually a really hard problem. Who knows.
    - nilslindemann 1y ago
fergie 1y ago
Good- the [real world examples of pipes in js](https://github.com/tc39/proposal-pipeline-operator?tab=readme-ov-file#real-world-examples https://github.com/tc39/proposal-pipeline-operator?tab=readm...) are deeply underwhelming IMO.
defraudbah 1y ago
do not let me start on monads in golang... both are going somewhere and super popular though
77pt77 1y ago
Best you'll git will be 3 new build systems and 10 new frameworks
epolanski 1y ago
Sadly they went obsessing over pipes with promises which don't fit the natural flow. Go explain them that promises already have a natural way to chain operations through the "then" method, and don't need to fit the pipe operator to do more than needed.

by bapak 1y ago

wouldbecouldbe 1y ago

It’s really not needed, syntax sugar. With dots you do almost the same. Php doesn’t have chaining. Adding more and more complexity doesn’t make a language better.

EGreg 1y ago
It’s not really chaining More like thenables / promises
- wouldbecouldbe 1y ago
  It looks like chaining, but with possibility of adding custom functions?
  - bapak 1y ago
    It's chaining without having to vary the return of each function. In JS you cannot call 3.myMethod(), but you could with 3 |> myMethod
    - cyco130 1y ago
      It requires parentheses `(3).myMethod()` but you can by monkey patching the Number prototype. Very bad idea, but you absolutely can.
      - senfiaj 1y ago
        You can just add extra dot: `3..myMethod()`.
    - EGreg 1y ago
      Not only that In chaining, methods all have to be part of the same class. In C++ we had this stuff ages ago, it’s called abusing streaming operators LMAO
bapak 1y ago
Nothing is really needed, C89 was good enough. Dots are not the same, nobody wants to use chaining like underscore/lodash allowed because it makes dead code elimination impossible.
- pjmlp 1y ago
  K&R C was good enough for UNIX System V, why bother with C89.
  - boobsbr 1y ago
    K&R C was the apex, we've just been going downhill since.
    - lioeters 1y ago
      This but unironically.
troupo 1y ago
> With dots you do almost the same. Keyword: almost. Pipes don't require you to have many different methods on every possible type: https://news.ycombinator.com/item?id=44794656 https://news.ycombinator.com/item?id=44794656
te_chris 1y ago
Dots call functions on objects, pipe passes arguments to functions. Totally missing the point.
Martinussen 1y ago
When you say chaining, do you mean autoboxing primitives? PHP can definitely do things like `foo()->bar()?->baz()`, but you'd have to wrap an array/string yourself instead of the methods being pulled from a `prototype` to use it there.
chilmers 1y ago
I'm tired of hearing the exact same arguments, "not needed", "just syntax sugar", "too much complexity", about every new syntax feature that gets added to JS. Somehow, once they are in the language, nobody's head explodes, and people are soon using them and they become uncontroversial. If people really this new syntax will make it harder to code in JS, show some evidence. Produce a study on solving representative tasks in a version of the language with and without this feature, showing that it has negative effects on code quality and comprehension.
- robertlagrant 1y ago
  Presumably it's up to the change proposers to produce said study showing the opposite.
- 38 1y ago
  [dead]
purerandomness 1y ago
If your team prefers not to use this new optional feature, just enable a PHPStan rule in your CI/CD pipeline that prevents code like this getting merged.
hajile 1y ago
Chaining requires creating a class and ensuring everything sticks to the class and returns it properly so the chain doesn't blow up. As you add more options and do more stuff, this becomes increasingly hard to write and maintain. If I'm using a chained library and need another method, I have to understand the underlying data model (a leaky abstraction) and also must have some hack-ish way of extending the model. As I'm not the maintainer, I'm probably going to cause subtle breakages along the way. Pipe operators have none of these issues. They are obvious. They don't need to track state past the previous operator (which also makes debugging easier). If they need to be extended, look at your response value and add the appropriate function. Composition (whether with the pipe operator or not) is vastly superior to chaining.

lacasito25 1y ago

in typescript we can do this let res res = op1() res = op2(res.op1) res = op3(res.op2) type inference works great, and it is very easy to debug and refactor. In my opinion even more than piping results. Javascript has enough features.

avaq 1y ago

Not only have we been waiting for 10 years, the most likely candidate to go forward is not at all what we wanted when the proposal was created: We wanted a pipe operator that would pair well with unary functions (like those created by partial function application, which could get its own syntax), but that got rejected on the premise that it would lead to a programming style that utilizes too many closures[0], and which could divide the ecosystem[1]. Yet somehow PHP was not limited by these hypotheticals, and simply gave people the feature they wanted, in exactly the form it makes most sense in. [0]: https://github.com/tc39/proposal-pipeline-operator/issues/221#issue-999806278 https://github.com/tc39/proposal-pipeline-operator/issues/22... [1]: https://github.com/tc39/proposal-pipeline-operator/issues/233#issuecomment-928217657 https://github.com/tc39/proposal-pipeline-operator/issues/23...

lexicality 1y ago
Am I correct in my understanding that you're saying that the developers of the most widely used JS engine saying "hey we can't see a way to implement this without tanking performance" is a silly hypothetical that should be ignored?
- avaq 1y ago
  They can't implement function application without tanking performance? I find that hard to believe. Especially considering that function application is already a commonly used (and, dare I say: essential) feature in the language, eg: `Math.sqrt(2)`. All we're asking for is the ability to rewrite that as `2 |> Math.sqrt`. What they're afraid of, my understanding goes, is that people hypothetically, may start leaning more on closures, which themselves perform worse than classes. However I'm of the opinion that the engine implementors shouldn't really concern themselves to that extent with how people write their code. People can always write slow code, and that's their own responsibility. So I don't know about "silly", but I don't agree with it. Unless I misunderstood and somehow doing function application a little different is actually a really hard problem. Who knows.
  - nilslindemann 1y ago

fergie 1y ago

Good- the [real world examples of pipes in js](https://github.com/tc39/proposal-pipeline-operator?tab=readme-ov-file#real-world-examples https://github.com/tc39/proposal-pipeline-operator?tab=readm...) are deeply underwhelming IMO.

defraudbah 1y ago

do not let me start on monads in golang... both are going somewhere and super popular though

77pt77 1y ago

Best you'll git will be 3 new build systems and 10 new frameworks

epolanski 1y ago

Sadly they went obsessing over pipes with promises which don't fit the natural flow. Go explain them that promises already have a natural way to chain operations through the "then" method, and don't need to fit the pipe operator to do more than needed.