The next meeting of the Denver Area Lisp Users' Group is set for Monday, April 28th at about 7pm in Boulder at:

Mountain Sun Pub and Brewery 
1535 Pearl Street 
Boulder, CO 80302 
Phone: 303-546-0886

Larry Hunter will be presenting on his work with Lisp and Bioinformatics.

I renewed my Radio subscription last week. Ironically, I haven't been that interested in posting lately, which I attribute to a comibination of being burned out from work, having Springtime arrive here on the Front Range, and not having anything much to say anyway. So time will tell if I just wasted $40 on this year's subscription.  Not feeling well today, and my daughter is celebrating her 10 month birthday with her first cold, so I didn't get much sleep either. 

I've noticed an interesting trend in my referrer logs: people are now hiding their referrers. Yesterday, I got a few hits from "undefined". Today, I have a hit from "Not Your Business!". Things like this make me wish that I did my own hosting, I'd probably start blocking smartass referrer abusers just to be a PITA. Not that I care that much, but it does bother me that somebody actually went to the trouble to code this up instead of just omitting the Referer: field.  If you can't be troubled to give me valid content, I shouldn't need to be troubled to produce it.

Javablogs readers seem to have picked up on last week's String.IsNullOrEmpty post, and that's caused a bunch of readers to come from Java Lobby. I did have one email from Eric Hancock commenting that it was a bad idea. Not that I was especially married to it, but the idea is that you'd expect to get an ArgumentNullException when passing null to a method that wouldn't accept it, and ArgumentOutOfRangeException, or a ArgumentException (or a subclass) when passing a string that wasn't a legal value to a method. So having String.Equals(null) throw ArgumentNullException saves a line or 2 of code and makes some sense, API-wise. But it does change the protocol for Object.Equals(), because having String do its own thing would be bad, so it'll probably never happen and if it did, it'd probably break a whole lot of existing code. So from that perspective, it is a dumb idea, and you shouldn't override Equals() in your own applications this way either.

Dare commented on the XML Command Line Parser.  I wouldn't call it a winner for the gratuitous use of XML in an application.  Gratuitous would be forcing the user to input the params as XML to save yourself the regex parsing ;-)  But I basically agree with Dare, it's an expedient way to short-cut having to write your own serializer, but it feels kind of wrong.  One problem I see is that it prevents using case-insensitive command line args, or using the GNU style args (i.e. -h and --help are synonyms).  The serializer wouldn't warn you about arguments that were ignored.  In fact, I'm not sure how XmlSerializer would treat fields that didn't exist in the object - would it error out?  Anyway, you could write something equally flexible using reflection, and give better functionality.  But it's a nice start to an idea; I think I'll try out my ideas the next time I need to do a command line app.