Hacker News Reader

Comment by klodolph | Hacker News Reader

> Having done a bit of Prolog programming in the dim and distant past, my intuition is that trying to make everything declarative is a mistake...

Calling Prolog "declarative" or "logical" is just marketing. Prolog is really built around two concepts: unification and backtracking. This produces a system that can be used as a general-purpose language, but you will probably get more mileage thinking about it as a database engine, capable of expressing non-finite relations. Compare it to SQL, which only supports finite relations (finite number of rows in each table). Indeed, optimizing Prolog compilers will remind you more of SQL engines -- optimizing Prolog compilers produce indexes, does that sound familiar?

View on HN

Yeah, I've always wished that I could query my SQL databases with Prolog. It's really so much more powerful than SQL, and allows you to actually create abstractions, rather than repeating yourself endlessly in joining tables together or using clunky views.

You might be interested in Datomic.

"Datomic embeds Datalog, a subset of Prolog, to move queries into the application." (http://www.infoq.com/news/2012/03/clojure-west)

Everything that you say is true. Thinking in Prolog does have something of the same flavor & texture as thinking in SQL. (Although my experience with both is limited & somewhat rusty at the moment). However, I seem to recall that one of the philosophical goals of Prolog was to provide the ability to write "executable specifications", and, if I recall correctly, Prolog programs seemed to me to be (at least on the small scale) pretty declarative in nature, although (as with SQL), attempting to write a fast, highly performant program required an understanding of what the machine was doing "under the hood".

You are right, but what I tell my programmers: if you want high performant SQL-query you can make 2 things: 1. Think carefully about data and write generic SQL without any DBMS specifics 2. Try to optimize everything with your DBMS specifics

The latter - almost never works. Be it Oracle, MSSQL, DB2 or PostgreSQL.

And even when it works - it's unacceptable.

We had a query in Oracle that executed several hours. Our Oracle DBA found a way to tweak Oracle that shrinked it to 30 minutes. It was interesting, but impossible to use in practice - we could not guarantee that other queries will go fine with this server settings. (Our DBA was the first who was against using in production)

Reply on news.ycombinator.com