

Is Functional Abstraction Too Clever? - Confusion
http://www.lostechies.com/blogs/dahlbyk/archive/2009/10/17/is-functional-abstraction-too-clever.aspx

======
mechanical_fish
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.

~~~
jacquesm
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_fish
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.

~~~
mdemare
This isn't Java, this is C#. (In Java this would be more verbose).

~~~
mechanical_fish
I'm aware of that. I chose to pick on Java because I assume, perhaps too
generously, that the C# designers are constrained by the need to market their
language to Java developers, such that when Java heads over a cliff the C#
folks are obliged to follow, though perhaps with a more elegant series of
aerial stunts on the way down.

The risk is that I unfairly maligned Java, a language which I do not know well
anymore, since I abandoned it about when it started to look like this. But
according to you I'm being too generous to them as well. :)

~~~
coliveira
> C# designers are constrained by the need to market their language to Java
> developers

No, because C# had generics before Java.

~~~
weavejester
Well, the C# 2.0 specification was written in 2002, but the compiler was only
released in 2005, a year after Sun released J2SE 5.0. So from a implementation
perspective, Java had generics before C#.

------
swombat
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...](http://rubyconf2007.confreaks.com/d1t1p1_what_makes_code_beautiful.html)

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

~~~
weavejester
Huh? Why is it illegible?

~~~
jrockway
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.

------
fnid
_Too clever_ is not determined by some property of the code, but rather the
audience who reads it.

