[osm3000]

I studied prolog back in 2014. It was used in AI course. I found it very confusing: trying to code A*, N-Queens, or anything in it was just too much. Python, in contrast, was a god-send. I failed the subject twice in my MSc (luckily passing the MSc was based on the total average), but did a similar course in UC Berkeley, with python: aced it, loved it, and learned a lot.

Never again :D

[freitzzz]

A similar thing happened at my university in an Advanced Algorithms course. Students failed it so much, the university was forced to make the course easier to pass, by removing the minimum grade to pass.

I believe your case (and many other students) is that you couldn't abstract yourself from imperative programming (python) into logic programming (prolog).

[scotty79]

It's a query language for graph database. You can write A* and N-Queens in SQL, but why?

[hunterpayne]

Performance, far better performance. Same reason you ever use SQL. Prolog can do the same thing for very specific problems.

PS Prolog is a Horn clause solver. You characterizing it as a query language for a graph database, well it doesn't put you in the best light. It makes it seem like you don't understand important foundational CS math concepts.

[scotty79]

I have no idea why are you dissing query languages. Software that makes those work is immensely complex and draws on a ton of CS math concepts and practical insights. But maybe you don't understand that.

I'm using SQL to do SQL things. And I'm sure when I somehow encounter the 1% of problems that prolog is the right fit for I'd be delighted to use it. However doing general algorithms in Prolog is as misguided as in SQL.

[hunterpayne]

> I have no idea why are you dissing query languages.

I'm not. I'm pointing out that saying a Horn clause interpreter is a graph query language indicates a fundamental misunderstanding on your part. Prolog handles anything you want to say in formal logic very well (at the cost of not doing anything else well).

SQL on the other handle uses a completely different mathematical framework (relational algebra and set theory). This allows really effective optimization and query planning on top of a DB kernel.

A graph DB query language on the other hand should be based upon graph theory. Which is another completely different mathematical model. I haven't been impressed by the work in this area. I find these languages are too often dialects of SQL instead of a completely different thing based upon the correct mathematical model.

PS I used to write DBs. Discretion is the better part of valor here.