[ruby-core:24250] Re: [ANN] meeting log of RubyDeveloperKaigi20090622

Charles Oliver Nutter wrote:
> On Mon, Jul 6, 2009 at 10:18 PM, Luis Lavena<[e-mail]> wrote:
>> But I still think that bundling sqlite3-ruby into Ruby itself is going
>> to slowdown the progress and release cycle of the extension, not
>> taking in consideration it adds another layer of complexity for the
>> ones that build Ruby from source (me).
>>
>> This also will impose a issue for implementations like JRuby, since
>> this put more work on the team to be able to replicate everything
>> under the sun of what MRI does.
> Agreed on both counts. What I'd find a lot more useful is if an
> FFI-based sqlite wrapper were written, and then everyone can just use
> the *exact same code*.

Except when they can't. It is true that much more Ruby
Implementations can support FFI than MRI C Extensions, but there
are still some implementations that can't support either of
those. I'm thinking of browser-based implementations like HotRuby
or Red Sun (or that V8-based one that constantly keeps popping up
on wishlists, but noone wants to actually write), implementations
running in limited environments like JRuby/GAE or JRuby/JME-CDC
and implementations running in "strange" environments like
BlueRuby.

Also, there are some implementations which run in environments,
where there already *is* a relational database. BlueRuby can only
run inside the ABAP VM; the ABAP VM itself is actually not just a
VM, it is more like an application server, or even an entire
application stack. And one of the things it includes, is a
relational database. In fact, the database is so tightly
integrated, that the BlueRuby Interpreter cannot even read .rb
text files. If you want to run Ruby code, you have to store it in
the database as a semi-preparsed structured syntax tree, and the
BlueRuby Interpreter will load *that* from the database and
interpret it. In fact, in ABAP there is no filesystem, all I/O
goes through the database. So, if you add SQLite to Ruby, you
would have to store the SQLite database file inside a BLOB column
in the relational database, just so you can get a relational
database. That's crazy!

However, that is not even the *real* problem.

If you add SQLite to Ruby, whether that be as an MRI C Extension,
an FFI Extension, a Gem or some other solution, there will still
be a fundamental problem remaining: the C sourcecode of SQLite
becomes part of the Ruby Language Specification, at a time when
the Ruby Community is working very hard on getting *away* from C
as the specification language for Ruby.

I remember you saying at a talk about JRuby something like "the
good news is, there is a specification for Ruby; the bad news is,
it is written in C." In this case it is even worse news, because
not only is the specification written in C, but it is written in
C *by someone else*, which means that the Ruby Community has
*no control* over its *own* specification!

Some examples for what it means to make random third-party
sourcecode part of the Ruby Language Specification: the only way
for JRuby to become fully compliant with the OpenSSL
specification was to lock Ola Bini in a dark room with a box of
Pizza, a crate of Red Bull, a printout of the OpenSSL sourcecode
and an empty Emacs buffer, and have him transliterate the entire
codebase line-by-line from C to Java. The only way to become
compliant with the Ruby 1.9 Regexp specification was for Marcin
Miel=C5=BCy=C5=84ski to do the same with Oniguruma. What's next, having
John Lam hand-translate SQLite to C#? Don't these guys have more
important work to do?

> Please, for Ruby's sake, no more C extensions.

Yes! But also, no more C in the Ruby Specification.

What would be a better approach is to add a "Ruby Interface For A
Lightweight Relational Datastore Specification" (maybe similar to
CoreData, but less, how shall I say this, "NeXTStep-ish") to the
Ruby Language Specification (plus corresponding Examples in the
RubySpec suite, of course) and then allow each individual
implementation to fulfill this spec in the way they see fit: MRI,
YARV, Rubinius and tinyrb could use an FFI version of the SQLite
Ruby wrapper, JRuby and XRuby could use Derby, H2 or HSQLDB (or
also SQLite-FFI), IronRuby could use, I don't know, Jet maybe,
HotRuby and Red Sun could use the new HTML5 Offline Storage
features, MacRuby could use CoreData, MagLev could use a
relational wrapper around their distributed object store, and
Blue Ruby wouldn't have to do anything, because it *already* sits
on top of a relational database.

Or, we could just do nothing, since SQLite seems to have worked
quite fine without being included in the stdlib. (I thought the
general consensus was that we need to *remove* stuff from the
stdlib, not add even more crap?)

Anyway, I'm not a Ruby Implementer, nor a Ruby Designer, nor a
Ruby Specification Author, so this is just my 2 cents.

(I *am*, however, a MRI-on-Windows, YARV-on-Windows, JRuby and
IronRuby user and as such I am painfully aware of the enormous
problems all that C crap causes.)

Cheers,
    jwm.