6 ms·

We've been writing SQL for decades without such complaints and it works rather well in practice. Speak for yourself. My experience of SQL is that it requires c

We've been writing SQL for decades without such complaints and it works rather well in practice. Speak for yourself. My experience of SQL is that it requires careful tuning whenever the numbers involved grow beyond the trivial. Query plans need inspecting, and often indexes aren't used appropriately. Queries are written and rewritten several different ways to encourage the database to choose one plan or another. If your use of a database is limited to key-value lookups and object graph navigation with an ORM, with <100 values on any given edge, you'll have a fine time, I'm sure. Not everybody uses databases that could trivially be replaced with an object graph. For more complex operations, I'd like to be able to write in the form of a plan with a graph of data flow directly. Scan this table, filter against this index, sort these two data sources and do an merge anti-join, etc. Today, I need to rewrite the query while knowing the planner well enough to foresee how it's going to implement my query, gradually homing in on my target through a series of indirect inspections.

agentultra 9y ago
> Speak for yourself. Fair enough. I use PostgreSQL quite heavily at present and do not use ORMs. I'd guess, probably optimistically, that 80% of the non-trivial queries I write are easily optimized by the query planner and require no further thought from me. In my experience these aren't the majority of the queries I write. The final 20% of these queries are the hard ones that, as you say, require some work and re-writing to get the query planner to choose an appropriate plan. At least I find the tooling in PostgreSQL to be more than ample to assist in optimization tasks. The spirit of my example of SQL is that we already use declarative programming languages in mainstream systems. Even with recursive queries and common table expressions I think, and I may be wrong, that Prolog is probably more general-purpose and expressive than SQL. And yet it's not nearly as popular for some reason.
- PeterisP 9y ago
  Well, but SQL is actually a quite good illustration of the reasons why Prolog isn't popular. I mean, you technically can write all of application functionality in many dialects of SQL, but it's generally considered a bad idea to do so for obvious reasons - SQL is good for some tasks, but for everything else other languages are preferred. In a similar manner, even in tasks ideally suited for Prolog's strengths (e.g. reasoning systems) that part of the task will be relatively small - in any practical system, the "boring" code of integrating everything with everything else, handling a graphical UI, mangling data from one format to another, wrapping it in a REST web API and god knows what else will be at least 3-10 times larger than the core part of that task. I recall an old project where we had the core algorithms in Prolog, but the surrounding app in Java - the fact that the Java code was much more than 20 times bigger wasn't a verbosity issue, it actually did 10 times more stuff; although it was quite boilerplate, it all was needed and it was clearly simpler/faster/cheaper to make it in Java back then rather than do everything in Prolog. It's not sufficient for a language to make the hard (or domain specific) things possible, it also needs to make all the easy things easy, and Prolog really does not. So the language either needs to be truly general purpose (and "more general-purpose than SQL" isn't sufficient) or easily integrated with other languages. There are successful examples - for example, tensorflow->python, where again the actual ML part for anything more than proof-of-concept is much, much smaller than the surrounding general purpose python code; or SQL, which is well integrated into other languages. In another post you mention "I've written declarative DSLs for a solver engine" - why it wasn't trivial (compared to writing a new DSL) to include some Prolog code as the DSL inside the app as easily as people include SQL in their apps as the DSL for managing data? There's your answer for why it's not nearly as popular.
jrochkind1 9y ago
> My experience of SQL is that it requires careful tuning whenever the numbers involved grow beyond the trivial. Depending on what you mean by "trivial", that can be syllogistically true, but if so, then a LOT of useful work can and is done in the realm of the 'trivial numbers involved'.
pacala 9y ago
Great point. An elementary feature of a SQL engine is exposing the query plan itself in a compact humanly readably format. Is there an equivalent for Prolog implementations?

agentultra 9y ago

> Speak for yourself. Fair enough. I use PostgreSQL quite heavily at present and do not use ORMs. I'd guess, probably optimistically, that 80% of the non-trivial queries I write are easily optimized by the query planner and require no further thought from me. In my experience these aren't the majority of the queries I write. The final 20% of these queries are the hard ones that, as you say, require some work and re-writing to get the query planner to choose an appropriate plan. At least I find the tooling in PostgreSQL to be more than ample to assist in optimization tasks. The spirit of my example of SQL is that we already use declarative programming languages in mainstream systems. Even with recursive queries and common table expressions I think, and I may be wrong, that Prolog is probably more general-purpose and expressive than SQL. And yet it's not nearly as popular for some reason.

PeterisP 9y ago
Well, but SQL is actually a quite good illustration of the reasons why Prolog isn't popular. I mean, you technically can write all of application functionality in many dialects of SQL, but it's generally considered a bad idea to do so for obvious reasons - SQL is good for some tasks, but for everything else other languages are preferred. In a similar manner, even in tasks ideally suited for Prolog's strengths (e.g. reasoning systems) that part of the task will be relatively small - in any practical system, the "boring" code of integrating everything with everything else, handling a graphical UI, mangling data from one format to another, wrapping it in a REST web API and god knows what else will be at least 3-10 times larger than the core part of that task. I recall an old project where we had the core algorithms in Prolog, but the surrounding app in Java - the fact that the Java code was much more than 20 times bigger wasn't a verbosity issue, it actually did 10 times more stuff; although it was quite boilerplate, it all was needed and it was clearly simpler/faster/cheaper to make it in Java back then rather than do everything in Prolog. It's not sufficient for a language to make the hard (or domain specific) things possible, it also needs to make all the easy things easy, and Prolog really does not. So the language either needs to be truly general purpose (and "more general-purpose than SQL" isn't sufficient) or easily integrated with other languages. There are successful examples - for example, tensorflow->python, where again the actual ML part for anything more than proof-of-concept is much, much smaller than the surrounding general purpose python code; or SQL, which is well integrated into other languages. In another post you mention "I've written declarative DSLs for a solver engine" - why it wasn't trivial (compared to writing a new DSL) to include some Prolog code as the DSL inside the app as easily as people include SQL in their apps as the DSL for managing data? There's your answer for why it's not nearly as popular.

jrochkind1 9y ago

> My experience of SQL is that it requires careful tuning whenever the numbers involved grow beyond the trivial. Depending on what you mean by "trivial", that can be syllogistically true, but if so, then a LOT of useful work can and is done in the realm of the 'trivial numbers involved'.

pacala 9y ago

Great point. An elementary feature of a SQL engine is exposing the query plan itself in a compact humanly readably format. Is there an equivalent for Prolog implementations?