Live data from Hacker News

Working pipe operator today in pure JavaScript

github.com

91–100 of 109 posts

Re: Working pipe operator today in pure JavaScript

#92
post #10

First example doesn't work though: const greeting = pipe('hello') | upper | ex('!!!') await greeting.run() // → "HELLO!!!" If you look at the tests file, it needs to be written like this to make it work: let greeting; (greeting = pipe('hello')) | upper | ex('!!!'); await greeting.run(); Which is not anymore as ergonomic.

That is a big enough DX problem that I would veto using this on a project.

You’ve implied what I’ll state clearly:

Pipes are for composing transformations, one per line, so that reading comprehension doesn’t nosedive too fast with accumulation of subsequent operations.

Chaining on the same line is shit for readying and worst for git merges and PR reviews.

Re: Working pipe operator today in pure JavaScript

#93
post #10

First example doesn't work though: const greeting = pipe('hello') | upper | ex('!!!') await greeting.run() // → "HELLO!!!" If you look at the tests file, it needs to be written like this to make it work: let greeting; (greeting = pipe('hello')) | upper | ex('!!!'); await greeting.run(); Which is not anymore as ergonomic.

I was playing with it, and you can do this, which looks a little better. const greeting = pipe('hello'); greeting | upper | ex('!!!'); await greeting.run(); // → "HELLO!!!" Since it uses the "Symbol.toPrimitive" method, you can use any operator (not just "bitwise OR" (|)). const greeting = pipe('hello'); greeting / upper * ex('!!!'); await greeting.run(); // → "HELLO!!!"

That’s not better because it implies these are all destructive function calls.

Mutating your inputs is not functional programming. And pipes are effectively compact list comprehensions. Comprehensions without FP is Frankensteinian.

Re: Working pipe operator today in pure JavaScript

#94

Earlier quoted context omitted.

I think JS's map/reduce/filter design is one of the worst ones out there actually - map has footguns with its extra arguments and everything gets converted to an array at the drop of a hat. Still, pipeline syntax probably won't help fix any of that.

I always thought JS map filter reduce felt quite nice, especially playing around with data in the REPL. Java maps with all the conversions back and forth to streams are clumsy.

Well in JS you have to convert to arrays instead. You can't do `document.querySelectorAll(...).map(...)`.

Re: Working pipe operator today in pure JavaScript

#95

Earlier quoted context omitted.

`map` returns an array and can only be called on an array.

Right, but I’m not clear on what gets converted to an array. Do you mean more or less what I said in my previous comment? That it requires you (your code, or calling code in general) to perform that conversion excessively?

One gripe I have is that the result of map/filter is always an array. As a result, doing `foo.map(...).filter(...).slice(0, 3)` will run the map and the filter on the entire array even if it has hundreds of entries and I only need the first 10 to find the 3 that match the filter.

Re: Working pipe operator today in pure JavaScript

#98
post #8

Further proof that JavaScript accidentally became the new C++. “Aren’t you surprised that this syntax works?” is not praise for a language design.

> “Aren’t you surprised that this syntax works?” is not praise for a language design.

It's a clever hack. This is Hacker News. Let's try to appreciate clever hacks while here.

Re: Working pipe operator today in pure JavaScript

#99
post #48

Earlier quoted context omitted.

Is there a language that can’t be contorted in surprising ways that I’m unaware of?

LISP — the contortions are expected, not surprises

Non-Lisp: gratuitous contortions are expected.
Post reply on HN