[alberich]

Just an observation about the parentheses... Although it can be hard to make sense of the large number of parentheses, using good indentation (emacs does it for you) helps a lot.

Of course Python makes it easier to figure out what code belongs where, it was made with this goal in mind after all.

I believe it is a tradeoff, Lisp's syntax gives you flexibility and an easy (in terms) and powerfull macro system at the expense of code readability (when compared with some languages).

[TylerE]

If you're using indentation anyway, why not allow indentation to IMPLY parenthesis.

so that say:

    foo 1 2 3
    bar 1 2
    if (eq qux 3)
      fizzbuzz 7

is translated by the parser to:

    (foo 1 2 3)
    (bar 1 2)
    (if (eq qux 3)
       (fizzbuzz 7))

[chc]

This is is suggested very, very often. It's been implemented a few times, but has never gained much currency. As best I can tell, it's one of those ideas that sounds good but rapidly grows either complex or kinda useless as you throw more cases at it and you just end up with lots of weird syntax thrown around instead of lots of parenthesis. It works best in a Lisp that was designed with this syntax like Dylan rather than as something you bolt onto a paren-dependent Lisp.

[adwf]

I think the problem is when you get into more complicated nesting of code than a simple function. For instance:

(setf new-links (append new-links (link-scanner (cu-body url-hash) (parse-uri cu-url url-hash)))))

That's a quick one-liner I wrote for part of a webcrawler. In Lisp you don't need to know anything much about parsing that syntax except that after an open parenthesis, you're going to have a function/macro followed by parameters.

Going by your example I could either do:

setf new-links (append new-links (link-scanner (cu-body url-hash) (parse-uri cu-url url-hash))))

or

  setf new-links 
    append new-links
      link-scanner 
        cu-body url-hash 
        parse-uri cu-url url-hash

or

  setf new-links append
    new-links link-scanner
      cu-body url-hash
      parse-uri cu-url url-hash

In the first example I've hardly improved anything, just removed a single pair of parens.

In the second example, I've split each new nested function call onto a new line and indented. This leaves "raw" parameters on the same line as the function call, whilst moving function params to the next line. (Note that Lisps don't make any distinction between the two usually).

In the third example, I've gone for some unholy mix where I've left the first nested function call on the same line as the first "raw" params, but moved the next params to the next line and repeated with any following functions. This is a mess...

Personally I think the 2nd example is actually quite readable. But here's the catch; this was 1 line from a 60 line function. If every line was multiplied by 5, is a 300 line function still as readable? And that's before you even get into any considerations of how to implement macros and other potentially complicated constructs.

EDIT: Admittedly, not every line is going to grow by a factor of 5, but it'll still be enough to turn a one page function into a multi-page function.

[spacemanaki]

It's been proposed a few times, and some people have gone pretty far with it, http://www.dwheeler.com/readable/sweet-expressions.html

It's never really caught on though, I would guess due to inertia. Most Lisp programmers just get used the parens, and maybe those that can't end up not using Lisp.

[rapind]

As a non-lisper reading over some of those examples I definitely prefer his "Sweet-expression". Seems much more approachable.

Once I make a serious foray into Lispland maybe that'll change...

[gknoy]

Change your IDE's color scheme so that parens are rendered in a low-contrast font color. The parens will be less-obvious.

Emacs' automatic indentation to The Proper Place is tremendously useful. I find Lisp's indentation to be just as easy as Python's, for example -- likely as I have used a Lisp for six years before coming to Python.

Once you've used it for a while, you don't think of it as much different from using {} for control blocks, () for method calls, and [] for array indexing in other languages. For me, the parens "go away", in that I follow the program control flow more by indentation than by counting parens.

[TylerE]

That's unfortunate, I think.

It would really open up the list world, especially to those of us comfortable with python.

It seems like such an obvious upgrade to me, since:

A: In no case will it break code that works now. B: It would always be possible to translate to and from it unambiguously, so if a team wanted to keep all of their code one way or the other, each individual developer could still see things with their own preference - imagine a tool like `gofmt`.

[pmelendez]

I don't see too much gain doing that though, and there are cases where using indentation would look odd. For instance:

  ((foo 1 2) 3)

  ((bar 1) 2)

would be

  foo 1 2
          3
  bar 1
        2

[TylerE]

Not at all. It wouldn't be mandatory.

May I propose:

    (foo 1 2) 3
    (bar 1) 2

[pmelendez]

Then it misses the point, don't you think? There is not too much gain between your version and original one. On the other hand, we are used to the use of parenthesis in formulas and people don't complain too much on that.

I think the main annoyance is not the syntax per se but the fact that calls are way more nested than in an imperative language counterpart.

[TylerE]

No, there is plenty to gain whe you have stuff that's nested 3 or 4 levels deep.

[pmelendez]

You don't need to if you don't want to. It actually kinda forces you to break the problem in smaller pieces or use macros.

[eksith]

I have no doubt as to the power of Lisp, I've seen the end results with my own eyes. Haven't tried reading it on Emacs yet, but I guess it couldn't hurt to try again. It's just extremely difficult to turn off my semicolon thought process and turn on parentheses.