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

331–340 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#331

Post by sfink »

scotty79 wrote: post #292
no_wizard wrote: post #234

Earlier quoted context omitted.

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…

I believe this approach was proposed, but implementers pushed back because the initial interning is expensive and there are a lot of scenarios where it would never be used. You don't really expect creating a Point to do a hash lookup.

Re: Pipe Operator (|>) For JavaScript

#332

Post by sfink »

scotty79 wrote: post #227
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…

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…

Sadly, JS weirdness interferes with value semantics:

    > 0 === -0
    true
    > #{v: 0} === #{v: -0}
    ???

Re: Pipe Operator (|>) For JavaScript

#333

Post by disantlor »

scotty79 wrote: post #137
jsf01 wrote: post #84

This strikes me as something better left to libraries. If you want to write in a functional style then Ramda, Lodash, Underscore, and plenty of others have pipe and compose functions. pipe(one, two, three) Easy to read. No new syntax. Extendable with arrow functions. Yes, there are some limitations in comparison to Hack Pipes. But those are far outweighed by not messing yet again with the language’s syntax.

For me limitations are killing 90% of usecases. In absence of |> % syntax I'd nearly always would go with intermediate temporary variables instead of pipe(). "point-free" syntax feels horrible for me and wrapping everything in lambdas feels excessive.

I use Ramda pipe() all the time and use a descriptively-named intermediate/temp variables wherever I might want to write a comment

Re: Pipe Operator (|>) For JavaScript

#334

Post by nitwit005 »

brundolf wrote: post #147
captainmuon wrote: post #133

I don't understand why you can't just use temporary variables. The article mentions mutation is bad, but what actually happens is that the name gets reassigned. No value is mutated. That brings me to something I really want in JS, actual unmutable values. If you use `const x = new SomeClass()`, you cannot reassign it, but you can change fields. The first time I encountered `const`, I thought it did the opposite. It w…

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…

> There's no way to break out inline intermediate constants here; you have to bail out and do it up above the `return`.

Which seems fine. There's not an obvious gain to having one giant super-complex return statement.

Re: Pipe Operator (|>) For JavaScript

#335

Post by 8note »

greggman3 wrote: post #228
rektide wrote: post #144

Earlier quoted context omitted.

why? are you of a 'pointfree' opinion? what are your concerns? https://wiki.haskell.org/Pointfree personally i detest pointfree syntax. having intermediate values makes it much easier to step through code with a debugger & see what is happening. and it gives the reader some name for what the thing is, which is incredibly useful context. the enablement of pointsfree styles is one of my main concerns about potential pi…

I agree that (1) named intermediate values are sometimes more readable ... though I have examples where it's very hard to come up with names and not sure it helped (2) debugging is easier. For (2) though, this IMO is a problem with the debugger. The debugger should allow stepping by statement/expression instead of only by line (or whatever it's currently doing). If the debugger stopped at each pipe and showed in valu…

It's hard to understand which statement the debugger has a break point set to when you can put many breakpoints on the same line

I have tools that can do it, but I'll still have a better time splitting out a variable for it, especially since what I really want is a log of all the intermediate values, so I can replicate what it's doing on paper

Re: Pipe Operator (|>) For JavaScript

#337

Post by steve_adams_86 »

tchocky wrote: post #326
scotty79 wrote: post #284

Earlier quoted context omitted.

> Objects carry prototypes and mutability with them. You can deep freeze the objects and freeze their prototypes.

It's not the same as tuples and records. You can do the following with them: const first = #{a: 'b', c: 'd'}; const second = #{a: 'b', c: 'd'}; first === second // true So no more deep comparing of objects if they have the same properties.

Fascinating. I would have guessed that identity checks are still possible with ===, and == would use a structural comparison.

I suppose V8 for example could easily optimize records and tuples which are structurally equal into the same memory, then separate them into distinct memory blocks when they differ. This way an equality check could have the speed of an identity check if the two are known to be structurally equal.

I could be talking out of my ass here – maybe this isn't a performance concern at all and has been addressed far better already, and this is nonsense. But I do wonder how you'd quickly check for equality of, say, a large state tree to discover changes. On one hand that could be addressed by architecture. On the other, it is nice sometimes to simply know if two variables reference the same memory.

Re: Pipe Operator (|>) For JavaScript

#338

Post by scotty79 »

notpushkin wrote: post #329
scotty79 wrote: post #251

Earlier quoted context omitted.

I'll bite: let _= Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ') _= `$ ${_}` _= chalk.dim(_, 'node', args.join(' ')) _= console.log(_); This is possible in current JS syntax. You can also cram it into one line with semicolon: let _= Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ') ;_= `$ ${_}` ;_= chalk.dim(_, 'node', args.join(' ')) ;_= console.log(_); So it's basicall…

;D

;D is perfectly legal syntax too.

Btw I think I'll name this operator duck ,D=

Maybe the pipe syntax extension will be introduced if we threaten to make duck operator a thing?

Re: Pipe Operator (|>) For JavaScript

#339

Post by rwalle »

sdflhasjd wrote: post #172
vikingerik wrote: post #122

Earlier quoted context omitted.

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…

Temporary variable make debugging easier too.

Agreed. It feels great to chain stuff or nest function calls, but then I hate myself when it comes to debugging.

Re: Pipe Operator (|>) For JavaScript

#340

Post by 8note »

tgv wrote: post #99
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…

So their argument in favor of this fugly new operator is that some people write unreadable code? That's not the language's fault. As they say, you can write FORTRAN in any language. This just gives them a new tool to make things even worse. chalk.dim(Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}`, 'node', args.join(' ')) |> console.log(%); And it doesn't even work on objects. La…

I'm trying to compare this to the jQuery kinda syntax

X

.this()

.that()

.then()

.do()

.a()

.thing()

And I expect this to let me keep that chain going for when I need to run a static function against the chain

X

.this()

.that()

.then()

.do()

.a()

.thing()

|>JSON.stringify(%)

Post reply on HN