perl – Radios Appear

Happy Birthday, Debian!

I estimate that I did my first install some time in late 1995, perhaps early 1996. I haven’t really used anything else as my day-in-day-out OS since. I’ve never had a Mac of any stripe, and haven’t used Windows with any frequency other than for World of Warcraft since ’99.

I can pin my first contribution to Debian with far more accuracy: September 3, 1996. That’s the date on the first Debian changelog entry in the libwww-perl package, which was, I believe, the first package I ever made. It still exists in Debian and Ubuntu (and other derivatives) and if you have it installed, you can look at /usr/share/doc/libwww-perl/changelog.Debian.gz, and right down there at the very end, you’ll find my grubby little fingerprints.

Sadly, things quickly went downhill—I am, to some extent, to blame for the fucked-up naming convention (with its poorly-sorting use of a -perl suffix) of every Perl library package in Debian, and probably by extension, the similar poor choices in the -java and -cil groups. Even the PHP guys were smarter.

As I remember it, having packaged libwww-perl (which is the actual name of the package as it exists on CPAN, so I just used that as the package name), I discovered that for some things—FTP support, I believe—it required the libnet package, which provides a lot of Net::* modules. But when I announced that I was going to package it someone (I want to finger Rob Browning, but cannot in be certain, and I don’t know if the Debian archives go back that far, and can’t be bothered to check, really) said they were about to package the libnet C library, which would conflict, so maybe I could call it libnet-perl, like libwww-perl, which I did. And then the next thing I packaged I ended up calling lib<whatever>-perl for no good reason, and it all went to hell.

Bleargh.

Almost 16 years later, we have ~ 3000 Perl packages in the repository, all with that damned -perl suffix. So, um, sorry.

My other big accomplishment of any note, I think, was to finally get the 64-bit Alpha port to a self-sustaining state. This started with a bootstrap that someone had done from a set of RedHat binaries before, and gradually pulling along various bits of the system until we had a self-hosting system.

Along the way, I was responsible for another unfortunate bit of “engineering”—@libc6.1@. Again, I don’t think I was totally alone in putting this forth (David, David…um, I forget his last name, and the libc6 changelog.Debian doesn’t go back that far), but it probably would have been better to bite the bullet and avoid all the gymnastics it required.

As I remember it (this was, err, ’97? So I may have some details wrong), RedHat had pushed their first Alpha release using a libc with a SONAME of 6, based on a pre-release glibc-2…and then the 64-bit ABI was changed when glibc-2 was released. Our versioning tools for shared libraries were much more primitive at the time, and we wanted to keep compatibility with RedHat, since that’s where a lot of the heavy duty engineering was going, so we had to follow them in changing the library SONAME to 6.1. This entailed a lot of churn at the time, most of which I’ve blocked out. I did a lot of mechanical patches on a lot of packages.

I did spent a lot of time doing fixes for 64-bit-isms in various packages, and I can remember the flush of pride I had when Alan Cox mentioned that he’d gotten a bunch of 64-bit fixes as well as the conversion of the @mh@ mail client to use an ELF shared library from the Debian package, because that was my work.

My time as an active Debian contributor was not always a smooth one—I wasn’t always as attentive about keeping things up to date or doing triage on bugs as I could have been. I think I finally formally recognized that I wasn’t able to keep up around 2002, which was probably a couple of years later than everyone else had realized it.

Ironically, I probably maintain more packages now, for our internal company purposes at Ironic Design, than I ever did as a developer; the tools have made the maintenance at least of the sorts of packages I do (libraries and simple applications) incredibly easy.

I maintain ~ 20 production Debian servers, with a handful of dev servers and a couple of home systems, including the laptop I’m writing this on, with basically no problems on a day to day basis. It has its warts, but I have boxes that have been continuously upgraded over a span of half a dozen years with no appreciable problems. I am able to be productive and use the environment happily. I remember the rough spots at the beginning (the move from a.out to ELF, for instance), but what Debian provides now always surprises and delights me.

So kudos to those Debian maintainers, former and current, who have contributed to such a great software system.

Choosing a new language

I have been programming primarily–for long stretches, almost exclusively–in Perl for the last 17 years or so. I seem to remember starting to use it around mid-1995, with 5.001–during that long, awkward time between when Perl 5 came out and when the 2nd edition of Programming Perl finally arrived in late 1996.

I’ve kept with it because I’m fluent in it, I am productive in it, and at this point, I can make it do some fairly absurd things (ask me about writing event-driven servers in Perl, I dare you). In fact, I like the language. I understand the complaints people have about it, but the subset in which I write these days is pretty clear while remaining concise and expressive, and the ecosystem that exists around it is simply unparalleled.

Nonetheless, I think the time has come to move on. The downsides of the language–speed, largely, and lack of good language support for expressing things like parallelism–have started to wear at me. I’m tired of the hoops I have to jump through to do the things I want to do.

So for the last 18 months or so, I’ve been reading a lot about a number of languages. I don’t think I’ve rejected any out of hand except PHP, though I certainly have some biases. For instance, I am looking for a mainstream language–something like “IO”:http://iolanguage.com/, though interesting, does not qualify.

But mainstream isn’t everything–I want something that is going to open up new options, that’s going to be fun to get immersed in; so I’m not considering things like Ruby or Python because for the most part I think they recapitulate most of the problems I have with Perl (speed, concurrency support) just with different syntax.

In the end, I came down to three options. Node.js, Scala and Haskell. I find that as I’ve been sitting with the question for the last couple of weeks, though, I’ve stopped thinking about Node.js as a real option. Though it’s fast, and it’s got a great ecosystem of software surrounding it, raw event-driven programming doesn’t really engage me any more. It was fun for the first year or two I did it, but the idea of moving to an environment where Everything Is A Callback leaves me cold.

So it’s down to Scala and Haskell, I think.

As a consequence, I’ve spent the last week reading _Programming in Scala: A Comprehensive Step-by-Step Guide, 2nd Edition_ by Odersky, Spoon and Venners, and before that I got most of the way through _Learn You a Haskell for Great Good_ by Miran Lipovaca (though I’m going to go back through it now and finish it).

I intend, over the next couple of weeks, to post about my experiences working on using each to write a couple of short (but non-trivial) programs with both of them–ones that, incidentally, I have implemented in Perl already, so I can do a real comparison of code.

A thing of beauty it is…

I’ve spent about the last three weeks converting much of the infrastructure code for AnteSpam to use AnyEvent.

One of the small bits of fallout from using AnyEvent is that we now have a large number of anonymous code references as callbacks, and in our logging code, these all have the same name: @__ANON__@.

This makes debugging output a little less useful.

In browsing some code in AnyEvent::SMTP, I happened across the trick of locally setting the @__ANON__@ typeglob to the name you want to use used in stacktraces and the like:

bc. my $var = sub { local *__ANON__ = ‘What::ever::you::want’; … };

So, this is kinda ugly, and I couldn’t find any official documentation of it, so I went looking around, and found @Sub::Name@, which is a module to make this a little more palatable. Now we can do:

bc. my $var = subname ‘What::ever::you::want’ => sub { … };

Still perhaps not beautiful, but not totally covered in warts, either.

Now to go retrofit this onto all of our code…