Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JavaScript Pipeline Operator

yanis.blog

Post reply on HN
Print view View original

41–50 of 63 posts

Re: The JavaScript Pipeline Operator

#41

Post by ravenstine »

icholy wrote: post #4

ES6 was needed, but I think js should hit the breaks for new language features for a while.

I'd rather that JavaScript as a community take a break from the framework wars. The amount of gained productivity occurring from new frameworks being created is miniscule, and in some ways it detracting. Meanwhile, other language communities have settled on a few frameworks and have allowed them to mature. Out of the gate, React already spawned a bunch of clones that claim to do things better. I'd bet good money that in 3 years React will be tossed aside like AngularJS for the next thing announced by the predominant tech company of the day. Hey, maybe one of Elon Musk's companies makes a JavaScript framework.

I'd rather that JavaScript continue to add features so that it remains relevant. I like its ubiquity and the the fact that it's both a server and browser language, and would hate to see it get completely railroaded by other language runtimes that can be compiled to WASM.

Re: The JavaScript Pipeline Operator

#42

Post by tracker1 »

yanis_t wrote: post #14
icholy wrote: post #4

ES6 was needed, but I think js should hit the breaks for new language features for a while.

I tend to agree with you. The thing is that most people would agree but at the time everyone wants different features. Me personally I even think we could be better without classes and all that "pretend you're writing Java" nonsense

I tend to prefer more utility/function approaches as much as possible. The exception to sometimes you need to carry context in a way often more simple (in terms of source complexity) to use class syntax. Not in every case, but some.

Re: The JavaScript Pipeline Operator

#43

Post by gedy »

> "Expressions Math.sqrt(64) and 64 |> Math.sqrt are equivalent. The difference is in how we read it. With pipeline operator data flows from left to the right, and thus making it much more comprehensible"

Ugh, no, that's a very subjective statement, 64 |> Math.sqrt is not "much more comprehensible" assuming especially for beginners.

Re: The JavaScript Pipeline Operator

#45

Post by Spivak »

hajile wrote: post #27
Spivak wrote: post #13

Earlier quoted context omitted.

64 |> Math.sqrt becomes pipe(64, Math.sqrt) 64 |> Math.sqrt |> Math.sin becomes pipe(pipe(64, Math.sqrt), Math.sin) Assuming pipe was smart and took varags we can make this better. 64 |> Math.sqrt |> Math.sin becomes pipe(64, Math.sqrt, Math.sin)

A pipe operator compiles directly into the AST and completely disappears before execution. 64 |> Math.sqrt |> Math.sin Compiles in the AST to Math.sin(Math.sqrt(64)) //curries variables away from functions var realPipe = (a, ...args) => (...initParams) => { var acc = a(...initParams); for (var i = 0; i (typeof a === "function") ? realPipe(a, ...args) : realPipe(...args)(a) I'd note that this pipe implementation also…

I see no reason our function form couldn't do the same magic behind the scenes. Really no different from a lot of C compilers in this respect and with the bonus of an absolutely trivial polyfill.

Re: The JavaScript Pipeline Operator

#46

Post by WorldMaker »

sAbakumoff wrote: post #2

rxjs is already available and allows to perform chained transformations by using wide variety of methods.

rxjs encourages a pipe() function approach as mentioned in other threads. It would still benefit from a pipe operator replacing that function, as the operator version would be easier to type (in Typescript and Flow) and to some of us aesthetically cleaner. The pipe operator that this article is hoping gets adopted is just a generic version of the rxjs pipe() function.

Re: The JavaScript Pipeline Operator

#47

Post by williamdclt »

gedy wrote: post #43

> "Expressions Math.sqrt(64) and 64 |> Math.sqrt are equivalent. The difference is in how we read it. With pipeline operator data flows from left to the right, and thus making it much more comprehensible" Ugh, no, that's a very subjective statement, 64 |> Math.sqrt is not "much more comprehensible" assuming especially for beginners.

I agree that this example isn't convincing, I also prefer the "vanilla" Math.sqrt(64).

It's more convincing (IMO) when chaining calls, eg:

Math.sqrt(Math.ceil(Math.sin(64))) VS. 64 |> Math.sin |> Math.ceil |> Math.sqrt

Re: The JavaScript Pipeline Operator

#48

Post by WorldMaker »

_uhtu wrote: post #32
icholy wrote: post #4

ES6 was needed, but I think js should hit the breaks for new language features for a while.

I disagree. ES6 made JS much more palatable but it's still behind most modern languages in terms of number of features and in velocity of new features getting introduced. Javascript has actually been extremely slow to get new features compared to other languages. Since ES6 (3 years ago), the only major, mainstream feature that has been added to JS has been async functions, which are awesome, but in that time Python (…

> In my opinion, JS badly needs more functions in it's standard library, which should move through the proposal policy quickly. However, common sense standard library functions like flatMap have been in the pipeline for years are still not in the final stage. We may not get flatMap, import(), trimStart, or trimEnd in ES2019, they are all stalled in Stage 3. There's no good arguments not to have these in the standard library, but we still have to wait years.

This is one of the arguments for the pipeline operator, as well. Right now browsers are inherently quite afraid of adding things to Object.prototype, Array.prototype, etc, because doing so breaks things. There are too many ancient JS libraries that patch whatever they want into Object.prototype/Array.prototype, such as MooTools, that threaten to break if the prototypes themselves change from what is expected. This is how flatMap() got stuck into "SmooshGate" and the intentionally absurd proposal that it should be named smooshMap(), because if Browsers add Array.prototype.flatMap it does break versions of MooTools still out in the wild.

The pipeline operator is one option (among several proposed options) to move the standard library forward without compromising backward compatibility. Maybe we can't have nice things like `myArray.flatMap()` because it breaks backwards compatibility, but maybe something like `myArray|>flatMap()` is an acceptable compromise.

Re: The JavaScript Pipeline Operator

#49

Post by mercer »

williamdclt wrote: post #47
gedy wrote: post #43

> "Expressions Math.sqrt(64) and 64 |> Math.sqrt are equivalent. The difference is in how we read it. With pipeline operator data flows from left to the right, and thus making it much more comprehensible" Ugh, no, that's a very subjective statement, 64 |> Math.sqrt is not "much more comprehensible" assuming especially for beginners.

I agree that this example isn't convincing, I also prefer the "vanilla" Math.sqrt(64). It's more convincing (IMO) when chaining calls, eg: Math.sqrt(Math.ceil(Math.sin(64))) VS. 64 |> Math.sin |> Math.ceil |> Math.sqrt

I used to feel that way until I got comfortable with Elixir and its pipe operator. I think without prior knowledge the latter, which is interpreted left-to-right, is more intuitive: "take some data, do x, do y, do z"

Re: The JavaScript Pipeline Operator

#50

Post by ConcernedCoder »

mbostock wrote: post #28

You don’t need lodash or a new operator for the example provided: departments .flatMap(d => d.employees) .map(e => e.salary) .reduce((p, v) => Math.max(p, v), 0) That said, the pipe operator is nice because it allows similar chaining patterns on subjects that are not arrays, as shown in the proposal’s README: https://github.com/tc39/proposal-pipeline-operator/blob/mast...

That's all well and good ( increasing readability ) but the problem remains that each step has to finish before the next step can begin... sometimes the entire dataset won't fit into memory/machine/whatever...

More useful, IMHO, would be a way to EASILY compose a true pipeline:

  const
    _pipe = (a, b) => (arg) => b(a(arg)),
    pipe = (...ops) => ops.reduce(_pipe)
...but have the behavior work like unix pipes ( a stream ), nodeJS supports this concept at it's most basic level using the pipe() abstraction, although you have to supply methods which handle being pipe'd to, and from... an example:

  const crypto = require('crypto');
  // ...
  fs.createReadStream(file)
    .pipe(zlib.createGzip())
    .pipe(crypto.createCipher('aes192', 'a_secret'))
    .pipe(reportProgress)
    .pipe(fs.createWriteStream(file + '.zz'))
    .on('finish', () => console.log('Done'));
*ripped from: [source](https://medium.freecodecamp.org/node-js-streams-everything-y...)

Imagine reading a 100gb json file line-by-line via ajax on the client, and feeding into the pipeline of transformative methods -- iteratively introduce data in one end of the pipe, and gathering the results at the other end, and creating some visualization like a graph or whatever... without ever having to have the entire thing in memory at once...

Post reply on HN