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

[Michael Turner]

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110521/f824e262/attachment.htm>