Paradigms of A.I. Programming: Case Studies in Common Lisp (1991)
norvig.github.io
norvig.github.io
Mark Watson on HN:
https://news.ycombinator.com/user?id=mark_l_watson
Edit: I should have said that you can also pay for his books:
“Good Old-Fashioned AI”
I had to look it up . . .
It's the book that got me hooked on Common Lisp (from Scheme) too. Focusing less on the elegance of the language definition and more on writing elegant programs.
(English isn't as elegantly defined as Lojban and but that didn't hold back Tolkien.)
What makes it my favorite is how clear Norvig's writing is. It's easy to follow (both when reading it in English, and when following its execution if you're a programmer), and it introduces important ideas so effortlessly that, years later, it will give you a chuckle.
Anyone interested in clearly communicating about technical topics, and with a knowledge of Lisp's nature and some idea of what programming in 1991 looked like, might be tickled to read Chapter 1; even its first few paragraphs are refreshing.
The advice to spend your limited time and attention on outdated approaches seems counterproductive. The things in this book aren't just old - they ended up being a dead end in research. So if it's 2023 and you have 20 hours to learn something new, you can do much better than this book.
I'm not an expert in either but am confident that progress is non linear. Are there any ideas that you think are definitely bad (or even possibly good) from the lisp days?
Besides, they're not the final solution to anything.
Learning your history is the only way to avoid repeating the same mistakes.
1. Machine learning.
2. Not neural networks.
3. Not in Norvig's book.
4. Still useful and relevant.
But it seems like we finally agree on something, simpler approaches to AI that predate neural networks are still potentially useful.
Because you're not going to claim that ML is the only useful kind of AI, are you?
Practically, which other book / ressource should someone with little time check out first ?
My version is from when I went to school 20 years ago. I assume it's been greatly updated over the past couple of decades. I wonder if it's worth taking a spin through the new edition.
http://aima.cs.berkeley.edu/contents.html
Chapters 19 on are going to be the biggest additions from the earlier editions.
(Interesting that AI is finally catching up with javascript frameworks.)
My personnal goal is to find some time to dig into https://course.fast.ai/ , assuming it's not terribly outdated, either.
The world isn't moving that fast. Transformers and LLMs are built on neural networks and lots of data and fast computers. You could jump straight to that point, but even the course you've pointed to starts off with more foundational ANN topics before getting to transformers. Much of which is at least in the TOC for the current edition of AIMA. Ought to be complementary texts.
Also, only fools ignore history, "classical" AI and topics also covered in the book are still applicable. ANNs aren't going to solve all the world's problems. Other techniques that fall under the category of "AI" are still applicable and very effective for a large number of real-world problems (and much more efficient than LLMs).
I'm seeing rampant use of ML now for problems we already know how to solve in much simpler ways: linear control theory, bayesian statistics, Kalman filters, etc. "Oh hey, no need to study those old, dry topics. Just throw a bunch of training data at this GPU-bound black box and it will probably work."
That's right, it will probably work. Until it doesn't. And then you won't be able to debug it. More important: You won't be able to predict when the system will fail, because it's a black box. And if it's controlling a high-consequence system, when it fails people could die.
The moral is that if your problem falls into one of the already known easy-to-solve domains, you should use the old techniques. It will probably need at least 1/10^6 the CPU resources as an ML approach and you'll be able to characterize its failure regimes in advance.
> I'm seeing rampant use of ML now for problems we already know how to solve in much simpler ways: linear control theory, bayesian statistics, Kalman filters, etc.
How many of these techniques are in the book in the original post?
I'm not saying the we should throw ML at everything, I'm saying the Norvig's book isn't useful in 2023.
Yes, he would. He's written as much in the past.
Its very possible (highly likely even) that elements of gofai end up being implemented into some of the upcoming RL/GNN combo based architectures. I highly doubt that the transformer will be the end-all-be-all for generating representations. At the very least, many of those 'in-the-know' around these GNNs realize that sheaf-NNs are much more expressive and can yield far better general results if improved properly for long range dependences - perhaps with a performer or longformer -like addition.
Ultimately, some of the best researchers in the field (Velockovic is one of the best, and heavily focused on dynamic programming for example) are not just focused on the transformer or any of the hype around it right now. In order to improve, you have to look elsewhere. Understanding old methods is typically a great resource to draw that inspiration / algorithm from.
While it would be great if everyone interested in the topic was well versed in the fundamentals, the truth is if you want to do anything from building something cool over the weekend to getting an actual job doing AI work, you're much better off starting not only with ML, but specifically with current SotA neural networks.
If you really want to get started in AI I highly recommend building even a trivial implementation of Stable Diffusion on your own. Not just because it's cool, but because at its heart it is an excellent demonstration of how current differentiable programming works. Diffusion models involve chaining together 3 separate models into an entire system that learns to solve a complex task. Once you understand this deeply, you can now solve a very broad range of tricky problems and are really approaching what we think of when we think of AI.
Differentiable programming is really the current pathway to any sort of AI solution to a problem.
I say this as the token "have you tried logistic regression?" guy in my org.
Massive Neural Nets do require a lot of data and are often not the best solution, but differentiable programming in general does not have higher data requirements than manually computing your derivatives or using OLS. You can still approach classical ML from the perspective of differentiable programming (and likely end up with a better sense of our how your models work in the end).
Currently, statistical/data-driven approaches work best, and that's what you will be expected to use whether you are building your own products, or working for an employer. Most people don't care about the GOFAI approaches anymore, seeing them as outmoded in all respects.
However, if you are curious and want to understand more of the history of approaches we have tried, and learn some really interesting algorithms along the way, I think studying the old school problems and their solutions can be both intellectually stimulating, and potentially increase your depth of understanding. After all, it's only once you've tried to solve a problem and failed miserably that you start to appreciate the depth of its complexity.
That depth of appreciation is sorely lacking in today's new cohorts, who are basically blinded by the incredibly convincing outputs of our cream-of-the-crop LLMs.
this is untrue. ml algorithms have nothing to do with gofai algorithms. if there is something one "would be better off surveying before diving head first into ML" it would be mathematical analysis, statistics, and probability
Even funnier to see how someone is always quick to explain that ´NN are not real AI’ when GOFAI was literally all about parsing, basic logic and search trees.
Personally, those "old" methods in the 80s make a lot more sense to me than recent statistical methods.
Same for me.
> I've been keeping my eye on the so called "GOFAI" for a long time but with recent advances in ANN methods (DL, LLM), does it even make sense to further pursue the former?
I think it still matters. Plenty of examples in the tech industry where "old" tech/paradigms became the new "hype". They say it's all a cycle.
Old techniques have several things going for them, with one of the more important ones for us being explainability. A random person off the street could hypothetically, with an hour or two of training, diagnose problems just by looking at the structure of the model. That's very helpful for adapting to market needs.
Generality is another big plus. Since the model encodes intuitive ideas there's a lot of room for using it in innovative ways.
Older techniques also tend to produce better results with less data, because big data wasn't as much of a thing back then.
Unless you have a crazy amount of resources, I think it's far better to be bleeding edge in as few things as possible. Solving a new business problem? Perhaps don't spend too much time on also solving all the childhood diseases of a new technology.
I think that going forward, we'll see a mix of "normal" programming, LLMs, and simpler machine learning techniques all combined together, because of economic reasons.
We switched from more modern techniques primarily because they needed too much data to work well, but the other things I mentioned are the benefits we noted along the way. I don't know if that answers your question.
Being able to trace how an answer is derived is also worth something.
Personally I avoid books like this one (similar to how I avoid very esoteric languages) because I want to spend my time on things are interesting and useful instead of only interesting.
Sorry if you don't get the metaphor, but it's like so.
As for GOFAI in the age of DL/LLM, yes, you should know it, for a couple of reasons. A lot of these techniques aren't really considered "AI" anymore, they're just regular CS algorithms everybody should know: graph search, backtracking, optimization, parsing, etc. The other is that a lot of newer DL/LLM is actually going back to these old problems, but bringing all the new techniques to deal with limitations of the classical algorithms.
[0] https://norvig.github.io/paip-lisp/#/chapter5?id=_52-pattern...
[1] https://github.com/norvig/paip-lisp/blob/main/lisp/patmatch....
I decided to give CL a try after reading about REPL-driven development, especially CL’s interactive condition/debugging experience. I’m almost done going through Practical Common Lisp. It’s been a fun experience so far!
Edit: thanks, everyone!
https://lispcookbook.github.io/cl-cookbook/ -- also great and up to date
https://awesome-cl.com/ -- for anything else.
One aspect of being new to the language is that I don’t know which libraries are commonly used.
https://www.youtube.com/playlist?list=PLTA6M4yZF0MzsMlNL0N67...
Read it to learn how to program, learn a bit about AI as an added benefit.
* SICP, by Abelson and Sussman
* Lisp (3rd ed), by Winston and Horn
* The Art of Prolog, by Sterling and Shapiro
It's like the same book written by different authors, and all of them are good.
Though, really, a lot of what it covers is much more common knowledge now than it was when I first read it. High-order functions and functions-as-first-class-citizens (ch1) are ubiquitous and most programmers I know are comfortable with them (which wasn't the case in the early 2000s, at least in my circle). Lists, maps, pairs, and symbolic structures are covered in ch2, but most people are comfortable thinking in such terms now. Ch3 covers handling state, and I think there are good ideas in that chapter that still haven't been broadly disseminated.
But where the book really shines is the last 2 chapters - I haven't seen much of those ideas (virtual register machine and writing a compiler for it) covered elsewhere. It's still a great way to get exposed to some fundamentals of computing from a pure software environment. But I think you could be quite a capable programmer without ever doing that.
Yes, its a book that uses lisp, but its not a lisp book. Its about programming techniques, i felt.
Of all the books that are usually recommended to be read and nobody actually does, this is the one that i actually read and liked.
I don't think you can have a good software education, in the sense of having a complete one, without studying LISP. It's a foundational paradigm of programming. It's kind of like studying physics and skipping Maxwell's equations, paraphrasing Alan Kay.
https://www.gnu.org/software/mes/manual/html_node/LISP-as-Ma...
So if you already have a solid CS education it's not really necessary, except maybe for the enjoyment of reading a really well thought through pedagogical work. Which can sometimes help coalesce concepts and the connections between them.
A question: is any of the currently hot software written also in Lisp? I mean the LLMs, SD, etc.
I would say so, specially when you plan to use it for web dev (welcome!). Shinmera has released a game in CL heavily depending on CLOS (object system), and he says the GC is barely a matter.
https://raw.githubusercontent.com/Shinmera/talks/master/els2...
Now, your time to build cool things and share in the process ;)
---
Going longer between garbage collection cycles could be worse in terms of caching and paging. Marking the live objects allocated in that generation is about the same, since that doesn't grow, but there is more garbage to visit and sweep. Sweeping a smaller memory area more frequently is going to be faster than sweeping a larger area less frequently, from the point or view of caches and TLB.
(Regarding my remark about live objects; with larger collection cycles, they could be spread in a wider VM footprint, even if their quantity doesn't grow. The image has a kind of "GC working set"; longer intervals mean that there is a longer working set. The data being transformed cycles through more memory locations.)
I don't think anyone's written a transformer or diffusion model with it, could be a fun challenge.