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

141–150 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#141

Post by captainmuon »

hajile wrote: post #128
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 F# syntax looks/acts a lot better here (especially paired with lodash). I also feel your code example wasn't done in the way people would actually use pipes. import {map, join} from 'lodash/fp' //iterators have better performance envars |> Object.entries |> map(([key, val]) => `${key}=${val}`) |> join(' ') |> x => chalk.dim('$ ' + x, 'node', join(' ', args)) |> console.log Even without lodash, it's still easy to…

The F# syntax would endlessly confuse me though. I'd always wonder whether |> join(' ') means join(x, ' ') or join(' ', x).

Re: Pipe Operator (|>) For JavaScript

#143

Post by scotty79 »

asciimov wrote: post #103

This just complicates things if you have any kind of complex nesting. Something "simple" like: a(b(),c(),d(e(),f(g()))) Turns into the following: value |> b() |> a( %, c() , v2 |> e() |> d(%, v1 |> g() |> f(%) ))

Nope, it becomes:

g() |> f(%) |> d(e(), %) |> a(b(),c(), %)

Which makes super clear what processing is actually done. Which is the data to process and which are just parameters of processing.

Because it could equivalently be:

e() |> d(%,f(g())) |> a(b(),c(), %)

If the data you process is rather produced by e() not by g().

This new syntax allows you to express intent beyond what's possible without it.

Re: Pipe Operator (|>) For JavaScript

#144

Post by rektide »

cokeandpepsi wrote: post #125
dns_snek wrote: post #107

Earlier quoted context omitted.

I won't speak about the specifics of the chosen syntax (Hack/F#) but in general - absolutely. With pipes you can visually follow the manipulations and function calls in the order that they happen instead of being forced to scan the code inside-out & outside-in, matching parentheses and function call parameters in your head, while still visualizing intermediate results to get 1 final return value. I find Elixir code m…

the refactored version of the example is much worse

why? are you of a 'pointfree' opinion? what are your concerns? https://wiki.haskell.org/Pointfree

personally i detest pointfree syntax. having intermediate values makes it much easier to step through code with a debugger & see what is happening. and it gives the reader some name for what the thing is, which is incredibly useful context. the enablement of pointsfree styles is one of my main concerns about potential pipe operator syntaxes: the various syntaxes that have been raised often introduce implicit variables which are passed, and i greatly fear the loss of clarity pointsfree style brings.

maybe there's something beyond the pointsfree vs not debate here that i'm missing, that makes you dislike the refactored example. personally i greatly enjoy the flatness, the step by step production of intermediate values, each of which can be clearly seen, and then assembled in a last final clear step. that is much more legible to me than one complex expression.

Re: Pipe Operator (|>) For JavaScript

#145

Post by pavlov »

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…

Internet Explorer supported multiple script languages.

The DOM in IE was essentially a COM API and callable from any supported scripting language. This included JScript (their JavaScript clone) but also VBScript and PerlScript.

Re: Pipe Operator (|>) For JavaScript

#146

Post by shadowgovt »

This makes me nervous.

In general, I think adding features like this to a mature language is a misstep because it increases the cognitive load of "things you have to know to read other people's code." And that's strictly increases... Since changes like this can't remove previous approaches (for backwards compatibility reasons), we'll now have three syntaxes for function calls? Yuck.

Left unchecked, this predilection eventually leaves you with languages like C++: a language where you can write good, safe code if you stick to modern methods, but good luck learning what "modern methods" are or finding tutorial books that don't teach you any of the bad-old approaches or, most importantly, working with other people's C++ code that still has `setjjmp` and `longjmp` in it because the language allows for it, therefore someone used it somewhere.

(oblig: https://xkcd.com/927/)

Re: Pipe Operator (|>) For JavaScript

#147

Post by brundolf »

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 lines of JSX, things start getting really spread out

Re: Pipe Operator (|>) For JavaScript

#148

Post by _boffin_ »

scotty79 wrote: post #143
asciimov wrote: post #103

This just complicates things if you have any kind of complex nesting. Something "simple" like: a(b(),c(),d(e(),f(g()))) Turns into the following: value |> b() |> a( %, c() , v2 |> e() |> d(%, v1 |> g() |> f(%) ))

Nope, it becomes: g() |> f(%) |> d(e(), %) |> a(b(),c(), %) Which makes super clear what processing is actually done. Which is the data to process and which are just parameters of processing. Because it could equivalently be: e() |> d(%,f(g())) |> a(b(),c(), %) If the data you process is rather produced by e() not by g(). This new syntax allows you to express intent beyond what's possible without it.

If i saw that in a colleague's code, i'd be angry at them as that's not legible.

Re: Pipe Operator (|>) For JavaScript

#149

Post by dns_snek »

cokeandpepsi wrote: post #125
dns_snek wrote: post #107

Earlier quoted context omitted.

I won't speak about the specifics of the chosen syntax (Hack/F#) but in general - absolutely. With pipes you can visually follow the manipulations and function calls in the order that they happen instead of being forced to scan the code inside-out & outside-in, matching parentheses and function call parameters in your head, while still visualizing intermediate results to get 1 final return value. I find Elixir code m…

the refactored version of the example is much worse

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.

Re: Pipe Operator (|>) For JavaScript

#150

Post by masklinn »

vikingerik wrote: post #129
substation13 wrote: post #43

Earlier quoted context omitted.

It's annoying to have to decide on and write out so many names. The intermediary names are not relevant to solving the problem. This is so much less noisy: value |> one |> two |> three

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.

There are lots of cases where they’re not and are just noise written in exactly the style of the original comment. Or worse all the one-shot temporaries get assigned to the same worthless name.

Unless you live and die by the mantra that no expression can have more than one period, pipes pretty much just bring attribute/method chaining to arbitrary functions and expressions.

Post reply on HN