After two weeks of showboating the least practical demo in the history of database programming, I’m reminded that there are toys worth having besides applets. Like text processing libraries.

We do have JTextile, thank heavens, and MarkdownJ. But it’s starting to feel like the 1970s Soviet computer industry around here. Can’t we have some text processors conceived in Java?

No, we can’t. It all goes back to throwing two or three checked exceptions on every stream reading function. Or maybe it all goes back to “1 file(s) deleted.” In any case there are two camps of nerds: in one they’re eager to get their hands dirty and make something pretty, while the other devotes its prettiness ambitions to UML diagrams and neglects the final product. Java is (mostly) in the wrong camp.

Databinder aspires to bring Java closer to “gettin’ cool stuff done” (before Java ends up in the same corporate waste bin as CORBA), but there’s no relief in sight for text processing libraries. They have ’em and we don’t.

The new Ruby Linguistics Framework is upping the ante, from polishing punctuation to changing copy. If you don’t care about the former you must think the latter is ridiculous, but I do want to programmatically turn "cow".en.quantify( 5 ) into “several cows,” and I want it now.

JRuby comes to mind, but its priority is calling old legacy Java code from Ruby, not calling the latest interdependent text processing libraries from (legacy!) Java. My sometimes-accurate ability to predict how much hair-pulling a computing task will involve is telling me to forget about running Linguistics in JRuby.

The remaining options are spawning a Ruby interpreter process (ouch, my hair!) or calling a Ruby XML-RPC server from Java. Now that might actually work, and nicely. You could still use RubyGems to manage Ruby libraries in a completely separate, normal setup. All you need is a little script to bridge the RPC requests into the libraries. It would be easy. It would be cool.

It would be darn good Databinder example.