4 ms·

Imperative Thinking and the Making of Sandwiches (2014)

33 points by luu 5y ago

willvarfar 5y ago
> So what would a general purpose language look like if it took these ideas to heart? 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.
- nerdponx 5y ago
  JavaScript actually has a nice syntax for this, called "template literals", specifically "tagged template literals" that can be used to represent things like SQL or GraphQL queries [0]: const sql = require('mssql') const query = sql.query`select * from mytable where id = ${value}` [0]: https://github.com/tediousjs/node-mssql https://github.com/tediousjs/node-mssql
  - mypalmike 5y ago
    Interesting that this gets treated as a prepared statement. I wonder if it might have the drawback, among less experienced developers, of encouraging the use of simple string substitution in queries because it looks so much like that's what's happening.
    - nerdponx 5y ago
      Possibly. In my experience, newbies use string interpolation because don't even know that parameterized queries exist. Once they know about it and why it's important, they generally start using it without hesitation. 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.
- scns 5y ago
  Some IDEs by Jetbrains have this feature, Ultimate for sure. Google has added it for SQLite in Android Studio IIRC. (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.
chrispsn 5y ago
> So what would a general purpose language look like if it took these ideas to heart? K or LINQ?
arketyp 5y ago
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, ...
zvr 5y ago
Always fun to watch the following of (imperative) instructions for making a sandwich: https://www.youtube.com/watch?v=cDA3_5982h8 https://www.youtube.com/watch?v=cDA3_5982h8
univacky 5y ago
I can't be the only one who was waiting for this reference: https://xkcd.com/149/ https://xkcd.com/149/

33 points by luu 5y ago

> So what would a general purpose language look like if it took these ideas to heart? 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.

nerdponx 5y ago
JavaScript actually has a nice syntax for this, called "template literals", specifically "tagged template literals" that can be used to represent things like SQL or GraphQL queries [0]: const sql = require('mssql') const query = sql.query`select * from mytable where id = ${value}` [0]: https://github.com/tediousjs/node-mssql https://github.com/tediousjs/node-mssql
- mypalmike 5y ago
  Interesting that this gets treated as a prepared statement. I wonder if it might have the drawback, among less experienced developers, of encouraging the use of simple string substitution in queries because it looks so much like that's what's happening.
  - nerdponx 5y ago
    Possibly. In my experience, newbies use string interpolation because don't even know that parameterized queries exist. Once they know about it and why it's important, they generally start using it without hesitation. 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.
scns 5y ago
Some IDEs by Jetbrains have this feature, Ultimate for sure. Google has added it for SQLite in Android Studio IIRC. (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.

chrispsn 5y ago

> So what would a general purpose language look like if it took these ideas to heart? K or LINQ?

arketyp 5y ago

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, ...

zvr 5y ago

Always fun to watch the following of (imperative) instructions for making a sandwich: https://www.youtube.com/watch?v=cDA3_5982h8 https://www.youtube.com/watch?v=cDA3_5982h8

univacky 5y ago

I can't be the only one who was waiting for this reference: https://xkcd.com/149/ https://xkcd.com/149/