Express What, not How.

[ketil+news at ii.uib.no]

Raffael Cavallaro <raffaelcavallaro at junk.mail.me.not.mac.com> writes:

> You're misreading those who have argued against me. They seem to think 
> that this advice should _not_ be followed in the case of anonymous 
> functions. I.e., the anonymous function camp seem to think that 
> anonymous functions are such a wonderfully expressive tool that they are 
> more clear than _actual desriptive function names_.

Anonymous functions *can* be more clear than any name.  Either because
they are short and simple, because it is hard to come up with a good
name, and/or becuase they are ambigous.

Say I want to attach an index to elements of a list.  I could write

        integers = [1..]
        attach_index ls = zip integers ls

or just

        attach_index ls = zip [1..] ls

Whether you want to give an explicit name to the list of integers is
not given.  If the indexed list is local, it is better to use the
definition directly; I don't want to look up the definition of
integers (perhaps in a different module) to check whether it is [1..]
or [0..].  

> They think it is just fine to expose the implementation details in
> code locations where it is completely unnecessary to know the
> implementation specifics.

All code exposes implementation details on some level of abstraction.
You seem to argue that an anonymous function is on a lower level of
abstraction?

> In article <pan.2003.10.14.23.19.11.733879 at knm.org.pl>,
>  Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> 
>> A name is an extra level of indirection. You must follow it to be
>> 100% sure what the function means, or to understand what does it really
>> mean that it does what it's named after. 

Obviously true, no?

>> The code also gets longer - not only more verbose but the structure
>> of the code gets more complex with more interdependent parts.

Code gets longer if you disallow anonymous functions, but of course,
it also gets (a lot) longer if you disallow named functions.  As
Marcin said in the posting, there should be a balance.

>> When you have lots of short functions, it's harder to find
>> them. There are many names to invent for the writer and many names
>> to rememner for a reader.

Surely this is true?  Has anybody seen code where all names were
descriptive and unabmigous, yet short and concise?

>> Function headers are administrative stuff, it's harder to find real
>> code among abstractions being introduced and used.

> In other words, don't use names _at all_ if you can avoid them. Just 
> long, rambling tracts of code filled with anonymous functions. 

I don't read it like that at all.  Just that naming everything has its
cost, a cost you often don't want to pay.  If you program
imperatively, a function is often a largish chunk of code, and it
often makes sense to name it.  If you program in a functional style,
small functions are composed and combined endlessly, and naming them
would be like naming all intermediate results in an expression, as
somebody illustrated.  

It's not just lambda, but function composition, partial applications,
and so on.  If I do 

        map (f x) ls

should I name the partially applied (f x)?  I.e. is

        map (4 +) ls 

worse than

        let add_4 = (4 +) in map add_4 ls

?  And should add_4 be globally defined somewhere?  How about 

module PartialAdders where

        add_0 = (0 +)
        add_1 = (1 +)
        :       :

        import PartialAdders(add_4)
        :
        ... map add_4 ls...

I hope you agree that naming has a very real cost, and in this case,
just reduces readability, maintainabilty and efficiency.

> After all, you'd just have to go look at the named function bodes
> anyway, just to be _sure_ they did what they said they were doing.

The ability to do this, is of course important.

> (I wonder if he disassembles OS calls too, you know, just to be sure).

Presumably, the language will be well defined on some level.  Some
people have needed to do that, though.

> Really I personally think they are often just enamored of their own 
> functional l33tness,

Well, sure.  But it IS better :-)

> but you'll always have a hard time convincing programmers that their
> unstated preference is to write something so dense that only they
> and others equally gifted in code decipherment can grasp it.

The argument is one of code clarity, more than anything.  Every
language or style has the geeks who obfuscate things with excessive
cleverness.  That isn't the point here.  At least not my point.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants