3 ms·

SQL queries make me anxious. I don't pretend to know what optmizations the compiler does to my C++ code, or the details of the cache, but at least I have a ment

SQL queries make me anxious. I don't pretend to know what optmizations the compiler does to my C++ code, or the details of the cache, but at least I have a mental model of what goes on under the hood which reflects the ballpark algorithmic complexity of my code. Even languages disavowing pointer logic make me a bit uneasy in this respect. 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.

dgb23 5y ago
You are looking at this with a performance lens and I appreciate that. Performance is important. But I think the issue is more general. 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.
ksherlock 5y ago
Most SQL engines have an EXPLAIN / EXPLAIN PLAN statement.
- TeMPOraL 5y ago
  Yup. For me, this is very much anxiety-removing. 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, ...

dgb23 5y ago

You are looking at this with a performance lens and I appreciate that. Performance is important. But I think the issue is more general. 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.

ksherlock 5y ago

Most SQL engines have an EXPLAIN / EXPLAIN PLAN statement.

TeMPOraL 5y ago
Yup. For me, this is very much anxiety-removing. 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, ...