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

291–300 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#291

Post by zelphirkalt »

For languages, which do not have built-in the power to change themselves, in many cases it might be better to stick to their feature set, instead of introducing even more language concepts. Look at how much work is involved to get something as simple as pipelines. As if they will ever find the right syntax for everyone.

If we used a normal function we might have to include a library or a dependency or heck, just take 5 minutes and write a pipeline function oneself. Sure, it will not be syntactically as minimal as a _change of the language itself_ to allow pipelining, but at least it will not introduce even more language features and everyone can easily look at the definition change it or include it in their own projects.

Ideally we would strive for a minimalistic set of features, which in turn can implement anything we want. Adding more and more features, without introducing a way for the user to modify the language without a commitee and a lengthy process, seems short-sighted.

If you want to give the user more power over syntax, introduce a well engineered macro mechanism (plenty of examples in other languages) and let people develop standards and libraries as macros and libraries. Later on decide what to take into the standard language. Similar to how jQuery influenced modern JS standard functions like querySelectorAll. Even if you don't take something into the standard language, users are still free to include it in their project. No harm done and everyone gets their lunch and can scratch their itches.

Re: Pipe Operator (|>) For JavaScript

#292

Post by scotty79 »

no_wizard wrote: post #234
scotty79 wrote: post #227

Earlier quoted context omitted.

Is the point of those just immutability or something else too? Wouldn't it be better to have a way to easily make any type deeply immutable? EDIT: I think tuples and records are also supposed to have value semantics, which is great, but why not a mechanism that turns on value semantics for arbitrary object type instead. Also value semantics is separate concept from immutability. Maybe there should have separate ways…

as outlined in the proposal, these new types have engine level guarantees, and support using a plain triple equals (`===`) statement to test structural equality. It also follows that strucural equality trickles down into objects that do this implicitly (Map, Set etc) as well. Doing this for plain arrays and objects has been said by the vendors for years to be too hard and possibly break alot of existing applications,…

You could create class that keeps static Map with references to all created objects of given type. On creation it would check if structurally same object was already created and return reference to previous instance instead of creating a new one.

If you freeze those objects and their prototypes you get exactly your records. === becomes structural comparison that costs exactly the same as reference comparison.

I made something like that for my own purposes for very simple types like Point.

To implement this you'd just need to be able to turn contents of an object into a key for a map. I agree that it's probably better to do this rather in the VM than in the library.

Re: Pipe Operator (|>) For JavaScript

#293

Post by de_keyboard »

captainmuon wrote: post #141
hajile wrote: post #128

Earlier quoted context omitted.

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

The F# syntax is an incredibly simple bit of syntactic sugar.

Just replace this:

    x |> f
With this:

    f(x)
For the join example, you must do this:

    xs
    |> (x => x.join(' '))
It de-sugars to:

    (x => x.join(' '))(xs)
... which of course is simply:

    xs.join(' ')

Re: Pipe Operator (|>) For JavaScript

#294

Post by tracker1 »

stoned wrote: post #64
BigJono wrote: post #52

Earlier quoted context omitted.

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:

I like decorators as a concept... but there have been a couple different implementations now... the TypeScript version is probably the most broadly used, but there were others before it via Babel (formerly 6to5).

I was an early adopter of the original decorators proposal as well as the F#-style pipeline operators. The more time has moved on and other bits made it into JS proper, I'm far more inclined to stick to what's "in the box"... Have even considered just writing straight JS + ESM (modules). Of course, I also like JSX, though not sure of any proposals of how to get that "in the box" as e4x died on the vine and a lot of other efforts didn't gain much traction either.

Re: Pipe Operator (|>) For JavaScript

#295

Post by mattgreenrocks »

dgb23 wrote: post #167

Saw a talk with Douglas Crockford[0] years ago. He said something like: Before JS classes got introduced he asked why they didn't just implement macros for the language. Classes are in fact just syntactic sugar. Just like async/await, and now this proposal. In hindsight he was right. JS would be better off if it did have macros. Much of the whole babel/webpack/react/ts stuff would be just a bunch of macros instead of…

It's pretty sad that you have to advocate for macros on a site called Hacker News nowadays. They aren't even terribly different from frameworks (which everyone loves): incorrect usage generates a stack trace you need to decipher.

Re: Pipe Operator (|>) For JavaScript

#296

Post by ravenstine »

As someone who actually loves JavaScript, I think this is a really bad idea.

Maybe it has a place in other languages. I really don't want to see it in JS. We don't need more ways to do things implicitly or bass-ackwards from how they're actually behaving underneath. Syntactic sugar rarely makes code more readable. This operator only makes code seem more concise and as if it's executing in a way that it actually isn't.

I can absolutely see junior developers running wild with this kind of thing.

JS should be kept simple. This operator is not simple. It now makes understanding expressions more complicated. JS has its quirks and rough edges, but its power is in its simplicity. Please do not import the mistakes of other languages into JavaScript. If someone wants this operator, they should be forced to use a Babel transform or to compile their own JS interpreter.

OR just compile your favorite language runtime with the pipe operator to WASM.

Re: Pipe Operator (|>) For JavaScript

#297

Post by de_keyboard »

At work I am always hopping between F# and JavaScript and I'm convinced that if more people had this experience they would want the pipe operator in JavaScript.

Unfortunately it's hard to convey the advantages to those who haven't used it. Maybe it's because it's such a simple bit of syntatic-sugar?

Re: Pipe Operator (|>) For JavaScript

#298

Post by tracker1 »

hajile wrote: post #154
galaxyLogic wrote: post #95

Earlier quoted context omitted.

I think we should have BOTH. Use |> for the Hack proposal and -> for F# -style.

I'd far rather save that for an alternative switch expression with pattern matching. const slowSum = (lst: {x: number}[]) => switch(list) { [{x}, ...y] -> x + slowSum(y) //not tail recursive [{x}, {x: y}] -> x + y //alias second x to y [{x}] -> x //handle length 1 [] -> 0 //handle length 0 }

Having been watching, and a couple times playing with Rust... would definitely like a similar pattern matching system in JS. I still feel the C# syntax for this feels a bit alien `varname switch {...}`.

Re: Pipe Operator (|>) For JavaScript

#299

Post by ravenstine »

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 flaw with that approach to language development is that there's no limiting factor.

Can you imagine a survey where everyone says they're satisfied with the language as-is? Of course not. That's statistically impossible. Even if 99% of the needs of developers are satisfied by a language, people are going to eventually answer that they'd like something that the language doesn't have, and that's always the case.

Let's say JavaScript implemented nearly every single language feature that's ever been invented. That is except the goto statement. Upon being surveyed on what they think is currently missing from JavaScript, a significant number of developers will have to respond with goto. Does that mean JavaScript is actually "missing" goto and that it was a mistake that it was never implemented in the first place? Of course not.

Re: Pipe Operator (|>) For JavaScript

#300

Post by UlisesAC4 »

vikingerik wrote: post #122
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.

This. Temporary variables are the way to go for deconstructing a complex expression like this. Everything is more readable when you put the results of an expression with two to four terms in a well-named variable. Trying to put everything into one giant closed-form expression feels clever and smart, but it's really just getting in the way of the next poor sucker who needs to understand what you were doing. This works…

Pipe is a tool for dealing with batching too.
Post reply on HN