[Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Magicloud Magiclouds]

Somehow, I agree with you.
I think inherit is not evil, the people use it wrong is. The problem
here is, inherit is naked right now. So people could use it wrong.

On Fri, Oct 30, 2009 at 7:42 PM, Yaakov Nemoy <loupgaroublond at gmail.com> wrote:
> 2009/10/30 Peter Verswyvelen <bugfact at gmail.com>:
>> The following is purely my own experience, I have no links to papers
>> of clever people :)
>>
>> I think none of the inheritance techniques work perfectly. E.g.
>> describing everything with OO interfaces (=a extensible record of
>> function pointers) is also problematic IMHO, at least when you have
>> side effects.
>>
>> The problem with an interface (with side effects) is that people using
>> the interface tend to depend on the side effects that a particular
>> implementation of that interface performs. So in order to describe the
>> "contract" for implementers of an interface, one often has to go into
>> great detail.
>>
>> Also in Haskell it is required that an implementers follows the
>> "contract" when implementing a type class, e.g. when writing a monad,
>> you must make sure it follows the monad laws. But  at least in
>> Haskell, this can be proven, while in OO, one has to hope that the
>> side effects of an implementation won't cause weird behavior
>> elsewhere. In practice, this seems to work, most of the time :)
>>
>> The evolution of industrial OO the way I see it, is strange. You start
>> with assembler, in which it is obvious to extend records. Then comes
>> C, which makes extending records hard to do without casting and
>> macros. Then C++, which offers insane ways of extending them (virtual
>> base classes, multiple inheritance, mixins using templates, ...). Then
>> to make software components more loosely coupled and maintainable,
>> Corba & COM enters the picture, and you only use interfaces to
>> communicate with other objects. Of course COM uses reference counting,
>> so reusable components is actually just an illusion; in order to avoid
>> memory leaks, you need to know how objects are connected, which
>> depends on the implementation... In the meantime Java becomes a
>> succes. Java is basically "back to basics": it tries to address some
>> of the flaws of complicated OO, has garbage collection, promises
>> multi-platform caps, and it is very easy to understand, so people
>> embrace it. Then C# comes along, which initially is almost the same as
>> Java, except is has closures, but it evolves towards a functional
>> language with side effects (even Haskell's FRP will be available in
>> .NET 4.0, with the Rx framework!). Then to manage large and
>> complicated software, things like "dependency injection" and
>> "inversion of control" are introduced, and... we're basically back to
>> COM in a sense, but now with garbage collection.
>>
>> So I have the impression that OO is running in circles, and every
>> iteration tries to pick up some goodies of the previous one, but where
>> will it end?
>>
>> Luckily humans seem to have the ability to get things done, whatever
>> primitive or flawed tools we get. I guess the brain itself it the best
>> programming language ;)
>
> Looking at this from a feedback circuit perspective, it seems like
> that industrial programming is just swinging back and forth between
> two extremes. It appears that at every step someone runs into the
> limitations of doing things one way and finds a way to orthogonally
> combine other designs together. For example, there's been alot of work
> on implementing other languages on top of Java, such as Jython, so
> different programming methods can be mixed into enterprise Java code.
> It all swings back and forth because more than one design and paradigm
> is needed and no single language can really support it all at once.
>
> -Yaakov Nemoy
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
竹密岂妨流水过
山高哪阻野云飞