[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions
Joe Armstrong
erlang@REDACTED
Fri May 20 17:36:17 CEST 2011
On Fri, May 20, 2011 at 12:44 AM, James Churchman
<jameschurchman@REDACTED>wrote:
> winner for the most nit-pickey thread ever
>
> also :
>
> >Me, I'd like to say
> >
> > L = [{foo, fun(X,Y) -> ... end}, {bar, fun(X) -> ... end}]
>
> > then have couple of new bifs Mod = list_to_mod(L) to compose a module
> from a load of funs and mod_to_list to do the inverse.
>
> should be possible by generating a bit of ast and would indeed be a cool
> addition to the runtime :-)
>
Unfortunately not.
/Joe
>
>
>
> On 19 May 2011 23:05, Edmond Begumisa <ebegumisa@REDACTED> wrote:
>
>> 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/
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110520/b0cf3ccd/attachment.htm>
More information about the erlang-questions
mailing list