Distance Release Date and nearly a month time, cheap jordans decided it was time nike lebron 10 for the launch of the engraved version of the retro jordans invasion sneakers fans wallet.

Perl: Old and crufty?

I hear people mummbling a lot about whether or not Perl is dying, but I think a better question is, “Is Perl perceived as old and crufty?”.  I think the answer is related to the perception that Perl is dying and I think there may be something the Perl community can do about it.

First, let me define what I mean by the phrase old and crufty.  When was the last time you cleaned out a communal refridgerator at work, church, or even at home?  What did you find?  Chances are you threw out anything that was obviously bad or wasn’t in a reusable container, but what about the questionable items?  You left them in there because they might belong to someone else, and they might still use them.  Even if you wouldn’t, they might.  So they didn’t get cleaned up.  That is what I call cruft.

Software developers don’t like cruft.  In our own code, we have the ability to see what is used and unused and clean vigorously.  It feels good to finish a rewrite or update to a system knowing that everything is nice and tight —  shiny code.  Or at least my perfectionist tendencies make me feel that way.  So, when I see comments like this on the Perl 5 Porters mailing list, it makes me cringe:

But I’d be scared of making it in any stable release as I would be surprise if someone somewhere isn’t matching on it, and ignoring the current term.

The change being discussed isn’t necessarily even one I would be in favor of, but it is a classic example of the kind of talk that leads into the perception of a language being full of cruft that developers don’t like.  I can understand how, through reading this type of comment, a person could come to see Perl as a language that is dying, not advancing, because the community is too afraid to make changes that would improve the language.

Now for some positivity: I think this perception can be changed, partly through the addition of quantitative analysis.  For example, if we take CPAN to be a (non-random, obviously) sample of all Perl code, then we can check to see if any module on CPAN checks the actual value of a warning someone requested a change to.  There are other Perl-based open source projects that can be grepped (or Ack-ed) through to quantify the potential impact of a change.  Instead of stating, “someone, somewhere might use <blather> for <unintended_use>”, try to add to it, “… but there were no modules on CPAN that did, and neither do open sourc projects A, B, and C.”  Perhaps we could even put together a set of projects and a tool to check outside of CPAN to make it easier to judge the impact of a proposed change.

Thoughts, anyone?

One Comment

  1. Posted April 6, 2009 at 11:19 am | Permalink

    I wanted you to know how much I enjoyed your “Old and Crufty” post. I have been writing code professionally for over 15 years and for personal enjoyment since the late 70’s. I started copying programs in basic out of book on a old TRS-80 model III. During all my years, I have tried to write great code the first time but you are right, anyone that cares about the code they write will always re-write it better the next time than the last.
    I have always believed that a language is a language. There are of course syntactical procedural differences between them but a good programmer can write good code in any language. In all my years of learning the newest, coolest language, I have found that they are all more the same than different. I think the measure of a language is if it is still doing it’s job effectively which is to convert the requirements given to the programmer into machine code which satisfy those requirements.

Post a Comment

Your email is never published nor shared. Required fields are marked *