[mieko]

The SQL language design is more contemporary to COBOL than anything we'd choose to use today.

That's not implying that large, successful projects cannot be built upon SQL. We see them in the real world all the time.

We have awesome implementations of the language, but any productivity is in spite of a quirky language designed in the early 1970s, not because of it.

[qsort]

It's a spurious comparison. I wouldn't pick COBOL as part of my stack for a greenfield project. I would definitely 100% pick SQL as part of my stack for a greenfield project.

[mieko]

Because COBOL has been replaced with better languages for most purposes. SQL is entrenched. I'd also pick SQL for a greenfield project, because... what else?

This says nothing about the quality of SQL as a language.

What I think is more interesting is: if you were to greenfield a language for a relational database, how much would it look like SQL?

[samatman]

I have a better comparison.

It is as though we lived in a world where, like our own, Lisp invented garbage collection. But unlike our own world, in 2022, Lisp is the only garbage collected language anyone uses. Others were invented but that mostly stopped by the 80s.

Many people would like to replace Lisp, and keep in mind this is Lisp so lexical scope is only available in some implementations and people who want cross-platform compatibility don't use it. But without it, you have to manage your own memory.

That's SQL and relational databases. Relational databases with ACID guarantees aren't optional, they aren't a nice-to-have, they're foundational.

And we talk to them in SQL because... we talk to them in SQL.

[ako]

If it has survived this long without being replaced by something better it must be really good.