++Mind vs Body in programming Is Dualism the future of programming? I like the RubyLanguage. Yet, I feel strange with the motto "In Ruby everything is an object". On the contrary I believe it is useful to pretend that some "things" are Objects and some other "things" are Values. Maybe I am not a Materialist. Let me explain. + Objects vs Values What is the difference between an Object and a Value? It's like the difference between material things and immaterial ideas. Objects must live in some body/place/container, whereas Values can live in multiple "minds" simultaneously. ++ Objects As I first read in a Grady Booch book a long long time ago, an Object has 3 main characteristics: # an *Identity*. A unique /identifier/ that makes it possible to "reference" a specific unique Object # a *State*, that can be represented using a *Value*. That state/value may or may not change over time # a *Behavior*, that defines how the Object will react when some "method" is invoked. Often the behavior depends on the "class" of the object (the "class" is part of the value). ++ Values Example of values include so called /primitive/ values like integers and floating point numbers, strings, dates. Some languages extend the notion to tables, lists, records, etc. But the notion of *value semantics* goes deeper, it relates to the idea that a value is an "in extenso" description of something (whereas a an object is that something itself). Values exist the way ideas exists, not the way a physical thing exist. Values are... # are *immutable*. They cannot change, they cannot "mutate". That means that the Value's value never changes! If string "ABC" is a value, then "ABD" is a different value. There is no way "ABC" can turn into "ABD". # are intrinsically *unique*. Integer 3 "exists" once only, there are no two integers 3, there never will. Values are neither created nor destroyed, they simply are, always have been and always will be. # are *self-identified*. Ie. the Value's identity is the Value itself. ++ An over simplification? Because Object Oriented languages use objects to represent values, they kind of hide the difference between Objects and Values. Everything becomes an Object. This is presented as an advantage. It is some kind of an "unification", a beautiful simplication. Well... really? Maybe it is an over simplification. I am asking because some of these languages later reintroduce the notion of "value semantics". Sometimes there are two "equality" operators. One for identity equality (are two object identifiers referencing the same object?). Another one for Value equality (are two objects representing the same value?). Some other times there will be a String class for example, and a MutableString class (or a StringBuffer/StringBuilder class maybe). As a result Values become second class citizen. They become a special case among all objects, the Immutable Object case. So, yes one can represent a value using an object, but the ideal/immaterial essence of the value gets lost. Why does this matter? + Only Values are multi-core friendly We are entering a time where parallel processing is becoming increasingly necessary to improve performances. That is why the distinction between Values and Objects is relevant. Values are friendly in a distributed non shared environment: # Values are light and fast. Values are naturaly cacheable. A value's computerized representation can be copied as much as one wants, there will never be a need to synchonize the copies. As a result accessing values is local, hence fast. # Mutable Objects are heavy and slow. Objects need a "home". That is the place where the object is stored. The place is not ubiquitous, it hosts the true and only Object. If there exists local cached proxies, they must be kept in synch with each others somehow, and this is costly. Functional programming, like in ErlangLanguage for example, is a nice thing. But pure functional programming, with no side effects, with only immutable values instead, is... a brutal paradigm shift, at best. Are we going to forget about Object Oriented Programming ? I don't think so. ++ The Fertile Paradox of OO Languages Some languages have both "by value" and "by reference" parameter passing schemes. But "Pure" object oriented languages are expected to provide only one mechanism: a "by reference" parameter passing, where references are object identifiers. The difference between "by value" and "by reference" becomes of paramount importance when the caller and the callee live in two different address spaces, maybe on two different computers. Cannotical Object Oriented languages have only "by reference". But, but, at some implementation level they actually pass Values: Object Identifiers. ++ Object Identifiers are Values! That passed Value is the /id/ of an object, a /reference/ to it. That's an added level of indirection. Call it an Oid, a Pointer, call it a Reference, at the end it is a kind of Value (hence immutable, unique, self identified). But these languages deny the existence of such values, claiming that "everything is an object". Maybe "everything is an object" but then what is the reference to an object? Is it an object or a value? That is where there is a paradox: If everything is an object, then what kind of object is a "reference to an object"? The truth is that not everything is an object, because references to objects are not objects, they are Values. ++ Nice consequence As a consequence, a language claiming "In xxxx everything is an object" seems extreme to me. I want something in between, where there are Objects and Values, with a clear understanding about what these two species of data have to offer. That request is legitimate, because Values are not second class citizen. I bet I am not alone. Future languages will provide native support for Objects /and/ Values. Some possibilities include: * *Thing Oriented Programming* would be the Top. In such a programming orientation, Value is the norm and Object the exception, versus the opposite in Object Oriented Programming. * A *Value* base class and mixin. To make it super easy to create objects with value semantics. * An *value* method. It would freeze forever the value of an object, so that further processing can optimize things and treat the object as if it were a value, an immaterial idea versus an material thing. It is the #freeze Ruby method. There even exists an evil #unfreeze http://eigenclass.org/hiki/evil.rb+dl+and+unfreeze * A *incarn* method. That would create a *new* mutable object from an idealized value. Is it the #dup Ruby method? * A *value?* method. That tells apart objects from values. Like Ruby #frozen? maybe? Maybe, probably, some languages already offer these possibilites. I get to find them. ----- Ressources: * B. J. MacLennan. “Values and Objects in Programming Languages.” ACM SIGPLAN Notices 17, 12 (December 1982). Page 70-79. * www.riehle.org/computer-science/research/1998/ubilab-tr-1998-10-1.pdf Values in Object systems at Ubilab -- Explains why Values are good. * c2.com/cgi/wiki?ValueObject * en.wikipedia.org/wiki/Immutable_object * www.javaworld.com/javaworld/javaqa/2002-12/01-qa-1206-immutable.html Mutable or immutable? in javaworld.com * bjouhier.wordpress.com/2010/05/15/objects-values/ Objects and Values – A conceptual model, by Bruno Jouhier ----- + Solution Implementing value semantics in object oriented languages can be tricky. * http://weblog.raganwald.com/2007/04/what-does-barbara-liskov-have-to-say.html What does Barbara Liskov have to say about Equality in Java? by Reg Braithwaite * http://www.geocities.com/technofundo/tech/java/equalhash.html Equals and Hash Code for **Java**, by Manish Hatwalne * http://www.texperts.com/2007/10/16/navigating-the-equality-maze/ Navigating the equality maze of **Ruby**, by Paul Butcher * http://www.parashift.com/c++-faq-lite/value-vs-ref-semantics.html Reference and value semantics. Part of **C++** FAQ Lite, Marshall Cline ----- Read/add http://virteal.tumblr.com/post/18981088 comments Category AboutProgramming, JavaScript Misc. I am getting old. I apparently wrote about this in 2004, http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/119917 @jhr - @jhr - @jhr - a visitor - @jhr -

Your name maybe: