So, in a discussion on the Atom protocol list, I asserted (paraphrasing myself) that any language one would want to implement the protocol in would have first-class support for regular expressions. The response I got referred to three things: C, C++, and the fact that Java did not have first class support for regexes until version 1.4.

The context of my comment, by the way, is microparsing XML — that is, XML formats that hide semantically significant information in the text content of an element, instead of using elements or attributes to represent the data; such situations should be avoided. It’s made even more abstract by the fact that I imagined a situation where APP required the use of regular expressions. That’s slightly silly as a rhetorical starting place, but really, I was just off-put by an opening salvo that suggested that it would be expecting too much of APP implementors to have to understand regular expressions.

Here’s a more defensible proposition: if you work with user-submitted content on the web, it behooves you to know how to use regular expressions; if your favoured language doesn’t have first class support for them, then it behooves you to find a library that lets you use them. Not every text-processing problem is a nail, but there are an awful lot of nails about nonetheless. I’ve been known to use regexes to parse dates now and again, not that I recommend it as a practice (you don’t know a programming language until you know how to use a good portion of its standard libraries; learn those libraries, folks).

I was of course being slightly provocative with the “first-class” aspect of it, but I don’t feel a need to back off from that too much. I can also back very slightly off of “regular expressions,” since what I really believe is that any language worth using “on the web,” where there is lots of text to be processed, should have standard or readily available powerful text query and manipulation capabilities. What that amounts to, for practical purposes, is that you need regular expressions. Sure, there are other ways to match and process text, but in general they’re more verbose and less powerful than regexes (quick: extract the longest sequence of digits from a user-submitted string without using regular expressions). If there’s anything close to a lingua franca of general text manipulation and extraction, it’s Perl-style regular expression. Yeah, you heard me. Perl.

To fend off one misinterpretation, I am not suggesting that regexes should be used to parse HTML or XML, but there’s a whole world of information inside attribute values and element text; if you’re not going to treat such stuff as unstructured blobs, you’ll want a way to muck with it. Depending on what type of information you’re interested in, your need to do so might be somewhat minimal, but it would be prudent to have access to the power of regular expressions.

So, where does that leave my slightly-less-emboldened claim with respect to that list of programming languages? Well, let’s take it in reverse order. It has been five years since J2SE 1.4 [¹ ] was released unto the world. It’s not a new feature of the language; two major revisions of the language have come out since 1.4. There are, I understand, people out there who are stuck with pre-1.4 JDKs (tick-tock) . I am genuinely unaware how many of them would want to run APP servers or clients. If they’re really stuck, there are several high quality regular expression packages available for the platform.

I suppose I could snark off and suggest one wouldn’t want to use C or C++. After all, the popularity of C and C++ as web development languages lag significantly behind that of (to pick a few examples) PHP, Perl, Ruby, and Java. That’s a pretty thin reed, though: I doubt that regular expression support has much, if anything, to do with the explanation for this fact. But suppose you’re embarking on a web-related project and you’ve chosen C or C++? Would you want to do it without regexes? Perhaps so, but why are you foregoing the power they bring to the table? Your reluctance is beginning to seem a little … pathological. Use PCRE or Boost. Join us.

[ ¹ ] One is permitted, should one so wish, to note that pre-1.4 Java lacked standard library support for one of those execrable markup languages the kids are on about today.

Work continues on the Atom Publishing Protocol, and on implementations thereof. Sylvain Hellegouarch started a list of APP implementations. Since it also looks like APP support will be added to Wordpress, it looks like we may be at or within a watershed moment for APP. Or maybe we passed one a while ago, and I just noticed. I’ll add to the above an informal listing of projects that are either nascent or about which I don’t know much:

• Dave Johnson brings news that an implementation based on ROME is in the works, which is all to the good.
• It seems that Python and Java hackers have taken the lead on APP, but there are what I hope are more than rumblings on RubyForge and
• … chatter on CPAN …

Out of all of these, I have only really used Apache Abdera so far. Although the API is in a bit of flux (early days yet), the fact that it’s currently implemented around AXIOM disposes me toward it favorably if you’re working entirely with Atom feeds and the APP and you’re going to process large feed documents. ROME is bound to JDOM, which means the whole XML document (including the overhead) has to be read into memory. OTOH, using ROME gives you the ability to transform your Atom feeds into other formats, and maybe your application would benefit from having the whole document in front of it.

The availability of in-browser implementations, such as Yulup, carries the promise of being able to quickly post to a lot of different blogs (or other content management systems) without having to visit a whole bunch of different web pages — at least when server-side APP support becomes widespread (on the Firefox extension front, see also Performancing, which is not APP-specific).