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

[Michael Turner]

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

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


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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You're being pedantic dude. I'm sure Joe Armstrong and the other
> programmers that designed and work on Erlang are acutely aware of DRY,
> PoLS, and a whole bunch of others.
>
> Personally, I think it is a feature to state the function name when
> defining another function clause.
>
>    some_func(X, Y) ->
>        %% Long bit of code
>        ...;
>    some_func(X, []) ->
>        %% More code
>        ....
>
> Without it, scanning the source could get confusing.
>
> Michael Turner <michael.eugene.turner@REDACTED> writes:
>
> > I can say
> >
> >    fun (1)->2;
> >         (2)->1
> >    end
> >
> > but, oddly, I can't define a named function in the analogous way, e.g.:
> >
> >    factorial
> >      (1) -> 1;
> >      (N) -> N*factorial(N-1).
> >
> > gives me a syntax error. I find the latter more readable than
> >
> >    factorial(1) -> 1;
> >    factorial(2) -> N*fact(N-1).
> >
> > It's also less to type and to read, which is consistent with the DRY
> > principle ("Don't Repeat Yourself").  And it lends itself to reading a
> > function definition as a set of cases. I think for Erlang newbies, it
> > should therefore would be preferred: it helps underscore the
> > pattern-matching style of Erlang function invocation.
> >
> > It also looks a *little* bit more like the mathematical convention for
> > defining these sorts of functions, where you have "f(x) = ", centered
> > vertically to the left of a big left "{" that (left-)encloses the list
> > of expression/parameter-condition pairs in a two-column format, e.g.,
> >
> >  http://cnx.org/content/m29517/latest/Picture%2047.png
> >
> > So there's a (weak) argument from the Principle of Least Surprise here
> > as well.
> >
> > It seems to me that, if anything, this requires only a *simplification*
> > of the Erlang parser. That leaves only one obvious objection: would any
> > existing code break if Erlang syntax were altered to allow this?
> >
> > -michael turner
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> - --
> Parnell "ixmatus" Springmeyer (http://ixmat.us)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJN0+GfAAoJEPvtlbpI1POLEMkH/3TKrH5uCapUy+jM2V7+JP43
> Fn8EEJIgkuGHd+t1Jp2BI190Yyl+hO1hlarQJzDulGWBdYMtsxIGJ32Za9rJrSyo
> C+nzfDpC5cKrLXXlk4vFq+GphnKOoOffQ7FCqQvElL89GBXxt7cvPCjk6X04BuYI
> MhQYidxOozerdvNkH1iw9uC61zVhz0ahPqwuMbyzCg71BjLYo8NR+qYpqtiTMHjx
> nXar6vcjzsrEQzi5Ul5hWjrgzQQgecFOeeZ5bQjTzhKfHMpUk1beI5rQuYxpuvVd
> 8kA1YiOU5mfQqoqA+ZKpoG598Isp1vnTc+DQznJC9GbE4mgUWNO5n4J51U2OR5U=
> =ypYB
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110519/812f9316/attachment.htm>