@gfredericks thanks, I guess thats the difference between runtime specs for cljs

@flyboarder the same applies to clj-jvm

makes sense

@alexmiller @seancorfield what's wrong with encapsulation, from the colujarians' world view? 🙂

I don't recall a very convincing blog post, or have just forgotten if I saw one

Oops should have moved it to #off-topic

Anyway I am very happy about spec, it is really a "missing piece" for robust programs that teams can collaborate on

@matan in OO (particularly thinking of Java / C++ here), encapsulation is used to hide or protect the data inside an object and access it via methods. Because this data is mutable, the accessor/mutator methods are also a place where you can apply a locking strategy to protect that mutable data in multi-threaded usage.

Clojure turns this inside out and says, data is actually the most important thing here - make it visible, introspectable, and directly manipulable via a generic data interface, rather than via a custom set of API methods that is different for every class.

Immutable data structures allow you to do this while also being automatically thread-safe and avoiding the need for locking around access and manipulation of mutable data completely.

even more than thread-safety, you get independence of usage -- you can pass the same object to different pieces of code and not worry about what things they will each "change" that might affect the other which may or may not be what alex's last sentence meant

@alexmiller to make data explicit and visible is undoubtedly a good thing, but there is definitely situations where encapsulation is valuable https://github.com/clojure/clojure/blob/clojure-1.9.0-alpha14/src/clj/clojure/core.clj#L4939

core.async channels and go blocks are another good example of encapsulation

Go blocks are about process, not data. Channels are about conveyance of values, not encapsulation

sure, but they both have opaque internal state

which doesn't make them bad primitives, btw

I get your point, but "encapsulation is bad" goes a bit too far imo

Agreed, but I didn't say that

Most encapsulation in OO is incidental, not useful

this is not quite the same topic but it just occurred to me that one of my biggest frustrations with legacy OO codebases that I haven't heard articulated before is that the classes I encounter have unclear lifecycles

the thing I want to understand about a class to help me understand the whole codebase is how/why the objects get instantiated, what you do with them while they're alive, how they get discarded, how that relates to the lifecycle of the program as a whole; and I've never seen an OO codebase where that's remotely clear

perhaps there's a similar question about how functions are used in a functional codebase, but it seems like less crucial of a question for some reason

“lifecycle” implies some degree of statefulness to me. mutable state requires coordination. all of that is often a mess in OO.

although I’d say that aspect is a distant second problem for me after the notion of not having a generic data interface and/or clear equality semantics in OO

the "no generic data interface" complaint also applies to type-oriented functional programming (haskell etc.), right?

I haven’t done enough of it to say

that feels like the biggest difference to me between clojure and most of the rest of FP, even more than static vs dynamic type system

though I'm sure the static vs dynamic dimension is highly correlated with generic vs typey

yeah not having equality, robust hashing and string representations built into your data structures is terrible

I had a giant dump of ruby data the other day and would have appreciated being able to read it into a repl and analyze it, but I just had to decide to not want to do that

one of my complaints with clojure is actually that the default string representation isn’t EDN — this decision confuses me. e.g.

(println {:foo "bar"})
{:foo bar}
=> nil

i use prn-str for everything, so it’s not a big deal

i guess not all clojure data can be represented as EDN because of nested Java objects, but why not quote “foo” above?

because then (println "foo") would be surprising

you'd need some other mechanism for printing a raw string

ah yeah, that makes sense

i guess you could special case strings inside of collections

that would bother me even more

but that might be a personality thing; some people like things that are less complicated to describe, others like things that are more likely to do what you wanted

well said. i lean towards the former too

ironically, now that I think about it, I feel like gripes about clojure are pretty evenly split between people wanting the former and getting the latter, and vice versa

a good knife’s edge to balance on =)

I suppose there are also gripes about situations where neither ideal is achieved

@alexmiller: Is there a place on the http://clojure.org site that would make sense for compiling links to blog posts, videos, and other external resources related to spec? There's a bunch of good ones on the Cognitect blog and elsewhere that I wouldn't know how to find if I were looking at it for the first time.

Depends what they are

The community/resources page is one place but may not be best for everything

@spieden Just to make sure it's said: pr does exactly what you want.

The docs actually say: > By default, pr and prn print in a way that objects can be read by the reader

@shaun-mahood give me examples and I can help find answers

@potetm yes thanks