4 ms·

Please no. Javascript's beauty lies in its versatile simplicity. Can we just leave these sorts of things to systems programming languages like C++? I came to

Please no. Javascript's beauty lies in its versatile simplicity. Can we just leave these sorts of things to systems programming languages like C++? I came to javascript because of its lack of cruft, but if libraries start adopting this then I'll be forced to put it in my code as well. If that happens then I'll probably leave for nim or clojure, though that's not preferable.

edgyswingset 11y ago
Can't speak for nim, but Clojure has a near-exact feature which is used all over the place, the thread-first and thread-last macros. Example: (defn do-stuff [params-map] (-> (build-object params-map) (do-thing-with-object) (extract-thing) (format-thing))) I'm not sure why you'd choose Clojure to get away from things like |>.
- wnfewnlkew 11y ago
  Clojure is a functional language, so it meshes well with the rest of the syntax, but in javascript's case it's just syntax bloat. It's going to be really jarring in the middle of regular imperative code, and it's not going to be too far removed from cout << "foo";
  - danneu 11y ago
    Whether `|>` would mesh with your code depends on the code that's already there. Doesn't seem fair to shut down this proposal because you happen to write and work with imperative code, a style that Javascript and modern abstractions are moving away from. In fact, the Javascript hack to get a pipeline-like style is to make some opaque wrapper object that you can chain method calls onto like `_.chain(a).b().c().d().value()` in Lodash, when all you wanted was a chain of function application. `|>`, `<|`, composition operators, and friends would all be welcome complements to the Javascript code bases I've worked with in the last few years.
    - takle 11y ago
      # Why not ## Lodash `_.flow(b,c,d)(a)` // left to right `_.compose(d,c,b)(a)` // right to left `_.flowRight(d,c,b)(a)` // right to left `_.backflow(d,c,b)(a)` // right to left ## RamdaJS `_.pipe(b,c,d)(a)` // left to right # But why are we inventing so many ways of doing forward, backward function application and composition. Aside: I've never found an application of lodash `_.chain` that couldn't be expressed in a better way.
- bpicolo 11y ago
  Elixir has this exact feature. I'm sure it's not the first language to either.
  - bitwalker 11y ago
    F#/OCaml too, probably all the ML variants actually.
abrezas 11y ago
C++ has a piping operator?
toni 11y ago
attrs |> bounded('age', 1, 100) |> format('name', /^[a-z]$/i) |> Person.insertIntoDatabase This reminds me of those "Perl Poetry" code snippets from 2001.
- mbreese 11y ago
  Yes, and we all know how that turned out with Perl. I don't think Perl is necessarily a good model for readable code. This seems to me to be a case of "just because we can, doesn't mean we should."
  - toni 11y ago
    There are a lot of programmers coming from other functional programming languages to Javascript, bringing a lot of ideas from their own language to "make Javascript better". On top of that, there are also "transpiler folks": Ruby |> CoffeeScript, C#/F# |> TypeScript, etc... The classical Javascript programmer might be the last of a dying breed.
gotchange 11y ago
This is syntactic sugar not cruft. They're not proposing to add any new functionality to what we already have.

edgyswingset 11y ago

Can't speak for nim, but Clojure has a near-exact feature which is used all over the place, the thread-first and thread-last macros. Example: (defn do-stuff [params-map] (-> (build-object params-map) (do-thing-with-object) (extract-thing) (format-thing))) I'm not sure why you'd choose Clojure to get away from things like |>.

wnfewnlkew 11y ago
Clojure is a functional language, so it meshes well with the rest of the syntax, but in javascript's case it's just syntax bloat. It's going to be really jarring in the middle of regular imperative code, and it's not going to be too far removed from cout << "foo";
- danneu 11y ago
  Whether `|>` would mesh with your code depends on the code that's already there. Doesn't seem fair to shut down this proposal because you happen to write and work with imperative code, a style that Javascript and modern abstractions are moving away from. In fact, the Javascript hack to get a pipeline-like style is to make some opaque wrapper object that you can chain method calls onto like `_.chain(a).b().c().d().value()` in Lodash, when all you wanted was a chain of function application. `|>`, `<|`, composition operators, and friends would all be welcome complements to the Javascript code bases I've worked with in the last few years.
  - takle 11y ago
    # Why not ## Lodash `_.flow(b,c,d)(a)` // left to right `_.compose(d,c,b)(a)` // right to left `_.flowRight(d,c,b)(a)` // right to left `_.backflow(d,c,b)(a)` // right to left ## RamdaJS `_.pipe(b,c,d)(a)` // left to right # But why are we inventing so many ways of doing forward, backward function application and composition. Aside: I've never found an application of lodash `_.chain` that couldn't be expressed in a better way.
bpicolo 11y ago
Elixir has this exact feature. I'm sure it's not the first language to either.
- bitwalker 11y ago
  F#/OCaml too, probably all the ML variants actually.

abrezas 11y ago

C++ has a piping operator?

toni 11y ago

attrs |> bounded('age', 1, 100) |> format('name', /^[a-z]$/i) |> Person.insertIntoDatabase This reminds me of those "Perl Poetry" code snippets from 2001.

mbreese 11y ago
Yes, and we all know how that turned out with Perl. I don't think Perl is necessarily a good model for readable code. This seems to me to be a case of "just because we can, doesn't mean we should."
- toni 11y ago
  There are a lot of programmers coming from other functional programming languages to Javascript, bringing a lot of ideas from their own language to "make Javascript better". On top of that, there are also "transpiler folks": Ruby |> CoffeeScript, C#/F# |> TypeScript, etc... The classical Javascript programmer might be the last of a dying breed.

gotchange 11y ago

This is syntactic sugar not cruft. They're not proposing to add any new functionality to what we already have.