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

181–190 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#181

Post by dns_snek »

brundolf wrote: post #147
captainmuon wrote: post #133

I don't understand why you can't just use temporary variables. The article mentions mutation is bad, but what actually happens is that the name gets reassigned. No value is mutated. That brings me to something I really want in JS, actual unmutable values. If you use `const x = new SomeClass()`, you cannot reassign it, but you can change fields. The first time I encountered `const`, I thought it did the opposite. It w…

A problem is that you can only declare intermediate constants in a statement context, not an expression context. And with React, more and more JS devs are spending time in expression contexts Example: return ( {foo(bar(stuff))} ) There's no way to break out inline intermediate constants here; you have to bail out and do it up above the `return`. In this case that may not be too bad, but when you've got a hundred line…

Technically, you should be able to write something uniquely terrible like this ;)

  return (
    
      {(() => {
        const barStuff = bar(stuff);
        return foo(barStuff);
  })()}
    
  )

Re: Pipe Operator (|>) For JavaScript

#182

Post by pier25 »

kriz9 wrote: post #53

Temporary variables are often tedious? I have found that well named temporary variables are the only clear way to comment code without actually writing the comment. The version with temporary variables is much easier to understand without having to read the rest of the code.

I agree.

I'm afraid these pipe operators will become like ternaries and will tend to produce "smart" lines of code which are difficult to parse at first glance.

Temporary variables are great for writing obvious code which is trivial to parse when reading.

Re: Pipe Operator (|>) For JavaScript

#183

Post by yamtaddle »

scotty79 wrote: post #175
yamtaddle wrote: post #159

Earlier quoted context omitted.

At least I can instantly tell which call is ultimately returning something, in that version.

There's nothing preventing you from not using the pipe for last call or even introducing that rule in your team if you can convince your colleagues it's a good idea or even automate it with the use of a linter. If it's really good rule you can advocate for it at this stage. It might be prudent to use |> % only inside function call parameter or possibly as right hand of an assignment instead of everywhere where parser…

That's almost worse. I think I'd have to break out pen and paper to figure out which of those things end up returning arguments to function "a".

Re: Pipe Operator (|>) For JavaScript

#184

Post by vips7L »

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…

Dart could have been our savior.

Re: Pipe Operator (|>) For JavaScript

#185

Post by dgb23 »

notdonspaulding wrote: post #174
scotty79 wrote: post #126

Earlier quoted context omitted.

When there are a few they can be really great. But if you need to accurately name every single intermediate thing they can become visual noise that hides what happens.

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…

Also the second example is easier to manipulate. You can hack in branches, logging etc. during development. I'm also not sure how the proposal tries to solve the problem that we can't easily pluck out members from an object in the first example. Will people just write something like `get(obj, "member")`? Or maybe they thought about this?

Re: Pipe Operator (|>) For JavaScript

#186

Post by brundolf »

dns_snek wrote: post #181
brundolf wrote: post #147

Earlier quoted context omitted.

A problem is that you can only declare intermediate constants in a statement context, not an expression context. And with React, more and more JS devs are spending time in expression contexts Example: return ( {foo(bar(stuff))} ) There's no way to break out inline intermediate constants here; you have to bail out and do it up above the `return`. In this case that may not be too bad, but when you've got a hundred line…

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

Yeah, JS programmers sometimes work around this and similar language gaps by making an inline function and immediately calling it (because that gives you a statement context inside of an expression context, which isn't normally possible). But IMO it's very rarely worth the hit you take to readability

Re: Pipe Operator (|>) For JavaScript

#187

Post by johnny22 »

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 that how they really do it? I haven't actually seen that happen. There's no reason not to take popularity into account for some measure, as long it's not the ONLY thing you take into account.

Re: Pipe Operator (|>) For JavaScript

#188

Post by drowsspa »

notdonspaulding wrote: post #174
scotty79 wrote: post #126

Earlier quoted context omitted.

When there are a few they can be really great. But if you need to accurately name every single intermediate thing they can become visual noise that hides what happens.

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…

What this reminds me is of those hierarchies Cat extends Animal... In these simple "real-world-inspired" examples it seems to make sense, but in programming I'd say a lot of times there's simply no good name for the intermediate steps.

Re: Pipe Operator (|>) For JavaScript

#189

Post by yamtaddle »

arp242 wrote: post #169
dns_snek wrote: post #149

Earlier quoted context omitted.

Do you mind elaborating? I find the refactored version significantly easier to understand than the original. Readability is one of the top priorities for me and I find the original example too clever, in a bad way.

I dislike variables that are used just once. Sometimes they're a "necessary evil", but rarely. For "envStr" it's defensible IMHO as it splits up some of the complexity, but I would rather just use a helper function, which has the same "splits complexity" effect and is re-usable. "styled" seems entirely pointless here.

In this case I like that it gives you a hint about what's going on. "chalk.dim" sure doesn't.

Re: Pipe Operator (|>) For JavaScript

#190

Post by postalrat »

notdonspaulding wrote: post #174
scotty79 wrote: post #126

Earlier quoted context omitted.

When there are a few they can be really great. But if you need to accurately name every single intermediate thing they can become visual noise that hides what happens.

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…

How about

    function bakeCake() {
      return do(
        () => gatherIngredients(),
        ingredients => mix(ingredients),
        batter => pour(batter, pan),
        batterInPan => bake(batterInPan, 350, 45),
        () => coolOff(bakedInPan),
        cooledCake => separateFromPan(cooledCake)
      );
    }
Post reply on HN