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.)
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.
At least with some bare metal Forth you can inspect the machine from high level to ASM levels.
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.
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.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:
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:
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.
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.
the one that's even worse than C-with-classes...
I'd like to see someone do for Prolog 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.”
So full of themselves on how much better they are than Java.
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.
You have it exactly backwards, I'm afraid.
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.
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.
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!
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.
:) Agreed, the AI models have great "people skills." Every user is a genius!
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.
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.
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?
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 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.
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?
If you care for recommendations to complement those two, O'Keefe's The craft of Prolog is my favorite Prolog book.
"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.
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.
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.> 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
Where did you get that idea? (I’m not seeing how that would work.)
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.
That being said, it is a very small subset of what prolog does, and it has little practical use beyond writing a blog post.
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.
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.
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 have no interest in studying prolog to extract what knowledge from it would be practical.
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.
My comment was that there are more practical alternatives than just programming languages.
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.
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.
> 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.
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.
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
JadeNB•2mo ago
passivegains•2mo ago
JadeNB•2mo ago