Pipe Operator (|>) For JavaScript • Hacker News Board

Re: Pipe Operator (|>) For JavaScript

#381

Post by mkl » Fri, Jan 20, 2023, 11:23 PM UTC

pharmakom wrote: post #377

mkl wrote: post #370

Earlier quoted context omitted.

And a lot more like JS than the F# proposal.

How so? JS already has operators, but placeholders is a totally new concept

Is there another JavaScript feature that looks like a list of function names but which causes actions to be performed? Or operators that operate on both functions and values? The placeholders are very similar to variables, so do what they look like they do, and it's only the implicit definition that is new. The explicit placeholders feel much more like JavaScript to me than the implicit function calling of the F# proposal.

Re: Pipe Operator (|>) For JavaScript

#382

Post by BeFlatXIII » Fri, Jan 20, 2023, 11:34 PM UTC

yuliyp wrote: post #307

matlin wrote: post #34

Can't wait for this. Pipes are awesome in Elixir and bringing them to JS/TS will be great. To me this is both concise and readable: const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> await fetch(%) |> await %.json() |> %.properties.periods[0]

That is concise, readable, and does not have any room at all for error handling. If this was Rust, it could at least be turned into something which returned the right Err for what was happening. Without something like that, trying to add error handling to the things which may blow up would instantly turn it into gibberish. Every single function here can fail (the HTTP request could fail, the data returned could be un…

That ignores the “let it crash” motto of the BEAM. Don’t bloat the code with error handling when the supervisory tree can retry crashed processes.

Re: Pipe Operator (|>) For JavaScript

#383

Post by dmix » Fri, Jan 20, 2023, 11:34 PM UTC

epolanski wrote: post #324

snow_mac wrote: post #271

I * HATE* pipes. For example from Elixir School ( https://elixirschool.com/en/lessons/basics/pipe_operator ): ``` foo(bar(baz(new_function(other_function())))) ``` They offer this example of an improvement: ``` other_function() |> new_function() |> baz() |> bar() |> foo() ``` While yes, pipes improve readability, how do they deal with errors? How do they deal with understanding what each thing is supposed to return?…

That's a limit of exception handling in Elixir. A good language treats errors as a first class type. Functions that can error have no business returning an A. Example given, the fetch API, is basically typed as fetch (): Promise In reality, there might not be A at all, it should return a data type such as Either (or Result) which encodes linearly and forces the consumer to consider and handle the error.

There's nothing stopping JS devs from combining pipes with heavy use of a Maybe library. You don't need to use pipes everywhere, but it would be useful for a system that was designed with that pattern in mind.

I already use Maybe patterns quiet a bit in my TS project but there always the libraries and frameworks you work with that don't. So yeah I can see it being a language level thing (the way Promises were used) pushing for wide adoption.

Re: Pipe Operator (|>) For JavaScript

#384

Post by wruza » Fri, Jan 20, 2023, 11:35 PM UTC

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…

React component should be chock full of do expressions

If the motivation behind these features are React components, javascript clearly lacks proper logic in array (and object) literals, like

  '[' if (cond) […]expr1 [else […]expr2] ']'

Although it seems pretty strange to add syntax only because some specific user interface library together with a specific language extension could benefit from it.

Re: Pipe Operator (|>) For JavaScript

#385

Post by WorldMaker » Fri, Jan 20, 2023, 11:37 PM UTC

epolanski wrote: post #311

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.

It absolutely is, but time and time again TC39 has followed few champions over the waves of people favoring F# pipes. It's incredible to me TC39 would rather have this monstruosity over F# pipes which are actually pretty similar to how most pipes work and read in most functional languages including unix `|` one.

On the flipside, I think that this is still such an ongoing debate is part of why the pipeline operator is still stuck in Stage 2 and having trouble getting into Stage 3, despite being listed as a "priority" multiple times on and before 2020. TC-39 isn't blindly following anyone here, they seem to be dragging their heels hoping that someone comes along with an even better compromise between the styles.

Re: Pipe Operator (|>) For JavaScript

#386

Post by galaxyLogic » Fri, Jan 20, 2023, 11:38 PM UTC

hajile wrote: post #275

galaxyLogic wrote: post #59

Earlier quoted context omitted.

Wouldn't it be better to use '->' as the operator? This is about dataflow so an arrow would represent that nicely. Whereas '|>' doesn't really "mean" anything. An arrow means that something flows in the direction of the arrow.

Sure, but I'd rather reserve that for a pattern-matching switch statement.

Why not use |> for that?

Re: Pipe Operator (|>) For JavaScript

#387

Post by crabmusket » Fri, Jan 20, 2023, 11:40 PM UTC

epolanski wrote: post #324

snow_mac wrote: post #271

I * HATE* pipes. For example from Elixir School ( https://elixirschool.com/en/lessons/basics/pipe_operator ): ``` foo(bar(baz(new_function(other_function())))) ``` They offer this example of an improvement: ``` other_function() |> new_function() |> baz() |> bar() |> foo() ``` While yes, pipes improve readability, how do they deal with errors? How do they deal with understanding what each thing is supposed to return?…

That's a limit of exception handling in Elixir. A good language treats errors as a first class type. Functions that can error have no business returning an A. Example given, the fetch API, is basically typed as fetch (): Promise In reality, there might not be A at all, it should return a data type such as Either (or Result) which encodes linearly and forces the consumer to consider and handle the error.

In this case, Promise already includes the possibility of rejection, though the types that may be rejected are not specified.

Re: Pipe Operator (|>) For JavaScript

#388

Post by MathMonkeyMan » Fri, Jan 20, 2023, 11:42 PM UTC

Can't javascript already do [this][1]?

    const thrush = (value, func, ...funcs) =>
        func ? thrush(func(value), ...funcs) : value;

    // no new syntax required
    thrush(
      envars,
      Object.entries,
      x => x.map(([key, val]) => `${key}=${val}`),
      x => x.join(' '),
      x => chalk.dim('$ ' + x, 'node', args.join(' ')),
      console.log);

[1]: http://www.davidgoffredo.com/thrush.html

Re: Pipe Operator (|>) For JavaScript

#389

Post by antipurist » Fri, Jan 20, 2023, 11:47 PM UTC

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.”

"Why did it take so long?" and "Pointless bloat!" reactions were much more common:

https://news.ycombinator.com/item?id=3780367

https://news.ycombinator.com/item?id=6418337

Re: Pipe Operator (|>) For JavaScript

#390

Post by WorldMaker » Fri, Jan 20, 2023, 11:47 PM UTC

nicoburns wrote: post #240

no_wizard wrote: post #205

I hope Records & Tuples[0] land before this does. It would have meaningful and far reaching positive effects for the language, without much controversy. Like most of these things, it takes about 5-7 years for it to permeate through enough of the engines to be meaningfully useful in the day to day of web developers (node / deno typically 12-18 months tops). It would drastically speed up existing code once wide adoptio…

The one I really want is “do expressions”. I also can’t understand why anyone wants private fields over these kind of improvements. Lack of private fields in JS has literally never caused a big for me in 15 years of JavaScript development, but I have to use mutable variables and ugly if-else chains to 3 case assignment all the time!

"do expressions" is one of the things mentioned in the Pipe Operator proposal as possibly a pre-req and one of many reasons the Pipe Operator seems to have stalled out at Stage 2 despite multiple attempts to push it past.

Personally, for the 3-case assignment I would love to see one of the smarter pattern matching "match" expression proposals make it further along over the over-generalized "do expressions". Especially now that C# has pattern matching switch expressions.