Or, more specifically, why sysadmins like programs written in interpreted languages. I say this because we do; it is one reason for the enduring popularity of writing things in the Bourne shell, because in a sense the Bourne shell is the platonic ideal of an interpreted language on Unix systems.

Here's why I at least really like such programs:

• you don't need a different copy for every different sort of system that you have, because
• you don't have to compile your programs.
• thus there is no bootstrapping required on new systems; you can simply grab a copy of the program and run.
• also, that means that you don't have to keep the source somewhere; the program is the source and can't get lost.

Strictly speaking, some of these aren't advantages of writing in interpreted languages, they're advantages of using self-contained programs. You can certainly write large programs in interpreted languages that require being installed before they can run (and that have large lists of fragile dependencies).

(However, some language environments make it easy to skip the installation step, at least on a temporary basis, with features such as search paths that include the current directory by default. And these days any sensible system should make copying over a directory as easy as copying over a file, because everyone should ship with a version of rsync, right? Yes, I'm looking at you, Sun.)

This also explains why I would generally rather use a hacked together and limited shell script than a much nicer C program; the shell script is a lot less hassle for casual use.

Sidebar: the source code advantage (again)

Take it from me: the last advantage is a big one. When the program is its own source, not only can it never get lost but there is never any question about which version of the source was used to build the binary (and with what compile options and so on).

(And let's not get started about old source that won't build in a modern environment, leaving you with a bunch of work to do if the old binaries stop working someday.)

This isn't to say that interpreted languages make portability issues go away entirely; of course they don't (and sometimes shell scripts make it worse). But they at least make it obvious, because your program blows up right away.

(The more technical way to put it is that with interpreted programs, you don't have any difference between source compatibility and binary compatibility. Compiled programs can preserve binary compatibility while breaking source compatibility.)