(even if you're not interested in building a new language, learning about programming languages and their design decisions increases our understanding of them and, hopefully, our proficiency with them)

What is Eiffel? Is it another language that lives solely in academia? Is there anything particularly interesting about it?

It's a static, strongly typed language, and...the rest of its characteristics you can read about on Wikipedia.

From a historical perspective, it's interesting to see some of the key features in Eiffel make their way into Java and Ruby, and to see which features didn't.

For example, Eiffel has a notion of abstract classes, except they're called "deferred" classes and use the deferred keyword. Ruby has no abstract classes, though you could simply make the constructor throw an exception, I suppose.

More interestingly, Eiffel supports multiple inheritance, but neither Ruby nor Java do (though Scala supports something similar). How does it evade the diamond inheritance problem? Eiffel doesn't support argument overloading, like Java does; so if two parent classes have the same method, it won't compile. Instead, you have to resolve the name conflict by renaming one or both of the conflicting parent methods in your subclass.

Like Java (1.5 and later, at least), you can't override a parent method without explicitly stating it, except instead of with an @Override annotation at the site of the override, you declare the override at the start of the class with redefine.

Like Scala, Eiffel holds the Uniform Access Principle close -- Eiffel lets you redefine an argument-less method in an ancestor as an attribute in the current class.

Like Scala, Eiffel has a void type, and it is a descendant of ALL reference types, which allows you to pass void into any function expecting a reference type.

Unlike Ruby, Java, and Scala, the only structuring tool is a class -- no interfaces, mixins, traits, interfaces, or modules.

Like Java, Eiffel has a notion of a once routine. Java's equivalent is the static initializer block (static {}). Ruby has a similar pattern, using ||=, to initialize a value once. (Scala also has a notion of lazily evaluated methods/attributes)

Unlike Java, Eiffel does not allow you to cast an object to another type (though you can always try to assign one object to a variable of a type and it will 'cast' it).

And so on. If this piqued your interest in the ancestor of two big languages of today, check out the tutorial. The first 2-3 chapters are a bit dry and apparently a little self-absorbed in places (it's not just a language, it's a process! they say), but still a good read/skim.

Edit: apparently you can embed Gists. Sweet. Gist is below.

From the repository

1. sudo aptitude install libopenssl-ruby1.9
2. sudo aptitude install ruby1.9

From source

1. sudo aptitude install libopenssl-ruby1.9
2. cd ~/Downloads/ruby-1.9.1-p0/ext/openssl
3. ruby extconf.rb && make && sudo make install

Note that if you haven't installed Ruby yet, you don't need to build the openssl gem manually -- I believe it will automatically get picked up during the regular Ruby 1.9.1 build process if all the dependencies are already there.

Disclaimer...

I'm not 100% sure these steps are accurate, so if they're not, please leave angry messages and I'll try to fix the directions. Otherwise, hope they help!

But, in the end, I think CouchDB is not the best way to solve this problem...

CouchDB is what's called a document-oriented database. This is as opposed to relational databases, like MySQL, PostreSQL, Oracle, even sqlite. For convenience I'm going to abbreviate each as DOD and RD, respectively.

How they differ:

1. DODs are schema-less. This means there are no columns/fields to speak of with size constraints. A "document" is a record in the database, which is essentially a hashmap (or associative array if you prefer) with a couple other little features (i.e. revisioning).
2. There are no "queries" in DODs (CouchDB, at least). If you were curious about how something without rigid structure could be fast, this is how. Instead of queries, you have "views", which are only slightly related to views in the RD sense. There are two types of views -- permanent views and temporary views. A view is the result of calling a user-defined function on every record in the database -- if the function evaluates to true, the record is included in the view. Permanent views are stored in the form of design documents within the database itself. Every time you add or modify a record, every view function is called on that record to (re)evaluate whether that record should be included in a particular view. Temporary views are the basically the same, but not stored permanently in a design document -- they disappear after they're used.
3. Some other things, see Wikipedia or their official page.

So here's the problem. You can't just say "Show all blog posts by user X", because that would require you pass a variable. Not a big deal; you create a view that returns true if the blog post belongs to that user. But still, you have to create a view for every single user if you want to be able to select all the blog posts by any particular user -- I'd imagine that could take up a lot of space, and CPU cycles. Alternatively, you could have a view that just returned all blog posts, and then filter through those in your application. Neither would be that good though, I feel, but I might be missing something.

Similarly, in a log file, you can't say "Give me all records with session ID Y" -- you'd need a view for that, and a temporary view would have to be generated on the fly, and the permanent view...well, you'd want a permanent view for every session ID, and there could be tens of thousands of those. Plus every time you add a new record, you'd have to run the view functions for all those on it, and that could take a while.

On the bright side, CouchDB doesn't have any locks in it (helps that it was written in Erlang). This means that no matter who or how many are reading or writing, nothing will ever get blocked. Additionally, I guess you can seamlessly distribute the contents of the database across multiple servers and get redundancy pretty easily, but I haven't looked into that tooo much. Also, CouchDB is technically Alpha, so all of the functionality hasn't actually been implemented yet, like interfacing with Apache Lucene (a full-text indexer search thing).

So CouchDB looks like it has a lot of potential, but I'm not exactly sure for what, unless you never have that many documents in the database or not that many different parameters you want to be searching on.

So, yes, Ruby+Gosu+Chipmunk play just fine with RubyScript2Exe on both Windows and Linux.

The first is called RubyScript2Exe. It takes all the files needed by an application and sticks it into a single binary executable, as well as any dependencies. Cool huh? The only problem is the smallest program RubyScript2Exe can generate is 700k. Not so bad, but then I include the Gosu game library I'm using and it comes out to 7.0M. Compressing (7z, tar.gz, zip) doesn't get it past 6.7M. Oh well, after adding all the media and stuff I want I can't imagine it getting past 15M or 20M, which is acceptable when most people have >100 gigs of space. But not everyone has uber broadband...oh well. Anyway, it just seems larger than it needs to be is all.

The other application (by the same guy I think) is Tar2RubyScript. Tar2RubyScript does something similar to RubyScript2Exe, but instead of generating a binary, it generates a Ruby script. That is, it takes your directory tree of files and generates a single equivalent .rb file. Cool huh? It's like JAR files, but with less overhead and without compression.

So, ultimately, Windows will have just the binary and Linux will have a binary (for those without Ruby), the single Ruby script (for people who don't care about the source), and the full directory tree (for the inquisitive and those who can't get the other script to work).