Yet another way to invoke functions in JavaScript without parentheses

How Perl was created:

‘Larry, throw the cat at the keyboard!’

MEEEOW!

‘What did it type?’

‘&}Ak'>v=4%Qe}9;’

‘OK, so let’s make this a syntax for hello world.’

Well, the prank is being refined for many years now, by the fine folks partying at:

https://www.ioccc.org

Unix is Dead! Wanna Fight?? (John C. Dvorak):

https://donhopkins.com/home/catalog/unix-haters/etc/unix-is-...

I wonder if there was a period in the 90s where the chess community was more interested in talking about IBM’s stock price than in actually playing chess.

I'm definitely gonna use that for April 1st though, just adding this as instruction in Claude.md

That will also serves as a litmus test to check how many of my coworkers are reading the code they push.

Programmers are still interested in code

It feels like it's from back when we unironically thought memorizing quirks like this makes us better programmers, or is somehow important for making computers more secure, aka middle of the 2010s tech bubble.

Reminds me of Harder Drives https://tom7.org/papers/murphy2022harder.pdf

And something my friend wrote a few years ago: https://github.com/radian628/tram

Data storage and transmission has so much innovation going on!

You might be interested in the book "Data Flow Analysis" by Khedker et al.

It's very compiler-focused, but it's one piece of the puzzle.

Never forget RFC 1149 or KERMIT!

For some reason this made me think about all of the potential complexities that can be involved in CLOS in calling a generic function and some method(s) actually being invoked...

Implement your own delay-line memory with the speaker, microphone, and echo of the room.

One of the things I love about programming in dialects of ML like ocaml and f# is the forward pipe operator:

  x
  |> f
  |> g
  |> h

So if it were something like

  h(z, g(y, f(x))

  x
  |> f
  |> g y
  |> h z

  my_data
  |> filter (x => x > 37)
  |> select (x => x * 2)
  |> sum

Mathematica has a crazy amount of syntax abbreviations (https://reference.wolfram.com/language/guide/Syntax.html). Of course your whish is fulfilled there: x // f called the postfix operator.

Do you mean (((x)h)g)f ?

since the order in which things happen is "h first, then g, then f"

So would you like to write shell commands connected with pipes like that too?

So is this better too

  $ less | find / -type f -perm /6000 -ls

  $ find / -type f -perm /6000 -ls | less

ps. I'm fine with current notation and would not like change it.

Did you even have an RPN-based calculator at school?

As to more serious programming languages, Erlang, F#, Haskell have forms of a "pipe" operator, roughly

  [1 2 3] |> sum |> print

But the original algebra functions, as introduced by Leibniz in 17th century, were, of course, pure functions, more like properties than procedures. So cos(x), aka cos x, is just a formalized shorthand for "cosine of x", so it preserved the order of words typical for Germanic and Romance languages. Maybe if functions were introduced by the Japanese, we would have the reverse order, kind of x の cos.

Assuming you mean h)g)f, you can do it in D. D allows you to write this:

f(g(h(x))) as x.h().g().f() or even x.h.g.f (parenthesis are optional).

That actually makes so much sense...

When you're calling a function, you're putting some things into the function... You have to get the things first before you can put them in...

Why didn't it evolve like that in the first place? Is it a byproduct of mathematical notation? If so, I wonder why mathematical notation evolved that way in the first place...

Stack based languages and the APL tradition all follow this pattern, which I agree can be more terse and nice too. I've also been experimenting with right-associative calls which does the same thing but in reverse. For a data pipeline you're more likely to transform from A->B, so I think the post-fix syntax makes sense.

But you can also define a "thread" operator easily for doing subsequent function calls. ala `threaded x { f; g; h }`

In a lazy language like Haskell, the order in which things are actually evaluated is f -> g -> h -> x, because arguments to a function are only evaluated when the are needed, rather than before they are called. But even so, I still prefer writing it as x |> h |> g |> f.

If `f` is an expression, that would require it to be evaluated last as well.

This is why some languages have the | pipe syntax for chaining operations.

I want to put the function below the arguments, so that the call tree actually looks like a tree

    u v x y
     f   g
       h

you can start with

    var chain = x=>f=>f?chain(f(x)):x;
    chain(x)(h)(g)(f)();

    var _ = (f,...y)=>x=>f(x,...y);
    var sum = (x,y)=>x+y;
    chain(1)(_(sum,1))()

    var $ = (x,...f)=>f.reduce((x,f)=>f(x),x);
    $(1,_(sum,1));

    var sum1 = _($,_(sum,1));
    sum1(1);

And that's why "purely procedural" languages don't make much sense to me

It's more natural to write

    x.h().g().f()

The function reference is actually evaluated first so your preferred order is actually backwards! Consider this:

  foo.bar(x)

  foo()(bar())

> optional API and only implemented by V8

aka "Chrome implemented this and wanted everyone else to do so as well"

Maybe it is, just requires a different parser

The prototype thing is quite unique among mainstream languages. It is kind of simple in principle and works well for what it intends to do, but god it causes so much confusion and is frequently a source of CVEs. valueOf combined with implicit conversion is a nightmare for production code.

Yesterday I was re-using some shaders I had written a long time ago, and here's what I used to do multiline strings before the glorious backtick arrived on the scene...

    (function () {/*
      my awesome shader code
    */}).toString().match(/[^]*\/\*([^]*)\*\/\}$/)[1]

If I were to write a book on programming in JS, it would be a black cover with the JS Holy Trinity equality diagram in red, to emphasize its Satanic nature.

Not when it comes to bad input sanitizers that only look for literal "()".

The unary plus implicitly converts an expression to a number, which calls `valueOf` for non-primitive values.

I think to implicitly trigger the valueOf function.