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

41–50 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#41

Post by nosianu »

CyberDildonics wrote: post #16
hajile wrote: post #15

Earlier quoted context omitted.

Because x |> f |> g |> h is much easier to read than h(g(f(x))) for most people.

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. But the TS folks have always taken great pain to only ever support features that are or are about to be in the ECMAScript standard, and not to deviate from it. That they did initially with some namespace stuff and enums was before ES2015, when JS was lacking some things many people thought were essential. Even then they only added less than a handful of "TypeScript-code".

When you look at the Babel "transpiler" for Typescript, before they added a bit more for class stuff, it pretty much showed that "transpilation" of TS to JS - as long as you targeted a recent ES version - was achieved by doing nothing more than to remove all those type annotations.

I'm still mad at the TS guiys for muddying the waters so much by confusing soooo many people by bundling type checking and transpilation in one tool. This could have been much more clear. I too stuck to using Flow for quite some time until I realized TypeScript really is Javascript, while Flow communicated in its architecture and usage already that it just "added types" (literally).

Re: Pipe Operator (|>) For JavaScript

#42

Post by hajile »

kibwen wrote: post #36
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…

I originally thought you were referring to this as a "hack proposal" as a way of denigrating its value, but in fact it is the "Hack proposal" where "Hack" is Facebook's fork of PHP.

It is strange to see JS taking ideas from a derivative of PHP.

Re: Pipe Operator (|>) For JavaScript

#43

Post by substation13 »

charles_f wrote: post #31

> three(two(one(value))) const oned = one(value); const twoed = two(oned); const threed = three(twoed); This proposition goes out of its way to find problems with code that is written in a confusing and uncommon way in the first place.

It's annoying to have to decide on and write out so many names. The intermediary names are not relevant to solving the problem. This is so much less noisy:

    value 
    |> one
    |> two
    |> three

Re: Pipe Operator (|>) For JavaScript

#44

Post by netchkin »

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…

I really enjoy writing me some of that F#, esp. with Bolero, but I would take `value |> foo(%)` over actual F#'s `value |> (fun x -> foo x)` any day. However, I agree that the "F# proposal" comes across as better, esp. when we consider -copypasting- consistency of the language. Now, considering everything in JS already, you are right, we did it again, didn't we? After couple more years, the Perl and Javascript languages will finally merge and become one.

Re: Pipe Operator (|>) For JavaScript

#45

Post by [deleted] »

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…

[deleted]

Re: Pipe Operator (|>) For JavaScript

#46

Post by prmph »

chadlavi wrote: post #22

JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.

But clearly we need "that kind of programming language" for rich client web apps. We need many of the modern language constructs in such a language. Would you advocate for an entirely new language to meet that need?

Re: Pipe Operator (|>) For JavaScript

#47

Post by ubertaco »

xnorswap wrote: post #25
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…

Is either proposal compatible with later adding a backward pipe If so I think that should be a consideration, even if in practice there isn't massive value in a backward pipe operator in javascript. It would be a shame to later want to add it and have to add another layer of kludge and messy syntax.

Yeah, F# has a backward pipe operator, and it works like this:

    a_value |> (fun a b -> a + b)
In F#, this works because of automatic function currying. Not sure how that would apply to Javascript, though. Without function currying, what would this even mean?

   a_value |> ((a, b) => a + b)
...since there's no currying, you'd just immediately invoke the function that sits "in the middle" with `a` set to `a_value`, but `b` set to `undefined`.

The Hack-style proposal though...I don't think it would work with a backward-pipe operator at all. Not without adding a _second_ special-case symbol, at least.

Re: Pipe Operator (|>) For JavaScript

#48

Post by teg4n_ »

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

`titleCase(“hello world”)` , how you would already do this seems equally ok to me

Re: Pipe Operator (|>) For JavaScript

#49

Post by WastingMyTime89 »

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.

Re: Pipe Operator (|>) For JavaScript

#50

Post by augusto-moura »

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…

The proposal is not finished yet (and might never been). Pessimism aside, there is a whole issue on why it was decided on following up with Hack's implementation [1].

You can always give your input on such decisions, the % token is still being "bikeshedded"[2] (is that a word?), and there's still a possibility of making follow-ups proposals that could implement some F#-esque implementation

[1]: https://github.com/tc39/proposal-pipeline-operator/issues/22...

[2]: https://github.com/tc39/proposal-pipeline-operator/issues/91

Post reply on HN