Recently, I ripped usage examples out of a rust project's README.md, and put them in doc comments. Almost all of them were broken due to small changes over time, and I never remembered to update the readme. `cargo test` runs doc comments like mini integration tests, so now the examples never rot. I wish more languages and tools had this feature.
It means having to go to the linked docs (which are automatically pushed to the repo's github pages) to see examples, but I think this is a reasonable tradeoff.
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.
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.
It is not a surprise that overriding the implementation of an operator’s type coercion works and overrides the behavior of the operator’s type coercion.
I actually don't think you are wrong, but I'm not backing that up with any actual data.
I happened to know it because of how the hyperHTML micro-library works; the author went into great detail about it and a ton of other topics. But my gut would say that the average js dev doesn't know about it.
But then... it's useful for creating component frameworks which... most js devs use. Which doesn't mean they know how they work under the hood. But... a lot of devs I've met specifically choose a framework because of how it works under the hood.
... so... I really have no idea how many people know this. I'm still betting it's less than average.
Well, Proxy objects do allow you to override the behavior of any property, including Symbol properties. Symbol.iterator is pretty widely used to create custom iterable objects, so I would expect curious devs to have taken a look at what else can be done through the use of Symbol properties.
I think that depends on the person, the language, and how familiar they are with the language. Someone's "what the fuck" is another's "obviously it can do that".
Swift, IMHO. Grew up on ObjC and the absolutely crazy things you could pull off dynamically at runtime. You can definitely feel they did not want that in Swift. There's operator overriding but idk if I'd count that as contorting in surprising ways shrugs
No way dude, this does a disservice to the insanity that is C++'s syntax. Wake me up when you have 6 different initialization syntaxes or fun things like 4[array]
It sounds like using less tokens (or, less output due to a more compact syntax) is like a micro-optimization; code should be written for readability, not for compactness. That said, there are some really compact programming languages out there if this is what you need to optimize for.
IMO it's more likely to get confused because there are less unique tokens to differentiate between syntax (e.x. pipe when we want bitwise-or or vice-versa)
I’ve heard it said before on HN that this is not true in general because more tokens in familiar patterns helps the model understand what it’s doing (vs. very terse and novel syntax).
Otherwise LLMs would excel at writing APL and similar languages, but seems like that’s not the case.
In a similar way to the featured project, Chute also uses proxies to work like a pipeline operator. But like in your reply, Chute uses a dot-notation style to chain and send data through a mix of functions and methods.
You might like to see how Chute uses proxies, as it requires no `chainWith` or similar setup step before use. Without setup, Chute can send data through global or local, top-level or nested, native or custom, unary, curried or non-unary functions and methods. It gives non-unary functions the current data at a specific argument position by using a custom-nameable placeholder variable.
Since this library leverages Symbol.toPrimitive, you may also use operators besides bitwise-OR. Additionally, the library does not seem to dispatch on the `hint` parameter[0]. Now I want to open a JS REPL, try placing this library's pipe object into string template literals, and see what happens.
In case it might interest anyone, I wrote a similar vanilla JS function last year called Chute. Chute chains methods and function calls using dot-notation.
I am all for clean syntax but I feel like JS has already reached a nice middle ground between expressiveness (especially w/ map/reduce/filter) and readability. I'd personally rather not have another syntax that everyone will have to learn unless we're already moving to a new language.
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.
> everything gets converted to an array at the drop of a hat
Can you name an example? IME the opposite is a more common complaint: needing to explicitly convert values to arrays from many common APIs which return eg iterables/iterators.
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?
I think what confused me is the passive language: "everything gets converted" sounds (to me) like the runtime or some aspect of language semantics is converting everything, rather than developers. Whereas this is the same complaint I mentioned.
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.
I agree but to steelman it, what about custom functions? I think just doing it naively is perfectly fine. Or if you want use some pipe utility. Or wrap the array, string, etc. with your own custom methods.
If you're interested in the Ruby language too, check out this PoC gem for an "operator-less" syntax for pipe operations using regular blocks/expressions like every other Ruby DSL.
C++ is the reason people have that reaction. The quintessential example in introductory texts for operator overloading is using bit-shift operators to output text. I mean, come on - if that’s your example, don’t complain when people follow suit and get it wrong.
C++ has std::format these days that does a far more sane thing, people are too quick to throw out the baby with the bathwater when it comes to bad things.
Some OO is fine, just don't make your architecture or language entirely dependent on it. Same with operator overloading.
When it comes to math heavy workloads, you really want a language that supports operator overloading (or have a language full of heavy vector primitives), doing it all without just becomes painful for other reasons.
Yes, the early C++ _STDLIB_ was shit early on due to boneheaded architectural and syntactic decisions (and memory safety issues is another whole chapter), but that doesn't take away that the language is a damn powerful and useful one.
std::format in C++20 is just for the string manipulation half but you still left shift cout by the resulting string to output text in canonical C++.
C++23 introduced std::print(), which is more or less the modernized printf() C++ probably should have started with and also includes the functionality of std::format(). Unfortunately, it'll be another 10 years before I can actually use it outside of home projects... but at least it's there now!
While that operator is also used for bit-shift, it is not the bit-shift operator. It's not that the bit-shift operator is used for stream direction, it's that the same operator is used for both stream direction and bit-shifts. And which code is operating on both high-level abstract streams and bit-shifts at the same time.
Oh wait, looked at the source again, so it's some weird stateful collection thing triggered by the type coercion? By now I'm wishing that it was operator overloading.
Pipes are great in environments where "everything is a string" (bash, etc), but do we really need them in javascript? I have yet to see a compelling example.
Pipes are great where you want to chain several operations together. Piping is very common in statically typed functional langauges, where there are lots of different types in play.
Sequences are a common example.
So this:
xs.map(x => x * 2).filter(x => x > 4).sorted().take(5)
In pipes this might look like:
xs |> map(x => x * 2) |> filter(x => x > 4) |> sorted() |> take(5)
In functional languages (of the ML variety), convention is to put each operation on its own line:
xs
|> map(x => x * 2)
|> filter(x => x > 4)
|> sorted()
|> take(5)
Note this makes for really nice diffs with the standard Git diff tool!
But why is this better?
Well, suppose the operation you want is not implemented as a method on `xs`. For a long time JavaScript did not offer `flatMap` on arrays.
You'll need to add it somehow, such as on the prototype (nasty) or by wrapping `xs` in another type (overhead, verbose).
With the pipe operator, each operation is just a plain-ol function.
This:
xs |> f
Is syntactic sugar for:
f(xs)
This allows us to "extend" `xs` in a manner that can be compiled with zero run-time overhead.
if the language or std lib already allows for chaining then pipes aren't as attractive. They're a much nicer alternative when the other answer is nested function calls.
e.g.
So this:
take(sorted(filter(map(xs, x => x \* 2), x => x > 4)), 5)
To your example:
xs |> map(x => x \* 2) |> filter(x => x > 4) |> sorted() |> take(5)
is a marked improvement to me. Much easier to read the order of operations and which args belong to which call.
First of all, with the actual proposal, wouldnt it actually be like this? with the %.
xs
|> map(%, x => x * 2)
|> filter(%, x => x > 4)
|> sorted(%)
|> take(%, 5);
Anything that can currently just chain functions seems like a terrible example because this is perfectly fine:
xs.map(x => x * 2)
.filter(x => x > 4)
.sorted()
.take(5)
Not just fine but much better. No new operators required and less verbose. Just strictly better. This ignores the fact that sorted and take are not actually array methods, but there are equivalent.
But besides that, I think the better steelman would use methods that dont already exist on the prototype. You can still make it work by adding it to the prototype but... meh. Not that I even liket he proposal in that case.
This is just different syntax for nesting function calls (i.e. c(b(a(value))) becomes value | a | b | c), right? Definitely would make code more readable if this was just something in JS or a compiler where it’s the same as normally calling functions.
I would actually love extension of TS with operator overloading for vector maths (games, other linear algebra, ML use cases). I wouldn’t want libraries to rely on it, but in my own application code, it can sometimes be really helpful.
Overengineered in my view, what is wrong with `x | f` is `f(x)`? Then `x | f | g` can be read as `g(f(x))` and you're done. I don't see any reason to make it more complicated than that.
Piping syntax is nice for reading, but it's hard to debug. There's no clear way to "step through" each stage of the pipe to see the intermediate results.
First example doesn't work though:
If you look at the tests file, it needs to be written like this to make it work: Which is not anymore as ergonomic.I suspect this was written with an LLM and the author didn't actually verify that the examples in the README worked.
Recently, I ripped usage examples out of a rust project's README.md, and put them in doc comments. Almost all of them were broken due to small changes over time, and I never remembered to update the readme. `cargo test` runs doc comments like mini integration tests, so now the examples never rot. I wish more languages and tools had this feature.
It means having to go to the linked docs (which are automatically pushed to the repo's github pages) to see examples, but I think this is a reasonable tradeoff.
FWIW it's possible to run readme examples automatically add part of tests: https://github.com/parallaxsecond/rust-cryptoki/blob/main/cr...
I wrote this with an LLM but manually changed the README. Thanks for pointing this out, it is now updated.
I was playing with it, and you can do this, which looks a little better.
Since it uses the "Symbol.toPrimitive" method, you can use any operator (not just "bitwise OR" (|)).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.
Thanks for pointing this out, I updated the examples now to this syntax.
Seems similar to the problem encountered when making the stupid idea PyNQ:
https://github.com/IAmStoxe/PyNQ
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.
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.
It is not a surprise that overriding the implementation of an operator’s type coercion works and overrides the behavior of the operator’s type coercion.
Do you really think that most JavaScript users are aware that “overriding the implementation of an operator’s type coercion” is a language feature?
Sure, you can claim that everyone should know this obscure feature when they don’t. But that’s how this language enters C++ territory.
I actually don't think you are wrong, but I'm not backing that up with any actual data.
I happened to know it because of how the hyperHTML micro-library works; the author went into great detail about it and a ton of other topics. But my gut would say that the average js dev doesn't know about it.
But then... it's useful for creating component frameworks which... most js devs use. Which doesn't mean they know how they work under the hood. But... a lot of devs I've met specifically choose a framework because of how it works under the hood.
... so... I really have no idea how many people know this. I'm still betting it's less than average.
Well, Proxy objects do allow you to override the behavior of any property, including Symbol properties. Symbol.iterator is pretty widely used to create custom iterable objects, so I would expect curious devs to have taken a look at what else can be done through the use of Symbol properties.
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.
I think that depends on the person, the language, and how familiar they are with the language. Someone's "what the fuck" is another's "obviously it can do that".
Reminder that Perl exists:
https://metacpan.org/dist/perlsecret/view/lib/perlsecret.pod...
Swift, IMHO. Grew up on ObjC and the absolutely crazy things you could pull off dynamically at runtime. You can definitely feel they did not want that in Swift. There's operator overriding but idk if I'd count that as contorting in surprising ways shrugs
A language where there's only one way to do things, maybe a very early version of CSS. The things is all languages end up bloated with new features.
Probably not, but there are definitely languages that don't do automatic type coercion - so at least one fewer contortion available.
Nothing new. This was 15 years ago:
https://github.com/tbtlr/def.js
No way dude, this does a disservice to the insanity that is C++'s syntax. Wake me up when you have 6 different initialization syntaxes or fun things like 4[array]
Agreed!!!!
Serious q: but how does this sentiment change with LLMs? They can pickup new syntax pretty fast, then use fewer tokens...
It sounds like using less tokens (or, less output due to a more compact syntax) is like a micro-optimization; code should be written for readability, not for compactness. That said, there are some really compact programming languages out there if this is what you need to optimize for.
I imagine the error messages must be terrible to read, since this hack is based on reusing syntax that was meant for something entirely different.
IMO it's more likely to get confused because there are less unique tokens to differentiate between syntax (e.x. pipe when we want bitwise-or or vice-versa)
I’ve heard it said before on HN that this is not true in general because more tokens in familiar patterns helps the model understand what it’s doing (vs. very terse and novel syntax).
Otherwise LLMs would excel at writing APL and similar languages, but seems like that’s not the case.
probably because there arent enough apl examples to imbue the rare weird apl tokens with sufficient semantic meaning to be useful.
I love the idea! The creativity of (ab)using JavaScript type coersion is really neat. I did something similar using proxies to create a chainable API.
https://dev.to/sethcalebweeks/fluent-api-for-piping-standalo...
In another comment, I mentioned a vanilla JavaScript function I published in 2024 called Chute. https://github.com/gregabbott/chute
In a similar way to the featured project, Chute also uses proxies to work like a pipeline operator. But like in your reply, Chute uses a dot-notation style to chain and send data through a mix of functions and methods.
You might like to see how Chute uses proxies, as it requires no `chainWith` or similar setup step before use. Without setup, Chute can send data through global or local, top-level or nested, native or custom, unary, curried or non-unary functions and methods. It gives non-unary functions the current data at a specific argument position by using a custom-nameable placeholder variable.
The Chute page describes some more of its features: https://gregabbott.pages.dev/chute/
Since this library leverages Symbol.toPrimitive, you may also use operators besides bitwise-OR. Additionally, the library does not seem to dispatch on the `hint` parameter[0]. Now I want to open a JS REPL, try placing this library's pipe object into string template literals, and see what happens.
Overall, cool library.
[0] https://tc39.es/ecma262/multipage/abstract-operations.html#s...
what are your ideas regarding the pipe object in string template literals? I'm just looking for an overview to see if it sparks some ideas.
In case it might interest anyone, I wrote a similar vanilla JS function last year called Chute. Chute chains methods and function calls using dot-notation.
https://github.com/gregabbott/chute
That's Point-free style programming.
https://en.wikipedia.org/wiki/Tacit_programming
Neat, but I think that functions already do what we need.
For one thing, the example isn't the most compelling, because you can:
or That said, there is already:Are any of the cases compelling? Thinking of the actual proposal. It creates some new magic with |> and % just for syntactic sugar.
I am all for clean syntax but I feel like JS has already reached a nice middle ground between expressiveness (especially w/ map/reduce/filter) and readability. I'd personally rather not have another syntax that everyone will have to learn unless we're already moving to a new language.
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(...)`.
That's the DOM API, it's not part of the language! They had reasons for querySelectorAll not returning an array.
> everything gets converted to an array at the drop of a hat
Can you name an example? IME the opposite is a more common complaint: needing to explicitly convert values to arrays from many common APIs which return eg iterables/iterators.
`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?
People write a lot of stuff like [...iterable].map(fn). They do it so much it's as if they do it each time a hat drops.
Thank you for clarifying. (I think?)
I think what confused me is the passive language: "everything gets converted" sounds (to me) like the runtime or some aspect of language semantics is converting everything, rather than developers. Whereas this is the same complaint I mentioned.
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.
I agree but to steelman it, what about custom functions? I think just doing it naively is perfectly fine. Or if you want use some pipe utility. Or wrap the array, string, etc. with your own custom methods.
Whatever that thrush thing is feels 10x more gross than the pipe
Not if you consider that the linked repo requires you to use asPipe on all functions first. So it's this:
Vs this: (And that doesn't work in reality, as the top comment here notes)Thrush is the "T combinator" - I believe that the "Thrush" name comes from To Mock a Mockingbird by Raymond Smullyan [1].
[1]: https://www.amazon.com/Mock-Mockingbird-Other-Logic-Puzzles/...
[2]: https://en.wikipedia.org/wiki/Combinatory_logic#In_computing
[3]: https://leanpub.com/combinators/read#leanpub-auto-the-thrush
If you're interested in the Ruby language too, check out this PoC gem for an "operator-less" syntax for pipe operations using regular blocks/expressions like every other Ruby DSL.
https://github.com/lendinghome/pipe_operator#-pipe_operator
It's an interesting experiment but standard Ruby is expressive enough.
[9, 64].map { Math.sqrt(_1) } #=> [3.0, 8.0]
For the first example I would just define a method that uses local variables. They're local so it's not polluting context.
This kind of stuff is why C++ developers has an almost overly allergic reaction to operator overloading.
C++ is the reason people have that reaction. The quintessential example in introductory texts for operator overloading is using bit-shift operators to output text. I mean, come on - if that’s your example, don’t complain when people follow suit and get it wrong.
C++ has std::format these days that does a far more sane thing, people are too quick to throw out the baby with the bathwater when it comes to bad things.
Some OO is fine, just don't make your architecture or language entirely dependent on it. Same with operator overloading.
When it comes to math heavy workloads, you really want a language that supports operator overloading (or have a language full of heavy vector primitives), doing it all without just becomes painful for other reasons.
Yes, the early C++ _STDLIB_ was shit early on due to boneheaded architectural and syntactic decisions (and memory safety issues is another whole chapter), but that doesn't take away that the language is a damn powerful and useful one.
std::format in C++20 is just for the string manipulation half but you still left shift cout by the resulting string to output text in canonical C++.
C++23 introduced std::print(), which is more or less the modernized printf() C++ probably should have started with and also includes the functionality of std::format(). Unfortunately, it'll be another 10 years before I can actually use it outside of home projects... but at least it's there now!
While that operator is also used for bit-shift, it is not the bit-shift operator. It's not that the bit-shift operator is used for stream direction, it's that the same operator is used for both stream direction and bit-shifts. And which code is operating on both high-level abstract streams and bit-shifts at the same time.
This isn’t overloading the operator, it is replacing the implementation of type coercion when | is used with pipe() or asPipe() objects.
| itself still works exactly as before.
Oh wait, looked at the source again, so it's some weird stateful collection thing triggered by the type coercion? By now I'm wishing that it was operator overloading.
Imagine the possibilities for control flow obfuscation when this trick is used with parentheses wrapping a part of the pipeline. :-)
Sad that the pipe operator proposal seems to have stalled.
The F# version of the proposal was probably the simplest choice.
Nice! I love it when a language introduces new syntax for things that weren't remotely difficult in the first place!
Pipes are great in environments where "everything is a string" (bash, etc), but do we really need them in javascript? I have yet to see a compelling example.
Pipes are great where you want to chain several operations together. Piping is very common in statically typed functional langauges, where there are lots of different types in play.
Sequences are a common example.
So this:
In pipes this might look like: In functional languages (of the ML variety), convention is to put each operation on its own line: Note this makes for really nice diffs with the standard Git diff tool!But why is this better?
Well, suppose the operation you want is not implemented as a method on `xs`. For a long time JavaScript did not offer `flatMap` on arrays.
You'll need to add it somehow, such as on the prototype (nasty) or by wrapping `xs` in another type (overhead, verbose).
With the pipe operator, each operation is just a plain-ol function.
This:
Is syntactic sugar for: This allows us to "extend" `xs` in a manner that can be compiled with zero run-time overhead.if the language or std lib already allows for chaining then pipes aren't as attractive. They're a much nicer alternative when the other answer is nested function calls.
e.g.
So this:
To your example: is a marked improvement to me. Much easier to read the order of operations and which args belong to which call.First of all, with the actual proposal, wouldnt it actually be like this? with the %.
Anything that can currently just chain functions seems like a terrible example because this is perfectly fine: Not just fine but much better. No new operators required and less verbose. Just strictly better. This ignores the fact that sorted and take are not actually array methods, but there are equivalent.But besides that, I think the better steelman would use methods that dont already exist on the prototype. You can still make it work by adding it to the prototype but... meh. Not that I even liket he proposal in that case.
There is more than one proposal; the F#-style one doesn't have the (weird) placeholder syntax.
> You can still make it work by adding it to the prototype
This is exactly what we want to avoid!
wrap the object?
Why would you want to avoid that? It's controversial syntactic sugar. Enforcing a convention locally seems ideal.
1. Wrapping is more code than using a built-in pipe operator
2. There is a run-time overhead to wrapping
IMO a design goal of programming langauges should be for the most readable code to also be the most performant.
Language features tend to be controversial until they are mainstream.
is this solving a problem people actually have?
other libraries like rxjs use .pipe(f,g,h) which works just fine.
Fully agreed, var-arg functions are well established in JS so no need to abuse operators for these kinds of things.
Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.
This is just different syntax for nesting function calls (i.e. c(b(a(value))) becomes value | a | b | c), right? Definitely would make code more readable if this was just something in JS or a compiler where it’s the same as normally calling functions.
It would be nice to have well-maintained fluent/pipe/streaming API solution for Python.
Won’t work in TS.
I would actually love extension of TS with operator overloading for vector maths (games, other linear algebra, ML use cases). I wouldn’t want libraries to rely on it, but in my own application code, it can sometimes be really helpful.
Check out C#. CliWrap does exactly this: https://github.com/Tyrrrz/CliWrap/blob/master/CliWrap/Comman...
Overengineered in my view, what is wrong with `x | f` is `f(x)`? Then `x | f | g` can be read as `g(f(x))` and you're done. I don't see any reason to make it more complicated than that.
You can’t make it work like that in current JavaScript.
Alternatively just use F# and Fable
Pipe "operator" for the rest of us:
Or code golf version:I know that it's wrong but I love it.
I am wondering if it could be useful for libraries:
That's clever! But I still want JS to get the actual pipeline operator.
Piping syntax is nice for reading, but it's hard to debug. There's no clear way to "step through" each stage of the pipe to see the intermediate results.
There is usually some variant of tee that lets you do that.
I'm not sure this is at all a good idea but thanks to the great discussion here at Hacker News - it is now up on npm:
npm i aspipes
Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.
It's simultaneously a miracle and deeply wrong that this worked.
These TC39 proposals take way too long to get approved and implemented.
Very clever. Love seeing stuff like this that pushes the bounds
This cargo seem to give magical superpowers.
Is this intended for code golf or something? This buys you literally nothing and just makes the language needlessly cryptic.
Very appealing.
See also https://livescript.net/
Cool work!
this is sick
Now we just need 'do notation' for monads! :-)
[dead]