Hacker News Reader

Comment by spenrose | Hacker News Reader

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.)

View on HN

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.

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.

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.

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.)

> 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.

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.

Ruby is more of a Smalltalk than a Lisp.

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.)

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.

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.

...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.

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.

I think perhaps you're suggesting a false dichotomy there. Almost any useful general-purpose programming language is going to have both some degree of extensibility and some degree of support from built-in language features. The different flavours are a question of priorities, because the more specialised tools you provide via dedicated language features, the harder it is to keep the core of your language generic. The really successful languages tend to have a set of specialised features powerful enough to give a significant advantage over languages without them, but well enough matched and with clean enough semantics that the overhead for extensibility in other directions isn't prohibitively increased.

> ... 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.

Lisps allow you to extend both the parser (reader macros) and do transformations on the syntax tree (macros) before it gets compiled/interpreted. In most of the other languages parsing and code generation are very tightly coupled with no easily accessible step in between.

What is important in the read-eval-print loop is the dashes :)

Reply on news.ycombinator.com