Re:Pipe Operator (|>) For JavaScript
by pharmakom on Friday January 20, 2023 @10:54AM
(#34454758)
The Hack proposal is horrible imo because it doesn’t look like JS anymore. The F# proposal is 99% of the benefit whilst being actually approachable.
[ Parent
| on HN ]
> The Hack proposal is horrible imo because it doesn’t look like JS anymore.
I mean it looks exactly like JS with an additional % placeholder.
And a lot more like JS than the F# proposal.
How so? JS already has operators, but placeholders is a totally new concept
Is there another JavaScript feature that looks like a list of function names but which causes actions to be performed? Or operators that operate on both functions and values? The placeholders are very similar to variables, so do what they look like they do, and it's only the implicit definition that is new. The explicit placeholders feel much more like JavaScript to me than the implicit function calling of the F# proposal.
- functions and lambdas are already first-class values in JS
- we already have operators on values, such as +
- |> is just another operator on values
Re:Pipe Operator (|>) For JavaScript
by galaxyLogic on Friday January 20, 2023 @11:20AM
(#34455267)
I think we should have BOTH.
Use |> for the Hack proposal
and -> for F# -style.
I'd far rather save that for an alternative switch expression with pattern matching.
const slowSum = (lst: {x: number}[]) =>
switch(list) {
[{x}, ...y] -> x + slowSum(y) //not tail recursive
[{x}, {x: y}] -> x + y //alias second x to y
[{x}] -> x //handle length 1
[] -> 0 //handle length 0
}Having been watching, and a couple times playing with Rust... would definitely like a similar pattern matching system in JS. I still feel the C# syntax for this feels a bit alien `varname switch {...}`.
As an F# developer who also does some JS and Java this would confuse the hell out of me! |> is the best operator
Re:Pipe Operator (|>) For JavaScript
by grumpyprole on Friday January 20, 2023 @04:10PM
(#34459980)
There's no need. The % placeholder can be used for a consise lambda syntax and would work with a F# application operator.
It absolutely is, but time and time again TC39 has followed few champions over the waves of people favoring F# pipes.
It's incredible to me TC39 would rather have this monstruosity over F# pipes which are actually pretty similar to how most pipes work and read in most functional languages including unix `|` one.
Re:Pipe Operator (|>) For JavaScript
by WorldMaker on Friday January 20, 2023 @06:37PM
(#34461750)
On the flipside, I think that this is still such an ongoing debate is part of why the pipeline operator is still stuck in Stage 2 and having trouble getting into Stage 3, despite being listed as a "priority" multiple times on and before 2020. TC-39 isn't blindly following anyone here, they seem to be dragging their heels hoping that someone comes along with an even better compromise between the styles.
Before ES6: “The arrow function proposal is horrible imo because it doesn’t look like JS anymore.”
It’s a balance. I actually support the addition of the F# proposal, minus the await parts.
Re:Pipe Operator (|>) For JavaScript
by antipurist on Friday January 20, 2023 @06:47PM
(#34461889)
"Why did it take so long?" and "Pointless bloat!" reactions were much more common: