All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

Well, what do I think a scripting language is? Despite my earlier assertion that I'm not really going to pay attention to any debates on the topic because truth be told, they bore me to hell, the fact is that I still have a mental model of what a scripting language is. That's a language which is suitable for writing smaller "glue" bits of code, but not larger systems.

We're re-watching Coupling season one at the moment (the real one, from the BBC), and all of this reminds me of Jane's pronouncement: "There's no such thing as homophobes. Only peoplephobes!" Debating whether or not "scripting languages" exist is about as silly.

The best description of what a scripting language is comes from Ousterhout, who coined the term. Why? Because coding comes down to two predominant modes: building modules, and connecting them. This may sound like a false dichotomy, but it turns out that it isn't. r0ml talked about this in his talk Failing
to Succeed [oreillynet.com] (slides [oreillynet.com]).
Like most of his talks, it was brilliant, wide ranging, entertaining, informative, involved his standard red clown nose prop, and impossible to summarize or remember fully.

One of the big points he made was in evaluating the cost of change in a codebase. There's a good
paper [mit.edu] he cites that analyzes the open source vs proprietary methodologies for software development (using the Linux kernel and the 1998 "Free the Lizard" Mozilla codebase as proxies), and manages to quantifiy the "modularity" of both codebases. As an extra experiment, the paper also analyzes the "modularity" of the Mozilla codebase before and after The Great Rewrite. (Which, in hindsight, disproves Joel's dictum to Never Rewrite Code.)

r0ml also made a few additional points, including the strong corollation between low modularity (tight cohesion) and high cost to change. The first way to reduce cost is to increase modularity (separate subsystems from each other). The next step is to make modular subsystems into standalone components (libxml, mysql, libpng, etc.), and glue them together into with some kind of "scripting language". Each component is general, well tested, and clearly defined. The sum of them as an application is similarly easy to understand.

But without discipline, application code can migrate away from components into glue code, so that most of the application is written as glue. That approach has different cost structure; moving application logic into glue code makes it *more* expensive to change. This could possibly be because each line of glue code is more expressive, so the cost to change is consequently multiplied. (At least that's how I remember r0ml describing it; I don't have the source handy.)

I don't think that r0ml's point is that glue code (scripting languages) are necessarily *bad*, just that it has a different impact on the project, and it's important to find the right balance among all of the competing factors. Gluing everything together in C is obviously bad, because without a constant effort to modularize, it leads to tight cohesion. Writing everything as glue is a similar problem, presumably because there's no clear distinction of what's a component and what's glue.

How should we interpret this with Perl? Well, it obviously has glue-like characteristics. Just look at any one page shell script. But it also has "component building nature" as well. The same relative high change cost probably still exists, if the barriers become fuzzy, and it's unclear where the modules end and where the glue begins.

Admittedly this is subjective, but a scripting language is to a "real" language as erotica is to pornography: I know it when I see it (further research is needed in this area).

No, it doesn’t. Joel wrote about this in one of his recent weblog posts, but I would have said the same thing even before he opined on this precise issue.

Joel’s dictum is not to forever keep the code you have – it’s to never throw it all away to start from scratch. Couldn’t Mozilla have improved their codebase one module at a time? Did they need to junk the rendering engine and the UI library and the