JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.
Pipe Operator (|>) For JavaScript
51–60 of 437 posts
Re: Pipe Operator (|>) For JavaScript
#52Is 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…
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 new features.
In a few years everyone is going to collectively lose their fucking mind once again and decide that ternaries are now the devil and every React component should be chock full of do expressions. I can see that coming clear as day. That might finally be enough to get me to throw in the towel if the also incoming decorator hell doesn't do it.
Re: Pipe Operator (|>) For JavaScript
#53Re: Pipe Operator (|>) For JavaScript
#54They 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.
This proposal reminds me of Scala with anonymous parameters '_'. Could I use more than one '%' for curried functions. xs.reduce(_+_)? Though I guess for perf reasons it might make sense to keep things as tuples so it would be xs.reduce(%[0]+%[1]).
Re: Pipe Operator (|>) For JavaScript
#55JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.
Javascript is, without exaggeration (and with much chagrin), the language that has done more to popularize functional programming than any other programming language in history. It's only natural that they'd continue pushing on that front. :P
Re: Pipe Operator (|>) For JavaScript
#56The 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
#57Is 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 have a feeling this doc lists every sort of usecase, not because they are advertising it as "always the better version", but because it's a design doc that needs to factor in edge cases, such as using a pipe following chained function calls.
Re: Pipe Operator (|>) For JavaScript
#58Earlier quoted context omitted.
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
#59They 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…
Re: Pipe Operator (|>) For JavaScript
#60They 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…