$ history | awk {'print $2'} | sort | uniq -c | sort -k1 -rn | head
  69 svn
  56 cd
  52 ls
  49 make
  26 perl
  19 vi
  15 tack
  15 cpan
  11 sudo
  11 prove

And actually, I’d have to merge the histories from eight different Terminal.app windows to get a full picture…

There are all sorts of reason why exceptions might be slow - they’re just more code the CPU has to execute after all. I worry though about general claims that any idiom is slow. Search a selection of programming blogs for “X is slow” and I guarantee that in the comments someone will say “I never knew that. I’m going to avoid X in future”. I imagine that after a couple of years of cargo-culting these folks are working with a miniscule subset of their chosen language, circumscribed by all those “slow” things that they’re religiously avoiding.

Measure instead of guessing. Look for algorithmic complexity: if you can go from O(N^2) or worse to O(N log N), O(N) or O(1) you might gain far more than a few percent. But then again you might not - so measure.

When I first got into computers I worried, briefly, that everything I learnt would inevitably be outmoded. I don’t want to scare anyone unduly but there will come a time when Perl 5 is outdated. Slow, ugly, verbose, arbitrary: it will become all of those and worse.

That is the fate of all languages. At least I hope that’s the fate of all current languages. These days if I really want to scare myself I need only imagine that the current state of the art is is a good as it ever gets. If that doesn’t worry you try to imagine a parallel universe in which our understanding of computers hit a glass ceiling any time in the past fifty years. Imagine COBOL as pinnacle of language design, 64k as a generous helping of memory, punched cards baby! Happy days, certainly, but I’m glad we were able to leave them behind.

As more of the world depends on computers there’s a growing force that slows change. The enemy of evolution in language design is the installed user base. In the case of a successful language like Perl millions of people may now be affected by an incompatible language change. The Perl 5 Porters must always balance the needs of the future with those of the past and that places an upper limit of the rate at which Perl 5 can mutate.

What to do? How do you move forward if you’re constantly looking over your shoulder? You take advantage of a fortunate property of software: that it is possible to simultaneously care for and conservatively develop the current active branch of a language and forge into the future with a clean new version. Two siblings: the elder healthy, but constrained by responsibilities, the younger relatively free and able to learn from the elder’s mistakes without repeating them. Perl 5 and Perl 6.

But Perl 6 is taking too long to mature. More than seven years in embarrassing, right? Not really. Perl wasn’t really the Perl we know and love until Perl 5. For the first ten or so years Perl was a lesser language. Sure, the step from Perl 5 to Perl 6 will be bigger than the step from 4 to 5. The jump from 4 to 5 was in its time the biggest seismic shift the Perl world had seen. There’s a trend there; the steps are getting bigger all the time. There was no significant dynamic language movement when Perl 1 entered the world. Perl 6 is gestating in a rather different environment.

Perl 5 is not yet decrepit. Rumours of its death greatly exaggerated (or imagined). Perl 6 doesn’t yet need to come of age so it makes sense for it to continue to mature in a relatively protected environment. As long as Perl 5 remains viable it’s sensible to give Perl 6 the space it needs to grow because when its time comes it’s going to face stiff competition from its elder and from Ruby, Python and others.

Rather than impatient foot tapping Perl 6 needs the help and nurture of the Perl community. The Perl 6 development process is transparent and open. Anyone with something useful to contribute will be welcomed. If you self-identify as a Perl person then Perl 6 is in part your responsibility. And if you can’t usefully contribute then, please, quietly reflect on the debt of gratitude you owe to those who do. They’re working to guarantee your future.

Perl 6 is not a liability. There’s no need to be defensive about it. Paul Cory would like to rebrand Perl 6 into the shadows. That’s the kind of Stalinist revisionism favoured by corporations that realise that their “next big thing” has become an embarrassing albatross. It’s a response to Perl 6 that the circumstances do not require.

Here are his reasons:

1) It emphasises the “inadequacies” of Perl 5.

All languages have inadequacies, imperfections, miss-features, cruft. Perl 5 is no different. Fortunately, instead of brushing them under the rug, the Perl 6 team is actively seeking to right those wrongs. A question: would you rather use a language that’s maintained by people who are a) in denial about it’s inadequacies or b) actively developing a new language based on recognised shortcomings? I hope that’s a rhetorical question.

2) It makes the development community look unorganized, at best. People comparing at the development pace of Python, Ruby and PHP to Perl 6 are likely to come to harsher conclusions about the community’s focus, viability and competence, based on Perl 6’s seven-year, and counting, gestation period.

Those hypothetical people are wrong and I don’t want to be part of a community that panders to their views. The Perl 5 Porters are doing a great job of continuously improving Perl 5 within the constraints that popularity brings. The Perl 6 team are laying the foundations for the next generation of Perl. Perl 5 and Perl 6 have a mutually beneficial relationship: features, tools and ideas are traded freely between the two groups. It’s healthy, responsible and creative.

Python and Ruby have, to their credit, somewhat similar splits between far sighted strategic development and tactical improvements to the current language generation. PHP is a bizarre bazaar that does not provide a model other language communities should emulate.

3) It creates uncertainty: what happens to Perl 5 when Perl 6 finally drops? How much new stuff will I have to learn? How will my existing code work, or not, if I upgrade? Why should I invest time in Perl 5 if Perl 6 is just around the corner, and will be far superior?

Learning to deal with an uncertain future comes with the territory of computing. Continual improvement necessarily means that things will change.

Perl 6 is visible proof that we have vision. Perl 5 is visible proof that we can maintain an extremely high quality programming language. These facts combined should give observers confidence about the health of Perl. As a community we certainly need to work to allay fears and calibrate expectations. But let’s not start by hiding one of our greatest assets, ok?

4) It creates frustration inside the community. Perl 6 has been “coming soon” for 7.5 years now. It’s hard to remain excited about something that long with no payoff.

Welcome to the world of free software. Instead of waiting for Godot we can go and meet him half way; help him carry his load. Let’s be explicit here: if Perl is part of your life or career and you’re tired of waiting for Perl 6 help make it happen.

You don’t have to contribute code to help. Learn more about Perl 6 so you can explain it to others. If you find it hard to learn make it easier for others: write an article that explains some of the important points, give talks, learn so you can teach.

5) The story is confusing: Pugs? Haskell? Parrot? Two development tracks? I thought this was about Perl? Yes, I have an idea of what those things are, but most folks outside the community (and a fair few inside, I’d wager) don’t know, don’t care, and shouldn’t have to.

If the story is confusing we need to tell it more clearly. That doesn’t justify changing the underlying technical narrative.

In a commodified world criticism and spending discretion are the consumer’s only levers. We crave influence over the things we consume. In the absence of direct influence over a product’s design we use criticism as a proxy for control. We hope that they’ll make the next version better as a result.

Criticism is still valid in the free software world but it’s importance is de-emphasised. You can criticise or you can help. In fact you can criticise and help.

It’s important that Perl 6 is not immune from scrutiny but if you’re frustrated that it’s taking a while then volunteer. The Perl 6 team is small at the moment; small enough that a few well placed contributions can make a real difference. Let’s not default to bitching about it when we have the opportunity of contributing to its success.

Why not make 2008 the year you do something for Perl 6?

After installing the proxy and telling Safari (and everything else on the machine) to use it I started to experience PubSubAgent crashes every twenty minutes or so. It turns out that PubSubAgent is responsible for .mac synchronisation - and it doesn’t like proxies. You can read more about the problem here.

The solution suggested on that thread - to add .mac.com to the proxy bypass list - is heading in the right direction but isn’t quite correct. Instead you must add *.mac.com to the proxy bypass.

Get yours here.

http://www.w3.org/TR/html4/strict.dtd

It’s quite a well known one. Certainly there’ll be a module on CPAN that can parse it. Let’s have a look.

XML::DTD

Looks promising, comprehensive. Unfortunately it fails with an error which is eventually tracked to a misspelled method name. So much for test coverage. Fix that and it throws a bunch of warnings that cause a rapid loss of confidence. No matter, let’s try…

XML::DTDParser

It’s a “quick and dirty DTD parser”. Hmm. “I’m too lazy to document
the structure”. Nice.

“Since version 1.6 this module supports my “extensions” to DTDs. If the DTD contains a comment in form…”

Maybe I’ll come back to XML::DTDParser…

SGML::DTDParse

SGML? That’s got to be good, right? SGML is the daddy. Every fule no that. Unfortunately it doesn’t really seem to have much of a Perl interface. It’s all about translating DTDs to XML. I might be able to use that. I’m getting desperate.

I’ll take a quick look at the test suite for a confidence boost. Here’s one:

    # Before `make install' is performed this script should be
    # `make test'. After `make install' it should work as `perl

    #########################                                  

    # change 'tests => 1' to 'tests => last_test_to_print';    

    use Test::More tests => 1;
    BEGIN { use_ok('SGML::DTDParse') };                        

    #########################                                  

    # Insert your test code below, the Test::More module is use
    # its man page ( perldoc Test::More ) for help writing this

(I’ve cut the right hand side of the test off so it fits my stupid page layout. Don’t worry - you’re not missing anything good)

The other test is pretty similar. I’m not that confident now.

XML::ParseDTD

Running out of options. Let’s look at XML::ParseDTD. From the documentation it appears to rock. The test results say “2 PASS, 2 FAIL”. 50/50. So at least it’s got some tests, right? Damn right! Here they are in their entirety:

    #!/usr/bin/env perl -w

    use strict;
    use Test::Simple tests => 2;
    use XML::ParseDTD;

    my $dtd = new XML::ParseDTD('http://www.w3.org/TR/xhtml1/D
    ok( defined $dtd, 'new() returned something' );
    ok( $dtd->isa('XML::ParseDTD'), 'it's the right class' );

(Again I’ve cut the right hand side of the test off. Again you’re not missing anything good)

I’m momentarily impressed that it managed to score two failures with that. I’m about to find out how.

Never mind, the DTD URI in the test looks a lot like the DTD I need to parse. I’m getting close. I can feel it.

Unfortunately it has a dependency on Cache::SharedMemoryCache (why?) which in turn depends on IPC::ShareLite - which doesn’t install on my PowerBook. So now I need to fix / avoid IPC::ShareLite.

See kids: the great thing about CPAN is how much time it saves!