Re: Paul Graham's Arc is released today... what is the long term impact?

Joost Diepenmaat wrote:

There are two points to consider here:

Readability: long/explicit names for functions can make the intent of
the code clearer. On the other hand, short - even "obfuscated" names for
often used functions can make the code easier to scan. A minimal amount
of knowledge of the language - or the project and its programming style
- can be supposed.

What do you mean by "making the code easier to scan?" Surely the computational complexity involved in lexical analysis of a token is not significantly increased by the length of the token involved. And, in Lisp especially, after the reader has finished with a string, we're only left with symbols anyway, which we can test for equality with EQ.

; SLIME 2006-04-20
CL-USER> (defun foo ()
(read-from-string "cam"))
FOO
CL-USER> (compile 'foo)
FOO
NIL
NIL
CL-USER> (defun bar ()
(read-from-string "compute-applicable-methods"))
BAR
CL-USER> (compile 'bar)
BAR
NIL
NIL
CL-USER> (defun baz ()
(read-from-string "compute-the-applicable-methods-from-the-types-of-the-arguments-which-would-be-passed-to-the-generic-function-at-run-time"))
BAZ
CL-USER> (compile 'baz)
BAZ
NIL
NIL
CL-USER> (time (foo))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 0 msec
; space allocation:
; 26 cons cells, 320 other bytes, 0 static bytes
CAM
3
CL-USER> (time (bar))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 0 msec
; space allocation:
; 2 cons cells, 0 other bytes, 0 static bytes
COMPUTE-APPLICABLE-METHODS
26
CL-USER> (time (baz))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 1 msec
; space allocation:
; 2 cons cells, 320 other bytes, 0 static bytes
COMPUTE-THE-APPLICABLE-METHODS-FROM-THE-TYPES-OF-THE-ARGUMENTS-WHICH-WOULD-BE-PASSED-TO-THE-GENERIC-FUNCTION-AT-RUN-TIME
120
CL-USER> (defun qux ()
(read-from-string (make-string 4096 :initial-element #\x)))
QUX
CL-USER> (compile 'qux)
QUX
NIL
NIL
CL-USER> (time (qux))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 2 msec
; space allocation:
; 2 cons cells, 38,136 other bytes, 0 static bytes
XXXXXXXX [...]
4096
CL-USER>

So, yes, QUX took 2 milliseconds instead of 1 millisecond for FOO, BAR, and BAZ. Perhaps "scanning" a 4096 character long symbol can make a measurable difference. Now, I could see whining about a name like something from BAZ, but when we're talking about a difference of four characters between LAMBDA and FN, I just can't believe that people are seriously considering such a thing to be an issue.

I watch my niece, who is just learning to read, trace her finger along with each individual letter of a word while she tries to form the sounds for it. But for quite some time after such a young age, I find that something along the pathway from my eyes to my brain will even helpfully correct spelling mistakes in words for me such that I have a hard time seeing the actual mistake on the page. I have absolutely no conscious thought of there being anything like "scanning" involved. Again, I can't believe that anyone would seriously argue that our mental apparatus gets bogged down by "scanning" the tokens. The longest symbol in the COMMON-LISP package is 38 characters long, at least according to

CL-USER> (loop for s being each present-symbol of :cl
maximize (length (symbol-name s)))
38
CL-USER> (loop for s being each present-symbol of :cl
when (= (length (symbol-name s)) 38)
collect s)
(LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT
LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT
LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT
LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT)
CL-USER>

If anyone would actually claim to have a difficult time "scanning" these phrases, I would seriously doubt that they could read at a level would be required to have been educating to the point to be able to understand the concept of a least positive normalized double float in the first place. And I seriously doubt that probably as high a percentage of 99% of the people making pop physiology arguments have the slightest idea of that on which they are basing their arguments. Which is, I suppose, why it is "pop" physiology. However, since we're already in that water, I might as well splash around a little bit, too. Given how difficult a time most people seem to have finding typos, given the unconscious behavior of seeing what one expects to find on the page instead of that which is really on the page, I would expect that compacting information into less characters actually makes it harder to scan. It requires that the reader basically be constantly on the alert for significant typos. Of course, I am far from an expert on the cognitive functions involved in turning glyphs on a page or screen into thoughts and meaning. I going to go out on a limb and guess that neither do you, Joost. My apologies if this just happens to have been the topic of your doctorate thesis.

Ease of use: I use lambda a *lot*. I suspect I'm not alone in that. If I
had to use "compute-applicable-methods" as much as I did lambda, I'd run
away screaming. Or write a short alias.

"c-a-m C-c M-i" works just fine for me. I have a feeling that the majority of people who like to complain about long names use deficient text editors. I wonder what Paul Graham's favorite editor is.

I don't care where it's coming from. It could be called /. for all I
care (as has been suggested in this thread). Except that /. is much
easier to type.

I tend to like my names to "come from" somewhere. I find it helps associate the name with the concept. What I type into the editor, on the other hand, I like to have it associated with the muscle memory of my fingers. Personally, I've never even paused to consider typing (lambda (x) (...)) to be an issue but if I did I would've probably defined an abbreviation in Emacs for "/." to insert "(lambda (x) ())", leaving point inside the body of the lambda form. Lisp is already a language for which one needs an editor which will help the programmer write her code. I can't imagine trying to write Lisp without some kind of parentheses matching capability.
.