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

[Edmond Begumisa]

As I described previously: I actually think that the current syntax is  
*better for newbies* (especially those coming from imperative languages)  
since it drills-in Erlang's declarative nature. I view your proposal as  
something to cater for the experienced Erlanger who wants an alternative  
syntax for one-off scenarios.

- Edmond -

On Sat, 21 May 2011 01:19:43 +1000, Michael Turner  
<michael.eugene.turner@REDACTED> wrote:

> Anyone who thinks that I address the needs of writers in preference to
> readers on this thread hasn't been reading me with much attention.
> Readability is somewhat in the eye of the beholder. A lot of the  
> beholders
> on this list are seasoned Erlang programmers. It's pretty clear what they
> prefer: the way things are.
>
> I happen to find the indented style I propose more readable. I have also
> said that I think programmers new to Erlang would tend to agree, although
> without a scientific test it would be hard to establish this, I admit.  
> Some
> day, if Erlang survives, all the eyes on it will be new, because we'll  
> all
> pass from the scene, eventually, one way or another. So it's not as if
> newbie opinion is utterly irrelevant here.
>
> Disagreeing with my expressed position on readability is fair. Writing  
> as if
> I'd never expressed that position, however, is not.
>
> -michael turner
>
> On Sat, May 21, 2011 at 12:04 AM, Edmond Begumisa <
> ebegumisa@REDACTED> wrote:
>
>> consider the needs of READERS in preference to WRITERS.
>>>
>>
>> I found this statement nicely summed up the conflicting views on this
>> thread. Very well put. And it puts the issue to rest IMO.
>>
>> - Edmond -
>>
>>
>>
>> On Fri, 20 May 2011 18:27:03 +1000, Richard O'Keefe <ok@REDACTED>
>> wrote:
>>
>>
>>> On 19/05/2011, at 4:08 AM, Michael Turner wrote:
>>>
>>>  "Sorry, but Erlang doesn't *need* a better chance of survival."
>>>>
>>>> Now, wait, I'm really pretty sure that, less than a year ago, I saw  
>>>> both
>>>> Peyton-Jones and Armstong in a video, speculating about the future of  
>>>> their
>>>> respective favorite languages, and openly wondering what the long-term
>>>> future held.
>>>>
>>>
>>> And?  Haskell is booming.  They tried to avoid success and failed
>>> miserably.
>>>
>>>  In the meantime, I haven't noticed a dramatic increase in the  
>>> frequency
>>>> of Erlang job postings, though perhaps it's gone up. However, a  
>>>> doubling
>>>> would still leave the number small.
>>>>
>>>
>>> That does not mean that Erlang is under threat.  Come to think of it,  
>>> R is
>>> booming
>>> also.  There are at least 81 mirrors of CRAN to handle the download
>>> volumes.  How
>>> many R jobs do you see?
>>>
>>>>
>>>> "Changing core language features that are solid,..."
>>>>
>>>> Except that that what I proposes fixes a weak spot (among other  
>>>> things):
>>>> failed syntactic consistency.
>>>>
>>>
>>> No, it leaves the *weak* spot (the absence of names in funs) along
>>> and smashes the *strong* spot.
>>>
>>>>
>>>> "... well thought out ..."
>>>>
>>>> Except that Joe Armstrong has just admitted (on this thread, IIRC)  
>>>> that
>>>> the reason for the inconsistency is that they just didn't think about  
>>>> it at
>>>> the time...."
>>>>
>>>
>>> If you mean when "funs" were introduced, that may be so.
>>> But the repeated function names were copied from languages where it  
>>> *WAS*
>>> well thought out, rather like you probably would not fault someone for
>>> designing a programming language using [] for array subscripting.
>>>
>>>
>>>> "... and non-harmful ..."
>>>>
>>>> Implying that what I suggest here IS harmful?
>>>>
>>>
>>> Yes, it is
>>> It would seriously impair readability.
>>> It would break several code processing tools that I use.
>>> It would drastically impair the usefulness of every existing Erlang  
>>> book.
>>>
>>>>
>>>> Actually not. No amount of education and experience will make  
>>>> repeating
>>>> the function name with every clause a DRY issue, for those who find  
>>>> that
>>>> repetition as more of an obstacle than otherwise.
>>>>
>>>
>>> Remember always to consider the needs of READERS in preference to  
>>> WRITERS.
>>>
>>> Take Haskell, as an example.  One of the advantages of Haskell is that  
>>> the
>>> types of functions can be inferred from their bodies (as long as you  
>>> stick
>>> to the standard language and don't use the rank 2 extension GHC  
>>> offers).
>>> Why then do most Haskell programmers recommend writing down function  
>>> types
>>> anyway, even though that violates DRY?
>>>
>>> Because although the type *is* implicit in the code, and the *compiler*
>>> can figure it out, that doesn't mean it's easy for *humans*.
>>>
>>> If you are one of the people who find repeating function names an  
>>> obstacle
>>> (on present evidence, a set of cardinality one),
>>>  - you don't have to use Erlang
>>>  - you can always write cases if you want
>>>  - you could look into LFE
>>>  - you could write your own preprocessor
>>>
>>>
>>>  No amount of education and experience will keep people from wondering,
>>>> "Why this strange inconsistency?"
>>>>
>>>
>>> As a matter of fact, I've known about Erlang since about a year (maybe
>>> two) since the first paper
>>> on it.  Since well before it *had* funs, in fact.  And you know, I've
>>> *never* had that thought.
>>> I don't experience any inconsistency.
>>>
>>>  oAnd better documentation and training will only make more people ask
>>>> that question. I didn't ask that question until I *stumbled* on the  
>>>> extended
>>>> syntax for funs; I didn't know about it before.
>>>>
>>>
>>> "Extended syntax for funs?"  What's that?  The syntax of funs is  
>>> described
>>> in
>>> chapter 7 of the reference manual, the chapter on expressions, which is
>>> exactly
>>> where you would expect to find it.
>>>
>>> The inconsistency I see is that functions are OK but funs
>>> (a) do not permit a visible function name
>>>    -- just like Haskell, Clean, SML, CAML, &c
>>> (b) begin with "fun" instead of just beginning
>>>    -- just like Haskell, Clean, SML, &c
>>> (c) end with "end" instead of ending with a "."
>>>    -- the other languages I mentioned do not have any
>>>    -- terminator, so I usually find myself having to
>>>    -- wrap them in parentheses.  It's quite nice not
>>>    -- having to do that.
>>>
>>> However, (b) and (c) are unsurprising because funs are
>>> *expressions* and normal function definitions are not.
>>>
>>> If you are that upset about (a), I suggest that the inconsistency
>>> should be resolved by allowing funs to have names, as I've suggested,
>>> because that would fix the *other* difference between funs and
>>> normal functions, which is that normal functions can be directly
>>> recursive, and funs cannot.
>>>
>>> Your proposal to add a definition style that I find horrible for
>>> normal functions fails to do anything about that *other* difference
>>> between functions and funs.
>>>
>>> I repeat, you are urging that a *strong* spot be smashed to make
>>> it consistent with a *weak* spot, which is quite the wrong way around.
>>>
>>> _______________________________________________
>>> 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/
>>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/