4 ms·

I don't see how any of this is more readable than: let v = first(); v = second(v, 10); v = third(x, y, v); return v; Why do we need a new oper

by junon 5y ago

I don't see how any of this is more readable than: let v = first(); v = second(v, 10); v = third(x, y, v); return v; Why do we need a new operator for this?

eyelidlessness 5y ago
- One thing not discussed in the article is type safety. But TC39 increasingly considers the impact of proposals on typed extensions to JS like TypeScript/Flow. In your example, v must be a union type of the return types of each of the called functions. - The pipeline operator can be used to assign to a const, to prevent further assignments. While const isn’t necessarily immutable, it is often idiomatically used to signal that the assigned value is intended to be final. The same can’t be achieved with your example without wrapping it in an IIFE, which is (IMO) much harder to follow than the pipeline operator. - More subjectively, it (in the F# variant) encourages better interfaces. For most use cases where piping would be appropriate, it’s generally a good idea to make the data you’re processing the last parameter. This also, as the article notes, works well with partial application. Which in turn also encourages good practices like composition.
- junon 5y ago
  I think your first point is the only compelling reason (for me) yet I also hold the stance that TC39 shouldn't cater to corporate projects such as Typescript as they are not maintained by the same committee. Those are my opinions, however.
  - eyelidlessness 5y ago
    They aren’t catering specifically to TypeScript (or Flow), but rather to increased interest in type safety across the community generally. It’s worth noting though that the TypeScript team does participate in the standards process. And Microsoft has two members on the committee.
  - Zababa 5y ago
    I do agree that they shouldn't cater to TypeScript or Flow or anything specifically, but I appreciate that they think about the impact of new changes on typing JavaScript. I find in general that code that can easily be statically typed is easier to understand and maintain.
    - eyelidlessness 5y ago
      Exactly this! And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! If you had a clear data flow/model the types will usually end up being much simpler too. This is somewhat less true in some frontend projects, where the underlying libraries/frameworks come with infectious built-in interface complexity (side-eyes React/JSX even though I quite like JSX otherwise).
      - Zababa 5y ago
        > And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! Part of it may also be due to the limitations of TypeScript. Structural typing is not always the best choice. ADT support is also not the best.
        eyelidlessness 5y ago
        I definitely have wants for the TS type system, particularly in the area of nominal typing. But it’s usually not this IME. It’s usually that untyped JS often is written in an overly permissive style where anything goes, or where state and data flow is a big ball of mud, or both.
      - junon 5y ago
        That's false equivalence. Typescript is trying to bolt on strict, formal types to a prototypical language. Because the language doesn't map cleanly into formal types doesn't mean it's poorly designed. You'd need to have a lot of evidence that that were the case, as it's a bold claim about not just JavaScript, but programming language design in general - one that isn't entirely factual, IMO. Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself. However for what it is, shell scripting is quite useful. Most would argue it has a simple interface, simple syntax, simple concepts. Perhaps a contrived example - my point mostly being that you can't draw conclusions like that.
paulddraper 5y ago
return first() | second(_, 10) | third(x, y, _) I somewhat agree.
- nsonha 5y ago
  Agree what? You can't overload bitwise with another semantic
- junon 5y ago
  Further, it has to be |> to disambiguate from bitwise OR. So yet another symbol to confuse readers. And the placeholder can't be _ as that's a valid identifier. The first issue on the tracker is the bike shedding thread about what the placeholder symbol should be, and it's neither _ nor ^, but instead probably something like ^label.
  - slaymaker1907 5y ago
    I think it's kind of ridiculous to say you can't use _ because it is a valid identifier. You could just have the pipe _ shadow the identifier _ if said id is present. I suspect the bigger reason is because of underscore/lodash being in wide use. Suppose you had "const _ = 42; /* more code / return x | f | g(11, _);". This would be semantically equivalent to "const _ = 42; / more code */ return ((_) => g(11, _))(f(x))". Since it is a new function, shadowing is not forbidden.
    - junon 5y ago
      I'm not the one saying it, check #92 I believe it is. The bike shedding thread. They don't want to shadow.
Zababa 5y ago
In your example you're mutating v, which is something people try to avoid these days, as immutable data is easier to work with. There's also a good chance you can't find a good name for v that fits what it is at every step. A good part of the pipeline operator is that you don't have to name every step. Sometimes there's just no good name.
- junon 5y ago
  > as immutable data is easier to work with Source? This hasn't been my experience. Going on 10 years of heavy Node.js ecosystem involvement, immutable data enthusiasts are exceedingly rare. Plus, this is const vs let, which is a reach to call "immutable data". We're not talking about object properties.
  - pharmakom 5y ago
    State in React should be immutable. It’s not rare at all!
    - junon 5y ago
      React != JavaScript.
      - pharmakom 5y ago
        Yeah, of course. But vast majority of React is written in JavaScript and large numbers of JavaScript devs are writing React. It shows FP and immutability have significant base of practitioners in JS world - although many might not realise it.
        junon 5y ago
        I would argue most JavaScript developers do not use React. Perhaps in your own bubble, but there are way more people writing other things in JavaScript.
  - eyelidlessness 5y ago
dtech 5y ago
The advantage is that you don't have to name things. "v" is a bad name in a larger context, and it quikly becomes unwieldy if you use a full name. let transformedData = transformFoo(data); transformedData = transformBar(transformedData); transformedData = transformBaz(transformedData); vs. const transformedData = data |> transformFoo |> transformBar |> transformBaz If you want have const's the first becomes even more unwieldy, and in general I'd recommend using const by default. Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.
- throw_m239339 5y ago
  > Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains. succinct =/= more readable. Readability here is really in the eye of the beholder... It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.
  - VenTatsu 5y ago
    > It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript. I am so glad this argument has not been winning out in the JavaScript language design community. There are so many wonderful constructs that have been added in the last 20 years that are just sorter ways to write things that could mostly already be done in the language. Many of these features focused on allowing developers to write what they intended to do without having to explicitly construction the intermediate steps to express the mechanics of how that should be carried out using basic language features. After all why do we need arrow functions when we could just sprinkle our code with `var self = this;` declarations for anonymous functions to bind to, the way it was done in the late 90's and early 00's. I'd much rather JavaScript adopt succinct ways to write common code patterns and let the developers and the community decide if those constructs are the correct ones to use on a case by case basis.
    - 5y ago

by junon 5y ago

I don't see how any of this is more readable than: let v = first(); v = second(v, 10); v = third(x, y, v); return v; Why do we need a new operator for this?

eyelidlessness 5y ago

- One thing not discussed in the article is type safety. But TC39 increasingly considers the impact of proposals on typed extensions to JS like TypeScript/Flow. In your example, v must be a union type of the return types of each of the called functions. - The pipeline operator can be used to assign to a const, to prevent further assignments. While const isn’t necessarily immutable, it is often idiomatically used to signal that the assigned value is intended to be final. The same can’t be achieved with your example without wrapping it in an IIFE, which is (IMO) much harder to follow than the pipeline operator. - More subjectively, it (in the F# variant) encourages better interfaces. For most use cases where piping would be appropriate, it’s generally a good idea to make the data you’re processing the last parameter. This also, as the article notes, works well with partial application. Which in turn also encourages good practices like composition.

junon 5y ago
I think your first point is the only compelling reason (for me) yet I also hold the stance that TC39 shouldn't cater to corporate projects such as Typescript as they are not maintained by the same committee. Those are my opinions, however.
- eyelidlessness 5y ago
  They aren’t catering specifically to TypeScript (or Flow), but rather to increased interest in type safety across the community generally. It’s worth noting though that the TypeScript team does participate in the standards process. And Microsoft has two members on the committee.
- Zababa 5y ago
  I do agree that they shouldn't cater to TypeScript or Flow or anything specifically, but I appreciate that they think about the impact of new changes on typing JavaScript. I find in general that code that can easily be statically typed is easier to understand and maintain.
  - eyelidlessness 5y ago
    Exactly this! And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! If you had a clear data flow/model the types will usually end up being much simpler too. This is somewhat less true in some frontend projects, where the underlying libraries/frameworks come with infectious built-in interface complexity (side-eyes React/JSX even though I quite like JSX otherwise).
    - Zababa 5y ago
      > And the inverse—where JavaScript devs complain that TypeScript types are overly complex and verbose—is just a symptom of the same principle. Those types are complicated because your interface is complicated! Part of it may also be due to the limitations of TypeScript. Structural typing is not always the best choice. ADT support is also not the best.
      - eyelidlessness 5y ago
        I definitely have wants for the TS type system, particularly in the area of nominal typing. But it’s usually not this IME. It’s usually that untyped JS often is written in an overly permissive style where anything goes, or where state and data flow is a big ball of mud, or both.
    - junon 5y ago
      That's false equivalence. Typescript is trying to bolt on strict, formal types to a prototypical language. Because the language doesn't map cleanly into formal types doesn't mean it's poorly designed. You'd need to have a lot of evidence that that were the case, as it's a bold claim about not just JavaScript, but programming language design in general - one that isn't entirely factual, IMO. Look at shell scripting. Imagine trying to apply a type system to shell scripts. It wouldn't map cleanly at all because (almost) everything is a string, and the operations define how those strings are interpreted - not the data itself. However for what it is, shell scripting is quite useful. Most would argue it has a simple interface, simple syntax, simple concepts. Perhaps a contrived example - my point mostly being that you can't draw conclusions like that.

paulddraper 5y ago

return first() | second(_, 10) | third(x, y, _) I somewhat agree.

nsonha 5y ago
Agree what? You can't overload bitwise with another semantic
junon 5y ago
Further, it has to be |> to disambiguate from bitwise OR. So yet another symbol to confuse readers. And the placeholder can't be _ as that's a valid identifier. The first issue on the tracker is the bike shedding thread about what the placeholder symbol should be, and it's neither _ nor ^, but instead probably something like ^label.
- slaymaker1907 5y ago
  I think it's kind of ridiculous to say you can't use _ because it is a valid identifier. You could just have the pipe _ shadow the identifier _ if said id is present. I suspect the bigger reason is because of underscore/lodash being in wide use. Suppose you had "const _ = 42; /* more code / return x | f | g(11, _);". This would be semantically equivalent to "const _ = 42; / more code */ return ((_) => g(11, _))(f(x))". Since it is a new function, shadowing is not forbidden.
  - junon 5y ago
    I'm not the one saying it, check #92 I believe it is. The bike shedding thread. They don't want to shadow.

Zababa 5y ago

In your example you're mutating v, which is something people try to avoid these days, as immutable data is easier to work with. There's also a good chance you can't find a good name for v that fits what it is at every step. A good part of the pipeline operator is that you don't have to name every step. Sometimes there's just no good name.

junon 5y ago
> as immutable data is easier to work with Source? This hasn't been my experience. Going on 10 years of heavy Node.js ecosystem involvement, immutable data enthusiasts are exceedingly rare. Plus, this is const vs let, which is a reach to call "immutable data". We're not talking about object properties.
- pharmakom 5y ago
  State in React should be immutable. It’s not rare at all!
  - junon 5y ago
    React != JavaScript.
    - pharmakom 5y ago
      Yeah, of course. But vast majority of React is written in JavaScript and large numbers of JavaScript devs are writing React. It shows FP and immutability have significant base of practitioners in JS world - although many might not realise it.
      - junon 5y ago
        I would argue most JavaScript developers do not use React. Perhaps in your own bubble, but there are way more people writing other things in JavaScript.
- eyelidlessness 5y ago

dtech 5y ago

The advantage is that you don't have to name things. "v" is a bad name in a larger context, and it quikly becomes unwieldy if you use a full name. let transformedData = transformFoo(data); transformedData = transformBar(transformedData); transformedData = transformBaz(transformedData); vs. const transformedData = data |> transformFoo |> transformBar |> transformBaz If you want have const's the first becomes even more unwieldy, and in general I'd recommend using const by default. Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.

throw_m239339 5y ago
> Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains. succinct =/= more readable. Readability here is really in the eye of the beholder... It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.
- VenTatsu 5y ago
  > It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript. I am so glad this argument has not been winning out in the JavaScript language design community. There are so many wonderful constructs that have been added in the last 20 years that are just sorter ways to write things that could mostly already be done in the language. Many of these features focused on allowing developers to write what they intended to do without having to explicitly construction the intermediate steps to express the mechanics of how that should be carried out using basic language features. After all why do we need arrow functions when we could just sprinkle our code with `var self = this;` declarations for anonymous functions to bind to, the way it was done in the late 90's and early 00's. I'd much rather JavaScript adopt succinct ways to write common code patterns and let the developers and the community decide if those constructs are the correct ones to use on a case by case basis.
  - 5y ago