Re: How to make Ruby _THE_ scripting language of choice, fold inSQLite

Thanks for the many responses, all made Good and perfectly valid
points... alas, mostly in the sense of very astute folk standing a
little too close to an elephant... :-)

So rather going into a point by point rebuttal (since, as I said,
everybodies responses were perfectly valid and hence I have no
objection) I rather highlight the response that glimpsed the full
Elephant.

On Fri, 26 Sep 2008, Jeff Davis wrote:

> As far as SQL being a "dead-end road", it needs to have a replacement,
> first. Sequel/SQLAlchemy are a start in that direction, but the SQL
> DBMSs provide a lot of things aside from just language.

Let's face it there are a _lot_ more SQL users out there than Ruby
users...pity SQL is _so_ ugly.

Big Money brooks no dead ends. SQL is a huge, very useful, successful
money spinner. Hence it will be and _is_ being extended both on the
client _and_ server side to do what scripting languages like Ruby does.

No sane language designer would choose such a path, the SQL extended
languages I have seen are as ugly as sin... but as I say, nothing
stops the money.

So tell me, assuming you, like millions of developers worldwide, have
to use some form of SQL database.

Which would you rather code in?

One of the SQLextended (distended)?  abortions that comes with the DB?

Or Ruby?

Silly question (in this forum):-). The answer obviously is Ruby.

Is the integration between Ruby and SQL as slick as you could imagine?

The current adapters are damn Good, but not as slick as I could imagine.

Neither in terms of syntax, Object / Relational integration, exception
handling nor performance.

Can you use Ruby in your server side stored procedures? Probably not.

So let's talk a bit about what SQL gives, that I'd like to see cleanly
and comfortably and slickly integrated in ruby...

  * Relational Data model. Yup. I'm aware of the perfectly valid
    criticisms that SQL doesn't go anywhere near close enough to Codd's
    Laws... but it's one of the closest practical things that does. And
    yes, I'd love it if Ruby had a true relational algebra embedded  within it.

    Despite what various flavours of Object Oriented Analysis guru's
    will tell you....

    A class is _not_ a relation, an Object _is_ not a row, a Hash map
    from primary key to class instances is _not_ a table. So ORM / Db
    adapters try mash these notions together, but the semantics aren't
    quite the same.

    I bet we could use Ruby Mixins to designate and extend certain
    classes as tables.

    I bet we could find a really Good Ruby way of defining the Data
    Model that would be better than "create table". Indeed some of the
    ORM libraries mention are excellent examples of this.

  * Data Persistence. Yip, marshal and restore gives us that. But is
    that enough?
     - Indexes / updates and deletes?
     - Concurrent access?
     - Even if an application can persist it's object model it's
       incredibly useful to query, and access that same data model from a
       query tool, or (perhaps indirectly via view or a projection) by
       another (loosely related) application.

  * Data Model / Database Management. Whoops. Adding / deleting /
    renaming columns to a data table created via marshal / restore is
    painful.

  * Set operations (on things too big to fit in ram). We're Ruby
    programmers. We think procedurally. Can I recommend the book "The
    Art of SQL"?  http://books.google.co.nz/books?id=HfcMDvxb43AC

    It is a Good Reminder that screens and screens of procedural code can be
    rewritten as set op one liners.

  * ACID - Well, actually that would be kind of handy in a number of
    other areas not traditionally "Database".

  * Query Language - selects, joins, group by's, sorts. Rich and
    expressive stuff indeed.

  * Client / Server / Concurrency - Actually Ruby is very Good at that
    already, except there is no support for concurrency at the marshal
    and restore level.

Does this involve a multiyear rewrite of the core of Ruby?

Nah.

It involves folding in preexisting public domain code. Sqlite. No,_not_
at the C API level...
   http://sqlite.org/capi3.html

but folding in the appropriate parts of (select,update,delete,insert) of Sqlite's parse.y
   http://www.sqlite.org/br3317/artifact/405
into
   http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/parse.y?view=markup


John Carter                             Phone : [phone]
Tait Electronics                        Fax   : [phone]
PO Box 1645 Christchurch                Email : [e-mail]
New Zealand