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 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.

You misunderstand. I didnt need an explanation of how they worked. Im refuting that they are a good practice.

I was complaining of the "cleverness" of them, when working or analyzing a codebase with people swapping from if/else loops to trinaries.

I prefer clarity and a bit more verbosity than a per5-ism. If that means a 5 line loop that I can easily follow, then so be it. 1 liners that effectively say "lookie at me im a l33t developer" are a very bad code smell, and make maintenance harder each cycle of more cleverness.

Trinary expressions are supported in a lot of languages. I actually agree with your point about "clever" code but I don't think trinary expressions are clever. They are quite normal and fairly common.

And every language has its idioms that are incomprehensible until you learn them. This isn't clever code so much as shorthand for common things.

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

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.

> 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.

There are many programs that aren't applications. For example, databases. You wouldn't argue that because you can program in eg. SQL it should be able to make applications with a robust command-line interface, right? Same idea applies to system Shell. Its purpose is to expose the operating system functionality interactively and for ad hoc automation. It is deliberately made simple and therefore incapable of more advanced system programming because complexity creates problems in this particular domain.

For instance, consider that Unix Shell only has one data-type: strings. I believe this was a deliberate decision by its creators (or a stroke of luck). Compare this to languages s.a. original JavaScript with a handful of built-in types, or, even worse, modern JavaScript with user-defined types. Even though the language tries hard to supply default "solutions" to type mismatch errors, it doesn't work well, and sometimes, at all. Unix Shell is inherently incapable of type errors.

While in statically checked programs, or even dynamically checked ones with robust debugging tools types could prevent certain kinds of programming errors, in the mostly interactive programs types make no sense. There simply isn't enough code to generate the kinds of problems types are supposed to solve.

> Minimalism isn't why posix shell syntax is bad.

I never said that.

> Powershell was never designed to be your system shell

Parent wants to replace Linux system shell with PowerShell, that was the reason I replied in the way I did.

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