Older blog entries for chromatic (starting at number 158)


I think the Waterbed Theory might apply. For example, I could explain Lisp syntax to my mother in fifteen minutes or so. It's very simple, just (f a b). However, the complexity that makes Lisp useful has to come out somewhere else. To be productive, she'd have to understand tree structures, code as data, car, cdr, list processing, and so on.

A language with simple syntax has to have a hefty standard library or it's not practically useful. The nice thing about syntax is that it's documented. In the case of Perl 5, we're talking about thousands of pages of standard documentation, indexed and searchable, organized by topic. Perl 6 will likely have similarly complete documentation.

Unless you're dealing with a program so very simple (or badly written) that it has no functions or modules or architecture, you're still at the mercy of the documentation or, failing that, the code itself. I'm not convinced you can really understand someone's code without reading it anyway.

If someone modifies the grammar in a Perl 6 module, you'll know. You'll have to read the grammar docs just as you would for any other library.

News is Pr0n:

For people who grew up watching war, it's time to live out the fantasy.
  -- News Producer

Was it Pat Cadigan's Synners that had the passage that described hundreds of television channels as one form of pornography or another? Some channels had disaster porn, with hurricanes, train wrecks, and car crashes. Several other channels had food porn, with recipes, slow, lingering shots of bundt cake, and the ubiquitous miracle knife.

I once saw a TV documentary that asked, "Why are American children so fascinated with guns?" Of course, they had slow, lingering shots of smooth, glossy black revolvers on softly-lit silk display stands. Ooh, sexy. Aah, forbidden. Why indeed?

To describe war -- and participating in war -- as a "fantasy" alternately frightens and angers me.

Open Source in Government:

Tomorrow, Oregon House Bill 2892 (also here) goes before the General Government Committee for discussion. If successful, it will then go before the Ways and Means Committee, then to the House floor for a vote.

I'm particularly interested in the discussion of open standards and document formats. Open Source and Free Software have several advantages here. The text of the bill mentions a few. Here's what I see:

  • Data will remain accessible where proprietary software might change document formats and licensing terms.
  • It is possible to switch vendors, as no one vendor can sell software to read documents of that type exclusively.
  • Citizens are free to choose software from several vendors to access public documents. It's possible they can run this software on their choice of computer at their choice of location -- home, work, a free lab, a library, a government office. This is immensely important: the cost or availability of a software package should not be a barrier to public involvement.
  • Where possible, the government should encourage development of resources for the public good. Support and development resources should go toward projects and knowledge that is freely accessible to the public, not locked away in one company or another.

Anything I've overlooked?

On Editing:

While I edit other people's work every day, I edit my own work much less frequently. In part, I write a lot less for publication than I edit.

My recent "hobby" has been a new book. The first draft is complete, and early, unofficial reviews have helped me improve great swatches of content. It's nearly time for the technical review, though, and I've been polishing individual sentences and paragraphs.

There are occasional gems I want to keep. It does often amaze me how I can read a paragraph out loud (to edit seriously, read out loud) and make faces at how painful my prose. There's a very clear line between "awkward" and "acceptable", and I can only ask "What was I thinking, to write such a thing?"

The line between "acceptable" and "accomplished" is much murkier. It is, however, much easier to go from something on a page to something passible than from a blank page to something.

Is programming similar? I do find it satisfying to clean up large chunks of murky, clunky code. There's also something highly satisfying about watching beautiful code emerge from the test-code-refactor cycle, too.

Bram: more rules about punditry at How to Write Like a Pundit.

Easy as E-Mail:

I wrote a mailing list manager today, based on Mail::Audit.

My buddy circle includes people in and out of the area. We send a lot of e-mail back and forth, making plans for weekends and weeknights and passing around interesting tidbits. That usually means creating large address lists based on random criteria -- who's in town, who's not, who might be interested in a subject and who isn't.

A few weeks ago, we were discussing some subject or another, and my brother replied and said, "Can you guys take me off of the cc-list? I'm not interested in this topic." That started my brain a-thinkin'.

My little mailing list manager lets you create new, temporary mailing lists by sending an e-mail with *NEW* in the subject to the proper address. The body has to be a list of e-mail addresses to which the mailing list will apply. It replies with the address of the new list -- just an alphanumeric addition to the main mailing last address. For example, if the list were sml@localhost, a list may be sml+a0f4b918@localhost.

All posts to that address go to everyone on the list. Anyone on the list can unsubscribe by sending an e-mail with *UNSUBSCRIBE* in the subject.

It runs from a .forward file, so it's a bit slow, but it was a whole lot easier than doing this out of procmail or writing a dedicated C program.

It needs a few more features, like limiting the people who can create a mailing list and optionally preventing people not on the list from posting to it. As well, I'm having trouble adding a little "For help, send an e-mail to this address with *HELP* in the subject" disclaimer to the end of the message body. It doesn't seem to stick when I get an arrayref back from $audit->body(). It doesn't do much logging, either.

It does appear to work pretty well, though, and it's 300 lines of code (including blank lines), though that's 2/3 test suite. It's pretty good for a day's work, though, especially since I got a bit of laundry and cleaning done.

On the other hand, it did absolutely nothing for finishing my book (draft due the 17th) or getting Everything 1.0 out the door, or working on my super secret space game. Still, it was pretty fun, and it's one more accomplishment.

Code available here, for the time being. It's not an official module package yet; early adopters and willing patchers only. Be sure to create an aliases file before you run it -- if it doesn't exist, it won't work. Big limitation; probably the first I want to fix.

A Little Advocacy:

Last week, the Linux in Boise Club allowed me to present a short talk. Since they found me through my Perl work, I gave a small advocacy talk entitled Why I Like Perl. It went really well, though having several books and miscellaneous pieces of swag to give away always helps.

You might notice that there's not a lot of traditional "advocacy" in the style that turns people off. I was more interested in talking about the advantages of Perl that I enjoy than discussing the bits of other languages I don't enjoy. In retrospect, that worked pretty well -- there were several interesting questions about Parrot, Ruby, and Java.

The Noble Chamois:

Generally found on less steep or severe mountains than Thar, Chamois are never the less capable of traversing steep and difficult terrain at high speed. They have excellent hearing, eyesight and sense of smell.


I also like the Latin name Rupicapra rupicapra.

16 Jan 2003 (updated 16 Jan 2003 at 04:08 UTC) »


I'm not a language purist by any means. I consider myself pragmatic, but realize I'm often idealistic. It's hard to reconcile those two ideas, though.

Consider polymorphism. I've most often seen it explained in terms of inheritance. I'm not a big fan of strong typing in general (at least as C and its descendants do it), but mixing polymorphism with the typing system seems... really wrong. Part of the reason Test::MockObject works is because polymorphism isn't limited to objects that share a common ancestor.

The secret is, objects which share a common interface are isomorphic.

Okay, it's not a very well-kept secret. Still, I've seen (and written) too much Perl code that relies on isa(). (Hey, at least I'm way over checking ref() so often!)

I'd like to see that Perl 6 doesn't encourage falling into that trap. At least, I'd like to see that Perl 6 encourages composition and delegation as well as it encourages inheritance. (Having failed to convince Allison completely through mad rhetorical skills, I resorted to code.)

In that light, I present Class::Interface. Please see the discussion at Perl Monks for more information.

As always, I may be way off track here. Once I figured out the way things really ought to work, though, they made a great deal more sense.


I'm on holiday this week, visiting my parents. Part of being on holiday means not doing my day job. (Those of you who've seen me work or who have seen the output of my work know that this is pretty rare.) I do have most of my work resources with me -- my laptop, my phone, a notepad, and an Internet connection, but this week is devoted to something besides writing and editing.

One of my goals this week was to do more work on Everything. Though the company's long since out of business, it's still viable software. There are still plenty of improvements to make, and I'd like to use it for a couple of projects in the future.

To aid in my goals, I decided to write yet another standalone web server. Being a smart (read lazy) programmer, I used HTTP::Daemon. I could install Apache and mod_perl on my laptop and work through the configuration there, but this allows other people to debug Everything on their laptops and will help with a future goal.

HTTP::Daemon and CGI.pm have never played well together. With the GET request method, it's not difficult to populate %ENV appropriately. It's harder with POSTed parameters. One solution is to tie *STDIN. I've done it before. Another idea is to write your own CGI parser. Good luck. (I've done that too.)

This time, I took a two-pronged approach. Since Gisle had already explained the wonders of headers_only last July (thanks, Gisle!), I didn't have to work around HTTP::Daemon having already read the entire request. First, I modified Everything slightly so as to pass an initializer filehandle to the CGI constructor. Then, I overloaded the iterator (readline, basically) in HTTP::Daemon::ClientConn. With a few lines of code to read a line at a time (respecting buffers and reading from sockets), CGI now gets something it expects.

GET works, POST works, images work (and can be generalized to regular files easily), and cookies work. I'm pretty sure uploads work, but I haven't tested them. All of this in a hundred and thirty lines of readable code: EVServer.

That was a big boost to my mood. As it turns out, though, I was coming down with a nasty, nasty head cold. That explains why I've been wanting to sleep twelve hours a day for the last week.

149 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!