> 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;
I wonder whether a way to get around this problem would be to show the student buggy Prolog programs, maybe even buggy solutions to textbook problems--whether the "solutions" are produced by AI or by humans might not matter.
The student's task is first to find out where the program produces the wrong results, and second to fix the code.
From what I've heard (I haven't used AI programs much myself), telling an AI chatbot to fix a program seldom results in the correct fix. So at least until the AIs are greatly improved, would this work?
I think the solution involves raising children to have integrity, and then not then discouraging that with tons of artificial gatekeeping theatre on the way to good jobs.
The first obvious thing I'd destroy is LeetCode interviews. Maybe the protagonist in the article would've thought differently about school and jobs and integrity, if he hadn't had to spend 600 hours on LeetCode rehearsals.
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.
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.
“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.
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.
True, I'm not sure you're going to get anything like cuts in a type system. I know with Haskell (GHC really, but that's kind of a given these days) and C++ you can make matching abort early, but only with an error.
Prolog and haskell communities are pushing in very different directions, and just because one piece in the haskell compiler happens to do one thing that prolog does, doesn’t mean haskell users get exposed to prolog ideas, or even that said piece of software offers a good way to express problems like prolog does.
Sure, you could use haskell to express your problem as a type, aphyr style. You could also try to teach haskell concepts by having students write a haskell compiler in python.
You could also write arbitrary prolog in brainfuck if you’re obstinate enough.
Repeating verbatim a post on a Haskell forum, someone talking about the Curry-Howard-Lambek correspondence and saying "you can write arbitrary Prolog in Haskell types". Seems most advanced type systems are already Turing-complete and based on unification matching, so I didn't see much reason to disbelieve it, though I realize that might be a little oversold.
Obviously it doesn't look like Prolog, and you don't necessarily even want the Turing-completeness in your type system -- or at least not to have to rely on it anyway. But I still think the parallels are clear enough that it'd make for a pretty relevant piece of a course in logic programming.
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.”
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.
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.
Community, I wasn't talking about the language itself.
It puts me off having a programming language that depends on the Java the Virtual Machine, Java the programming language, Java the ecosystem, so that their language could exist in first place, and then talk down on it.
Still waiting on Scala Native or Kotlin Native to take over JVM and the standard library.
Clojure community isn't like that, while they try to stay on Lisp like land, they embrace the ecosystem (JVM and JS), without putting it down at every opportunity.
How can Scala 'talk down' the platform it exists on? This doesn't even make sense. You know the creator of Scala made deep contributions (generics) to the JVM, right? Scala's sbt is used by many Java projects as a build system. Its Play Framework and Akka actor system are super popular in Java too because they provide idiomatic Java APIs. Projects like Spark keep JVM relevant for Big Data. SoftwareMill's Ox project builds directly on top of JVM virtual threads and structured concurrency. I haven't even heard of any equivalent Clojure project.
The community, do I have to letter spell you, why do you keep talking about Scala the language, Scala projects?
Why do I care what is written in Scala, how well it interoperates with the JVM, or whatever Scala projects are successful, when I am talking about how human beings talk down about another piece technology, its limitations and warts, how it prevents the language greatness, that by accident happens to be the underlying infrastructure of their beloved language?
Do you rather have links to discussions on Reddit, Twitter discussions and what not?
I never said anything about the creator specifically.
> Why do I care what is written in Scala, how well it interoperates with the JVM, or whatever Scala projects are successful, when I am talking about how human beings talk down about another piece technology
There are always a few loudmouths in every community, you are making the classic mistake of judging everyone by that same brush. Most people using Scala are using it exactly because of the JVM, otherwise what's the point? There are great languages on other platforms too.
A few people use it to push the boundaries of what's possible on the JVM, and it is thanks to these people and the Scala team themselves that the JVM continues its evolution and the Java language continues to acquire more Scala-like features. It's not a zero-sum game, everyone is benefitting here.
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.
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.
It's not the same flavor of logic language but I've been trying to find some interesting things to do in Curry. The functional dependency component it introduces makes some problems a lot easier to deal with in Curry than in Prolog (or at least that's what someone told me one day....)
The project as a whole exists and everything, but even things like just having an easy-to-install implementation on Homebrew hasn't happened yet, so if you're up for some sweat and tears and low hanging fruit, it feels right to me!
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.
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.
seems interesting, though i'm not sure I fully understand - its mainly a demo where LLMs generate prolog code for this specific port problem?
I was imagining my idea on a larger scale, 1. using prolog to improve general "reasoning" benchmarks (for ex. these kinds of problems https://www.llm-reasoning-benchmark.com/) and 2. using prolog in the context of an agent, as a way to model its environment and make better plans towards goals.
It's a guide for prompting LLMs to generate Prolog for any problem that can be solved by a STRIPS-like formulation with state and robotic actions like the container packing and container shipping problems (and a few artificial ones from AI competitions). A main predicate encoding a goal selection strategy is omitted in generation and a generic one is supplied instead. The point is using language models to translate text descriptions into Prolog knowledge and state change representations guided by in-context examples, which was found to work really well in practice, and is also quite natural given Prolog's NLP roots.
Very interesting, TIL about STRIPS - but if this works as well as claimed then without knowing more it seems too good to be true, and further surprising that it isn't more widely adopted. I'm curious if you have plans for this site and code, or was it your own PoC? Like I mentioned I'm curious how it would hold up to more standard benchmarks. When I finally start my own prolog journey I'll remember to revisit your site so I can fully appreciate it, nonetheless thanks for sharing and explaining.
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.
Eh I don't think I would commit to vibe coding something I don't understand. I don't know enough about prolog to know if the idea is truly plausible - or as another commenter suggested, less than ideal compared to other solvers. And I don't know enough to steer it in the right direction either. I'd rather sit down and learn it the right way first.
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?
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.
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.
> 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.
It sounds like the writer has a good idea on how to extract a lot more value from the subject for students, but I think we might be missing the value of tools like prolog in the LLM era. It seems to me that tool use of prolog for logic and python or R for math would be extremely helpful for LLMs (especially smaller local ones) to solve problems.
"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.)
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.
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.
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.
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.
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.
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.
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.
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.
The idea of a kind of higher-order Eternal September, where the flood of newbies and low-value content is from educators, instead of students/"true newbies", is interesting. I wonder what causes it? Maybe some vague desire by educators to "teach something old for the sake of seeing alternate technologies" or something.
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.
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!
Enjoy. I could see not liking programming videos, but they are very informative and sometimes veer into the philosophical or even political, but always in a level-headed way. Markus semi-regularly posts on HN about Scryer and I always enjoy reading what he comments.
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?
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.
While I was never taught Prolog, I did did have programming teacher that was really bad at explaining
And yet, I fell in love with code and the language I was taught and everything else
The secret? GOOD and LARGE set of exercises
Having teacher diligent enough to ask correct tasks in correct order to be done in-class (and check them being done) is a lot more valuable than you think it is
"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.
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.
I'm a fairly competent programmer and problem solver and I'm curious about a wide variety of programming paradigms (Haskell, Lisp, etc.), esoteric programming languages, and even abstract concepts such as Turing machines and lambdas calculus. Despite, I have not benefited from being shown Prolog in classes. I did not understand it (nor did the teacher) and I never became curious about it again.
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.
Well, there are many ways to learn about things, there's no "have to" about it.
Learning principles in the context of a language is learning in the context of application rather than pure theory. For some, this helps ground ideas by connecting them to others they already understand. Of course, no advice is universal, and each person needs to decide if it applies to them.
This advice most applicable in the context of deciding what language to learn next. Assuming you want to improve your ability to tackle more kinds of problems, rather than fulfill a particular checkbox. Like learning Java when you already know C# is going to contribute to personal growth less than a LISP or prolog or Rust.
Because learning a new language with a different world model gets you to think about problems on a different way. A library for a language you already know will not do that to anything like the same degree.
I suggest you actually try the exercise before making assertions like that. Mind you, there's the old saying, "Real programmers can write FORTRAN in any language"...
IMO it is important to learn that the world of programming languages is bigger than bcpl descendents where they statement correspondence to a few assembly instructions.
> 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.
I wonder whether a way to get around this problem would be to show the student buggy Prolog programs, maybe even buggy solutions to textbook problems--whether the "solutions" are produced by AI or by humans might not matter.
The student's task is first to find out where the program produces the wrong results, and second to fix the code.
From what I've heard (I haven't used AI programs much myself), telling an AI chatbot to fix a program seldom results in the correct fix. So at least until the AIs are greatly improved, would this work?
I think the solution involves raising children to have integrity, and then not then discouraging that with tons of artificial gatekeeping theatre on the way to good jobs.
The first obvious thing I'd destroy is LeetCode interviews. Maybe the protagonist in the article would've thought differently about school and jobs and integrity, if he hadn't had to spend 600 hours on LeetCode rehearsals.
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.
Many of these course websites are still around and/or recycled to later courses.
Sounds very interesting, which text book did you use for your course?
I don't remember sorry :(
would you accept telling us which university you went to ? unless you want to keep that private
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.
“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.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.
Exactly—Haskell’s type checker can be made Turing-complete, but that won’t make it much like Prolog.
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
True, I'm not sure you're going to get anything like cuts in a type system. I know with Haskell (GHC really, but that's kind of a given these days) and C++ you can make matching abort early, but only with an error.
Prolog and haskell communities are pushing in very different directions, and just because one piece in the haskell compiler happens to do one thing that prolog does, doesn’t mean haskell users get exposed to prolog ideas, or even that said piece of software offers a good way to express problems like prolog does.
Sure, you could use haskell to express your problem as a type, aphyr style. You could also try to teach haskell concepts by having students write a haskell compiler in python.
You could also write arbitrary prolog in brainfuck if you’re obstinate enough.
> 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.
Where did you get that idea? (I’m not seeing how that would work.)
Repeating verbatim a post on a Haskell forum, someone talking about the Curry-Howard-Lambek correspondence and saying "you can write arbitrary Prolog in Haskell types". Seems most advanced type systems are already Turing-complete and based on unification matching, so I didn't see much reason to disbelieve it, though I realize that might be a little oversold.
Obviously it doesn't look like Prolog, and you don't necessarily even want the Turing-completeness in your type system -- or at least not to have to rely on it anyway. But I still think the parallels are clear enough that it'd make for a pretty relevant piece of a course in logic programming.
There is a blog post by Aphyr doing just that (typing the technical interview), which is well worth a read.
That being said, it is a very small subset of what prolog does, and it has little practical use beyond writing a blog post.
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.
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.”
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.
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.
Oh boy are they so true, one of the reasons I don't care about the Kotlin Virtual Machine any longer.
So full of themselves on how much better they are than Java.
Imho, Scala is the coolest of the JVM guest languages :-)
The language yes, the way the community embraces the platform and ecosystem that makes their existence possible in first place, not as much.
What do you consider as 'embracing the platform and the ecosystem'? As far as I'm aware Scala is fully interoperable with anything on the JVM.
Community, I wasn't talking about the language itself.
It puts me off having a programming language that depends on the Java the Virtual Machine, Java the programming language, Java the ecosystem, so that their language could exist in first place, and then talk down on it.
Still waiting on Scala Native or Kotlin Native to take over JVM and the standard library.
Clojure community isn't like that, while they try to stay on Lisp like land, they embrace the ecosystem (JVM and JS), without putting it down at every opportunity.
How can Scala 'talk down' the platform it exists on? This doesn't even make sense. You know the creator of Scala made deep contributions (generics) to the JVM, right? Scala's sbt is used by many Java projects as a build system. Its Play Framework and Akka actor system are super popular in Java too because they provide idiomatic Java APIs. Projects like Spark keep JVM relevant for Big Data. SoftwareMill's Ox project builds directly on top of JVM virtual threads and structured concurrency. I haven't even heard of any equivalent Clojure project.
You have it exactly backwards, I'm afraid.
The community, do I have to letter spell you, why do you keep talking about Scala the language, Scala projects?
Why do I care what is written in Scala, how well it interoperates with the JVM, or whatever Scala projects are successful, when I am talking about how human beings talk down about another piece technology, its limitations and warts, how it prevents the language greatness, that by accident happens to be the underlying infrastructure of their beloved language?
Do you rather have links to discussions on Reddit, Twitter discussions and what not?
I never said anything about the creator specifically.
> Why do I care what is written in Scala, how well it interoperates with the JVM, or whatever Scala projects are successful, when I am talking about how human beings talk down about another piece technology
There are always a few loudmouths in every community, you are making the classic mistake of judging everyone by that same brush. Most people using Scala are using it exactly because of the JVM, otherwise what's the point? There are great languages on other platforms too.
A few people use it to push the boundaries of what's possible on the JVM, and it is thanks to these people and the Scala team themselves that the JVM continues its evolution and the Java language continues to acquire more Scala-like features. It's not a zero-sum game, everyone is benefitting here.
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.
Do look up annotated logic: https://www.sciencedirect.com/science/article/pii/0743106692... as e.g. utilized by https://github.com/lab-v2/pyreason which is the best summation of the various fuzzy logics more modern prologs experimented with
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.
I still have a fanfold printout somewhere of the OPS5 implementation I wrote in C, back in the 80s :-)
Same here. Remember when we called our AI "Expert Systems"?
That's amazing.
It's not the same flavor of logic language but I've been trying to find some interesting things to do in Curry. The functional dependency component it introduces makes some problems a lot easier to deal with in Curry than in Prolog (or at least that's what someone told me one day....)
The project as a whole exists and everything, but even things like just having an easy-to-install implementation on Homebrew hasn't happened yet, so if you're up for some sweat and tears and low hanging fruit, it feels right to me!
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.
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
seems interesting, though i'm not sure I fully understand - its mainly a demo where LLMs generate prolog code for this specific port problem?
I was imagining my idea on a larger scale, 1. using prolog to improve general "reasoning" benchmarks (for ex. these kinds of problems https://www.llm-reasoning-benchmark.com/) and 2. using prolog in the context of an agent, as a way to model its environment and make better plans towards goals.
It's a guide for prompting LLMs to generate Prolog for any problem that can be solved by a STRIPS-like formulation with state and robotic actions like the container packing and container shipping problems (and a few artificial ones from AI competitions). A main predicate encoding a goal selection strategy is omitted in generation and a generic one is supplied instead. The point is using language models to translate text descriptions into Prolog knowledge and state change representations guided by in-context examples, which was found to work really well in practice, and is also quite natural given Prolog's NLP roots.
Very interesting, TIL about STRIPS - but if this works as well as claimed then without knowing more it seems too good to be true, and further surprising that it isn't more widely adopted. I'm curious if you have plans for this site and code, or was it your own PoC? Like I mentioned I'm curious how it would hold up to more standard benchmarks. When I finally start my own prolog journey I'll remember to revisit your site so I can fully appreciate it, nonetheless thanks for sharing and explaining.
http://www.incompleteideas.net/IncIdeas/BitterLesson.html
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.
Good take, yeah my naive idea of prolog is as a kind of "solver", so I suppose the better the solver the better implementation.
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.
Would be pretty easy to write an mcp that interfaces with prolog apps. Probably an hour or two of vibe coding. ;)
Eh I don't think I would commit to vibe coding something I don't understand. I don't know enough about prolog to know if the idea is truly plausible - or as another commenter suggested, less than ideal compared to other solvers. And I don't know enough to steer it in the right direction either. I'd rather sit down and learn it the right way first.
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?
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.
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.
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.
> 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.
Thanks for the recommendation :-)
It sounds like the writer has a good idea on how to extract a lot more value from the subject for students, but I think we might be missing the value of tools like prolog in the LLM era. It seems to me that tool use of prolog for logic and python or R for math would be extremely helpful for LLMs (especially smaller local ones) to solve problems.
"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.)
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.
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: <https://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:
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.
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.
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
They should know what the C abstract machine does and doesn’t guarantee, for one.
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.
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.
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:
and that was it. It ran on both PForth and EForth. Eforth on a subleq (muxleq for performance) under an n270 Atom netbook.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.
you mean "C with new"?
the one that's even worse than C-with-classes...
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.
Theres actively hostile and then there's indifference to a certain class of questions. Anyway AI models don't suffer from this nowdays
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!
The idea of a kind of higher-order Eternal September, where the flood of newbies and low-value content is from educators, instead of students/"true newbies", is interesting. I wonder what causes it? Maybe some vague desire by educators to "teach something old for the sake of seeing alternate technologies" or something.
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
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!
Enjoy. I could see not liking programming videos, but they are very informative and sometimes veer into the philosophical or even political, but always in a level-headed way. Markus semi-regularly posts on HN about Scryer and I always enjoy reading what he comments.
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?
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.
Right, but thinking you can change how people teach a subject without their believing it's worth knowing seems unrealistic, too!
While I was never taught Prolog, I did did have programming teacher that was really bad at explaining
And yet, I fell in love with code and the language I was taught and everything else
The secret? GOOD and LARGE set of exercises
Having teacher diligent enough to ask correct tasks in correct order to be done in-class (and check them being done) is a lot more valuable than you think it is
"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.
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.
I'm a fairly competent programmer and problem solver and I'm curious about a wide variety of programming paradigms (Haskell, Lisp, etc.), esoteric programming languages, and even abstract concepts such as Turing machines and lambdas calculus. Despite, I have not benefited from being shown Prolog in classes. I did not understand it (nor did the teacher) and I never became curious about it again.
Why does it have to be via a new language? Why not instead do it via teaching about constraints solvers?
> 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.
I meant new to the person learning about it.
I have no interest in studying prolog to extract what knowledge from it would be practical.
Well, there are many ways to learn about things, there's no "have to" about it.
Learning principles in the context of a language is learning in the context of application rather than pure theory. For some, this helps ground ideas by connecting them to others they already understand. Of course, no advice is universal, and each person needs to decide if it applies to them.
This advice most applicable in the context of deciding what language to learn next. Assuming you want to improve your ability to tackle more kinds of problems, rather than fulfill a particular checkbox. Like learning Java when you already know C# is going to contribute to personal growth less than a LISP or prolog or Rust.
Mandatory means "have to."
My comment was that there are more practical alternatives than just programming languages.
Ah, I see, I thought the last sentence in your original post was making a comment more generally, not still tied to the classroom setting. Sorry.
Because learning a new language with a different world model gets you to think about problems on a different way. A library for a language you already know will not do that to anything like the same degree.
Why? Libraries and grammar are both abstractions. The important part is how one can reframe problems and not how exactly it is written.
I suggest you actually try the exercise before making assertions like that. Mind you, there's the old saying, "Real programmers can write FORTRAN in any language"...
IMO it is important to learn that the world of programming languages is bigger than bcpl descendents where they statement correspondence to a few assembly instructions.