In lisp you're essentially hacking at the AST level, this is precisely where a huge chunk of lisp's power comes from, and parens are an incredibly natural and concise way to express this structure.

I have also written a lot of Python and I can honestly say significant white space as been an issue for me far more often than parens in Lisp (and I don't find significant white space to be an issue at all).

There is clearly an "approachability problem" to Lisp, and it seems worth trying to solve. (If nothing else, the more popular a language gets, the more opportunities you will have to get paid to write in it for a living.)

Parens come up every single time the word Lisp is mentioned in "mixed company"--that is, both Lispers and non-Lispers. It's not just the most common complaint about the language, but the dominant complaint. (Thought experiment: What's the #2 complaint newbies make about Lisp? And how much longer did it take you to answer that question than #1?)

Originally John McCarthy had intended to use M-Expressions for Lisp, e.g. "car[cons[(A . B); x]]", but programmers preferred the parens-and-whitespace of S-Expressions instead, so they became the default.

There's no reason to dismiss the possibility of another such evolution, again based on nothing more than programmer preference.

No matter how familiar or useful you might find the existing approach, it's always possible that it can be improved.

Although these alternate syntaxes may be helpful to newcomers, they have never caught on. Expert users actually prefer the parenthesized form; so anyone working in Lisp for very long has to learn to deal with it -- and usually, once they do, they find it preferable.

You said it yourself: programmers preferred S-expressions, so they became the default.

The other important point here is that the non-Lispers are right, in a sense: editing Lisp without a paren-counting editor is just as tedious as one would expect. But with a paren-counting editor -- and even better, with something like Paredit that keeps the parens balanced at all times -- editing actually becomes easier, more fluid, and more pleasant than in other languages.

That is why expert Lisp users prefer the parens.

That's the real barrier, IMO. Who wants to switch editors just to learn a new language with an (apparently) impoverished syntax?

If it really is the case that all Lisp needs to really take off is editor plugins for IntelliJ IDEA and Visual Studio -- hmm -- maybe we should do that.

I mean, learning syntax is really not where we spend most of our time while writing software, right? All else being equal, the amount of time it takes to learn new syntax is orders of magnitudes less than the time you spend, in aggregate, finding and fixing bugs. So it's a misguided trade-off, and (fortunately or unfortunately) I don't think swapping square brackets for parens (or whatever) is going to change people's preferences for what looks and feels easiest for them.

I'm not sure what you're getting at, but the perennial #2 complaint is "There aren't any libraries!", and my response is typically the same (exasperated) answer as for #1: "You've written maybe 10 lines of Lisp in your life -- I've written several orders of magnitude more than that, and I can say that it's simply not an issue, and I wish the libraries we had in $(MAINSTREAM_LANGUAGE) were as high quality".

(I admit I am not a very good ambassador for Lisp.)

#3 is always "Who's going to maintain it?", at which point I remind them that more than half the team they've hired didn't know $(MAINSTREAM_LANGUAGE) when they started here, either, so apparently learning new languages isn't a showstopper.

There is no #4, because at this point they usually stop talking to me, and get that "He's one of those weird Lisp guys" look on their face, and politely make it clear that regardless of how many objections I can answer, Lisp will never be used for anything except Emacs.

I appreciate when languages don't make me insert/edit/move over/count/deal with/etc. more characters than necessary. Maybe there's a good vim setup to do that already - that would go a long way to alleviate my concerns.

[0]: https://github.com/santoshrajan/lispyscript/blob/master/exam...

    (if (empty? x)
      foo
      bar)

foo is the result of if x is empty, and you can tell it is not a function call because it has no parens. Whitespace is merely a style consideration, as it is in C++ or Java.

There are ways to save time/trouble within the language. For instance, in Clojure

    (foo (bar (baz (quux x))))

    ((comp foo bar baz quux) x)

Ultimately syntax is more about ease than it is about power or simplicity. I think it's worthwhile to try to look beyond that into what the code is saying rather than how it's saying it. You have to do this anytime you learn a significantly different language anyway, right?

Ideal:

    if (empty? x)
        foo
        bar

    (if (empty? x)
        foo
        bar)

    (comp foo bar baz quux) x

As it stands now, the trade-off is some unfamiliarity and discomfort up front for rather elegant consistency for the entire time you use the language. When you're optimizing for the people who'll use the language, the former is a lot less significant. :)

One thing worth noting is that Clojure does introduce constructs which use square brackets, braces, etc. It's a little nicer to use brackets for grouping, in lieu of parens for lists or declaring function params.

The elegance seems to come from having a simpler parser, and one less thing to explain to people when they're learning the lanuage. As a user of a language and not a developer of a parser, the first doesn't concern me and the second should be trumped by long-term concerns. Using significant whitespace to eliminate syntax is elegant in its own way as well.

Again, maybe this is just because I'm not a lisper, but keeping implicit parens that follow a well-established pattern should be a trivial mental task for a developer. Could you provide a piece of lisp code as a contra example?

Myself, I only picked up Clojure a couple of weeks ago, give or take. I don't use it at work so this is in my spare time (which seems ever more shrinking).

Parens aren't a big deal, and it's kind of crazy we spend this much time talking about them instead of something more significant. (Hell, maybe people just enjoy trolling.) Omit all indentation in Java or C++ and you'll be doing the bracket-counting that you assume Lispers spend their time doing.

  (define (factorial n)
    (if (<= n 1)
      1
      (* n (factorial (- n 1)))))

  define factorial(n)
    if {n <= 1}
      1
      {n * factorial{n - 1}}

Of course, it looks better to me because I'm used to lisp. When I first saw lisp I thought the syntax was nuts. Point being - what looks "good" can simply be a matter of what you're used to.

    factorial n = case
    | n <= 1 -> 1
    | else   -> n * factorial (n - 1)

clisp:

    (defun factorial (n) (cond
        ((<= n 1) 1)
        (T        (* n (factorial (- n 1))))))

    (defn factorial [n] (cond
        (<= n 1) 1
        :else    (* n (factorial (dec n)))))

the clojure one is nicer since it lacks the visual clutter of the per-case enclosing parens, but it feels slightly wrong from a lisp perspective since i'm now replacing [(a, b), (c, d)] with [a, b, c, d] which has changed the innate structure of the expression.

i actually like the racket convention of using square brackets to distinguish this the best of all the lispy options:

    (defn factorial [n]
      (cond
        [(<= n 1) 1]
        [:else    (* n (factorial (dec n)))]))

  (define (factorial n)
    (cond
     [(<= n 1)  1]
     [else      (* n (factorial (sub1 n)))]))

Getting rid of parentheses means you cannot use structured editing tools like Paredit anymore (http://emacswiki.org/emacs/ParEdit). You can't appreciate how slow and clumsy it is to edit code in other languages until you've been using Paredit for a while.

One sometimes valid argument against prefix notation is for expressions primarily involving binary math operations (+ * - / etc.). In some cases it's true, in other cases the Lisp code looks gnarly because people try to write the formula out without introducing intermediate variables. There's macros out there that will parse infix arithmetic (http://cliki.net/Infix); I've never used them so I can't comment on whether they improve code readability or not.

    (defun paredit-barf-all-the-way-forward ()
        (interactive)
        (paredit-split-sexp)
        (paredit-forward-down)
        (paredit-splice-sexp)
        (if (eolp) (delete-horizontal-space)))

    defun paredit-barf-all-the-way-forward ()
        interactive
        paredit-split-sexp
        paredit-forward-down
        paredit-splice-sexp
        if (eolp) (delete-horizontal-space)

    range = fn: [i]
      loop: [i, r = []]
        if: (i == 0) r
          continue: (i - 1), concat: (i - 1), r
    
    print: range: 5                # [0, 1, 2, 3, 4]

I'm not a lisp guy though, so I'm sure that sentiment is naive.