I think the origins of the "JavaScript is Scheme!" meme have more to do with the fact that you can pretty trivially re-implement all of the code from the Little Schemer (including the applicative order y-combinator) in JavaScript, than any of the reasons mentioned here. JavaScript still, imho, has nicer closures and lambdas than most mainstream programming languages.

Actually, thinking back on it, I remember having a conversation with Prof. Daniel Friedman about how similar the two language are and I believe his response was something along the lines of: if you have the lambda calculus, what else do you need?

Final nitpick: most of the "Y isn't really a lisp!" (another meme) articles I've read always miss what I think is the biggest thing missing from all languages compared to any lisp: symbolic expressions. To me this is the single most underrated feature of lisp that almost no other programming languages offer.

So I think it's worth remembering that it's really a very recent development that we can now treat it as obvious that a language like JavaScript would contain the things it has in common with Scheme.

When I first started thinking about writing this post, I was considering going from the angle of "JS was Scheme when Crockford said that but now every language has caught up and we're all Scheme now" but somehow a different post fell out of my head when I started writing.

And let's not forget great book Higher-Order Perl: Transforming Programs with Programs http://hop.perl.plover.com/

But code generation and execution during runtime, which is what I think you meant, is capable in any language with eval().

Perl claims to have a compilation stage, by which the documentation means that the lexer and parser produce an optree, which the runtime phase traverses. During that compilation stage, it's possible to run code which changes how the parser will treat subsequent syntactic elements.

That's spurious. Anything that can be implemented in one Turing complete language can be implemented in any Turing complete language. The question is how easy it is.

I would never claim that Javascript is scheme (and it doesn’t sound like that’s what you’re claiming), but the things I love about Javscript are also things I love about scheme.

Is it the homoiconic-ness of the s-expressions you like?

Personally, I'd love to see continuations in Javascript, despite the potential for horrible abuse. Deeply nested callbacks are a pain in the ass. Of course, promises are a pretty decent solution.

I was recruited to Netscape with the promise of “doing Scheme” in the browser...

I’m happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients.

https://brendaneich.com/2008/04/popularity/

So "JS=Scheme" is not very crazy. Maybe it oversimplifies. But it's not baseless. And it's short.

Obviously JavaScript isn't Scheme using the author's "top 10 defining characteristics of Scheme." Crockford's analysis is on track - and John Resig and Bear Bibeault highlight the same idea by introducing functions are really fundamental to the languages more than objects (in "Secrets of a JavaScript Ninja").

The language's history does imply the comparison as well. Eich's original mandate was to "write Scheme for the browser" but he was later directed to give his language a C-like syntax and to ride on the coat-tails of the hype surrounding Java.

"JavaScript isn't Scheme" might not be accurate for folks schooled in the finer points of Scheme. It is very useful to those who cut their teeth learning Java.

Anyone trying to draw parallels between Javascript and Scheme isn't crossing some pedantic line, they're off in crazyland. Or, more likely, they don't understand both languages as well as they're implying.

    it breaks the connection between JavaScript and Java.

I think that's too blunt of an instrument to help you reason about any of the languages in question, but I do appreciate encouraging people to think functionally.

That's not true. In fact, there are some prominent people in the Lisp community who do not think that Scheme is a Lisp.

See this thread from 2002 on comp.lang.lisp (especially Pitman and Naggum's comments) for more. If you are too young to have posted on C.L.L when Usenet was still popular, and want to see what a full fledged flame war looks like, look at the end of the thread.

Some people who posted there (including the OP) are on HN.

https://groups.google.com/forum/#!topic/comp.lang.lisp/Bj8Hx...

OTOH Lisps like Emacs Lisp, Common Lisp, ISLisp, and some others are still carrying the core of the first Lisp. Basically you can run Lisp 1.5 code in those without many changes.

Just like Java is not the new C. OTOH languages like C++ and Objective C still support much of C. You can port C to C++ easily.

Over the history many other languages have been trying to replace Lisp: ML (functional programming), Dylan (object-oriented programming), Logo, Scheme, ... all tried to modernize/improve Lisp. Now it is Clojure and some other languages.

Still there are core Lisp languages which carry on the genes.

But not Clojure:

    Clojure 1.5.0-RC2
    user=> (car '(1 2))
    CompilerException java.lang.RuntimeException: Unable to resolve symbol: car in \
    this context, compiling:(NO_SOURCE_PATH:3:1)

    user=> (append '(1 2) '(3 4))
    CompilerException java.lang.RuntimeException: Unable to resolve symbol: append \
    in this context, compiling:(NO_SOURCE_PATH:4:1)

    user=> (assoc 'foo '((foo . 3)))
    ArityException Wrong number of args (2) passed to: core$assoc  clojure.lang.AFn\
    .throwArity (AFn.java:437)

    user=> (atom 'foo)
    #<Atom@2285af04: foo>

Does not look like it supports Lisp processing as defined by McCarthy:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91....

Additionally the Java error messages are especially irritating. I enter Clojure code and get Java error messages.

Compare that with a real Lisp:

    bash-3.2$ java -jar abcl.jar
    Armed Bear Common Lisp 1.1.1
    Java 1.7.0_25 Oracle Corporation
    Java HotSpot(TM) 64-Bit Server VM
    Low-level initialization completed in 0.628 seconds.
    Startup completed in 1.968 seconds.
    Type ":help" for a list of available commands.
    CL-USER(1): (car '(1 2))
    1
    CL-USER(2): (append '(1 2) '(3 4))
    (1 2 3 4)
    CL-USER(3): (assoc 'foo '((foo . 3)))
    (FOO . 3)
    CL-USER(4): (bar 10)
    #<THREAD "interpreter" {6EEE1E2}>: Debugger invoked on condition of type UNDEFINED-FUNCTI\
    ON
      The function BAR is undefined.
    Restarts:
      0: CONTINUE     Try again.
      1: USE-VALUE    Specify a function to call instead.
      2: RETURN-VALUE Return one or more values from the call to BAR.
      3: TOP-LEVEL    Return to top level.
    [1] CL-USER(5): 

Clojure may be a cool language, but the core of Lisp has been replaced in parts with something else. List processing is different. It's now based on 'persistent' lazy sequences...

In Clojure, your examples are spelled:

    (first '(1 2))
    (concat '(1 2) '(3 4))
    (get {:foo 3} :foo)       ; or (get {'foo 3} 'foo)
    (symbol? 'foo)            ; or (not (coll? 'foo))

I'd like to point out that your examples wouldn't have worked in Lisp 1.5 either. You would have had to type, for example,

    CAR (QUOTE (1 2))

Btw., LispWorks, plain:

    CL-USER 23 > CAR (QUOTE (1 2))
    1

http://www.informatimago.com/develop/lisp/com/informatimago/...

Clojure lists aren't lazy, and they support the Lisp operations, under slightly different names, and with the same asymptotic performance characteristics you're used to, because they're made of chained cons cells. The cons operation is implemented at https://github.com/clojure/clojure/blob/master/src/jvm/cloju.... Your "more complex example" is a 1960 program written, originally, in M-expressions; here's the first definition on the cited p.32:

    th1r[v;a1;a2;c1;c2] = [atom[v] → member[v;a1]∨
        th[a1;a2;cons[v;c1];c2];T → member[v;a2]∨
        th[a1;a2;c1;cons[v;c2]]]

    (defn th1r [v a1 a2 c1 c2]
        (cond (symbol? v) (or (some #{v} a1) (th a1 a2 (cons v c1) c2))
              true        (or (some #{v} a2} (th a1 a2 c1 (cons v c2)))))

Compare the above to the LISP 1.5 version:

    (TH1R (LAMBDA (V A1 A2 C1 C2) (COND
        ((ATOM V) (OR (MEMBER V A1)
        (TH A1 A2 (CONS V C1) C2) ))
        (T (OR (MEMBER V A2) (TH A1 A2 C1 (CONS V C2))))
        )))

The set thing, though, points to a real difference in Clojure: it has a set data type, and you're expected to use it instead of the list data type when what you want is a set. It's still immutable, though, and supports efficient nondestructive update, so if you decide to rewrite this as

    (defn th1r [v a1 a2 c1 c2]
        (if (symbol? v)
            (or (a1 v) (th a1 a2 (conj c1 v) c2))
            (or (a2 v) (th a1 a2 c1 (conj c2 v)))))

You could argue that adding sets (and finite maps) to Lisp is violating the underlying essence of Lisp, in which you use conses for everything, but in fact we already have vectors, hash tables, classes, structs, and closures in all of the other Lisps you're citing, none of which were present in the Ur-Lisp in 1960.

ATOM doesn't exist in Clojure, although you can define it. atom does, and yes, it does something totally different from what ATOM did historically.

By "persistent" Clojure means "immutable". That is, there's no RPLACA or RPLACD. But RPLACA and RPLACD weren't present in McCarthy's original proposal, and they're hardly central to Lispiness. You could even argue that their absence is Lispier, since it encourages functional programming and enables the compiler to optimize it better, and indeed Racket already abandoned them a few years back for that reason.

BTW, I was wrong about what you would have had to type at LISP 1.5's read-apply-print-loop. You would have had to type

    CAR ((QUOTE (1 2)))

Of course Clojure sequences are lazy.

    (defn map
      ([f coll]
       (lazy-seq
        (when-let [s (seq coll)]
          (cons (f (first s)) (map f (rest s))))))

They are also not acting like cons cells:

    user=> (cons 1 2)
    IllegalArgumentException Don't know how to create ISeq from: java.lang.Long   clojure.lang.RT.seqFrom (RT.java:496)

What you saw in the file was the source code used by the first Lisp implementation.

> an interpreter

That was no 'interpreter'. Mostly a different reader.

> what you'd write in any modern Lisp looks a lot more like the Clojure version than the LISP 1.5 version.

Not necessarily. See the Lisp source for http://www.shenlanguage.org/Download/download.html

Plain old-style Lisp code.

There are not many modern Lisp books. If you look at PAIP, that is old-style. PCL is more modern. But neither has the look or feel of Clojure.

But I'm not saying that Lisp's don't contain new stuff. I'm saying that they contain the old stuff + new stuff.

Clojure gets rid of core old stuff:

* names are different

* concepts are removed (mutable cons cells, ...)

* syntax is different from every other Lisp

* semantics is different (persistent data structures, ...)

> By "persistent" Clojure means "immutable"

immutable and persistent are different, but related concepts. A data structure can be immutable, but it does not need to be persistent. 'Persistent' means that an immutable data structure can be updated, keeps all its versions and provides certain performance/space characteristics (one does not do full copies for example).

Imagine a list (f o o b a r). Now I want to insert 1 between f o o and b a r.

Immutable: I need to make a new list with elements from the old list copied.

Immutable and Persistent: I make a new list, but I possibly reference parts of the old data structure. Thus I don't need to make a full copy.

Lisp's lists/vectors/... are not immutable and also not persistent.

Clojure replaces that. Just read http://clojure.org/sequences

As for the 1960 code in the manual, no, that wasn't the source code used by the first Lisp implementation.

In the Shen case, I assume you're talking about things like this, in primitives.lsp?

    (DEFUN eval-kl (X) 
      (LET ((E (EVAL (shen.kl-to-lisp NIL X))))
          (IF (AND (CONSP X) (EQ (CAR X) 'defun))
              (COMPILE E) 
              E)))

    - Indentation to show structure;
    - DEFUN;
    - ';
    - IF;
    - LET;
    - some lowercase letters.

Your taxonomy of immutability and persistence is interesting; thank you. I thought you might have meant that Clojure lists were automatically serialized to stable storage on, for example, program exit. Lisp lists have always been persistent, then, except when you mutate them? Because you can make your (f o o 1 b a r) from (f o o b a r) without copying the whole thing in any Lisp.

Lots of Lisps have been backwards-incompatible with previous Lisps. Scheme, Common Lisp, Emacs Lisp, and even MACLISP and LISP 1.5 were all significantly backwards-incompatible with their predecessors. That didn't make them non-Lisp. Common Lisp was not the end of Lisp development.

Right. That's what I'm saying. Clojure does not care to be backwards compatible with Lisp.

> Your taxonomy of immutability and persistence is interesting

That's not mine.

Clojure took its base data structures from Haskell and modern ML.

Not Lisp.

See:

http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

http://en.wikipedia.org/wiki/Persistent_data_structure

The book comes with examples in ML and Haskell.

http://www.amazon.com/Purely-Functional-Structures-Chris-Oka...

How are they not. Okay, I see your argument with Clojure, but how does that apply to Racket?

  Welcome to Racket v5.3.4.
  > (car '(1 2))
  1
  > (append '(1 2) '(3 4))
  '(1 2 3 4)
  > (assoc 'foo '((foo . 3)))
  '(foo . 3)
  >

Epic.

I started posting on Usenet ~1989. I've seen a number of flame fests that I considered epic but this moved the bar exponentially.

I hesitate to ask this question because I really don't want to start a flame war.

http://c2.com/cgi/wiki?LexicalScoping

[1] - Immediately Invoked Function Expressions: (function(){ ... }())

(To be strict, that seems to be more a matter of what a scope is, rather than if the scoping is lexical or dynamic.)

In scheme, lexical scoping is easily accomplished through the let form, and it's pretty hard to make a variable global by mistake.

So yes it does have lexical scoping in the sense that function arguments are lexically scoped, but that's the only scoping environment, and you can't hide that fact behind macros like you could in scheme if it was needed.

There is; it's just ugly. You just have to use an immediate function as the body of the if statement.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It seems like this argument conflates lexical scoping with the requirement that variables be lexically scoped. Lexical scoping (even if optional) is extremely useful for closures. Requiring lexical scoping would very useful for safety.

    function foo() {
      console.log(whereDidThisComeFrom);
    }
    window.whereDidThisComeFrom = "the damn global object";
    foo();

    function foo() {
      var a = {
        whereDidThisComeFrom: "a, of all places"
      };
      with (a) {
        console.log(whereDidThisComeFrom);
      }
    }
    foo();

scheme@(guile-user)> (define (foo) (write where-did-this-come-from)) ;;; <stdin>:1:14: warning: possibly unbound variable `where-did-this-come-from' scheme@(guile-user)> (define where-did-this-come-from "the damn global scope") scheme@(guile-user)> (foo) "the damn global scope"scheme@(guile-user)>

Munificent's assertion that this doesn't represent lexical scoping is wrong, but his assertion in another thread that with() is an exception to lexical scoping is correct, and therefore JS is not lexically scoped, just mostly lexically scoped.

Strict mode in ES 5 does address the first two, and "let" in ES 6 addresses the latter, so that's good. But at that point, you're talking about the future and not JavaScript as it is today.

This is not lexical scoping:

    function example(k) {
        function ugly() {return i};
        for (var i = 0; i < k; i++) {}
        return ugly;
    }
    example(4)() // => 4

The i in ugly is lexically resolved to refer to a particular declaration, the one on the line below it. Scheme's lexical scoping rules are not the only possible lexical scoping rules. A lexical scoping system does not cease to be lexical simply because it is not the same as Scheme's lexical scoping. For it to be non-lexical, the scoping would have to depend on something other than the lexical structure of the program. For example, you could just as well have a dynamically-scoped JS in which ugly's return value would depend on its caller's binding for i, and in which calling a function with a free i from within example would make example's binding for i visible to that other function, but that isn't the way JS works.

It's quite reasonable to argue about whether that scoping is sane, and indeed with "let", the ES folks are giving us a saner binding construct; but it is certainly the case that the relationship between the declaration and the use of a variable is established by the lexical structure of the program text, not the dynamic structure of the executing program.

So probably Javascript was meant to write something like: while(function(k) { ++i; return i < k; });

where the while function would call the closure until it got false at which point the while function itself would return so having var declarations be hoisted was not a problem in this syntax because everything (including if and while) would have its own scope due to being a function

Access to the global object is still statically decidable. It just might raise an exception. This is not really different from Scheme.

I agree that block scope is a defining feature of Scheme's (and ALGOL's, and C's) approach to scope. However, Scheme's block scopes are all functions, at least if you accept the macro-definition of let that's been there since R5RS, rather than treating let as a separate primitive construct.

I think that what you are arguing is that Javascript is statically scoped.

http://www.adequatelygood.com/JavaScript-Scoping-and-Hoistin...

Hoisting generally seems ugly to me.

Edit: I think there is some confusion here about scoping. One axis is dynamic versus lexical scoping (are there other options?). Another axis is function, block, global, etc. scope. They seem orthogonal to me.

Have JS developers taken a bunch of compiler theory terms without understanding them and applied them to Javascript? I have to say, I'm not really surprised...

The level of scope (global, block, ...) interact with the type of scoping in many ways, so I would not say that they are orthogonal. This example would behave very differently under dynamic and lexical scoping.

  function foo() {
    var i = 1;
    function bar() {
        var a = i;
        var i = 2;
        return a + i;
    }
    return bar;
  }
  foo()() // => ?

    In a lexically scoped language I would assume that the scoping follows the lexical representation of the code.

    The variable i is not even defined before it is refered to in the inner function.

    void Foo() {
        i = 10;
        int i;
    }

Incidentally, Javascript made the opposite decision; you can refer to variables before their declaration, they're just "undefined". But in both cases the compiler knows what "i" it's referring to by the lexical scope.

My first argument was that the order of statements is part of the lexical representation of code, and thus should effect the lexical scoping.

In languages like C#, a separate analysis is then done to find out if the variable is definitely assigned at each reference. This can include some sophisticated reachability analysis(how sophisticated depends on the usefulness/complexity tradeoff).

I guess it's all semantics really, but I prefer to keep the scope (ha ha) of lexical scoping rules closer to name resolution than start mixing in definite assignment and reachability analysis and the things that come with that.

It makes understanding and expressing the commonalities and differences between different language's lexical scoping a lot easier. C# is lexically scoped with blocks introducing new lexical scopes. Javascript* and Python are lexically scoped with functions introducing new lexical scopes. As an orthogonal concept, C# and Python disallow references before definite assignment, while Javascript allows it.

(*) With the dynamic 'this' caveat.

    function foo() {
      window.c = "really?"
      d = {};
      function bar() {
        var a = "var";
        {
          with (d) {
            var a = b;
          }
        }

        console.log(a);
      }

      d.b = c;
      bar();
    }

    foo();

Chapter 1: The Early Years: http://www.youtube.com/watch?v=JxAXlJEmNMg

Chapter 2: And Then There Was JavaScript: http://www.youtube.com/watch?v=RO1Wnu-xKoY

JS has inherited from both Scheme and Self.

I think the thing that makes the comparison is more the first class functions than the closures. The closures assist the first class functions, but the functions are the star.

Not a whole lot of non functional programming languages support first class functions with the simplicity and completeness of javascript.

http://en.wikipedia.org/wiki/First_class_function#Language_s...

In javascript, passing functions as parameters is a day to day thing, and that style of being able to pass around different functions as building blocks is what gets it compared to functional languages. Sure, that's not the only thing that functional languages have going for them, but it's the most important thing, and what they're even named after.

But people like to repeat slogans without understanding. This is how everyone is calling Clojure a Lisp, for example, while it is a language of its own, which happen to use parenthesized syntax.)

It is not parenthesis that makes a language Lisp. It is not first class functions that makes it Scheme.) Lisp/Scheme is a set of conventions/features, and when some are broken and other are missing that means it is something else.

This is in contrast to JavaScript, whose creators never claimed it was Scheme or even a dialect, although the author of the article suggests it was influenced Scheme. In addition, he has perceived that lately, many people claim JavaScript is Scheme, and he rejects that claim.

Disputing the validity of Clojure as a Lisp is orthogonal to the subject of the article.

It is possible, for example, to go through some books, especially "The Joy Of Clojure" which contains 20 line of marketing slogans for 1 line of code, and make explicit commentaries on all the subtle differences, but I'm not going to perform such a tedious task for free.)

> "The Joy Of Clojure" which contains 20 line of marketing slogans for 1 line of code

> but I'm not going to perform such a tedious task for free

Well, obviously there's no point in discussing this further and we have to agree to disagree. Have a nice day anyway.

  (define (cross xs ys)
      (cond ((or (null? xs) (null? ys)) '())
            ((atom? xs) (cons (list xs (car ys)) (cross xs (cdr ys))))
            (else (append (cross (car xs) ys) (cross (cdr xs) ys)))))

  (defun cross (xs ys)
      (cond ((or (null xs) (null ys)) nil)
            ((atom xs) (cons (list xs (car ys)) (cross xs (cdr ys))))
            (t (append (cross (car xs) ys) (cross (cdr xs) ys)))))

    (defn cross2 [xs ys]
     (cond (or (and (sequential? xs) (empty? xs)) (empty? ys)) '()
           (not (sequential? xs)) (cons (list xs (first ys)) (cross2 xs (rest ys)))
           true (concat (cross2 (first xs) ys) (cross2 (rest xs) ys))))

But I would argue that this interface is poorly designed, since you can say (cross2 '(a b c) '(1 2 3)) or (cross2 'a '(1 2 3)) but not (cross2 '(a b c) '1), and worse, (cross2 '(a (b c) d) '(1 2 3)) implicitly flattens the (b c) into individual items, which is probably a latent bug rather than desired behavior. So I would argue for writing it in this form instead:

    (defn sc [x ys]  ; scalar cross
          (if (empty? ys) '() 
              (cons (list x (first ys)) (sc x (rest ys)))))

    (defn cross [xs ys]
          (if (or (empty? xs) (empty? ys)) '()
              (concat (sc (first xs) ys) (cross (rest xs) ys))))

Except really, if this isn't a homework problem, I think you should write it like this in any of these three Lisps:

    (defn cross [xs ys]
          (map (fn [x] (map (fn [y] (list x y)) ys)) xs))

One more subtle thing: your solution produces (((a 1) (a 2)) ((b 1) (b 2)) ((c 1) (c 2))) while the contract was to produce "list of all possible pairs".

   (defn cross [xs ys]
          (mapcat (fn [x] (map (fn [y] (list x y)) ys)) xs))

   (defun cross (xs ys) 
          (loop for x in xs
                appending (loop for y in ys
                                collect (list x y))))

I'm not sure I agree on (recur...). You would need to use (recur...) if you were translating tail-recursive code that iterated over something other than a data structure and didn't produce new live objects on every iteration. But the code you gave wasn't tail-recursive, and what it iterated over was a data structure, and every iteration produced live objects that can't be garbage-collected. Even if you rewrote it to be tail-recursive, it wouldn't run out of stack for reasonably-sized output lists anyway; and for unreasonably-sized output lists, it would be likely to run out of heap for the output before it ran out of stack. I'm interested to hear if you manage to get it to stack-overflow. (It seems likely to be possible, but perhaps a bit of a challenge.)

Regardless, I don't think it's reasonable to claim that languages that don't have tail-call elimination — which I suspect you may be on the point of doing — aren't Lisps. Many popular Lisps have had TCE, but many more Lisps haven't, and the CL standard doesn't require it.

Python, for example: def cross(xs, ys): return [[x, y] for y in ys for x in xs]

LOOP in disguise :) (at least to my (very possibly faulty) understanding.)

    (defn cross [xs ys]
      (for [x xs, y ys]
        [x y]))

This definition seems to exclude Common Lisp from being a Lisp. That might be a defensible position, but it does call into question how your definition of "Lisp" is useful to you. It also seems to exclude languages like Dylan, which are commonly regarded as Lisps by people far cleverer than me.

> What is a lisp?

It's a very good question. I think PG sums it up quite nicely in "Revenge of the Nerds" [1]. Although, now that I'm thinking about it, I'm not quite sure there's any point in classifying something as a Lisp or not...

[1] http://www.paulgraham.com/icad.html

Again, Lisp could be defined as a limited set of conventions/features. As long as some other features, such as CLOS added there is no problem, but if some features are broken, then it is not Lisp anymore. It is just doesn't walk like a duck.

Let's say that Clojure was developed with a "put everything useful together" or Ruby-approach, if you wish, which is very popular for scripting languages, while development of Scheme and other Lisp dialects was founded on "put only what is absolutely essential, and done right".

The first approach "stuff anything in" you could see almost everywhere. The second approach "research first, and do the best" is unpopular for the obvious reasons and could be rarely seen only in masterpieces, such as Gambit-C, nginx, old-school marvels such as Informix.

So, in my opinion, Clojure is much closer to Ruby than to Lisp (let's not be deceived by parentheses) - it is a scripting language (to quickly put everything together with variety of clever special syntax and fancy data-structures without much thinking about implementation details). This is, of course, most productive approach to coding - this is why people love scripting languages so much.

Your suggestion of "let's say ..." is based in what appears to be complete lack of familiarity with all of the languages involved. Providing useful libraries doesn't preclude having done things right. Supplying a bare minimum of libraries does not preclude having made them miserable. There are plenty of awkward moments in using Common Lisp libraries that have made this plain to me.

Your suggestion that "research first, and do the best" is unpopular for "obvious reasons" is just hand-waving. The "obvious reasons" that are left unstated here are that "research first and do the best" languages general suck, hard. They suck because they sit in toy environments for years while the "release early and iterate" languages flourish under constant adaptation to real world usage. Both will have warts. The latter will be worth using.

Suggesting that "Clojure is closer to Ruby that Lisp" is just silly. What lisp? Scheme and Common Lisp, both definitely Lisps, are easily as different from each other as Clojure is from either. Ruby's insane class monkey patching is closer to the type of advice you find in Common Lisp than the immutable datatypes and carefully conceived concurrency primitives found in Clojure. Common Lisps many different name classes are a horror found in few modern languages. There's nothing in Clojure's "clever special syntax" that many developers did not toy with using reader macros and other abominations. Your suggestion that the olders lisps data structures, usually cobbled together with a pattern of lists and a prayer, are somehow more thought through than Clojures is both ignorance and meanness combined. Yes, Common Lisp had many builtin and library added datatypes. No, it didn't stop alists and structure built from underlying alists from being its fondest love.

As for classifying Ruby and Clojure as "scripting" languages, please define "scripting" language. It's a meaningless term for nearly anything other than `bash`.

The differences between, say, Scheme and CL are few and subtle - #' and funcall syntax, behavior of nil, etc. all the foundational special forms and general function application rule are the same.

Of course, CL is a much bigger language, but all its features never broke the basis on which everything is founded - a few special forms, list structure, general evaluation rule with exceptions only for these special forms, each of which follow its own rules.

Most of CL's features are macros and libraries, so they do enrich the base language, without breaking it up.

https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

Most Common Lisp implementations have their compiler written Common Lisp. The language is implemented and extended in Common Lisp.

Well, the official website doesn't help much by itself calling Clojure a (dialect of) Lisp.

http://clojure.org/

The only other time I heard someone saying "Clojure is not Lisp" it wasn't in order to say something nice about the former.