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

401–410 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#401

Post by dalmo3 »

charles_f wrote: post #266
substation13 wrote: post #160

Earlier quoted context omitted.

> The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. I just don't think that this is always true. Consider: const highestScore = players |> filter(x => x.isAlive) |> map(x => x.score) |> tryMax I don't see how this is better: const alivePlayers = filter(x => x.isAlive)(players); const scoresOfalivePlayers = map(x => x.score)(alivePlayers); const hig…

> I don't see how this is better Case in point: > you can add helpful comments to pipeline code if needed The pipeline with explanatory variables explain to you what the steps are with code . Using pipeline you need to add comments to explain "what" you are doing.

And then it's a pleasure to open the debugger and immediately see the values for each step.

Re: Pipe Operator (|>) For JavaScript

#402

Post by hajile »

wruza wrote: post #380
hajile wrote: post #128

Earlier quoted context omitted.

The F# syntax looks/acts a lot better here (especially paired with lodash). I also feel your code example wasn't done in the way people would actually use pipes. import {map, join} from 'lodash/fp' //iterators have better performance envars |> Object.entries |> map(([key, val]) => `${key}=${val}`) |> join(' ') |> x => chalk.dim('$ ' + x, 'node', join(' ', args)) |> console.log Even without lodash, it's still easy to…

it's still easy to read That’s highly subjective I’m afraid. “Take entries of envvars, turn that into k=v, join that by a space, make dim $, previous that, and args, log that”. Personally I have no clue what’s going on at first glance with all these %%% “thats”. It’s meant to be declarative, but reads imperatively instead. console.log(chalk.dim( '$', ...Object.keys(envars) .map(k => `${k}=${envars[k]}`), 'node', ...a…

That's why I prefer the F# version where it's just the names of functions or anonymous arrow functions. Nothing magical about them. It just calls the functions in order from top to bottom.

Re: Pipe Operator (|>) For JavaScript

#403

Post by captainmuon »

greggman3 wrote: post #246
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…

> 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 would be cool if you could declare something (object, array) to be an immutable value. That sounds like a fundamental mis-understanding. Variables do not hold objects, they hold ref…

I don't want to freeze the object, I want to have a handle that doesn't allow me to modify the object. (Whether that would be at all possible in JS is another question.)

So

    let foo = {field:1};
    immutable let bar = foo;
    bar.field = 2; // error
    foo.field = 3; // ok
This is what I actually want when I think "const". I don't really care that you can reuse a variable, or re-seat a value. What I care about is that I recieve an object and sometimes want to modify it, and sometimes I want to make sure it stays the same. Maybe somebody else holds a reference and I don't want to surprise them.

(The inverse problem is when I have a function that takes something like a string or a number, and I want to change that from within the function. There is no way to pass a value type by reference. You have to encapsulate the value in an object and pass that. It would be cool if you could say something like `function double(ref x) { &x = x*2; }`.)

Re: Pipe Operator (|>) For JavaScript

#404

Post by yakshaving_jgt »

nerdponx wrote: post #24
chadlavi wrote: post #22

JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.

My pet theory: Front-end devs are generally stuck with JS, but they wish they were able to use other languages, but they can't, and can't convince their managers to use Clojurescript or Purescript, so this is what happens. What's bonkers to me is that ECMA would prefer to keep adding features like this instead of adding a macro system.

I'm not buying that theory. I'd love if more front-end developers were eager to use PureScript or Elm, but popular sentiment appears to be that anything other than JavaScript is weird or hard or impractical or unreadable.

Re: Pipe Operator (|>) For JavaScript

#405

Post by captainmuon »

de_keyboard wrote: post #293
captainmuon wrote: post #141

Earlier quoted context omitted.

The F# syntax would endlessly confuse me though. I'd always wonder whether |> join(' ') means join(x, ' ') or join(' ', x).

The F# syntax is an incredibly simple bit of syntactic sugar. Just replace this: x |> f With this: f(x) For the join example, you must do this: xs |> (x => x.join(' ')) It de-sugars to: (x => x.join(' '))(xs) ... which of course is simply: xs.join(' ')

Sure, I know. What I actually mean is that I don't grok curried functions.

Does join(a)(b) mean join(a, b) or join(b, a)? Does it mean a.join(b) or b.join(a)? And is a or b the delimiter? I don't really feel confident without looking it up or trying it out. I have a similar problem with Haskell's function syntax a -> a -> a.

If the function was called makeJoinerBy(sep)(array), it would be somewhat clearer:

    join = makeJoinerBy(' ')
    result = join(array)

Re: Pipe Operator (|>) For JavaScript

#406

Post by captainmuon »

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…

But isn't then the problem that JS doesn't offer more expressive function contexts? Some languages like Nim allow you to use blocks in place of expressions; the last expression in the block determines the return value. You can also use `if` as an expression. No need to introduce a separate syntax for this case. (Although I do like piping in bash, but I don't think it is a good idea for JS.)

Also sometimes you should just give stuff a temporary name, and treat React like a templating language.

Re: Pipe Operator (|>) For JavaScript

#407

Post by hajile »

galaxyLogic wrote: post #386
hajile wrote: post #275

Earlier quoted context omitted.

Sure, but I'd rather reserve that for a pattern-matching switch statement.

Why not use |> for that?

It's more common for pattern matching Java's new syntax, Erlang, Elixir, StandardML (fat arrow), F#, Kotlin, Ocaml, Haskell, Rust (fat arrow), Ada (fat arrow), Scala (fat arrow), Zig (fat arrow), and probably a bunch of others too.

That's a lot of prior art for people to be comfortable with and as the fat arrow already has another meaning, overloading it in pattern matching might complicate things.

Re: Pipe Operator (|>) For JavaScript

#409

Post by dimal »

yuliyp wrote: post #307
matlin wrote: post #34

Can't wait for this. Pipes are awesome in Elixir and bringing them to JS/TS will be great. To me this is both concise and readable: const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> await fetch(%) |> await %.json() |> %.properties.periods[0]

That is concise, readable, and does not have any room at all for error handling. If this was Rust, it could at least be turned into something which returned the right Err for what was happening. Without something like that, trying to add error handling to the things which may blow up would instantly turn it into gibberish. Every single function here can fail (the HTTP request could fail, the data returned could be un…

But it allows a fully functional style, and so you can do railway oriented programming[0], where every function has a success and failure route. The top level code looks the same as that without error handling.

[0] https://fsharpforfunandprofit.com/rop/

Post reply on HN