2009/9/14 Amit Uttamchandani <atu13...@csun.edu>: > On Thu, Aug 06, 2009 at 05:26:55PM -0600, Jack Woehr wrote: >> And for your delectation: Conversation with Anselm R. Garbe of >> suckless.org >> <http://dobbscodetalk.com/index.php?option=com_myblog&show=Conversation-with-Anselm-R.-Garbe-of-suckless.org.html&Itemid=29> >> > > Definitely an interesting read. Thanks for the post.
Well I'm not very happy with this post, it was in a hurry and many aspects I raised were quite raw, some are even contradicting in retrospective. > Just curious as to the arguments against OO programming. All the classes > I have taken in uni always trumpet OO. I have been using it ever since > but I do agree that it can get out of hand at times. Let me paste some response I gave recently via priv mail: --- 2009/9/9 frederic <fduboi...@gmail.com>: > Hi, > > You said in Dobbs code talk interview that "Data structures are more > important than actual code". Can you elaborate on this? Sure. Let's ignore OO for the moment. If you assume that data isn't mixed up with code (methods/functions) it defines in itself a problem description that can be used by different implementations. In this respect it becomes easy to change the code without touching the data structure, or to extend the data structure without changing existing code. (this is the biggest issue I have with OO, because it encourages to mix data with code.) When solving a problem, the data structure itself is key to see if the problem is solved in a good [simple] or bad [complex] way. So the more code is necessary to work with the data structure, the poorer the data structure in question. As a rule of thumb the data structure needs to be as simple and closest to the problem in question as possible to drive efficient and simple implementations. Also, if in doubt, use the simpler data structure first and avoid thinking "will this list perform" -- usually pre-optimisations are evil to data structure design and implementations. The first and possibly biggest effort -- prior to any code written -- is designing the data structure and getting it right, in order to create a problem description that actually developing code for will work like a charm. --- > My question is that, there are some approaches that 'seem' > easier/logical to implement with OO, how does one approach this in a not > OO way? Well that was my excuse when I was a fan of OO as well, that there are plenty problems "better solved" using OO. When carefully thinking about it, I always concluded, no, this problem is better not solved the OO way. Can you give examples where you think OO is the better choice? My current situation is this: I think OO is the better choice if you need to solve a problem for OO itself, eg if you are writing API or language bindings that rely on OO design. But that's the only example I cam across so far where I believe OO really is better to solve a problem created by OO itself ;) But that doesn't applies to the general purpose obviously. Kind regards, Anselm
