←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 #
aseipp ◴[] No.42159072[source]
Logica is in the Datalog/Prolog/Logic family of programming languages. It's very familiar to anyone who knows how to read it. None of this has anything to do with OOP at all and you will heavily mislead yourself if you try to map any of that thinking onto it. (Beyond that, and not specific to Logica or SQL in any way -- comparing two 3-line programs to draw conclusions is effectively meaningless. You have to actually write programs bigger than that to see the whole picture.)

Datalog is not really a query language, actually. But it is relational, like SQL, so it lets you express relations between "facts" (the rows) inside tables. But it is more general, because it also lets you express relations between tables themselves (e.g. this "table" is built from the relationship between two smaller tables), and it does so without requiring extra special case semantics like VIEWs.

Because of this, it's easy to write small fragments of Datalog programs, and then stick it together with other fragments, without a lot of planning ahead of time, meaning as a language it is very compositional. This is one of the primary reasons why many people are interested in it as a SQL alternative; aside from your typical weird SQL quirks that are avoided with better language design (which are annoying, but not really the big picture.)

replies(3): >>42159145 #>>42159449 #>>42159858 #
joe_the_user ◴[] No.42159858[source]
It's very familiar to anyone who knows how to read it.

"Anyone who know the system can easily learn it" he said with a sniff.

Yes, the similarity to Prolog lets you draw on a vast pool of Prolog programmers out there.

I mean, I studied a variety of esoteric languages in college and they were interesting (I can't remember if we got to prolog tbh but I know 1st logic pretty well and that's related). When I was thrown into a job with SQL, it's English language syntax made things really easy. I feel confident that knowing SQL wouldn't oppositely make learning Prolog easy (I remember Scala later and not being able to deal with it's opaque verbosity easily).

Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake.

replies(2): >>42159988 #>>42160091 #
jyounker ◴[] No.42159988[source]
> Basically, SQL syntax makes easy things easy. This gets underestimated a lot, indeed people seem to have contempt for it. I think that's a serious mistake.

The flip side of that is SQL makes hard things nearly impossible.

SQL doesn't have facilities for abstraction, and it doesn't compose, and this has consequences that I deal with daily.

The lack of abstract facilities makes it hard to construct complicated queries, it makes it hard to debug them, and it makes it hard refactor them.

Instead of writing more complicated SQL queries, developers lean on the host languages to coordinate SQL calls, using the host language's abstraction facilities to cover for SQL's inadequacies.

replies(1): >>42160103 #
1. joe_the_user ◴[] No.42160103[source]
The flip side of that is SQL makes hard things nearly impossible.

What about SQL syntax makes the hard things possible? I get that the actual language SQL is broken in all sorts of ways. But I don't see any reason to replace it with some opaque from get-go.

I mean, what stops you from defining, say adjectives and using those for rough modularity.

Say

    EXPENSIVE(T) means T.price > 0;
    Select name FROM books WHERE EXPENSIVE(books); 
Seems understandable.
replies(2): >>42162433 #>>42198564 #
2. geocar ◴[] No.42162433[source]
Isn't that just WITH?

    WITH expensive AS (SELECT * FROM books WHERE price > 100)
    SELECT name FROM expensive
3. jyounker ◴[] No.42198564[source]
Yes, you can extend the language with more syntax. This kind of proves my point.

If there weren't deficiencies then you wouldn't need to define more syntax, and so many work-arounds wouldn't have already been created. The deficiencies in SQL are why each big SQL database ends up creating some procedural-SQL language for use in stored procedures and triggers.

CTEs are close to what you outline above, but even then (as far as I know) you can't name that CTE and use it across multiple statements.