4 ms·

Similarly, Lisp has lost. It's clear to me that S-expr are not popular. Other languages and environments have captured much of what Lisp has offered forever,

Similarly, Lisp has lost. It's clear to me that S-expr are not popular. Other languages and environments have captured much of what Lisp has offered forever, but not S-expr, and, less so, not macros. Any argument one has against Lisp is answered by modern implementations. But, specifically, by Clojure. Modern, fast, "works with everything", "lots of libraries", the JVM "lifts all boats", including Clojure. But despite all that, it's still S-expr based, and its still a niche "geek" language. A popular one, for its space, but niche. It's not mainstream. Folks have been pivoting away from S-expr all the way back to Dylan. I'm a Lisp guy, I like Lisp, and by Lisp I mean Common Lisp. But I like CLOS more than macros, specifically mulithmethod dispatch. I'd rather have CLOS in a language than macros. I don't hate S-expr, but I think their value diminishes rather quickly if you don't have macros. Most languages have structured static data now, which is another plus of S-expr. I don't use many macros in my Lisp code. Mostly convenience methods (like (with-<some-scope> scope <body>)), things like that). Real obvious boiler plate stuff. Everyone else would just wrap a lambda, but that's not so much the Common Lisp way. In my Not Lisp work, I don't really miss macros. Anyway, S-expr hinder adoption. It's had all the time in the world to "break through", and it hasn't. "Wisdom of the crowds" says nay.

PaulHoule 2y ago
What did win is the scalar/list/dict trinity which I first saw clearly articulated in Perl but is core to dynamic langauges like Python and Javascript and in the stdlib and used heavily in almost every static language except for the one that puts the C in Cthulu.
- dudinax 2y ago
  And a lot of lisps have clunky dicts.
kazinator 2y ago
This is kind of backwards. Languages which imitate everything from the Lisp family except S-exprs and macros are, because of that, other languages. Those that have S-exprs and macros are identified as in the Lisp family. The appearance of new languages like this has not stopped.
- cageface 2y ago
  This is kind of a no true Scotsman argument. The point is that most of the key ideas of lisp have been enthusiastically adopted by many very popular languages but lisp itself remains a small niche.
  - kazinator 2y ago
    A language that enthusiastically adopts all key ideas is identified as a Lisp. There aren't "many" popular languages; only a fairly small number. The vast majority of languages are destined for unpopularity, regardless of what they copy from where.
  - _19qg 2y ago
    You'll need to say what this "lisp" and the "lisp features" are. When we go back to the original idea of LISP, we have the following things: idea -> what follows from those 1) programming with Symbolic Expressions -> support the implementation/implementation of languages 2) "programming with Symbolic Expressions" applied to itself -> Lisp in itself, code as data, macros, self-hosting compiler, Lisp interpreter 3) linked lists and symbols as data structures for Symbolic Expressions 4) a programming system to build algorithms and programs based on the ideas of above -> symbols repository, late binding, recursive functions, symbols with properties, garbage collection, Lisp interpreter using s-expressions, Lisp compiler, reader, printer, read-eval-print-loop, a resident development environment, managed memory, saving/loading heap dumps, dynamic data structures,... LISP means "List Processor" (not "List Processing"). Which indicates that this is at its core, not a library or an add on. There aren't that many other languages which are based on these ideas. We can define three levels of "feature adoption": * enables a feature (the language provides mechanisms to provide a feature) * supports a feature (the language actually includes those features, but use is optional) * requires a feature (the language requires the use of that feature, its not optional for the developer) If we use a programming system, which requires the four core ideas above (and many of the features that follow from those) and is based on them, it is still very (!) different to what most people use. Example: Smalltalk development was started more than a decade after LISP. It adopted a huge amount of features from Lisp: managed memory, resident development environment, garbage collection, late binding, interactive use, runtime evaluation, dumping&loading heaps, etc. etc. For a decade Xerox PARC developed a Smalltalk system and a Lisp system side-by side: Smalltalk 80 systems and Interlisp-D systems were the results. Still: Smalltalk 80 did not use the first three core ideas from above and replaced them with another core idea: objects+classes communicating via message passing. Thus mass feature adoption alone does not make Smalltalk fundamentally to be a LISP. Nor does feature adoption make a language popular. So we can ask use, will those core ideas of Lisp make it very popular? Seems like it did not. Still many of the useful features which were following from it could be replicated/adopted/morphed into other languages. The original article was probably taking a view that a language&programming system which enables domain specific embedded languages would be "better" than the diverse stack of tools and languages in the automotive domain. Lisp is such a tool for embedded languages (embedded into a hosting language, not in the sense of languages for embedded systems), but that does not make it the best for that domain, which has a lot more requirements than language embedding (like reliability, robustness, etc. ...). In Germany A-SPICE gives a lot of hints what a development process needs to do, to deliver reliable software for the automotive domain. I don't think Lisp would fit well into such a development process.
Straw 2y ago
You can implement CLOS with macros, but not the other way round!
cylinder714 2y ago
As an aside, Ron Rivest and Donald Eastlake last updated "SPKI S-Expressions" just a couple of months ago: https://datatracker.ietf.org/doc/draft-rivest-sexp/ https://datatracker.ietf.org/doc/draft-rivest-sexp/
bunderbunder 2y ago
I think you're absolutely right about macros being the main thing that makes s-expressions valuable, but allow me to inject my own opinion to drive it all the way home: It's not that the homoiconicity of S-expressions makes it easier to write macros. Plenty of infix expression languages have macros that let you manipulate ASTs. We're programmers; mapping from lexical syntax to an AST is not hard for us. What makes s-expressions so great in macro-heavy code is that the simplicity and regularity of the syntax lets you create DSLs without having to fuss with defining your own syntax extensions or figuring out how to integrate it into the "parent" language in a way that isn't completely terrible. Racket demonstrates this rather nicely. They've got a fantastic system for creating macros that let you define your own syntax. It really does work well. But I'd generally rather not use it if I don't have to, because if I do then the job instantly gets 10x bigger because now I have to write a parser plus all the extensions to make sure it won't break syntax highlighting, ensure parse errors are indicated nicely in the editor, etc. And also all that work will be tightly coupled to DrRacket; people who prefer a different editor will not get a good editing experience if they use my macro. I can avoid all of that headache if I just let it be s-expressions from top to bottom.

PaulHoule 2y ago

What did win is the scalar/list/dict trinity which I first saw clearly articulated in Perl but is core to dynamic langauges like Python and Javascript and in the stdlib and used heavily in almost every static language except for the one that puts the C in Cthulu.

dudinax 2y ago
And a lot of lisps have clunky dicts.

kazinator 2y ago

This is kind of backwards. Languages which imitate everything from the Lisp family except S-exprs and macros are, because of that, other languages. Those that have S-exprs and macros are identified as in the Lisp family. The appearance of new languages like this has not stopped.

cageface 2y ago
This is kind of a no true Scotsman argument. The point is that most of the key ideas of lisp have been enthusiastically adopted by many very popular languages but lisp itself remains a small niche.
- kazinator 2y ago
  A language that enthusiastically adopts all key ideas is identified as a Lisp. There aren't "many" popular languages; only a fairly small number. The vast majority of languages are destined for unpopularity, regardless of what they copy from where.
- _19qg 2y ago
  You'll need to say what this "lisp" and the "lisp features" are. When we go back to the original idea of LISP, we have the following things: idea -> what follows from those 1) programming with Symbolic Expressions -> support the implementation/implementation of languages 2) "programming with Symbolic Expressions" applied to itself -> Lisp in itself, code as data, macros, self-hosting compiler, Lisp interpreter 3) linked lists and symbols as data structures for Symbolic Expressions 4) a programming system to build algorithms and programs based on the ideas of above -> symbols repository, late binding, recursive functions, symbols with properties, garbage collection, Lisp interpreter using s-expressions, Lisp compiler, reader, printer, read-eval-print-loop, a resident development environment, managed memory, saving/loading heap dumps, dynamic data structures,... LISP means "List Processor" (not "List Processing"). Which indicates that this is at its core, not a library or an add on. There aren't that many other languages which are based on these ideas. We can define three levels of "feature adoption": * enables a feature (the language provides mechanisms to provide a feature) * supports a feature (the language actually includes those features, but use is optional) * requires a feature (the language requires the use of that feature, its not optional for the developer) If we use a programming system, which requires the four core ideas above (and many of the features that follow from those) and is based on them, it is still very (!) different to what most people use. Example: Smalltalk development was started more than a decade after LISP. It adopted a huge amount of features from Lisp: managed memory, resident development environment, garbage collection, late binding, interactive use, runtime evaluation, dumping&loading heaps, etc. etc. For a decade Xerox PARC developed a Smalltalk system and a Lisp system side-by side: Smalltalk 80 systems and Interlisp-D systems were the results. Still: Smalltalk 80 did not use the first three core ideas from above and replaced them with another core idea: objects+classes communicating via message passing. Thus mass feature adoption alone does not make Smalltalk fundamentally to be a LISP. Nor does feature adoption make a language popular. So we can ask use, will those core ideas of Lisp make it very popular? Seems like it did not. Still many of the useful features which were following from it could be replicated/adopted/morphed into other languages. The original article was probably taking a view that a language&programming system which enables domain specific embedded languages would be "better" than the diverse stack of tools and languages in the automotive domain. Lisp is such a tool for embedded languages (embedded into a hosting language, not in the sense of languages for embedded systems), but that does not make it the best for that domain, which has a lot more requirements than language embedding (like reliability, robustness, etc. ...). In Germany A-SPICE gives a lot of hints what a development process needs to do, to deliver reliable software for the automotive domain. I don't think Lisp would fit well into such a development process.

Straw 2y ago

You can implement CLOS with macros, but not the other way round!

cylinder714 2y ago

As an aside, Ron Rivest and Donald Eastlake last updated "SPKI S-Expressions" just a couple of months ago: https://datatracker.ietf.org/doc/draft-rivest-sexp/ https://datatracker.ietf.org/doc/draft-rivest-sexp/

bunderbunder 2y ago

I think you're absolutely right about macros being the main thing that makes s-expressions valuable, but allow me to inject my own opinion to drive it all the way home: It's not that the homoiconicity of S-expressions makes it easier to write macros. Plenty of infix expression languages have macros that let you manipulate ASTs. We're programmers; mapping from lexical syntax to an AST is not hard for us. What makes s-expressions so great in macro-heavy code is that the simplicity and regularity of the syntax lets you create DSLs without having to fuss with defining your own syntax extensions or figuring out how to integrate it into the "parent" language in a way that isn't completely terrible. Racket demonstrates this rather nicely. They've got a fantastic system for creating macros that let you define your own syntax. It really does work well. But I'd generally rather not use it if I don't have to, because if I do then the job instantly gets 10x bigger because now I have to write a parser plus all the extensions to make sure it won't break syntax highlighting, ensure parse errors are indicated nicely in the editor, etc. And also all that work will be tightly coupled to DrRacket; people who prefer a different editor will not get a good editing experience if they use my macro. I can avoid all of that headache if I just let it be s-expressions from top to bottom.