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

[Eugene Kirpichov]

Yoda Master tells understands he you not, inheritance naked can be
how, you clarify please asks he to.

2009/10/31 Magicloud Magiclouds <magicloud.magiclouds at gmail.com>:
> 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
>>
>
>
>
> --
> 竹密岂妨流水过
> 山高哪阻野云飞
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru