Live data from Hacker News

Prolog language for PostgreSQL proof of concept

github.com

71–80 of 83 posts

Re: Prolog language for PostgreSQL proof of concept

#71

Earlier quoted context omitted.

What are you concerned about when using .NET?

For me, I just haven't enjoyed the developer experience. It's been a few years so take my opinions with a dash of salt but I find the language itself verbose, I should be freed of having to think about its memory layout because of garbage collection but I still end up thinking about it because of type boxing and enumerator-wrappers, the garbage collection routine itself is not as mature as other environments that I'm…

To clarify, Unity case is a massive night and day difference to what is expected to be "normal" language experience e.g. using ASP.NET Core/EF Core, AvaloniaUI, writing a CLI app or a systemd service, or GtkSharp even, or using Godot/Stride. This is due to GC being much slower and more punishing, very often completely different way of doing basic operations and it also (ab)using IEnumerators as coroutines which may make it seem that average usage of them is just as difficult (it's not). Performance is also significantly different, sometimes by an order of magnitude, even including Burst-compiled code.

Boxing is rarely something you have to think about if ever in general purpose code, nor is garbage collection outside of not insisting on doing things less efficient and often more painful way (doing int.Parse(text.Substring(0, 4)) over int.Parse(text.AsSpan(0..4)), something the analyzer prompts you to fix).

If you care about performance as indicated by message content, then any JVM language is a very big downgrade as many patterns are simply not expressible with it the way they are with C#/C++/Rust.

There are also significant differences in tooling as .NET one is much more aligned with what you expect from using Rust/Go/even Node interacting via CLI (dotnet build/run/publish).

Re: Prolog language for PostgreSQL proof of concept

#72

Earlier quoted context omitted.

CREATE TABLE edges ( source INT, target INT ); INSERT INTO edges (source, target) SELECT generate_series as source, generate_series + 1 as target FROM generate_series(0, 999); WITH RECURSIVE path_lengths AS ( -- Base case: Direct paths from edges SELECT source, target, 1 AS distance FROM edges UNION ALL -- Recursive step: Double the path length by joining on intermediate nodes SELECT p.source, e.target, p.distance +…

That's really not bad. I'm looking at CozoDB for a hobby project of mine, but if Logica could produce output like this consistently I'd probably prefer it because I'm much more familiar with maintaining RDBMSs.

Logica didn't output that. I posted SQL equivalent to the original Logica.

Re: Prolog language for PostgreSQL proof of concept

#74
post #48

Earlier quoted context omitted.

> If your entire database can be lifted into the application's heap, it's probably small enough that I wonder why you've got it stored in an RDBMS I think he meant lifting the database schema, not the whole database. This would help with auto completion and other static checks before trying to run queries.

Much much more important would be the foreign keys. If I remember my prolog correctly, this: parent(alice,bob). is duplicating information that could already be found in the schema's relationships.

Something like this! So that you can naturally query your data defining relationships and constraints

(This can already be done using joins, but that is not very ergonomical, especially when a lot of relations are at play)

Re: Prolog language for PostgreSQL proof of concept

#75

As a proof of concept, this looks very cool. Suggestion: add a short example to the README. I had one experience with Prolog in the 1980s that blew my mind. I had an IR&D project to build a complete prototype of an air/land battle simulator (yes, I was a defense contractor back then) in Common Lisp given 6 weeks of coverage to write it and demo it. After a month I was satisfied with the functionality and after demoin…

Can you explain a little about why / how you modeled a battle simulation in Prolog? To me, the most natural approach is simply a time-stepped battlespace model. With event uncertainty (e.g., did the bullet hit its target?) modeled as random draws that get baked into the outcome.

My speculative reaction: Prolog offers a way to describe an AI "commander" that can make plans that optimize for many units simultaneously. This technique is often used in strategy games, not usually with Prolog itself but using similar hand-written planner algorithms in tandem with FSMs.

One of the downsides of this approach where it appears in games is that it results in unit behaviors that look robotic and overly micromanaged, often using tactics similar to early computer chess AI.

Re: Prolog language for PostgreSQL proof of concept

#76
post #53

As a proof of concept, this looks very cool. Suggestion: add a short example to the README. I had one experience with Prolog in the 1980s that blew my mind. I had an IR&D project to build a complete prototype of an air/land battle simulator (yes, I was a defense contractor back then) in Common Lisp given 6 weeks of coverage to write it and demo it. After a month I was satisfied with the functionality and after demoin…

This reminds me of an old idea I’ve toyed with. In a logic class in university we talked about how some logic is time dependent, like A is true 2 hours after B becomes true. I was inspired to try to think through a language like prolog that could model and solve these relations through time. Didn’t get far with it since it’s a hard problem and I had too many classes that term. I was thinking it would be useful for cl…

It is called Temporal logic or tense logic[1][2]. Linear time temporal logic is used in formal verification.

[1] https://plato.stanford.edu/entries/logic-temporal/

[2] https://en.wikipedia.org/wiki/Temporal_logic

Re: Prolog language for PostgreSQL proof of concept

#77

As a proof of concept, this looks very cool. Suggestion: add a short example to the README. I had one experience with Prolog in the 1980s that blew my mind. I had an IR&D project to build a complete prototype of an air/land battle simulator (yes, I was a defense contractor back then) in Common Lisp given 6 weeks of coverage to write it and demo it. After a month I was satisfied with the functionality and after demoin…

What about it blew your mind?

Are you implying it's because a rewrite took less time than the first version?

Re: Prolog language for PostgreSQL proof of concept

#78
post #15

Love this, I've long considered that this should've been made as Prolog and SQL are ternary logic and basically SQL derives from Datalog and it itself from Prolog. A table record can be taught as of as a Prolog fact, so this makes the WHERE clauses the predicates in the conjunction on the right-hand side of a rule. And then exhausting the goal is actually returning the result-set. Hope to see this develop even furthe…

WHy do you say that Prolog is ternary? It ssemantics are roughly those of predicate logic that is bivalent. In Prolog a "query" can either succeed or fail, i.e. be true or false, or raise an error- are you counting errors as a third truth value?

Re: Prolog language for PostgreSQL proof of concept

#79
post #34

Earlier quoted context omitted.

Sure, a few organizations may actually need some obscure feature that Oracle provides, but again, it's niche. For most companies, Postgres provides way more features than they will ever use. And for the other 1%, it sometimes happens that their need for a specific feature in Oracle DB turns out to be entirely unnecessary. Not to mention that the vast majority of products turn out to be fancy CRUD apps. Doesn't matter…

The main enterprise-necessary feature missing in Postgres compared to Oracle is free trips to the Bahamas.

I am sure companies selling Postgres support to Fortune 100, can think out of something to please corporate sales team.

Re: Prolog language for PostgreSQL proof of concept

#80
post #15

Love this, I've long considered that this should've been made as Prolog and SQL are ternary logic and basically SQL derives from Datalog and it itself from Prolog. A table record can be taught as of as a Prolog fact, so this makes the WHERE clauses the predicates in the conjunction on the right-hand side of a rule. And then exhausting the goal is actually returning the result-set. Hope to see this develop even furthe…

WHy do you say that Prolog is ternary? It ssemantics are roughly those of predicate logic that is bivalent. In Prolog a "query" can either succeed or fail, i.e. be true or false, or raise an error- are you counting errors as a third truth value?

well the ternary thing about SQL is that it has this NULL/unknown, and it can be demonstrated with the outer joins.

Then SQL being a slang of DataLog, which comes from Prolog implies Prolog is ternary, no? Indeed Prolog's handling of "unknown" is more procedural than a true ternary logic.

So it has slightly different notion. Even though I'm more a Prolog amateur (s.o. who loves it), a a failed query in Prolog implies the unknown state. It's about the provability within the system, not about a third truth value.

Post reply on HN