[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions
Edmond Begumisa
ebegumisa@REDACTED
Fri May 20 00:05:55 CEST 2011
As I child I asked my mathematician father:
"Why is the number pad of a telephone in the flipped order from the number
pad on a calculator/computer keyboard?"
His answer: "That's just the way it is."
Sometimes "that's just the way it is" is a perfectly sufficient and
reasonable answer to both questions: why something is done a particular
way; and why it shouldn't be changed.
Mind you on the noob argument: when I first started learning Erlang (my
first functional language -- I had tried Lisp and gave up), I found the
current syntax a very good learning aid. To use Turner's original
example...
factorial(0) -> 1;
factorial(N) when N > 0 -> N*factorial(N-1).
I would read this as...
"The factorial of 0 is 1; the factorial of N when N is greater than zero
is N times the factorial of N - 1."
Having the function name at the beginning of each clause helped me greatly
to adapt to the declarative nature of Erlang. In contrast, I first
struggled with multi-clause funs because my brain wanted so badly to use
the anatomy of a function that I was so used to from imperative languages.
So I'd argue that changing this might make code actually *harder* for
noobs when they come across it. The function names reinforce the
declarative nature of Erlang, me thinks.
Besides, every programmer I know is a touch-typist -- it's not _that_ much
work typing the function names :)
- Edmond -
>>>> > 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).
>
On Fri, 20 May 2011 03:19:11 +1000, Mike Oxford <moxford@REDACTED> wrote:
> Noting that I'm not against core language changes where critically
> warranted, why is this one particular thing such an issue to you?
>
> Erlang is not an ivory-tower-on-a-hill-university-project. It's an
> organically-grown beast that gets down in the trenches and brawls in the
> mud.
> If you don't like it, write it off as an "Erlang wart." Every language
> has
> them. If you don't like it then write your own, or your own parser.
>
> For what it's worth, some users (such as myself) actually PREFER it the
> way
> it is because it makes code-scanning easier from a visual standpoint.
> Yes, I'm one of those people who will put "comment breaks" between
> methods
> in my code, too, regardless of language.
>
> And to reference your copy-paste-mutate argument....what do you think
> we'll
> be doing for every internal case-clause? Yes, that's right,
> copy-paste-mutate the pattern matches except that you now have your
> logical
> branches at indent-level-1 with, potentially, the rest of your code that
> doesn't deal with argument-specific code instead of at indent-level-0.
> If
> you need "common chunks of code" well, I'm pretty sure that's why we have
> methods. To wit, write your "unified interface" and case it yourself
> and
> call the argument specific sub-method.
>
> My vote: keep it as it is.
>
> <wipes-the-mud-off-his-beast-and-goes-back-to-work/>
>
> -mox
>
>
> On Wed, May 18, 2011 at 9:39 PM, Michael Turner <
> michael.eugene.turner@REDACTED> wrote:
>
>> Joe, with all due respect, I think you've misinterpreted DRY. It's not a
>> matter of writing something again because you can't find where it's
>> already
>> implemented. In fact, the canonical example of DRY is to write something
>> that works for one case, and then, rather than define it as a function,
>> template or macro, and invoke it with varying parameters, instead
>> copy-paste-mutate for each case. In fact, the most common violations of
>> DRY
>> are *precisely* when you know where the repeated code is, either because
>> you've just found it or because you've just written it.
>>
>> "DRY says that every piece of system knowledge should have one
>> authoritative, unambiguous representation."
>>
>> http://www.artima.com/intv/dry.html
>>
>> Erlang function definition syntax has two representations in the parser
>> --
>> for no good reason I can see. Why?
>>
>> "Changing syntax is *incredibly difficult* project managers get
>> apoplectic
>> at the thought of retesting million lines of code -"
>>
>> No existing code will use the syntax I suggest. So how can any of it
>> break?
>>
>> I have yet to get an answer: what could this proposed change possibly
>> break, even *theoretically*?
>>
>> -michael turner
>>
>> On Thu, May 19, 2011 at 6:47 AM, Joe Armstrong <erlang@REDACTED> wrote:
>>
>>>
>>>
>>> On Wed, May 18, 2011 at 5:29 PM, Parnell Springmeyer
>>> <ixmatus@REDACTED>wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Sorry, but Erlang doesn't *need* a better chance of survival. This
>>>> language is not just growing, it's booming. Changing core language
>>>> features that are solid, well thought out, and non-harmful (in other
>>>> words, they are, FEATURES) to make it more "adoptable" is a lot like
>>>> someone saying, "you have to quit that quirky smile so other people
>>>> will
>>>> like you more."
>>>>
>>>
>>> Languages survive forever once they get to the point where
>>>
>>> 1) legacy applications in the language still earn money
>>> 2) it costs more to convert to a new language than maintain the
>>> existing app in the old language
>>>
>>> Erlang reached this point, many years ago.
>>>
>>> Right now Erlang companies have a commercial advantage
>>> over non-erlang companies and so there is not much point in
>>> trying to spread the language further - you just loose your commercial
>>> advantage.
>>>
>>> /Joe
>>>
>>>
>>>>
>>>> Sometimes, yes, there are features in a language that could use
>>>> refinement - but many times, in a mature language, the ratio between
>>>> need and usefulness in refining a feature further, drops
>>>> significantly.
>>>>
>>>> Instead of changing something that is solid, educate the people that
>>>> have a hard time grasping it, build killer example applications that
>>>> exhibit the quirky style and idioms to a T - people /will/ follow it,
>>>> almost to a religious end.
>>>>
>>>> That's actually what I like about Erlang the most, the documentation
>>>> has
>>>> so many gems in it like the efficiency guide (where many common idioms
>>>> are expressed with clear DO and DON'T DO examples) and style guide.
>>>>
>>>> RE: syntactic consistency: Erlang's syntax *IS* consistent - it's more
>>>> consistent than many languages I've touched.
>>>>
>>>> Is Erlang easy for a Perl programmer? I bet not, and Perl's syntax is
>>>> less consistent than Erlang's is in my opinion. The issue you are
>>>> attempting to get at is (again) an educational and experience one, not
>>>> something that is inherently wrong with the language or its expression
>>>> itself.
>>>>
>>>> I'm actually baffled by the efforts people are putting into different
>>>> Erlang VM frontends that look like Ruby or Python. Good on them for
>>>> exercising the freedom of open source but /why/? Erlang's syntax is
>>>> almost beautiful to me now after using it, it's so well suited for
>>>> what
>>>> Erlang is good at!
>>>>
>>>> Erlang isn't that great for general purpose programming - you use
>>>> Python, Ruby, C, D, etc... for stuff like that. Erlang is great at
>>>> fault
>>>> tolerance, easy parallelism (which isn't easy!), and hot code
>>>> loading. Features that are so difficult to do in the traditional
>>>> imperative environment that (to date) I have not seen a single
>>>> implementation of any one of those features that even approaches the
>>>> completeness of Erlang's.
>>>>
>>>> Michael Turner <michael.eugene.turner@REDACTED> writes:
>>>>
>>>> > Another objection raised against this syntax change is that all
>>>> > functional languages violate DRY in this manner, so it's OK if
>>>> Erlang
>>>> > does it too. This is a Principle of Least Surprise argument, and not
>>>> > bad as far as it goes. But how far does it go?
>>>> >
>>>> > Erlang will have a better chance of greater success and survival if
>>>> you
>>>> > consider your recruitment base to be the overwhelming majority of
>>>> > programmers. And from what I can tell,
>>>> >
>>>> > http://www.langpop.com
>>>> >
>>>> > the overwhelming majority of programmers have no experience to speak
>>>> > of, when it comes to functional programming languages. Appealing to
>>>> the
>>>> > "cross-training" benefit of coming from other FP languages seems
>>>> like a
>>>> > pretty weak argument. Especially since all I'm asking for here is
>>>> > syntactic consistency *within* Erlang -- a PLoS argument in itself.
>>>> >
>>>> > Richard O'Keefe suggests that the syntactic consistency goal is
>>>> better
>>>> > met by allowing a kind of limited-scope special-case fun name,
>>>> > permitting, e.g.
>>>> >
>>>> > Fact = fun F(0) -> 1; F(N) -> N*F(N-1) end.
>>>> >
>>>> > I could get behind that too, but I don't follow his reasoning from
>>>> > syntactic consistency, which is apparently that an unnamed fun has a
>>>> > name, it's just the degenerate case of a name. It's really there.
>>>> We
>>>> > just can't see it. Hm, really? If that were true in Erlang as it
>>>> > stands, shouldn't I be able to write it this way?
>>>> >
>>>> > Fact = fun (0) -> 1; (N) -> N*''(N-1) end.
>>>> >
>>>> > Looks like it's not quite that simple. It compiles, but it doesn't
>>>> know
>>>> > what module to look in for '', when it comes time to execute. In the
>>>> > shell, I get an error indicating that it tried to resolve ''/1 as a
>>>> > shell command. Even if I put it in a .erl file and compile it,
>>>> there's
>>>> > no obvious way to tell the compiler what module to look in.
>>>> ?MODULE:''
>>>> > doesn't work. Nor does '':'', which I tried just for the hell of it.
>>>> >
>>>> > What Richard's suggesting appears to require a rigorous re-think of
>>>> how
>>>> > scopes are defined in Erlang. What I'm suggesting amounts to simply
>>>> > asking the compiler to do some of your tedious keying for you.
>>>> >
>>>> > -michael turner
>>>> >
>>>> >
>>>> > 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+XsAAoJEPvtlbpI1POLEXEIAJrjAGVTkveBi5/akYNMjBEX
>>>> 8wI9twatnXh8sfg2ohGKr3P1hj4jTr9ARrG5wiB9OCArRkBymnjFeY5g2dkBDOhN
>>>> aN722l+yDPpUewAM58m0dDoDHjrHXvxF1MJejQJGhQ+Nr9fM+7G+4QIrCN9RvX1S
>>>> QTAS+OqOnl8lsS98yvUiXXLB5ehdHcR46Ix6Sq7UwSvqaOKZMoPrzkTtW3VyS5kf
>>>> i/uGbPZ1I3KQJYRShk2QlLis/tpXGtLDnYc1E5uADqeClDXy5Au6LWpNqUjNIiWw
>>>> h8I2emcBq5Ur7nivNUYgnVMjg+0qTkQOtttPpOJ25xIYv07L+eMfXneb5nRx4hc=
>>>> =GGPU
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the erlang-questions
mailing list