As a UNIX systems administrator, I’ve picked up bits and pieces of probably a dozen different programming languages. I try to avoid the programming-language-elitism that I see in other system administrators:
- “If it can’t be done in <XYZ programming language>, it isn’t worth doing!” (Where XYZ mostly == C)
- “<XYZ programming language> sucks!” (Where XYZ mostly == Java)
I’m most well versed (I won’t say “skilled”) in Perl and Bourne shell. But some times, another language that I’m not so used to is simply a better tool for the job at hand. So how do I decide which one to use? I have a few guidelines:
- For quick-and-dirty one-timers, I usually use Bash + sed + awk. I have talked about awk before, but I prefer not to dig any more deeply into it that I have discussed before.
- Solaris start-up scripts force you to use old-school Bourne shell. Bash won’t work here due to the way Solaris executes it’s startup scripts:
for i in script1 script2 ...
do
/bin/sh $i start
done
- Anything that requires arithmetic, processing more than one input parameter, or almost any kind of string comparison, usually gets an automatic upgrade to Perl.
- Interacting with applications in OS X requires AppleScript
- Interacting with Solaris/UNIX system libraries obviously requires C. Even though I’m not very good at C yet, some times it is actually quicker for me to get things done with it than with Perl, due simply to the fact that I can call C libraries that I know are already on the system. Solaris has been shipping with Perl since at least version 8, but some modules that I might be tempted to use are only available from CPAN, and thus are not installed on all of my systems.
- Any thing that needs to run fast is normally C.
- Most any thing that needs to be written fast is normally Perl when I have a choice.
- String processing/manipulation is abysmal in C, and I prefer using Perl.
- Ocassionally, I have been known to resort to doing very demented things like writing Perl code that does nothing except output Bourne-Shell code.
- Data structures in Perl are abysmal, so anything more complex than a simple array or a hash, I usually revert to C, even if it is more painful to write, it is easier for me to understand.
- Most any thing that I’m forced to write for Windows is done in Visual Basic Scripting Edition. I prefer not having to do this, and avoid it when possible.
- Simple web applications might get Perl. Lately, they’re Ruby-on-Rails, which I love.
- I try to avoid building GUI programs on UNIX when possible. I’ve use Perl-Tk before. I like the look of KDE applications, but since KDE isn’t reliably available on all of my Solaris systems, this isn’t usually a good choice. Writing directly for the X Windows protocol isn’t a good idea. Ever.Generally, I try to make things into web applications to avoid writing UNIX GUIs.
- GUI programs for OS X can be AppleScript or Objective C/Cocoa. Since I know the Cocoa framework is always there, it eliminates the problems normally associated with GUI programming under UNIX. If only Sun would adopt Apple’s GUI, running on top of a Solaris core, I’d be happy.
- If the problem is well-suited to an object oriented solution (not all of them are, contrary to what CIS students learn at University these days), I might use Ruby for fast written programs and C++ for fast running ones. I know how to spell Java, and I’m quite fond of the coffee from there, but I don’t know much else.
- SPARCv9 Assembler: If it can’t be done in SPARCv9 Assembler… Oh who am I kidding…

