I think this comment is unhelpful. The meaning of "Lisp" is a little bit complicated, but I think it can be explained better than this.

"Lisp" has two meanings: (1) ANSI Common Lisp; and (2) the family of programming languages to which ANSI Common Lisp belongs, and which was called "Lisp" many years before ANSI Common Lisp was conceived; that family includes many other languages with quite a bit of variety, including Scheme, Clojure, INTERLISP, T, kernel, picolisp, *Lisp, (the early versions of) Dylan, and many others.

I appreciate the feedback. Maybe my approach could have left out the claim of Lisp == Common Lisp, though I still am amused (as I mention near the end of my later comment) and slightly bothered that such a diverse set of languages (Python too, it's sometimes called an acceptable Lisp) can get called "Lisps" or "dialects of" or "members of the family" rather than an explicitly vague "Lisp-like".

The main direction I was coming from though was that ~10 years ago I was just like the OP, I had read some of SICP and PG's essays and thought I knew Lisp, but no, I just knew a minimal subset of Scheme. Very pretty (https://www.thejach.com/imgs/lisp_parens.png), learned some neat things, but didn't pursue it in favor of practical workhorses like Python et al. I went with the "learn Lisp for the side effects of learning it but don't ever use it" crowd, but I never learned Lisp. It wasn't until much later that I found out Common Lisp was way more than just an ugly syntax change on Scheme that required #' in front of function names. So the features I listed in my comment are really a subset (but a strong one) of the features that would have convinced me ~10 years ago to take a much closer look into actually using Lisp and recognizing I learned something very different.

I get it; you thought Scheme was Lisp and Lisp was Scheme, and want to prevent others from falling for the same misunderstanding. That's a laudable goal.

Lisp is an old family of languages, though. It's been around a long time, and it's explored a broad range of language ideas and a lot of nooks and crannies. There are a lot of Lisps that are pretty different from each other. There's a pretty good list at Wikipedia (https://en.wikipedia.org/wiki/List_of_Lisp-family_programmin...), but it still omits some interesting variants (for example, *Lisp, Kernel, Lispkit Lisp, Connection Machine Lisp, and others). There are greater differences between, for example, Common Lisp and kernel than between Common Lisp and Scheme, but all of them are still recognizably Lisp.

So you're right: you don't want to be fooled into thinking that Scheme is all there is to Lisp. But Common Lisp also isn't all there is to Lisp. Scheme plus Common Lisp plus Clojure isn't all there is to Lisp, either. It's a big space, and there's room for it to grow bigger still without losing its essential Lispiness.

"APL is like a beautiful diamond – flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud – it still looks like Lisp."

-- attributed to MIT Professor Joel Moses

To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language)

Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.

Lisp user base is so small enough that these categories largely look pointless to people outside.

For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

> For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.

Since only CL and Emacs Lisp can and do share actual Lisp code, I call only them Lisp for practical purposes.

For 'unpractical' purposes - they share no source code but are influenced by practical Lisp - , Logo, Javascript, Ruby, Clojure ... are also Lisp.

>>Since only CL and Emacs Lisp can and do share actual Lisp code

But what exactly is 'actual lisp'. I mean what is this strict definition?

Forgive me, I understand calling Scheme and CL as same might feel like saying Java and C++ as same. But one would be right in saying Java and C++ both come from a C based paradigm.

On the same lines one could say CL and Scheme come from lisp paradigm. At this point in time both communities compared to any major language community are so small that one could refer to both as Lisp.

The problem is that both CL and Scheme communities have very little to do with each other.

For practical purposes Lisp dialects are those directly inheriting back to Lisp I from McCarthy. You can run programs from 1960 in Common Lisp with very little changes (unless it uses machine interfaces). To port them to Scheme is possible. To port them to Logo, Clojure, Javascript or other languages considered to be dialects in a wider sense mostly means a rewrite.

Thus for me Lisp means the dialects of Lisp and their respective communities which can share code, libraries, applications by relatively simple ports. For example Emacs Lisp has Common Lisp enhancements, which are semantically very similar. ISLISP could be directly integrated into a Common Lisp - Kent Pitman mentioned that he actually did that to see that they are culturally compatible.

Languages who don't directly share code are maybe part of an abstract family, which has no agreed on definition - thus this is for practical purposes relatively useless.

>The problem is that both CL and Scheme communities have very little to do with each other.

At first I thought this was absurd, but after some time learning Lisp this was more obvious.

Scheme and Common Lisp are built around totally different philosophies, and thus not only the languages diverge, but also the way you program in them.

It's definitely a confusion. The point seems to come up on HN from time to time... I don't care very much about the distinctions but it's still fun to spell out my case for why maybe one should care. "Lisp" has these nice connotations as old-but-gold going back to 1960 and many success stories in real world applications. Common Lisp has a direct lineage to that Lisp, but even ignoring that there's a syntactical lineage too. e.g. You can take stuff from the Lisp 1.5 manual and with very small rewrites have it run on a modern Common Lisp implementation.

    DEFINE (( 
    (LENGTH (LAMBDA (L) 
    (PROG (U V) 
        (SETQ V 0) 
        (SETQ U L) 
    A   (COND ((NULL U) (RETURN V))) 
        (SETQ U (CDR U)) 
        (SETQ V (ADD1 V)) 
        (GO A) ))) ))
    LENGTH (((X . Y) A CAR (N B) (X Y Z))) ; ---> 5

could be rewritten (even if not idiomatic) to

    (defparameter length-cl (lambda (l)
        (prog (u v)
            (setq v 0) 
            (setq u l) 
        A   (cond ((null u) (return v))) 
            (setq u (cdr u)) 
            (setq v (1+ v)) 
            (go a))))
    (length-cl '((x . y) a car (n b) (x y z))) ; ---> 5

Differences: CL doesn't have a special top-level that doesn't need parens. CL doesn't use 'define' (though Scheme does), you'd usually use defun for a function and not use lambda either. CL uses '1+' instead of 'add1'. CL needs a quote (or something else) before the argument to the function to avoid trying to evaluate it. But that's basically it. You can do this for other examples in that manual too, including more complex ones.

To me, a "dialect" implies that you're in the same language but some users of that language just say things a bit differently to each other. "Howdy" vs "Yo". So "add1" and "1+" might be an instance of a dialect change from 1960. For Common Lisp, "sb-ext:run-program" would be the SBCL "dialect" / implementation's way of running an external program while "run-shell-command" might be Allegro CL's. Is Scheme's call/cc a dialect of Lisp60's prog and go? Clojure doesn't have goto at all.. Racket is much cooler than standard Scheme and has nice packages like https://docs.racket-lang.org/control-manual/index.html but is that a dialect equivalent? At what point does the C equivalent of all the above just become another dialect on the way Lisp says it? (And if you're using Common Lisp as the basis Lisp... do Clojure and Scheme have regional dialects that let them say what CLOS says, or what the condition system says, with minor changes?)

As I said at the top I don't think it matters that much, when people talk about "a Lisp" I just assume they mean something with an s-exp syntax and macros, when people talk about "implementing Lisp" I assume they mean "implementing [a] Lisp" but I kinda wish they meant Common Lisp. Such a loose definition raises the question why other langs are described as Algol-like or C-like and never "an Algol" or "a C", or a dialect of either, but whatever.

I think perhaps to some degree, people read "Lisp stands for LISt Processing" and internalize this as a kind of shorthand (in spite of any formal naming), so it becomes natural to call any language that operates primarily through lists, and represents source code directly as nested lists, "Lisp".

As an essayist I've found the abstraction of thinking in terms of "lisp" being about "list processing" to be very helpful when reasoning about and abstracting ideas precisely.

Lisp can have almost zero syntax, so can last a long time and be picked back up quickly, I've found.

This doesn't necessarily mean lines-of-code is the most productive immediately; as much as there is resistance to it from current (i.e., 2018March17) mainstream programmers, hyperdimensional programming (i.e., 2D+, and higher in VR) like with Unreal Engine 4's Blueprint, are likely going to win out with pure advancement of results, perhaps (that is, creating effective art quickly).

Imagine finessing functions of different shapes in VR, rather than lines of text code.

Good list. I'd add macros and the conditions mechanism for error handling. The latter still has no analogue in other languages.

> The latter [the conditions mechanism for error handling] still has no analogue in other languages.

Could you explain this for a non-Lisp person? (I have some understanding of macros already.)

The CL condition system separates the signaling of a condition (of which errors are a subtype), the handling of a condition, and the definition of recovery strategies (restarts).

Instead of unwinding the stack when a condition is signaled, handler code is invoked in the dynamic context of the signal and thus has much more information available to decide how to recover.

If a decision on how to recover can't be made programmatically, the system kicks out to the user where they are presented with the choices you have given them.

See: http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h... for more.