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

Pipe Operator (|>) For JavaScript

github.com

Post reply on HN
Print view View original

281–290 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#281

Post by substation13 »

charles_f wrote: post #266
substation13 wrote: post #160

Earlier quoted context omitted.

> The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. I just don't think that this is always true. Consider: const highestScore = players |> filter(x => x.isAlive) |> map(x => x.score) |> tryMax I don't see how this is better: const alivePlayers = filter(x => x.isAlive)(players); const scoresOfalivePlayers = map(x => x.score)(alivePlayers); const hig…

> I don't see how this is better Case in point: > you can add helpful comments to pipeline code if needed The pipeline with explanatory variables explain to you what the steps are with code . Using pipeline you need to add comments to explain "what" you are doing.

Then you can mix-and-match:

    const activePlayers = 
      players
      |> filter(x => x.isAlive)

    const highestScore = 
      activePlayers
      |> map(x => x.score)
      |> tryMax
In any case, I don't see how being restricted to always using an intermediary variable for every step is an advantage.

Re: Pipe Operator (|>) For JavaScript

#282

Post by scotty79 »

lucideer wrote: post #260
scotty79 wrote: post #247

Earlier quoted context omitted.

It's not jarring. It expresses what is the subject that's being processed and what are additional parameters of the processing steps. This allows to keep all parameters of each processing step together and processing steps easily visually separable.

> It's not jarring. It expresses what is the subject that's being processed and what are additional parameters of the processing steps. Only if the first parameter of the function is the sole subject & subsequent parameters are "additional". Which isn't the case in this example: all params are equal subjects.

Right. `chalk.dim()` is probably not the best thing to use as an example for this.

But you can still think about this as merging in two additional pipes into the one you are processing. So 'node' and argsOutput are just very short pipes that you are merging into the flow of current one.

Btw... chalk API feels super weird.

Re: Pipe Operator (|>) For JavaScript

#283

Post by TheAngush »

hajile wrote: post #204
dns_snek wrote: post #181

Earlier quoted context omitted.

Technically , you should be able to write something uniquely terrible like this ;) return ( {(() => { const barStuff = bar(stuff); return foo(barStuff); })()} )

They should repurpose `do` so that `do {}` (without the `while`) is an expression that you can put statements inside and return the last statement. It would be great if we had expression if..else too (instead of just the tertiary operator)

> They should repurpose `do` so that `do {}` (without the `while`) is an expression that you can put statements inside and return the last statement.

There's a proposal for precisely that. Unfortunately, only Stage 1 though.

https://github.com/tc39/proposal-do-expressions

Re: Pipe Operator (|>) For JavaScript

#284

Post by scotty79 »

hajile wrote: post #238
scotty79 wrote: post #227

Earlier quoted context omitted.

Is the point of those just immutability or something else too? Wouldn't it be better to have a way to easily make any type deeply immutable? EDIT: I think tuples and records are also supposed to have value semantics, which is great, but why not a mechanism that turns on value semantics for arbitrary object type instead. Also value semantics is separate concept from immutability. Maybe there should have separate ways…

Objects carry prototypes and mutability with them. Further, all primitives/value types of the language are immutable. Adding those features to an Object would still necessitate creating a new primitive. At that point, you might as well make that primitive record that is directly available and just use the constructor to convert (just like you'd use `Number("123")`, you'd use `Record({my: "object"})`).

> Objects carry prototypes and mutability with them.

You can deep freeze the objects and freeze their prototypes.

Re: Pipe Operator (|>) For JavaScript

#285

Post by pharmakom »

galaxyLogic wrote: post #95
pharmakom wrote: post #38

Earlier quoted context omitted.

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.

I think we should have BOTH. Use |> for the Hack proposal and -> for F# -style.

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

#286

Post by pharmakom »

maxloh wrote: post #256
galaxyLogic wrote: post #82

Earlier quoted context omitted.

But in the Hack proposal wouldn't that have to be “hello world” |> titleCase (%) I'm starting to like the F# proposal more now.

Consider the example code here in Hack, const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> await fetch(%) |> await %.json() |> %.properties.periods[0] In F# it would be much more verbose, const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> fetch |> await |> json |> await |> x => x.properties.periods[0] // or |> { properties : { periods: [result] } } => result Hack will a…

Number of key strokes is only one design consideration and not even a very important one

Re: Pipe Operator (|>) For JavaScript

#287

Post by arp242 »

dmix wrote: post #272
arp242 wrote: post #257

Earlier quoted context omitted.

What is the point then?

I don't see design docs as a tutorial on how to be a better programmer using a new syntax, the goal is to flesh out a new concept built on some fundamental ideas. You cherry picked one example of a tangled/messy block of code that they used to communicate specific idea around "left to right" comprehension and flow of the data using the new syntax. For that specifically it did a fine job. But that doesn't mean that's…

The way I read the proposal is that they used a real-world example from a commonly used codebase (React) to demonstrate how this feature would improve it. I think that's a good approach as features are intended to address real-world concerns, and concrete real-world examples help with that.

I don't think it's fair to say it's "cherry picking" to focus on the example they focus on themselves. They have a few other examples too, but I would say "I don't see how [NEW] is better than [OLD]" for many of those as well (and for some, I think the [NEW] is significantly worse).

Re: Pipe Operator (|>) For JavaScript

#288

Post by pharmakom »

renke1 wrote: post #69
pharmakom wrote: post #35

The pipe operator is awesome because you can use it to “extend” objects without messing with their prototypes. Missing String.titleCase ? Write your own! “hello world” |> titleCase

There was also a different proposal that allows objects to be extended: https://github.com/tc39/proposal-bind-operator Personally, I don't use classes much, but sometimes I think free functions are a little too hard to find, so I tend to experiment with the following pattern. interface User { … } const User = { rename(user: User, newName: string): User { … }, getDisplayName(user: User): string { … } } const renke: Us…

This is the beauty of pipeline operator. It adds very little extra machinery - it’s just an infix operator that makes working with free functions easier.

Re: Pipe Operator (|>) For JavaScript

#290

Post by mg »

I wonder if "%" placeholder is the right approach. It makes the code longer in most cases.

Without pipes:

    a = d(c(b))
With pipes in the proposed form:

    a = b|>c(%)|>d(%)
My first approach to design it would be:

    a = b~>c~>d
So the rule is that on the right side of the pipe operator (~>) there is always a function. We don't need parenthesis to indicate that.

If the function takes more than one argument, it can be defined by another value on the left of it.

Without pipes:

    a = d(c(b,7))
With pipes in the proposed form:

    a = b|>c(%,7)|>d(%)
With the ~> approach:

    a = b,7~>c~>d
Post reply on HN