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

[Richard O'Keefe]

On 19/05/2011, at 3:46 AM, Michael Turner wrote:

> "You're being pedantic dude."
> 
> If I argued only from syntactic consistency, you'd have a point. Frankly, I don't really care about syntactic consistency, if it doesn't get me something. Having to type less gets me something. Having more readable code gets me something. Those are practical considerations, not mere pedantic ones. Dude.
> 
> What you have as
> 
>    some_func(X, Y) ->
>        %% Long bit of code
>        ...;
>    some_func(X, []) ->
>        %% More code
> 
> could, as I proposed above, also be written
> 
>   some_func
>      (X,Y) -> %% long bit of code
>                  ...;
>      (X,[]) -> %% More code
>                  ....
> 
> Why is this less readable to you?

For the same reasons it is less readable to me.
Readable code PROVIDES HELPS FOR THE READER.

> You could answer, "Because it's not what I'm used to seeing in Erlang programs," but that begs the question. If people were more used to seeing the latter -- because making Erlang syntactically more self-consistent made it possible -- that argument wouldn't have much force -- except as an argument from pure conservatism.

It seems to me that Michael Turner's argument is an argument from conservatism.
Algol, Basic, COBOL, Fortran, PL/I, Simula, XPL, Java, Javascript, PHP, Perl,
all of these languages write a function name once and only once at the beginning
of a function.  So therefore Erlang should do the same?  Give me a break: those
languages that "the majority of programmers" are familiar with don't *have*
multiple clause functions.

Let's take an example *adapted* from "Pattern Matching in Scheme".

(define parse
  (match-lambda
    [(and s (? symbol?) (not ’lambda))
      (make-Var s)]
    [(? number? n)
      (make-Const n)]
    [(’lambda args body)
      (make-Lam args (parse body))]
    [(f args ...)
      (make-App (parse f) (map parse args))]
    [x (error ’syntax "invalid expression")]))

Now let's write that in Erlang:

parse(S) when isatom(S), S \== lambda ->
    make_var(S);
parse(N) when isnumber(N) ->
    make_const(N);
parse([lambda,Args,Body]) ->
    make_lam(Args, parse(Body));
parse([F|Args]) ->
    make_app(parse(F), [parse(Arg) || Arg <- Args]);
parse(_) ->
    error(syntax, <<"invalid expression">>).

That paper ends with a page full of code defining a single
function, and looking at it, I can see what pattern is being
matched, but not why, and can't really tell without the aid
of a ruler.

I've played with things like that, and I never want to do
so again.  I greeted SML, then Haskell, and Erlang, with load
cries of joy.

> And this is entirely apart from "long bit of code" being a classic Smell anyway:
> 
>   http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
> 
> -michael turner

You will find that some of the things in that taxonomy are, um,
expressed in an over-general way in the interests of brevity.
For example, I don't see any reason to ban switch statements
from Java.  They don't do anything that dynamic dispatch can
do, and dynamic dispatch doesn't do what switches can do.

"Long Methods" is very much a matter of taste; how long is too
long?  I've just recommended to someone that they add about
another 100 lines of code to a certain method today; 90 of
those lines are a table of strings.  There is nothing evil
about a table of strings.