5 ms·

Every Lisp article promoting the "elegance" of its syntax will do the exact opposite to non-users of Lisp. This is no exception. From the first example on the

Every Lisp article promoting the "elegance" of its syntax will do the exact opposite to non-users of Lisp. This is no exception. From the first example on there is not one case where the Lisp syntax is a clearer expression of the concept and it's hard to justify that anything that is less clear is elegant in the slightest. Personally I'd put destructing assignment as more elegant for the first example: [a, b, c] = [10, 20, 30] But that's just me.

lispm 10y ago
In CL without the need for destructuring: (setf (values a b c) (values 10 20 30))
- icebraining 10y ago
  That's still three superfluous words. I have to agree with abritinthebay, especially when comparing with Python's destructuring, which doesn't even need brackets: a, b, c = 10, 20, 30
  - lispm 10y ago
    What about all those superfluous commas? I also dislike languages where expressions don't have visible bounds.
    - icebraining 10y ago
      A line break isn't visible? Not by itself, I suppose, but in the code, it's hard to miss.
      - lispm 10y ago
        for what expression does the line break stand, exactly?
        smallnamespace 10y ago
        But why must everything be an expression?
        davexunit 10y ago
        Because anything else is a language design mistake.
        smallnamespace 10y ago
        Can you justify that statement empirically?
    - 918723192 10y ago
      a, b, c is a tuple. Parentheses can be omitted, same as in some ML dialects: # let a, b, c = 10, 11, 22;; val a : int = 10 val b : int = 11 val c : int = 22 # a, b, c;; - : int * int * int = (10, 11, 22) # (a, b, c);; - : int * int * int = (10, 11, 22)
  - kazinator 10y ago
    Python needs a piece of whitespace on the left of the correct size and tab/space constituency, and a newline on the right. It's ambiguous. What is the relative precedence of the comma and equal sign? You just have to know. Lisp means never memorizing associativity and precedence tables again.
    - icebraining 10y ago
      No, just the name and argument order of a bunch of functions/macros (set, setf, setq...).
    - smallnamespace 10y ago
      > never memorizing associativity and precedence tables again. Why is that an unambiguous benefit though? By that logic, we ought to have parentheses around every mathematical expression as well. I think there's a sane middle ground between forcing people to memorize endless precedence tables versus not having any implicit precedence at all.
      - kazinator 10y ago
        > By that logic, we ought to have parentheses around every mathematical expression as well. Yes we should. Some math notations are simply crazy; they make it hard to follow the semantics. The one thing that turns me off math is the notation. A lot of math papers don't explain their notation; that's another problem.
        deleted 10y ago
        [deleted]
    - Macha 10y ago
      > Python needs a piece of whitespace on the left of the correct size and tab/space constituency, and a newline on the right. Good luck getting your lisp code merged with mismatched tabs/spaces or everything aligned to column 0.
- abritinthebay 10y ago
  Better, I wouldn't call it elegant though. But better than other Lisp example in this thread. Though realistically you're destructuring in the same way just with implicit vs explicit structure. Practically speaking there's no difference but CL has a less clear syntax.
kazinator 10y ago
That assignment has 9 pieces of extra syntax above a b c 10 20 30. By contrast, (setf a 10 b 20 c 30) has only three: two parens and setf. Let's count the crumbs: [a, b, c] = [10, 20, 30] 1 2 3 4 5 6 7 8 9 In Common Lisp, you an express that 10 20 30 should go to a b c using values: (setf (values a b c) (values 10 2 30)) That still has fewer overhead tokens! (setf (values a b c) (values 10 2 30)) 1 2 3 4 5 6 78 If they are bother make yourself (vsetf (a b c) (10 20 30)) This is easy to implement in a quick and dirty way: (defmacro vsetf (places exprs) `(psetf ,@(mapcan #'list places exprs)) (macroexpand-1 '(vsetf (a b c) (1 2 3))) -> (PSETF A 1 B 2 C 3) psetf is probably a good choice here since it is probably best for the construct to have parallel semantics. That is to say, we want, for instance, to be able to exchange variables with it: (vsetf (x y) (y x)) which will work thanks to psetf. We could huff and puff a little harder in the macro and make it work like (vsetf x y = y x)
- smallnamespace 10y ago
  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.
Myk267 10y ago
Or maybe it will invite them to try it out themselves? I think the 'which is clearer' thing is up to personal choice and experience. And personally, often when I'm programming in one not-Lisp, I'm often bitten by things which would have been explicit in Lisp, and the other way around - sometimes I really wish that different things looked different, as in Perl.
klibertp 10y ago
Wouldn't this work: (destructuring-bind (a b c) '(10 20 30) c) ? Destructuring is also supported in the LOOP macro (http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node252.html http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node252.html) I don't think this article was written for the non-users of Lisp, it uses too many advanced language features without any explanation to be accessible to non-Lispers.
- abritinthebay 10y ago
  Thats... similar but I wouldn't call it "more elegant". It's less clear in almost every way. Why c? Why the quote? Why not have elegant language syntax instead of that clunky macro?
  - klibertp 10y ago
    I put `c` there because `destructuring-bind` is lexically scoped and only binds values to names inside of it. This may be a good or a bad thing, depending on your use case, but I prefer having the scopes clearly visible. The quote is a multi-purpose element of the syntax, unlike `[` in Python, which only serves a single purpose (actually, it doubles as an item getter syntax). Whether having a single, more universal construct which you can use in many situations, or having a few more specialized constructs is more elegant is debatable and I think a matter of taste. The problem with having specialized syntax for this is that it's not extensible. For example, we (I'm a Python programmer, too) had to wait for 3.4 (IIRC) for a very simple feture of `a, b, *c = range(10)`; with a language built on macros you can extend these constructs as much as you wish. For example adding support for destructuring hash-maps (if it's not supported already) shouldn't be a big problem; on the other hand adding a specialized syntax for dict destructuring in Python is impossible within a language.
    - abritinthebay 10y ago
      Good explaination! Thank you! That does explain it very well but I'd also argue that a syntax that requires that much explaining probably can't be called "elegant". Powerful though? Yes. Lips syntax certainly is that.

lispm 10y ago

In CL without the need for destructuring: (setf (values a b c) (values 10 20 30))

icebraining 10y ago
That's still three superfluous words. I have to agree with abritinthebay, especially when comparing with Python's destructuring, which doesn't even need brackets: a, b, c = 10, 20, 30
- lispm 10y ago
  What about all those superfluous commas? I also dislike languages where expressions don't have visible bounds.
  - icebraining 10y ago
    A line break isn't visible? Not by itself, I suppose, but in the code, it's hard to miss.
    - lispm 10y ago
      for what expression does the line break stand, exactly?
      - smallnamespace 10y ago
        But why must everything be an expression?
        davexunit 10y ago
        Because anything else is a language design mistake.
        smallnamespace 10y ago
        Can you justify that statement empirically?
  - 918723192 10y ago
    a, b, c is a tuple. Parentheses can be omitted, same as in some ML dialects: # let a, b, c = 10, 11, 22;; val a : int = 10 val b : int = 11 val c : int = 22 # a, b, c;; - : int * int * int = (10, 11, 22) # (a, b, c);; - : int * int * int = (10, 11, 22)
- kazinator 10y ago
  Python needs a piece of whitespace on the left of the correct size and tab/space constituency, and a newline on the right. It's ambiguous. What is the relative precedence of the comma and equal sign? You just have to know. Lisp means never memorizing associativity and precedence tables again.
  - icebraining 10y ago
    No, just the name and argument order of a bunch of functions/macros (set, setf, setq...).
  - smallnamespace 10y ago
    > never memorizing associativity and precedence tables again. Why is that an unambiguous benefit though? By that logic, we ought to have parentheses around every mathematical expression as well. I think there's a sane middle ground between forcing people to memorize endless precedence tables versus not having any implicit precedence at all.
    - kazinator 10y ago
      > By that logic, we ought to have parentheses around every mathematical expression as well. Yes we should. Some math notations are simply crazy; they make it hard to follow the semantics. The one thing that turns me off math is the notation. A lot of math papers don't explain their notation; that's another problem.
      - deleted 10y ago
        [deleted]
  - Macha 10y ago
    > Python needs a piece of whitespace on the left of the correct size and tab/space constituency, and a newline on the right. Good luck getting your lisp code merged with mismatched tabs/spaces or everything aligned to column 0.
abritinthebay 10y ago
Better, I wouldn't call it elegant though. But better than other Lisp example in this thread. Though realistically you're destructuring in the same way just with implicit vs explicit structure. Practically speaking there's no difference but CL has a less clear syntax.

kazinator 10y ago

That assignment has 9 pieces of extra syntax above a b c 10 20 30. By contrast, (setf a 10 b 20 c 30) has only three: two parens and setf. Let's count the crumbs: [a, b, c] = [10, 20, 30] 1 2 3 4 5 6 7 8 9 In Common Lisp, you an express that 10 20 30 should go to a b c using values: (setf (values a b c) (values 10 2 30)) That still has fewer overhead tokens! (setf (values a b c) (values 10 2 30)) 1 2 3 4 5 6 78 If they are bother make yourself (vsetf (a b c) (10 20 30)) This is easy to implement in a quick and dirty way: (defmacro vsetf (places exprs) `(psetf ,@(mapcan #'list places exprs)) (macroexpand-1 '(vsetf (a b c) (1 2 3))) -> (PSETF A 1 B 2 C 3) psetf is probably a good choice here since it is probably best for the construct to have parallel semantics. That is to say, we want, for instance, to be able to exchange variables with it: (vsetf (x y) (y x)) which will work thanks to psetf. We could huff and puff a little harder in the macro and make it work like (vsetf x y = y x)

smallnamespace 10y ago
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.

Myk267 10y ago

Or maybe it will invite them to try it out themselves? I think the 'which is clearer' thing is up to personal choice and experience. And personally, often when I'm programming in one not-Lisp, I'm often bitten by things which would have been explicit in Lisp, and the other way around - sometimes I really wish that different things looked different, as in Perl.

klibertp 10y ago

Wouldn't this work: (destructuring-bind (a b c) '(10 20 30) c) ? Destructuring is also supported in the LOOP macro (http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node252.html http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node252.html) I don't think this article was written for the non-users of Lisp, it uses too many advanced language features without any explanation to be accessible to non-Lispers.

abritinthebay 10y ago
Thats... similar but I wouldn't call it "more elegant". It's less clear in almost every way. Why c? Why the quote? Why not have elegant language syntax instead of that clunky macro?
- klibertp 10y ago
  I put `c` there because `destructuring-bind` is lexically scoped and only binds values to names inside of it. This may be a good or a bad thing, depending on your use case, but I prefer having the scopes clearly visible. The quote is a multi-purpose element of the syntax, unlike `[` in Python, which only serves a single purpose (actually, it doubles as an item getter syntax). Whether having a single, more universal construct which you can use in many situations, or having a few more specialized constructs is more elegant is debatable and I think a matter of taste. The problem with having specialized syntax for this is that it's not extensible. For example, we (I'm a Python programmer, too) had to wait for 3.4 (IIRC) for a very simple feture of `a, b, *c = range(10)`; with a language built on macros you can extend these constructs as much as you wish. For example adding support for destructuring hash-maps (if it's not supported already) shouldn't be a big problem; on the other hand adding a specialized syntax for dict destructuring in Python is impossible within a language.
  - abritinthebay 10y ago
    Good explaination! Thank you! That does explain it very well but I'd also argue that a syntax that requires that much explaining probably can't be called "elegant". Powerful though? Yes. Lips syntax certainly is that.