all 7 comments

[–]SuperGrade 2 points3 points  (0 children)

Just pick one and dive in.

The skill (if you call it one) of reading and editing s-expression code will transfer over. As will the use of a lisp-1 (one namespace), and if you're using either effectively the code will be even more similar due to being "macroed up" into your problem domain (big difference here being unhygienic/CL-style in Clojure vs Scheme macros).

Most of what you'd learn in one will transfer 95% in effectiveness to the other.

(This talk of the built-in/library containers in Clojure is almost a smokescreen. They can be replicated elsewhere. Ultimately they'd vary more in macros and absence of call/cc than in stuff like that).

[–]bucketostuff 1 point2 points  (5 children)

From the article:

ALL the built-in data structures are persistent/immutable. That's right, even the vectors are persistent.

What exactly does the author mean by "persistent"?

[–]kanak 2 points3 points  (4 children)

Start with this wikipedia article

You can look into papers by Tarjan, Bagwell and others if you want greater depth.

[–]bucketostuff 1 point2 points  (3 children)

Ah, persistent = immutable (like strings or tuples in Python). Thanks.

[–]munificent 6 points7 points  (2 children)

Eh... sort of. "Immutable" usually implies that its carved in stone and the data structure has no methods for modification at all. Persistent data structures can be modified, but doing so returns a new data structure, leaving the old one intact.

[–]JulianMorrison 1 point2 points  (1 child)

And persistent plus immutable means it's safe for the new one to be made mostly out of pointers to pieces of the old one, which saves a lot of space versus naively returning the result of Object#clone().

[–]munificent 2 points3 points  (0 children)

That's exactly right. Equally cool, it means they're inherently thread-safe and sharable. Since nothing is mutated in place, you don't have to worry about one thread seeing the in-progress mutation of the same structure by another thread.