Rewriting the language
Not Perl, mind you, I'm not in that area (yet?). But some key terms I keep hear buzzing around, and, in the tradition of starting the Christmas season in late July, I'll begin my Festivus preparation with some minor Airing of Grievances.
- X Driven Development
- Considered Harmful
Brain child of the people behind Extreme Programming (mainly Kent Beck), this blew up into a big snowclone, as every minute variant of "how we do things" can immediately shovelled under a "X driven development" headline.
For example, you start the development process by writing a design doc? Design Driven Development.
You create a list of features? Feature Driven Development.
How about compiling a list of tickets, requests and bugs in a tracker? Bug Driven Development.
You write the interface first? API Driven Development (Probably better abbreviated APIDD)
I say: enough. Whatever methodology you use to "drive" your development, you'll still end up writing source code, compiling, running, QAing it, judging it according to whatever spec you initially (or ultimately, or medianly) wrote. The work is the same, the result is the same. You can name it however you like. Call it "Development Driven Development" for all I care, it doesn't matter, and only stops cross-pollination of ideas seeing as "your" X Driven Development isn't "my" XDD.
And while on the subject of snowclones,
Right. So there's this guy, Edsger W. Dijkstra, who once wanted to urge programmers to use a more structured, procedural methodology, rather than use Goto's. He wrote an article "The case against the Goto statement" and sent it to ACM magazine. The editor, another guy called Niklaus Wirth, renamed it, using an established phrase used by editors to "alert readers that the writer is going to be expressing negative opinions about X" (Language Log, CONSIDERED HARMFUL).
Fortunately, the argument stuck. Goto is now reviled among programmers, if only for its reputation. Unfortunately, the headline also stuck, and is now one of the most abused terms in programming (and technical) blogging. And for a good reason. It's catchy. It's well known. It has an authoritative air to it. Programmers have, by now, conditioned to consider the term a definite argument, in the same vein that "best practices" are usually considered "laws" rather than "sensible suggestions". It definitely sounds much better than "Why I think this idea isn't good" (or, heavens forbid, "The Case against ...").
It should cease to exist. Nothing in programming is definite. There is no single element that is either a silver bullet or the Antichrist. It cheapens the argument, Glenn Beck style, by reducing it to a war of slogans. (see also Eric Meyers' "Considered Harmful" Essays Considered Harmful).
Dijkstra himself, in later articles and speeches, have shown he learned the lesson Wirth taught him, and substituted well described arguments with a short, catchy, provocative one-liners, such as calling FORTRAN "the infantile disorder", and arguing that "[COBOL] teaching should ... be regarded as a criminal offence." ("How do we tell truths that might hurt?"
On a different matter, I've written before on the perceived importance of nomenclature, at least for marketing reasons, and this one's a biggie, and not just for Perl. Common interpretation of the abbreviation place it as "Linux, Apache, MySQL, and PHP", and while you can claim that it could also mean Perl, or Python, this is what is commonly known as.
I take a cue from Jeff Waugh, who jokingly suggested that LAMP should mean "Linux, Apache, Most of our cool scripting languages start with P, PostgreSQL" (What does LAMP stand for?), and suggest we now re-explain LAMP to *actually* mean: Linux, Apache, Modern-perl, and a Persistence layer (to each his own).