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

Parnell Springmeyer ixmatus@REDACTED
Wed May 18 17:16:34 CEST 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Catering directly to the lowest common denominator is *not* a good
strategy. People should stop saying this: "We need to change feature X
to for reason Y for n00bs" and start saying this: "We need to write more
engaging documentation and have better idiomatic use case examples so
n00bs can /learn/".

It's easier to educate them than to not. Sure, learning Erlang is a
rough ride for your first year - but once you grok it, you have it for
life.

I would actually think they *wouldn't* have an easier time with that
sort of syntactic change because now you have to find that hidden set of
parentheses in a possible sea of code. See my previous email. It's a
nice idea in theory for small examples like factorial - but when you
have large functions that have multiple clauses, it is SOOOOOO nice
being able to scan down the left side of your editor window and see all
of those function names.

Michael Turner <michael.eugene.turner@REDACTED> writes:

> It's just been pointed out to me (in a possibly *unintentionally*
> private e-mail) that this topic was already taken up on a recent
> thread:
>
>   http://erlang.org/pipermail/erlang-questions/2011-May/058323.html
>
> I don't really understand one of the objections: that newbies would
> find it strange. When I started learning Erlang, even with some
> experience in lisp and prolog, I found *lots* of things strange.
>
> And yes, I understand that function clauses were borrowed from prolog.
> But an influence is not a stricture, especially when that influence is
> only partial, as it is here -- and maybe prolog wasn't doing it right
> either?
>
> The better way to evaluate newbie-friendliness of the proposed
> syntactic change is to do it *scientifically*: teach some newbies both
> ways of writing function clauses, then see how well they do in timed
> code-comprehension tests where the only difference is the proposed
> change in syntax. I predict they'd actually have an easier time with
> what I propose, or at least do just as well.
>
> -michael
>
> On Wed, May 18, 2011 at 6:16 PM, Michael Turner <
> michael.eugene.turner@REDACTED> wrote:
>
>     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+LTAAoJEPvtlbpI1POLw1IH+QHYn/PuxcxZz6Xp6yzVuhnM
rPNkpp/kWpub2EBxo0qfyt/xhXE/FCdfHfgTy6T0mOXbuXx8vRRqVSQHP4OXwWSr
5NEnlavUQjIGtUjI8FX+ImSqNOWmvlT0RtMpwP7tuvFEiDpcc5XFf6+ba1ktJoK5
cNKNm1EFp6qLCN5y33Nrd/OavtTJf4o9nv/08gxpwRU3tIoee9Lh1uJTpmJ8EPh3
zfYRZ/wIR/7xMFIK40X+7YMyAEzmwy9TDM7RLAgwLrqMjbuphfRq0BDeLUVVRGhe
SMPS41QUjmxHkMY7W4t6S6KJy2BGey7pYeXNXjBbOhabiBknvHbl/Xd/APAU5/E=
=DpFL
-----END PGP SIGNATURE-----



More information about the erlang-questions mailing list