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.