I don't really even understand what is meant by "being able to write code from left to right without backtracking”, much less why that is bonkers. Scrolling down and seeing the code examples, the language even seems quite conventional, so I'm even more confused.

Isn't that a whole lot more "being able to write code without making a lot of dumb mistakes", which is a feature of the programer.

So it boils down to getting gud and practice?

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)

Here's an example. In SQL the "select" clause comes at the start. In C# LINQ queries, "select" comes at the end. A major resulting difference is autocomplete works in the latter case but not the former.

A more pervasive example is how OOP languages do x.f(...) instead of f(x, ...). This also helps with autocomplete. Also it results in calls chaining like x.y(...).z(...) instead of nesting like z(y(x(...), ...), ...).

These kinds of things have noticeable effects on how easy it is to discover relevant methods and how fast they are to type.

Talking of shell, the preference for left-to-right is often used to justify "useless use of cat", i.e. `cat file | command` instead of `command <file`, but it can just be written `<file command` instead.

I'm surprised that file> command isn't the preferred idiom. Does that mean something else?

Yes, that would write to a file called "command". So the correct way to write that would be:

    command > file

https://www.gnu.org/software/bash/manual/html_node/Redirecti...

That would execute the command `file` and put the output into the file `command`.

Oh, now I re-read it - of course! Hah.

Is `<file` shorthand for `cat file`, or is that only true when used in a sub-shell?

I guess it's equivalent to `: <file` i.e. hooking up the stdin of the no-op command.

Doesn't seem to be the case. For example, `< file cat` shows the file, whereas `: < file cat` or `: < file | cat` does nothing.

Not sure what's surprising you in those snippets. `:` itself is a command and it does nothing with its arguments or stdin.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

I know. The only thing surprising me is your previous claim that `< file` is equivalent to `: < file`.

My interpretation of sgarland's question was that he meant `<file` being the entirety of the statement, i.e. typing only that at a shell prompt and pressing return.

Ah. Now I understand where the misunderstanding was. It confused me that we were talking about redirection as a replacement for useless use of cat.

Yep I can appreciate the misunderstanding. For completeness of the discussion, I think where sgarland mentioned a sub-shell, he was possibly referencing the Bashism `$(<` detailed on this page https://www.gnu.org/software/bash/manual/html_node/Command-S... in addition to what I called a "statement" above.

Correct, that’s what I had in mind.

No, `< file command` is completely equivalent to `command < file`.

In that fun way that shells are, for bare redirection it depends.

In bash/ksh, it matches frou_dh's explanation. In zsh, it depends on how you've set the various *NULLCMD options and parameters. In csh, it is an error.

Even in zsh, when configured to behave like `cat file` it still doesn't quite do that as it won't concatenate files as it only passes the first shell word following the `<` to `cat`(or whatever you've set NULLCMD to). Guess that means you could be evil by making a wrapper that allows weird Unicode separators to pass multiple files in one word ;)

Because I hate myself I guess, I use zsh as my interactive shell, but generally write scripts for bash. The latter is mostly for portability (although with Macs stuck on 3.2 unless updated manually, that’s less true over time), and also because shellcheck doesn’t work on zsh.

This means I get to remember an increasingly unfortunate amount of differences. I’ll add this one to the pile, thanks.

I've mentioned this in previous posts here, but I write zsh scripts utilising all the extras that zsh gives(alternate form syntax, extensive extended globbing, zsh module support for extra functionality). It sounds stupid but it makes it really obvious that what you're writing isn't a generic shell script, and you can forgo having to think too much about whether something will work in modern bash, or MacOS pre-GPL3 bash, or {b,d,k,z}ash as /bin/sh symlink.

I definitely get the argument about shellcheck though, it would be nice if it supported zsh.

That’s fair. I wrote a script at work recently for zsh that relied on some of its niceties, like glob qualifiers. The reason for using zsh was we only use Macs, so it was reasonable to assume everyone would have a decently modern version of zsh available.

It definitely looks foreign, but then, so does parameter substitution in bash or zsh. There are shell scripts, and then there are those that make you break out the man pages to figure out what they’re doing.

I'll often commit 'useless use of cat' there for three reasons:

1) Muscle memory

2) Often when I don't I end up needing two files later

3) It annoys merlyn (Randal Schwartz)

Yeah, Smalltalk also works this way...mostly.

  3 negated + 2 negated.

Alas, as with the post, this also breaks down when you have more than 2 arguments (or in Smalltalk parlance, 1 argument in addition to the message receiver), as those are handled by keyword arguments and you can't tell where the keywords for one message stop and the ones for the next one start. Let's say we have some nested arrays, which are accessed with at: in Smalltalk:

   array at:4 at:2 at:1.

Alas, that doesn't get interpreted as 3 messages, but as the single message at:at:at:. As it kind of has to be as there is no way to disambiguate. Surprisingly, Smalltalk does have a way to chain messages and thus separate the keywords, the semicolon:

   array at:4;
         at:2;
         at:1.

Alas, this sends the subsequent messages to the original receiver, so it is equivalent to:

   array at:4.
   array at:2.
   array at:1.

(And so this example doesn't actually make sense, it's just a syntax example). So what you have to do is add parens:

   ((array at:4) at:2) at:1.

Hmm, not nice. For Objective-S (https://objective.st), I introduced the pipe for message chaining:

   array at:4 | at:2 | at:1.

One way of looking at this is as a syntactic device that allows left-to-right typing without backtracking, which it is. And that is both nice to write and quite readable, IMNSHO.

A second way of looking at it is as a version of the pipe/filter architectural style, with each message expression being a filter, the results from the filter on the left piped into the filter on the right as the receiver. This is a little bit like |> in some FP languages. But really only a little bit, because in Objective-S this is not the whole story, but just a way of integrating messaging into the way the pipe/filter architectural style is supported at the language level.

The syntax reads similar to R with pipes