Live data from Hacker News

Ask HN: What's Prolog like in 2024?

news.ycombinator.com

181–190 of 289 posts

Re: Ask HN: What's Prolog like in 2024?

#181

Prolog, and Constraint Programming especially are great to have in your toolbox. I’ve done research in the field for years, and my job in the industry today is writing Prolog. There are real issues with Prolog: - no proper module nor package system in the modern sense. - in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided un…

I'd advise to not use Prolog as general-purpose programming language, but as an embedded DSL or as a service for the part it's really suited for (if your app involves exploration and search over a large combinatorical space in the first place, such as in discrete optimization in industry, logistics, and finance). You really don't need yet another package manager and pointless premature modularization for modelling yo…

At this point, why not use one of the many other CP solver packages out there and the layers on top like OR-tools?

Re: Ask HN: What's Prolog like in 2024?

#182
post #162

Earlier quoted context omitted.

> A few dedicated clever people and idealists and dreamers talking about ontologies and building things I don't understand I was briefly deeply interested in ontologies via OWL and I suspect Prolog has the same issues that I think plague ontologies in general. They are a fantastic tool for a system complex enough to be nearly useless. Modelling an ontology for a reasonably complex domain is unreasonably difficult. No…

This is why Lenat and CYC had settled on micro-theories. They found it impossible to build a useful universal ontology so had to fracture them on domain boundaries.

I was just pondering if the Prolog universal quantifier would be applicable to reasoning about Cyc frames. Does your comment imply it's not?

Re: Ask HN: What's Prolog like in 2024?

#183
post #93

Girard has some commentary scattered about his writing. The search algorithms for logic programming are simply slow, it's a very interesting idea in programming languages, but there's a reason it's not widely used. > PROLOG, its misery. Logic programming was bound to failure, not be- cause of a want of quality, but because of its exaggerations. Indeed, the slogan was something like « pose the question, PROLOG will do…

This is a great quote and sadly true. What text is this from?

For me this kind of criticism is very familiar. It comes from theoretical computer scientists who have these purist ideological convictions about how a declarative language should look and behave, that are as unrealistic, because impossible to implement on a real-world computer, as they are uninteresting for practicing programmers because strictly a matter of aesthetics. Such critics have never made anything useable themselves and are simply angry that someone else made something that works in the real world while they were busy intellectually masturbating over their pure and untouchable vision.

Although I concede that my comment might be a bit unfair to Girard who did, after all, invent the mustard watch.

Re: Ask HN: What's Prolog like in 2024?

#184

Earlier quoted context omitted.

Who still has nightmares of infinitely nested parenthesis?

The more nightmarish thing about Clojure is realizing that, in truth, you have no idea what all these dicts you are passing around the terse, nil-punning functions of your codebase hold at any given time.

That was the case for me. I went all in drinking the Clojure koolaid and wrote some small internal CLI tools with it. If I came back to that code a month or two later I could only properly understand it if I opened up a REPL to debug it. I ported those tools to Java and they were dead simple to comprehend.

Re: Ask HN: What's Prolog like in 2024?

#185

Earlier quoted context omitted.

Who still has nightmares of infinitely nested parenthesis?

The more nightmarish thing about Clojure is realizing that, in truth, you have no idea what all these dicts you are passing around the terse, nil-punning functions of your codebase hold at any given time.

Yup. I learned Clojure just so I can use a Lisp and get paid for it, but there is some weird cult against all forms of typing. Even coming from a Common Lisp background, this was strange to me. In Common Lisp, there are implementations (like SBCL and ECL) that can make use of type declarations to produce efficient machine code and allow the compiler to catch errors that would otherwise be run-time errors. There's also other benefits like contextual autocomplete. The autocomplete in Clojure tooling is very basic, and many Clojure libraries try to make up for this by using qualified keywords everywhere. That way, rather than seeing all keywords ever interned, you can type ":some.namespace/" and your editor shows a dozen keys instead of hundreds of unrelated keys.

Many in the Clojure community believe that occasionally validating maps against a schema "at the boundaries" is good enough. In practice, I have found this to be insufficient. Nearly every Clojure programmer I know has had to "chase nils" as a result of a map no longer including a key and several functions passing down a nil value until some function throws an exception. (Note: I don't specify which exception, because it depends on how that nil value gets used!)

Refactoring Clojure code in general is a nightmare, and I suspect it is why many in the community are reluctant to change code in existing libraries and build entirely new things in parallel instead. Backwards compatibility is one often-cited reason, but I do think another reason is that refactoring Clojure code creates an endless game of bug fixing unless you have full test coverage of your codebase and use generative testing everywhere. (I've never seen a Clojure codebase with both of these things. I can count on one hand the number of Clojure codebases where generative testing is used at all).

Function spec instrumentation provides something that feels like runtime type checks in Common Lisp, but now you have to manually run certain functions at the REPL just to ensure some change in your codebase did not introduce a type error.

On the flip side, Java has things like DTOs which always felt too boilerplate-ish for me (though at least it provides useful names for endpoint data when generating Swagger/OpenAPI documentation). Even then, records in Java provide what are essentially maps with type safety and similar characteristics as DTOs.

I think the structural typing offered by languages like OCaml and TypeScript provide exactly what I'd want in Clojure. But when faced with feature requests in Clojure, people will state something like "I have never had a use-case for X, therefore you don't need X". In the case of criticisms, the response is often "I may have ran into X before, but it's so rare that I don't consider it a problem".

Re: Ask HN: What's Prolog like in 2024?

#186

Prolog, and Constraint Programming especially are great to have in your toolbox. I’ve done research in the field for years, and my job in the industry today is writing Prolog. There are real issues with Prolog: - no proper module nor package system in the modern sense. - in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided un…

Maybe it's just me but I see a lack of a package manager as a massive, massive pro. I can't stand how seemingly every language has a package manager which requires it's own installation and you have to learn how to use THAT thing and then you need some library off github that does some minor task really well but you can't just download the fucking code, you have to import it via, idk, the Fork-Lyft manager which requ…

Me too! I absolutely see a lack of package manager as a pro. I also hate to saddle anything with 600MB I don't need. 100% agree.

I would go as far as to say that Prolog is more a problem solving language rather than a system building language. Package managers and module systems are for modularization of big systems. You don't need that when solving small recurrent problems. Furthermore, lack of them forces you to avoid dependencies, that most of the time would end as technical debt. IMHO.

Re: Ask HN: What's Prolog like in 2024?

#187

Earlier quoted context omitted.

what does that mean?

It's an except from the article. Getting an explanation out of context is worthless.

Excerpt from what article? (edit: i see you're referring to the indented quote from the article, but i was asking what the "fuckin a." thing meant.)

Re: Ask HN: What's Prolog like in 2024?

#188
post #23

Shameless plug: you should check out my podcast The Search Space for a view of the broader landscape of Prolog and logic programming: https://thesearch.space/ I don't publish episodes often but I have a lot of good interviewees lined up :) In general, I would advice you to look beyond Prolog and explore Answer Set Programming, the Picat language, and the connections between logic programming and databases (SQL, RDF o…

I love your podcast! I wish you published episodes more often!

I particularly enjoyed the first episode, the conversation with Robert Kowalski.

Re: Ask HN: What's Prolog like in 2024?

#189

Earlier quoted context omitted.

The more nightmarish thing about Clojure is realizing that, in truth, you have no idea what all these dicts you are passing around the terse, nil-punning functions of your codebase hold at any given time.

Yup. I learned Clojure just so I can use a Lisp and get paid for it, but there is some weird cult against all forms of typing. Even coming from a Common Lisp background, this was strange to me. In Common Lisp, there are implementations (like SBCL and ECL) that can make use of type declarations to produce efficient machine code and allow the compiler to catch errors that would otherwise be run-time errors. There's als…

I still don't get how Java records can be used for anything like a DTO. Since you're a Clojure dev you may remember the pattern Rich Hickey described as "place oriented programming" :) Nearly every endpoint will have more than 2-3 fields and you really don't want a Java record with more than that many fields for the same reason you don't want a Java method with that many fields e.g. doIt(Long, String,String,Long,String,int,int,String) And the problem I always see is something may start off as a Java record and then need to be refactored into a class as soon as 1-2 more fields are added.

Re: Ask HN: What's Prolog like in 2024?

#190

The problem with Prolog is that it's based on unification, and small unification engines can be expressed in a few lines in any functional programming language. That narrows down the already small niche where one would choose Prolog by probably a few orders.

What makes Prolog, Prolog is not unification on its own but SLD-Resolution with unification, where "SLD" stands for [L]inear Resolution with a [S]election rule restricted to [D]efinite clauses. If you know your Resolution typology, that means soundness and refutation-completeness (or completeness with subsumption) [1].

I don't think I've ever seen a discussion of Resolution in functional programming textbook implementations of "Prolog". They typically just bodge some depth-first search with backtracking and unification in polish notation and call it "Prolog", or "logic programming". A bit like if I wrote a "lisp" with eval(X):- call(X), then completely ignored all that jazz about lambda calculus and concentrated on garbage collection and linked lists.

A good starting point instead, if one wishes to understand Prolog and not just dismiss it out of hand, is to try and understand Resolution, and what unification does for Resolution, and why it ended up in Prolog (and how) in the first place. I'd start, well, at the beginning:

A Machine-Oriented Logic Based on the Resolution Principle

https://www.semanticscholar.org/paper/A-Machine-Oriented-Log...

Where you can follow the progress from ground Resolution, to unification, the Resolution theorem, and all the way to the (pre-modern) Subsumption Theorem. It's a long way to Prolog from there, but that's where it all begins.

_______________

[1] Although Prolog implemented by DFS is not complete if Prolog implemented by DFS is not complete (etc).

Post reply on HN