Several of my respected friends/colleagues view Perl, PHP and the ilk as great -- for "fast" jobs. We've had experiences with these scripting languages that make us tend away from them for "serious" work. We all like scripting, but we don't want to be stuck hacking on the same scripts for several months.
What does "fast" or "serious" mean? Some of the problems we've had with scripting include --
- Difficulty finding bugs. These languages are flexible -- very flexible. Logical and even syntax bugs can be difficult to find because simple mistakes in assumptions have to be checked by the programmer everywhere.
- Difficulty reading the code. Perl is like "interpreted line noise", according to jcv one of my friends. In Paul Graham's essay Hackers and Painters, he also notes this phenomenon:Many a hacker has written a program only to find on returning to it six months later that he has no idea how it works. I know several people who've sworn off Perl after such experiences.
- Inconsistent language/library design PHP, for example, seemed to be a mish-mash of useful routines, each with its own special calling conventions and partial documentation.
It's as if we have a love/hate relationship with scripting languages. They're great -- until you have to start maintaining them. "All programming is maintenance programming."
Maintenance becomes a problem with scripting languages because I can't fit the entire system into my head. I don't remember all of the rules and assumptions that are intrinsic to my application. (I'm speaking mostly of the gnarly vertical-market business applications here.) I'm crafting new software, yes; and I need to be able to change it rapidly -- therefore, I need system support to keep me in the sandbox of my application.
But Tim O'Reilly's comments on Why Scripting Languages Matter run at variance to this:The reason why dynamic languages like Perl, Python, and PHP are so important is key to understanding the paradigm shift. Unlike applications from the previous paradigm, web applications are not released in one to three year cycles. They are updated every day, sometimes every hour. Rather than being finished paintings, they are sketches, continually being redrawn in response to new data.
I'll buy this comment about rapidly-changing applications -- but I don't understand why scripting languages are perceived as being more suitable for this.
Indeed, to make changes rapidly, you need a system helping you find when you've violated assumptions -- this is why agile programming methods are often associated with testing. And this is why we need strong language support for limiting the behavior of a system -- especially for rapidly-changing applications.
I haven't found this kind of support in scripting languages, by and large. But what attracts us to scripting languages in the first place? Maybe it's the fact that we don't have to define a class and stick a method in it just to do a simple job. This suggests that it's the lack of system support for constraint validation that attracts us to scripting.