One of our software languages is missing

A major computer language is missing. Not missing in the sense of having disappeared but missing in the sense of never having been there. Despite there being hundreds of computer languages, many of them domain specific, there is no computer language to aid support and configuration.

That might seem like something trivial. Does there really need to be a language created just to, say, configure a printer once the driver is installed? Take one look at the most common tickets raised in any support database and you’ll know the answer.

So, given that just about everything you want to do in the way of configuration on Windows is possible using VBScript, you might think that it’s the obvious answer. But what if you want to configure a couple of group printers on an XP desktop, a Windows 7 laptop, an old Windows Server 2000 machine and a Windows Server 2008 box? Are you sure that they all use the same API?

Then comes the bigger horror. What about all those Sun boxes in the server room running Oracle? VBScript won’t run on it so the printers have to be configured manually unless someone writes a shell script.

What if you want to put a Linux box somewhere in the business? Most support teams will be all for it. Unless they have to support it. They may be geeks in support but that’s no guarantee that anyone there has ever touched Linux. If they have, they’ll be wary enough to start asking questions about which distro and which GUI for starters.

That’s just for printers. Check with any support team and you’ll discover that most of their day is spent on configuration problems. They can talk a user through half of the Control Panel settings with their eyes closed. Many larger companies even produce their own Windows installation disks so that all of the major configuration has been done. Where the proxy server resides, the local name server, the group printers, the AD server, mapped network drives and so on.

And heaven help you if some salesman comes along and convinces the directors to buy something like PolyServe. Suddenly any desktop software that has a T-SQL database backend will need to be reconfigured to point at the bigwigs’ new white elephant.

The worst thing is that someone has to know how to do all of these things for all different kinds of machine. It has to be documented. The documentation has to be kept up to date. And it almost never is.

So here’s a little proposal for anyone who wants to get on with it because they’re fed up of waiting for Microsoft, Apple, Sun and the rest of the industry to get off their butts.

The support language needs to be simple. People in support aren’t programmers. It needs to be easy to read, easy to understand and easy to maintain. If you think C-style syntax is the best, you’re not the person for this job. Think along the lines of Basic, Python or Rexx. But simpler.

Obviously the language needs to be cross-platform. A Windows-only support language would be an improvement on what’s there at the moment but Microsoft hasn’t even managed that properly with VBScript let alone the embarrassing PowerShell scripting. The ideal will be when you can schedule an AV scan remotely for every machine in an enterprise that has AV. Where adding a new printer for 200 users is as simple as publishing one small script that works on pretty much any version of any OS.

There are some tough questions too. Should the language be able to update drivers on a machine? Should it allow the running of executables? What about changing the IP of the DNS? VBScript used to be a favourite of virus writers because it was so easy and flexible, somehow the new language will need to avoid that trap.

The graphics world has had OpenGL for nearly twenty years. The parallel processing gurus have OpenCL. The poor blighters in support have been helping people for longer than either of those areas of computing even existed so isn’t it about time they got a language to make their life easier too?