Hacker News new | ask | show | jobs
by geysersam 1302 days ago
I think one of the biggest counter examples to your argument is SQL.

It's been around a long time. It's not general purpose. It's considered the best option there is if your setup allows you to use it.

5 comments

SQL persists because it's an interchange format, not just a programming language. It's one of the few programming languages you'll see embedded in other languages - and generating SQL from other languages is a common source of security bugs. You can't upgrade away from SQL without changing both ends of that connection.

You can write large programs in SQL, but it's generally considered good practice not to.

(I feel I ought to mention LINQ here, not to make any specific point but just to fanboy about it)

For LINQ, I personally vastly prefer the fluent version (IEnumerable.Select(..).Where(...) and so on) over the SQl like syntax.
same, and in fact, despite using C# since before LINQ even existed, I don't even know how to write the sugar candy version of it.

Part of that is me coming from C++ and its algorithm header and the other part is that the code is just easier to read and understand than the sugar candy version (to me, atleast).

As to not repeat the same argument: https://news.ycombinator.com/item?id=33704199
It's still quite little compared to general purpose languages with similar expressive power in the same domain.
Plenty of people prefer language-integrated things like LINQ over SQL, although we can argue whether or not LINQ represents a kind of DSL.
SQL is a beast of a language and there's definitely room for improvement. Also it's not Turing complete
Mysql 8 is turing complete with the recursive common table expressions
Somewhat pedantic argument: SQL is kinda dead. Sure, modern databases use upgraded dialects of it, but they are custom to each database and often incompatible with plain SQL. There are even many cases where modern databases don't support even standardized SQL constructs.

The easiest example of where databases and SQL part ways: UPSERT. It doesn't exist in standard SQL.

ref. https://jakewheat.github.io/sql-overview/sql-2016-foundation...

Many modern products use SQL. Supabase and BigQuery comes to mind, but the examples are basically inumerable.

There are others of course. But I'd rather call SQL challenged (by graphql etc.) than dead.

SQL has MERGE
Forest for the trees, my dude.
Then let me address the forest. Modern DBs offer SQL as an on-ramp for the most common DML and querying. This further entrenches it as a data language and why SQL just won't die.

There are always more proprietary methods where one needs them. That doesn't mean SQL is dying, it means SQL will likely grow to include some of those too.