Entries classified under weblog created during Feb 2005

These numbers look pretty bad... or good, depending on where you stand, I guess. I find it hard to believe that Rails is that much slower than Quixote/Durus for a truly similar task but hey I'm on the right side of this one so I won't complain too loudly.

Mike, you've given some info about the tests but it would be really helpful if you provided everything needed to recreate them. Specifically, the versions of Rails/Instiki/Quixote/MoinMoin and the specific URI stems you were pointing to with ab. Otherwise stuff like this can be taken the wrong way and turn into a big Python-vs-Ruby flame-fest. If your numbers are correct, I can't see the test setup making a whole lot of difference but still...

There are lies, damn lies, and statistics, unless you provide absolutely everything needed to recreate the statistics, in which case there are only lies and damn lies. We can reduce this a little further by removing the speculative concept of damnation, leaving us with just lies. This is probably the best we can do without killing everyone, which I'm not sure we can accomplish in any predictable time-frame.

LATER: Mike takes a closer look at his tests, revealing some issues with the comparison method.

Anyway...

I also wanted to comment on some of the RDBMS vs. Durus/ZODB stuff as I've been down this road myself and have been meaning to write about it a bit.

Mike compares relational persistence and object persistence:

Rails has a SQL object relational mapper; Quixote imposes no such thing but doesn’t get in your way of using SQLObject, ORM, Cucumber, any other o-r mapper, or no o-r mapper at all. I’ve done all of the above, but am slowly retiring all my SQL based code (where sensible) in favor of Durus, a ZODB inspired object database. Quixote sister project “Durus” provides an easy to use object database which is far more productive than force fitting objects to SQL. Durus certainly not limited to writing web apps.

Object databases like Durus/ZODB and relational databases are apples and oranges (or possibly oranges and mangos). I've recently been down the let's put everything in ZODB path and it comes with some problems:

• ZODB/Durus using FileStorage can only be accessed by a single-process.

• ZODB/ZEO or Durus/ClientStorage can be accessed with multiple processes over a network much like most relational databases but there is no concept of "multiple databases". If you want multiple databases, you need multiple ZEO servers running.

  LATER: Richard Jones corrects me on this and also the packing thing below.

• Durus has issues with multi-threaded access.

• There's not a lot of cheap hosting options that have ZODB/ZEO running out of the box or that will let you run any number of long-life processes.

• ZODB maintenance (packing) is a pain in the ass, IMO.

• Indexing is hard. The BTree classes get the job done but handling multiple indexes on objects can be tedious as you have to keep multiple BTrees in sync manually. (No I'm not talking about the full text index catalog crap. I need fast lookups on specific attribute values).

• Only Python code can access the database. I shrugged this off at first but found that it's actually really² nice to have data in some kind of language-independent storage.

There are a whole range of situations for which these issues aren't really issues at all and relational persistence has its own set of issues. But in my experience, making the decision between ZODB and relational has been less about what's better for the code and more about what's better for the data. That being said, I use ZODB quite a bit where I used to throw up hacks around pickles and shelves and also when I know I will have complete control over the application environment and don't have to play nice with others.

I've been enjoying David Heinemeier's (Ruby on Rails / 37signals) blog lately. The kid has excellent chin, which seems to be a requirement for dynamic language advocates mingling with the static language community. In his latest, Serving the koolaid with the facts, he takes on some of the criticism coming out of the Java weblogs that targets various aspects of Rails that go against conventional static language thinking.

It's really easy to take a concept that fails in a given environment and put it into the that's always bad part of your brain. Later, you see the same concept in a different environment and the that's always bad fiber starts blipping like crazy and your mouth starts saying things like, That's always bad.

There seems to be a trend emerging in conversation between the dynamic and static language camps that I believe is based in this flaw in the human mind. There are so many aspects of dynamic language programming that really just don't work in a static language environment and the opposite is also true; one is an ocean and the other dry land. Unfortunately, this isn't immediately apparent and those with strong backgrounds in one environment have a tendency to misjudge the viability of approaches in another.

Fish? That will never work.

I think the key to overcoming this problem is just to keep on talking. Over time it will become apparent that you can't measure dynamic language approaches under the static language microscope and then maybe we can just get on with things and start figuring out where the two environments can work together. It is perhaps not an accident that some of the most beautiful places in nature are the coasts where two strange environments meet.

Bill de hÓra describes the integrator's dilemma (also known as, WS-* vs. REST).

If dirt simple equates to good growth and better profits, then the missed opportunity arises when simple and simplistic are conflated. When the WS contingent are looking at the REST and syndication crowd and saying more or less, 'here's a nickel kid', they may want to stop and take a second look at what the kid is doing with that nickel.

I thought that was great. I suggest reading the whole piece. Bill's super smart.

The WS-* vs. REST thing is starting to heat up again due largely to James Governer's SOAP is boring, wake up Big Vendors or get niched piece last week. This led to the discussion at the beginning of Bill's post on whether Microsoft is ignoring developer demand for REST tools. I have a sinister theory on this (but not MS in particular) that I've been hanging on to for a while so let's just have at it. Bill has provided the voice of reason and I don't have anything to add so I'll just follow up with some good old fashioned religious rambling.

These are blogs, right? The last time I read the blogger's handbook, we were encouraged to make unsubstantiated claims about the intentions of others (especially big companies and industry cartels) without any real evidence, so here we go...

Dan Gillmor points to an excellent example of distributed journalism in action over at Daily Kos. I was completely blown away by what I saw when I got there. I'm still trying to soak in all the background around the Plame Leak / Jeff Gannon thing but, to be honest, the specifics of this event are not as important to me as the general phenomenon occurring there. This seems an obvious glimpse into a future where involvement by the general population in issues of import to the general population is increased substantially. Herewith some rant and analysis of our present toolset and humble suggestion for improvement...