4 ms·

What's so painful about just doing `exclaim(capitalize(doubleSay("hello")));`? Why introduce needless syntactic sugar that'll only confuse people about how UNIX

by pskocik 11y ago

What's so painful about just doing `exclaim(capitalize(doubleSay("hello")));`? Why introduce needless syntactic sugar that'll only confuse people about how UNIX pipes work?

thescriptkiddie 11y ago
(because (there (is (such (a (thing (as (too (many parens)))))))))
- pskocik 11y ago
  I bet Lispers would beg to differ. :D Nested function do one thing on a chunk of data, then another, then another. *nix pipelines apply all the filters at once and control the scheduling and lifetime of the filters. Those are quite different concepts, and I think it's confusing to conflate the two. Plus every decent editor can handle paired parentheses.
  - danneu 11y ago
    > I bet Lispers would beg to differ. :D Would they? I wrote and read threading macros all the time when I used Clojure. Turns out it cleans up code.
- efdee 11y ago
  I think you meant many_parens(too(as(thing(a(such(is(there(because)))))))).
radicalbyte 11y ago
To understand the nesting you have to evaluate the functions in the opposite order than you're reading them: exclaim capitalize doubleSay Sure, some of us has spent 20 years doing this so it's easy, but you can't deny that this is far nicer to read: doubleSay capitalize exclaim I'm a big fan of Fluent Interfaces, so I use this construct fairly often: "hello".doubleSay().capitalize().exclaim()
- andrewpe 11y ago
  This should be how it's done, simplistic, nothing new to learn, easy to read.
edgyswingset 11y ago
Because that's a terrible code smell! The proper way to handle that case in a language which doesn't support pipelining would be to break each call into a variable and use those those variables. But even that can be tedious, hence the pipelining operators which have cropped up in some languages.
abrezas 11y ago
it's very common in javascript to have chained methods, to be able to do things like _(array) .compact() .map(function(x) { return x * x; }) .filter(function(x) { return x > 100; }).value() (example from underscore/lodash) The problem with this is to be able to add a custom function to this pipeline, you have to extend the prototype of the library with your own functions, or re-implement it. Extending the prototype is considered bad practice for a lot of reasons, for example due to polluting code in other modules or upstream changes breaking your code. If instead of chaining methods we chained functions we are left with this awkward syntax: custom(filter(map(compact(array), function(x) { return x * x; }), function(x) { return x > 100; })); it's much cleaner to write it like this: compact(arr) |> map(function(x) { return x * x; }) |> filter(function(x) { return x > 100; }) |> custom The linked page has a nice example and explanation about this concerning promises https://github.com/mindeavor/es-pipeline-operator#sample-usage-with-promises https://github.com/mindeavor/es-pipeline-operator#sample-usa...
- rakoo 11y ago
  > The problem with this is to be able to add a custom function to this pipeline, you have to extend the prototype of the library with your own functions, or re-implement it. That's exactly what transducers try to solve, and fortunately they do exist for js (http://jlongster.com/Transducers.js--A-JavaScript-Library-for-Transformation-of-Data http://jlongster.com/Transducers.js--A-JavaScript-Library-fo...) where processing of individual elements is separated from plumbing, so you can add your own custom computation in the chain. It even has pretty good performances (http://jlongster.com/Transducers.js-Round-2-with-Benchmarks http://jlongster.com/Transducers.js-Round-2-with-Benchmarks), all with the standard data structures ! Of course transducers are useful only when you want to transform data, not when you want to act on them in the chain.
deleted 11y ago
[deleted]

by pskocik 11y ago

What's so painful about just doing `exclaim(capitalize(doubleSay("hello")));`? Why introduce needless syntactic sugar that'll only confuse people about how UNIX pipes work?

thescriptkiddie 11y ago

(because (there (is (such (a (thing (as (too (many parens)))))))))

pskocik 11y ago
I bet Lispers would beg to differ. :D Nested function do one thing on a chunk of data, then another, then another. *nix pipelines apply all the filters at once and control the scheduling and lifetime of the filters. Those are quite different concepts, and I think it's confusing to conflate the two. Plus every decent editor can handle paired parentheses.
- danneu 11y ago
  > I bet Lispers would beg to differ. :D Would they? I wrote and read threading macros all the time when I used Clojure. Turns out it cleans up code.
efdee 11y ago
I think you meant many_parens(too(as(thing(a(such(is(there(because)))))))).

radicalbyte 11y ago

To understand the nesting you have to evaluate the functions in the opposite order than you're reading them: exclaim capitalize doubleSay Sure, some of us has spent 20 years doing this so it's easy, but you can't deny that this is far nicer to read: doubleSay capitalize exclaim I'm a big fan of Fluent Interfaces, so I use this construct fairly often: "hello".doubleSay().capitalize().exclaim()

andrewpe 11y ago
This should be how it's done, simplistic, nothing new to learn, easy to read.

edgyswingset 11y ago

Because that's a terrible code smell! The proper way to handle that case in a language which doesn't support pipelining would be to break each call into a variable and use those those variables. But even that can be tedious, hence the pipelining operators which have cropped up in some languages.

abrezas 11y ago

it's very common in javascript to have chained methods, to be able to do things like _(array) .compact() .map(function(x) { return x * x; }) .filter(function(x) { return x > 100; }).value() (example from underscore/lodash) The problem with this is to be able to add a custom function to this pipeline, you have to extend the prototype of the library with your own functions, or re-implement it. Extending the prototype is considered bad practice for a lot of reasons, for example due to polluting code in other modules or upstream changes breaking your code. If instead of chaining methods we chained functions we are left with this awkward syntax: custom(filter(map(compact(array), function(x) { return x * x; }), function(x) { return x > 100; })); it's much cleaner to write it like this: compact(arr) |> map(function(x) { return x * x; }) |> filter(function(x) { return x > 100; }) |> custom The linked page has a nice example and explanation about this concerning promises https://github.com/mindeavor/es-pipeline-operator#sample-usage-with-promises https://github.com/mindeavor/es-pipeline-operator#sample-usa...

rakoo 11y ago
> The problem with this is to be able to add a custom function to this pipeline, you have to extend the prototype of the library with your own functions, or re-implement it. That's exactly what transducers try to solve, and fortunately they do exist for js (http://jlongster.com/Transducers.js--A-JavaScript-Library-for-Transformation-of-Data http://jlongster.com/Transducers.js--A-JavaScript-Library-fo...) where processing of individual elements is separated from plumbing, so you can add your own custom computation in the chain. It even has pretty good performances (http://jlongster.com/Transducers.js-Round-2-with-Benchmarks http://jlongster.com/Transducers.js-Round-2-with-Benchmarks), all with the standard data structures ! Of course transducers are useful only when you want to transform data, not when you want to act on them in the chain.

deleted 11y ago

[deleted]