2010/12/20 Tim Daly <d...@axiom-developer.org> > > > On 12/19/2010 10:53 PM, Ken Wesson wrote: > >> On Sun, Dec 19, 2010 at 10:33 PM, Tim Daly<d...@axiom-developer.org> >> wrote: >> >>> On 12/19/2010 10:21 PM, Ken Wesson wrote: >>> >>>> On Sun, Dec 19, 2010 at 9:42 PM, Tim Daly<d...@axiom-developer.org> >>>> wrote: >>>> >>>>> On 12/19/2010 9:24 PM, Ken Wesson wrote: >>>>> >>>>>> On Sun, Dec 19, 2010 at 8:25 PM, Tim Daly<d...@axiom-developer.org> >>>>>> wrote: >>>>>> >>>>>>> On 12/19/2010 8:20 PM, Ken Wesson wrote: >>>>>>> >>>>>>>> On Sun, Dec 19, 2010 at 8:18 PM, Tim Daly<d...@axiom-developer.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I didn't mean to imply that other people >>>>>>>>> don't have the "ah-hah!" experience with >>>>>>>>> other languages. However, I have only had >>>>>>>>> the (before lisp)|(after lisp) experience >>>>>>>>> with lisp. >>>>>>>>> >>>>>>>>> Your enlightenment might vary. >>>>>>>>> >>>>>>>>> Rich gave his "Whitehead" talk and brought >>>>>>>>> up the fact that OO languages get several >>>>>>>>> things wrong. >>>>>>>>> >>>>>>>> Out of curiosity, which "several things" were these? >>>>>>>> >>>>>>> http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey >>>>>>> >>>>>> "Please install Flash Player". >>>>>> >>>>>> Has everyone on this list developed a sudden allergy to plain text and >>>>>> HTML? First I get pointed to a 34-minute video, and now this. A simple >>>>>> bulleted list with a brief precis about each item would have sufficed; >>>>>> a multi-megabyte install of an executable and who knows how much >>>>>> futzing around, overkill. >>>>>> >>>>>> The points made by Rich in the video require context. >>>>> Besides, the only way I could make a bullet list would >>>>> be to listen to the video again. My memory is hopelessly >>>>> lossy. >>>>> >>>> Exactly why text is preferable to video for stuff that can be >>>> expressed in text. Your memory wouldn't matter -- you could link to >>>> the text. And Google could search inside it. >>>> >>> Ah. So, like the confused situations you get with Java's mutable >> >> collections. Two lists are equal if they have the same contents in the >> same order -- but then you use one as a key in a hashmap, and then add >> an item to it, and boom! Clojure separates this stuff out because the >> Clojure vector's immutability makes its value stable given its >> identity. Refs and atoms and agents can encapsulate mutable state, but >> their identity (as defined by = and hash) is fixed rather than >> changing with its state. And some objects (keywords and symbols) exist >> to be almost pure identity, used to label other things. >> >> Something like that? >> >> Ummm. no. You're approaching the question in an OO mindset. > There is no path from that starting point to Rich's insight. >
I disagree, it /is/ "something like that" : in clojure parlance : * a value is an immutable object (and beyond that, also a /persistent/ datastructure for performance reasons). Clojure datastructures are the classical building blocks for creating values. * an identity is represented by a "ref" in clojure : an ref, an atom, an agent. An identity is an object representing "something" which can have different values at different points in time. * a "state" is a pair "identity/value" at some point in time. Refs and atoms and agents can also be considered as values, and can be embedded in other refs. But then, the "value" you must consider is just their "identity", not their "changing over time" flux of values. All of this is pretty much the same as for relational databases. Once you get the technical id of a table row, you've a stable pointer for the identity of a concept. The values of the concept may change over time, though. And yes, languages which allow uncontrolled mutation of class instances fields generally will "conflate" those notions of identity and state, making it more difficult, for example, to write correct concurrent programs because it's much harder to work on a "consistent set" of the values of an object. Anyway, Ken, this video really is worth watching when you have the time to. > > Rich spent the better part of an hour trying to explain the > insights that he got from what must certainly be months of > reading and thinking. I'm part way through the Whitehead > book he mentioned (and the other book is on-order). That's > some heavy reading he's been doing. I also downloaded the > primary paper on Multiversion Concurrency Control. > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.5778&rep=rep1&type=pdf > > And, no, I don't plan to summarize Whitehead or the MVCC paper :-) > > @mike, Yes, a video isn't "documentation". But the MVCC paper > certainly is. Open source software doesn't seem to "do" documentation > (which annoys me also since I'm a literate programming fanatic). > > > Tim Daly > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
