On 8/9/06, Francis Cianfrocca <garbagecat10 / gmail.com> wrote:
> On 8/9/06, Simen Edvardsen <toalett / gmail.com> wrote:
> >>>If the "natural" way of modeling computation is that of moving around
> bits in memory and doing trivial operations on them, we wouldn't be
> building all these kinds of fancy abstractions, now would we? Also,
> Ruby is full of higher order functions, so saying FP is not for
> mainstream use but Ruby is a step in the right direction seems a bit
> od<<<
>
> Give that a bit more thought. Most of the "fancy abstractions" are
> attempts to map aspects of particular problem domains into language
> constructs. And what are the typical things we do with our fancy
> abstractions? They are mostly about *transport* and communications. We
> create purchase orders and store them in databases, then we email them
> to vendors. We make accounting calculations and then generate reports.
> We send email and instant messages to each other. These operations are
> undertaken primarily for the side effects they generate (or
> alternatively, the persistent changes they make to the computational
> environment).  Constructing mathematical fields to solve these
> problems rather than scripting them imperatively is arguably a less
> natural approach. True functional languages do not have side effects
> at all, or they are considered hybrid if they do (SML for example).
>

Understanding why something works and how it works and how we might
make it work more easily seems worth making a science about. For the
record, I find adding complexity to satisfy mathematics at best an
academic exercise.

> Now you and many others may argue with much justification that true FP
> is just as valid for constructing nontrivial programs and in many ways
> better. Fair enough. But in the real world, I've become convinced that
> more programmers will do "better" work (where "better" is defined in
> economic terms as high quality at low cost) with imperative languages.
> And the reasons why are certainly of interest, but only of theoretical
> interest.
>

Pure FP seems to complicate making complex systems. I've been trying
to learn Haskell, but lifting values in and out of layers of monads to
achieve simple state seems needlessly complicated. I believe Clean has
an alternative solution to state in a pure functional language -- I
don't know if it's any better. Anyway, my point is that non-pure FP
languages produce shorter and more readable -- more "pure" and
"elegant" if you like -- solutions to many problems. I'm no hardcore
FP advocate. There is no one solution that fits all problems.

> Ruby's "higher order functions": aren't you confusing the true
> functional style with the simple ability of Ruby (and many other
> imperative languages) to treat functions and closures as objects?
>
>

True, they're not really mathematical functions, but how is map, each,
inject etc. not higher-order functions? Ruby favors functions (well,
methods) that take blocks (aka closures). The definition of higher
order function from Wikipedia:

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.

-- 
- Simen