3 ms·

Token-counting is a strawman here; you can use more tokens and still have something that's easier for a person to read. I think his point was that Lisp pushes

Token-counting is a strawman here; you can use more tokens and still have something that's easier for a person to read. I think his point was that Lisp pushes syntactic minimalism to an extreme, but all the complexity then gets shoved into what your keywords are doing. You're not eliminating complexity, you're just moving it somewhere else. Judicious introduction of syntax + keywords can be better than depending on magic keywords/macros/symbols alone. A concrete example of this comes from math--while we could write every integral as (Integral lbound ubound body differential) I'd argue that our usual integral notation is both more readable and compact because the spatial positioning of the elements has semantic meaning. The tradeoff is as you introduce more syntax, it's harder to get a macro system as elegant as Lisp's; Lisp macros are relatively easy to write because s-exprs are simple. But we shouldn't pretend that there's no downside to a minimal syntax--otherwise we would all be coding in pure untyped lambda calculus or Brainfuck.

kazinator 10y ago
Yes, you're eliminating complexity. Because there is a fixed amount of complexity in the semantics of the assignment operation itself. Having to parse some syntax with precedence and whatnot is extra complexity that doesn't further the goal of assigning to those three variables. The ideal syntax for performing some operation O on entities X, Y and Z consists only of the symbols O, X, Y an Z. We need the parentheses to delimit that as an expression among other symbols.
- smallnamespace 10y ago
  > The ideal syntax for performing some operation O on entities X, Y and Z consists only of the symbols O, X, Y an Z That's simply begging the question. That viewpoint only makes sense if all code is most parsimoniously broken down into its parse tree, but I don't think that's been shown. When all you have is a hammer (even a slick, homoiconic hammer), everything looks like a nail. > We need the parentheses to delimit that as an expression among other symbols. There are other ways to delimit expressions as well (e.g. implicitly with precedence, with whitespace, with HTML tags, with curly braces, etc.); why is Lisp's way the one true way?
  - deleted 10y ago
    [deleted]

kazinator 10y ago

Yes, you're eliminating complexity. Because there is a fixed amount of complexity in the semantics of the assignment operation itself. Having to parse some syntax with precedence and whatnot is extra complexity that doesn't further the goal of assigning to those three variables. The ideal syntax for performing some operation O on entities X, Y and Z consists only of the symbols O, X, Y an Z. We need the parentheses to delimit that as an expression among other symbols.

smallnamespace 10y ago
> The ideal syntax for performing some operation O on entities X, Y and Z consists only of the symbols O, X, Y an Z That's simply begging the question. That viewpoint only makes sense if all code is most parsimoniously broken down into its parse tree, but I don't think that's been shown. When all you have is a hammer (even a slick, homoiconic hammer), everything looks like a nail. > We need the parentheses to delimit that as an expression among other symbols. There are other ways to delimit expressions as well (e.g. implicitly with precedence, with whitespace, with HTML tags, with curly braces, etc.); why is Lisp's way the one true way?
- deleted 10y ago
  [deleted]