Yoda Master tells understands he you not, inheritance naked can be how, you clarify please asks he to.
2009/10/31 Magicloud Magiclouds <magicloud.magiclo...@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 <loupgaroubl...@gmail.com> > wrote: >> 2009/10/30 Peter Verswyvelen <bugf...@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@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe