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

371–380 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#371

Post by mkl »

8note wrote: post #340
tgv wrote: post #99

Earlier quoted context omitted.

So their argument in favor of this fugly new operator is that some people write unreadable code? That's not the language's fault. As they say, you can write FORTRAN in any language. This just gives them a new tool to make things even worse. chalk.dim(Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}`, 'node', args.join(' ')) |> console.log(%); And it doesn't even work on objects. La…

I'm trying to compare this to the jQuery kinda syntax X .this() .that() .then() .do() .a() .thing() And I expect this to let me keep that chain going for when I need to run a static function against the chain X .this() .that() .then() .do() .a() .thing() |>JSON.stringify(%)

To format code as code, indent two spaces: https://news.ycombinator.com/formatdoc

Re: Pipe Operator (|>) For JavaScript

#372

Post by sfink »

scq wrote: post #342
sfink wrote: post #332

Earlier quoted context omitted.

Sadly, JS weirdness interferes with value semantics: > 0 === -0 true > #{v: 0} === #{v: -0} ???

That's not a JS thing, 0 and -0 comparing as equal is specified in the IEEE 754 floating point standard.

It's the JS `===` operator. The semantics are defined by JS. JS can use IEEE754 semantics for numeric `===` comparisons if it wants, but it'll be at a cost if there are other ways to distinguish the two. In this case, if you make `#{v: 0} === #{v: -0}` then you're ok with `a === b && 1/a.v !== 1/b.v` being possible.

I could see an argument for `0 == -0 && 0 !== -0`. It would have made it possible to say "if a === b, then a and b can use the same bitwise representation internally without losing information". But that's not what we have.

I guess for maximum consistency, we could use the 3rd JS equality operator `Object.is` with records, so that

    0 == -0
    0 === -0
    ! Object.is(0, -0)
    #{v: 0} == #{v: -0}
    #{v: 0} === #{v: -0}
    ! Object.is(#{v: 0}, #{v: -0})
but then all Record-comparing code would have to do `Object.is()` in order to avoid a recursive comparison. (Well, maybe the engines would get clever and include a "contains -0" flag in Records, and skip the recursion if it's false for both sides?)

Re: Pipe Operator (|>) For JavaScript

#374

Post by coffeebeqn »

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…

I mean it’s still not very readable. Reading through the code I can tell that it does.. some strong things with envars.

Re: Pipe Operator (|>) For JavaScript

#375

Post by mkl »

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…

JavaScript has been a frankenbeast of a language right from its inception, by design.

However, the 5th most requested feature in that poll is somehow "functions", and "sanity" also appears in the results, so this particular source may not be a good one.

Re: Pipe Operator (|>) For JavaScript

#376

Post by coffeebeqn »

_boffin_ wrote: post #223
scotty79 wrote: post #151

Earlier quoted context omitted.

It's no less legible than original code and at least expresses the intent of what's being processed, what are the processing steps and what are processing parameters. a(b(),c(),d(e(),f(g()))) is just function call soup.

And I’d be angry if I saw that too. Break out the soup into variables and have it all be In a clean layout

Use a functional language if you want to chain 10 functions together! I would definitely tell them in the PR to stop being clever and rewrite it

Re: Pipe Operator (|>) For JavaScript

#377

Post by pharmakom »

mkl wrote: post #370
masklinn wrote: post #140

Earlier quoted context omitted.

> 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

Re: Pipe Operator (|>) For JavaScript

#378

Post by trekkie1024 »

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…

Having done some personal projects in F#, I'm a huge fan of the syntax. However we would need most standard functions in JS to be curried to take advantage of it.

Re: Pipe Operator (|>) For JavaScript

#379

Post by wefarrell »

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…

I think what you're looking for is:

  const x = Object.freeze(new SomeClass())

Re: Pipe Operator (|>) For JavaScript

#380

Post by wruza »

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…

it's still easy to read

That’s highly subjective I’m afraid.

“Take entries of envvars, turn that into k=v, join that by a space, make dim $, previous that, and args, log that”.

Personally I have no clue what’s going on at first glance with all these %%% “thats”. It’s meant to be declarative, but reads imperatively instead.

  console.log(chalk.dim(
    '$',
    ...Object.keys(envars)
      .map(k => `${k}=${envars[k]}`),
    'node',
    ...args,
  ))
“Log dimmed $, k=v pairs of envvars, node, then args”.
Post reply on HN