Lambda: the Ultimate Paradigm - European Lisp Symposium 2026

Added: 2026-05-15

[00:00:00]All right. So, welcome back this afternoon. I hope you had a great lunch.

[00:00:03]Sorry to wake you up.

[00:00:06][laughter] It's my great pleasure to introduce uh today's keynote speaker. I'm not sure actually Frans Reerido aka Far needs any kind of introduction. You probably all know him. He's been a an important contributor to to the communist community in particular. Uh he took over the maintenance of ASDF at some point.

[00:00:26]He's also a great traitor to the common list coast because he dropped the language and asferable scheme but we still do love him. Right.

[00:00:38]Right.

[00:00:40]So we do as a proof of love we had him as the program chair last year and we have him this time as a keynote speaker but that's not actually the reason why we do love him. There are two reasons.

[00:00:52]The first one is is French and the second one is shoes accepted.

[00:00:58]Here's a true fashion statement.

[00:01:00]So you have the floor with your shoes.

[00:01:05][applause] Today I'm going to tell you about the past and the future of lisp and let's start with a part who knows uh who are the people on this picture and what they're doing.

[00:01:19]Yes.

[00:01:21]>> No. almost >> it would be Steve Russell but uh it's not him >> Dan Edwards the left >> and uh Peter Samson in the middle and to the right we have a PDP1 playing space war the first and at the time only uh video game and it was indeed written by Steve Russell who is also the guy who wrote the first list implementation And to the left we have Dan Edwards Ward the the garbbert collector of of list the first garbbert collector. And in the middle we have Peter Samson who would write um PDP1 lip which is >> let me use these [whistles] >> Peter Samson who would write PDP1 list which was the first interactive uh language ever maybe at least first interactive list for sure and maybe programming language implementation.

[00:02:24]Okay. and and they both contributed alo also to space war adding things like gravity and whatever else.

[00:02:32]Okay. Lambda the ultimate who knows who these guys are. Yes.

[00:02:37]>> Tom Knight and green.

[00:02:40]>> Yes. Yes. Tom Knight to the left and Richard Glenbright to the right who are building the first machine and Greenblat is also the guy who did MLSP.

[00:02:49]So let's start the talk itself by a cone.

[00:02:55]A student in hopes of understanding the lambda nature came to greenlat.

[00:03:03]As they spoke a multic system hacker walked by.

[00:03:09]Is it true? asked the student that PL1 has many of the same data types as lisp.

[00:03:18]Almost before the student had finished his question, Greenblat shouted, "Foo!"

[00:03:24]and hit the student with a stick.

[00:03:31]Years before he built the connection machine, Danny Hillis composed this and other coands.

[00:03:39]Instead of Buddhist Zen masters and their disciples, these coans featured lisp hackers from the MIT AI lab. And thus, Danhillis launched a genre dispensing wisdom about modern computing informed inherited by the ancients.

[00:04:01]About the same time, uh, Susman and Steel wrote their famous series of papers. Lambda, the ultimate imperative.

[00:04:13]Lambda, the ultimate declarative.

[00:04:17]Lambda, the ultimate go-to.

[00:04:21]They launched another genre showing how to reduce programming paradigms down to lambdas.

[00:04:32]Then the question is um so what is this lambda that imbuss some software with its blessed lambda nature?

[00:04:47]What is this lambda that gives lisp its ultimate power? Is it functional programming? Many people think it's functional programming. The list hackers back then might have thought it was functional programming.

[00:05:03]It's lambda. It's in the name. It doesn't just rhyme with Buddha. It's essence of pro computing, is it? Well, no. These days, not just ML and Haskell, but even Python and JavaScript and even C++ and Java, they all have lambdas or another form of first class anonymous function. Do that possess the lambda nature? Does C++ possess a lambda nature? Does C++ process a lambda nature?

[00:05:35]>> No. No. Absolutely not.

[00:05:39]And if the lambda nature is not about functional programming, how can lisp itself have no if lambda nature is about uh functional programming, then how can lisp itself have claimed to process this lambda nature when it didn't actually have true lambdas until 1975 like 17 years after uh it was invented.

[00:06:08]So uh whoops this is the wrong uh oh no this is a sorry yes this is the correct one. So yes you can reduce all computations to lambdas and that's remarkable and lambdas are elegant you can compose them they are logically simple that's one of the simplest thing it's equivalent to functional implication so beautiful way to reduce computation beautiful thing to reduce computations to but you could reduce computations to touring machines this is a a finite implementation of a touring machine or a touring machine with finite amount of ink and finite amount of tape but otherwise it's chewing machine. You could also reduce all computations to machine code and that's actually very useful thing to do and people do it all the time and it's uh uh problem with machine code of course it changes from machine to machine and machines get old very quick especially back at the time but all that means is that lambdas and touring machines and machine code are universal and it's very important for a language for a general purpose language to have a a universal subset but it's also a basic requirement for a general purpose language I suppose that's what makes a language general purpose that uh it has a universal subset and so that doesn't make list special or any language special just mean general purpose so is a lamely nature just being a general purpose language well there's a saying that when a wise man points the moon the fool looks at the finger And the land does or like the moon. It's beautiful.

[00:07:54]But the uh the magic was in the pointing all alone and not in the lambda themselves.

[00:08:04]When a fool when any fool can point at the moon, the wise man marvels at the finger. Well, this tool that allows anyone to point at any semantics and make the thing happen. That's much more important that whether it's a lambda or a machine code or anything else. This ability to transform code from one form to the other. The finger, the wise mind looks at the finger, not the not at the moon.

[00:08:33]So, does lisp have a lambda nature?

[00:08:36]Well, let's see if it does.

[00:08:41]Was this great?

[00:08:44]>> Okay. In the 50s um they invented artificial intelligence like they anticipated it uh didn't make it happen for a while but still they advanced it more than anything else. Conditional expressions. Who doesn't have conditional expressions as a basic thing in language? It didn't exist before lisp. Meta circular interpreters. Uh interpreter the semantics of your language in your language itself. And we'll see how important that that is.

[00:09:11]Recussion. Recussion was a mathematical tools. You could use it to reason about programs, but it was certainly not part of any programming language before list put that in and many [clears throat] other things. I don't have time to discuss all that. great advancements by by Lisp in the 60s. Well, the garbage collection, macros, the ripple, it was called redevelopment cycle at the time, error handling as part of your language and all of plenty of other things in the 60s. Lisp advancements.

[00:09:44]Uh in the 70s, we had object orientation. The first object-oriented paper was by Bob row about Carol in lisp first class continuation lexical scoping extensible editors and so many things in 70s I can't list them all don't have time in the 80s we have class cas or whatever you how you don't don't care how you pronounce it it's the greatest object system ever designed by far it's still decades ahead of what exists today apart outside the list language uh languages they had massively parallel programming with a connection machine that had micro hygiene and plenty of other things. Uh in the '9s we have meta object protocols and web programming with continuations and a few other things in the 2000s module systems with face separation.

[00:10:33]Okay. Racket and closure things 2010.

[00:10:37]Okay. But certainly list was great more infos has been done in rust and in types for a long time and far better done in rocket but anyway uh yeah it's like it's been done many times it's just copy I mean maybe a bit better but copy and did list really invent anything new I mean uh list processing lisp well the first list processing language was actually IPL invented like in 56 by Newan Simon H. So is is it just like being a copycat of everything like even lambdas what is a lambda? Well, sure lisp was the first language with a lambda, but first he didn't invent lambda like the lambda calculus is church in the 30s. Uh he didn't even read church. He read clean who had a first order logic presentation of lambda calculus and he got it wrong. He didn't even implement lambdas properly. He failed to capture the environment and so he had he invented by by mistake dynamic binding instead of lexical scoping.

[00:11:47]So he got it wrong.

[00:11:49]uh is that not only he copied but yeah well anyway uh and then uh the list when they noticed that they had to invent something had a function special form that would explicitly copy the entire environment and then you do a linear search in a giant gigantic alias. So you could have it, but it was so expensive that you would avoid it like the plague if you cared any anything about uh performance, which people did in the time because machines were really slow.

[00:12:21]And so they only invented lexical binding in 75 when susman and steel found scheme and they still didn't use it until 78 when still sees this about rabbit showed how to compile it efficiently and by that time uh land in ' 66 I published a paper about a language called Icewim which is the ancestors of all the modern programming functional programming languages. It was implemented in ' 68 at MIT also by Arthur Evans and the BCPL team a language with lexical scoping. Then uh ML is also early 70s early 70s. So scheme is not even the first language with lexical scoping. H and yet people equate lexical scoping with scheme for for some reason. Some good reasons too because they popularized it. But so let's let's get this straight. Even though they had the word lambdas, they didn't have true lambdas for 17 years or or even 20 years if you count the time to to actually adopt it. And yet those 20 years were the most productive of of lisp. If you look at my my list, the 50s the late 50s to the late 70s like 20 years that everything was done. They invented objective programming, rulebased programming, everything.

[00:13:43]So they did not need the true lambda to be um to be productive and to have the lambda nature.

[00:13:51]What they did need is something different. Once again the the first lambda was copied and badly and list processing rule-based programming theory improvers type systems list copied them badly.

[00:14:06]every paradigm that been has been copied badly in list and that's the point they could copy anything badly and they could keep hacking on it and and turning it from epic failure to epic success because the language can keep evolving and not just from the outside by a a small cast of um anointed priests. You know any regular user of lisp can change the language and evolve the language and define macros etc. If you are not a lisper uh you have to invent a new programming language from scratch even anytime you have a programming language idea and then while you're a loan programmer or smaller programmer you only have the time to implement one paradigm and usually you also do it badly. Most people do it badly and some people are good, they do it well or they have the tendency to keep at it and do do it well, but they only have the time to do it once and the language evolution is left in the small class of language implementers and regular users they have to watch for the sidelines. They can publish bug report but if it's not in the priority of the language implement it will never happen. In lisp, you can quickly absorb any program paradigm invented by anyone else. And sure, you can do it badly and you can also do it well. And you can keep hacking and refining it until it's not bad anymore, until it's so great that and not just that. And it's great by itself and it integrates with all these other paradigms that you have also imported in lisp. That's something you cannot do in other languages.

[00:15:53]So lisp makes paradigms friends. And of course the obvious example is uh functional programming and object-oriented programming which for some reason in the 90s everyone knows are opposite to each other. Well back in the 70s Lisp had them both and Lispers wrote these two very nice um uh motos and then sure Bob Bro did not invent object-oriented programming. He published the first uh paper with this word in the correct meaning. The word was used with various meanings before. Uh Alan K invented the word but he didn't have a preset meaning to give to it. So short coin invented but so Bob bro did contribute a lot. He took something maybe pieces that exist but he did something totally new and he kept improving it. Every time someone had a new idea about object- generator programming, Bob Bro could integrate it in his systems. And in his systems, in the end, he produced cloth.

[00:17:01]Once again, the best by far.

[00:17:04]And so he didn't do it alone. And that's the point. He didn't have to do it alone. He could take random ideas from random people. um method combinations and multiple inheritance done right were done by Howard Canon, a nobody from MIT and he could do it and re revolutionize object-oriented programming never being much uh recognized for it but it was a nobody who did it and then the idea was kept and integrated to lisp. The poor of lisp in other languages never happened because the priest never did it.

[00:17:40]Lisp had all the paradigms then are now popular or unpopular deservedly or undeservedly functional object-oriented rule-based actors declarative imperative logic graphical what have you. It has all these paradigms long before any bigoted imbeile invented any opposition between some of them such as functional programming and object-oriented programming. The only real opposition that exists is not between the paradigm itself. It's between the fact that your resources are limited and therefore you can only do one paradigm or the other because you don't have lisp and you can't combine them incrementally.

[00:18:18]So the opposition is actually it's not an opposition between the paradigms.

[00:18:22]It's a limitation of people who don't have lisp.

[00:18:28]So next the serendipity of partic a go back memory lane.

[00:18:37]Well, lisp at the beginning uh had all something like called MX. It's a some kind of infix syntax like fu equals con of bar fu. That's how it was written in the beginning and it looks like a reg any regular infix syntax except they never fully formalized it.

[00:18:56]You you never find a consistent use of this MX or meta expressions.

[00:19:02]the first implementation. So there was a meta-circular imple uh meta-ircular interpreter written by MARCY which was a kind of a a fun thing like a look Turing did something like that we can do it same yeah we can do a Turing kind of fun experiment thought experiment and then a student called Steve Russell said you know what it's it's not just a fun thing this is an actual implementation we're going to uh implement it and it just works and run with it And that became the first lift interpreter.

[00:19:36]Uh and the thing is that his program took data as in as input and the data was written with this uh syntax with parenthesises and they used a lot of uh original syntax at commas but commas were painful to write and support or whatever. He preferred putting spaces.

[00:19:56]So that's how we got the the sex syntax was just a syntax designed for data but now it was used for programs too because he didn't have the space on these machines to implement both syntaxes and the MX were not formulized anyway.

[00:20:12]So in 63 Tim Hart who was maintainer of list 1.5 invented something called macros and here's what the very first macro looks like the stash macro which is kind of push with the arguments in the other side and here it's what it look like including all the bugs in the first report on macros. Uh you can read the slide and find the bug later. Here is uh PDP6 uh in ' 66 by is it Peter Samson?

[00:20:43]Maybe it's Peter Son. Oh yeah, I was confused. PDP1 was El Peter Deutsch and Peter Son's PDP6. So he's the first one who decided instead of having this magic forms at the beginning where macro see you have a command and then you have the arguments. It's just like a batch processor in any comment processor except that your arguments are structured. Ooh, but it's still constants and you read the name of a constant, a macro, you need a constant argument and you evaluate it. It was called eval quote. And Peter Simpson said, why would we just use eval also for the top level things? So now there's no difference between the top level forms and the regular expressions. And so the the saying that list knows the value of everything that comes after that. Before that, it was not true. The top level forms were different. This what you typed were different. So and he could do that because Peter Deutsch had made this interactive. So now it makes there's an evolution like first you have this theoretical thing then it becomes practical with batch processor then it becomes interactive and and after things become interactive like that people only think in terms of parents because you think as you type and then you don't have type you don't have time to think in terms of MX and then translate to to sex. It's um directly sync and see you don't co then is still full full letters 69 greenlat writes mlisp now you have defen defer it's 69 and quotes is a quote character uh this is 79 list bash in list now you have def macro 79 like 20 years later it looks very much what you have in common these days and you even have back quotes oo and lower case. It's not lisp lisp uppercase all caps. Now it's lisp big l small IP.

[00:22:42]Uh this is common list the language because now we have a notion of places uh which you can set it or read from it and if you don't want to if you want your place to be computed but you don't want to comput it twice because of side effects um there's some slight complications.

[00:23:00]Uh in 91 you rename get set f method into get set f expansion because method needs something else because now we have a built-in object system. Um and of course uh very different approach the schemers they don't have a notion of place or they don't care they don't care that much about side effects just don't do them. So this they have this uh version that's simpler and hygienic.

[00:23:24]Okay. So what we did see uh through all these uh things is that the language evolved and evolved a lot and took more than 20 years to go from the invention to something that resembles what we have now and even 30 years you should actually have what what we have now hasn't evolved much since.

[00:23:47]So what uh what did we do? Why did it work?

[00:23:55]Well, um [sighs] I have glitch of display glitch.

[00:24:06][sighs] That's okay. So, Matt Cary, like Alan Turing, dreamt of inventing thinking machines. What he discovered instead is a machine for thinking, a language design that minimizes the overhead to express new ideas. [snorts] Your ideas can be incremental and interactive extensions of existing ones. Your ideas can be cheaply refined into better ideas.

[00:24:36]The language minimizes drudgery.

[00:24:41]Uh [sighs] wait, let me uh read that on a different terminal. This is not working. Um, uh, [groaning] no, that's my that's, uh, don't buy an ARM laptop unless you want protection against malware because the malware expected um, Intel laptop. True story. Don't don't ask me how I know. Um, uh, you want a language, he discovered a language that minimizes drudgery. No more building parsers and runtimes. No more expanding design patterns by hand.

[00:25:26]No more dealing with boiler plates. The programmers can focus on the semantics of their systems and they can go straight to the notions that matter.

[00:25:37]This is what made Lisp a great substrate for innovation and development. its meta capabilities, reflection, macros, embedded domain specific languages, etc. A low barrier to entry for new ideas that you can easily copy from any other language as well as grow in house. TSOT wrote that immature poets imitate, mature poets steal.

[00:26:08]Lisp enables mature software poetry sorry.

[00:26:24]So what happened then?

[00:26:26]So why did all this progress stop? You remember my slides like 50 60 70 is great. 80s is still pretty good and then it stops some sometime between the late 80s and the mid 90s. What happened? Does that mean lisp hasn't changed for the worse? At least it has improved. Uh if you try to use list from 1994, you'll be very disappointed.

[00:26:54]So it has improved and yet despite this improving the output and the creation like almost disappeared or slow down certainly and the relevance of this certainly thinned.

[00:27:08]So does that mean that list does not have the lambda nature anymore or does it still have it and and yeah what what happened there there must have been other factors at stake that this metability factors that were present then can you okay okay factors [snorts] that were present then and that have disappeared. So what is it?

[00:27:37][sighs] I previously likened the power of lisp as that of being able to point a finger at semantics you're interested in. And pointing a finger is something you do for a spectator.

[00:27:51]And one of the spectators is a machine that will evaluate the semantics.

[00:27:58]But other spectators, just as importantly, are the humans who will understand enough of the semantics to keep developing the software based on it.

[00:28:11]This is a map of the arpanet in 1973 at the height of less development and you see that MIT is there and BBN and Stanford and uh something I don't know where is Xerox. So all the big players in Lisp were there and other players in Lisp like people these people were connected they were at MIT Central BBN park which are elite well-endowed institutions interconnected and lavishly funded by DARPA. They gathered a critical mass of exceptionally talented researchers.

[00:28:53]So this is what we call a semiasy or at least what Norah Bateson called them sea.

[00:29:00]Given longtime horizon access to the best computer hardware available and superior electronics communication channels uh they formed sim which is a group of people who learn together. a living mutually reinforcing culture where people discover uh new things and learn from each other and break new grounds and grounds that the mainstream computing would not reach for decades.

[00:29:27]And then what happened? Well, by 1987, these machines that were luxury were losing ground to much cheaper Unix workstations, which like for for onetenth of the price, you could have a machine that was faster and had a bit less memory, but you know, we could still pay more to have the memory. At the same time, the listbased research programs were losing funding due to the unfulfilled promises of AI, which will never happen. like it's all No. Well, it looked like that way in 1987 to the funders of DARPA who decided to cut the funds. And what makes things worse? This is a nice keyboard. This machine keyboard uh in 1991 something else happened or 1889. Well, 89 depending. Yes. In 89 uh Berlin wall fall fell which means that the big enemy did not exist anymore. There was peace no more cold war to reap the peace dividend who could even further slash the defense spending.

[00:30:34]So now DARPA didn't even have the funds to cut the list hackers from. You could not even try to recycle your list thing in something else.

[00:30:43]The list talent was dispersed into an industry that had grown around the business of workstations and now mass market PCs that were catching up and both business workstations and PCs were efficiency first cultures driven by short-term competition very different from the subsidized laboratories where List grew up and was discovered.

[00:31:09]Instead, we had languages like basic, Pascal, C, C++ or Pearl that occupied the niches of development of the 1990s.

[00:31:23]Niches that advanced hackers had afforded neglecting. Who cares about machines that have less than one megabyte of memory, you know, but uh not everyone had neglected this these niches? And so the only small pieces of list that survived are those wherein listpers have inspired Java or JavaScript languages that are now still very popular and brought half of lists with them except those that count of course except the lambda nature of list.

[00:31:57]A minority of researchers and hobbyists and a few odd people in the industry.

[00:32:01]Thank you. uh kept using uh one or many of the dialects of Lisp uh but there was no longer an active force driving list forward and driving and keeping the community together.

[00:32:17]because these disappeared instead now we have a tower of babel of dialects of lisp uh tens of which are active the once dominant commonly standard still has a dozen active implementations maybe one more thanks to senosan here and uh they are different enough from each other that they don't quite interoperate but they still interperate to some degree that's common lisp then there is team that has more standards and implementations and but still a lot of implementations like don't not because there are few implementation just too many standards uh and then there are few application specific dialects such as emacs list or auto list that survive or die with our application there is now the practically minded closure that has had enduring uh industrial success any closurists around yay thank you and of course rack market in in in the subset of the um academia has been developing its own SIMs but it's not as well funded and not as elite as it used to be and certainly doesn't gather all the whispers and so these listers the list languages are incompatible not just with each other but even more so with mainstream languages and introduces an impedance mismatch and a non-negligible cost if you want to share code between lisp and uh C or Java or whatever it's it's doable but it's very costly and so the breakdown of this community of lispers has also prevented the resurgence of any unified sim around lisp as it was in the 60s or 70s the communities just gather to all to all the winds uh there's also The lone wolf curse the fra the fragmentation of the committee is not just linguistic it's cultural lisps selects for brilliant individualists the very confidence that makes a great lister becomes a curse without [snorts] the institutional structures that once chneled it into collaboration.

[00:34:42]Each hacker builds their own cathedral.

[00:34:45]None of them interoperate.

[00:34:47]The collective output is far less than the sum of its parts.

[00:34:52]Markver diagnosed this in an article called the bipolarist programmer.

[00:34:57]Interesting read whether you love it or hate it. And without the shared hallways of MIT or park the meccarsis, Bob Rosro, Huitid, Susman, Steel, etc. don't have anyone to crosspollinate with. They're only lone wolves.

[00:35:14]Few exceptions. Thank you.

[00:35:20]Interestingly, another phenomenon has limited the amount of cooperative experimentation open to listers.

[00:35:27]The common list standard has drawn a line with conformant code above the line and conformant implementations below such that it is very easy for lispers to experiment above the line.

[00:35:42]But it is what is below is a black box.

[00:35:45]You have tens of implementations to be compatible with. You cannot assume anything there. And experimentation is just both extremely hard and totally non-portable. very high cost and low benefit. Not impossible, but much less possible and much less affordable to a point. The increasing efficiency expectations led on compilers and the complexity of code capable of fulfilling such such expectations has led to a similar line on every dialect and implementation of lisp or any language.

[00:36:21]If you want things to go fast, it has to be complex.

[00:36:24]But list still makes it so easy to extend the language from above. And it used to be easy to extend it below. You could just open your list machine system and extend it. It's not possible anymore. There are too many implementations are too different and too complex.

[00:36:45]But there is a bright future awaiting us.

[00:36:51]So are we condemned to see the list gone forever like this is the empty school of ascensure all for not or its serendipitous discoveries to be forever lost a memory kept by old daughterers and eccentric owners I will argue that the age of AI though it was not brought by lisp and the AIS of the 1980s is a boon for lisp in the 2020s.

[00:37:29]The lambda nature of lisp was its ability to collapse the distance between a concept and its expression. This ability holds for artificial intelligences just as well as for natural stupidities.

[00:37:44]As great as an AI may be, it will always be finite in size and limited by costs.

[00:37:51]It will always be important to save on neurons, on tokens, and whatever resources these machines have while tackling increasingly hard problems with combinatorial explosion.

[00:38:05]When handled na n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n naively, the issue of representing ideas precisely and concisely becomes an objective and reproible reproducible matter of costs and capabilities for AIs when the same matter was only subjective and personal for humans.

[00:38:25]Now you can actually give a number to whether lisp is or or isn't better. So if like me you think that lisp is great, you should see that as an opportunity.

[00:38:41]So anecdotal evidence shows that a human has about the same failure rate per line of code in any programming language but still needs an order of magnitude fewer lines of code in lisp compared to non-Lisp language or blob as Paul graham dubbed them. I conjecture that the same observation will hold for AIS and that you can save an order of magnitude in AI codes by programming in lisp versus blob languages. I haven't tested this hypothesis hypothesis yet but I invite you with me to test it if you have tokens to spare. try to have them program generate code in lisp versus another language and see how much tokens it it takes in one one case or the other.

[00:39:38]Now, of course, there remains a problem of interoperation.

[00:39:42]Using a marginal language like your favorite list dialect means that you cannot benefit from code written in other languages, whether lisp or blob, without spending scarce resources in writing either a wrapper or translation.

[00:39:59]But AI just vastly lowered this cost.

[00:40:03]Previously you would need weeks of skilled work your work to write a rapper or translation of existing code. Now it can be generated in matter of hours by an existing AI. Oo that means that all this expensive FFI layer or rewrite layer can be made cheap reviewed. You still need to review the code. It feels time consuming but now the AI you can query it interactively to understand the code that you are reviewing. it can still be reviewed faster and the result is not perfect and but it's still improving at rapid pace which means that it's not a solved problem but it's a problem that is much cheaper to solve than it used to be and I would say that the cost of the wrappers and the translations doesn't change when you use the resulting software a lot of times so it's an investment that can pay that can pay back the the savings grow linearly with the amount of stable um code you you produce.

[00:41:08]So AI does not solve the language fragmentation issues but it makes them manageable just like we don't uh deal with units anymore. We just uh use computers to automate unit conversion.

[00:41:25]Diving assistance AI can handle uh can help untangle legacy code. It can help refactor it into cleaner code, document it, explain it. It can add test and specifications and correctness proofs.

[00:41:39]And modifying a language implementation below the line while still hard is much easier with AI. it can help you navigate the source code you're not familiar with and generate a lot of the a lot of the thing it can generate a test etc. So at some point you might want to modify common lisp to unify classes and strrus as per my book lambda's ultimate object using my C4 linearization algorithm and before AIS it means that you would have to tackle the implementation of SBCL and other implementation very costly weeks of work now it can be done in hours or you can maybe try to add better support for lazy evaluation into your list. And to do it properly, you need to hack the garbage collector. Guess what? The AI can help you do that. Tasks that were previously out of reach are though physible.

[00:42:35]So AI is an amplifier. It can amplify your go your good code or your bad code.

[00:42:41]You can generate lots of unmaintainable boilerplate or you can generate well factor wellactored uses of macros and DSLs.

[00:42:53]Uh I often talked about three comma programmer which is a list version of a threestar programmer. Who knows what a three star programmer is? Okay. So a three star programmer is a programmer.

[00:43:05]It's not just it's not like a three star restaurant which is a very good restaurant. It looks like that. But a three star programmer is a a C programmer who writes code that has star store star which means like three level of indirection. if you can follow it. uh you're one you're good and two you have lots of time to spare and a three comma programmer well you can guess it's a list programmer who writes comma comma comma h so yeah if you are a three ka programmer you can handle a lot of complexity that means you're bright but also you're not bright enough to simplify this complexity away can be a four comma programmer or it can ask it to refactor the code and make it easier to so it's amplifying good things and the bad things. So it will AI will give you code that is too stupid or too clever, correct or incorrect, complete or incomplete, relevant or irrelevant, simple or complex, maintainable or earn. It will do the good or bad things for you. It will amplify you but it will also enable you to be listeners in a new sematzy.

[00:44:28]So this is if you can't see can you see what's on this thing? It's the same um school of asens but now everyone is a robot.

[00:44:39]Thank you to slap generators.

[00:44:41]Well, I believe that AI code generation can enable this new age of listbased cooperation in the exploration of software concepts. A rejuvenator this community that innovates faster than blob languages in topics that are relevant to the world out. But it is not automatic. It requires deliberate effort by you and me. We still must want to exchange ideas with each other and AI may facilitate the publishing of our ideas and the finding and understanding of the other of the ideas of others but still we must produce the thing and use the AI to do that. So I have a prophecy and a challenge.

[00:45:27]So the John Ky discoverer of list was an extreme optimist and I do not share always his extreme optimism but when I do I remember that change happens not outside people but through people and so lisp or the equivalent ideas will win I'm convinced that it will win even if no one listens to us and everyone does list it will be reinvented But yeah, if we if it doesn't happen to us, it will happen to someone else. But it can happen through me and for you if we do the right thing and build this new AI assisted list.

[00:46:11]So come and enjoy with me the days of innovation and cooperation through expressing programming concepts as directly as possible through incrementally extending languages with new concepts. Through absorbing any and all paradigms into lisp faster than others can develop them outside lisp with barriers lowered through AI.

[00:46:36]Thank you. And before we leave, I want of course to pitch my book Lambda's ultimate object. I think I will talk about it tomorrow. So let's not talk too much about it. And I want to tell you something very important.

[00:46:58]That's all.

[00:47:01][applause] Do we have time for questions?

[00:47:08]>> Yes, >> we do.

[00:47:17]Um, thanks for the talk. Uh, especially the end. I have to just I'm going to make some comments more than a question.

[00:47:22]Yes.

[00:47:23]>> Uh, because I do what you were saying at the end resonates a lot with me. Um, I was fortunate enough, thank God, to get some I had a decent uh job [clears throat] so I could take some time off and I'm using AI now uh to generate a lisp system and to create a lisp language my own dialect that I could never have done before. Nobody would have given me the team. Nobody would give me the money. I I wouldn't even have the ability in my brain to do it.

[00:47:47]>> Yeah.

[00:47:48]>> But I had a vision that I wanted to achieve and I was able to achieve it.

[00:47:51]>> Right. And I have to to some degree I was maybe do a lightning talk on it. But there are some problematics with it. I would like to point out there is very little benefit in me actually collaborating. It slows everything down unless you have a really unique idea and let's talk about a unique idea but sharing code if I can move 10 times faster at least 10 times faster than I could do before. And I have to then slow that all the way down for human processes where I go to a PR and I wait for somebody to read the email and I wait for them to look at it and wait for them to maybe decide that they might accept it.

[00:48:25]>> It's just not it's not going to work anymore.

[00:48:27]>> The time scales are too truncated. If you're moving that speed and then you suddenly have to stop.

[00:48:33]>> So it's just where's the advantage?

[00:48:36]>> Uh so yes, list can uh once again AI is an amplifier. It can amplify the cursed list programmer as well as it can amplify the semasy and it's a matter of legacy and what you want to live in this world. If you're happy with the ephemerality of code that is generated and forgotten that's fine and I don't want to discourage you from that. If you want to partake in the same that's fine too and and the two can coexist together and you can partake in it both. You can start with code you generate at some point you think oh this part is stable enough that I want to share it or not it both are fine I'm not saying that there's not space for it but I'm saying there is a space for list symmetry that there was not even a few years back >> it gets more it gets worse than that it's not like that I I mean sorry if >> please give this man the microphone please >> no sorry we can talk >> okay after one next Okay. Um, you talked very briefly about the AI winter.

[00:49:42]>> Is it not because there was no standardization for an ABI maybe because people did not sell computers that would work with it. The list machines were not ready. Well, they were ready for a lot of things, but whatever they were ready for, they were like 10 times or more too expensive for like list machines had hypertext documentation systems, multiple language integration, uh, higher resolution displays, etc. before anyone else. There are useful things, but they did not scale down.

[00:50:16]They scaled up every time.

[00:50:19]>> Sorry.

[00:50:19]>> They did not scale down in >> Yes, they did not care about and processors and did not care about poor people. They were fun.

[00:50:27]>> This is a compiler part coming up right now.

[00:50:31]>> Okay. Uh next I think uh sure it's not a question. Next.

[00:50:42]>> Yeah. So a bit uh philosophical vintage angle on what you saying about uh you making a better language, better lisp using AI as a leverage.

[00:50:52]>> Yes. What do you think is the point of making a better lisp if it's increasingly being used by machines to generate?

[00:50:59]>> No, you the point is not necessarily making a better lisp is making if you like lisp there's chance are that you think list makes you productive because it compresses the amount of things to say for your thought. It it minimizes the irrelevant. It makes you focus on the things that matter.

[00:51:23]it the li the AI that generate code has the same issue. It can generate one gigabyte of boilerplate with like just one like 10,000 lines that hide in in the middle or it can generate just those 10,000 lines and it will require much fewer tokens and not just that it means that with fewer tokens you can keep more things in context. So you can address larger pro problems by writing your software in lisp or something listike versus writing it in blob and and millions and zillions of lines of of boilerplate. So if you believe like me that lisp is valuable, it will be also valuable for the same reasons to the AI and then the point is not making a better list or I mean yes as a side effect but the main point is that lisp is better and will help you write better software.

[00:52:18]This gentleman here um I have two questions. What do you think of the statement that um there is less of a corpus of lisp software on the net than for C and JavaScript and that therefore uh large language models that write code will do much poorer for lisp than for JavaScript or C. So I don't know if it that's a good question and indeed uh they are better trained in the C and in list but you know the list syntax is pretty easy to learn >> want to ask for question >> for users for humans as well as for machines the list syntax is the easiest part of lisp and as for the semantics well the whole point is that you don't stay within the semantics of basisp but you zoom into the semantics of your problem So in my experience sure it makes error lots of mistakes writing uh gerbles code or common list but still it's useful it's already useful I could have it generate hundreds of lines of code that are worth thousands of lines of code of another language. So is it perfect? No.

[00:53:36]Is it already useful? Yes. And will it already save you lots of tokens and make code that is much easier to review because it's much smaller? Yes. I think it I think it's positive. Some of it is a conjecture but I think it's something if you are here you're interested in list and you should try.

[00:53:55]>> Okay. I have another question.

[00:53:57]>> Okay.

[00:53:58]>> Word on the street has that you transitioned from common lisp to gerbil scheme?

[00:54:04]>> Yes.

[00:54:05]>> Uh can you say something on the reasons uh for that?

[00:54:09]>> I wrote a blog post on my live journal about the detailed reasons. So uh I don't remember all of them and I don't have to because I can refer to that. But one of the reasons is that I found the list community not as welcoming as I wanted it to be. I mean most people are welcoming. Everyone here I think is welcoming but uh there were a few toxic elements that made my life harder. And also the language is less able to evolve. common list has been the same since 1994. It's a strength in some ways. It's also a weakness in other ways and I'm interested in those other ways to to make changes under the language and I cannot do that with common list and so I could I could pick one common list implementation say HBCL but I decided to adopt durable scheme because I some objective and some subjective reasons I I'm friend with viso and uh it's a language that I I can hack at all the levels and for instance one thing I did is this C4 like hack of uh object system. I could very easily do that in general scheme because I master it. It's possible to do in common list. Actually, I may or may not do it uh if I have copious free time, but my copious free time is cheaper now that AIS can actually do most of it for me. So, we'll see. Actually, I think an exercise in my book is implement C4 for your favorite language. So you know maybe you read my book and you do the exercise I don't remember the number but implement C4 for your language which was an exercise would be totally out of uh like totally out of left field in before the invention of AI. You would not ask a reader of your book to implement something for the language but now with AI yeah the AI will will do most of the work. So you can Yes, this gentleman there.

[00:56:04]>> The internet has a question. Uh, the internet would like to know what list projects you have worked on with current AIS that support your thesis.

[00:56:14]>> Uh, well, I have the AI proof in my book and it it doesn't only find uh misspellings, it actually find logical mistakes in my code. Sometimes I did a incomplete refactoring and it could fix it or find that oh you forgot the word not in this sentence. So it has a semantic model. Uh I wrote uh an implementation of list style inheritance in C++. Well I didn't code did uh I would never have written the C++ code but I can review it. Uh it is implemented C++ style stupid inheritance uh in lisp. also something a project that would have taken me days spent in vain to to write some stupid code that no one would use. But with AI, I can prove that it's possible and it's simple and that the reason people don't use it is not because that's hard or impossible, but because it's stupid. So you can prove thanks to AI that C++ is stupid. That's I think that's a good use of AI.

[00:57:14]Objective proof that C++ is stupid, not subjective um taste.

[00:57:22]Yeah, just a very quick comment. I I completely agree with you on the uh amplifying property of AI. But the interesting thing I think is that lisp is also an amplifier of some kind because [clears throat] the language by design being as permissive as expressive but at the same time as permissive as it is. It it really can amplify your genius ideas or your utter pile of crap. So as a musician I think we must be extremely cautious because amplifying the output of an amplifier all hell can break loose.

[00:57:57]>> Not I I think they amplify things along uh orthogonal dimensions and so that's fine. Yes. So I'm not worried about that but yes it's it's interesting remark.

[00:58:09]>> The name of the scheme that that you two mentioned >> durable scheme con.io cs.io io.io.

[00:58:19]>> Yes, I it doesn't work right at the moment. Uh github.com/mighty-jerbles plural uh gerbble >> gerbal scheme gerbble >> gb i b i l >> g e rb i l mighty-jilerbal.com >> what [laughter] github.commighty >> github >> mit-jerbble that's what mighty Mighty M. M I G H T Y.

[00:58:57]>> M I G H T Y D.

[00:59:03]Good.

[00:59:05]>> Do I have it here?

[00:59:10]>> Uh [sighs] let's talk about that later. Uh >> let's talk about it over coffee.

[00:59:16]>> Personal issues.

[00:59:18]No, it it will be solved. It should have been solved today. Okay. Any uh Oh, no.

[00:59:24]Tomorrow. Anyway, um or later today.

[00:59:29]>> Okay. Thank you. Uh >> thank you very much and please come join my list with trouble scheme.

[00:59:39]>> It's the same as common list because the boyers are down.

[00:59:44][applause] >> Thank you. And now let's have another coffee break.

[00:59:51]>> Yay.