Marvin Minsky - The beauty of the Lisp language (44/151)
HTML-код
- Опубликовано: 7 сен 2024
- To hear more of Marvin Minsky’s stories, go to the playlist: • Marvin Minsky - The am...
The scientist, Marvin Minsky (1927-2016) was one of the pioneers of the field of Artificial Intelligence, having founded the MIT AI Lab in 1970. Since the 1950s, his work involved trying to uncover human thinking processes and replicate them in machines. [Listener: Christopher Sykes; date recorded: 2011]
TRANSCRIPT: John McCarthy was a good programmer; I was a… not very good programmer and he had invented this wonderful language called Lisp, which was based on the nice language that Newell and Simon had invented called… no, it’s called IPL, Information Processing Language. IPL is made of little atoms and it’s very tedious, and McCarthy’s invention was… it was more like FORTRAN, which was… which is a language… IPL just had little instructions, FORTRAN has statements, make this true, and Lisp had statements with a very clean syntax. It only had… it basically has five basic verbs, whereas FORTRAN has a big mass of arbitrary… has a big library, and so McCarthy’s was a very elegant cleaning up of… of computer science. And thereafter, there were two kinds of languages, the algebraic language FORTRAN, and this recursive language call… based on Lisp, which… they’re now dying out because of… in a Lisp program, you can write a program that writes Lisp programs so it has a kind of open future; now, no… no-one actually does that yet, but it’s still possible. In the other languages, it's almost… you can’t write a C program that will write a C program, it’s just… there aren’t any verbs of the right kind, so to me programming hasn’t changed much in 50 years because they got locked into this… strange set of limitations.
I like how he talks about the LISP programming language. He sounds passionate about LISP.
talking about homoiconicity brings him joy. So beautiful.
Beautiful point about the distinction between code and data. 🥳
He said... You can write a program in LISP that will write a program in LISP. That is the definition of AI
Why do we code directly in Lisp? Why don't we put a visual layer thats maps 100% onto the textual Lisp, but lets you fit the code tree more on the screen (maybe make it 3D). Also the instead of doing fixed character we should have token boxes which represent a token, with the parens being replaced by darker shades of colors. Also paredit should show various commands with highlighting when you hold the shift, alt, ctrl, C-M keys like showing two to four commands then by holding it longer it will show more commands.
The visual layer will make it so that if you want Lisp to look more like Haskell you can, and if you want it to look more like C you can. Through ambiguity resolution also you can convert infix operations into prefix as well.
Am I the only one who finds the parentheses beautiful? No sharp edges -- everything is rounded, beautiful, flowing. And you can tell at a glance if a function is tail-recursive, structured around a loop, or just a normal function -- based simply on its overall shape.
I'll never understand why people hate parentheses so much.
I do agree with Stray, that parentheses are beautiful, "No sharp edges -- everything is rounded, beautiful, flowing."
But I do find your concept of a 3D visual LISP environment intriguing, very intriguing.
@@stray2277 i like sharp edges though
Visual representation of programming languages has been tried numerous times and has failed. Prograph, a popular one, was impressive at first glance. As soon as the program became at nontrivial in the slightest, however, it turned into an unmanageable rats nest of connections.
funny how many things he's saying aren't really true anymore
- lisp is getting a bit of a resurgence, not a big one, but big enough to have spawned multiple dialects in the past 10 years
- "nobody is writing lisp programs that write lisp programs", that solely depends on what you mean by "program". In a sense, every macro is a program in and of itself
- "you can't write a c program that writes another c program". I mean you can, it's just kinda inconvenient to do
Niko L spawning multiple dialects is a bad idea... there should be one dialect although there should be some configuration as long as people can work together. Many people have created view layers on atom, emacs, and visual studio code which converts your code into sexpressions with boxes and you can switch between infix, prefix, and postfix like in Mathematica. I’ve seen projects that do this, but if you try to bundle them into the lisp box newbie distros a lot of the old doggies get upset, maybe if they are more mature it’d be nice. I also want to put small ruby chars on top of the lists to write the argument names and test values so you can see the data flow while you are coding. The test values can be mined from sample runs, I’ve seen it done with Juno for Julia, light table for emacs lisp, and light table editor.
@@aoeu256 say that to C and all of its dialects
@@NikolajLepka D isn't popular at all though... C and its dialects are popular because of backwards compatibility; it wasn't until the 90s that Lisp could be run on normal computers and at that time it was easier to just port your C++ code to Java & C#. It wasn't until I saw SCIP that I understood the power of Lisp's eDSLs, but by that time Scheme had fragmented, and Common Lisp has no standards committee anymore.
I look at the Common LISP spec, and that predates the popularity of POSIX-based OSes. So you see it is full of awkward constructions in its file-handling system, for example, for coping with weird pathname syntaxes.
You could chuck most of that out today, and end up with a much cleaner common standard.
@@lawrencedoliveiro9104 a Common-er Lisp, if you will
What the... Who had the nerve to downvote this?! Ugh...
Exactly, must be fools
fortran programmers
Over the years, dissenting voices have been raised against the "C can't write C" idea. Minsky is actually right: one can't write a C program that writes C programs in the same way as one can with Lisp. See my comment to Mark Archer for an explanation.
I see everywhere that people consider Denis Ritchie to be one of the best programmers, but I think he could have retarded the growth of technology. The C language makes "hot-loading" the thing of von neumann archictecture difficult, and not only can C not write C but Shell scripts the so called high-level alternative to C in Unix can't write C very well either. C makes applications take millions of lines to write and the Operating System is then tied to the CPU/memory architecture of the computer. A better way of coding is to build compilers (Lisp MACROS) to generate low-level programs like LLVM intermediate code or C from a declarative code description of your program. This requires the programming language to be high level (higher-order functions, generic methods, programmable semantics, macros) so that building compilers takes less code than writing in C directly.
Genius !
what are the "five verbs" he's talking about?
atom, eq, car, cdr and cons, I think.
quote, atom, eq, car (first), cdr (rest), cons, cond. See lib.store.yahoo.net/lib/paulgraham/jmc.ps for a description of these verbs (special forms) and how to write an interpreter for Lisp in Lisp using these special forms.
Minksky left two out or else he was familiar with the first iterations of LISP that McCarthy invented.
I believe there are 7 basic predicates in LISP that one can use to bootstrap LISP.
However, to explain these predicates requires a deep understanding of LISP itself and its philosophy.
@@englishverseyou really only need 2 things. eval and apply. but it helps to have more than that.
Well I can write a C program that writes a C program but I would likely have to invent a fair amount built in to Lisp to do it well. :)
LISP is the silly putty or topology of computer science. A space within which to think, without applying a metric
LISP is a language designed to dream in: the code you can dream is the dream you can code. LISP can be bootstrapped from seven predicates. Minksky left two out. Go read the book "Let Over Lambda" to get a true feel for what I am talking about. LISP is the most language agnostic of all languages. In a deep sense, all languages are sublanguages of LISP. They just don't know it yet.
There is a reason why LISP was developed by McCarthy in 1958 as THE language for AI research.
Even today, I am still doing things in LISP that I have never done before today.
Could you give examples? Do you have a github profile?
It is so remarkable how people miss the boat on this LOL
Well, they likely need to read the book "Let Over Lambda" to get a true feel for what LISP is all about.
LISP. It is utterly mind-expanding.
How many techies do you know that have expanded minds? Most do not stray far from their own boxes, no interest at all in philosophy, which is what you need to "grok" LISP.
LISP is all about thinking, thinking about thinking.
It is meta-programming. That apparently hurts a lot of people's heads.
I always say: it's lonely at the top.
@@Antiorganizer Smalltalk is also pretty good, its an infix LISP based on keyword arguments.
@@AlexRodriguez-gb9ez The live coding aspect of Smalltalk is another gem that's lost.
Inspiring
:-(
People just want to make money instead of writing self-writing programs
swell guy lisp programmers will spend time building new languages into lisp and then lisp will split it a million languages, while python programmers are locked into building libraries
why not both? :3
crocodile gena toy. wow
Number of people actually getting it.... meh, nearly zero.
Of course you can write C programs that write C programs.
He lost me there. I did not get what he meant.
But in another way. Look into Lisp macros - not to be muddled up with C-style macros! A whole different beast.
Yes. But it is completely antithetical to the nature of the C language to do so. C was and continues to be one step above assembler, yet still letting you get into the metal, when you need it.
LISP is a language designed to dream in: the code you can dream is the dream you can code. LISP can be bootstrapped from seven predicates. Minksky left two out. Go read the book "Let Over Lambda" to get a true feel for what I am talking about. LISP is the most language agnostic of all languages. In a deep sense, all languages are sublanguages of LISP. They just don't know it yet.
LISP is all about thinking, thinking about thinking. It is meta-programming. That apparently hurts a lot of people's heads.
LISP is the silly putty or topology of computer science. A space within which to think, without applying a metric.
What is more fundamental, I think, is the way macro processing is done. Doing it at the string level (as the C preprocessor does) is fiddly and fragile and troublesome, while doing it at the syntactic token level (as LISP does) is wonderfully powerful and elegant.
I tried a more powerful string macro processor in the form of m4, thinking it would be nicer than the C preprocessor, but it wasn’t. Its greater power just made it even more fiddly and fragile and troublesome.
It is way more complicated than in lisp: you must write the C source text in a file, then call the C compiler with system or fork/exec, then produce a shared library, then load this shared library with dlopen, find the symbols naming the functions you generated with dlsym, and then you can call those functions. In lisp, you can just do (eval (generate-an-expression)). Eg. (let ((a 42) (b 33) (op (aref #(+ - * /) (random 4)))) (eval (list op a b))) and obtain 75, 9, 1386 or 14/11 depending on the random operator selected.
A C program can write a C program. Just not as easily as Lisp can write a Lisp program.
Haha I thought the same thing. I've done it in C.
ASM program can write ASM program. Just not as easily as Lisp can write ASM program that write ASM program.
Yup that's also true! I'm glad we agree on the facts ;) It's important to keep them straight. I'm not sure why Marv said "you can't write a C program that will write a C program". That's clearly false.
If fans of Lisp are going to convince the world to use Lisp, we need to clearly communicate why it's better, not assert things that are demonstrably false.
Of course you can output C in a C program. In a language such as Python you can even call eval and execute it at runtime.
But only Lisp/Prolog/Rebol has the homoiconicity thing that allows to treat data and program indistinctly.
I agree, homoiconicity is a great feature and languages that have it feel superior to me than ones that don't. But there's nothing to stop someone from implementing that feature in C as a library. C can do anything Lisp can and vise-versa. This was proven by Alan Turing before either language was even invented.
I think what we want to be talking about is how expressive a language is. Think of hieroglyphics vs modern alphabets. And I think Lisp is much more expressive than C when it comes to inspecting and manipulating algorithms. But expressiveness is pretty subjective so we want to be careful when making assertions about it.
wtf is the description? Born in 1927?
Yep.
@@no-defun-allowed emacs based
Minsky is one of THE pioneers of the entire field of Artificial Intelligence. He founded the MIT AI Lab in 1970. He was born in 1927.
I disagree, You can easily write a C program that can write a C program...
He's referring to modifying the AST while the Lisp programming is running.
easily?
Just generating the C code in a source file is easy enough. What we're talking about here is getting it to be executed inside the same program that generated it! In C that will involve additionnal to invoke the C compiler, generate a shared library, dynamically load it, find the symbols and call the function. All that is done internally, without touching the file system or invoking external tools in lisp using EVAL (or even COMPILE).
@@informatimago And after generating all this C code and performing the acrobatics of compiling and loading the resulting code, you cannot even easily access the calling program's global variables. I really thought that C programmers would write smarter comments, but they just keep saying "you can do that in C" without really understanding the point. BTW I'm a C programmer (but one who has written a LISP interpreter).