in reply to Re^3: Understanding 'Multiple Inheritance'
in thread Understanding 'Multiple Inheritance'

BrowserUk wrote:
The single biggest (and hardest) lesson I've had to learn through experience, because it was never covered on any CS course I took--nor any I have read about since--is: "Don't do it unless you have to!".
Funny, the one that I've learned is "Always be neat, even when you think you don't have to."
  • Comment on Re^4: Understanding 'Multiple Inheritance'

Replies are listed 'Best First'.
Re^5: Understanding 'Multiple Inheritance'
by BrowserUk (Patriarch) on Mar 08, 2005 at 14:07 UTC

    Funnily enough, most every course I took at college, form was favoured over content.

    I saw people that wrote the most boring, derivitive and unoriginal work consistantly score the highest marks because they were blessed with neat handwriting and good rote recall for spelling.

    And one American girl got really upset because she would be constantly marked down by our English English teacher for "mis-spellings" like favor -v- favour, color -v- colour etc.

    Her writing were damn nearly magical to most of us very parochial Brits. We loved hearing her stories of the Near and Far East, and her recounting of everyday life in West Berlin in the 70s were so far beyond our experience it was almost like SciFi. For her writing to be marked down because she had been taught to write differently to us always seemed most unfair.

    This was all the more galling for her as she had gained her education all over the world. As the daughter of a USAF guy, she had travelled all over and been schooled in many countries in Europe and Asia. And the only country where she was penalised for her spelling, and expressions like "they borrowed me a cup of sugar", was the UK.

    "Always be neat, even when you think you don't have to."

    Reminds of a guy I was at school with. He was brilliant at woodwork. His joins were always invisible, his joints barely needed the glue, his tools always sharp, and his workbench was never covered in shavings and sawdust. He became a carpenter--and hated it.

    His first commercial job was erecting shuttering. He would carefully align the edges of the boards. Every board had the same number of nails, which were always equidistantly spaced along the edges. Every nail was driven home properly with none ever being turned over. The problem was, he couldn't earn anywhere near the same amount of money as his colleagues. He was too slow and it was piecework.

    Shuttering is the wooden frameworks they build to pour concrete into when they build office blocks and bridges. It's purpose is to scaffold and support whilst the concrete dries, after which it is just ripped off. It is a temporary structure that doesn't need to be neat or perfect. It simply needs to perform its function for the few hours or days that it takes for the concrete to be poured and set. And it needs to be fast and cheap.


    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
      Would it have been clearer what I meant if I said "Always be orderly, even if you think you don't have to"? How about "Always use 'use strict', even if you think you don't have to?"

      Most quests for a software methodology seem to boil down to a search for an "Always do it like this", e.g. always encapsulate (meaning, insulate the small parts from the behavior of the whole... this might or might not be done using OOP).

      I would contend that every one of these principles is the enemy of strict parsimony. Should you never use encapsulation unless you know you need to, or should you always use (some form of) encapsulation, so you don't have to worry about whether you need to?