[erlang-questions] DRY principle and the syntax inconsistency in fun vs. vanilla functions
James Churchman
jameschurchman@REDACTED
Fri May 20 00:44:43 CEST 2011
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 :-)
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110519/b504cf80/attachment.htm>
More information about the erlang-questions
mailing list