4 ms·

I have plenty of gripes about SQL but am not aware of any real alternatives ... which I do find bizarre - in the realm of programming languages in general we li

I have plenty of gripes about SQL but am not aware of any real alternatives ... which I do find bizarre - in the realm of programming languages in general we live in a time of Cambrian explosion in terms of the number and type of languages being used and developed, and yet SQL sits aloof and unassailable on its pedestal. There are a number of clear paths not taken: 1/ A new, better language that compiles down to SQL; 2/ A set of enhancements to SQL that compile down to regular SQL (<= best imo); 3/ A new language that compiles down to the same AST that is generated from SQL: this of course would need to be done by the database implementors. That we don't see this I attribute to: 1/ Perception that SQL is "good enough". Which is true as far as it goes, but again odd compared with the endless innovation in the world "normal" programming languages; 2/ Innate conservativism of the database tech community; 3/ Wide use of tools that already sit on top of SQL - query builder APIs, ORMs etc.

garysieling 10y ago
I've wondered about this too. I think ORMs serve effectively the same purpose as Javascript transpilers (which gives you 1 & 2) You can also write stored procedures in Postgres in other languages.
- __jal 10y ago
  ORMs attempt to bridge object and relational models. (With results that vary from "works fairly well" to "screw it, give me a DB handle and I'll just write SQL".) I see what you're saying, but they operate at a different place than generators/translators. Stored procedures are just that - they get a name and persistence. PLSQL has procedural extensions, but it is still SQL. Fabian Pascal (who has made a career out of SQL criticism) proposed a replacement system called Raquel that would have a "real" set-theory-based query language. I don't think it went anywhere. My best guess as to why there aren't many alternatives: SQL is both mature and Good Enough(tm), but importantly, also unsexy and complicated. Database engine development is more similar to kernel development than, say, web application development, and there are simply far fewer engineers qualified to do it. Building some framework in Javascript currently gets a ton of love, and in comparison is far easier than developing a SQL replacement that is roughly as performant as SQL and either less awkward linguistically or functionally superior. People do take up those sorts of projects, but they're pretty lonely unless some combination of talent, luck, and timing turns into rock star status (Linus wasn't the only one writing unix clones at the time).
  - dancek 10y ago
    > Stored procedures are just that - they get a name and persistence. PLSQL has procedural extensions, but it is still SQL. PostgreSQL distributions come with support for PL/Python, PL/Tcl, PL/Perl and PL/pgSQL (a PostgreSQL specific PL/SQL clone). Other languages exist, but aren't included. See https://www.postgresql.org/docs/9.6/static/external-pl.html https://www.postgresql.org/docs/9.6/static/external-pl.html
    - __jal 10y ago
      Yes. And PL/Perl is perversely fun. I don't think I've ever seen other languages used in production, though[1]; I think folks tend to stick to PLSQL because of defaults. [1] I'm sure people do, but this discussion has an anecdata deficiency.

garysieling 10y ago

I've wondered about this too. I think ORMs serve effectively the same purpose as Javascript transpilers (which gives you 1 & 2) You can also write stored procedures in Postgres in other languages.

__jal 10y ago
ORMs attempt to bridge object and relational models. (With results that vary from "works fairly well" to "screw it, give me a DB handle and I'll just write SQL".) I see what you're saying, but they operate at a different place than generators/translators. Stored procedures are just that - they get a name and persistence. PLSQL has procedural extensions, but it is still SQL. Fabian Pascal (who has made a career out of SQL criticism) proposed a replacement system called Raquel that would have a "real" set-theory-based query language. I don't think it went anywhere. My best guess as to why there aren't many alternatives: SQL is both mature and Good Enough(tm), but importantly, also unsexy and complicated. Database engine development is more similar to kernel development than, say, web application development, and there are simply far fewer engineers qualified to do it. Building some framework in Javascript currently gets a ton of love, and in comparison is far easier than developing a SQL replacement that is roughly as performant as SQL and either less awkward linguistically or functionally superior. People do take up those sorts of projects, but they're pretty lonely unless some combination of talent, luck, and timing turns into rock star status (Linus wasn't the only one writing unix clones at the time).
- dancek 10y ago
  > Stored procedures are just that - they get a name and persistence. PLSQL has procedural extensions, but it is still SQL. PostgreSQL distributions come with support for PL/Python, PL/Tcl, PL/Perl and PL/pgSQL (a PostgreSQL specific PL/SQL clone). Other languages exist, but aren't included. See https://www.postgresql.org/docs/9.6/static/external-pl.html https://www.postgresql.org/docs/9.6/static/external-pl.html
  - __jal 10y ago
    Yes. And PL/Perl is perversely fun. I don't think I've ever seen other languages used in production, though[1]; I think folks tend to stick to PLSQL because of defaults. [1] I'm sure people do, but this discussion has an anecdata deficiency.