From: Simen Edvardsen <toalett@...>
Date: 2006-08-10T00:37:42+09:00
Subject: Re: Language chatter

On 8/9/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> Simen Edvardsen wrote:
>  >
> > In mathematics and computer science, higher-order functions or
> > functionals are functions which do at least one of the following:
> >
> >     * take one or more functions as an input
> >     * output a function
> >
> > According to this definition, Ruby's standard library is filled with
> > higher order functions, as are the libraries of Ocaml, Scheme etc.
>
>
> This comment is extremely interesting. It is actually *not* the case
> that Ruby's "functions" are functions in the mathematical sense. They
> are actually objects that point to blocks of executable code or to
> closures. They have the ability to execute instructions that modify the
> contents of memory or produce other side effects so as to make visible
> the results of operations that simulate mathematical functions.
>

Yes, in the post you quoted I said that Ruby functions are not true
mathematical functions. My point still holds: functions, or methods or
whatever you'd like to call them, that operate on closures (regardless
of whether the closures are themselves purely functional) is a very
functional idea. Whether you call it "Higher order method" or
something else, it's still a functional idea.

> But true functional languages directly expose composable mathematical
> functions (mappings from a possibly infinite domains to ranges). Pure
> functional languages don't expose any side effects at all. They are
> extremely effective at modeling computations (I once wrote a complete,
> correct qsort in 7 lines of ML) but not very good at executing
> communications or data transport tasks, which are all about side
> effects.
>

What about Erlang? It's not purely functional, but it certainly favors
a functional style and is used extensively at tasks that seem exactly
like the ones you describe.

> I've often been mystified when people talk about Ruby's metaprogramming,
> closures, lambdas, etc. as constituting a "functional" programming
> style. Your comment is striking because it made me realize that perhaps
> many people who learn languages like Scheme are actually trying to apply
> the imperative, Turing-style computational model to languages that don't
> support them. And that reinforces all the more my intuition that pure FP
> is not well-suited for mainstream professional programming.
>

Perhaps not pure FP. I can agree with you on that. But a functional
style and ideas like closures, higher-order functions, pattern
matching etc. are all good tools which the mainstream could benefit
greatly from.

> Years ago, I spent a lot of time trying to teach professional
> programmers to grasp the functional style. And most people couldn't even
> let go of the concept of variables as little boxes holding readable and
> writable values. That's when I gave up on FP.
>
> --
> Posted via http://www.ruby-forum.com/.
>
>

But as long as *you* understand FP, there's no reason to give up on
it. Surely there are other intelligent programmers out there who
understand it too. I'm not saying we should abandon imperative
constructs altogether, as you seem to imply.

-- 
- Simen