Re: DRY vs. KISS

On Thursday 12 Nov 2009 20:41:09 Omer Zak wrote:
> On Thu, 2009-11-12 at 19:24 +0200, Shlomi Fish wrote:
> [... an example was snipped ...]
> 
> > So the question to you is: do you think DRY and KISS can sometimes
> > contradict one another? If so, which one is more important, or that you
> > should just use your reason. I should also note that I've been feeling
> > that less expressive languages sometimes result in being unable to avoid
> > duplicate code or undesirable "patterns" in the code (in accordance to
> > DRY). Possibly the only family of languages that completely avoids
> > duplicate code is Lisp.
> 
> I think that more important than DRY, KISS or whatever is the principle
> of not overloading the memory of whomever is going to read the software.
> 
> You overload his memory if he has to look up elsewhere for definitions
> of variables, functions, closures or whatever constructs you are using.
> According to this criteria, LISP can be very bad.

Interesting. Of course, part of the reason why we have functions is so we can 
encapsulate a potentially complex function in an easy to digest thing that we 
know what it does.

Of course, this may result in a http://en.wikipedia.org/wiki/Leaky_abstraction 
which will require us to understand what the function does and how it does it 
before we can proceed, which will also overload the memory during reading the 
code.

> 
> If you define another function in order to avoid code repetition at 3
> places in your project, then whomever is reading the code needs to look
> up the new function definition.  If it's the only function in the
> statement - OK.  But if the statement already invokes 7 functions to
> compute values, return a function pointer to be invoked, and the address
> of the variable to receive the result, then adding 8th function would
> already overflow the reader's short term memory.

Well, in his book "Refactoring", Martin Fowler advocates very short methods of 
very few statements with simple expressions each, while extracting the more 
complex evaluations to helper methods, and many people seem to agree with him 
(including me to a large extent[Practice]). Of course, this in turn causes 
understanding the code or tracing a bug be more difficult because you have to 
delve several methods deep (which in turn causes a memory overload).

{{{{{{
[Practice] - while I agree with it, but often my code, including my open-
source code does not exhibit this. It's just that I'm too anxious to write 
functional code, that I don't make sure it's properly factored. Normally, I 
only give an external API and do not support any internal APIs, including not 
class-inheriting API, so it's not that critical.
}}}}}}

> And sometimes when you need to modify all copies of an expression in
> your project, egrep can do good enough work - so no need to make them a
> function to enable code modification at one place.  In a way it would be
> "virtual DRY" - the entity which you don't repeat is the egrep pattern.

What if someone who is not intimately familiar with the code changes one place 
and not all other places? What if you forget to change them? That's the danger 
of duplicate code.

Some people may argue that syntactical patterns in the language are not really 
duplicate code, but Lisp purists may disagree.

> 
> Those are vague ideas.  I hope that someone would continue the
> conversation and can distill those ideas and find the hidden principle -
> it surely would be a gem!
>                                               --- Omer
> 

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
My Aphorisms - http://www.shlomifish.org/humour.html

Chuck Norris read the entire English Wikipedia in 24 hours. Twice.


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/hackers-il/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/hackers-il/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/