Is Functional Abstraction Too Clever?

http://www.lostechies.com/blogs/dahlbyk/archive/2009/10/17/is-functional-abstraction-too-clever.aspx

by Confusion • 17 years ago

22 29 17 years ago

My verdict: The code is just fine. It's the syntax of the extension methods that is causing the audience to panic and flee:

    public static IEnumerable<TResult> Pairwise<TSource, TResult>(
        this IEnumerable<TSource> source,
        Func<TSource, TSource, TResult> resultSelector)

"Too clever" is, if anything, a polite way for a relative beginner to describe this code. I'd go with "fscking illegible" myself.

When, as a language designer, you find yourself designing syntax like this, it's a sign that you have drunk the Kool-Aid too greedily and too deep. In exchange for precious, precious type safety you have traded away the legibility and learnability of your language. The inevitable result is that, five years from now, you will be one of those frustrated people who grumbles on message boards, wondering why everyone prefers to use PHP.

Try a different language. I suspect that in Ruby or Python this code would not be so "clever". In Scheme it would be par for the course.

jacquesm4• 17 years ago

Type safety is vastly overrated.

Dealing with polymorphism in a clever way (say by using duck-typing) is the way to get much the same effect, the only price you pay is that the errors shift from compile time to run time, and that's unacceptable in some situations.

The mess above is a typical example of taking something to an extreme.

I remember there was somewhere a coding standard (I think it was microsoft) that required you to put the initial letter of the type of every parameter in the function names.

People come up with something ('typing' or 'everything is an object') and then try to shoehorn each and every issue they have into that shape, even if it is totally not applicable.

mechanical_fish4• 17 years ago

The convention you refer to is "Hungarian Notation", and Spolsky's essay on the subject is required reading before you get too vehement about it's stupidity. Basically, it started out as a relatively useful convention, then got misunderstood and misapplied and morphed into a ridiculous version of itself.

I wonder sometimes if the same thing has happened to type safety. I'm not convinced it is a bad idea, actually. I am convinced that it's not well-served by having Java as it's poster child. If my mental picture of a type-safe language is something that reads like this, no wonder I'm inclined to think it's overrated.

viraptor2• 17 years ago

> Type safety is vastly overrated.

I don't think it is. Explicitly listing types is definitely overrated though. Basically the same function in haskell:

    pairwise (a:b:xs) f = (f a b):(pairwise (b:xs) f)
    pairwise _ _ = []

What does ghci know about it now?

    pairwise :: [t] -> (t -> t -> a) -> [a]

Without any user annotation - magic! :) Just in case - mapping to the original types from the article:

    TResult == a
    IEnumerable<TResult> == [a]
    TSource == t
    Func<TSource, TSource, TResult> == t -> t -> a

Shorter notation and a bit of type inference can make that example a lot easier. And it is completely type-safe which can save you in case the predicate tries to do something stupid.

fnid2• 17 years ago

You should qualify, "Type safety is vastly overrated -- today." There was a time when type safety was very valuable to the performance and functionality of programming. Computers are so fast now that the performance hit is almost negligible, but this wasn't always the case and dynamic languages were very very slow compared to their strictly typed brethren.

Even within the same language, strict typing and dynamic typing had big gaps in performance.

Confusion• 17 years ago

Type safety does not require illegible code. You could express this more nicely in, even, Scala.

colomon• 17 years ago

As an example, here's my quick implementation of the original code in Perl 6. (Note that this is the entire implementation, no helper functions needed.)

    sub GetSlots($slots, $max) 
    { 
        my @a = (1..($max-1)).pick($slots-1, :repl).sort;
        return (@a, $max) >>-<< (0, @a);
     }

(1..($max-1)) generates a list of integers from 1 to $max - 1. pick($slots-1, :repl) randomly picks $slots - 1 from the first list, replacing the one picked each time (so duplicates are possible). sort does just what you would think.

The second line of the sub uses a hyper-operator to subtract one array from another -- in this case the sorted array of random numbers plus $max on the left, 0 plus the array on the right. The result is also an array, and that's what we return.

It's not a pure functional implementation, obviously -- you could certainly do that in Perl 6, but to my mind this approach emphasizes what is actually going on, rather than hiding it in the Pairwise function. (Without digging into the Pairwise function code, how do you know if it splits (1,2,3,4) into (1,2) and (3,4) or (1,2), (2,3), and (3,4)?)

BTW, this code already works in the Rakudo implementation of Perl 6...

jauco• 17 years ago

I really value your opinion on most programming matters but I have to respectfully disagree. I can understand someone having a problem with c#'s syntax in general. But in this case I had more trouble with verifying the algorithm than with the type annotations. They might require some carefull reading but you have to keep track of only two types so the cognitive load is minimal. More importantly, writing these function definitions makes using the functions really easy (auto complete support etc.)

that being said I don't really like the tone of the code's author who poses the question on his blog with fake honesty hoping everyone will laurel his clever solution.

swombat• 17 years ago

Functional abstraction in general is not too clever. This particular code example, though, absolutely is. As mechanical_fish pointed out, it's pretty much illegible.

DRY is only one of the principles of good code, and not the highest one. The highest one would be that the code must work. The second highest that the code must be clear to the reader.

I warmly recommend this excellent talk by Marcel Molina Jr at RubyConf 2007, about what makes code beautiful:

http://rubyconf2007.confreaks.com/d1t1p1_what_makes_code_bea...

He gives a good example of a case where using too many abstractions results in unclear, and hence ugly code.

weavejester2• 17 years ago

Huh? Why is it illegible?

jrockway2• 17 years ago

Because the reader doesn't know the language it's written in. Note that "illegible" is a property of the reader, in this case, not of the code itself.

fnid2• 17 years ago

Too clever is not determined by some property of the code, but rather the audience who reads it.

Is Functional Abstraction Too Clever?

Related Stories