I say the opposite. Lisp's regularity allows the qualities of the program itself to emerge visually. It's amazing how fine-tuned an intuition one develops after a while for code one's looking at when its structure isn't distorted by extraneous demands of the language. In Lisp, I find I am frequently (and often subliminally) processing visual cues to figure out what I'm looking at, prior to parsing what the text says, which is a slower thing to do.

Actually, you get the same effect in any language. You can tell a lot about, say, a Java program by printing it out, sticking the printout on a wall, and walking back 10 feet. But Lisp's regularity makes this effect richer, more powerful, and workable-with at much smaller scale.

Unfamiliarity reactions are not properties of the unfamiliar thing. When you walk into a space that is brighter or darker than what your eyes are used to, you can't see as well. This does not mean the space "lacks visual cues".

Clojure makes great strides in this area, by claiming for itself the reader macros for [] and {} in addition to (). [] is always used any time variable binding takes place, for example. It also more closely follows the JSONy conventions used by Python, Ruby and Javascript.

The use of [] is something I hate about clojure. I'm never entirely sure where it can/cannot/must be used and why. Sometimes it seems to get used as a replacement for quoting a list, somtimes for efficiency reasons, most of the time I just don't know why it is used.

My (arc-like) lisp dialect has pervasive python-style keyword args, which I find makes code easier to read. See, for example, https://github.com/akkartik/wart/blob/master/063http-get.wts.... Tokens starting with a ':' are keyword args. Removing them doesn't change program behavior.

You don't have to use them, but I find inserting the odd keyword arg makes things much easier to read.

I think Python-style implicit kw-args are a mistake. It means that caller can depend on the name of your function parameters and you can't change them without breaking existing code, which may not be yours. Explicit kw-args, where the names of params are explicitly advertised as part of the interface of the function, are a fine idea OTOH, and should be in every language.

Upvoted. We'll have to agree to disagree on this. I don't see why the number and semantics of arguments can be part of the interface but it's bad for the name to be.

Also, wart is like arc in that it's utterly unconcerned about backwards compatibility. It's not meant for building large edifices. That doesn't mean you can't build webapps in it. It does mean that you better write lots of unit tests.

Mostly it's a matter of habit (it's the same for typefaces, btw).

After some time, I found syntax-colored Common Lisp (in SLIME) to be very readable, and I started to find confusing other languages.

c2.com is classic, or in other words: archaic, software. This makes the page hard to read in this case. For example, it seems to be written in the style of a discussion, by multiple people, but you never know who wrote what (there are a few signed comments, but most are not). There are also no sub-headings to help you navigate the page.

It (Lisp's "lack of visual cues") is also an interesting topic, and I think it would be especially interesting if you looked at this while comparing it to Haskell.

Ward's Wiki was the first wiki, and as such, many of the pages were a mess. When you winnow through the crap, there's a lot of pure gold.

I was active at Ward's Wiki from 1999 to 2002. I just spent some seriously nostalgic moments clicking around.

When reading Scheme code for Chicken Scheme packages I find myself thinking – “So this is why Lisp is unpopular, it really is the parentheses!”

I am not experienced reading Lisp code, but I find the many levels of indentation and the abundance of parentheses overwhelming. I don’t know if this is the case with Common Lisp code.

In Chicken Scheme however, parentheses are interchangable with other brackets – so you can add visual cues through your style if you don’t care much about portability.

Someone (sorry for not noting your name) suggested dimming/graying the parentheses in lisp modes and gave this elisp snippet to do it. I find that I prefer reading lisp with dimmed parentheses.

(defface paren-face '((((class color) (background dark)) (:foreground "grey20")) (((class color) (background light)) (:foreground "grey70"))) "Face used to dim parentheses.")

(add-hook 'scheme-mode-hook (lambda () (font-lock-add-keywords nil '(("(\\|)" . 'paren-face)))))

I also came across a blog post[1] which includes a slightly more complete solution.

http://briancarper.net/blog/492/

There's also Dave Pearson's parenface.el:

http://www.davep.org/emacs/parenface.el

Hm, I'm a lisp newbie but just had a little think about this (http://blog.timfarland.com/2011/05/12/lithp.html). I'd be happy just giving special forms short, mostly non-alphabetic names, and using a bit of matchfix sugar, looking something like:

  (def map 
    (-> |list f|
        (? (== list []) []
           // (: (f (. list)) (map (.. list) f)))))

Here's how I call the various punctuation which I've found to be reasonably consistent with others' nomenclature:

Parentheses: ()

Braces: {}

Square brackets (or just Brackets): []

Angle brackets: <>

The link title is my #1 complaint with Lisp. I think it has many strengths and it's homogeneity is a strength, but also it's biggest weakness. Not a showstopper, of course, but it is a turn-off for me esp when I consider cases like having to parachute in and understand a new codebase or maintain something I wrote years ago. Python, in comparison, gives more visual cues as to what's what. It has less power, but more readability.

Indentation and convention both help (as does experience).

Python:

    def spam(self, eggs):
        for egg in eggs:
            if egg.color == "white":
                egg.crack

Which goes to:

    xxx xxxx(xxxx, xxxx):
        xxx xxx xx xxxx:
            xx xxx.xxxxx == "xxxxx":
                xxx.xxxxx

CL:

    (defun spam (eggs)
      (dolist (egg eggs)
        (when (equal (color-of egg) 'white)
                     (crack egg))))

(Ignore the fact that this example was clearly written with object-oriented Python in mind :P .)

Which goes to:

    (xxxxx xxxx (xxxx)
      (xxxxxx (xxx xxxx)
        (xxxx (xxxxx (xxxxx-xx xxx) 'xxxxx)
                     (xxxxx xxx))))

I don't think there's a huge difference.

Actually, you've misindented the CL and that's causing confusion.

You should indent when statements like:

    (when (equal foo bar)
        (do-something)

So that it doesn't look like:

    (when (equal (some-long thing)
                 (that is being compared))
        (do-something)

I think you are over-cutting the python.

First of all, with the python the first things on the lines are:

def for if egg

My eyes are naturally drawn along that list. While I could do the same thing for CL, I find the opening brackets slow me down.

The colons at the end of each of those lines tell me that each of the def, for, and if are one-statement lines. With the CL, I have to backet-count along the line to figure out if everything is on one line.

I can see instantly that ' if egg.color == white: ' is a complete statement, as it is a common pattern. With (when (equal (color-of egg) 'white), I need to bracket count to see where I have got to by the end of the line.

The only significant different I see is that == isn't xx. If you turn == into xx then it's no different.

If it were clojure it would look better than the python version since you'd use [] instead of () in a couple of places.