8 ms·

McCarthy's Lisp:zygote::Python-or-Ruby:adult human. You could say that both Python and Ruby are instances of Lisp's fragmentation, rather than unfragmented alt

McCarthy's Lisp:zygote::Python-or-Ruby:adult human. You could say that both Python and Ruby are instances of Lisp's fragmentation, rather than unfragmented alternatives. (I am not a Lisp programmer, BTW.)

rpearl 14y ago
Python and Ruby are both very fundamentally Not Lisp: Lisp's intentional s-expression syntax is very much a part of what makes Lisp powerful (it lets you write macros very easily, since code and data have the same representation). Python and Ruby both don't have that. They are alternatives to Lisp, and in the same family of dynamically typed programming languages, but they are not "instances of Lisp's fragmentation" in any way: nobody took a Lisp-like language and from that created Python.
- mtts 14y ago
  Lisp's s-expression syntax was very much not intentional: IIRC McCarthy specifically wrote that he left implementation of the syntax as an excercise for the reader. As it turned out, very few readers chose to devise a syntax and instead worked on s-expressions directly.
  - rpearl 14y ago
    I am dubious of this assertion. The original 1960 paper "Recursive Functions of Symbolic Expressions and Their Computation by Machine" introduces S-expressions and M-expressions as explicit entities (not as some abstract syntax, but as a literal syntax that people were able to write down). Now, M-expressions never really got used because everyone just used S-expressions, since they were simpler. Do you have some citation about how he left implementation of syntax as an exercise? I'd be interested to see that.
    - chc 14y ago
      I think he's kind of close, at least in that it was not meant to be written as S-expressions. AFAIK, the M-expressions were meant to be the main syntax. The very early Lisp docs I've seen were all written in M-expressions, with S-expressions taking the lead something like a decade later. (This was all decades before my time, so it's possible this is sampling bias, but I don't think so.)
- jhuni 14y ago
  > Python and Ruby both don't have that. Python and Ruby have first class functions, garbage collection, dynamic typing, and many other advanced dynamic features, so there is definitely a similarity between them and Lisp. However, the fact that they don't have code as a first class object is definitely a major limitation. In Lisp essentially everything is first class and manipulable at run time.
  - rpearl 14y ago
    Sure, they are similar. It would be very strange, however, to argue that they are fragmentations of Lisp in the sense that Ocaml and SML are fragmentation of ML. They may share ideas since they are in the same semantic family (dynamically typed) but that's about the extent of it.
mtts 14y ago
Interesting take. I'm not a Lisp programmer either, just know enough about it to be dangerous, but it seems to me all programming languages, including Lisp implementations like CL and Scheme, are mere instantiations of Lisp, with (byte) compilers merely parsing down into a syntax tree that a Lisp-like engine can then execute. ML I know nothing about, BTW.
- Silhouette 14y ago
  ...it seems to me all programming languages, including Lisp implementations like CL and Scheme, are mere instantiations of Lisp... There's an element of truth in that, but only in the same sense that all Turing complete programming languages are equivalent or that many programming languages are ultimately instantiations of a register machine, a memory store, and a program counter. The interesting thing in most cases is what you build on top of that foundation. With Lisps, the value is in the uniformity. That makes it very easy to extend the basic functionality you get out of the box in a way that fits in, using macros and so on. With various other languages, the value is in the pre-built tools that rest on top of some underlying abstract syntax tree. That covers a vast range of functionality these days: more expressive type systems, a wider range of built-in data structures, actor-based concurrency, low-level memory and port access, and numerous other practically useful language features. Hopefully any given language offers a combination of features that work well together and have natural supporting syntax and semantics. That in turn gives each language its own flavour and means each language works better for some types of software than others, even if ultimately it's usually just syntactic sugar for a relatively simple execution model and an AST.
  - spenrose 14y ago
    Two things: both mtts and Silhouette are expanding on what I meant (rather than what I wrote): McCarthy's Lisp:{Python,Ruby}::zygote:adult human mtts as quoted by Silhouette gets it right IMO. Conversely, S's distinction between extending a language and using the tools (the distinction, to oversimplify, that makes you a Lisp programmer) that sit on top of its core seems to me a confusion of means with ends. Any useful program is a fall from the perfection of JM's insight. This perspective makes me a not-Lisp-programmer. Thousands of developers smarter and more experienced than I have taken each side of this dispute without resolving it; I certainly don't hope to.
Zaak 14y ago
Ruby is more of a Smalltalk than a Lisp.
- stcredzero 14y ago
  It's like the eccentric love child of Smalltalk and Perl. (I mean that in a good way, having been paid for work in both.)
freyrs3 14y ago
Python and Ruby are very different from Lisp. Other than the fact that they share certain ideas that originated in the Lisp community ( GC for example ) the languages couldn't be farther apart. Programming in say, Ruby, is a vastly different experience than Lisp.
deleted 14y ago
[deleted]

rpearl 14y ago

Python and Ruby are both very fundamentally Not Lisp: Lisp's intentional s-expression syntax is very much a part of what makes Lisp powerful (it lets you write macros very easily, since code and data have the same representation). Python and Ruby both don't have that. They are alternatives to Lisp, and in the same family of dynamically typed programming languages, but they are not "instances of Lisp's fragmentation" in any way: nobody took a Lisp-like language and from that created Python.

mtts 14y ago
Lisp's s-expression syntax was very much not intentional: IIRC McCarthy specifically wrote that he left implementation of the syntax as an excercise for the reader. As it turned out, very few readers chose to devise a syntax and instead worked on s-expressions directly.
- rpearl 14y ago
  I am dubious of this assertion. The original 1960 paper "Recursive Functions of Symbolic Expressions and Their Computation by Machine" introduces S-expressions and M-expressions as explicit entities (not as some abstract syntax, but as a literal syntax that people were able to write down). Now, M-expressions never really got used because everyone just used S-expressions, since they were simpler. Do you have some citation about how he left implementation of syntax as an exercise? I'd be interested to see that.
  - chc 14y ago
    I think he's kind of close, at least in that it was not meant to be written as S-expressions. AFAIK, the M-expressions were meant to be the main syntax. The very early Lisp docs I've seen were all written in M-expressions, with S-expressions taking the lead something like a decade later. (This was all decades before my time, so it's possible this is sampling bias, but I don't think so.)
jhuni 14y ago
> Python and Ruby both don't have that. Python and Ruby have first class functions, garbage collection, dynamic typing, and many other advanced dynamic features, so there is definitely a similarity between them and Lisp. However, the fact that they don't have code as a first class object is definitely a major limitation. In Lisp essentially everything is first class and manipulable at run time.
- rpearl 14y ago
  Sure, they are similar. It would be very strange, however, to argue that they are fragmentations of Lisp in the sense that Ocaml and SML are fragmentation of ML. They may share ideas since they are in the same semantic family (dynamically typed) but that's about the extent of it.

mtts 14y ago

Interesting take. I'm not a Lisp programmer either, just know enough about it to be dangerous, but it seems to me all programming languages, including Lisp implementations like CL and Scheme, are mere instantiations of Lisp, with (byte) compilers merely parsing down into a syntax tree that a Lisp-like engine can then execute. ML I know nothing about, BTW.

Silhouette 14y ago
...it seems to me all programming languages, including Lisp implementations like CL and Scheme, are mere instantiations of Lisp... There's an element of truth in that, but only in the same sense that all Turing complete programming languages are equivalent or that many programming languages are ultimately instantiations of a register machine, a memory store, and a program counter. The interesting thing in most cases is what you build on top of that foundation. With Lisps, the value is in the uniformity. That makes it very easy to extend the basic functionality you get out of the box in a way that fits in, using macros and so on. With various other languages, the value is in the pre-built tools that rest on top of some underlying abstract syntax tree. That covers a vast range of functionality these days: more expressive type systems, a wider range of built-in data structures, actor-based concurrency, low-level memory and port access, and numerous other practically useful language features. Hopefully any given language offers a combination of features that work well together and have natural supporting syntax and semantics. That in turn gives each language its own flavour and means each language works better for some types of software than others, even if ultimately it's usually just syntactic sugar for a relatively simple execution model and an AST.
- spenrose 14y ago
  Two things: both mtts and Silhouette are expanding on what I meant (rather than what I wrote): McCarthy's Lisp:{Python,Ruby}::zygote:adult human mtts as quoted by Silhouette gets it right IMO. Conversely, S's distinction between extending a language and using the tools (the distinction, to oversimplify, that makes you a Lisp programmer) that sit on top of its core seems to me a confusion of means with ends. Any useful program is a fall from the perfection of JM's insight. This perspective makes me a not-Lisp-programmer. Thousands of developers smarter and more experienced than I have taken each side of this dispute without resolving it; I certainly don't hope to.

Zaak 14y ago

Ruby is more of a Smalltalk than a Lisp.

stcredzero 14y ago
It's like the eccentric love child of Smalltalk and Perl. (I mean that in a good way, having been paid for work in both.)

freyrs3 14y ago

Python and Ruby are very different from Lisp. Other than the fact that they share certain ideas that originated in the Lisp community ( GC for example ) the languages couldn't be farther apart. Programming in say, Ruby, is a vastly different experience than Lisp.

deleted 14y ago

[deleted]