IronRuby

Microsoft apparently hops on the dynamic languages train and releases IronRuby, a Ruby interpreter for the .NET platform which is also supported by Microsoft’s counterpart to Adobe Flash, the all new silvery Silverlight (which by the way also supports Python). I’m not exactly a fan of Microsoft, but I like the idea that web applets can now be written in Python and Ruby. How great would it be if these languages could once replace JavaScript on the client side as well. For now, I’ll stick with RJS templates for that purpose.

Java and/or Ruby

Currently I am working on a small prototypical application involving lots of webscraping, a database and some sophisticated term indexing and search query expansion. Since some parts of the app are quite independent from the others, sharing data only via the database, I decided to code as much as I could in Ruby. There is nothing better for getting into a new language than working on a real project.

For web scraping (which I always did with Python, my absolutely favourite scripting language to date, and the fabulous BeautifulSoup library) I decided to switch to Hpricot (silly name), which does the job of scraping untidy HTML pages good enough for me.

So, what do I use as a cost-effective, well-maintained search and indexing framework? Of course Lucene, because I have grown up with Java and the bold faith that there is a library for everything under the sun - written in Java. But lately I found that there is in fact a Lucene-lookalike implementation for Ruby named Ferret. And it is even faster than Lucene. So off to new pastures.

All that is left in Java will be the RDF handling, because there is nothing as sophisticated for RDF/OWL ontology handling as the Jena library in Ruby.

Tune in next time to hear me talk about the pitfalls of weakly-typed scripting languages …

Links:

Humane Interface Design

Martin Fowler writes on his view on humane interface design, i.e. APIs that are designed for convenient use, in contrast to minimalist APIs. He states that

The essence of the humane interface is to find out what people want to do and design the interface so that it’s really easy to do the common case.

For example, Ruby’s arrays have convenience methods such as first, last, flatten, etc. which tend to be omitted in minimalist interfaces, because they can easily be implemented by clients. And Ruby also aliases method names, i.e. using multiple names for the same functionality, such as length and size of arrays. As an example for a minimalist interface, Fowler mentions the Java API for collections.

I wonder where Python falls in this spectrum. The Python folks state explicitly that

There should be one — and preferably only one — obvious way to do it.

Which sounds like a minimalist approach to me, in the meaning of “reduce stuff to the things that are canonically necessary”. But if you look at the APIs, you’ll find aliases there as well. I don’t know Python terribly well, so perhaps some Python guru can enlighten me on this?

Wrapping things up I don’t think that one approach – humane or minimalist – is necessarily better than the other. Both have their benefits and drawbacks, but like Martin Fowler I prefer humane interfaces.

Via One Man Hacking