[Goladus]

I fail to see how Perl-golf style conciseness is inherently more "productive" (particularly when it makes it harder to understand and maintain operationally important software).

I'm not sure the author made a great case, but it does matter. Unix admins often think in terms of lines, because lines are the default unit of action. No matter how much planning and cfengining you do, there are still times when an admin must take direct action on a system. When that happens, they use the interactive command lines. These lines often aren't repeated frequently and have no need to be stored in any file other than .bash_history, and therefore do not need to be read or maintained. In those situations, the conceptual and physical overhead incurred by something like 'import re' is most assuredly significant.

[piccadilly]

I can get insanely concise one-liners out of C and shell, but that doesn't make those inherently more-productive languages.

I forget what bash does, but when I write a block of shell in zsh, it is saved as a 'line.' This is a tool issue, not an issue of language expressiveness.

If you can't write concise Python, maybe that's just because you aren't that comfortable with Python... that's a perfectly good reason not to use it but it isn't some sort of dramatic limiting case requiring all system administrators to use Ruby instead.

[Goladus]

I don't use Ruby at all, personally. I use Python and Bash almost exclusively. I use Puppet but am not a huge fan, and I certainly have no plans to switch to ruby. I mostly agree with your original point.

However, the CLI thing is a legitimate advantage in favor of Ruby and Perl. Python is just really annoying to use for system administration one-liners. A number of fundamental design choices that have a minimal impact on even the smallest .py files make 'python -c' cumbersome.

Specifically:

A number of common tasks available as syntax in Perl and Ruby are in libraries in python. In particular, you often need to import sys, os, re, and subprocess. Not a real issue writing scripts, but adds a lot of overhead to a single line.

You can't pass a DEDENT token to '-c', at least I haven't figured it out, meaning you can't use more than one loop or control structure. You can work around this to some extent using list comprehensions.

Python's string literal syntax is more limited. I have never had an issue with this writing scripts, however from the command line it can be annoyingly tricky to keep track of which quote characters are needed. Ruby and Perl both have non-conflicting options for notating string literals. In shell scripts, strings are the default literal and you only need to worry about keywords and special characters.

Another advantage of shell are list literals. (I don't have enough practice to know how Ruby and Perl fare in this regard).

Bash also has some extremely convenient list expansion syntax.

    for fqdn in {www,news}.ycombinator.com ; do echo $fqdn ; done

    python -c "import sys; [sys.stdout.write('%s\n' % fqdn) for fqdn in ['%s.ycombinator.com' % sd for sd in ['www', 'news']]]"

Obviously this particular example could technically be shorter, since I could use for-loop syntax (and in python 3+ print is a function). But I would have to arrange it like this if I needed another nested loop. If you wanted to perform some additional action on the names you might have to import yet another library.

Incidentally, C can be a useful admin tool if you know how to use it, but usually the compile-execute cycle makes it more cumbersome than it's worth for one-offs. A C compiler might not even be available on your production system.