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

361–370 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#361

Post by cyberlock »

stouset wrote: post #353
arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

> Is this… ${new-style} really better than… ${old-style}? Yes! A hundred thousand times yes! I have not seen this syntax in JavaScript before, but just by having the vague notion that it's pipe-like, I was able to generally understand what was happening within seconds of reading it. I'd have to read up on the syntax a bit to confidently write code in this style, or perhaps to fix a bug (does "${%}" do what I think it…

[flagged]

Re: Pipe Operator (|>) For JavaScript

#362

Post by dalmo3 »

wefarrell wrote: post #252
notdonspaulding wrote: post #174

Earlier quoted context omitted.

I struggle to think of real-world examples where I've just needed to chain and chain and chain values of different types more than a handful of times. The claimed need for the pipe operator is this construction: function bakeCake() { return separateFromPan(coolOff(bake(pour(mix(gatherIngredients(), bowl), pan), 350, 45), 30)); } The piped code looks like: function bakeCake() { return gatherIngredients() |> mix(%, bow…

Imagine that you asked someone the question "How do you make a cake?" Which response would be clearer? 1. Gather the ingredients, mix them in a bowl, pour into a pan, bake at 350 degrees for 45 minutes, let it cool off and then separate it from the pan. 2. Get ingredients by gathering the ingredients. Make batter by mixing the ingredients. Make batter in a pan by pouring the batter in a pan. Make a baked cake by baki…

Right, it works for your analogy.

Going back to the concrete scenario GP presented, naming things makes it much clearer to me.

Re: Pipe Operator (|>) For JavaScript

#363

Post by vikingerik »

substation13 wrote: post #160
vikingerik wrote: post #129

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. Code is read far more than it is written. Use temporary variables. Put in the effort to name them once, and then that effort pays back every time anyone needs to read and understand the code.

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

    const alivePlayers = filter(x => x.isAlive)(players);
    const scoresOfalivePlayers = map(x => x.score)(alivePlayers);
    const highestScore = tryMax(scoresOfalivePlayers);
I think this is way better. The variable names tell me at an instantaneous glance what each clause is doing. I don't have to spend mental effort delving into what's going on with the lambdas, or scan back and forth to find a comment that may or may not be there or out of date if it is.

Furthermore, I'd wrap all of those lines together into a getHighestScore() function as well. That makes the complexity exactly as visible or as abstracted as you want at any given moment. The name of that function tells you what the aggregate of the operations is doing, and you can go look inside that function if you want to see the individual steps.

Re: Pipe Operator (|>) For JavaScript

#364

Post by scotty79 »

notdonspaulding wrote: post #317
greggman3 wrote: post #239

Earlier quoted context omitted.

and yet looking through code from the place you work I see something like this let field = ve.instanceContext.replace(/(#\/)|(#)/ig, "").replace(/\//g, ".") Which you apparently claim should be const fieldWithHashMarksUnesacped = ve.instanceContext.replace(/(#\/)|(#)/ig, ""); const field = fieldWithHashMarksUnesacped.replace(/\//g, ".") https://github.com/mirusresearch/firehoser/blob/46e4b0cab9a2... and this return m…

Thanks for taking the time to look and reply. In your first find, yes, your modification helps me understand that code much more quickly. Especially since I haven't looked at this code in several years. In that case, patches welcome! In your second case, as the sibling comment explained, I'm not opposed to chaining in all cases. But if the pipe operator is being proposed to deal with this situation, I'm saying the ju…

|> is for functions the same thing that . is for methods

If you program in object oriented style then . is mostly all you need.

If you program in functional style you could really use |>

Re: Pipe Operator (|>) For JavaScript

#365

Post by xigoi »

pharmakom wrote: post #38
arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

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.

Before ES6: “The arrow function proposal is horrible imo because it doesn’t look like JS anymore.”

Re: Pipe Operator (|>) For JavaScript

#366

Post by marcosdumay »

Someone1234 wrote: post #96

Can someone remind me again why there's never been movement to add a second modern language to web-browsers? JavaScript was created in a weekend and then stuff tacked on for the last 28 years. We know so much more about how to create programming languages today than we did then, and the whole "Year of the Linux Desktop" has become a WebAssembly meme now every year since its introduction six years ago, with it getting…

If you want to use wasm, just go and use it. You don't need every other site to do the same before you jump in.

Personally, I do think JS is a better fit than Rust or C for almost everything people do on the web. And the support in other languages is still too bad to use. But you can use it whenever you want, differently from a second language you may invent.

Re: Pipe Operator (|>) For JavaScript

#367

Post by pharmakom »

xigoi wrote: post #365
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.

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

#368

Post by dgb23 »

ketzu wrote: post #360
dgb23 wrote: post #167

Saw a talk with Douglas Crockford[0] years ago. He said something like: Before JS classes got introduced he asked why they didn't just implement macros for the language. Classes are in fact just syntactic sugar. Just like async/await, and now this proposal. In hindsight he was right. JS would be better off if it did have macros. Much of the whole babel/webpack/react/ts stuff would be just a bunch of macros instead of…

> Much of the whole babel/webpack/react/ts stuff would be just a bunch of macros instead of idiosyncratic build tools and so on. And we would have had much less compatibility churn. Wouldn't that just trade compatibility churn against running the transpilers on client side in javascript, making it even slower to execute? Moving this part of the execution on the developer side seems like a good choice to me.

It’s not as clear how macros affect performance.

You can write macros that are very declarative but generate very hairy code that you wouldn’t necessarily write by hand. The result might be much more machine optimized.

Sure, you pay some upfront cost for expansion, but generally speaking macros don’t hinder you to write fast code, they just give you more options and trade offs.

Re: Pipe Operator (|>) For JavaScript

#369

Post by quickthrower2 »

arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

I don’t like complex nesting inside the string though. That might be a nitpick as you can split that out without the pipe operator.

Re: Pipe Operator (|>) For JavaScript

#370

Post by mkl »

masklinn wrote: post #140
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.

> 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.
Post reply on HN