Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.
Working pipe operator today in pure JavaScript
21–30 of 109 posts
Re: Working pipe operator today in pure JavaScript
#22Damn, that’s really clever. I love seeing these expressive explorations of JavaScript syntax.
Re: Working pipe operator today in pure JavaScript
#23In 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.
Re: Working pipe operator today in pure JavaScript
#24Won’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.
Re: Working pipe operator today in pure JavaScript
#25Further proof that JavaScript accidentally became the new C++. “Aren’t you surprised that this syntax works?” is not praise for a language design.
Agreed!!!! Serious q: but how does this sentiment change with LLMs? They can pickup new syntax pretty fast, then use fewer tokens...
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.
Re: Working pipe operator today in pure JavaScript
#26Won’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...
// Examples
var cmd = Cli.Wrap("foo") | (stdOut, stdErr);
var target = PipeTarget.Merge(
PipeTarget.ToFile("file1.txt"),
PipeTarget.ToFile("file2.txt"),
PipeTarget.ToFile("file3.txt")
);
var cmd = Cli.Wrap("foo") | target;Re: Working pipe operator today in pure JavaScript
#27This 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.
Re: Working pipe operator today in pure JavaScript
#28Overengineered 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.
[deleted]
Re: Working pipe operator today in pure JavaScript
#29This cargo seem to give magical superpowers.
Re: Working pipe operator today in pure JavaScript
#30Further proof that JavaScript accidentally became the new C++. “Aren’t you surprised that this syntax works?” is not praise for a language design.
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.