3 ms·

Never blame the user for the problems of the system. Lisp fans know the syntax is a huge problem. It has been for decades. Their solution is to blame the user.

by boxed 6y ago

Never blame the user for the problems of the system. Lisp fans know the syntax is a huge problem. It has been for decades. Their solution is to blame the user. This approach is absolutely doomed. Clojure actually fixes quite a few of the syntax problems with previous lips, but doesn't go nearly far enough so they still have the same problem.

p_l 6y ago
What happened is that "better syntax" turned out to universally fail in practice. It's not that we decided to blame the user. But there's 60 years of empirical data that points to M-expressions being irrelevant and waste of time. And people who don't have experience with other languages tend to pick it up just fine, even if the formatting is sometimes atrocious (AutoLISP community is an example).
- mumblemumble 6y ago
  M-expressions did fail. Their greatest failure is that they persist as a universal strawman that's useful for killing any conversation about evolving lisp's syntax. M-expressions didn't just fail because they were unnecessary; they also failed because they just weren't a very good syntax. They were more cluttered and less readable than S-expressions, while adding no real practical value. But Clojure has arguably demonstrated that you can evolve on Lisp syntax without going to M-expressions, or even changing S-expressions all that much, just by adding a few new bits of literal syntax and sprinkling some clever macros into the standard library. (A macro invocation may not technically be syntax from the parser's perspective, but it sure feels like syntactic sugar from a user experience perspective.) And, while I haven't actually tried them at all, I've at least been intrigued by t-expressions. They seem to achieve some nice things like git-friendliness and easier visual scannability without sacrificing on macro-ability.
  - p_l 6y ago
    M-expressions happen to be catch-all name for various non-Sexp syntax forms. As for Clojure, TBQH I'm not too convinced that few sigils make all that difference in writing, in plus or in minus. But I am far from my 10k hours in Clojure so YMMV
    - mumblemumble 6y ago
      > M-expressions happen to be catch-all name They're that, but it's also used to describe a specific syntax. IMO, the more general definition is not particularly valuable and should be discarded. Because it's just not useful to paint m-expressions, i-expressions, t-expressions, etc. with the same brush like that. Doing so just muddies the waters. If you want a general-purpose term for alternative lisp syntax, why not "alternative lisp syntax?"

by boxed 6y ago

p_l 6y ago

What happened is that "better syntax" turned out to universally fail in practice. It's not that we decided to blame the user. But there's 60 years of empirical data that points to M-expressions being irrelevant and waste of time. And people who don't have experience with other languages tend to pick it up just fine, even if the formatting is sometimes atrocious (AutoLISP community is an example).

mumblemumble 6y ago
M-expressions did fail. Their greatest failure is that they persist as a universal strawman that's useful for killing any conversation about evolving lisp's syntax. M-expressions didn't just fail because they were unnecessary; they also failed because they just weren't a very good syntax. They were more cluttered and less readable than S-expressions, while adding no real practical value. But Clojure has arguably demonstrated that you can evolve on Lisp syntax without going to M-expressions, or even changing S-expressions all that much, just by adding a few new bits of literal syntax and sprinkling some clever macros into the standard library. (A macro invocation may not technically be syntax from the parser's perspective, but it sure feels like syntactic sugar from a user experience perspective.) And, while I haven't actually tried them at all, I've at least been intrigued by t-expressions. They seem to achieve some nice things like git-friendliness and easier visual scannability without sacrificing on macro-ability.
- p_l 6y ago
  M-expressions happen to be catch-all name for various non-Sexp syntax forms. As for Clojure, TBQH I'm not too convinced that few sigils make all that difference in writing, in plus or in minus. But I am far from my 10k hours in Clojure so YMMV
  - mumblemumble 6y ago
    > M-expressions happen to be catch-all name They're that, but it's also used to describe a specific syntax. IMO, the more general definition is not particularly valuable and should be discarded. Because it's just not useful to paint m-expressions, i-expressions, t-expressions, etc. with the same brush like that. Doing so just muddies the waters. If you want a general-purpose term for alternative lisp syntax, why not "alternative lisp syntax?"