I gave two talks today in YAPC::Asia in Tokyo. Surprisingly I finished both talks in a lot less time than planned; usually I need to rush at the end to stay on schedule. I really should work out why these talks finished quickly when I spoke more slowly.

One of the talks was 混合語 (”Kongougo”) (yes, the title will look strange if you don’t have a Japanese font installed). When I gave this talk in Europe I spend some time explaining Japanese to the Europeans, and I obviously didn’t need to do that in Japan. So instead I rewrote the slides to use more Japanese. It seemed to work: the audience laughed a lot, which is really the only important thing.

4 hours is enough time to watch a good film and have a good meal.
It’s also just enough time to find a very annoying bug.

My script wasn’t inserting all its stuff into the database, but it was inserting part of it so I knew it wasn’t a database connectivity problem; it was also reaching the end without complaint, so I knew it wasn’t dieing somewhere. It thought it was doing the right thing.

The code looked correct, and I had similar scripts that worked, so I starting cutting bits off (the code). Eventually I had two scripts, one working and one failing, with the following diffs:

-my ($username) = "marty" or exit 65;
+my ($username) = ($rcpt =~ /(\w+)\@$MX/) or exit 65;

Now I knew I would be here for quite a while: someone somewhere in the code was using one of those irritating regex variables without checking if their match had actually worked! AARGH!

The offending code looked something like this (I’ve simplified it so it won’t distract from the bug):

    $text =~ m/:(\w+);|==(\w+)==/;
    return $+;

So, when $text was "foobar", the match failed and $+ still contained the last bracketed part of a previous unrelated match.

The code should have been something like:

    $text =~ m/:(\w+);|==(\w+)==/  or return;
    return $+;

I do try to be thankful in all circumstances: I’m glad I was using Free Software that I can debug and patch.

I have a pet snake called Scsi (don’t ask!). He eats warm mice, nothing else. I keep the mice in the freezer until needed, then defrost them slowly and finally warm them in a cup of hot water.

A few years ago Scsi was not easy to feed: I had to spend time waving small warm mice in front of him before he would bite. He is much easier to feed now for at least 3 different reasons:

1. He eats larger mice.
2. I can tell when he is hungry.
3. He can recognise his feeding by me.

I have phrased #3 quite carefully, but I’ll explain in more detail: Scsi doesn’t know what I am! When I move in a particular way he knows that I supply food, and he also knows that he can safely climb up my arm; he might think I’m a moving mouse tree!

As Scsi gets older, he will gain increasing experience of being a snake. He might learn new things, but he will never understand who or what I am, and he will always be a snake. Humans are just too different for snakes to comprehend, unless they smell like warm mice.

Unfortunately, many programmers are like Scsi. They live as masters in their own tiny vivariums, and they don’t recognise the greater things outside. They continue to program in the same way, and may gain many years experience without ever becoming more advanced. I have seen programmers with 2 years experience who were much better than other programmers with 10 years.

This effect is common with Perl programmers. Perl has a larger range of expression than most other programming languages, so you are much more likely to find these primitive programmers in a Perl world: they might have 5 years experience of CGI scripting with Perl, and they might even be extremely good at CGI scripting with Perl, but they are not advanced Perl programmers.

This problem is not confined to higher-level languages: I have observed similar situations with lower-level languages like C, C++, and Java.

But let’s not limit this analogy to programmers. Many people (although still a minority) don’t believe in God! They look out of their vivarium and believe they understand the universe despite the constant reminders that they don’t.

As I’ve mentioned before, I’m a Java anti-fan. As such, one of my duties is to attempt to correct the misleading Java propaganda. But I have to make sure I don’t go too far and create misleading propaganda of my own.

Someone recently asked: Can Java technology beat Perl on its home turf with pattern matching in large files?

Given the supplied answer, a more accurate question would have been: “Can a poorly written Java program beat a really badly written Perl program?”

I could easily retort with another stupid example showing Perl code kicking Java’s ass, but that wouldn’t help. We need a more objective way of measuring how crap Java is
The Language Level system by Capers Jone is a nice way to rate a language, but other empirical comparisons are needed.