[HN Gopher] Prolog's Eternal September (2017)
       ___________________________________________________________________
        
       Prolog's Eternal September (2017)
        
       Author : Tomte
       Score  : 67 points
       Date   : 2025-05-08 11:32 UTC (2 days ago)
        
 (HTM) web link (storytotell.org)
 (TXT) w3m dump (storytotell.org)
        
       | JadeNB wrote:
       | It seems strange to make "let's make it easier for people to
       | teach Prolog who don't understand it." At very best, this'll lead
       | to students with a minimal factually correct knowledge of Prolog,
       | and no idea why it matters. If we're imagining changing teachers'
       | practice, why not aim a little higher and try to convince faculty
       | that Prolog is interesting, at which point anyone qualified to
       | teach computer science can learn about it themselves, and teach
       | it better than from material designed around their ignorance?
        
         | passivegains wrote:
         | the author is pretty up front about this: _I would like to live
         | in a world where professors consider Prolog worth knowing and
         | put in the effort. That probably isn't realistic._ He clearly
         | wishes he 's wrong, which makes three of us.
        
           | JadeNB wrote:
           | Right, but thinking you can change how people teach a subject
           | without their believing it's worth knowing seems unrealistic,
           | too!
        
       | Arch-TK wrote:
       | "I think the underlying problem is that Prolog is part of a
       | mandatory curriculum, but the professor doesn't understand it.
       | How do you teach something you don't understand?"
       | 
       | Same problem with C and probably other languages.
       | 
       | Although by far the most annoying is that lots of people who also
       | get paid to write C don't know it and have no interest in
       | actually learning it. (Worst of all, they don't realise how
       | little they know about C and think they know it very well.)
        
         | Bootvis wrote:
         | What is something such a person should know but doesn't? I
         | don't write C but the language is fairly small so I can imagine
         | a professional keeping 99% of it in their head at all time.
        
           | remexre wrote:
           | Idiomatic design would be a big one; there are a lot of ways
           | to design a program in a higher-level OO language that, if
           | followed in C, will lead to a program with lots of bugs
           | around error handling and resource cleanup.
           | 
           | This kind of ties into the argument made by some in the Rust
           | community that "the ownership was there the whole time" -- in
           | a language without automatic memory management, you really do
           | need to be aware of the life-cycle of an object in memory.
           | Rust's specific rules aren't fundamental, but "even when an
           | error occurs, I know what cleans up this object / this state"
           | is.
        
           | layer8 wrote:
           | They should know what the C abstract machine does and doesn't
           | guarantee, for one.
        
           | anthk wrote:
           | C it's highly machine dependant. Something like Scheme, CL or
           | even Forth would be preferable.
           | 
           | At least with some bare metal Forth you can inspect the
           | machine from high level to ASM levels.
        
             | codr7 wrote:
             | I agree Forth could make a more optimal first language to
             | learn.
             | 
             | I often recommend beginners to learn all of Forth, C, Lisp
             | & SmallTalk. Because they're all conceptually clean local
             | maximums in the language design space.
        
               | anthk wrote:
               | With Forth (Starting Forth and Thinking Forth) and Lisp
               | (especially CLOS or Scheme with SICP) you cover them all.
               | 
               | Even Subleq+Eforth it's fine, you'll learn EForth (it can
               | be set at muxleq.fth/subleq.ftj with some compatibility
               | with do...loop and floats) and Subleq as a VM. It's
               | highly documented and it even has a book to play with.
               | 
               | EDIT: as a nice example, I had some pas.f example with a
               | Pascal triangle. In order to get it working under eforth,
               | I just had to define .r as u.r on top like:
               | : .r u.r ;
               | 
               | and that was it. It ran on both PForth and EForth. Eforth
               | on a subleq (muxleq for performance) under an n270 Atom
               | netbook.
        
           | codr7 wrote:
           | As others said, just because you know the syntax that doesn't
           | mean you understand how to use it effectively.
           | 
           | C is very different from most other languages, I would say
           | the closest one is actually Assembly.
           | 
           | I've been working on a book for a while now to try and share
           | some of the ideas I've picked up over the years:
           | 
           | https://github.com/codr7/hacktical-c
        
           | bqmjjx0kac wrote:
           | C looks friendly enough, but it has many nooks and crannies
           | filled with undefined behavior (UB). If your program
           | accidentally does something like overflow a signed integer,
           | you're toast.
           | 
           | Raymond Chen has the best write up on UB that I've seen: <htt
           | ps://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...>
           | .
           | 
           | In addition to the "obvious" undefined behavior, strict
           | aliasing is subtle and poorly understood in my experience.
           | Consider the following:                   Foo
           | ReadFooFromBytes(const char* data, size_t len) {
           | Foo foo;             assert(len == sizeof(Foo));
           | foo = *(const Foo*)(data);             return foo;         }
           | Foo ConvertToFoo(Bar bar) {             return
           | ReadFromBytes((const char*)&bar, sizeof(bar));         }
           | 
           | The `ReadFooFromBytes()` function could exhibit undefined
           | behavior, depending on the _provenance_ of its pointer
           | parameter.
           | 
           | If you gave it a pointer to a true array of chars, it's fine.
           | If you use `ConvertToFoo()`, big bada boom. Truly baffling
           | stuff, the first time you encounter it.
        
         | ggerules wrote:
         | I agree with you!
         | 
         | Having spent decades writing C and sometimes teaching C at the
         | university level, to really understand the "why" of things in C
         | you have to spend some time,separately, writing / studying some
         | assembly language. In many universities teaching assembly
         | language has fallen out of favor.
        
       | cbarrick wrote:
       | One of my many probably-going-nowhere hobby projects is a modern
       | Prolog. I think the module system especially is a place where we
       | need innovation.
       | 
       | I'd like to see someone do for Prolog what Clojure did for Lisp.
        
         | brudgers wrote:
         | _what Clojure did for Lisp_
         | 
         | Hickey's goal was improving JVM programming ergonomics. It was
         | not changing Common Lisp (or Scheme).
         | 
         | Sure, Clojure exposed some programmers to lisp, but lisp shops
         | didn't convert to Clojure. JVM shops did adopt it in part
         | because Clojure "is just a Java library."
        
           | tyre wrote:
           | Yep. The parallel here would be taking logic programming and
           | opening it to new users. Prolog or systems like CLIPS are
           | super powerful and map to common problems better than other
           | tools, but are Scary and Niche and Unknown.
        
           | pjmlp wrote:
           | Which is why the Clojure community is the coolest from guest
           | languages on the JVM, as they embrace the platform, instead
           | of dissing the platform like the other one used to bootstrap
           | a mobile SDK ecosystem.
        
             | zbentley wrote:
             | Not entirely wrong, but ... only one of Clojure and Kotlin
             | is close enough to Java that it's inspiring meaningful
             | improvements in the upstream ecosystem. If the "dissing"
             | hypothesis were true I'd expect Clojure to be the one
             | influencing the most change, but it's not.
        
         | ww520 wrote:
         | 20 years ago I had the same thought. I actually started
         | implementing the Rete algorithm. Midway through I realized,
         | "hey, this is just relational algebra. May be I can integrate
         | it in a relational DB engine. Use rows in tables as facts and
         | materialized views as generated facts." It soon spin out of
         | scope and I lost interest. Later I did use what I learned to
         | build a rule based event processing engine.
        
           | crustycoder wrote:
           | I still have a fanfold printout somewhere of the OPS5
           | implementation I wrote in C, back in the 80s :-)
        
       | oh_my_goodness wrote:
       | I hear this and I agree. It's obviously a serious problem.
       | 
       | As a side issue. There's also a different, deeper problem. Any
       | Q&A site that's actively hostile to people who ask questions is
       | going to become toxic and intolerable within a few years. I'm
       | pretty sure that's true even if the hostility is reasonable and
       | justified.
       | 
       | As a newsgroup user since 1986: The problem with the original
       | Eternal September was not only a tidal wave of ignorant new
       | users. It was also that a large fraction of the experienced user
       | base were smug lunatics long before September finally arrived.
       | 
       | Sorry for the like "radical candor" here.
        
         | jamespo wrote:
         | Theres actively hostile and then there's indifference to a
         | certain class of questions. Anyway AI models don't suffer from
         | this nowdays
        
           | oh_my_goodness wrote:
           | Yes, that is a big difference. From what I've seen
           | indifference leads to much better outcomes.
           | 
           | :) Agreed, the AI models have great "people skills." Every
           | user is a genius!
        
       | melenaboija wrote:
       | I wish I still had the curriculum from my logic class in computer
       | science from 20 years ago. It was clearly structured to build a
       | deep understanding of how Prolog works, starting from the
       | fundamentals of tautology, then moving on to unification and
       | backtracking implementations in Prolog and so on. The practical
       | classes involved solving different problems ending with
       | simulating the Enigma encryption machine.
       | 
       | The approach really worked and I know it did because whenever I
       | revisit Prolog, it only takes me a few hours to get back up to
       | speed on the fundamentals. For something as abstract as logic and
       | Prolog I think it says a lot.
        
         | billfruit wrote:
         | Sounds very interesting, which text book did you use for your
         | course?
        
           | melenaboija wrote:
           | I don't remember sorry :(
        
             | agumonkey wrote:
             | would you accept telling us which university you went to ?
             | unless you want to keep that private
        
         | sitkack wrote:
         | Many of these course websites are still around and/or recycled
         | to later courses.
        
       | neilv wrote:
       | > _The pre-beginners are not at Stack Overflow to look at
       | existing solutions (which is what Stack Overflow wants you to
       | do). They just want someone to do their homework for them._
       | 
       | This is/was also a thing in the Scheme (and Racket) community,
       | where maybe half the users in the world, at any given time, just
       | want to pass the class and then never see it again.
       | 
       | The funny part was that it's a fairly small world, and the forums
       | the students were asking include the people who wrote the
       | textbooks and often the problem sets, as well as probably knew
       | the students' professors.
       | 
       | Fortunately, :) "AI" is now doing all the lazy students' homework
       | for them. So now:
       | 
       | 1. The AI plagiarizes from books, open source code, and forums;
       | 
       | 2. then the student plagiarizes from the AI;
       | 
       | 3. then the forums are left to people who are actually
       | interested;
       | 
       | 4. then the AI companies come and again steal whatever the
       | interested people do;
       | 
       | 5. and repeat.
        
       | subjectsigma wrote:
       | Someone, quick, perform the mtriska summoning ritual
       | 
       | I have no idea if he's read this post but his YouTube channel
       | provides, I feel, the missing link between a "day one" Prolog
       | tutorial and an expert-level Prolog guide. It's exactly what the
       | author is talking about.
       | 
       | http://metalevel.at
        
         | crustycoder wrote:
         | I hadn't come across that, In general I'm not a great fan of
         | programming videos (life is too short) but the website content
         | looks interesting - thanks!
        
       | crustycoder wrote:
       | Coincidentally, on Friday I pulled my dusty 1987 copies of
       | Sterling & Shapiro and Bratko off the bookshelf for the first
       | time in literally decades, and built myself a copy of SWI so that
       | I could have a tinker with it for something where I think it may
       | be a good fit.
       | 
       | Sure there are now some shinier toys in the Prolog box but the
       | problems with Prolog seem to be the same now as they were 35+
       | years ago - it's seen as a niche CS-only tool, where to get any
       | traction at all you have to absorb reams of terminology that's
       | mostly unknown outside of academia, or has been forgotten post-
       | graduation - Prolog really doesn't do itself any favours, and
       | never has.
       | 
       | I think expecting academia to ever "sell" Prolog is a bust - if
       | it hasn't happened by now, it never will. Better to directly
       | target people earning their crust writing code, and sell the
       | benefits to them, with real examples, not Towers of Hanoi and
       | N-Queens. And as far as practicable, try to relate them to things
       | that they are more likely to already know, such as SQL or
       | Functional programming?
        
         | JadeNB wrote:
         | > Coincidentally, on Friday I pulled my dusty 1987 copies of
         | Sterling & Shapiro and Bratko off the bookshelf for the first
         | time in literally decades, and built myself a copy of SWI so
         | that I could have a tinker with it for something where I think
         | it may be a good fit.
         | 
         | If you care for recommendations to complement those two,
         | O'Keefe's _The craft of Prolog_ is my favorite Prolog book.
        
           | crustycoder wrote:
           | Thanks for the recommendation :-)
        
         | thesz wrote:
         | https://github.com/stassa/louise
         | 
         | "Louise is a machine learning system that learns Prolog
         | programs."
         | 
         | For example, it can infer context-free grammar from half a
         | dozen examples, one positive and several negatives.
        
         | jrapdx3 wrote:
         | Back in the ancient 80s Prolog made a splash for a time. There
         | was Turbo Prolog (Borland) that I used for a couple of years,
         | wrote some useful programs with it. I also have "The Art of
         | Prolog" and pull it out once in a while. My Prolog skills seem
         | subject to rapid decay with disuse. While the appeal of
         | declarative programming is still there, the most that can be
         | said is Prolog's influence is evident in subsequent languages.
         | The incorporation of pattern matching is one example that comes
         | to mind.
        
         | superdisk wrote:
         | From experience I've found that Prolog excels at anything to do
         | with parsing. The one thing I miss in every other language is
         | DCGs especially, and any time I need to write a personal script
         | that reads and writes some file format, I always use Prolog
         | because then I can just write the code once and get both
         | modalities for free :)
         | 
         | When I finally get around to making my own perfect language
         | I'll have to figure out how to crowbar backtracking and DCGs in
         | somehow.
        
       | chuckadams wrote:
       | Teaching prolog in the context of modern type systems might be
       | more worthwhile, since to my understanding, there's quite a bit
       | of overlap, to where you can write arbitrary prolog in Haskell or
       | Scala's type systems. Probably even holds for C++ and TypeScript
       | too. But I don't think there's a technological solution for
       | teaching a subject for which the school cares so little that it
       | won't hire anyone who actually understands it.
        
         | klodolph wrote:
         | "Arbitrary prolog in Haskell's type system" is overselling it.
         | 
         | There are a lot of GHC extensions out there, so maybe some
         | combination of extensions can bring this statement closer to
         | reality. But, as stated, it's pretty far away. There's an
         | important common thread shared by Prolog and type certain
         | systems, which is unification, but Prolog gives you a lot of
         | tools to control what happens when you go forward and backward:
         | +---+       >---|   |--->           |   |       <---|   |---<
         | +---+
         | 
         | Prolog is, after all, Turing complete by design. I don't know
         | if Haskell's type system is Turing complete with enough GHC
         | extensions enabled, but if it is, then it's by accident.
        
           | syrak wrote:
           | You need very little to make a Prolog-like language Turing-
           | complete (lists and recursive predicates). And so Haskell's
           | type system only needs one (or two) extensions to be Turing-
           | complete, `UndecidableInstances` (and maybe
           | `FlexibleInstances` or `MultiParamTypeClasses`). It is no
           | accident. The name "undecidable" shows that the authors of
           | that extension were well aware that it enables Turing-
           | completeness.
        
           | fc417fc802 wrote:
           | I'm not sure how useful it is in practice but even C++
           | templates are turing complete. https://rtraba.com/wp-
           | content/uploads/2015/05/cppturing.pdf
           | 
           | > I don't know if Haskell's type system is Turing complete
           | with enough GHC extensions enabled, but if it is, then it's
           | by accident.
           | 
           | Undecidable instances? I don't think that's an accident.
           | https://stackoverflow.com/questions/42356242/how-can-
           | undecid...
           | 
           | Also see. https://github.com/seliopou/typo
        
       | CyberDildonics wrote:
       | _" I think the underlying problem is that Prolog is part of a
       | mandatory curriculum, but the professor doesn't understand it.
       | How do you teach something you don't understand?"_
       | 
       | Or the underlying problem is prolog itself. If students are
       | constantly learning it for a class and never wanting to touch it
       | again, maybe it's time to face facts. Some people get caught up
       | in the pageantry of programming and forget to spend their mental
       | energy building the software instead of doing clever stuff with a
       | programming language.
        
         | Bjartr wrote:
         | Of the things that can expand your problem solving skills as a
         | programmer, learning a language that's extremely unlike
         | languages you already know is extremely powerful. It gives you
         | new ways to think about problems, even if you never touch the
         | language again.
        
           | charcircuit wrote:
           | Why does it have to be via a new language? Why not instead do
           | it via teaching about constraints solvers?
        
             | Jtsummers wrote:
             | > Why does it have to be via a new language?
             | 
             | Prolog is not a new language, it's been around for 53
             | years.
             | 
             | > Why not instead do it via teaching about constraints
             | solvers?
             | 
             | Prolog is used for more than just constraint solving. If
             | that's all you think it does, perhaps you could consider
             | studying it and finding out what it can do.
        
       | disambiguation wrote:
       | I'll keep shilling the idea that someone should find a way to
       | glue LLMs and prolog together to create better reasoning agents.
       | I say this as someone who cant write a single prolog program, but
       | i get the gist of it and afaik it hasn't been done yet.
       | 
       | The idea is based on the following simple logic: LLMs are bad at
       | counting the number of "r's" in "strawberry" but good at writing
       | code that counts letters in a string. It follows that while LLMs
       | are also bad at solving reasoning problems, maybe they're good at
       | writing the prolog code (or driving a hypothetical prolog engine)
       | that solves those types of problems instead.
       | 
       | Maybe one day ill stop being lazy and do it myself, but until
       | then I'm putting the idea out there - to OP's request, that's one
       | reason to learn prolog.
        
         | dmd wrote:
         | http://www.incompleteideas.net/IncIdeas/BitterLesson.html
        
           | sirwhinesalot wrote:
           | This is a very important article but not one that applies to
           | what the person is saying. They're not suggesting hardcoding
           | knowledge into the system (i.e. through a predefined prolog
           | program) but by having the LLM learn to use it as a tool,
           | same as how an LLM will write and run Python instead of
           | guessing the output of a program.
           | 
           | I don't think Prolog is the right tool for this, actually for
           | the very reason stated in the Bitter Lesson (effective Prolog
           | use requires imperative constructs like cuts).
           | 
           | It makes much more sense to have the LLM learn how to use a
           | constraint solver or (automated) theorem prover which have
           | really powerful search algorithms (the search part of the
           | bitter lesson), same as how humans use them.
        
         | johnecheck wrote:
         | This idea feels obvious enough that people must be trying it.
         | It's probably just hard to train such a model that performs as
         | you'd want it to.
        
         | conception wrote:
         | Would be pretty easy to write an mcp that interfaces with
         | prolog apps. Probably an hour or two of vibe coding. ;)
        
         | tannhaeuser wrote:
         | Indeed, generating Prolog for robotic and other discrete
         | planning has been pursued. From [1]:
         | 
         | > _Rather than having LLMs perform planning itself, it 's thus
         | only natural to complement LLMs with the raw combinatorial
         | power of Prolog, much like a human would be reaching out to a
         | pocket calculator._
         | 
         | [1]: https://quantumprolog.sgml.net/llm-demo/part1.html
        
       ___________________________________________________________________
       (page generated 2025-05-10 23:00 UTC)