Objects before behavior … continued

Now I have to define or limit the scope of application. I am here talking about enterprise operation management applications. The application that the companies support or run their businesses.


The hard core of programming is complex management. When one must keep track of business processes then OO is at least one magnitude more effective that any functional or procedural of course with the assumption that the coding is correctly produced!


The overall complexity can be divided in two subparts. Local complexity and its global aspect. A given domain functionality has a given intrinsic complexity. Here the local complexity is inversely proportional to its global part. This means that when one decreases local complexity at the same time one does increase global one. I have used APL programming language. It is an executable matrix algebra syntax. It was locally extremely complex – compact. The difficult with that was that only 10 % of Cobol programmer had any chance understanding it, but in hands of a master it was frighteningly powerful and productive.


Local complexity is easy to recognize because it can be seen in one o two pages of code but global complexity is insidious because it is really difficult to detect. This complexity steams from purely from number of combinations. The procedural languages gives too much freedom for programmer which ends up a mess.


This is why object with their association gives an almost isomorphic mapping from reality and thus enables to implement each behavior at most once. Their blessing is the restriction the put to a programmer. As I earlier said the prerequisite of this is that the development is done model driven and the implementation is strictly 3-tier. This meas that the application layer ( GUI , GUI- interactions, work flow control) is strictly separated from domain layer and business functionality.


I actually deeply understood this after reading Stuart Kauffman’s: Home at the universe. (http://www.amazon.com/At-Home-Universe-Self-Organization-Complexity/dp/0195111303/ref=sr_1_1?s=books&ie=UTF8&qid=1349817326&sr=1-1&keywords=at+home+in+the+universe+by+stuart+kauffman )


I warmly recommend this to all that truly.

Then when we consider really complex processes from reality, not only mathematics then the von Neumann architecture is not enough. For this reason big player have already for some time been developing new computing machine architectures that are simulating neurons and brain. ( see: http://www2.dac.com/events/videoarchive.aspx?confid=122&filter=keynote&id=122-120–0&#video )


Finally here is little bit more on complexity: https://jukkatamminen.wordpress.com/2011/08/01/managing-complexity/

Objects before behavior – the most fundamental OO concept.

There has been for some time now at least some debate about functional languages. These are declarative in nature. In these the actual processing is defined by describing the logical predicate that the result must fulfill. Thus this brings the computing near mathematics. I have seen many times attempt to declare that computing is mathematics. Most probably one can do mathematics with computers but computing (ie. programming of application) is very far from any mathematics.

My viewpoint to computing is business operation control. In other words the company’s application portfolio reflects the state on the reality within the company and gives to the worker of the company a possibility to monitor and manage the business actions. In this domain – that actually is the great majority of all IT of companies – the amount of complex computing is non-existent. There are also some complex calculation done somewhere but I am not familiar with these but here we are talking about complex calculators.

When I teach the basics of OOA, I will start with looking how we perceive the world. Well here is the core of that:

The reality, the whole world consist purely of material things that we can generally call “objects”. ( see. The first few page of Ludvig Wittgenstein: “Tractatus Logico-Philosoficus”). So everything is object and there are layer of objects within objects. This way the concept is highly abstracted and gives us the intersection of what is the smallest common denominator in the reality. What is the common thing in all objects? The answer is uniqueness of objects. We all are unique this is materialized by a common attribute: ID. To the uniqueness is loosely connected the fact that there is no object in the whole universe that is eternal. So every single object is bound by the time. The consequence of this is the every object shares two attributes: time of birth and time death. This way every object is created and destroyed in one way or an other. In an OO model these basic facts are reflected in class model. A life of on object is a continuum of state transitions – the states that are realized as values of that objects attributes.

Now we get to the issue. All action or behavior is always performed by someone or something. So every action has a subject – ie. someone behind the action – an actor.

OO- paradigm uses this fact very effectively. In OO there are no unbound action, function or other behavior. The realty is modeled by two types of behavior: internal and external. Internal is behavior that a single object produces and external behavior can be called collaboration. Well of course this requires that a fight of what ever type between objects is one kind of “collaboration”. Collaboration is objects internal action and messaging between objects.

SO when we try to mirror some part of local reality the minim complexity is achieved with this kind of one–to-one mapping (or homomorphism if you want to put it into mathematical terms). In this kind of implementation every function is implemented at most once. This is never the case if all the behavior is not bound in objects. Of course you can break this role also with object if you want, but it is easier to detect to be avoided. This yields absolute minim complexity solutions within von-Neumann machines.

On other finding after creating a few of these is that the business method within the business object are almost without an exception stupidly simple. If one is looking for really complex behavior it includes learning and it can not be ever achieved with von-Neumann machines but needs a neuron based architecture ( see:

http://www2.dac.com/events/videoarchive.aspx?confid=122&filter=keynote&id=122-120–0&#video )

Art of programming – the ultimate design expression of an application

The programming languages that I myself have programmed with are in chronological order: Fortran, Cobol, Pascal, APL, Smalltalk and Java. The one that I have been write real production code are: Cobol, APL, Smalltalk and Java.

 I don’t know how many languages there actually exists. There was a presentation at JAOO- conference in Århus Denmark 2008 named “50 in 50” by Righard p. Gabriel and Guy L. Steele Jr .They went trough 50 programming languages in 50 minutes.

 Thus the only common thing over all these languages is that they can be either compiled or interpreted to executable machine code.

 Then there are two categories of programming languages: procedural and object-oriented. The categories also form both chronological and evolutionary layers. Most procedural languages have been created before 1980. The transition is not sharp but gradual but ParcPlaces Smalltalk-80 is a watershed or marker. This was also a fundamental paradigm change.

 Procedural languages are primitive syntaxes to facilitate expressing of algorithms. The thinking behind OO- languages are fundamentally different. In these the behavior is design as a seen with actor call “objects” and the total behavior is a mixture of various objects internal activity as well as their external activity: collaboration with each other by messaging. I like to emphasize here the concept “collaboration”. This is substantially more that the term “communication”.

When I after doing about half a year OOA got my first Smalltalk environment at first it was really hard to overcome the procedural thinking even as I was very aware the theoretical OO concept.

My production Smalltalk was ParcPlace’s VisualWorks. It was actually an Smalltalk programming environment not just an interpreter and how we learned to love it. It was just fantastic compared to anything I have worked with earlier. This was around 1995. Then came along Java, which was in its infancy. I was furious. When we finally had to switch over we almost concretely stepped back 5 years! Todays Java IDEs like Eclipse are fairly at the same level where Smalltalk was 1997.

When I consider OO -languages they are fro me just dialects of Smalltalk. The core language syntaxes have only some cosmetic differences and actually the real differences come from class libraries. These are not part of language but part of environment. So I would say that Java,C+,Objective C and Eiffel is a dialect of Smalltalk. Scala, Rubi and C# are dialects f Java.

The sad thing is that too big portion of the people programming with OO- languages does know too little or no the underlying OO- theory and thus uses it very poorly. When we were using Smalltalk, at first I thought that the language itself prohibits programming procedurally. The I attended a Smalltalk conference where a Smalltalk guru told us that he has come across first procedural Smalltalk program. It actually had a call with name MainProgram! I was both terrified and furious!