garethrowlands

well duh

It's really not that simple. Yaml can be more token efficient but not necessarily. And it's often not the biggest factor.

I totally agree with you.

> the goodness of language for long code is inversely proportional to how nice it is for shell one-liners

Well, except for this bit. Oil or fish and awk are perfectly fine for one liners but don't repeat the mistakes of posix shell syntax.

Yeah, I don't see pwsh finding a place in the ecosystem. Even oil or fish struggle. Their place was mostly taken by python (which is a huge dependency but not another huge dependency).

I like your 2026 perspective. Objectively, the posix shell syntax is genuinely bad, even though the overall system that it enabled is amazing. It's a very old system that took off because it solved a problem - history is kind to it because of that context. Though, awk is around the same age and provides a proof-by-existence that posix shell syntax didn't have to be make these mistakes.

The trinary is semantically just an if expression though. Perl inherits C's problem that `if` can't be used in an expression context:

  my $x = if ($cond) { 1 } else { 2 };  # Syntax error

Because of this, Perl introduces a second syntax to plug the gap:

  my $x = $cond ? 1 : 2;

That expression is neither obtuse nor hard to read.

Something like the code below is hard to read:

  my $fee =
    $is_member
        ? ($is_student ? $student_member_fee : $member_fee)
        : ($is_student ? $student_fee        : $standard_fee);

It's equivalent to the following code that uses `if`:

  my $fee;
  if ($is_member) {
      if ($is_student) {
          $fee = $student_member_fee;
      }
      else {
          $fee = $member_fee;
      }
  }
  else {
      if ($is_student) {
          $fee = $student_fee;
      }
      else {
          $fee = $standard_fee;
      }
  }

But ideally you would want to write this:

  my $fee =
    if ($is_member) {
        if ($is_student) {
            $student_member_fee
        }
        else {
            $member_fee
        }
    }
    else {
        if ($is_student) {
            $student_fee
        }
        else {
            $standard_fee
        }
    };

Though, of course, perl5 doesn't allow that.

Absolutely!

Your company likely started using bash before python was ubiquitous.

I still think that learning the shell environment makes a lot of sense these days. But mainly for interactive use. It's amazing the scripts your LLM can make you with, say, fd and fzf.

Heh, I like that. We are indeed stuck with posix shell syntax; I didn't claim we weren't.

There are plenty of alternative shells that don't suffer these problems. Posix syntax didn't win because it was better - it's the classic 'worse is better'.

> Old doesn't imply arcane.

Indeed so. For example, awk is about the same age but doesn't suffer the same problems.

> the shell syntax was never meant to be anything like a systems or application programming language

A programmable shell is not only like a programming language, it is a programming language. Systems tasks have some specialised requirements but, overall, scripting is programming. There is nothing in the problem domain that requires the posix string-substitution problems.

If fish or oil had existed back then, they would likely have won, since they are better.

Sorry, the backticks were merely meant to delimit the code.

Some models are better than others. But it's all fixable with a relatively small skill. Try PowerShell Windows Skill perhaps.

$ Hey, claude, I've figured out the powershell one-liner we need and I've pasted it below. Please insert it into the application.

...

I have analysed your idiomatic one-liner and propose adding the following 30 lines into the application Yes/Yes and always accept such idiocy/No

ESCAPE ESCAPE

/clear

I want to update my powershell skill so that it writes idiomatic pipelines and does not introduce idioms from other languages.

[PASTES overeagerness wording from Claude prompting best practices]

I have some absolutely amazing bash scripts that I would never have contemplated making myself in bash. And they'd only have been somewhat better in python. Claude for the win!

> System shell, however, isn't meant for writing entire applications.

Programmable shells are, in fact, for programming. That posix shell syntax makes it impractical for meaningfully large scripts is something you just accept. And, realistically, it is something you have to accept.

Minimalism isn't why posix shell syntax is bad. For example, awk and jq are minimal but don't make the same mistakes.

Powershell was never designed to be your system shell (Windows doesn't really rely on one) but the main reason it can't be the shell is startup time, which rules it out of wrapper scripts. Its having lots of features might contribute to that but it's not the problem per se (being built on .net is the reason - that and startup time not really mattering on windows). Its lacking the syntax problems of posix shells is very much not a problem. Powershell's error handling is just fine, by the way.

The startup time of even pwsh is too slow to be usable in many scenarios.

PowerShell's not going to be the system shell on your *nix box but it wasn't designed to be. But your posix shell isn't the system shell because it's better. It's pretty much the ultimate expression of worse is better.

That's why there's an industry of alternatives without the faults, such as oil, elvish, fish, nushell. And why awk is so popular.

The only upside of weird bash tricks is there's so much bash out there that the LLMs are really well trained on it - so you won't have to read the script, just the tests.

Articles like this are fun but they all come from posix shell syntax being fundamentally bad for scripting/programming. All the piping stuff is great, of course. And the overall ecosystem is great. But the interpretation of the script itself working by a series of string substitutions is a mechanism we wouldn't accept in a regular programming language. And there's no excuse for it really, except that shell syntax is really, really old.

For example, what does `$foo` mean in shell syntax? In any reasonable language (perl or powershell, for example, or python if you drop the `$`), it's an expression that evaluates to whatever value's inside that variable. In shell, `$foo` isn't an expression in that sense, and what it does depends on what's inside it via a variety of string substitution rules.

This is the main reason we have arcane articles like this.

That said, nice article.

The number one hard working concept in Haskell is parameterisation. A typical Haskell concept is just a concept, not a Haskell concept.

That map doesn't seem to include the trees in actual parks. Somewhere like Hampstead Heath or Richmond Park has actual woods.

That's awesome. Though, it doesn't seem to think Hampstead Heath has any trees. Nor Croydon, not even Thornton Heath. The Wilderness in Richmond Park seems to be a missing spot, as are some of the plantations (maybe Isabella Plantation, my map fu is failing me). Maybe the royal parks keep their own records?

Citation needed.

STM isn't really used in Go like it is in Haskell.

Here's the example from a Go STM package that's based on Haskell STM. It has gotchas that you won't encounter in Haskell though, due to the nature of these languages.

https://github.com/anacrolix/stm/blob/master/cmd/santa-examp...

For the equivalent Haskell, check out the link at the top of the file.

It's very good. And quite short!

XSLT's matching rules allow a 'push' style of transform that's really neat. But you can actually do that with any programming language such as Javascript.

I used to use XSLT a lot, though it was a while ago.

You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code.

Do you have a particular example where you think Javascript might be more verbose than XSLT?

The term 'variable' is from mathematics. As others have said, the values of variables do vary but they do not mutate.

One way to get some intuition with FCIS is to write some Haskell.

Because Haskell programs pretty much have to be FCIS or they won't compile.

How it plays out is...

1. A Haskell program executes side effects (known as `IO` in Haskell). The type of the `main` program is `IO ()`, meaning it does some IO and doesn't return a value - a program is not a function

2. A Haskell program (code with type `IO`) can call functions. But since functions are pure in Haskell, they can't call code in `IO`.

3. This doesn't actually restrict what you can do but it does influence how you write your code. There are a variety of patterns that weren't well understood until the 1990s or later that enable it. For example, a pure Haskell function can calculate an effectful program to execute. Or it can map a pure function in a side-effecting context. Or it can pipe pure values to a side-effecting stream.

Surely transactions are a pretty good example of where functional core / imperative shell is a good guide. You really don't want to be doing arbitrary side effects inside your transaction because those can't be backed out. Check out STM in Haskell for a good example.

I'm unclear what you're suggesting here. Are you suggesting you couldn't write a POS in Haskell, say?

> Indeed, the general idea of imperative assembly comes to mind as the ultimate "core" for most software.

That's not what functional core, imperative shell means though. It's a given that CPUs aren't functional. The advice is for people programming in languages that have expressions - ruby, in the case of the original talk. The functional paradigm mostly assumes automatic memory management.