Re: [dev] Conversation with Anselm R. Garbe of suckless.org

On Tue, Sep 15, 2009 at 11:42 PM, Charlie Kester <corky1951_AT_comcast.net> 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
Received on Wed Sep 16 2009 - 04:05:56 UTC