If we’re going to revive this, maybe I should start a pointless and interminable dispute. Like, “Lisp isn’t a functional language” or “C++/Java/C# isn’t object-oriented” or similar.
(Both of those have been seriously defended, BTW, and by people of importance.)
We can turn this around, ask whether Dylan is a Lisp, or whether Python is a Lisp. Hell, by some measures, Lisp won the Programming Wars when nobody was looking, and now it’s just Java and C++ and Rust picking up the scraps far away from where the action is.
Whether X is a lisp or not is helpful only with context: Are you saying that it can trace its lineage directly to LISP? Are you saying it’s got cons? (Dylan calls it pair!). Is it’s source code made up of atoms and lists? Does it have macros? Eval and lambda? What exactly is someone trying to say when they say this?
Kent Pitman helped define Common Lisp and he says he agrees with Erik Naggum: “X is a lisp” is worthless. It says nothing about the communities, the underlying representation, the source code lineage, the kinds of functions and capabilities you’ll find, and so on. You still might say it to be polite, or with sufficient context (X is lispy in that it Y), but that’s about it.
This sounds as if JavaScript was designed after Scheme. To me it seems, that JavaScript kind of “happened”, more by chance and under time pressure. So the inspiration was really more the certainty that a dynamically typed scripting language could work. It was not a concious design decision to take features A, B, C from Scheme, but omit feature D.
Peter Norvig does say that “Python can be seen as a dialect of Lisp with ‘traditional’ syntax”, although it’s not clear he means that as a particularly strong statement vs an offhand comment about some resemblances. His introduction to Python for Lisp programmers is interesting though.
When he finished Peter [Norvig] took questions and to my surprise called first on the rumpled old guy who had wandered in just before the talk began and eased himself into a chair just across the aisle from me and a few rows up.
This guy had wild white hair and a scraggly white beard and looked hopelessly lost as if he had gotten separated from the tour group and wandered in mostly to rest his feet and just a little to see what we were all up to. My first thought was that he would be terribly disappointed by our bizarre topic and my second thought was that he would be about the right age, Stanford is just down the road, I think he is still at Stanford – could it be?
“Yes, John?” Peter said.
I won’t pretend to remember Lisp inventor John McCarthy’s exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.
“No, John, it can’t,” said Peter and nothing more, graciously assenting to the professor’s critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.
Whenever Norvig is quoted that way, there are people quickly pointing out how Python cannot be a Lisp, because of X, Y and Z. Nevertheless, Norvig’s argument is not ticking off a list of necessary features of a language being a Lisp. Rather, it’s about how a typical program looks like. And a typical lisp program is suprisingly imperative, especially if seen through the eyes of someone who is interested in functional programming in 2017. There are loops, occasional recursion, classes and instances, getters and setters, hash-tables and lists.
Macros were probably as popular in the Common Lisp community as writing “decorators” and metaclasses in Python today, it’s something you do rather rarely. I wanted to dig up some reference for this claim, because when I first heard it, I was kind of surprised (being constantly told how great macros in lisp are), so the C2 Wiki has an entry about this: http://wiki.c2.com/?LispMacro
I would put it more strongly. Always use functions, period. In the Lisp community, typically it is not the case that application programmers use macros. It is usually avoided and discouraged. But sometimes you really, really need one, and you then seek out the macro programmer in the group and ask them to provide one that is then available to everyone.
It is the year 2017 and Lisp is almost irrelevant as a platform to write new software in. In a way, it is a fantasy land that we all can project our long-held wishes into. The past we see in our nostalgic dreams, probably never existed in the way we think.
And a typical lisp program is suprisingly imperative, especially if seen through the eyes of someone who is interested in functional programming in 2017.
It’s not so surprising. Pick two general-purpose languages: a dynamically typed imperative one and a statically typed functional one. You will find that (Common) Lisp is closer in spirit to the former than to the latter. Lisp and Lisp programmers consistently prefer introspection over abstraction, expressivity over guarantees, and flexibility over sharp distinctions, exactly like other dynamically typed imperative languages and their users.
Norvig does admit that in the above article, yeah; see point 11 under “Gotchas for Lisp Programmers in Python”. Lisp has historically had a pretty wide range of programming styles, though, and Python suits some of them in a way that, say, previous competitors like Fortran or Java were completely unsuited for, while it remains unsuitable for other styles.
If we’re going to revive this, maybe I should start a pointless and interminable dispute. Like, “Lisp isn’t a functional language” or “C++/Java/C# isn’t object-oriented” or similar.
(Both of those have been seriously defended, BTW, and by people of importance.)
We can turn this around, ask whether Dylan is a Lisp, or whether Python is a Lisp. Hell, by some measures, Lisp won the Programming Wars when nobody was looking, and now it’s just Java and C++ and Rust picking up the scraps far away from where the action is.
Go for it. More fuel for the fire.
Whether X is a lisp or not is helpful only with context: Are you saying that it can trace its lineage directly to LISP? Are you saying it’s got cons? (Dylan calls it pair!). Is it’s source code made up of atoms and lists? Does it have macros? Eval and lambda? What exactly is someone trying to say when they say this?
Kent Pitman helped define Common Lisp and he says he agrees with Erik Naggum: “X is a lisp” is worthless. It says nothing about the communities, the underlying representation, the source code lineage, the kinds of functions and capabilities you’ll find, and so on. You still might say it to be polite, or with sufficient context (X is lispy in that it Y), but that’s about it.
if you consider that JavaScript was inspired & based of Scheme, then Scheme won by a landslide.
If this is victory, then some horrible prices must have been paid along the way…
Scheme’s biggest innovations w.r.t. Lisp were:
JavaScript has neither.
This sounds as if JavaScript was designed after Scheme. To me it seems, that JavaScript kind of “happened”, more by chance and under time pressure. So the inspiration was really more the certainty that a dynamically typed scripting language could work. It was not a concious design decision to take features A, B, C from Scheme, but omit feature D.
Peter Norvig does say that “Python can be seen as a dialect of Lisp with ‘traditional’ syntax”, although it’s not clear he means that as a particularly strong statement vs an offhand comment about some resemblances. His introduction to Python for Lisp programmers is interesting though.
When he finished Peter [Norvig] took questions and to my surprise called first on the rumpled old guy who had wandered in just before the talk began and eased himself into a chair just across the aisle from me and a few rows up.
This guy had wild white hair and a scraggly white beard and looked hopelessly lost as if he had gotten separated from the tour group and wandered in mostly to rest his feet and just a little to see what we were all up to. My first thought was that he would be terribly disappointed by our bizarre topic and my second thought was that he would be about the right age, Stanford is just down the road, I think he is still at Stanford – could it be?
“Yes, John?” Peter said.
I won’t pretend to remember Lisp inventor John McCarthy’s exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.
“No, John, it can’t,” said Peter and nothing more, graciously assenting to the professor’s critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.
source
Whenever Norvig is quoted that way, there are people quickly pointing out how Python cannot be a Lisp, because of X, Y and Z. Nevertheless, Norvig’s argument is not ticking off a list of necessary features of a language being a Lisp. Rather, it’s about how a typical program looks like. And a typical lisp program is suprisingly imperative, especially if seen through the eyes of someone who is interested in functional programming in 2017. There are loops, occasional recursion, classes and instances, getters and setters, hash-tables and lists.
Macros were probably as popular in the Common Lisp community as writing “decorators” and metaclasses in Python today, it’s something you do rather rarely. I wanted to dig up some reference for this claim, because when I first heard it, I was kind of surprised (being constantly told how great macros in lisp are), so the C2 Wiki has an entry about this: http://wiki.c2.com/?LispMacro
It is the year 2017 and Lisp is almost irrelevant as a platform to write new software in. In a way, it is a fantasy land that we all can project our long-held wishes into. The past we see in our nostalgic dreams, probably never existed in the way we think.
It’s not so surprising. Pick two general-purpose languages: a dynamically typed imperative one and a statically typed functional one. You will find that (Common) Lisp is closer in spirit to the former than to the latter. Lisp and Lisp programmers consistently prefer introspection over abstraction, expressivity over guarantees, and flexibility over sharp distinctions, exactly like other dynamically typed imperative languages and their users.
EDIT: Phrasing.
Norvig does admit that in the above article, yeah; see point 11 under “Gotchas for Lisp Programmers in Python”. Lisp has historically had a pretty wide range of programming styles, though, and Python suits some of them in a way that, say, previous competitors like Fortran or Java were completely unsuited for, while it remains unsuitable for other styles.
[Comment removed by author]