An enduring aspect of the various academic IT-related jobs I have had over the years has been the ongoing and seemingly endless debate about the merits of the Perl and Java programming languages, with strong adherents on both sides. Perl in many ways is seen by some people (not just software engineers) as a poor contender in this debate – Java is more ubiquitous and widely-used after all, certainly outside academia. But Perl has been around for longer than Java and refuses to go away.
In my view, a software engineer should not see themselves as entrenched on any side of this debate. They should never subscribe slavishly to a particular development methodology, ideology or programming language. All too often I see software engineers describing themselves (or being pigeonholed by non-software engineers) as ‘Java programmers’ or ‘Perl programmers’. A good software engineer should only subscribe to what works.
And what works in any given situation changes. There seems to be a lot of argument about whether Java or Perl is the better language, but the mistake is to see this as an either/or argument. Both Java and Perl have their place, and a good software engineer should be proficient in both.
Java is a good language to use when a particular software development project involves multiple programmers and has web-based components. If a development model requires something like an MVC or similar multiple-tier architecture, then it makes sense to use Java for this. Java is good for larger scale projects that require distributed and reusable code components, and a sophisticated GUI (I haven’t mentioned performance issues, in which case C may perhaps be the language of choice).
Perl is a good language for developing web-based applications also, but those that are simpler and of a smaller scale. It also excels at implementing the myriad small server-side tasks that are always required in a web-based software application such as file manipulation and Unix-style cron jobs. An informal but accurate description of Perl is as a ‘housekeeping glue’ language – it is good for integrating components in an application so that they work together and for tidying up all the various data flows that form an inevitable part of any functioning application. It is good for enabling M2M communication between software components that are distributed on different hardware platforms.
Many software engineering tasks are often relatively small-scale (right down to one software engineer building something that requires one day of writing code), and Perl is the right choice of language for these tasks, with its interpreted ‘scripting‘ model and low overhead libraries/modules enabling very quick development cycles. Perl is a good choice of language for developing dynamic websites that offer a basic read-only interface to a database and the ability to process CGI parameters from HTML forms. Whilst it’s all the data-heavy applications with enormous concurrent user requirements (like say, eBay) that get all the hype and media attention, a huge number of development projects fall into this smaller-scale category – using Java for them is like using a Boeing 747 to travel the 45 miles between Edinburgh and Glasgow. There are also other languages like Python, PHP and TCL that can be thought of as fulfilling the same sort of lightweight and smaller-scale roles as Perl, in this comparison to Java.
The point is, the choice of programming language should be dependent on the architecture model used to define the design of an application – which should of course come before particular technologies are chosen to implement the application, whether that technology is a software language, OS platform, presentation method, database or whatever. See my previous posting ‘When Java goes wrong‘ for an example of what happens when this is done the wrong way round.
Java and Perl can be viewed not as rivals, but as complementing each other. Neither one of them is adequately multipurpose enough for a software engineer to use in a job description label. As I mentioned at the start of this posting, a software engineer should use software that works, not software that fits in with what they might have used previously or that others expect them to use.