No, what the author is discussing is a syntax thing.

Lets take a hypothetical C-like language:

    result = C(B(A()))

In this your result is on the left hand side. The first function to be executed is A and then B and lastly C, which also reads right to left. This is a pretty common way to write code, it's by no means unique to C-like languages. So you'd have gotten so good at reading code like this that you probably don't even realise you're reading right to left.

Now lets look at a POSIX-like shell language:

    result = $(A | B | C)

Here the result is still on the left hand side but now you're reading the functions from left to right (ie pipes)

I'm not the article author by my own programming language takes things a step further from conventional shells and you can do the following:

    A -> B -> C -> set result

Here it reads fully left to right. There is zero confusion about which order to read this.

----------------

Going back to the more general point about reading left to right, it's worth noting that even math operators can be extended this way. For example with polish notation (https://en.wikipedia.org/wiki/Polish_notation) your operators precede your values. Effectively turning those symbols into function names:

    + 2 5

...would return 7

Though personally I prefer the more traditional format of operators sitting between their values (2+5), but that's purely because that is what I'm used to.

You can write A | B | C | result=$(cat) in shell.

Edit: this only works if the shell runs the last command in the current environment (as opposed to a subshell), and only ksh and zsh seem to do that...

Or with uniform function call syntax

result = A().B().C()

The post gives an example of how python doesn't have this feature in the section [https://blog.vero.site/post/noulith#coding-with-and-without-...]

Python fails this criteria because if you type as you think through the process, you have to move the cursor to the beginning to prefix the 'map' around the input.

For example this series of transforming the input:

puzzle_input.split("\n\n")

map(ints, puzzle_input.split("\n\n"))

map(sum, map(ints, puzzle_input.split("\n\n")))

max(map(sum, map(ints, puzzle_input.split("\n\n"))))

----------------------

Compare to this postfix syntax where you can write this incrementally as you think through the operations:

puzzle_input split "\n\n" map ints map sum then max

Thanks for pointing out that specific example and comparison. The solution seems like it's just a less readable pipeline.

    puzzle_input split "\n\n" map ints map sum then max;
    puzzle_input split "\n\n" map ints map sum then sort then (_[-3:]) then sum;

after a while, my brain reorganized and i think of the map() first, before thinking about the content of the map, basically to avoid the keystrokes required to go to beginning of line, then back to where I was typing.

That's what it sounds like to me. Thinking about a line of code before writing it down, or knowing what the code will do instead of trial and error (which... is what I often do, lol)