Fork me on GitHub

@viebel I'm copying an excerpt of a discussion between Fogus and Rich. I think it explains well the advantage of using maps to represent information over objects.

When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications. Clojure eschews this and instead advocates a simple associative model for information. With it, one can write algorithms that can be reused across information types.

This associative model is but one of several abstractions supplied with Clojure, and these are the true underpinnings of its approach to reuse: functions on abstractions. Having an open, and large, set of functions operate upon an open, and small, set of extensible abstractions is the key to algorithmic reuse and library interoperability. The vast majority of Clojure functions are defined in terms of these abstractions, and library authors design their input and output formats in terms of them as well, realizing tremendous interoperability between independently developed libraries. This is in stark contrast to the DOMs and other such things you see in OO. Of course, you can do similar abstraction in OO with interfaces, for instance, the java.util collections, but you can just as easily not, as in .

Fogus: Can you expand on what you mean by "simple associative model for information"?

Hickey: Most classes used to represent information are just bespoke associative maps of named properties/attributes to values. But in the customization process we usually lose the ability to treat them like generic maps. This then precludes the writing of generic information manipulation code, since such code requires the capability to generically access/modify/add properties by name/key, enumerate properties, etc. An associative information model retains and emphasizes those capabilities.


FYI, also available in this collection of many talks by Rich Hickey and others:


Thanks. Too bad github doesn't allow fined-grained addressing here.


You mean to a particular range of lines in such a file? I don't know how to do that for these file formats, but you can always copy and paste text, or say "search for the first occurrence of these words in this page" if you want to refer to some small part of it.


> Too bad github doesn't allow fined-grained addressing here. You can click Blame and then the addressing feature appears again 🙂

Yehonathan Sharvit16:03:11

@U963A21SL Are you copying this piece in order to correct something in my article or in order for us to get a broader picture on the importance of generic ways to represent associative pieces of information?


To add to my point that the use of generic abstraction is interesting in terms of reuse/interoperability and especially powerful when representing static information. I feel like those are the real selling points of the approach as opposed to saying "use maps everywhere because it makes your system less coupled" which I think is not as convincing as what Rich says in this interview (and wrong in my opinion but that might depend on what you mean by coupling).

Yehonathan Sharvit16:03:56

I think that the rationale behind Rich’s idiom “just use maps” goes in the opposite direction. First, Rich explains why it makes sense to represent business related information with maps (that’s one of the main points in almost each of his talks). Then, Rich explains that even for algorithmic level code “just use maps” is a good practice.