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/

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!