Live data from Hacker News

The JavaScript Pipeline Operator

yanis.blog

31–40 of 63 posts

Re: The JavaScript Pipeline Operator

#31

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...

Realistically, there's always a few functions I want to call on my data that aren't part of the prototype of the thing I'm transforming. And then this pipe operator is called for.

Re: The JavaScript Pipeline Operator

#32
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 (a language of similar age and global use) has gotten an optional type system, async/await, and _hundreds_ of standard library modules, classes, and functions.

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.

In addition to that, JS could really use some language features that make it's core paradigms, functional and object oriented, simpler, and have been in other languages for years. The pipeline operator would make functional programming much easier, and decorators would make object oriented programming easier. These are, in my opinion, common sense features since they are so well received in other langauges, but they get stalled out since they are seen as "bloating" the syntax, or making javascript "too opinionated on how to do something". Meanwhile, people are compiling full fledged functional languages (Reason, Elm, Purescript) to Javascript, because Javascript isn't keeping up with them on features. It could, but the TC39 review process is so slow that it's not worth waiting on. For those reasons, in my opinion, we should really be releasing new language features much quicker.

Re: The JavaScript Pipeline Operator

#33
post #30

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...

Good point. Is flatMap already supported by browsers or is it a proposal?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Is one of many results google returns on the topic.

Re: The JavaScript Pipeline Operator

#34
post #14
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 see this idea that adding classes to JS was a bad thing a lot, but even though I don't ever use classes in my codebase, I don't know why it would make sense to remove them before adding new features, or to stall new features because they exist and I don't like them.

In my opinion, we should be moving forward with features that make functional paradigms easier, such as the pipeline operator, regardless of the fact that JS has object oriented features. There's no reason to stall new features just because different people want different features, at this moment we're pleasing no one with the slow release cycle.

Re: The JavaScript Pipeline Operator

#35

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...

[deleted]

Re: The JavaScript Pipeline Operator

#36
post #8

>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 without the need to introduce extra variables. Why you need operator? Can't it be done with a function? pipe(64,Math.sqrt)

And if you have 10 of them in a row then you have: pipe(pipe(pipe(pipe(pipe(pipe(pipe(pipe(pipe(pipe(64,sqrt),add),divide),subtract,....)

I don't know about you, but I wouldn't want to debug that.

Re: The JavaScript Pipeline Operator

#39
post #30

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...

Good point. Is flatMap already supported by browsers or is it a proposal?

Still a proposal and experimental, stage 3.

Re: The JavaScript Pipeline Operator

#40
post #30

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...

Good point. Is flatMap already supported by browsers or is it a proposal?

Both flat[1] and flatMap[2] are unsupported in Edge, IE and Node.

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Post reply on HN