Data-point of one here, but I was instantly turned off by the conflation of the empty-list, nil, and boolean-false. I could tell instantly that I'd have a hard time interfacing with data from other real-world systems, so I decided to skip CL and stick to Clojure and various Schemes for my lispy kicks.
If it doesn't have nil that is also false and the empty list, it is not a Lisp.
The conflation is a stroke of genius. I was immediately attracted to Lisp because of its clever handling of lists and booleans. Also how nil is a symbol, but () means the same thing as an alternative spelling.
People who wake these things out are imbeciles who are mutilating their language to the point it shouldn't be called Lisp.
How nil works in Lisp has a tremendous virtue: it blows away a lot of useless verbiage from code that manipulates code.
Ancient Lisp in the 1960's didn't allow car and cdr on the empty list nil. The Interlisp people realized that it was an inconvenience to always have to test consp before using car or cdr so they turned the functions polymorphic, allowing (car nil) -> nil, and (cdr nil) -> nil. According to the HOPL History of Lisp paper, the MacLisp and Interlisp people held a conference. They didn't agree on some things, but MacLisp adopted (car nil) -> nil and (cdr nil) -> nil from Interlisp. It's a compelling idea; taking it out of a supposed Lisp dialect is a counterproductive regression.
Scheme is generally considered a Lisp.
Not by me. I'm a skilled Lisp programmer, yet Scheme isn't usable to me a the rudimentary coding level using the core language. There are stumbling blocks at every turn against straightforward Lisp coding. How can it be a Lisp?
I can't even rely on Scheme to evaluate the function arguments left to right. Many forms have an "undefined" return value; in Lisp, everything returns a defined value, as a fundamental tenet! Remember Alan Perlis: "Lisp programmers know the value of everything, but the cost of nothing." Well, Scheme programmers do not in fact know the value of everything; it is often undefined! Might Scheme not be a dialect of C, in fact? The expression f(i++, i++) is directly translatable from C to Scheme, undefinedness of behavior intact!
"Lisp" has to do with the little design details, not superficial resemblance.
Calling every language with parentheses a Lisp is like calling every web browser "Netscape". Chrome is Google Netscape, Firefox is Mozilla Netscape; Explorer is Microsoft Netscape. How can they all not be "Netscape"? They run Javascript, process HTML and CSS, fetch URLs and render content.
Also, MS-DOS and Windows are Unix! Proof: their filesystem design has a directory structure in which "." means this directory and ".." means parent. There is a "cd" command in the command interpreter, and slash is accepted as a path separator such that the leading slash indicates an absolute path. Piping between processes is done with |. Gee, how can DOS and Windows not be Unix?
Superficial resemblances mean that we can dilute any name we want, as thinly as we want, to the point that it means nothing.
Me (now, after reading P and other responses): I was wrong (or at least half-wrong) about this being generally accepted. I was not aware that I've been in a "Scheme is a Lisp" bubble.
EDIT: When I was working in Lisp (early to mid nineties), ANSI Common Lisp was relatively recent, and many of my co-workers[1] — a couple of whom in fact were members of the X3J13 committee — had come from working in and implementing a variety of earlier dialects. Maybe that has something to do with it.
[2] looks like a good summary of the current divide. [3] and [4] represent only one side of it.
[1] http://amigos.rdsathene.org/other/prefix-dylan/book.annotate...
[2] http://wiki.c2.com/?IsSchemeLisp
[3] https://en.wikipedia.org/wiki/Lisp_(programming_language)?wp...
[4] https://en.wikipedia.org/wiki/Scheme_(programming_language)?...
My view isn't that Lisp is a coveted brand name, but that it should have a reasonably precise meaning. Abusing "Lisp" has created confusion.
Here is one problem: people come across some language which are called some kind of Lisp. They have some sort of experience that didn't sit well with them. Then, because of a human reasoning process called "guilt by association", they attribute the bad experience to everything that is called "Lisp".
It must all be the same, right? It's called Lisp!
The result is that if I make a language that is some kind of Lisp, I can't just present it to the users to enjoy; I have to work at dislodging their preconceived notions about what that language is, based on what they believe "Lisp" to be from some prior experiences.
Please leave the "Lisp" word for those of who earnestly implement something that has the important attributes of the original, so that over time, the meaning of the word will be narrowed and sharpened, regaining some of its discerning power.
It should be the case that if someone uses a language that is some kind of Lisp, they should be able to program in it straight away, if they have experience with any other language that is some kind of Lisp.
They should be able to define an elementary function, such as a recursive Fibonacci or whatever, without having to study the reference manual of the different Lisp.
If someone comes to me saying they learned some kind of Lisp, but then they are confused by nil in my Lisp, that is unfortunate. I put a bona fide classic Lisp feature into my Lisp, which baffles someone who thinks they had previously studied some kind of "Lisp"! How stupid is that?
Unhelpful, to say the least, and confusing.
What is the take-away message for that person? How can it possibly be anything other than: "Lisp is fragmented! If I learn something completely rudimentary under one Lisp, like how Boolean conditions work, I have to un-learn and re-learn it differently under something else, also calling itself Lisp! This is like Linux distros, only 100X worse! Phooey!"
When I last worked in Lisp (in the 90s), "Lisp" wasn't just fragmented. The word described a family of languages, that weren't even unified around LISP1 versus LISP2, let alone Flavors vs CLOS, etc. If you wanted to be clear about which one you meant, you'd say MacLISP, or InterLISP, or Common Lisp, or Emacs Lisp, or something.
Hence my question in a sibling comment: does Lisp now mean, in general or in your community, Common Lisp?
Less "family" nonsense, and more solid definitions. Problem with family is that drunken Uncle Al who comes over and sleeps on your sofa for three weeks is also "family". Al doesn't even understand that empty list is false, like everyone in this household was raised to; kick the lamer out!
But if Lisp means only "Common Lisp", that is very unhelpful and stifling.
That would be like "C" only meaning "ISO C 2011", excluding concepts such as "GNU C" or "Microsoft Visual C", or "C90" (a superseded ISO language, no longer C now).
There has to be some flexibility: a sweet spot between useless rigidity and scatter-brained dilution of meaning.
Would you consider LISP 1.5, MacLISP, InterLISP, etc. to be Lisps? They differ on different design details than Scheme does, but they differ significantly.
Related: does Lisp these days or in your community just mean Common Lisp?
I would count Emacs Lisp, ISLisp, and some similar languages as mainline Lisps. Scheme is now called Scheme. Racket was renamed from DrScheme (IIRC), to avoid being directly associated with Scheme - since it is now its own language.
See: a laudably reasonable behavior.
Oddly enough, that’s almost always something I consider a feature, even when I'm interfacing with the outside world. If I’m expecting a list, then NIL is just an empty list; if I'm expecting a value, then distinguishing NIL & false hasn’t caused me trouble. Worst-case, it’s been something I take care of at the mapping level, and don’t worry about anywhere else.
In return, actually using Lisp is really pleasant. Using Scheme tends to be a lot more verbose, because it makes a distinction where it doesn’t really have to.
(in-package :my-package)
(shadow 'if)
(defmacro if (condition then else) `(cl:if (true? ,condition) ,then ,else))
(defgeneric true? (thing) t)
Defining appropriate defmethods to make things work the way you want is left as an exercise.
In [1]: [] is None
Out[1]: False
In [2]: [] is False
Out[2]: False
In [3]: [] == False
Out[3]: False
In [4]: [] == None
Out[4]: False
In [5]: False is None
Out[5]: False
In [6]: False == None
Out[6]: False
if not []:
print("looks boolean to me...")For things like optional arguments you usually use None with an "if l is None" parameter
Meanwhile you can't iterate over None, so [x for x in None] blows up
Closure (to my understanding) allows a null value in the place of any empty seq. This seems like a major bug swallower to me
Using implicit truthiness to test for empty sequences is idiomatic Python, for better or worse.
My point is that, for me, Common Lisp is particularly defficient in this regard, in a way that means I can't really consider using Common Lisp for development work today.
In the POSIX shell, a failed termination status of a command is a false condition. Storing false as a datum is usually represented by an empty or unset variable.
Yet, people are able to write robust shell scripts to boot systems, build programs and so on.
Everything you wrote is based on a guess; not even anecdotal experience. That is below the expected level of discussion on HN.
The nil/empty/false thing is an excellent tradeoff in code that manipulates lists, rendering it succinct. For instance an expression like (when attributes (do-this ...)) means, (do-this ...) when attributes are present; i.e. the list of attributes is not empty. All the default nil return values that occur are automatically empty lists, which is very convenient. For instance a two-clause if (if condition then) returns nil if condition is false. If the caller expects a list, then that is perfect; it's the empty list. All these little conveniences dove-tail together to clarify the code.
The empty/false conflation doesn't do anything in code that doesn't manipulate lists. For instance, if you're manipulating numbers, or strings, there is no ambiguity: nil isn't a number and it isn't a string. It is distinct from 0, 0.0, and "".
You cannot have a meaningful opinion about this that anyone should take seriously unless you have experience with it: having experienced both the convenience in writing list manipulation code (particularly code-writing code) and the situations in which the ambiguity between nil (the atom) and nil (the empty list) was actually a problem.