[pavelludiq]

Obviously you haven't seen the lisp ads from the 80's :) Lisp was surely hyped then. Not to mention all the hype from people like ESR and PG. Even clojure owes part of it's success to the great presentation skills of Rick Hickey and the other early clojure adopters. Languages DO succeed mostly because of marketing, if it was features, then smalltalk would have won, and C++ and Java never would have existed, Lisp would have won and python, ruby and perl would have been forgotten. Even other technologies works that way too, NeXT and the other Unixes would have won, and windows would have never had a chance if what you are saying is true.

As for the name, if clojure was named anything that had the word "lisp" in it, like "foo lisp" or the like, it would have been dead already. Even racket had to get rid of the word "scheme" from their name for marketing reasons.

[bitcracker]

> Obviously you haven't seen the lisp ads from the 80's :)

I studied computer science in the 80's. Maybe that there were some business ads of Lisp (especially Lisp machines). But I had the strong impression that Ada was much more hyped than Lisp. Where is Ada today?

> if it was features, then smalltalk would have won

It depends on how "features" is defined. C won over Lisp and Smalltalk because of the single feature of performance. At the time when C was invented hardware was very expensive.

> Even racket had to get rid of the word "scheme" from their name for marketing reasons.

Racket is a different language. Scheme (R6RS etc.) is a subset of that.

According to your logic Rust will have no chance at all. We will see.

[hga]

Trust us, Lisp was hyped (I worked for "the other Lisp Machine company" in the early '80s). Albeit perhaps not as much as Ada.

One big thing to consider about the normal Lisp and Smalltalk implementation style vs. C and Clojure by virtue of it running on top of the JVM (and CLR, and for the Javascript version I hope it inherited a lot of this) is that the former are "take over the world" approaches, back in those days and still a lot today (e.g. SBCL) implemented by dumping an image to memory and restoring that when you want to run it.

Whereas C is very much a building blocks approach, and within the JVM Clojure is as well. E.g. for the latter the popular Leiningen tool uses directives like

  :dependencies [[org.clojure/clojure "1.4.0"]

                 [clj-time "0.4.4"]
                 [etc.]

And known repositories to pick up the corresponding .jar files. Java and any other language that fits into the JVM ecosystem is an equal player on the JVM with Clojure, and it defers to Java for things the latter already does quite well enough.

This sort of approach, which in the case of Java and Clojure is NOT Worse is Better/The New Jersey Way, seems to have survival characteristics.

Hard to determine how much this was a factor vs. performance, C being a general purpose portable assembler. After UNIX(TM) and C grew up on tiny machines, we then largely squeezed into barely larger ones, the 8086 and 68000 based ones when DRAM was still pretty dear. Or for "engineering workstations", I'm told a non-common, although not all that good configuration early on was one Sun with a hard drive and 2-3 diskless ones all sharing the drive.