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

[Michael Turner]

"When I type a ";" in my editor it auto-completes the function clause for
me, ..."

I apologize for being one of those cavemen who still uses vi. And for
thinking, "If a program can autocomplete anything more than an identifier in
context, it must be generating a pretty redundant piece of code to begin
with."

-michael turner

On Thu, May 19, 2011 at 1:11 AM, Parnell Springmeyer <ixmatus@REDACTED>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > 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.
>
> How do you type more? When I type a ";" in my editor it auto-completes
> the function clause for me, that is an empty argument for changing
> something so trivial.
>
> Practical considerations would be better defined through education for
> core language features.
>
> > 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
> >                  ....
>
> Because, now I would have:
>
>    some_func
>        (X, Y) ->
>            %% Long bit of code
>            ...;
>         (X, []) ->
>            %% More code
>            ....
>
> It makes the "structure" less flat when you start adding in indentation
> levels (which you *have* to do if you are writing non-trivial functions
> in order to be able to read them two weeks later).
>
> Again, the style you are suggesting is really well suited for functions
> with small and concise function bodies. Which, is well suited for the
> lambda. I use this all the time for small functions:
>
>    SomeFun = fun (X, Y)  -> %% Short peice of code;
>                  (X, []) -> %% Short peice of code.
>
> It's obviously much easier and quicker to read - but I don't beleive
> that is the case with named functions.
>
> > Why is this less readable to you? 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.
>
> Then we would have someone like you complaining the opposite and
> proposing we all do it the way it is now - that person would probably be
> me.
>
> > And this is entirely apart from "long bit of code" being a classic
> > Smell anyway:
> >
> >   http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
>
> This is why I used the word "pedantic", don't I know abstraction and
> orthogonality is preferred over monolithic functions? Of course I
> do. But, what does one consider "long"? Some functions I write are
> /better/ written as a long function to avoid unnecessary (read:
> pedantic) abstraction that actually clouds the intent.
>
> - --
> Parnell "ixmatus" Springmeyer (http://ixmat.us)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJN0++gAAoJEPvtlbpI1POLn14H/2yY/dpNJVrMOnSPVrxjFRBY
> peMjGJZM/tRmReMWM9b6Df+hoRMXmPqZ+253LaAKYTfuehlowwXvG/HBRiFNB+vv
> +rOIcP/OOqeJNJp3MtRIKxKvqiubQMKfbalxh4Au0xzCp70o6fKYKQKZY1hS6TiY
> jtkeKxXU4vnmGockYhAlUlHNJLmopbVZGk97XZ2NtAqFDI8UmaWCZfSK7zN7Ebnm
> HLIXrv13TrwHy/i9xonuGrOvV8W7QPtzspGQxcix3a6JMEFox2E06tBRBHcVK1I8
> tAB6i9RVblWUqi4i4a1jjan9rk/p366sPz3yBUQVnPmgdezaA/q+mxsGxBAp6pE=
> =YwFM
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110519/b67e1091/attachment.htm>