> Clojure is a Lisp. One of the distinctive things about Lisp is that it has dialects.
When one of those dialects is completely source-incompatible with every other dialect (the rest of them share non-trivial programs freely), and doesn't share the same core features as every other dialect (like list structure), then why is it still a dialect and not a different language? Calling all the other Lisps that share core features and run the same code different versions of one language makes sense to me; I don't see the point in applying it to any language that borrowed a couple ideas.
If I have a large codebase written in (any) Lisp, will porting it to Clojure be significantly easier than porting it to Javascript or Ruby or any other modernish language? Not really; it's a complete rewrite either way. That sounds to me like it might just be a different programming language.
> the rest of them share non-trivial programs freely
Heh. Most Scheme dialects don't even have source compatibility despite implementing the same standards.
Common Lisp lets you write portable (between different CL implementations) applications, but it's easy to end up doing something that is implementation-dependent if you're not careful.
> it's easy to end up doing something that is implementation-dependent if you're not careful.
I wouldn't say that. I've done a fair amount of porting code between CL implementations, and it's usually pretty straightforward. Implementation dependencies tend to be found only in code doing OS-y things like threads, external processes, network sockets, etc. This code is usually not difficult to find, and I would think that the authors would have expected it to be implementation-dependent. Computational code usually ports with zero effort, even when the machine word size changes.
> Clojure is a Lisp. One of the distinctive things about Lisp is that it has dialects. You wrote your comment using software written in another of them.
I also wrote other comments on other sites using software written in PHP, what does that have anything to do with anything mentioned here? I guess it proves that you can use Lisp to write forum software. Still, not really related to my main question.
Slightly off-topic, I should mention that I've read most of pg's articles several times over the years. I know about Arc, Viaweb, etc. I'm asking about this topic after having read all those articles.
> The youngest of the companies you list was founded in 2007. The first stable Clojure release was in 2009.
Ok, then some other big company founded since 2009. It's been already about 9 years, there should be some around. I can wait for examples. Those companies can use any dialect of Lisp invented since the 50's :)
I know quite a few people employed working on Clojure. It's true that none of them are spectacularly large corporations, but there are quite a few companies out there using it day to day.
Ok, Clojure is a lisp-1 like Scheme, CL is a lisp-2.
Clojure is not based on CONSes but you have CAR and CDR they are first and rest. Processors are no more based on accumulator and decrement registers... :D
Cons exists but it works only on lists as CONSes doen't exists in Clojure, only lists.
Empty list != nil.
Clojure is based on immutability like Scheme, CL is often used in a mutable way (see the shameful f-set).
{}, [], #{} are syntactic sugars and have already been implemented in CL.
Clojure is an hosted language, so Clojure, ClojureScript, ClojureCLR can be somewhat different, but the core language is the same (same base Clojure library).
> Clojure is not based on CONSes but you have CAR and CDR they are first and rest.
CAR and CDR are operations on conses, so you can't have them without conses; that's like having sqrt without numbers. Lisp has FIRST and REST for operating on lists, and so does Clojure. Lisp also has CAR and CDR for operating on conses, but as Clojure doesn't have conses, it doesn't have CAR and CDR, either.
> Processors are no more based on accumulator and decrement registers
CAR and CDR were named for 'contents of address part of register' and 'contents of decrement part of register', not anything about accumulator or decrement registers. I'm not sure where you heard that processors don't have accumulators anymore, but that's definitely not true. The reason Clojure doesn't have CAR and CDR doesn't have anything to do with obsolete processors, though.
> Clojure is based on immutability like Scheme
Scheme is not based on immutability.
> CL is often used in a mutable way (see the shameful f-set).
Do you mean SETF? FSet[0] is an immutable data structure library for Common Lisp. A lot of Schemes have SETF, too, by the way, there's even an SRFI[1]. But SETF is just so that you can have one generic assignment operator; standard Scheme has plenty of commonly-used, destructive assignment operators like set-car!, set-cdr!, vector-set!, etc.
> Literal constants, the strings returned by symbol->string, and possibly the environment returned by scheme-report-environment are immutable ob jects. All objects created by the other procedures listed in this report are mutable.
> {}, [], ...
These characters are reserved for the user in CL and have been used for a bunch of different things.
Is it really? If we go back to the roots, lisp is made of what John McCarthy calls the Primary S-Functions which are atom, cons, car, cdr, and eq (a.k.a =).
Of these five, clojure only has two (atom and eq)
The youngest of the companies you list was founded in 2007. The first stable Clojure release was in 2009.