Database languages (was Re: Macros Make Me Mad)

[Neel Krishnaswami <address@hidden>]

Sundar Narasimhan writes:
>    It's not because of macros, but because it has a SQL sublanguage
>    integrated deeply into it. 
> 
> Thanks Neel. I agree that the integration of SQL w/ the language
> datatype *is* the big win (and loss) w/ PL/SQL. I thought you were
> going to point out some creative way of using DBMS_SQL :).

I've had to use DBMS_SQL far too frequently, and quickly grew to
dislike it -- it's so verbose! ODBC looks a lot like it, and that's
one of the reasons I'd want to wrap it.

> Personally I've never cared too much for the syntax checking ability
> of PL/SQL (wrt. column datatypes etc.) -- I know it's there, but
> given %type and other such facilities, I rarely stumble across that
> type of error any more. 

One thing that I found painful with its type checking was the fact
that all columns and table names had to be resolved at compile time.
This meant you couldn't write queries that were parameterized across
different tables without using DBMS_SQL. A more modern type system
would have let you do that, for a significant productivity win.

> Personally speaking, if any of the LL languages could demonstrate
> such deep integration w/ SQL (esp. wrt dynamic tables etc.) that
> could be something genuinely new and worth looking into.

It seems like most of the internal applications people write these
days involve database access. My own job was data-mining hooked up
to a SQL database. I'd have loved to use a matrix language that knew
SQL.

-- 
Neel Krishnaswami
neelk@alum.mit.edu