Functional programming

[Steven D'Aprano]

On Tue, 04 Mar 2014 11:56:07 +0100, Antoon Pardon wrote:

> Op 04-03-14 09:56, Steven D'Aprano schreef:
> 
> 
>>
>>> If you
>>> explicitly say that this is an int, then yes, that should be
>>> disallowed;
>> It's that "explicitly" part that doesn't follow. Having to manage types
>> is the most tedious, boring, annoying, *unproductive* part of languages
>> like Java, C and Pascal. Almost always, you're telling the compiler
>> stuff that it can work out for itself.
> 
> In the same way writing unit tests is the most tedious, boring,
> annoying, *unproductive* part. 

Actually, I like writing unit tests. How do you know what the function 
does until you test it? I'm not a TDD fanatic, but often I write tests 
before I write the code, and there's really nothing nicer than seeing a 
whole lot of failing unit tests suddenly start working.

Well, maybe a nice BLT sandwich, when the bacon is nice and lean and the 
lettuce crisp and the tomato flavourful and not too soggy. But other than 
that, writing unit tests and seeing them pass is great.

On the other hand, writing

    int n, m
    double x, y

and similar three hundred times throughout your program is not terribly 
exciting. Even when it compiles, it doesn't mean it works.

> Amost always you are giving the program 
> results it can work out for itself.

Not even close. I'd like to see the compiler that can work out for itself 
that this function is buggy:

def sine_rule(side_a, side_b, angle_a):
    """Return the angle opposite side_b."""
    return math.sin(side_b/side_a)*angle_a


If you don't remember your Sine Rule from trigonometry, that's okay. 
Trust me, the function is badly wrong. It's rubbish really. But short of 
some really impressive AI coupled with a Mathematica-level of maths 
knowledge, how is the compiler supposed to know that?

Static type testing, while valuable, cannot tell you that the program 
does what you wanted it to do.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/