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

On Mon, Sep 14, 2009 at 9:59 AM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> 2009/9/14 Amit Uttamchandani <atu13439_AT_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 <fdubois76_AT_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.

This is one of most important lessons, and most often forgotten, in
the history of programming. Fred Brooks mentioned it in The Mythical
Man Month (which should be one of three books every programmer knows
by heart), and was repeated again by Pike and Kernighan in the
Practice of Programming.

Once you have your data structures properly figured out, the code just
falls from them naturally. Forcing to arbitrarily tie up your data
structures to how your code is laid out, and mixing both together is a
very, very, very bad idea, this is what OO does.

And it can't be said often enough: inheritance is the most idiotic and
counter-productive form of 'code reuse' ever conceived by man, and
often drives one to write much more code, and worse, much more complex
code. You are better off exclusively using camefrom and goto to reuse
code than using inheritance.

As for multiple inheritance... that is sheer lunacy and anyone that
even considers using it should be confined to a mental asylum for the
rest of their days.

Peace

uriel

> ---
>
>> 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
>
>
Received on Mon Sep 14 2009 - 13:13:30 UTC