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

61–70 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#61

Post by CyberDildonics »

nosianu wrote: post #41
CyberDildonics wrote: post #16

Earlier quoted context omitted.

If you're compiling from another language you would be using whatever syntactic sugar you want, why break compatibility just to have the compiled javascript look a little better?

> If you're compiling from another language TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That TypeScript, the tool, also adds a transpiler is a distraction that made a lot of people believe TS is a different language. Bu…

You're completely missing the point here. If you are transpiling something, you don't need to worry about syntactic sugar in the base language you are transpiling to, only what you're transpiling from.

Re: Pipe Operator (|>) For JavaScript

#62

Post by progx »

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…

For me not. In the Pipe example you must read first that something is done with the object and that it will be output at the end.

If i read a code and i want to now what it will do, i wanna first read that it will output something. If that is what i search for, i read the nested code.

With the pipe style i waste more time, even if the code looks clearer.

I not overused example could look like this:

  console.log(
    Object.keys(envars)
      .map(envar => `${envar}=${envars[envar]}`)
      .join(' ')
    |> `$ ${%}`
    |> chalk.dim(%, 'node', args.join(' '))
  )
If i don't care about console.log, i don't have to read the nested code.

Re: Pipe Operator (|>) For JavaScript

#63

Post by substation13 »

WastingMyTime89 wrote: post #49
hajile wrote: post #3

They should have stuck with the F# proposal. The hack proposal just takes one more giant step toward turning JS into Perl. Hack proposal value |> foo(%) for unary function calls, value |> foo(1, %) for n-ary function calls, value |> %.foo() for method calls, value |> % + 1 for arithmetic, value |> [%, 0] for array literals, value |> {foo: %} for object literals, value |> `${%}` for template literals, value |> new Foo…

On the one hand, I tend to agree and I dislike making JS syntax even more complex than it already is. On the other hand, it works well in F# (and the ML that then borrowed it from F#) because it’s just a standard infix operator there and everything is already curried which is definitely not the case with JS. It means you will nearly always have to use a lambda when piping in JS which is honestly a bit tedious.

You do for member access, e.g.

    let firstName = 
      person
      |> fun x -> x.FirstName
      |> trim
Some languages allow:

    let firstName = 
      person
      |> .FirstName
      |> trim
But you're right, expression-orientation and currying make this much more natural.

Re: Pipe Operator (|>) For JavaScript

#64

Post by stoned »

BigJono wrote: post #52
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…

TC39 proposals often have rubbish real world examples that should never see the light of day in a JS codebase. It makes me really question the judgement of the people that are working on this language, and it explains how some of the shittier proposals manage to slip in and why the good ones are misused all over the place in every real world codebase when this is the kind of guidance devs have on where to use fancy n…

I am still hoping that decorators might not pan out :fingers-crossed:

Re: Pipe Operator (|>) For JavaScript

#65

Post by swyx »

nassimsoftware wrote: post #5

To give credit where it's due. I came across the proposal through this video : https://www.youtube.com/watch?v=h1FvtIJ6ecE by Theo the CEO of Ping.gg.

and kudos also belong to the people whove been heavily championing and bikeshedding the proposal on behalf of the rest of us for the last 8 years - which i just discovered is really nicely documented in the repo: https://github.com/tc39/proposal-pipeline-operator/blob/main...

there's usually a ton of nuance behind the syntax considerations and i usually find that the people on tc39 care way more than i do about the things i never think about until its too late. peeking into their discussions is often very enlightening... and a reminder of how hard it is to do language design by committee and at scale.

Re: Pipe Operator (|>) For JavaScript

#66

Post by krapp »

nosianu wrote: post #41
CyberDildonics wrote: post #16

Earlier quoted context omitted.

If you're compiling from another language you would be using whatever syntactic sugar you want, why break compatibility just to have the compiled javascript look a little better?

> If you're compiling from another language TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That TypeScript, the tool, also adds a transpiler is a distraction that made a lot of people believe TS is a different language. Bu…

>TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript".

That's another language. Javascript doesn't have type annotations - even the suggested addition of type annotation syntax to JS[0] doesn't actually do anything because it can't and still be Javascript. Javascript doesn't have enums. Javascript doesn't have interfaces. That 1% (although it's probably more than that) matters. If it can't run, unaltered, in a Javascript interpreter it isn't Javascript.

[0]https://github.com/tc39/proposal-type-annotations

Re: Pipe Operator (|>) For JavaScript

#68

Post by evnp »

const isRandNumOdd = Math.round(Math.random() * 100) |> % % 2 |> Boolean;

Excruciatingly contrived, but does this sort of arithmetic work in the Hack syntax? I'm genuinely curious, couldn't find any mention of modulo (or remainder) in the proposal.

Re: Pipe Operator (|>) For JavaScript

#69

Post by renke1 »

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: User = { … }   
   
   console.log(User.getDisplayName(renke));
Which makes finding an operation for a certain type easier to find (just write User and trigger autocomplete).

The alternative is of course having renameUser (or userRename) and getUserDisplayName (or userGetDisplayname). The prefixed version would make autocomplete easier also.

Re: Pipe Operator (|>) For JavaScript

#70

Post by usrusr »

binarymax wrote: post #12
CyberDildonics wrote: post #4

I don't see how syntactic sugar makes any sense for javascript. Breaking compatibility is so severe because every browser needs to catch up, yet it doesn't actually enable anything that couldn't be done before.

Indeed. The argument of “nested calls are hard to read” is strange, because this looks terrible

Anything looks better than nested calls once you have started to get used to the benefits of reading left-to-right. It's one of those pains you don't realize you have unless it suddenly goes away.
Post reply on HN