Live data from Hacker News

Show HN: A JavaScript function that looks and behaves like a pipe operator

github.com

131–140 of 148 posts

Re: Show HN: A JavaScript function that looks and behaves like a pipe operator

#132

I think what makes a programming language easy to use is largely due to the constraints that it imposes, through carefully thought-out design decisions. At first the constraints may be difficult to grasp. You may feel like a feature is missing, but that's part of learning a language. Once you have learned them, the constraints actually become helpful. One thing I dislike about JS is that it's like the wild west. You…

[deleted]

Re: Show HN: A JavaScript function that looks and behaves like a pipe operator

#134
post #22

Earlier quoted context omitted.

The difference is that they want to turn a = d(c(b,7)) into a = b |> c(%,7) |> d(%) and I would like to see it turn into a = b,7 ~> c ~> d

It feels a bit unnatural to pipe multiple arguments like that in JS, and you could inline them in the first call without losing legibility: a = c(b, 7) |> d(%) It's the arguments added way down the line that are problematic: a = f((e(d(c(b))), 4), 5) a = ((b ~> c ~> d), 4 ~> e), 5 ~> f a = b |> c(%) |> d(%) |> e(%, 4) |> f(%, 5) Smart pipes [1] were a bit nicer about that: a = b |> c |> d |> e(#, 4) |> f(#, 5) Basica…

> P. S. When studying Haskell on a CS course in school, I used to define exactly the same squiggly arrow operator for my programs :-)

Haskell base already has the reverse application operator (&) which does the same thing. Not included in the prelude but can be imported from Data.Function. [1] It's defined as:

  (&) :: a -> (a -> b) -> b
  x & f = f x
Not that there's anything wrong with using your own definitions, just thought I'd point it out!

[1] https://hackage.haskell.org/package/base-4.18.1.0/docs/Data-...

Re: Show HN: A JavaScript function that looks and behaves like a pipe operator

#135
post #22

Earlier quoted context omitted.

The difference is that they want to turn a = d(c(b,7)) into a = b |> c(%,7) |> d(%) and I would like to see it turn into a = b,7 ~> c ~> d

It feels a bit unnatural to pipe multiple arguments like that in JS, and you could inline them in the first call without losing legibility: a = c(b, 7) |> d(%) It's the arguments added way down the line that are problematic: a = f((e(d(c(b))), 4), 5) a = ((b ~> c ~> d), 4 ~> e), 5 ~> f a = b |> c(%) |> d(%) |> e(%, 4) |> f(%, 5) Smart pipes [1] were a bit nicer about that: a = b |> c |> d |> e(#, 4) |> f(#, 5) Basica…

This:

    a = f((e(d(c(b))), 4), 5)
Seems not to make sense. Replacing c(b) with x we get:

    a = f((e(d(x)), 4), 5)
Replacing d(x) with x we get:

    a = f((e(x), 4), 5)
Replacing e(x) with x we get:

    a = f((x, 4), 5)
What is that?

Re: Show HN: A JavaScript function that looks and behaves like a pipe operator

#137
post #135

Earlier quoted context omitted.

It feels a bit unnatural to pipe multiple arguments like that in JS, and you could inline them in the first call without losing legibility: a = c(b, 7) |> d(%) It's the arguments added way down the line that are problematic: a = f((e(d(c(b))), 4), 5) a = ((b ~> c ~> d), 4 ~> e), 5 ~> f a = b |> c(%) |> d(%) |> e(%, 4) |> f(%, 5) Smart pipes [1] were a bit nicer about that: a = b |> c |> d |> e(#, 4) |> f(#, 5) Basica…

This: a = f((e(d(c(b))), 4), 5) Seems not to make sense. Replacing c(b) with x we get: a = f((e(d(x)), 4), 5) Replacing d(x) with x we get: a = f((e(x), 4), 5) Replacing e(x) with x we get: a = f((x, 4), 5) What is that?

Sorry, messed up parens here. It should have been:

    a = f(e(d(c(b))), 4), 5)
b is passed to c, then the result is passed to d, then to e along with 4 as a second parameter, and finally to f along with 5.

Re: Show HN: A JavaScript function that looks and behaves like a pipe operator

#138

Earlier quoted context omitted.

But at what cost? You had to name two intermediate variables - and naming things is hard.

Code is read many more times than it is written. Put in the minute or two to devise good intermediate variable names, and that will pay back manyfold every time someone needs to read and understand it.

Some code. E.g. most of my code was barely read by anyone, as most of it was utilitary or mvp or niche/local enough to never see big light. And when from time to time I read other code, e.g. on github, in projects I’m occasionally interested in, there’s barely anything resembling these high class advices. FOSS with large reach - yeah. But a library that you found for a specific hardware is “just code”. And to be honest, the difference between the two is not that big. Any decent programmer navigates both almost equally fast. As someone who modified Lua internals (typical example [1]) for employer’s needs I can say that I prefer Lua style to ceremony on top of ceremony, to multiparagraph explanations of what should be obvious to a competent developer, and to hundreds of extracted functions for the sole reason of clean-ish scopes or whatever.

But still I’ve done what people advised, for many years. And know what? It never paid back. I’m sort of tired to keep that secret and nod to this obvious overgeneralization and a blanket idea. Pretty sure I’m not alone.

[1] https://github.com/lua/lua/blob/6baee9ef9d5657ab582c8a4b9f88...

Re: Show HN: A JavaScript function that looks and behaves like a pipe operator

#139
post #60

Earlier quoted context omitted.

No worries your ide will help you for the parentheses.

IDEs and linters should not be a crutch methinks because not everyone uses the same IDE or text editor. Either way, it will still be awkward to read. Better that you either avoid that pattern or at least indent it in such a way that its not so visually confusing. Or yknow use a pipe operator.

People do tend to use the same linter and LSP. That’s why they exist in the first place.
Post reply on HN