Ah, you're mixing up Clojure and Lisp. The restrictions in Clojure have nothing to do with Lisp tradition.

Someone used to a Lisp-like language will also struggle with Clojure.

Traditional Lisps like Common Lisp are multi-paradigm languages in which variables and most aggregate types are mutable.

They are not hard to pick up for someone with a background in C.

C has pass-by-value functions; so does proper, traditional Lisp.

C has mutable variables, arrays and structures; so does Lisp. Lisp data structures like lists or hash tables are easily understandable by a C programmer with a good background in data structures.

cons is like malloc-ing and filling-in a two-field struct, except that freeing is taken care of.

People have written Lisp systems in C (and written more than one book on that exact subject: Nils M. Holm just put a new one out: http://www.t3x.org/lsi/index.html), with a lot of the internals being written in C over the Lisp library functions. E.g. visiting and printing the elements of a list can literally look like this, in the internals of a C-based Lisp implementation:

   for (val iter = list; list; list = cdr(list))
     print(car(list));

Dynamically typed. As a dynamic language Clojure is less capable than many other Lisp implementations/languages. See for example 'late binding'. In Clojure you either need to define a function before its use or need declare it. Not that 'dynamic'. In a typical Lisp dialect the order of definitions makes much less a difference, since functions can be called late-bound. For an interpreter-based implementation, it makes no difference at all.

> It promotes combinations of built-in data structures (lists, maps, vectors) over objects

An aspect I don't like. This makes debugging of larger systems more difficult, since maps are maps. Whereas objects have a type tag built in, have a list of allowed fields, etc. etc. They simply have more more explicit and standardized structure to them.

> Some built-in features like reducers and transducers rely heavily on composing higher order functions for transforming other functions.

Which makes code complex, since transducers are a mildly complex mechanism.

> It encourages REPL-based development

In relatively weak form. Basic features of Lisp need to be added to do simple tasks: like 'instrumenting' code to debug it, since it lacks an interpreter or more capable compiler support. REPLs with actual interactive error handling are not standard. Interactive Lisp compilers like the one from SBCL give much more information and warnings.

Thus the Lisp development features are at best only medium-level.

> Historically, Lisp programmers weren't the biggest proponents of OOP

Funky, people from the Lisp community helped to shape OOP and explored much of it. From guys like Hewitt who developed the actors paradigm in the early 70s, Minsky who developed the frame theory mid 70s and inspired a whole range of OO programming in Lisp, to Howard Cannon who developed Flavors in 1979 with flexible mixins and multiple inheritance used to implement the object-oriented operating system parts of the MIT Lisp Machine, to Lieberman who developed OOP with prototypes mid 80s, to Kiczales who worked a decade on OO in Lisp (LOOPS, CLOS, Meta-object Programming, Object-oriented Protocols, Meta-level architectures, early Aspect oriented programming, ...).

Actually objects in the early Lisp were simply symbols with their property lists. These property lists could hold both normal attributes and also functions.

I have definitely seen this. I'm not sure that I understand this sentiment. The only thing that Clojure is missing is the "system" feel that Common Lisp provides, with things like character macros, symbol macros, etc.

That being said, I definitely appreciate how thought through Clojure is, especially when compared to CL. Several things are missing/don't feel well thought out in CL (notion of a `calleable` type is gone, `nth` isn't defined on vectors or strings (but you can still `length` them!) nor is `first` and `rest`) That provides a great deal of friction.

> Programs have to be re-architectured, because the concepts are different:

"Re-architectured" can be read in a multitude of ways. Changing a few datatypes because Clojure prefers vectors instead of lists, etc., feels like it falls well below the bar for "re-architectured".

> no TCO, but 'functional'

This would hold weight if CL mandated TCO, but it doesn't.

With this in mind, I'd like to examine a few of your points from a different angle:

Racket:

- Basic concepts are the same, (atom, linked lists, '...')

- Restructuring not really needed (up for debate, depends entirely on your prefered initial design choices in either language. Racket isn't that opinionated.)

- Tail call optimization required as per Scheme standard, so is present. Note that this is not actually something Lisp mandates.

- Doesn't 'care' about side effects, community is pragmatic and will generally advise you to do whatever is practical

- Has an object oriented sub-language with message passing and so on

There are a lot of points here that, according to you, makes Racket essentially a Lisp, even your non-point about TCO. I'm curious to know what you feel about people saying Scheme is a Lisp, considering the above.

The whole debate of "Is X (a) Lisp?" reminds me of nationality debates that essentially boil down to some people saying blood is more important than culture. You seem to be taking both sides, however; arguing culture and blood (source code). You cherry pick the cultural differences like most people standing on one side of the nationality debate would and argue that just those specific differences are the most important.

That's the thing, though; Swedish people could argue however much they want that they're very different from Norwegian people. To the rest of the world, though, they're essentially the same. Especially when you start comparing them to people from Peru, Venezuela, South Africa, and so on. When you're in the bubble the very small differences are much bigger to you, but if you zoom out to get some perspective these differences are much smaller than the commonalities.

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...

I don't know but if I had to guess, it's because lisp is list processing language, and Clojure doesn't really support lists (I mean, it's possible to make some, but there are none out of the box); instead it has a variety of trees that mimic the runtime performance of lists, arrays, hashes, etc.

>> only abstraction is a linked list

> What language are you referencing here?

They are referring to Lisp.

You are not stuck with anything in Common Lisp.

Instead of loop you have lots of options, from the built-in constructs (do, dolist, map...) to very powerful libraries like SERIES and ITERATE.

You are not stuck with the default hash table interface either. Many libraries for data structure are available, you just pick the one that suits you best.

>And then Clojure implemented Map literals and - what do you know - Clojure still has Lisp Macros!

Most of those Clojure features are already available in CL through the use of libraries. Even the ability to easily call Java libraries, by using the Armed Bear Common Lisp implementation.

I can write ugly code in any language. But if I was writing this code in Clojure, I would probably do something like this:

  (let [r1 (- (* b b) (* 4 a c))
        r2 (+ (- b) (sqrt r1)))
        r3 (* 2 a)]
    (/ r2 r3))

Yeah, you may say that I needed to introduce other variables to make this work and the code got bigger as a result, but on the other side how many people are actually writing this kinda of code on daily basis that are not Computer Scientists?

it's always better to ask than to make incorrect assumptions

I disagree. I rarely find myself slowed down by the grammar or operator precedence in Java and C#. In C++, only when I have to do something rather esoteric (pointer-to-member, member function template specializations, etc.).

On the other hand, I critically rely on types. The IDE is able to narrow down suggestions about applicable methods to a handful. But since `js->clj` is a function `string -> map` (a very generic signature), there must be hundreds of them with the same signature. Context-sensitive discoverability with the help of IDE becomes nearly useless.

Yes, that's how I learn APIs these days. Types, intellisense + reading the documentation to learn about possible edge cases. I cannot imagine being productive in something like Clojure.

I also find Java 11 + VAVR rather pleasant to work with.

Unlikely.

Clojure. The language is built around immutable data structures with the expected interface for maps and vectors, and the idiomatic list-churning we're both referring to is unified through the sequence abstraction. So switching from a vector to a map can often be as simple as switching constructors. Because they're immutable, every operation makes a "copy" but does so efficiently.

I don't have a lot of use for Clojure these days but I enjoyed working with it. Rich Hickey is a smart fella.

Having syntax for 4 different data structures instead of just one would be one of my main reasons. Also, the syntax of a lisp-1 is cleaner.

Clojure's syntax and semantics are quite different from Scheme and Common Lisp:

https://clojure.org/reference/lisps

https://www.more-magic.net/posts/thoughts-on-clojure.html

Most differences are due to design choices, not merely JVM nuances. A few differences are due to JVM limitations at the time that Clojure was designed.

I don't think any attempt was made to comply with a Scheme spec.

I don't understand what you mean here, the lack of infix operators in Lisp? You make it sound like prefix notation is inferior. But given how Lispers usually sell it as the best thing since sliced bread, such reactions don't surprise me.

Anyway, you're right. It really seems like C-style syntax has won, and deviating from that is certainly a barrier of adoption. Clojure has been remarkably successful despite this, but I really don't see it becoming the next Java.

That feeling may be the result of some questionable syntactic design decisions in Clojure.

Hickey went over Lisp syntax and tried to remove parentheses wherever possible. (It was the hip thing, PG's Arc did it, too, which may be where Hickey got it from.) As a result, you get a sub-par editing experience —generic sexp-based structure editing doesn't get you as far as with a Lisp— and diminished readability once you get above three omitted pairs of parentheses in a row.

On the other hand, Clojure arbitrarily mandates a secondary kind of list literal in some places of the syntax, again making Clojure harder to write and edit. I don't even see a readability benefit, but of course YMMV.

TL;DR: Clojure syntax is a "complected" derivative of Lisp :-)

Yes and no. The fact that the language is a list (which is the same data structure that you use to manipulate value) is what makes it that powerful. Once you start adding more syntax, then it's not a list anymore.. so you can't just pass that code to your macro and it becomes trickier.

For instance, you could receive your AST, manipulate and return it, but now you're getting into implementation detail about how the lexer and parser are working. Compare that with lisp where you get a list and you return a list. The fact that your code is your AST is that makes it so magical.

I understand that the lisp syntax can throw someone off guard when they're used to seeing obj-c or javascript. But honestly, it's much simpler and easier to get to than, say, get familiar with C++ if you're a java programmer.

One problem that I see with Lisp is that since everything looks the same, it's hard to quickly parse it when reading a file. I feel like reading a Python file is really fast because it's separated in classes / method, or even the methods are clearly separated in "paragraph". While in lisp, everything has the same syntax and to know what's happening you need to read almost every line. Basically, I feel like it's lacking visual clue. Clojure fixes that a little bit by adding a few more data structure.

The other problem that I see with Lisps are that code abusing lambdas is hard to follow. I.e. In python, lambda are used for very short functions. But in Lisp, most people nest lambda in lambda in lambdas and often don't even use good variable names or variable name at all. Lisp code feels "write-only" to me. That being said, this is more of a mentality than a language problem because it's easy to define internal functions rather than nesting everything. Similar to how javascript can be one giant pack of nested functions or well defined functions with good variable names.

</ end of rant.

All that being said, I think Arc (And other lisps) are amazing and I'm sad that they're not more popular.

I haven't used Clojure macros but as a programmer that uses both C and Common Lisp, I can say with good authority that C macros and CL macros are very different.