Before I even start: I will use scripting (probably with Perl) any time to get a job done – if the job is suitable for scripting. Now you may read on
I recently read an IEEE Computer Society article “In Praise of Scripting”. Having been a big Perl fan who ran into big problems with a not even sooo big Perl project I have a comment or two on the article.
In the article (and elsewhere) scripting is displayed as the method of choice for free, creative spirits who develop the groundbreaking, innovative (web) software of tomorrow while the use of compilers with strict typing is the tool of narrow-minded syntax-watchdogs who develop unremarkable applications by committee.
I beg to differ, having used Perl heavily for about seven years between 1993 and 2000. Perl does an incredible job when a single programmer has to interpret text files and transform data. This is the kind of job I still often use it for today.
But scripting languages like Perl can be a big problem when a team has to create a really large application with complex data structures and elaborate functionality. During the dot com boom a lot of very successful software was written in Perl. What people might not realize is that maintaining and extending these applications was a nightmare, and I know people who quit their job because they could not get away from having to install and maintain these contraptions.
Perl is excellent for many things including shooting your own foot. Neat features can produce obscure errors that are very hard to find. In example, variables don’t need to be declared, and have no type. Of cause it is nice that a variable just springs into existence when you need it (less typing, in example). Or that you don’t have to care about conversions from strings to numbers and the other way round. Or that complex data structures can be created, extended, and modified on the fly because associative arrays give you all that.
On the other hand, what if you misspelled a variable name? Or the second parameter of a function was supposed to be the forename of a customer, not the year of his birth? Your program will produce odd results but no error. And you then painfully realize, too, that there is no IDE such as Eclipse to help you track down the mistake you made. The compiler won’t help you either, because a = b + c is fine for it whether b and c are strings, numbers, or a combination of the two.
Some find it nice that Perl allows you to program in a number of different styles. You can make the code look like C or Java, or more like Visual Basic. There are a number of constructs that don’t exist in other languages that allow you to express yourself even more concise, such as “…unless”.
But since these constructs do not exist in other languages, people not familiar with Perl have a hard time understanding what is going on intuitively, and some constructs are just not very intuitive (“do this, this, and this – unless something is so and so” – you first follow that “this and that” will be done, but – surprise! – not under the following condition). Different styles, non-intuitive and surprising developments are great in a book or movie, but not in source code.
This article obviously is not exhausting the subject; I’ll give it a shot another time.