61–70 of 109 posts
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 suspect this was written with an LLM and the author didn't actually verify that the examples in the README worked.
Earlier quoted context omitted.
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.
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.
Further proof that JavaScript accidentally became the new C++. “Aren’t you surprised that this syntax works?” is not praise for a language design.
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.
Sure, you can claim that everyone should know this obscure feature when they don’t. But that’s how this language enters C++ territory.
This kind of stuff is why C++ developers has an almost overly allergic reaction to operator overloading.
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.
Earlier quoted context omitted.
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.
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.
> 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.
Earlier quoted context omitted.
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),…
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 strictl…
> You can still make it work by adding it to the prototype
This is exactly what we want to avoid!
Earlier quoted context omitted.
> 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.