Functional programming

Antoon Pardon antoon.pardon at rece.vub.ac.be
Wed Mar 5 09:59:14 CET 2014


Op 04-03-14 12:47, Steven D'Aprano schreef:

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

You examine the code. Just like you examine the code to interfere the type. 

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

Even if your unit tests pass, that doesn't mean your program 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:

Who said anything about buggy. If you want to test the function add1, what do you do?
You call for example add1(5) and check that it is equal to 6. In other words you provide
the result yourself you want the function to produce.

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

In the same way it can't interfere the return type you want the function to have.




More information about the Python-list mailing list