6 ms·

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 impl

by 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.
  - Silhouette 14y ago
    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.
praptak 14y ago
> ... 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 :)

by mtts 14y ago

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.
- Silhouette 14y ago
  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.

praptak 14y ago

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