

Lisp Lacks Visual Cues - gnosis
http://c2.com/cgi/wiki?LispLacksVisualCues

======
gruseom
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".

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

~~~
fauigerzigerk
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.

------
akkartik
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...](https://github.com/akkartik/wart/blob/master/063http-get.wtst).
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.

~~~
BruceForth
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.

~~~
akkartik
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.

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

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

~~~
officemonkey
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.

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

~~~
Tiomaidh
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.

~~~
jrockway
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)

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

~~~
mcn
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/>

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

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

------
twfarland
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)))))

------
beza1e1
Guess what, syntax sometimes actually helps readability. For example Python's
"something[2:-2]" to remove the first and last to elements of a list or maybe
characters of a string.

Lisp is the language, where you have to write the AST yourself instead of
having a language-defined parser.

------
gord
they're called brackets

~~~
biot
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: <>

