Imperative Thinking and the Making of Sandwiches (2014)
scattered-thoughts.net
scattered-thoughts.net
Fourth-generation programming languages is hardly a new idea. I don't know, I think we need to see a trend going both ways. Software today is so bloated; I think that's a symptom of fewer programmers having a good intuition about what's happening near the metal.
Software is bloated because we modify and patch together existing solutions instead of designing from first principles, because we think that more is better and because we are too afraid to say no. In essence we are too reactive and short term oriented.
---
An aside:
Bloat and amount of functionality are not necessarily equal. There are systems that have evolved since decades and have stood the test of time because they incorporate additive evolution such as the JVM, Emacs, Linux, the Web...
Something that grows because it enables growth is not the same as something that is large because stuff was piled on top of it in an ad-hoc manner. Calling the former "bloated" would be unfair.
---
SQL or rather relational thinking and expression is something that by its nature reduces complexity, because it lets you express the essence of a given model without introducing control and state (at the interface).
What you are criticizing is fair: it is a leaky abstraction because at some point you are forced to think about performance and the initially beautiful model becomes limiting. But it does solve the "make it work" and "make it beautiful" parts very well for a large category of problems.
And this was, in a way, the point of the article. It was explicitly mentioned that the desired thing isn't some wide abstraction hiding everything, backed by a Sufficiently Smart Compiler that makes it Do What I Mean. No, the desired state is good enough abstractions plus interactive usage.
In SQL case: you write your query, run EXPLAIN on it, notice it'll run slow because $reasons, add an index, rerun EXPLAIN, ...
Rather than expressing SQL in each language, I'd rather mix SQL with whatever language I am using.
There are simple affordances that can happen at the tooling level to make SQL a first-class part of other languages. E.g. instead of having to use strings for SQL fragments, or 'change language' with special preambles, the language and tools could seamlessly work out that SELECT is entering an SQL mode and so on.
This brings SQL into the code-base in a much better way.
const sql = require('mssql')
const query = sql.query`select * from mytable where id = ${value}`
For everyone else, I think "tagged" string literals in general are a great compromise. You don't have to add extra syntax to the language (no need for regex literals like /^foo/ if you can write something like regex"^foo"), but you can statically signal to your dev tools that the string might require highlighting or other analysis. The downside is that you are passing around a string and not an AST or something comparable if you really do need to do complicated code generation type of work, but maybe the ideal world is to have both tagged string literals and an abstract representation.
The prepared statement technique I think is used in Python as well, at least in the SQLite library (maybe the ODBC library as well). Whereas e.g. libpq has an API function for executing a query with parameters. So the Postgres version of this wouldn't return a prepared statement, but some kind of opaque object that specifies what exactly will be fed to libpq upon query execution.
(edit) DataGrip has it too. You connect to the database and the IDE offers autocompletion for tables and columns and checks for corectness. SQL dialect can be set in Ultimate/DataGrip.
K or LINQ?