←back to thread

171 points voat | 3 comments | | HN request time: 0.412s | source
Show context
thenaturalist ◴[] No.42158900[source]
I don't want to come off as too overconfident, but would be very hard pressed to see the value of this.

At face value, I shudder at the syntax.

Example from their tutorial:

EmployeeName(name:) :- Employee(name:);

Engineer(name:) :- Employee(name:, role: "Engineer");

EngineersAndProductManagers(name:) :- Employee(name:, role:), role == "Engineer" || role == "Product Manager";

vs. the equivalent SQL:

SELECT Employee.name AS name

FROM t_0_Employee AS Employee

WHERE (Employee.role = "Engineer" OR Employee.role = "Product Manager");

SQL is much more concise, extremely easy to follow.

No weird OOP-style class instantiation for something as simple as just getting the name.

As already noted in the 2021 discussion, what's actually the killer though is adoption and, three years later, ecosystem.

SQL for analytics has come an extremely long way with the ecosystem that was ignited by dbt.

There is so much better tooling today when it comes to testing, modelling, running in memory with tools like DuckDB or Ibis, Apache Iceberg.

There is value to abstracting on top of SQL, but it does very much seem to me like this is not it.

replies(4): >>42158997 #>>42159072 #>>42159873 #>>42162215 #
Tomte ◴[] No.42158997[source]
The syntax is Prolog-like, so people in the field are familiar with it.
replies(1): >>42159153 #
1. thenaturalist ◴[] No.42159153[source]
Which field would that be?

I.e. I understand now that it's seemingly about more than simple querying, so me coming very much from an analytics/ data crunching background am wondering what a use case would look like where this is arguably superior to SQL.

replies(2): >>42159739 #>>42174951 #
2. tannhaeuser ◴[] No.42159739[source]
> Which field would that be?

Database theory papers and books have used Prolog/Datalog-like syntax throughout the years, such as those by Serge Abiteboul, just to give a single example of a researcher and prolific author over the decades.

3. evgskv ◴[] No.42174951[source]
In my opinion any analytical query is easier to read in logic language than in SQL. But it's most obvious for recrusive querries. E.g. distance in graph defined by predicate (aka table) G written in Logica looke like:

  D(a, b) Min= 1 :- G(a, b);       # Connected by an edge => distance 1.
  D(a, c) Min= D(a, b) + D(b, c);  # Triangle inequality.
 
It will be much harder to read with SQL CTE. It can also computed over weighted graphs, which is impossible or extremely hard with SQL.

In practice you rarely need recursive querries, so gap between Logica and SQL isn't as large as it is here, but Logica is easier to read (in my opinion) for similar reasons.