[remontoire]

> There is more to collections than lists. You can have instances of empty collections, some of which have literal support ([], {}, and ()). Thus there can be no sentinel empty collection value.

Probably my favorite feature over common lisp. Combined with comma (,) being treated as whitespace (ie, use comma if you want to but you don't have to), makes typing out data structures in clojure a much more enjoyable process than other languages.

This ease of typing out data structures also extends to edn (clojure's version of json)

[fiddlerwoaroof]

This isn’t really a thing, though: Common Lisp has built-in literal syntax for n-dimensional arrays and structs and libraries like fset provide literal syntax for Clojure-style immutable data structures.

[remontoire]

I've used fset and cl21. The problem is that once you start using those you no longer are able to use libraries. Data structures have to be built into core.

The common lisp community has rejected reader macros for interop reasons the last time I checked (in the case of cl21)

Even the docs for fset doesn't show the use of data literals. it does things like (set) and (isetq s2 (set 'c 1 "foo" 'a 'c))

This pretty much proves my point. it's not fun typing (set 'c 1 "foo" 'a 'c) instead of #{'c 1 "foo" 'a 'c}. It's also not possible to put those on the wire (easily) for communication between common lisp processes. Breaking the whole point of homoiconicity.

[fiddlerwoaroof]

> once you start using those you no longer are able to use libraries

This isn't true: if the libraries you use are designed to use generic functions for their internals, rather than normal functions. I've written code using custom data structures heavily, with little or no impact on which libraries I could use.

> The common lisp community has rejected reader macros

cl21 is just confusing matters here. Plenty of code uses named-readtables to use arbitrary reader macros.

I don't understand the "interop reasons" you're talking about: as long as you use named-readtables, interop basically Just Works.

> It's also not possible to put those on the wire (easily) for communication between common lisp processes. Breaking the whole point of homoiconicity.

Using the reader on untrusted input is a bad idea in either Common Lisp or Clojure, because both readers can execute arbitrary code. However, there are packages like safe-read ( https://github.com/phoe/safe-read ) and Eclector ( https://github.com/s-expressionists/eclector ) that let you solve this problem pretty trivially in a safe way. Not to mention projects like my cl-edn ( https://github.com/fiddlerwoaroof/cl-edn ).

[remontoire]

It looks like you're right for the most part. Literals are supported if you use https://github.com/vseloved/rutils. If your cl-edn actually works then a combo of rutils and cl-edn could bring most of the value I found in clojure to common lisp.

[kgwxd]

Immutability by default is a world of difference from library support. I think pretty much every language has a library for it.

[fiddlerwoaroof]

Immutability by default is mostly overrated: I’ve written code in many languages (Haskell, Clojure, JS, CL, etc.), and I’ve found I care more whether a library (Immer, ramda, etc.) provides referentially transparent APIs than whether or not the language’s data-structures provide immutability guarantees.

But, additionally, my point was that CL has literal representations for arbitrary data types, not that you can get immutable datastructures from a library.