On Tue, Sep 15, 2009 at 11:42 PM, Charlie Kester <[email protected]> wrote: > On Tue 15 Sep 2009 at 13:51:44 PDT Amit Uttamchandani wrote: >> >> On Tue, Sep 15, 2009 at 09:33:22PM +0200, markus schnalke wrote: >>> >>> You have the separation in the operation system then. Single >>> independent programs take the place of classes. You can combine them >>> to larger programs. >>> >> >> Again I agree here but how is this accomplished? Through UNIX pipes? How >> do you transfer data between these programs? Do you use something like >> inter process communications? Sockets? > > Yes, or something like 9P. (Beat you to it, Uriel!) > > Does anyone nowadays still remember the lessons of the structured > programming paradigm that preceded OOD? It's amazing how well the Unix > approach exemplifies the structured design virtues of modularity, > decoupling, cohesion, etc. The OO stuff *tries* to achieve the same > virtuosity, but doesn't succeed nearly as well.
Actually OO suckcedes(sic) very well in archiving the opposite: tight coupling due to complex and convoluted interfaces just look at all the Java and C++ 'frameworks' and other such abominations, porting code that uses them to any use anything else is basically impossible. Languages that support duck typing ameliorate this somewhat, but with duck typing interfaces between components become vague and ambiguous, even when you have a duck, you don't know if it will be asked to cuak or to moo until you send it down the rabbit hole. The python File 'interface' is often held as a great example of duck typing, but it illustrates its failure: yea, there are many interfaces that take a 'File-like object', but without actually looking at the code it is almost always impossible what aspects of the byzantine standard Python File object interface will be used, and in what conditions, basically it means that the implementation details regarding what aspects of the File interface are used and how become part of the external interface, but are only specified implicitly in the code that implements the interface, which makes it hard to use the interface with any certainty without actually looking at all the code, and makes it very risky to change the code that implements the interface, as it will easily alter the interface and break any code that uses it. And this is all before we take into account OO's archetypal feature: *inheritance*, inheritance by design violates every possible principle of decoupling and modularity, it makes goto and camefrom look like paragons of modularity and separation of responsibilities. Peace uriel
