5 ms·

OP's link provides answers[1] to that question. And in my personal view, they aren't very convincing. The first answer, tedium, is unconvincing, because prett

OP's link provides answers[1] to that question. And in my personal view, they aren't very convincing. The first answer, tedium, is unconvincing, because pretty much anyone with more than a couple of years of experience in software development in a team knows that ease of reading beats ease of writing. The second answer, unexpected mutation of temporary variables, seems to point to a deeper issue in JavaScript. That of const not quite being const. Unless you Object.freeze everything. The third answer, that temporary variables require sequences of statements instead of a single big expression, is more of a feature than a bug, in my personal opinion. Statements allow the reader to comprehend the algorithm one step at a time instead of trying to untangle one giant expression. To say nothing about the fact that a sequence of statements is way more debuggable. I'd say that JS is moving closer and closer to Perl in its write-only-ness. [1]: https://github.com/tc39/proposal-pipeline-operator#temporary-variables-are-often-tedious https://github.com/tc39/proposal-pipeline-operator#temporary...

ravenstine 5y ago
> The first answer, tedium, is unconvincing, because pretty much anyone with more than a couple of years of experience in software development in a team knows that ease of reading beats ease of writing. Hah, I dunno, man. I guess it depends on how one defines "readable". If having layer upon layer of indirection through inheritance, dependency injection, procedures split into tiny functions written in no particular order, and magic strings/numbers are considered readable code, then yeah, I suppose most mid-level developers prefer "readable" code. > The third answer, that temporary variables require sequences of statements instead of a single big expression, is more of a feature than a bug, in my personal opinion. Simplicity is much more important than even readability, though readability is still important. The more tools we add, the more rules and complexity need to exist around them, all while possibly adding little meaningful benefit. In all honesty, I think that the most meaningful thing we got out of >=ES2015 is modules, promises and async/await, and maybe constants. Everything else became window dressing around existing constructs but introduced more complexity while also creating more rules. Things like classes were mistakenly implemented to satisfy Ruby and Python developers and to assist transpilers. The more I got away from using inheritance, the more I realized how unnecessary class syntax is. If you can just write a function that takes data and spits out data, then there's hardly any need for other class syntax features. If something seems to need inheritance, chances are you could have written your code to be more composable. The more we try adding to JavaScript at this point, the more people are going to be encouraged to do things that make themselves feel clever to the exclusion of writing code that future devs won't have to spend hours deciphering. A huge part of my job is deciphering. I don't know if it's like that for anyone else, but there's so much of it that it really makes me wonder how many millions, perhaps billions of dollars are wasted because engineers are trying to be clever.
zodiakzz 5y ago
Ah, missed that example. I am not seeing a single good argument > Indeed, the benefits of method chaining are so attractive that some popular libraries contort their code structure specifically to allow more method chaining. The most prominent example is jQuery, which still remains the most popular JS library in the world. jQuery’s core design is a single über-object with dozens of methods on it, all of which return the same object type so that we can continue chaining. There is even a name for this style of programming: fluent interfaces. Do they know what's so attractive about method chaining/fluent interfaces? They guarantee returning the same damn object/interface (tho the underlying values mutate). This pipe thing is complete opposite of that, what's the relevance here?
- danielsju6 5y ago
  It's about reading the code in a natural order. jquery style: a().b().c().d() However this isn't tree shakable. modern esm: d(c(b(a()))) this proposal: a() |> b(%) |> c(%) |> d(%)
  - lifthrasiir 5y ago
    I think this is a good summary of why pipeline operators are long sought, more so than the proposal. If you are not fundamentally against chaining calls, there is no fundamental reason to be against pipeline operators because it can be thought as a generalization of chaining with similar pros and cons.
handrous 5y ago
> I'd say that JS is moving closer and closer to Perl in its write-only-ness. I've never understood why it's common to dismiss Perl as "line noise" while, outside of contrived or unusual Perl examples, it's way less line-noiseish than what I see in certain languages that are, evidently, very popular among people influential in the JavaScript community. Implicit, repeated re-assignment of a magical "%" variable while adding a two-character punctuation operator to reverse the "direction" that values "travel" is clean and more readable? In what universe? The example that also uses Underscore, especially, reads like some kind of parody.

ravenstine 5y ago

> The first answer, tedium, is unconvincing, because pretty much anyone with more than a couple of years of experience in software development in a team knows that ease of reading beats ease of writing. Hah, I dunno, man. I guess it depends on how one defines "readable". If having layer upon layer of indirection through inheritance, dependency injection, procedures split into tiny functions written in no particular order, and magic strings/numbers are considered readable code, then yeah, I suppose most mid-level developers prefer "readable" code. > The third answer, that temporary variables require sequences of statements instead of a single big expression, is more of a feature than a bug, in my personal opinion. Simplicity is much more important than even readability, though readability is still important. The more tools we add, the more rules and complexity need to exist around them, all while possibly adding little meaningful benefit. In all honesty, I think that the most meaningful thing we got out of >=ES2015 is modules, promises and async/await, and maybe constants. Everything else became window dressing around existing constructs but introduced more complexity while also creating more rules. Things like classes were mistakenly implemented to satisfy Ruby and Python developers and to assist transpilers. The more I got away from using inheritance, the more I realized how unnecessary class syntax is. If you can just write a function that takes data and spits out data, then there's hardly any need for other class syntax features. If something seems to need inheritance, chances are you could have written your code to be more composable. The more we try adding to JavaScript at this point, the more people are going to be encouraged to do things that make themselves feel clever to the exclusion of writing code that future devs won't have to spend hours deciphering. A huge part of my job is deciphering. I don't know if it's like that for anyone else, but there's so much of it that it really makes me wonder how many millions, perhaps billions of dollars are wasted because engineers are trying to be clever.

zodiakzz 5y ago

Ah, missed that example. I am not seeing a single good argument > Indeed, the benefits of method chaining are so attractive that some popular libraries contort their code structure specifically to allow more method chaining. The most prominent example is jQuery, which still remains the most popular JS library in the world. jQuery’s core design is a single über-object with dozens of methods on it, all of which return the same object type so that we can continue chaining. There is even a name for this style of programming: fluent interfaces. Do they know what's so attractive about method chaining/fluent interfaces? They guarantee returning the same damn object/interface (tho the underlying values mutate). This pipe thing is complete opposite of that, what's the relevance here?

danielsju6 5y ago
It's about reading the code in a natural order. jquery style: a().b().c().d() However this isn't tree shakable. modern esm: d(c(b(a()))) this proposal: a() |> b(%) |> c(%) |> d(%)
- lifthrasiir 5y ago
  I think this is a good summary of why pipeline operators are long sought, more so than the proposal. If you are not fundamentally against chaining calls, there is no fundamental reason to be against pipeline operators because it can be thought as a generalization of chaining with similar pros and cons.

handrous 5y ago

> I'd say that JS is moving closer and closer to Perl in its write-only-ness. I've never understood why it's common to dismiss Perl as "line noise" while, outside of contrived or unusual Perl examples, it's way less line-noiseish than what I see in certain languages that are, evidently, very popular among people influential in the JavaScript community. Implicit, repeated re-assignment of a magical "%" variable while adding a two-character punctuation operator to reverse the "direction" that values "travel" is clean and more readable? In what universe? The example that also uses Underscore, especially, reads like some kind of parody.