Is Dualism the future of programming ?

Mind vs Body in 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.
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.
Values in Object systems at Ubilab -- Explains why Values are good.
http://c2.com/cgi/wiki?ValueObject
http://en.wikipedia.org/wiki/Immutable_object
Mutable or immutable? in javaworld.com

Solution

Implementing value semantics in object oriented languages can be tricky.

What does Barbara Liskov have to say about Equality in Java? by Reg Braithwaite
Equals and Hash Code for Java, by Manish Hatwalne
Navigating the equality maze of Ruby, by Paul Butcher
Reference and value semantics. Part of C++ FAQ Lite, Marshall Cline

Read/add 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

PAGE PRECEDENTE