Wednesday, August 27, 2003

Public Commentary on Patents. Yeesh.  These guys, bless their hearts, are out there attempting to patent LISP! Well, not exactly -- they're trying to patent the use of XML as a LISP machine.  Essentially what they've done is dumb down s-expressions into an XML form.  It's amazing sometimes that when you navigate your way through a problem you end up right back where you started.  At each step of the game you found something new, something incredible -- an excellent new thought or path.  And then it all led back to the beginning. Thus it is with LISP.  Now there are things I don't like about LISP.  It's syntax, while incredibly clean, simply doesn't excite too many pattern recognizers in the brain.  Everything is a parenthesis, and that's tough when you're reading.  I wrote a while back on cognitive signposts in computer languages, and boy could LISP ever stand to have a few more of them.  A sort of "pretty LISP" if you will. There's another way to solve that, of course -- instead of doing our editing with fixed column width editors that just colorize what we're looking at, do actually desktop-publishing style layout, on the fly, on the LISP code.  That would be cool.  It would be a kind of literate programming...more like art programming.  But I digress. The point of the patent post is this: The patent office has already managed to put pretty much everything online, so the public can at least view these stupid patents.  Why not go the extra step and allow the public to comment on what they see?  Why shouldn't the public be able to point out prior art, make commentary on the patent, and basically try to thoroughly invalidate these things early in the process? We should be able to get involved.  Companies lie about their patents all the time, during the application process.  The patent process presumes the honesty of the applicant, and that is simply not the case, much of the time.  A company will deliberately hide the origin of the patent, fail to point out prior art to the examiner, and other such shenanigans.  We've got to start using the internet to put things back in balance. 9:07:44 PM

Anders Hejlsberg is Wrong on Checked Exceptions. Boy, I can't believe I just wrote that. He's got the quote of the day on Cafe au Lait, from something called "The Trouble with Checked Exceptions". He gives two arguments on why checked exceptions are a bad idea. Versioning is first -- he says that if you need to throw a new exception from your library, it has to go into the signature, making it incompatible. Second, when combining together multiple libraries, you end up with a kind of cross-product situation for catching exceptions. If your librarty calls another, you need to add the other library's exceptions to your own throws list. He's wrong on both points. First, most libraries will declare a general exception class, like LibraryException, and build all their more specific exceptions using subclassing. Most methods will throw a LibraryException, and specialize from there if necessary. Problem solved. You can pay attention to the messages and concrete subclasses if you want to, but you don't have to. Second, chained exceptions are an effective way of dealing with the library combination issue. You capture a sub-library's exception, then wrap it with one of your own. As a library, your use of a sub-library is something that should be transparent to the calling system. Chained exceptions allow you to convey the right information back in a general form. Java provides good tools for handling exceptions. Languages that don't check them (which is basically everything else out there) just kind of scare me right now. How do you know you've got everything handled? The answer is...you don't. And centralized error handling in a server-based application isn't necessarily practical. 8:58:58 PM