I'm posting from work, but will try to follow up in more
detail when I get home.

For the record, KirbyBase is cool. Jamey has done an amazing
job on it, and it works well and is intuitive.

If you need gigantic tables, if you need SQL, if you need
20K transactions per second -- don't use it. :)

But if you need a lightweight, low-profile data storage
mechanism with a good Rubylike interface, then do use it.

Many of the recent developments in it have been driven in part
by me. I have had a few ideas which Jamey was kind enough to
implement. All credit for the code goes to him. I haven't
written a line of the engine.

But Jamey and I have a slight disconnect in our communication
which is almost an object of study in itself.

Aside: I had a CS prof, Tobin Maginnis, with degrees in
psychology. He was always interested in research into the
psychology of human interfaces and of the coding process.
I bet he would love to watch Jamey and me and take notes. ;)

The thing is, Jamey is a Database Guy. As the sole architect
and coder of KirbyBase, this is a Good Thing.

Me, I'm just a guy who has objects he wants to store and retrieve.
In fact, I have looked at Madeleine and such. I'm not married
to the idea of a database at all, as long as I can store and
retrieve my objects.

As an Object Guy, I don't want too many of the details of the
database to intrude into my code (or especially into my classes).
I want the wires hidden from the audience. I want to pay no
attention to that man behind the curtain. I want it as blackboxy
as it can reasonably be.

For a past example: When I started uaing KB, a select would
return me an array of fields. I would take those fields and use
them to construct an object. It got to be a pain when I wanted to load
an object, change it, and store it back (decomposing it back
into an array before storing).

Eventually I said: Why am I doing this? And Jamey and I hammered
something out. Now when I do a select, I get an object back; and
when I store an object, I don't have to convert it.

Some of my basic principles are:

1. Software should be my servant, not my master.
2. My servant should be smart and read my mind whenever
possible. I don't want to micromanage him.
3. At the same time, if I have very complex or specific needs,
I want him to be able to accept micromanagement.
4. In connection with #2, common or ordinary actions should be
easy.
5. In connection with #3, infrequent or extraordinary actions
may be more complex. (Think Zipf's Law. Also remember DHH's
"say no by default.")

This to me is the essence of why I like Ruby (and by extension
why I like Rails).

Now, how does this relate to KirbyBase? I'll get into specifics
later on.


Cheers,
Hal