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

321–330 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#321

Post by jameshart »

tracker1 wrote: post #301
jameshart wrote: post #276

Earlier quoted context omitted.

The thing I dislike about it most is the constantly-rebound % variable. It means something different in each line. In this case they have elected to keep it as a string throughout the pipe, but this ‘more pipey’ version of the code has it start out as an array then turn into a string halfway through the pipe, which feels dangerous (and is presumably why they didn’t take the example this far): Object.keys(envars) |> %…

Not really... F#-style pipeline syntax would be a bit more explicit about it, assuming you could use % for a variable name... Object.keys(envars) |> % => %.map(envar => `${envar}=${envars[envar]}`) |> % => %.join(' ') |> % => `$ ${%}` |> % => chalk.dim(%, 'node', args.join(' ')) |> % => console.log(%); To be honest, I've pretty much given up the hopes that TC39 would actually resolve pipelines and decorators at this…

But then why would you call all those different variables ‘%’?

Reading this version though I also notice something else that the F# style enables that the Hack style doesn’t which is that it supports destructuring. So in F# style, I can more easily make pipe steps that pass on multiple values in a structured object or array, then access them easily down-pipe.

Re: Pipe Operator (|>) For JavaScript

#322

Post by tracker1 »

pavlov wrote: post #145
Someone1234 wrote: post #96

Can someone remind me again why there's never been movement to add a second modern language to web-browsers? JavaScript was created in a weekend and then stuff tacked on for the last 28 years. We know so much more about how to create programming languages today than we did then, and the whole "Year of the Linux Desktop" has become a WebAssembly meme now every year since its introduction six years ago, with it getting…

Internet Explorer supported multiple script languages. The DOM in IE was essentially a COM API and callable from any supported scripting language. This included JScript (their JavaScript clone) but also VBScript and PerlScript.

I don't recall seeing anyone actually using PerlScript, or other scripting languages beyond VBScript in the browser for apps. I did work in a few locations where there was heavy push for VBScript for browser. I used JScript in classic ASP in much the same way.

Re: Pipe Operator (|>) For JavaScript

#323

Post by tracker1 »

vips7L wrote: post #184
Someone1234 wrote: post #96

Can someone remind me again why there's never been movement to add a second modern language to web-browsers? JavaScript was created in a weekend and then stuff tacked on for the last 28 years. We know so much more about how to create programming languages today than we did then, and the whole "Year of the Linux Desktop" has become a WebAssembly meme now every year since its introduction six years ago, with it getting…

Dart could have been our savior.

You can still use Flutter/Dart if you want.

Re: Pipe Operator (|>) For JavaScript

#324

Post by epolanski »

snow_mac wrote: post #271

I * HATE* pipes. For example from Elixir School ( https://elixirschool.com/en/lessons/basics/pipe_operator ): ``` foo(bar(baz(new_function(other_function())))) ``` They offer this example of an improvement: ``` other_function() |> new_function() |> baz() |> bar() |> foo() ``` While yes, pipes improve readability, how do they deal with errors? How do they deal with understanding what each thing is supposed to return?…

That's a limit of exception handling in Elixir.

A good language treats errors as a first class type. Functions that can error have no business returning an A.

Example given, the fetch API, is basically typed as fetch(): Promise

In reality, there might not be A at all, it should return a data type such as Either (or Result) which encodes linearly and forces the consumer to consider and handle the error.

Re: Pipe Operator (|>) For JavaScript

#325

Post by tracker1 »

jameshart wrote: post #321
tracker1 wrote: post #301

Earlier quoted context omitted.

Not really... F#-style pipeline syntax would be a bit more explicit about it, assuming you could use % for a variable name... Object.keys(envars) |> % => %.map(envar => `${envar}=${envars[envar]}`) |> % => %.join(' ') |> % => `$ ${%}` |> % => chalk.dim(%, 'node', args.join(' ')) |> % => console.log(%); To be honest, I've pretty much given up the hopes that TC39 would actually resolve pipelines and decorators at this…

But then why would you call all those different variables ‘%’? Reading this version though I also notice something else that the F# style enables that the Hack style doesn’t which is that it supports destructuring. So in F# style, I can more easily make pipe steps that pass on multiple values in a structured object or array, then access them easily down-pipe.

Unfortunately F# pipelines have been rejected a few times by TC39 to advance... I used it for a while via Babel/6to5, but I gave up (like with decorators) after many years of no advancement. I doubt I'll see either any time soon.

Re: Pipe Operator (|>) For JavaScript

#326

Post by tchocky »

scotty79 wrote: post #284
hajile wrote: post #238

Earlier quoted context omitted.

Objects carry prototypes and mutability with them. Further, all primitives/value types of the language are immutable. Adding those features to an Object would still necessitate creating a new primitive. At that point, you might as well make that primitive record that is directly available and just use the constructor to convert (just like you'd use `Number("123")`, you'd use `Record({my: "object"})`).

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

Re: Pipe Operator (|>) For JavaScript

#327

Post by mg »

tracker1 wrote: post #309
mg wrote: post #290

I wonder if "%" placeholder is the right approach. It makes the code longer in most cases. Without pipes: a = d(c(b)) With pipes in the proposed form: a = b|>c(%)|>d(%) My first approach to design it would be: a = b~>c~>d So the rule is that on the right side of the pipe operator (~>) there is always a function. We don't need parenthesis to indicate that. If the function takes more than one argument, it can be define…

Your ~> operator is effectively the F# style pipelines (using |>) that have already been rejected twice... Personally, I was fine with F# style myself... Hack style in TFA is also fine, not sure on `%` specifically though. In either case, I've lost hope of seeing either pipelines or decorators actually make it through committee in my lifetime at this point... it's been about a decade now.

I haven't looked into F# pipelines for a while, because they seemed so bloated to me that it hurts. Isn't it that this:

    a = b|>c(%,7)|>d(%)
Becomes something like this in F# pipes?

    a = b|>(b)=>c(b,7)|>d
If not, what does it become?

My suggestion is much shorter:

    a = b,7~>c~>d

Re: Pipe Operator (|>) For JavaScript

#328

Post by 6510 » 

   three(two(one(value)))
.

   value |> one() |> two() |> three()
.

   a=one(value);
   a=two(a);
   three(a);
.

   pipe(value, one, two, three)
all seem fine but nr 2, where does the return value from three() end up?

Re: Pipe Operator (|>) For JavaScript

#329

Post by notpushkin »

scotty79 wrote: post #251
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'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

Re: Pipe Operator (|>) For JavaScript

#330

Post by scotty79 »

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.

Yes. This fixes only immutability. For the value semantics (=== comaprison of content) pls check sibling comment thread.
Post reply on HN