Ask HN: What's Prolog like in 2024? • Hacker News Board

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

#261

Post by rramadass » Sat, Jul 20, 2024, 3:28 AM UTC

derdi wrote: post #245

rramadass wrote: post #154

Earlier quoted context omitted.

In The Development of Erlang Joe Armstrong says "We concluded that we would like something like Prolog with added facilities for concurrency and improved error handling". See pdf linked here - https://news.ycombinator.com/item?id=40998632

You're reading too much into that quote. This is in a section titled "early experiments". It was an initial goal. There is a lot of historical connection to Prolog, due to the original implementation, and there are syntactic similarities and non-linear pattern matching and dynamic types and a general declarative vibe, but the actual end result of Erlang's evolution, despite the goal of "something like Prolog", is not…

You are stating some obvious things which are not what is being argued here. I only gave the above quote because it is the conclusion that the Erlang designers came to after a lot of research/playing/implementing with other languages (read the full paper and others listed below). I had also stated above that "he conceived Erlang as Prolog-Ideas+Functional/Procedural+Concurrency+Fault-Tolerance." So we already know Erlang is a different language. Note that Robert Virding also states in the Erlog page "due to the fact that Erlang evolved from Prolog". So obviously Prolog was a huge influence on Erlang design (not to be confused with the fact that the first experimentation was done in Prolog) in addition to other systems/languages. The above paper also states "It was a strange mixture, with declarative features (inherited from Prolog), multi-tasking and concurrency (inherited from EriPascal and Ada) and an original combination of error handling mechanisms". The last came from AXE/PLEX and others.

Joe Armstrong wrote two papers The Development of Erlang (linked here https://news.ycombinator.com/item?id=40998632) and a longer A History of Erlang (pdf at https://www.labouseur.com/courses/erlang/history-of-erlang-a...). In addition to his thesis (pdf at https://erlang.org/download/armstrong_thesis_2003.pdf) they provide a fascinating study into what goes into the design of a language i.e. lots of messy experiments, shifting goals, inspiration/features from many different languages etc. until everything coalesces into a organic whole which is then validated by users. Reading the above two papers will give you a more complete picture of Prolog's influence on Erlang (in addition to others).

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

#262

Post by rramadass » Sat, Jul 20, 2024, 3:36 AM UTC

YeGoblynQueenne wrote: post #253

rramadass wrote: post #154

Earlier quoted context omitted.

In The Development of Erlang Joe Armstrong says "We concluded that we would like something like Prolog with added facilities for concurrency and improved error handling". See pdf linked here - https://news.ycombinator.com/item?id=40998632

Yeah but to be honest, Erlang ended up being not something like Prolog at all. I think Joe Armstrong was a user here and I interacted with him waaaay way back when I first joined. He's dead now :(

See https://news.ycombinator.com/item?id=41013798

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

#263

Post by tannhaeuser » Sat, Jul 20, 2024, 7:51 AM UTC

Karrot_Kream wrote: post #248

tannhaeuser wrote: post #218

Earlier quoted context omitted.

The domain-specific Prolog code bases you're going to create still can become large and represent a significant development effort. Prolog being an ISO standard with many conformant (or at least mostly conformant) implementations available and relatively strong mindshare and ecosystem compared to extremely niche "CP solver packages and OR-tools" (which one exactly?) significantly reduces project risks such as not bei…

> extremely niche "CP solver packages and OR-tools" (which one exactly?) significantly reduces project risks such as not being able to find experts, the system not meeting functional or performance requirements, or becoming obsolete down the road. The same cannot be said for some mythical "CP solver packages and OR-tools" "Mythical CP solver packages and OR-tools"? Lol! Google's OR-Tools [1] has been winning golds in…

Ok but is the argument now just because it's by Google with its media presence it's not niche? "Constraint solving" is an overly broad term that can encompass most of computer science but at least finite domain solving, interval propagation, and SAT solving as specific algorithmic approaches with very different applications. Going by your post, potential users looking for planning, scheduling, or optimization problems to solve will jump to very specific implementation techniques having won synthetic benchmarks in basically unrelated domains for showcasing "something with constraints". Classic OR is about optimizing systems of linear (in-)equations, but discrete optimization problems and most financial investment planning problems don't come in this flavor and really need very laborious encodings (like into equational systems with 1000s of artificial variables) to fit OR model formulation requirements or SAT checkers. Great, now you're prematurely solving idiosyncratic representation problems; your consultants surely will rub their hands. But I stand by my opinion that Prolog is, by far, a much better starting point for the kind of explorative programming required in this domain. Making Prolog fast/scaling on mainstream cloud hardware (like Quantum Prolog and SICStus are doing) has very much to offer to users, and is behind many or even most real-world scheduling and optimization applications.

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

#264

Post by derdi » Sat, Jul 20, 2024, 8:49 AM UTC

rramadass wrote: post #261

derdi wrote: post #245

Earlier quoted context omitted.

You're reading too much into that quote. This is in a section titled "early experiments". It was an initial goal. There is a lot of historical connection to Prolog, due to the original implementation, and there are syntactic similarities and non-linear pattern matching and dynamic types and a general declarative vibe, but the actual end result of Erlang's evolution, despite the goal of "something like Prolog", is not…

You are stating some obvious things which are not what is being argued here. I only gave the above quote because it is the conclusion that the Erlang designers came to after a lot of research/playing/implementing with other languages (read the full paper and others listed below). I had also stated above that "he conceived Erlang as Prolog-Ideas+Functional/Procedural+Concurrency+Fault-Tolerance." So we already know Er…

Thanks, I know that history, and nobody is denying the influence. The broader context are your claims about "a lot of commonalities here". There are commonalities, but they are shallow.

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

#265

Post by rramadass » Sat, Jul 20, 2024, 10:17 AM UTC

derdi wrote: post #264

rramadass wrote: post #261

Earlier quoted context omitted.

You are stating some obvious things which are not what is being argued here. I only gave the above quote because it is the conclusion that the Erlang designers came to after a lot of research/playing/implementing with other languages (read the full paper and others listed below). I had also stated above that "he conceived Erlang as Prolog-Ideas+Functional/Procedural+Concurrency+Fault-Tolerance." So we already know Er…

Thanks, I know that history, and nobody is denying the influence. The broader context are your claims about "a lot of commonalities here". There are commonalities, but they are shallow.

That we have to disagree. Leaving aside the non-Prolog features, much of the Erlang syntax is definitely inspired by Prolog (mentioned in many papers including https://www.erlang.org/faq/academic). That was the reason the HN submission i had referenced which linked to a reference sheet comparing Prolog/Erlang/Elixir was so interesting (direct link https://hyperpolyglot.org/logic). In most cases the Erlang syntax is just a simplified version.

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

#266

Post by [deleted] » Sat, Jul 20, 2024, 10:59 AM UTC

rramadass wrote: post #262

YeGoblynQueenne wrote: post #253

Earlier quoted context omitted.

Yeah but to be honest, Erlang ended up being not something like Prolog at all. I think Joe Armstrong was a user here and I interacted with him waaaay way back when I first joined. He's dead now :(

See https://news.ycombinator.com/item?id=41013798

[deleted]

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

#267

Post by YeGoblynQueenne » Sat, Jul 20, 2024, 11:14 AM UTC

rramadass wrote: post #262

YeGoblynQueenne wrote: post #253

Earlier quoted context omitted.

Yeah but to be honest, Erlang ended up being not something like Prolog at all. I think Joe Armstrong was a user here and I interacted with him waaaay way back when I first joined. He's dead now :(

See https://news.ycombinator.com/item?id=41013798

I saw, as I saw your upthread quote from the paper above but I think you misunderstand it. The previous paragraph gives context to your quote:

  The main conclusion [5] was that declarative language
  programs for POTS were a lot shorter and easier to
  understand than imperative language programs. Un-
  fortunately the declarative languages lacked features
  for concurrency control and had poor error handling
  facilities.

  We concluded that we would like something like Pro-
  log with added facilities for concurrency and improved
  error handling. No such language existed at the time.

"Something like Prolog" here reefers to the declarative features found in Prolog as well as other declarative languages, left unnamed in the quote, which make programs "a lot shorter and easier to understand thatn imperative language programs".

But that's where the "commonalities" you mention in your OP, between Prolog and Erlang, end. Similarly, CSS and XML are declarative but that's where their "commonalities" with Prolog (and Erlang) end.

I'm insisting with this because I'm concerned that your comment promulgates a common misconception about the, like you say, "commonalities" between Prolog and Erlang. These end with syntactic similarities and misunderstanding this can cause some disappointment to people trying to go from one to the other. I've seen a similar misunderstanding arise about "commonalities" between Prolog and, e.g. Haskell - they both have weird, arcane syntax and immutable data structures, but that's all. Or, think of C and javascript: both Algol like syntax and in fact the first js compilres must have been written in C, but that's all. etc.

There is much, much more to Prolog than the declarative syntax.

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

#268

Post by YeGoblynQueenne » Sat, Jul 20, 2024, 11:27 AM UTC

jodrellblank wrote: post #112

dkarl wrote: post #69

Earlier quoted context omitted.

> Prolog uses depth-first search and backtracking, which can lead to infinite loops if the rules are not carefully ordered Is this an issue in practice? Most languages can create programs with infinite loops, but it's easy to spot in code reviews. It's been over a decade since I encountered an infinite loop in production in the backend. Just wondering if the same is true for Prolog.

Here's an infinite loop in Prolog, getting the length of a list: length(List_of_animals, Len) Oops, List_of_animals hasn't been bound to any value, so length/2 will backtrack forever making it a longer and longer list of empty placeholders. Nothing will warn you that the variable wasn't declared because that's also a normal thing to do. Here's another, checking if something is in a list: member(cat, List_of_animals)…

The OP is asking whether that is an issue "in practice" and then points out the rarity of infinite loops "in production in the backend" [1].

For me, while that kind of thing gets me once in a while it never makes it to my final commits. That's because I always test every predicate I add to a program in isolation. Hey, sometimes I even write unit tests! So my experience is that the ability to write and test your program in sizeable chunks makes up for the danger of unbound variables causing infinite loops, in practice.

Also note that some Prologs have helpful error messages that direct the user to the problem. E.g. in SWI-Prolog (in "debug" mode):

  [debug]  ?- findall(cat,member(cat,List_of_animals),Cats).
  ERROR: Stack limit (1.0Gb) exceeded
  ERROR:   Stack sizes: local: 71Kb, global: 0.9Gb, trail: 3Kb
  ERROR:   Stack depth: 417, last-call: 0%, Choice points: 415
  ERROR:   Possible non-terminating recursion:
  ERROR:     [417] lists:member_(_230090210, cat, _230090214)
  ERROR:     [416] lists:member_([length:1|_230090242], cat, _230090236)
  ^  Exception: (4) setup_call_cleanup('$toplevel':notrace(call_repl_loop_hook(begin, 0)),   $toplevel':'$query_loop'(0), '$toplevel':notrace(call_repl_loop_hook(end, 0))) ? creep

Note:

  ERROR:   Possible non-terminating recursion:
  ERROR:     [417] lists:member_(_230090210, cat, _230090214)

_________________________

[1] I remember two infinite loops in production, one in the backend, one in the frontend. That was ca. 2013 so more than 10 years ago- good estimate!

The first loop was a missing terminating condition in a for-loop in C# that brought down the company's server along with every client's deployment (it was before everyone moved all their data to the cloud, you see). There was a meeting Upstairs™ and the programming team lead returned to tell us that he had explained what happened, explained that it was nobody's fault and that there's no way to prevent infinite loops like that happening again with perfect certainty, and that Upstairs had decided that, henceforth, iteration should no longer be used and when loops are required recursion should be used instead. Obviously that was completely ignored and everyone carried on as before.

The second loop was a bona-fide recursion without a terminating condition that happened in an in-house, Jango-like, templating language, called Mango. I don't remember the details but the folks who had coded the Mango interpreter evidently did a good job because it had no problem interpreting a recursive call in a template. The programming team lead from the previous story found it in a late-afternoon session where it was just me and him in the room. I felt a little deflated but I was just a junior starting out so I guess I was excused for missing it.

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

#269

Post by YeGoblynQueenne » Sat, Jul 20, 2024, 11:52 AM UTC

ted_dunning wrote: post #132

dkarl wrote: post #69

Earlier quoted context omitted.

> Prolog uses depth-first search and backtracking, which can lead to infinite loops if the rules are not carefully ordered Is this an issue in practice? Most languages can create programs with infinite loops, but it's easy to spot in code reviews. It's been over a decade since I encountered an infinite loop in production in the backend. Just wondering if the same is true for Prolog.

Infinite loops in Prolog can appear with very subtle changes in the use of code. One of the core problems is related to the reversible nature of Prolog. Not only are some programs reversible and some are, practically speaking, not, there are many gradations on this. The result is that programs that look equivalent and whose tests appear equivalent may exhibit non-termination in surprising ways. This is, in my experie…

Prolog provides predicates to throw and catch exceptions and it's simple to test that a predicate is called in the right "mode" (i.e. what variables are bound on entry and on exit).

That detracts from the declarative aesthetics of the program code so it upsets purists but it is very useful to those who want to actually use the language to actually write actual programs and so can avoid lots of wailing and gnashing of teeth.

In other words, Prolog is like any other programing language: if you're careful, you will not hurt yourself. Also applies to chainsaws, bathtubs, and banana peals.

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

#270

Post by YeGoblynQueenne » Sat, Jul 20, 2024, 11:59 AM UTC

fraber wrote: post #241

Prolog is very, very dead. I love Prolog with all my heart, but it excells at problems that are solved today much more efficiently using neuronal networks. So it's utterly obsolete. The issue of Prolog is that you need to code your rules manually. Doing ML with Prolog is possible, but very clumsy. Better stick to Python. Speed is irrelevant, because most problems suitable for Prolog are exponential. Implementation is…

Prolog was never designed for function approximation, like Neural Nets, so there is no comparison. Machine Learning with Prolog is perfectly possible and not at all clumsy. In fact these days we can even say it is done elegantly, by raising everything to the second order of logic where deduction and induction become one and the same.

Let me know if you need links and refs, but please try to keep your knowledge up-to-date before making big, splashy statements like "Prolog is very, very dead".