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

391–400 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#391

Post by layer8 »

layer8 wrote: post #270
CodexArcana wrote: post #142

Earlier quoted context omitted.

but then is not a pipe!

It’s a horizontal pipe. It arguably actually makes more sense when the values flow horizontally from left to right through the pipe. In an alternative universe, Unix shell syntax may have used “—“ instead of “|” for piping.

PS: The commands in Unix pipes are executed in parallel, and “|” could be interpreted as a mnemonic of that fact. However, the same is not true for the programming-language feature discussed here, which only processes singular values, not streams.

Re: Pipe Operator (|>) For JavaScript

#392

Post by yamtaddle »

arp242 wrote: post #349
pcthrowaway wrote: post #345

Earlier quoted context omitted.

> I do have to admit I never worked with a language that uses |> Have you never worked with Bash? It's basically the same thing

Indeed it is, but it's kind of a different context than a "real" programming language. What works for one doesn't necessarily work well for the other.

Truly, one of the main reasons I might stop increasing the complexity of a bash one-liner and move it to a full shell script, or bail for Python, is specifically so I can turn those chains of pipes into imperative steps with temp vars so that they're actually legible and easy to reason about. I can't imagine why I'd want to go the other direction.

Re: Pipe Operator (|>) For JavaScript

#393

Post by wruza »

scintill76 wrote: post #318
notdonspaulding wrote: post #132

Earlier quoted context omitted.

Exactly. As the proposal contemplates this alternative, it claims: > But there are reasons why we encounter deeply nested expressions in each other’s code all the time in the real world, rather than lines of temporary variables. And the reason it gives is: > It is often simply too tedious and wordy to write code with a long sequence of temporary, single-use variables. Sorry, but...that's the job? If naming things is…

> The aphorism "There are two hard problems in computer science: cache invalidation, and naming things." is not an argument to never cache and never name things. Sure, it can’t be completely eliminated, but why not do less of a thing that’s hard, when it can be avoided? Values have a “name”, whether it’s a variable ‘keysAsString’ or the expression ‘keys.join(' ')’. The problem with keysAsString is that you have to ty…

If names are the source of crisis, wouldn’t it be better to define temporary variables without names?

  var [$1, $2] = foo(bar(envars))
  console.log(chalk.bold($2), $1)
Job done, no plumbing needed. Has the same level of semantics as %.

Re: Pipe Operator (|>) For JavaScript

#394

Post by wruza »

greggman3 wrote: post #239
notdonspaulding wrote: post #132

Earlier quoted context omitted.

Exactly. As the proposal contemplates this alternative, it claims: > But there are reasons why we encounter deeply nested expressions in each other’s code all the time in the real world, rather than lines of temporary variables. And the reason it gives is: > It is often simply too tedious and wordy to write code with a long sequence of temporary, single-use variables. Sorry, but...that's the job? If naming things is…

and yet looking through code from the place you work I see something like this let field = ve.instanceContext.replace(/(#\/)|(#)/ig, "").replace(/\//g, ".") Which you apparently claim should be const fieldWithHashMarksUnesacped = ve.instanceContext.replace(/(#\/)|(#)/ig, ""); const field = fieldWithHashMarksUnesacped.replace(/\//g, ".") https://github.com/mirusresearch/firehoser/blob/46e4b0cab9a2... and this return m…

fieldWithHashMarksUnesacped

The code removes all “#/“ (or just “#” if a slash isn’t there). After that it replaces slashes with dots. How on earth is that “hash marks unescaped”?

Re: Pipe Operator (|>) For JavaScript

#395

Post by 01acheru »

The syntax is simply disgusting, some examples look worse with pipes than without them.

I understand it is stage 2 now but can we do something about it? I'm seeing that most comments here and in other places are critical, why should we get this stuff in JS because of a vocal minority that is trying to push it on everyone else?

If we keep adding the fifth thing asked on state of JS year after year we will end with some frankenstein weirdness... JS was getting better and better, let's not make it worse.

Re: Pipe Operator (|>) For JavaScript

#396

Post by josevalim »

epolanski wrote: post #324
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.

Elixir handles errors as you describe, the example does not cover it. The pipeline also assumes a single direction, which pushes error handling to the next step, but there are also constructs (case and with) for handling and composing errors in one go.

Re: Pipe Operator (|>) For JavaScript

#397

Post by trekkie1024 »

I actually find the original easier to read than the piped example given for this one:

Original

  jQuery.merge( this, jQuery.parseHTML(
    match[ 1 ],
    context && context.nodeType ? context.ownerDocument || context : document,
    true
  ) );
-----------------------------------------

With pipes

  context

  |> (% && %.nodeType ? %.ownerDocument || % : document)
  |> jQuery.parseHTML(match[1], %, true)
  |> jQuery.merge(%);
I think F# pipes are ideal in more complex cases, the % can add unnecessary complexity when reading code. Alas, it looks like we're not going to get that.

Re: Pipe Operator (|>) For JavaScript

#398

Post by TheRealPomax »

tracker1 wrote: post #310
TheRealPomax wrote: post #253

Earlier quoted context omitted.

We said the same things when arrow functions got introduced using an outlandishly un-javascripty syntax, as well as when templating strings got introduced using symbols that were the domain of LaTeX. Now they're "just what JS looks like" to both old and new JS devs. Look past the syntax, because you'll master it quickly enough and 2 years down the line forget it was ever not part of the language: does the actual func…

Working with something that uses an ES3-like level of the JS language, it's actually painful not having some of the conveniences added in the past decade+.

I see someone's using Photoshop.

Re: Pipe Operator (|>) For JavaScript

#399

Post by runarberg »

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.

The problem with that is that it is impossible to infer the type of the n-ary pipe() function. Libraries “solve” this by overloading that function with n annotations, but that really isn’t a permanent solution, especially for libraries with millions of users, as there will always be a user that puts n + 1 parameters in that function.

Re: Pipe Operator (|>) For JavaScript

#400

Post by CyberDildonics »

Rumudiez wrote: post #87
CyberDildonics wrote: post #61

Earlier quoted context omitted.

You're completely missing the point here. If you are transpiling something, you don't need to worry about syntactic sugar in the base language you are transpiling to, only what you're transpiling from.

No, you don’t get it. Babel is for transpiling newer versions of JS to older ones, typically based on targeted browsers or Node runtimes. JS is a fantastic fp language and pipe/compose is commonplace for people writing in that style already. This just adds first class support to the language

> This just adds first class support to the language

If it was a different language you could say it "just" adds something, but javascript is not compiled and any syntax change means you start over as far as compatibility goes. It is unique in its scope and usage and this feature doesn't enable anything new for users and is only marginally useful for programmers.

Post reply on HN