[klibertp]

> which is a nice Lisp

Well, it's definitely a Lisp; however, I don't think the "nice" qualifier fits here.

Clojure has a few interesting features which are well integrated with each other, but it also comes with a lot of opinionated choices one might not like. Another thing - not a language issue per-se - is that relying on Java ecosystem can be painful (and ClojureScript, fortunately finally bootstrapped a while back, is not quite the same language).

Personally, I feel that, in pursuit of simplicity, Clojure dropped a lot of useful features. As an example, in both CL and Racket, you have 2-3 times more ways of structuring your code than in Clojure. This is important, because different parts of a codebase benefit from different structuring mechanisms - and the more choice you have, the easier it is to find the right one. In Clojure, all you have are maps and defrecord, with the latter being almost never used.

Of course, you have macros to combat this, but then you're put in the shoes of language inventor and implementer, which is a lot more complexity than most programmers would like to fight just to be able to order the function definition the way they want.

To summarize: in my opinion, Clojure did some things right but then got locked into that single track and refused to incorporate additional features (and lessons learned) from other Lisps. So no, I don't think it's a "nice Lisp." OTOH, it may well be a good language, especially if your problem and domain are a good fit for it.

[lispm]

It might be a nice language but not an especially nice Lisp. Lots of stuff from Lisp is missing: interpreter and compiler integrated, self hosting compiler written in Lisp, condition system with interactive error handling, nice object-system like CLOS, simpler numeric tower, good error messages, Lisp-like stack traces, image-based development with fast startup times, Tail Call Optimization, continuations, ... plus it has some strange design decisions with basic list data structures.

It's 'Lisp'-like where the basic primitive list processing has been replaced with a different higher-level data structure (persistent sequences) built on top of an alien infrastructure which leaks through everywhere and which was not developed for interactive programming (the JVM)... That was one of its original design decisions: being hosted on top of the JVM.

[TeMPOraL]

> It's 'Lisp'-like built on top of an alien infrastructure which leaks through everywhere...

Given it's Lisp (CL in particular) that's "built with alien technology"™, I'd say Clojure is built on top of terran architecture, with the usual human stuff leaking everewyhere... ;).

[aerique]

Would Common Lisp be Zerg or Protoss technology?

[TeMPOraL]

Xel'naga.

[dang]

> some strange design decisions with basic list data structures

What are those?

[lispm]

Hopefully a Clojure user will correct me, but something like (1 2 3) has a single printed representation for slightly different data structures. You can construct something which prints as (1 2 3) and when you read it, then it is something else.

  user=> (list 1 2 3)
  (1 2 3)
  user=> (list? (list 1 2 3))
  true
  user=> '(1 2 3)
  (1 2 3)
  user=> (list? '(1 2 3))
  true
  user=> (cons 1 '(2 3))  
  (1 2 3)
  user=> (list? (cons 1 '(2 3)))
  false

It might not be a big deal, but from a language design view I would expect the single most important external data structure representation in Lisp - a list - is not overloaded with different data structures, where basic operators give different results. I personally would also think that in Lisp the predicate list? is fundamental and returns true for everything which looks printed like a list.

Common Lisp has a related problem for arrays: there are some attributes of arrays which have no printed representation. One will read an array back, but it might lack some features - like not having a fill-pointer. But atleast ARRAYP will still return true.

This seq/list thing might not be a big deal in practice, but it's another design wart. The language has in several places names, which are fundamental in Lisp and which mean something totally different now. Like 'atom'. Since the concept of a Lisp atom no longer applies - remember we have seqs, not linked conses - the name was reused to mean something different. atom used to mean (not (consp thing)) now it is something else.

[rpeden]

The way I usually read Clojure,

   (1 2 3)

isn't the printed representation of a list. It's just the printed representation of a sequence, which could be a list, a lazy seq, or others.

I'm not a Clojure expert, but when I use it, it looks like everything that responds to seq? prints in brackets. And so I tend to think of a seq as the fundamental, most important data structure in the language, and think of a list of just one kind of seq. And following from that, the seq? predicate is fundamental and returns true for everything that prints like a seq - which includes lists.

So maybe this seq primacy means it would be more accurate to call Clojure "Lisp like" or "a Lisp descendant" rather than "a Lisp"? I'm not sure.

I like Clojure, I like CL, and I tend to use and enjoy them both without worrying too much about taxonomy. Having said that, it's totally fair and important to ask the questions you asked!

For me, though, the answers to those questions don't make me like or dislike Clojure or CL more or less relative to each other. They're both fun and useful, and I'm glad they both exist. :)

[kbp]

Clojure isn't Lisp because it doesn't run Lisp programs and has different syntax and semantics to Lisp. McCarthy's original Lisp, Lisp 1.5, Maclisp, Emacs Lisp, Zetalisp, Common Lisp, EuLisp, etc, can share nontrivial programs written for each other with little to no modification; that's why people talk about them as versions of the same language. That doesn't hold at all for Clojure.

That isn't a complaint about Clojure at all, Clojure is a really cool language and does some things better than Lisp, but it's just not a Lisp, it's a Clojure. It borrows some syntax from Lisp in the same way that Java borrows some syntax from C, and it makes about as much sense to refer to Clojure as Lisp as it does to call Java C.

If you want to say that Clojure uses sexprs for source representation, say that; if you want to say that Clojure has dynamic typing and lexical closures (the latter of which most Lisps have not had), say that. Calling it "Lisp" to mean whatever handful of features that you personally think are the defining elements of Lisp doesn't aid clear discussion.

[rpeden]

That's a reasonable way to look at it, and I think we mostly agree. I personally don't call it anything other than Clojure. :)

[lispm]

Call it Seqp. ;-)

[rpeden]

Works for me. :)

[dang]

Thanks! Super interesting.

Of course the meaning of (not (consp thing)) for atom is classical, but don't you think it's a bit weird? It always struck me that way. In a language where lists were the only composite data structure (i.e. not being a cons means being a number or a string or a symbol), it made sense, but that meaning degrades once you have vectors and hashtables. Those are no more deserving of the name 'atom' than lists are. Indeed if one indulges in the oxymoron of treating atomicity as a spectrum, vectors feel more atomic to me than lists while hashtables feel less atomic.

[kbp]

Older Lisps didn't tend to have strings as a separate datatype, they just used symbols and there was a function EXPLODE (and similar) for turning a symbol into a list of one-character symbols (or fixnums), and a corresponding IMPLODE (and similar) for combining them again, and that's how string processing was done. Vectors and hashes predate "real" strings in Lisp as far as I'm aware.

[lispm]

The older Lisp (60 and before) talked about 'atomic symbols'. ATOM checked whether something is an 'atomic symbol'. Cons cells were not atomic symbols. They were pairs. But atomic symbols could be symbols, numbers, functions and variables. Arrays were not there in an explict form and the few data types of Lisp were made of atomic symbols. A number was an atomic symbol where the name starts with a digit and the symbol's assoc list stored the numeric value...

See: http://www-formal.stanford.edu/jmc/recursive/node4.html