Food for thought for Christmas

41 views
Skip to first unread message

Trygve Reenskaug

unread,
Dec 8, 2017, 5:09:29 AM12/8/17
to DCI-object-composition
Hi All,
I have been contemplating abstraction hierarchies and found some fun analogies.
When I wrote my first programs in 1957, it was on a von Neumann machine. Each of its CPU instructions were hard wired with vacuum tubes and gates and such.  Then, as now, a program was an executable sequence of CPU instructions.  There was one opaque abstraction barrier:  Hardware/CPU instructions. New programming languages were new ways of specifying the executable sequence of CPU instructions, but they did not change the fundamental model.

Some years later, hardware was much simplified by only reifying primitive operations called microcode. Each and every CPU instruction became implemented in microcode as a microprogram. There were no facilities for writing application programs in microcode; applications belonged on the CPU instructions above. We now had 2 opaque abstraction barriers: hardware/microcode and microcode/CPU instructions. The arrival of various assemblers and high level programming languages did not change this picture: A program was still a sequence of CPU instructions.


History appears to repeat itself. A special application program harness CPU instructions to define a virtual class machine. Examples are the Java and Smalltalk runtime systems. An object is an instance of a class and the class defines the object's external properties. We get a third opaque abstraction barrier: runtime system/classes. Where microcode defined the properties of CPU instructions, the class with its byte codes defines the message interfaces of objects. As with microcode, the class offers no facilities for composing a program as a sequence of messages across objects. A class definition is the microcode of objects.

DCI introduces a fourth opaque abstraction barrier: object/message interface. An object is now an entity that has a globally unique and immutable identity and that encapsulates state and behavior. It is accessed from its environment through its message interface. Its inner construction, e.g., its class, is invisible and irrelevant. A program is an executable sequence of messages. The isolation from the primitive layers of classes, CPU instructions, and microcode is complete. Programs with IOT etc. can do it differently, our top level is ignorant of implementation details such as classes and such.

With mainstream O-O programming, "it's clear that code won't reveal everything about how a system will work" (GOF). Huge and unreadable application programs are written in the microcode of objects. No wonder it's hard to get them right. No wonder they are open to attack from evil-doers.

The Context is the computer and the  Interaction is he program of the future!

Merry Christmas and a Happy New Year to you all!
--Trygve




--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
mailto: try...@ifi.uio.no
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

Reply all
Reply to author
Forward
0 new messages