[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions

[Richard O'Keefe]

On 21/05/2011, at 5:51 AM, Michael Turner wrote:

> 
> Here's the core paragraph from that first post:
> 
> "It's also less to type and to read, which is consistent with the DRY principle ("Don't Repeat Yourself").

What you have failed to acknowledge is that DRY is a principle for
*writers*, not a principle that is even intended to help *readers*.

Readers benefit from having the information they need where they
need it, when they need it.  And that means redundancy.  When you
are writing to be read, REPETITION HELPS.

> That's an argument in which readability weighs slightly more, isn't it?

It's an argument in which readability is *mentioned* but in which
it actually counts for nothing at all, in which nothing that is
known to make anything more readable is suggested or even approved
(other than good indentation, which you *did* take care over, but
we all agree that good indentation is important even if we do not
agree what it is).

From the Wikipedia page about DRY:
	Kent Beck has mentioned that he does not
	"subscribe to [DRY] for test code because
	[he] want[s] [his] tests to read like a story".[2]

He is implicitly saying that DRY harms readability.

I should also point out that DRY simply isn't about source syntax.
It's much more about architecture.

Also, DRY is about there being a single authoritative source for some
piece of knowledge.  It is NOT about what is *displayed* to the programmer
in an editing environment.  Again, the needs of the reader and the needs
of the writer are different.  If Erlang had started with the syntax you
recommend, by now we would have IDE tools to turn
	max
	    (X, Y) when X >= Y -> X;
	    (X, Y) -> Y.
into
	max
	    (X, Y) when X >= Y -> X;
	%max
	    (X, Y) -> Y.

providing the reader with a usefully redundant display.  This would NOT
violate the DRY principle.  I've seen manually inserted comments of this
kind in enough Lisp code...

DRY is closely related to "Once and only once",
and at the c2.com wiki page on that topic we find

	OnceAndOnlyOnce sounds like a nice principle but,
	when taken at face value, would lead to untested code.
	Even XP advocates stating each fact at least twice,
	preferably three times.