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...
The JavaScript Pipeline Operator
31–40 of 63 posts
Re: The JavaScript Pipeline Operator
#32ES6 was needed, but I think js should hit the breaks for new language features for a while.
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
#33You 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?
Is one of many results google returns on the topic.
Re: The JavaScript Pipeline Operator
#34ES6 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
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
#35You 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...
Re: The JavaScript Pipeline Operator
#36>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)
I don't know about you, but I wouldn't want to debug that.
Re: The JavaScript Pipeline Operator
#37 []+|>
Down from the 6 that jsfuck requires: []+!()Re: The JavaScript Pipeline Operator
#38Re: The JavaScript Pipeline Operator
#39You 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?
Re: The JavaScript Pipeline Operator
#40You 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?
1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...