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

[Michael Turner]

"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."

But which of those allow more than one argument list? It isn't just that
people are used to the function name being written only once. (That isn't
true for C++ member functions, and there are *lots* of C++ programmers out
there.) I think the indentation style I suggest also makes it more
immediately obvious that Erlang features a kind of pattern-directed
invocation.

As for what you claim is more readable, remember: the intuitive is the
familiar. Someone who is entirely new to Erlang will perceive things
differently. The only way to make the proposition "syntax X is more
readable" a scientific one is to test -- on people *new* to Erlang. After
all, someday, all of us will have passed from the scene and it will be only
the new people who matter.

-michael turner


On Fri, May 20, 2011 at 5:07 PM, Richard O'Keefe <ok@REDACTED> wrote:

>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110520/7785487b/attachment.htm>