[eksith]

Nope, you're not. Readability is crucial for those of us not wired the same way as those who seem to be more comfortable in Lisp. Can you get a lot done in Lisp? Sure, if you can scan through and make sense of it. I've tried for a long time, almost to the point of barging in on my work time, but I haven't been able to get comfortable. The innumerable parentheses, for example, make perfect sense to those with the Lisp brain, but since I'm reading it in the context of English, where too many of those are frowned upon, it's nearly impossible for me to follow quickly.

Whenever I bring this up among my colleagues, I get shot down by the proficient folks. The argument then turns into how I'm deficient somehow or haven't tried hard enough -- the word "stupid" came up a few times -- and that just completely turned me off the language.

Religion is a touchy subject.

[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.

[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.

[neutronicus]

For me, reading Lisp is a tactile experience as well as a visual one.

Lisp code is a tree, and emacs has a lot of neat commands to let you move around the tree (up one level, down one level, leaf forward, leaf backward), and I find myself doing this whenever I have a piece of Lisp code open to "feel out" its structure.

It's a little different, and maybe less like "reading" than understanding a piece of Python code, but I like it.

[ScottBurson]

There's no excuse for people calling you stupid.

But see orthecreedence's post. It can be learned with practice.

[eksith]

Thank you. I should make it clear that I'm still on OK terms with those people. It wasn't so much a direct "you're stupid" or else I wouldn't speak to them again, but more of a "that's just stupid that you can't get it". Which I guess is a long about way of saying almost the same thing, but I think they held back.

I can try to do something with it again if I have time, but I feel it's going to be a long and laborious process before I start to get comfortable. I used to unconsciously put semicolons ;)

[tensor]

Interestingly, I now unconsciously do this switching back to C:

(printf "%d" i)

Before I forget and switch back. I strongly suspect that the people who can't adapt are having difficulty because they are not programming with the new syntax full time. Practicing at night while the majority of your time is still spent with some other language is not the same thing. This is also true for learning human language and is why immersion programs are so successful.

Further, I absolutely do not buy the claims that people have that they can understand haskell easily but not lisp. Haskell might look more familiar at a casual glance, but its syntax takes a substantial amount of time to really understand.

[bobwaycott]

> I strongly suspect that the people who can't adapt are having difficulty because they are not programming with the new syntax full time. Practicing at night while the majority of your time is still spent with some other language is not the same thing. This is also true for learning human language and is why immersion programs are so successful.

I think this is spot on. I have a minor quibble that can't adapt ought to actually read find it difficult to adapt for the very reasons specified--it's not a matter of can or cannot, but a reflection of how much time one is actually able to invest in learning, like a human language. Random, sporadic investment into learning French vocabulary won't help much in improving one's ability to actually speak French. Much will be forgotten that way.

Immersion is definitely the best model for picking up any new [programming] language. Each language I use with measurable proficiency--Python, Objective-C, C#, JavaScript, French, English, etc.--is in that list because I actually took on tasks in which that was the language I had to use. Each language I've messed around with on the side for fun/experimentation/curiosity--Mandarin Chinese, Lisp, Haskell, Java, etc.--is barely worth mentioning.

[martinced]

> I strongly suspect that the people who can't adapt are having difficulty because they are not programming with the new syntax full time.

That is very interesting. It took me indeed may months of night-time programming in Clojure and elisp to get at a point where I could feel confortable with the syntax. I had a series of small "enlightenment" during that journey: the last one was not long ago, when I realized how I could "carry" state through a high-order function.

But to stay focused I kept reading and re-reading great writing about Lisp by Paul Graham and kept viewing and re-viewing amazing videos by Rich Hickey.

It's as with everything: keep your eyes on the goal, not on the obstacles.

And at one point things are going to click in.

[rayiner]

If you don't like the parents, check out Julia. It's basically Common Lisp with an infix syntax + cleanups.