Agile SysAdmin

In an ideal world, your whole IT department will make a policy decision to pick one scripting language and stick to it. Sadly this does mean that the advocates of other languages will “lose” the argument and be prevented from using their most comfortable language.

However, the benefits of a consistent policy should be obvious - people can switch between teams without a huge learning curve; there is more incentive to invest time in learning the language properly; no one creates a legacy of code only they can support; and it’s less likely that someone ends up maintaining code in a language they hardly understand. It also means you can concentrate the support effort: creating templates, building shared modules, etc.

Some points to look for in a language:

• Rapid development is essential, i.e. a high-level language with rich functionality
• The ability to extend it by creating shared modules/libraries/classes
• The existence of plenty of add-ins already available (e.g. CPAN for Perl)
• Suitable for your domain, i.e. available on every OS you use, will work with your RDBMS and webservers, appropriate for your usage.
• Can integrate to your existing codebase (vendor libraries etc).
• Quick to do the basics - if you want to replace a procedure with half-a-dozen commands, it should not take all afternoon to script.
• Scales to write larger more complex scripts & applications.
• Reasonably easy to learn
• Practised widely enough to be easy to hire for in your local talent pool

It may well be that these are not all compatible in one language and you decide to support more than one, e.g. if you have a vendor product where you need to access APIs in Java or .NET. You have to choose your compromise, but try to make the rules clear, to avoid Tom, Dick and Harriet each writing new code in the language they just happen to have grown up with. The reason there are “religious wars” about which is the best language is that most of the time there’s very little to choose apart from personal preferences.

Generally, avoid languages with a compile step - C of course, but also Java and C# - it adds too much time to the turnaround. (These are all fine languages, just not for scripts.)

Some possibilities are:

• Perl: older than most, a love-it-or-hate-it option for many people. Huge range of modules available on CPAN. Very powerful, fast for a scripting language, and there’s a lot of it about. Built into almost all *ix systems these days, and also available for Windows (and just about any other platform)
• Ruby and Python: each have their advocates. Not quite as many modules around as CPAN, but still perfectly adequate. Run on most platforms, but you may have to install them yourself.
• PHP: usually thought of as a web-scripting language, but can be used for general-purpose work. Might make sense if you have a lot of web interfaces and want to use just one language.
• Unix shells: ksh and bash are fine for a few lines, particularly if you’re just copying files around and so on. But if you find yourself stringing together long chunks of sed commands, it might be time to switch! I’d advise against csh these days, it seems to be a minority sport; zsh will emphasise your alpha-geek status, but isn’t widely known.
• JVM or .NET based: there are now several languages designed to have the characteristics of dynamic languages but run in the JVM or .NET.  These can call out to existing Java/.NET classes, ideal for accessing an application API or where you already have a large codebase. JVM options include: Jython, JRuby, and Groovy. Similar options in the .NET world include IronPython and IronRuby.
• PowerShell: An interesting new tool from Microsoft, which will soon be almost unavoidable in the MS world. Learning curve is supposedly simple once you’ve “grokked” the new object-based paradigm. Currently slow, but v2 may fix that. Windows-only of course. This is another .NET-based language, allowing you to use .NET objects, e.g. your C# code or vendor APIs.

This entry was posted on Sunday, March 15th, 2009 at 01:02 am and is filed under Best practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.