Working pipe operator today in pure JavaScript

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.

I wrote this with an LLM but manually changed the README. Thanks for pointing this out, it is now updated.

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.

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.

LISP — the contortions are expected, not surprises

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

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.

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.

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.

Not if you consider that the linked repo requires you to use asPipe on all functions first. So it's this:

  const greeting = thrush(
    'hello',
    s => s.toUpperCase(),
    s => s + '!!!'
  );

  const upper = asPipe(s => s.toUpperCase())
  const ex = asPipe((s) => s + '!!!')
  const greeting = pipe('hello')
    | upper
    | ex
  await greeting.run()

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

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.

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.

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)

    xs |> map(x => x \* 2) |> filter(x => x > 4) |> sorted() |> take(5)

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);

    xs.map(x => x * 2)
        .filter(x => x > 4)
        .sorted()
        .take(5)

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.