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

201–210 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#201

Post by ed_balls »

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.

Quite often I rewrite the code from

```

return validate(get_response(value))

```

or

```

value = get_response(value)

value = validate(value)

return value

```

into

```

res = get_response(value)

new_res = validate(res)

return new_res

```

Why? Easier to read and when Sentry throws an error I have each value from the call stack. Much easer to debug. In the example 2 you can accidentally move a line and not notice the error.

Re: Pipe Operator (|>) For JavaScript

#202

Post by yakshaving_jgt »

Rumudiez wrote: post #87
CyberDildonics wrote: post #61

Earlier quoted context omitted.

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.

No, you don’t get it. Babel is for transpiling newer versions of JS to older ones, typically based on targeted browsers or Node runtimes. JS is a fantastic fp language and pipe/compose is commonplace for people writing in that style already. This just adds first class support to the language

> No, you don’t get it. Babel is for transpiling newer versions of JS to older ones

For all intents and purposes, JavaScript with all the extra features it has accreted over the years is a different language from the JavaScript of a decade ago, and a compilation step is necessary in order for web browsers to parse it.

If you're running a compilation step anyway, you may as well write the code in a language that isn't such a dumpster fire.

> JS is a fantastic fp language

Actually, it's pretty terrible at that.

Re: Pipe Operator (|>) For JavaScript

#203

Post by masswerk »

I don't think that it's a good idea to introduce a left-to-right flow into a language, which strictly assigns righthand values by general design. The text mentions a back-and-forth in reading, this introduces a back-and-forth intellectually.

(There's already a limited left to right capability, namely by chaining expressions using logical operators, especially when used outside of condition. It should be mentioned, however, that this is already confusing to some.)

Re: Pipe Operator (|>) For JavaScript

#204

Post by hajile »

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); })()} )

They should repurpose `do` so that `do {}` (without the `while`) is an expression that you can put statements inside and return the last statement.

It would be great if we had expression if..else too (instead of just the tertiary operator)

Re: Pipe Operator (|>) For JavaScript

#205

Post by no_wizard »

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 adoption is gained though.

I don't think the Pipe Operator would be as useful in comparison.

I really hate how long the Records & Tuple proposal has been languishing at stage 2. It could've shipped years ago if not for a syntax debate that dragged on and on without being fruitful[1]

EDIT: there is a class based version of this, that is stage one, for adding structs[2]. They behave similarly.

[0]: https://github.com/tc39/proposal-record-tuple

[1]: https://github.com/tc39/proposal-record-tuple/issues/10

[2]: https://github.com/tc39/proposal-structs

Re: Pipe Operator (|>) For JavaScript

#206

Post by masswerk »

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…

  > I also feel this:
  >> In the State of JS 2020 survey, the fourth top answer to “What do you feel is currently missing from JavaScript?” was a pipe operator.
  > Is the wrong way to go about language design.
Let's call it Signor Rossi language design…

"Signor Rossi cosa vuoi? … E poi, e poi, e poi" (Viva la felicità by Franco Godi [1])

[1] https://www.youtube.com/watch?v=UrKKMtjNWCI

Re: Pipe Operator (|>) For JavaScript

#208

Post by pwdisswordfisha »

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…

> some of the shittier proposals manage to slip in

Examples?

Re: Pipe Operator (|>) For JavaScript

#209

Post by OkayPhysicist »

travisgriggs wrote: post #91
NhanH wrote: post #72

Earlier quoted context omitted.

Method chaining is better, but you need the library/class/ code to support it. If you got a bunch of function it can’t help you. Pipe operator is useful for when you use other people’s code. On the other hand, pipe is less useful when you don’t have partial application of function built-in. So yeah I think this is not worth it.

This works when your language doesn’t have an implicit “return nothing” as it’s default. Nothing says “imperative” like “this routine may or may not take input, but you ain’t getting nothing back out of it.” Ironically, OO gets thrown under the bus a lot lately because it ain’t functional. But in reality, early OO languages like Smalltalk and CLOS were much more functional in this regard, you always had an implicit r…

Elixir's pipe mechanics probably aren't a great model for implementing pipe operators in existing languages. A large part of what makes |> work in Elixir is the steadfast commitment to f(most_likely_to_be_piped_param,other,params) argument ordering in the standard library.

Re: Pipe Operator (|>) For JavaScript

#210

Post by tgv »

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.

Except that the order of evaluation is different now. Side effects? Who cares.
Post reply on HN