Survey results: Lisp-2-ness is used by many

Thanks to the many who responded to my survey on comp.lang.lisp and on my blog. It seems like more than 80% of the more than 60 people who responded do not avoid using the same names for variables and functions.

The original statement that inspired the survey was posted to the arc forum a few days ago.

Tags:

Comments

I suppose this makes me a total lame-ass, but I really dislike this habit. Anything that makes symbol bindings less obvious -- even by a tiny amount -- seems to be a net loss of comprehensibility for maintenance programmers. I mean, I feel the same way about dynamic binding in OO languages so this is not really a lisp-critique per se. It just seems gratuitous.
Do you write or maintain much Common Lisp? There are often lots of problems an external observer can imagine in a system that don't really come into play in practice.
My experience with lisp is limited to two professional gigs maintaining and extending someone else's scheme code, and some side-project toys I've written in CL and/or scheme. I enjoyed many aspects of writing lisp and would probably bite if another such job came along. But nothing ever motivated me to want to try using the lisp-2-ness of CL in my own code. I've always hated the random-guess-at-symbol-binding that comes into play in the homebrew OO systems and macrology of scheme code, and wouldn't want to make matters worse.

In general though, lisp-2-ness doesn't seem any different to me than type/type-parameter/macro/function/operator/field-name/tag/constructor/value namespace disjointness that appears in various languages, or in fact just the simpler facility of block-structured variable shadowing. And in all such cases -- everywhere outside of this "lisp-1/lisp-2" thing that seems to have stuck in lisp culture as being historically meaningful -- the outcome has more or less been "don't recycle names from legally-different namespaces". Doing so would get a patch rejected from most projects I've ever contributed to. Indeed, most language cultures I've seen wind up adopting some typographic conventions to further visually differentiate names of different "meanings", beyond what the language requires, such as UPPER_CASE_MACROS or <type-names> or *special-variables* or such. And I think that's generally a good thing. Helps the reader. Even just pragmatically, it helps dumb "readers" like grep or font-lock-mode.

Maybe I've missed something that makes functions and non-functions an especially-tasty case of shadowing or disjoint-naming?

(Anonymous)

Sampling bias?

I know you were trying to get a sense for how many people that program Lisp-2s pretend like they're Lisp-1s, but it might have been beneficial to also try to get a feel for how many use Lisp-1s because they don't like the separate-but-equal treatment of variable names found in Lisp-2s.

Perhaps my preference won't count because I have yet to do any substantial software development in either a Lisp-2 or Lisp-1, but I think that the perceived need to reuse the names of variables and functions stems from a habit of poor variable naming. Instead of calling a variable or parameter "list" or something equally nondescript, try to more accurately describe what it is. This may create some slightly longer names, but ultimately creates more readable, maintainable code.

(Anonymous)

Re: Sampling bias?

Instead of calling a variable or parameter "list" or something equally nondescript, try to more accurately describe what it is. This may create some slightly longer names, but ultimately creates more readable, maintainable code

And sometimes a name "list" is the most descriptive one you can have, if the function you are writing is general enough (and Common Lisp programmers create quite a lot of these) functons. Look for instance at the signature of MEMBER function. Or even COPY-LIST. Same goes for strings -- if I write a function that does something to any string passed in, then there's no more descriptive name for the parameter as "string".

(Anonymous)

Re: Sampling bias?

"And sometimes a name "list" is the most descriptive one you can have, if the function you are writing is general enough (and Common Lisp programmers create quite a lot of these) functons. Look for instance at the signature of MEMBER function. Or even COPY-LIST."

I disagree. The hyperspec describes it as "copy-list list => copy". But why "list"? Wouldn't "original" be both more descriptive and consistent?

I think this is another aspect of what Kent Pitman points out in his "The Best of Intentions: EQUAL Rights - and Wrongs - in Lisp" essay. Other languages conflate physical meaning and semantic meaning, but much of Lisp's power comes from not doing this: almost everything is a list, so the semantics of "a list" exist only in context, in the programmer's head and in the names of the variables. If I were to call something simply "list", it would imply I think that the physical type is its most important aspect.

After all, I know from the name "COPY-LIST" that it's a list. The important part of the arg is that it's the original. Well, in this case it's trivial, so even calling it "x" would suffice.

(Anonymous)

another note

Hi Zach,

I used to wonder why people would want separate namespaces. Then a couple things made it clear:

1) Having a separate namespace for functions means that all values in that space are functions. Thus you can avoid typechecks. I understand that Chez Scheme uses this as an implementation detail, though it is not exposed to the language.

2) Having a separate function namespace makes hygiene less of a problem. In Guile Scheme I used to unquote in values into macro expansions -- function values -- to ensure hygiene. Of course once we started to compile, that didn't work, which finally made me wary of the defmacros I used and loved for many years. Of course having modules made that problem much more acute. But in a system without modules, having functions be in there own namespace reduces hygiene problems because functions are rarely rebound lexically.

Andy Wingo

Re: another note

Hi Andy,

the following paper by Gabriel and Pitman addresses this thoroughly:
http://www.dreamsongs.com/Separation.html

Luis Sergio Oliveira

September 2014

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
282930    
Powered by LiveJournal.com