5 ms·

> A more conventional notation was planned but never happened: This is evidence that S-expressions are objectively superior to other serializations. They are

by lisper 4y ago

> A more conventional notation was planned but never happened: This is evidence that S-expressions are objectively superior to other serializations. They are objectively simpler (this is why they were chosen in the first place -- writing a parser for sexprs is vastly easier than writing a parser for just about anything else), and the fact that humans who become accustomed to them early on generally prefer not to move away from them is evidence that other representations offer no advantages, and considerable disadvantages in the form of added complexity for no objective benefit. In other words, the main reason people don't like S-expressions is that they are indoctrinated from an early age (like grade school) into objectively inferior serializations, which trace their roots literally into antiquity. Lisp should be taught in elementary school. Children should be taught to think not in terms of of "two times three" and "two plus three" but rather "the sum of two and three" and "the product of two and three". It would make the world a better place in the long run.

shadowofneptune 4y ago
The more 'objectively' is used here, the less meaning it seems to have. If people have trouble using the notation, it's a subjective issue that cuts into the utility of the language. Even after getting used to it myself, I sometimes get tied up translating infix formulas to RPN or PN. There doesn't need to be one notation/language to handle everything.
- qsort 4y ago
  The point is why people have more trouble parsing (+ 2 3) than they have parsing (2 + 3). I agree with you (contra GP) that path dependency is a fine reason to prefer infix. Continuing with what we're used to is very often the preferable choice where the costs of switching are high and the benefits unclear. I actually think that infix notation has some advantages, especially for associative operations {e.g. if (G, +) is a group and a, b, c \in G, it's much more natural to write a + b + c than to choose between the equivalent (+ (+ a b) c) and (+ a (+ b c))}. But undeniably S-expressions are superior from a teaching point of view as they don't hide the "true" structure. Even though I don't dislike infix at all, it's hard to argue the reason most people prefer it isn't that they're just used to it.
  - hayley-patton 4y ago
    Then don't choose, write (+ a b c).
    - qsort 4y ago
      Yeah, but what's the difference then?
  - consilient 4y ago
    > I actually think that infix notation has some advantages, especially for associative operations {e.g. if (G, +) is a group and a, b, c \in G, it's much more natural to write a + b + c than to choose between the equivalent (+ (+ a b) c) and (+ a (+ b c))}. > But undeniably S-expressions are superior from a teaching point of view as they don't hide the "true" structure. That's exactly what they do though. A group G is not the same as a particular choice of presentation, and an element of g is not a particular tree of generators. Linear transformations aren't matrices, numbers aren't decimal expansions, polygons aren't lines on a chalkboard - and internalizing this is extremely important for beginning math students.
    - qsort 4y ago
      > That's exactly what they do though. > and internalizing this is extremely important for beginning math students. I'm not saying that you're wrong, because, well, you aren't. But does the choice of notation help here? Understanding that a matrix isn't a linear transformation but only a representation of it is something that's inherently hard and requires a certain level of mathematical maturity. At that point in a sense notation doesn't really matter any longer.
dgb23 4y ago
One of the things that make me jealous of programmers who use Lisps in their day to day, is how powerful code navigation and editing becomes. Programming is, as everyone here knows, a thinking discipline first... But when you do formulate a thought, you want the typing, navigation and editing to be as fluent, fast and expressive as possible. You want to extract and move sub expressions without friction. You want to jump around the code and “zoom” in and out of contexts. And of course evaluate every sub expression in isolation. All of this stuff is just much harder or limited without something like S-expressions.
- JonChesterfield 4y ago
  And when you want to write programs that move or translate subexpressions, it is so much easier when you aren't converting to and from a stream of bytes or tokens on the fly as well.
shaunsingh0207 4y ago
While I agree that RPN should be taught in schools, ease of parsing is not a reason to force them on everyone. Similarly, just because people get accustomed to lisp does not mean it's a good language. I say this as a lisp "enthusiast" using it for pretty much everything I can. Whatever language we teach in schools should be simple and quite natural to get the hang of, and should be somewhat "industry standard" if they choose to continue with said language. Python is a great candidate because of its reliance on indents and lack of delimeters. While "we" consider lisp's parenthesis incredibly useful, new programs find it scary. Forcing it on people does not make it any less scary. For me lisp wouldn't be enjoyable without good tooling. Parinfer, paredit, emacs, slynk, etc. make lisp enjoyable to use and edit. Python has the benefit of - you can quickly graphically install it - pip is incredibly easy to use, sometimes to its detriment. - you can edit python sanely in any text editor (even notepad). Perhaps a lesson in introductory lesson to hy in their compsci python classes would be nice though
- dgb23 4y ago
  When a Lisp is your first or one of your first languages, it’s apparently much less of a problem. Racket is probably one of the best languages to start with. Incredibly beginner friendly and complete, uniform tooling.
- distcs 4y ago
  > Python is a great candidate because of its reliance on indents and lack of delimeters. Really? Lack of delimiters? Python relies much more on delimiters than Lisp! Python has all kinds of delimiters for subscripting, comparison, slicing, destructuring, etc. Each one of this adds a lot of syntactic overhead while teaching Python to beginners. Whether indentation makes it easy or more difficult to learn Python is debatable. Indentation definitely makes it easy to read but beginners are learning to write code. > Python is a great candidate because of its reliance on indents and lack of delimeters. While "we" consider lisp's parenthesis incredibly useful, new programs find it scary. Forcing it on people does not make it any less scary. Can you point to some actual data or references instead of making one unfounded claim after another? Do beginners who have not been exposed to any programming language yet really find parentheses scary? Where can I see the data? I have first hand experience in teaching BASIC, Python and Lisp (actually, Scheme) to students as their first programming language. Believe it or not, in my experience they found BASIC the easiest to learn, then Lisp and Python was the hardest of the three. > you can edit python sanely in any text editor (even notepad). Spoken like an experienced programmer! For someone who is learning to program a computer for the first time, the indentation rules of Python happen to the very first thing that trips up the students. Did I indent the previous line with spaces? Or tabs? Or worse, with a mix of spaces and tabs? Notepad won't tell me and Python will refuse to run the program if I guess it wrong! Lisp has its own share of problems too. Like I said beginners find BASIC the easiest to learn but that does not make it the best language. But my experience teaching students is just that -- my experience! I am not going to go ahead and claim that my experience is a general trend. That is why I think it is important to have proper data for things like this. Might do a lot of good for future generation of programmers and teachers. Sharing personal anecdotes is fine as long as it is disclosed that they are anecdotes. But taking your anecdotes or even worse -- your beliefs from your own biases formed as an experienced programmer -- and claiming that they form some sort of general trend is disingenuous.
emmelaich 4y ago
Agree with all except that I'd prefer square brackets because it doesn't require using the shift key.
- hhdave 4y ago
  Having to press the shift key all the time while programming lisp was annoying. I've remapped them.
- lispm 4y ago
  That's why there were special keyboards -> see the unshifted parentheses: https://webwit.nl/input/lynk/compare1.jpg https://webwit.nl/input/lynk/compare1.jpg
amanwithnoplan 4y ago
But why (+ 1 2 3) and not +(1 2 3) since the head is special? Or (1 2 3 +) so nested trees are built bottom up?
- simongray 4y ago
  If it's +(1 2 3) then the language is no longer homoiconic and you will lose the primary leverage of being a Lisp. The fact that Lisp code consists entirely of Lisp data literals (code as data) is what enables Lisp macros and the superior REPL experience.
  - pasc1878 4y ago
    There are languages where this can be written +/ 1 2 3 e.g. APL
  - distcs 4y ago
    Can you elaborate what about +(1 2 3) makes it not homoiconic? Isn't it trivial for a hypothetical Lisp implementation to treat +(1 2 3) as the list [+, 1, 2, 3]? Not sure if I am missing something. This is an honest question.
    - lispm 4y ago
      Homoiconicity in Lisp means that it is written on top of the data syntax. Sure you can put other parsers in front, which might just convert a different notation into Lisp data. The difference is then, that the primitive datastructure itself has a different syntax. In Lisp we use the syntax of the primitive data notation (-> s-expressions) to encode both data AND code.
    - simongray 4y ago
      First of all, that place is where the reader macros go, so the spot is already taken. Second of all, notwithstanding interference with reader macros, then no, it isn't completely trivial unless what you're suggesting is just pointless string substitution, which would also make e.g. 1(2 3) be equal to (1 2 3). If what you're suggesting is having an enforced hard split between lists and function/macro invocation, that pretty much just makes everything harder to do with no perceivable gain, other than looking a bit more like C-based languages. It's a bit like enforcing that any strings that are parsed as numbers somewhere in the source code must be defined using "..." while strings that aren't must use '...' instead. The entire point is that you can manipulate code as data structures. You can rewrite the rules of the language by returning data structures. There's no reason to make this more complex.
revskill 4y ago
How to express try catch block in Lisp then ? In all programming language, composability was broken at exception handling. No, instead of teaching 2 + 2 = sum (2, 2), i will teach the GOTO statement.
- lispm 4y ago
  Common Lisp has a bunch of that stuff. For example HANDLER-CASE http://www.lispworks.com/documentation/HyperSpec/Body/m_hand_1.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_hand...
- tmtvl 4y ago
  A try-catch block? (handler-case (/ 1 0) (division-by-zero (condition) (format nil "We caught ~S." condition)) ((or file-error parse-error type-error) (condition) (format nil "We should never catch ~S" condition)) (:no-error (result) (declare (ignore result)) "We should never get here.")) That's an example of how it can be done in CL, in Scheme you've got guard. (guard (con ((warning? con) "We should never get this.") ((assertion-violation? con) "We should get this.")) (/ 1 0))
distcs 4y ago
> This is evidence that S-expressions are objectively superior to other serializations. Do you have links to the evidence? Not trying to be snarky. Genuine question. I wish to see more research and data in this space.
- zrloopw 4y ago
  McCarthy himself: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised.
JetSetWilly 4y ago
"objectively simpler" is just false. You might prefer it, but that doesn't mean it is simpler. The reason people mostly don't like it, in fact, is because they find it more complex. A simple infix expression - say (2 + 3 - 1) / (5 - 2 + 4) becomes the comparatively more complex (/ (- (+ 2 3) 1) (+ (- 5 2) 4))) - with multiple layers of nesting to parse, operators a large distance away from what they are operating on etc. There's a reason it isn't taught in primary school, and it isn't objectively superior, just a trade off some people prefer because of other benefits they think it brings.
- ASalazarMX 4y ago
  I definitely find the former much easier to visually parse than the latter. I liberally unneeded parenthesis to emphasize parts of an operation which might depend too much on operator precedence, but humans are not great at keeping track of many nested parentheses. These kinds of expressions tend to end with a cluster of parentheses, and it becomes hard to identify the beginning and end of each one, and making sure they're being closed at the right scope. Before someone comments "the editor will keep track of them for you", I want to answer that needing a tool to keep track of nested parenthesis might be a sign that such notation needs improvement.
- velcrovan 4y ago
  Not going to comment on the “objectively” part of this discussion. But having come to S-exps late in life, I would say they definitely are “simpler” over the whole problem domain of programming computers. Programming has many examples of syntax and constructs that definitely are simpler for grade school level programs, but which make your life a living hell of complexity if you rely on them for building real-world software.
  - simongray 4y ago
    I think you're describing the difference between being "simple" (objective, absolute) and being "easy" (subjective, relative). Of course, I'm paraphrasing this classic: https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
- 4y ago

by lisper 4y ago

shadowofneptune 4y ago

The more 'objectively' is used here, the less meaning it seems to have. If people have trouble using the notation, it's a subjective issue that cuts into the utility of the language. Even after getting used to it myself, I sometimes get tied up translating infix formulas to RPN or PN. There doesn't need to be one notation/language to handle everything.

qsort 4y ago
The point is why people have more trouble parsing (+ 2 3) than they have parsing (2 + 3). I agree with you (contra GP) that path dependency is a fine reason to prefer infix. Continuing with what we're used to is very often the preferable choice where the costs of switching are high and the benefits unclear. I actually think that infix notation has some advantages, especially for associative operations {e.g. if (G, +) is a group and a, b, c \in G, it's much more natural to write a + b + c than to choose between the equivalent (+ (+ a b) c) and (+ a (+ b c))}. But undeniably S-expressions are superior from a teaching point of view as they don't hide the "true" structure. Even though I don't dislike infix at all, it's hard to argue the reason most people prefer it isn't that they're just used to it.
- hayley-patton 4y ago
  Then don't choose, write (+ a b c).
  - qsort 4y ago
    Yeah, but what's the difference then?
- consilient 4y ago
  > I actually think that infix notation has some advantages, especially for associative operations {e.g. if (G, +) is a group and a, b, c \in G, it's much more natural to write a + b + c than to choose between the equivalent (+ (+ a b) c) and (+ a (+ b c))}. > But undeniably S-expressions are superior from a teaching point of view as they don't hide the "true" structure. That's exactly what they do though. A group G is not the same as a particular choice of presentation, and an element of g is not a particular tree of generators. Linear transformations aren't matrices, numbers aren't decimal expansions, polygons aren't lines on a chalkboard - and internalizing this is extremely important for beginning math students.
  - qsort 4y ago
    > That's exactly what they do though. > and internalizing this is extremely important for beginning math students. I'm not saying that you're wrong, because, well, you aren't. But does the choice of notation help here? Understanding that a matrix isn't a linear transformation but only a representation of it is something that's inherently hard and requires a certain level of mathematical maturity. At that point in a sense notation doesn't really matter any longer.

dgb23 4y ago

One of the things that make me jealous of programmers who use Lisps in their day to day, is how powerful code navigation and editing becomes. Programming is, as everyone here knows, a thinking discipline first... But when you do formulate a thought, you want the typing, navigation and editing to be as fluent, fast and expressive as possible. You want to extract and move sub expressions without friction. You want to jump around the code and “zoom” in and out of contexts. And of course evaluate every sub expression in isolation. All of this stuff is just much harder or limited without something like S-expressions.

JonChesterfield 4y ago
And when you want to write programs that move or translate subexpressions, it is so much easier when you aren't converting to and from a stream of bytes or tokens on the fly as well.

shaunsingh0207 4y ago

While I agree that RPN should be taught in schools, ease of parsing is not a reason to force them on everyone. Similarly, just because people get accustomed to lisp does not mean it's a good language. I say this as a lisp "enthusiast" using it for pretty much everything I can. Whatever language we teach in schools should be simple and quite natural to get the hang of, and should be somewhat "industry standard" if they choose to continue with said language. Python is a great candidate because of its reliance on indents and lack of delimeters. While "we" consider lisp's parenthesis incredibly useful, new programs find it scary. Forcing it on people does not make it any less scary. For me lisp wouldn't be enjoyable without good tooling. Parinfer, paredit, emacs, slynk, etc. make lisp enjoyable to use and edit. Python has the benefit of - you can quickly graphically install it - pip is incredibly easy to use, sometimes to its detriment. - you can edit python sanely in any text editor (even notepad). Perhaps a lesson in introductory lesson to hy in their compsci python classes would be nice though

dgb23 4y ago
When a Lisp is your first or one of your first languages, it’s apparently much less of a problem. Racket is probably one of the best languages to start with. Incredibly beginner friendly and complete, uniform tooling.
distcs 4y ago
> Python is a great candidate because of its reliance on indents and lack of delimeters. Really? Lack of delimiters? Python relies much more on delimiters than Lisp! Python has all kinds of delimiters for subscripting, comparison, slicing, destructuring, etc. Each one of this adds a lot of syntactic overhead while teaching Python to beginners. Whether indentation makes it easy or more difficult to learn Python is debatable. Indentation definitely makes it easy to read but beginners are learning to write code. > Python is a great candidate because of its reliance on indents and lack of delimeters. While "we" consider lisp's parenthesis incredibly useful, new programs find it scary. Forcing it on people does not make it any less scary. Can you point to some actual data or references instead of making one unfounded claim after another? Do beginners who have not been exposed to any programming language yet really find parentheses scary? Where can I see the data? I have first hand experience in teaching BASIC, Python and Lisp (actually, Scheme) to students as their first programming language. Believe it or not, in my experience they found BASIC the easiest to learn, then Lisp and Python was the hardest of the three. > you can edit python sanely in any text editor (even notepad). Spoken like an experienced programmer! For someone who is learning to program a computer for the first time, the indentation rules of Python happen to the very first thing that trips up the students. Did I indent the previous line with spaces? Or tabs? Or worse, with a mix of spaces and tabs? Notepad won't tell me and Python will refuse to run the program if I guess it wrong! Lisp has its own share of problems too. Like I said beginners find BASIC the easiest to learn but that does not make it the best language. But my experience teaching students is just that -- my experience! I am not going to go ahead and claim that my experience is a general trend. That is why I think it is important to have proper data for things like this. Might do a lot of good for future generation of programmers and teachers. Sharing personal anecdotes is fine as long as it is disclosed that they are anecdotes. But taking your anecdotes or even worse -- your beliefs from your own biases formed as an experienced programmer -- and claiming that they form some sort of general trend is disingenuous.

emmelaich 4y ago

Agree with all except that I'd prefer square brackets because it doesn't require using the shift key.

hhdave 4y ago
Having to press the shift key all the time while programming lisp was annoying. I've remapped them.
lispm 4y ago
That's why there were special keyboards -> see the unshifted parentheses: https://webwit.nl/input/lynk/compare1.jpg https://webwit.nl/input/lynk/compare1.jpg

amanwithnoplan 4y ago

But why (+ 1 2 3) and not +(1 2 3) since the head is special? Or (1 2 3 +) so nested trees are built bottom up?

simongray 4y ago
If it's +(1 2 3) then the language is no longer homoiconic and you will lose the primary leverage of being a Lisp. The fact that Lisp code consists entirely of Lisp data literals (code as data) is what enables Lisp macros and the superior REPL experience.
- pasc1878 4y ago
  There are languages where this can be written +/ 1 2 3 e.g. APL
- distcs 4y ago
  Can you elaborate what about +(1 2 3) makes it not homoiconic? Isn't it trivial for a hypothetical Lisp implementation to treat +(1 2 3) as the list [+, 1, 2, 3]? Not sure if I am missing something. This is an honest question.
  - lispm 4y ago
    Homoiconicity in Lisp means that it is written on top of the data syntax. Sure you can put other parsers in front, which might just convert a different notation into Lisp data. The difference is then, that the primitive datastructure itself has a different syntax. In Lisp we use the syntax of the primitive data notation (-> s-expressions) to encode both data AND code.
  - simongray 4y ago
    First of all, that place is where the reader macros go, so the spot is already taken. Second of all, notwithstanding interference with reader macros, then no, it isn't completely trivial unless what you're suggesting is just pointless string substitution, which would also make e.g. 1(2 3) be equal to (1 2 3). If what you're suggesting is having an enforced hard split between lists and function/macro invocation, that pretty much just makes everything harder to do with no perceivable gain, other than looking a bit more like C-based languages. It's a bit like enforcing that any strings that are parsed as numbers somewhere in the source code must be defined using "..." while strings that aren't must use '...' instead. The entire point is that you can manipulate code as data structures. You can rewrite the rules of the language by returning data structures. There's no reason to make this more complex.

revskill 4y ago

How to express try catch block in Lisp then ? In all programming language, composability was broken at exception handling. No, instead of teaching 2 + 2 = sum (2, 2), i will teach the GOTO statement.

lispm 4y ago
Common Lisp has a bunch of that stuff. For example HANDLER-CASE http://www.lispworks.com/documentation/HyperSpec/Body/m_hand_1.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_hand...
tmtvl 4y ago
A try-catch block? (handler-case (/ 1 0) (division-by-zero (condition) (format nil "We caught ~S." condition)) ((or file-error parse-error type-error) (condition) (format nil "We should never catch ~S" condition)) (:no-error (result) (declare (ignore result)) "We should never get here.")) That's an example of how it can be done in CL, in Scheme you've got guard. (guard (con ((warning? con) "We should never get this.") ((assertion-violation? con) "We should get this.")) (/ 1 0))

distcs 4y ago

> This is evidence that S-expressions are objectively superior to other serializations. Do you have links to the evidence? Not trying to be snarky. Genuine question. I wish to see more research and data in this space.

zrloopw 4y ago
McCarthy himself: https://en.wikipedia.org/wiki/M-expression https://en.wikipedia.org/wiki/M-expression The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised.

JetSetWilly 4y ago

"objectively simpler" is just false. You might prefer it, but that doesn't mean it is simpler. The reason people mostly don't like it, in fact, is because they find it more complex. A simple infix expression - say (2 + 3 - 1) / (5 - 2 + 4) becomes the comparatively more complex (/ (- (+ 2 3) 1) (+ (- 5 2) 4))) - with multiple layers of nesting to parse, operators a large distance away from what they are operating on etc. There's a reason it isn't taught in primary school, and it isn't objectively superior, just a trade off some people prefer because of other benefits they think it brings.

ASalazarMX 4y ago
I definitely find the former much easier to visually parse than the latter. I liberally unneeded parenthesis to emphasize parts of an operation which might depend too much on operator precedence, but humans are not great at keeping track of many nested parentheses. These kinds of expressions tend to end with a cluster of parentheses, and it becomes hard to identify the beginning and end of each one, and making sure they're being closed at the right scope. Before someone comments "the editor will keep track of them for you", I want to answer that needing a tool to keep track of nested parenthesis might be a sign that such notation needs improvement.
velcrovan 4y ago
Not going to comment on the “objectively” part of this discussion. But having come to S-exps late in life, I would say they definitely are “simpler” over the whole problem domain of programming computers. Programming has many examples of syntax and constructs that definitely are simpler for grade school level programs, but which make your life a living hell of complexity if you rely on them for building real-world software.
- simongray 4y ago
  I think you're describing the difference between being "simple" (objective, absolute) and being "easy" (subjective, relative). Of course, I'm paraphrasing this classic: https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
4y ago