Why functional Python matters

[Thaddeus L Olczyk]

On 17 Apr 2003 17:53:15 +0200, Nils Goesche <cartan at cartan.de> wrote:

>Thaddeus L Olczyk <olczyk at interaccess.com> writes:
>
>> On 17 Apr 2003 16:27:53 +0200, Nils Goesche <cartan at cartan.de> wrote:
>>=20
>> >A definition that seems sensible to me would be something like: A
>> >language is functional if it somehow contains the lambda calculus.
>> >If you can take lambda calculus formulae and readily translate them
>> >into working code.
>
>> That makes nearly every modern language functional.
>
>Certainly not Java or C# ;-)=20
Yes. Both contain lambda calculus. As does any language
which supports objects.

In ( a sort hand wavy way ),
class Lambda
{
public:
        retval exec(arglist){...}
}

Java ( can't say I know enough about C# ) may lack some syntactic
sugar to make it pretty, but it's there.

>But even if that's true -- then so be it.
>If it is true that modern languages tend to be functional, too, then
>you could call that progress.  Why should we change the definition of
>``functional=B4=B4 every year in order to keep the ratio of functional t=
o
>non-functional languages constant over time?
>
While it's true that in math and CS, many definitions evolve over
time ( ones that come to mind right now are function/procedure
[which were distinct, now considered the same thing], fiber bundles,
sheaves, topological space ... ), that's all just bullshit thrown out
to distract people from *your stupidity*.

That's because the definition that you have suggested is not some
formal definition appearing in seminal "Introduction to Functional
Programming" type books or papers. It's *your* definition, and it
sucks. Because it's your definition and not a formal one, there is
no suggestion that I am changing the definition over time. As I said,
it's simply a distraction to hide the fact that your definition
*sucks*.

As for your definition, it sucks because it fails to make any
distinction. Almost everyone would agree that languages like
Haskell, ML, Clean, Scheme and  ( sometimes ) Lisp are functional.
And your definition includes those. But your definition would say that
languages like C, Eiffel and Smalltalk ( not to mention C++, Java and
C# ) are functional, which almost no one would agree with.

>> >And you have to be a bit relaxed when using this requirement; for
>> >instance, writing an Y-combinator in ML is very hard because of the
>> >stupid type checker.
>>=20
>> No it is easy.
>>=20
>> In OCaml,=20
>>     let rec fix f x=3Df (fix f) x;;
>
>That's cheating and you know it :-)
>
No. It's not.
It's a standard definition of Y in a combinatorial approach
to computing.

>> For a more traditional approach.
>> type 'a rf =3D RF of ( 'a rf -> 'a );;
>>=20
>> let y f x=3D=20
>>   let g (RF h) z=3D
>>       f( h (RF h) )  z in
>>   (g (RF g)) x;;
>>=20
>> Of course the example above looks like:
>>    let fact x=3D y ( fun q->
>>                              (fun n->=20
>>                                 if n<2 then 1=20
>>                                 else n* (q (n-1)))) x;;
>>=20
>> When I did it this way the first time it was a bit difficult getting
>> the type right.
>
>I know: Been there done that ;-\  Took me some time. =20
What can I say. Some people are slower than others.

>Certainly /much/
>longer than simply translating the lambda calculus formula to Lisp, so
>I refuse calling it easy, even if the ML code that finally works is
>short.
And know we see why some people are slower.
I never even thought of "translating" the code.
I did what every one is taught in every math class.
I rederived it in ML. In the process I found it easy.
The only sticking point was that I did not understand
user defined types well enough to write HOFs. Once
I understood that it was trivial.

>
>> But the reason was that I was new to the OCaml typing system. It
>> wasn't what the type should look like, it was just getting the
>> declaration right.
>
>If it's so easy, why did they even bother putting it into the ML FAQ?
Because there are lazy people who don't write code from first
principles, or bother to learn enough about user defined types
to write HOFs ( the true FP practitioner doesn't just use HOFs
he writes them too ).

>
>> While not an expert, I should say this type of infinite cascading
>> type and data is typical of a class of ML programs. I believe the
>> little MLer has an example early on.
>>=20
>> This should also be easy for a Lisper/Schemer to grasp as it just
>> extends on some of their ideas.
>
>Sure, once you know how to do it, it seems easy and obvious.  But that
>is true about almost all problems.
No. It's easy and obvious because I learned enough OCaml to make it
easy and obvious. These are aspects of the language which are
fundamental, and anyone taking a professional approach to programming
in ML should be familiar with it enough to understand how to write
HOF's. It's only hackers who have a hard time implementing Y in ML.


--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.