Comment by iLemming
4 days ago
I don't have great experience of using CL for analyzing data, because of "why?", if I already have another Lisp that is simply amazing for data.
Clojure, unlike lists in traditional Lisps, based on composable, unified abstraction for its collections, they are lazy by default and literal readable data structures, they are far easier to introspect and not so "opaque" compared to anything - not just CL (even Python), they are superb for dealing with heterogeneous data. Clojure's cohesive data manipulation story is where Common Lisp's lists-and-symbols just can't match.
Homework assignments notwithstanding, very few serious Common Lisp programs use lists and symbols as their primary data structures. This has been true since around 1985.
Common Lisp has O[1] vectors, multidimensional arrays, hash-tables (what Clojure calls maps), structs, and objects. It has set operations too but it doesn't enforce membership uniqueness. It also has bignums, several sizes of floats, infinite-precision rationals, and complex numbers. Not to mention characters, strings, and logical operations on individual bits. The main difference from Clojure is that CL data structures are not immutable. But that's an orthogonal issue to the suggestion that CL doesn't contain a rich library of modern data structures.
Common Lisp has never been limited to "List Processing."
I wasn't trying to denigrate Common Lisp, I'm sorry if I hurt your feelings. It does have comprehensive support for all kinds of data structures. I wasn't talking it being limited to "list processing". SBCL is great for many things, but from many practical points Clojure actually much better suited for data analysis.
You're saying: "hash-tables (what Clojure calls maps)" not only inaccurate, you're hand-waving Clojure's core design philosophy (immutability, structural sharing, lazy sequences) as orthogonal. But those aren't cosmetic differences - they're the reason why Clojure's data structures are fundamentally better for data analysis. I think you're confusing "having equivalent data types" with "solving the same problem the same way"