5 ms·

Modern languages have learned a lot from Lisp. In fact they've stolen just about every major feature from it, except for s-expr syntax. Which should tell you so

Modern languages have learned a lot from Lisp. In fact they've stolen just about every major feature from it, except for s-expr syntax. Which should tell you something about s-expr syntax.

yvdriess 8y ago
Any language adopting s-expr would instantly be called a Lisp. Arguably, the s-expr syntax is what enables the rich code-as-data metaprogramming that you find in Lisps. Working with full macros in a sexpr language is already complex enough, the an extra layer of complexity that non-sexpr language add really breaks that camel in half. The point is, you really need code == AST parity to make a powerful macro system workable. You don't necessarily need the parans, but complaining about parens is really missing the point.
- pathsjs 8y ago
  As it turns out, you can have a powerful macro system without s-expr syntax (e.g. Scala, Nim). In any case, you jus need to write functions that operate over trees, which you can do in any language. That this tree is not immediately reflected in the actual syntax is just a minor hindrance
  - yvdriess 8y ago
    Writing non-trivial macros in Scala or Nim will quickly liberate you of this notion.
    - pathsjs 8y ago
      In fact, I do :-)
    - _yawn 8y ago
      What problems do you run into? I'm familiar with lisp's macro system but didn't get to look into hygienic macros in other language, and was wondering if they are equivalent.
  - KingMob 8y ago
    Personally, I find homoiconicity is key to easy construction of macros, and to do that, you need s-exprs (or something similar). Without that, it's certainly doable, but the result looks nothing like your non-macro code in that language.
dwheeler 8y ago
It tells me that the vast majority of software developers do not want to read or maintain code in raw s-expression format, for the same reason that the vast majority of software developers do not want to read or maintain code in machine code. S-expressions and machine code run, but when the argument is "you won't see the parentheses after a while" then clearly the parentheses shouldn't be there in the first place. For example, normal people find "a + b" easier to read than "(+ a b)", because they receive 12-18 years of training in infix notation AND practically all materials with math (books, papers, etc.) use infix. Lisp's current s-expression syntax is simply unacceptable to most software developers. Of course, s-expressions have a big advantage: homoiconicity. Homoiconicity enables the metaprogramming that is such a powerful and relatively unique capability of the Lisp family. But it's possible to add additional abbreviations to s-expressions to make the notation much easier to read by most software developers. Indeed, the original Lisp didn't have "quote", but no one would be happy today if you had to write (quote a) instead of 'a. (See the "LISP 1.5 Programmer's Manual" by McCarthy et al. of 1962 at http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf http://www.softwarepreservation.org/projects/LISP/book/LISP%... ... and note that it has only QUOTE.) I think adding a few more abbreviations to the s-expression reader can make a big difference in the readability (and acceptability) of Lisps. E.g., "{a + b}" as an abbreviation for "(+ a b)" retains homoiconicity, while making code significantly easier to read for most people. For more information, see: https://readable.sourceforge.io/ https://readable.sourceforge.io/
- vt100 8y ago
  Maybe it's valid to think of Python (and Javascript, and R, etc) as a DSL, where the Domain is very large, almost as large as Lisp itself, but not quite, just missing the elegant metaprogramming. A DSL for "easy-to-use coding by non-Lispers".
- yvdriess 8y ago
  I am tired of seeing this programmer's meme constantly being repeated. Superfluous parens: Do not assume that the parentheses are superfluous, they are an excellent way to write down and communicate a tree-like structures. Code happens to be such a structure. With regard to the readability, this probably reveals an initial training in an Algol-syntax language. It is really not self-evident that s-expr are harder to read, and find it hard to believe that is true. Most likely, if it is the case for you, it more likely means it is not leveraging years of brain-training on Algol/C style notation. Do not mistake this for anything intrinsic about s-expr. To grab to personal experience: I have thought both Lispy and Alogly languages to complete programming virgins and have anecdotally seen less syntax-related mistakes in the former. The benefit of pre-learned infix semantics from mathematics courses is vanishingly small compared to the complexity of learning how to program. Unless your domain is actual mathematics (R, Matlab, ...), only a very small set of expressions in any program actually leverage that familiarity. The benefit in teaching/learning S-expr syntax is that is comparably uniform: whitespace breaks with paren ends. Infix languages introduce a set of context-dependent symbols. For example, a good portion of the errors I saw first timers make in class is mixing commas versus semicolon breaks. Even Python does this in the form of complex line breaking rules mixed with symbol-breaks (semicolon expression seperators, colon in conditionals, etc). It isn't hard when you are already familiar, but you definitely notice the complexity when holding the hand of a first-timer. In short, the 'not seeing parens' is akin to not 'seeing commas, semicolons, colons, braces, parens, backspaces, ...' in Algol-syntax languages. But honestly, things that are different should look different. Leveraging familiarity is a vital tool when designing a consumer-facing interface, but avoiding faulty preconceptions and ambiguities is more important for the professional tool that is a serious programming language. I personally think in C when handling low-level memory, Lisp when doing metaprogramming, Prolog when doing logic programming and something APL-like when doing linear algebra.
geoalchimista 8y ago
"except for s-expr syntax" Julia-lang: Hold my beer. [1] [1] https://docs.julialang.org/en/latest/devdocs/ast/#Surface-syntax-AST-1 https://docs.julialang.org/en/latest/devdocs/ast/#Surface-sy...

Modern languages have learned a lot from Lisp. In fact they've stolen just about every major feature from it, except for s-expr syntax. Which should tell you something about s-expr syntax.

yvdriess 8y ago

Any language adopting s-expr would instantly be called a Lisp. Arguably, the s-expr syntax is what enables the rich code-as-data metaprogramming that you find in Lisps. Working with full macros in a sexpr language is already complex enough, the an extra layer of complexity that non-sexpr language add really breaks that camel in half. The point is, you really need code == AST parity to make a powerful macro system workable. You don't necessarily need the parans, but complaining about parens is really missing the point.

pathsjs 8y ago
As it turns out, you can have a powerful macro system without s-expr syntax (e.g. Scala, Nim). In any case, you jus need to write functions that operate over trees, which you can do in any language. That this tree is not immediately reflected in the actual syntax is just a minor hindrance
- yvdriess 8y ago
  Writing non-trivial macros in Scala or Nim will quickly liberate you of this notion.
  - pathsjs 8y ago
    In fact, I do :-)
  - _yawn 8y ago
    What problems do you run into? I'm familiar with lisp's macro system but didn't get to look into hygienic macros in other language, and was wondering if they are equivalent.
- KingMob 8y ago
  Personally, I find homoiconicity is key to easy construction of macros, and to do that, you need s-exprs (or something similar). Without that, it's certainly doable, but the result looks nothing like your non-macro code in that language.

dwheeler 8y ago

It tells me that the vast majority of software developers do not want to read or maintain code in raw s-expression format, for the same reason that the vast majority of software developers do not want to read or maintain code in machine code. S-expressions and machine code run, but when the argument is "you won't see the parentheses after a while" then clearly the parentheses shouldn't be there in the first place. For example, normal people find "a + b" easier to read than "(+ a b)", because they receive 12-18 years of training in infix notation AND practically all materials with math (books, papers, etc.) use infix. Lisp's current s-expression syntax is simply unacceptable to most software developers. Of course, s-expressions have a big advantage: homoiconicity. Homoiconicity enables the metaprogramming that is such a powerful and relatively unique capability of the Lisp family. But it's possible to add additional abbreviations to s-expressions to make the notation much easier to read by most software developers. Indeed, the original Lisp didn't have "quote", but no one would be happy today if you had to write (quote a) instead of 'a. (See the "LISP 1.5 Programmer's Manual" by McCarthy et al. of 1962 at http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf http://www.softwarepreservation.org/projects/LISP/book/LISP%... ... and note that it has only QUOTE.) I think adding a few more abbreviations to the s-expression reader can make a big difference in the readability (and acceptability) of Lisps. E.g., "{a + b}" as an abbreviation for "(+ a b)" retains homoiconicity, while making code significantly easier to read for most people. For more information, see: https://readable.sourceforge.io/ https://readable.sourceforge.io/

vt100 8y ago
Maybe it's valid to think of Python (and Javascript, and R, etc) as a DSL, where the Domain is very large, almost as large as Lisp itself, but not quite, just missing the elegant metaprogramming. A DSL for "easy-to-use coding by non-Lispers".
yvdriess 8y ago
I am tired of seeing this programmer's meme constantly being repeated. Superfluous parens: Do not assume that the parentheses are superfluous, they are an excellent way to write down and communicate a tree-like structures. Code happens to be such a structure. With regard to the readability, this probably reveals an initial training in an Algol-syntax language. It is really not self-evident that s-expr are harder to read, and find it hard to believe that is true. Most likely, if it is the case for you, it more likely means it is not leveraging years of brain-training on Algol/C style notation. Do not mistake this for anything intrinsic about s-expr. To grab to personal experience: I have thought both Lispy and Alogly languages to complete programming virgins and have anecdotally seen less syntax-related mistakes in the former. The benefit of pre-learned infix semantics from mathematics courses is vanishingly small compared to the complexity of learning how to program. Unless your domain is actual mathematics (R, Matlab, ...), only a very small set of expressions in any program actually leverage that familiarity. The benefit in teaching/learning S-expr syntax is that is comparably uniform: whitespace breaks with paren ends. Infix languages introduce a set of context-dependent symbols. For example, a good portion of the errors I saw first timers make in class is mixing commas versus semicolon breaks. Even Python does this in the form of complex line breaking rules mixed with symbol-breaks (semicolon expression seperators, colon in conditionals, etc). It isn't hard when you are already familiar, but you definitely notice the complexity when holding the hand of a first-timer. In short, the 'not seeing parens' is akin to not 'seeing commas, semicolons, colons, braces, parens, backspaces, ...' in Algol-syntax languages. But honestly, things that are different should look different. Leveraging familiarity is a vital tool when designing a consumer-facing interface, but avoiding faulty preconceptions and ambiguities is more important for the professional tool that is a serious programming language. I personally think in C when handling low-level memory, Lisp when doing metaprogramming, Prolog when doing logic programming and something APL-like when doing linear algebra.

geoalchimista 8y ago

"except for s-expr syntax" Julia-lang: Hold my beer. [1] [1] https://docs.julialang.org/en/latest/devdocs/ast/#Surface-syntax-AST-1 https://docs.julialang.org/en/latest/devdocs/ast/#Surface-sy...