I think that's focusing on the non-unique parts of Clojure. Clojure was a product of the 2000s, a generation of interop-focused FP languages (Scala, F#, and Clojure foremost among them) that were deeply influenced by the functional programming languages of the 90s (mainly thinking of Haskell and OCaml here). Immutability and FP are not the new things that Clojure brought to the table. While Clojure transients are a fascinating tool and derived from its implementation of immutable data structures, otherwise its immutable data structures are roughly in the same ballpark as other languages. And parameter ordering is something that I think Rich has walked back occasionally (I remember a talk at some point where he talked about his skepticism of the entire idea of parameter ordering vs just named parameters or its equivalent, e.g. passing in a map).
Clojure's main shtick (at least its main influence on me) is a combination of image-oriented programming (that is a live REPL that lets you edit a program you're writing on the fly without needing to restart the program) with a strong distrust of any abstractions that extend beyond immutable collections (Clojure's mantra of focusing on data).
This combination is a bit unique. You had some of the latter in "classical" Haskell (that is Haskell from the 90s and 2000s that was quite skeptical of user-defined typeclasses compared to modern-day GHC Haskell where some codebases use typeclasses out the wazoo), that emphasized using algebraic data types over typeclasses and higher-order functions and demanded that any typeclasses had associated laws. OCaml still has a lot of that today.
Then you had other languages with the former, such as Smalltalk and Common Lisp. But those two languages never really treated immutable collections as essentially the end-all-be-all of abstractions (certainly not Smalltalk where the idea of independent data is almost antithetical to its premise!). This is definitely an exaggeration; Clojure does have facilities for other abstractions and being an FP language it certainly has higher-order functions, but the community shies away from those as much as possible.
But Clojure in my mind is the first to marry those two ideas together and see how far things can go.
Clojure's main shtick (at least its main influence on me) is a combination of image-oriented programming (that is a live REPL that lets you edit a program you're writing on the fly without needing to restart the program) with a strong distrust of any abstractions that extend beyond immutable collections (Clojure's mantra of focusing on data).
This combination is a bit unique. You had some of the latter in "classical" Haskell (that is Haskell from the 90s and 2000s that was quite skeptical of user-defined typeclasses compared to modern-day GHC Haskell where some codebases use typeclasses out the wazoo), that emphasized using algebraic data types over typeclasses and higher-order functions and demanded that any typeclasses had associated laws. OCaml still has a lot of that today.
Then you had other languages with the former, such as Smalltalk and Common Lisp. But those two languages never really treated immutable collections as essentially the end-all-be-all of abstractions (certainly not Smalltalk where the idea of independent data is almost antithetical to its premise!). This is definitely an exaggeration; Clojure does have facilities for other abstractions and being an FP language it certainly has higher-order functions, but the community shies away from those as much as possible.
But Clojure in my mind is the first to marry those two ideas together and see how far things can go.