7 ms·

I'm amused by the fact that when you criticize LISP's syntax, defenders always say the syntax doesn't matter and real Lisp programmers don't even see the parent

• manifestsilence 7y ago
  I think the appeal of the syntax for those who get used to it is the regularity, like you said. The advantage of the regularity isn't its human readability, but its ability to macro, no? What I'd like to see is better tools for reading and editing such a regular syntax. Probably I should just learn emacs, but I'm thinking someone could make a more intuitive structured editor for LISP syntax. No need to mush around blobs of text when everything is nested lists.
  • braythwayt 7y ago
    > The advantage of the regularity isn't its human readability, but its ability to macro, no? This. You can write macros for less regular languages, but there's always additional friction involved. At some point, it comes down to whether you think LISP is a "programmable programming language." If you do, macros are a core part of the paradigm, and s-exprs make macros easy to work with.
    • kazinator 7y ago
      I already really liked Lisp's syntax before I learned about the macros. No ambiguity; no brain cycles required to work out what element is a child or sibling of what element. Great editing ergonomics.
  • c3534l 7y ago
    I suppose that's a good point. Lisp programmers seem to enjoy macros quite a bit, and so I guess those things do work well together.
  • mumblemumble 7y ago
    I would guess, based on the second and third sentences of the article, that the author agrees that this is the primary motivation: > If you already love s-expressions then lisp-flavored languages will make it nicer when you need to build on existing platforms. In case the target language does not support advanced features like macros and REPL-driven development, these can often be easily added by using the s-expressions layer. To the comment about "parenthesis-laden syntax", I find that, if I actually count the characters, my Java code tends to have just as many parens as my Clojure code. I suspect that there's just a tendency, if all you've ever known is algol-style syntax, to hyper-fixate on lparens that appear to the left of the function name. I think maybe the only programmers who get to criticize others for overuse of parenthesis are Forth, ML, and Haskell programmers.
    • randallsquared 7y ago
      Actually, in my experience detractors tend to fixate on the )))))))))) that ends some lispy code.
      • madmulita 7y ago
        Yet are completely fine with things like: } }) ]} }]) } } } }
        • krapp 7y ago
          At the very least that is more readable due to the indents and the extra syntax. Depending on what language you're using, those different common groups of tokens do communicate context, whereas a dozen right-parens on a single line really don't.
  • hencq 7y ago
    For me personally the regularity is definitely a plus. Especially combined with an editor like paredit or smartparens it becomes very easy to move entire sections of code around.
• nextos 7y ago
  You should look into Racket. Apart from getting some momentum due to the merger with Chez, it has a relatively big academic community backing it up. And it's very different from other Lisps in the sense it's trying hard to be an ecosystem for language-oriented programming, which is probably taking the idea of macros to a new level. I've used Common Lisp and Clojure for many years, but Racket looks more and more appealing to me.
  • nikofeyn 7y ago
    > it has a relatively big academic community backing it up this is actually a problem in my eyes and will prevent it from gaining industrial traction. for example, this keeps the main developers as a revolving door of graduate students writing code and the core maintainers as full professors who have priorities different from industrial users. secondly, the culture of racket is as a research language. they just replaced the runtime (loads of risks for industrial users), and now they are replacing the syntax. this does not create an environment enticing to industrial users. the racket team feels these changes will increase its user base, but i believe if that ever happens, these changes are deferring such an increase well into the future.
• fungiblecog 7y ago
  The parentheses give you Macros, a completely uniform calling convention, and the "everything's an expression" programming style. These are arguably the things you cannot get from a non-lisp language. Almost everything else varies between lisp implementations. The lack of syntax matters in the sense that once you don't have any you realise that it just gets in the way. Having lots of parentheses is a small price to pay for powerful tools so that's why "it doesn't matter". Non-lispers generally don't understand how lisp is different from their language of choice and therefore don't understand why the lack of syntax is an advantage.
  • rusini 7y ago
    The syntax of S-expressions is the syntax. It's a form to serialize trees (made out of pairs) and it is described by some grammar.
    • lispm 7y ago
      > The syntax of S-expressions is the syntax. of s-expressions. Lisp has an additional layer of syntax on top of s-expressions. For example the DEFINE-CONDITION operator has this syntax: define-condition name (parent-type*) ({slot-spec}*) option* => name slot-spec::= slot-name | (slot-name slot-option) slot-option::= [[{:reader symbol}* | {:writer function-name}* | {:accessor symbol}* | {:allocation allocation-type} | {:initarg symbol}* | {:initform form} | {:type type-specifier} ]] option::= [[(:default-initargs . initarg-list) | (:documentation string) | (:report report-name) ]] function-name::= {symbol | (setf symbol)} allocation-type::= :instance | :class report-name::= string | symbol | lambda expression with even more syntax for things like lambda expressions and type specifiers.
      • rusini 7y ago
        I know :) And that's cool, and that property is the base of my own programming language. I am also trying right now to find some explanation why it's cool based on some fundamental conclusions from theoretic computer science... I just feel that when someone says that Lisp does not have syntax or that syntax is not important, it's plain wrong...
• lispm 7y ago
  The thing that matters is that code is written as s-expressions, which has a simple textual serialization format with lists, symbols, numbers, strings, vectors and a bunch of other data types. Thus any Lisp form is automatically data: not simple strings or complex syntax trees. This enables a bunch of stuff: code can be relatively easily treated as data. It allows easy code generation, transformations (-> macros), traversal (-> interpreters/compilers) or editing. The parentheses are just a part of the s-expression textual syntax. The s-expressions then are used by basic operations like READ, MACROEXPAND, PRINT and EVAL. Additionally many of the primitive data functions can be used to manipulate code: first/rest, list, append, reverse, map, ...
  • unlinked_dll 7y ago
    The issue is that code is read more often than it is interpreted, written, or compiled. All the beautiful aspects of lisp make it decidedly unwieldy in production software. There’s a tendency of projects written in lisps to be unwritten in lisps as they mature.
    • dreamcompiler 7y ago
      That has more to do with managerial ideas of programmer fungibility than Lisp's readability.
    • naniwaduni 7y ago
      Frequently-used interpreted code is probably interpreted more than it is read. Most of the code in a large codebase is likely compiled more than it is read. One-off code is often written, compiled, and executed once, and read never. If a piece of code is read more often than it's interpreted, written, and compiled, it's probably example code.
    • lispm 7y ago
      > The issue is that code is read more often than it is interpreted, written, or compiled. In a Lisp system, the code is always there and not just in textual forms. > All the beautiful aspects of lisp make it decidedly unwieldy in production software. There’s a tendency of projects written in lisps to be unwritten in lisps as they mature. There are two main factors which lead to Lisp software being rewritten: 1) deployment. In the early days it was the lack of resources (memory, speed, ...), but there are other factors like having a robust runtime or the ability to integrate in larger software around it. 2) familiarity. There are not many people available to maintain Lisp software. Not because the syntax is strange, but because the whole language is strange. There are no major other programming languages which work like Lisp, so few people can productively program in it. There are exceptions to it, like the simple Lisp used in AutoCAD and related software. These have millions of installations and the complexity on the Lisp side is not that huge - there it's mostly used as a simple interactive programming language. What makes Lisp actually difficult for programmers is not the syntax, but the pervasive use of code as data, code transformations, various ways of meta-programming, etc. It's the features it was developed for: computing with symbolic expressions - here even applied to itself. The language Lisp was built to compute with symbolic expressions, then the idea that a Lisp program is itself a symbolic expression is tempting... this then leads to center programming activities around this idea.
• mindslight 7y ago
  Like the mainstream political arena, the most accurate explanations don't stick, but the most appealing ones do. The parentheses of Lisp's "function within the tuple" application disappear in the same way that other languages' function-before-the-tuple parenthesis disappear - it's not particularly noteworthy. "Don't even see the parenthesis" is talking past the real objection, which is that the depth of parenthesis in every other language does not matter - ie (expr) is equivalent to ((expr)). Whereas in Lisp they also mean another level of application. I think an interesting synthesis is Haskell, where function calls are simply juxtaposition. Parenthesis are just grouping like most languages, but it ends up feeling quite Lispy.
  • kazinator 7y ago
    > the depth of parenthesis in every other language does not matter - ie (expr) is equivalent to ((expr)). You might want to rethink that hurried statement just a tad: // C for ((i = 0; i < MAX; i++)) {...} printf(("hello, %", name)); #if defined ((__GNUC__)) # Shell var=$((cat /etc/motd)) # Pascal type color_type = ((Red, Green, Blue));
    • mindslight 7y ago
      Sure, my phrasing was overly simplistic, applying in spirit to the way languages define general recursive expressions. But if you want to be technical, most of your examples would not be considered expressions in the given language. int j = i = 0; i < MAX; i++; /* ? I think not. */ But sure, many languages also use parenthesis for things besides general expressions. Ultimately this argument is anti-productive nitpicking.
      • kazinator 7y ago
        > most of your examples would not be considered expressions in the given language. So that's a piece of cognitive load that you have to carry to know when the parentheses are on an expression, and do not change the meaning if compounded, versus when they are around something else where they may not be removed or compounded. In Lisp, everything is an expression, and no there is no willy-nilly removal of nesting or compounding of nesting. That's less to remember. Even fragments of forms are expressions, according to ANSI CL glossary terminology. If we have (let ((a b)) ...) then a, b, (a b), ((a b)) and let are all expressions. With the exception of b, what they are not is forms: expressions presented for evaluation. > Ultimately this argument is anti-productive nitpicking. Who started it?
• kazinator 7y ago
  > Lisp clings onto the parenthesis thing while claiming the parenthesis thing doesn't matter. Of course it matters; it just doesn't matter in the sense of not being a problem. Your argumentation is rooted in drifting across different semantics of the phrase "doesn't matter".
• pera 7y ago
  Parenthesized sexprs are easy to parse (by both machines and humans) and Lisp text editors already have many convenient ways to work with them. There are though some interesting alternatives such as sweet-expressions[1] and wisp[2], but not too many people care about these. [1] - https://srfi.schemers.org/srfi-110/srfi-110.html https://srfi.schemers.org/srfi-110/srfi-110.html [2] - https://srfi.schemers.org/srfi-119/srfi-119.html https://srfi.schemers.org/srfi-119/srfi-119.html
• iLemming 7y ago
  It's not about syntax. It's about code being data and vice versa. > Syntax, interestingly, complects meaning and order often in a very unidirectional way. Professor Sussman made the great point about data versus syntax, and it's super true. I don't care how many you really love the syntax of your favorite language. It's inferior to data in every way. Rich Hickey