[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: functional languages ill-suited for large programs?

Vadim Nasardinov <el-vadimo@comcast.net> writes:

> That's what Peter Van Roy is claiming, if I read him right.  In
> http://lambda.weblogs.com/2003/10/22#a9361, he writes
>     In our experience, true state (destructively assignable entities)
>     is essential for reasons of program modularity (which for this
>     discussion I take as meaning: the ability to change one part of a
>     program in a significant way without changing the rest of the
>     program). Threaded state, e.g., monads as used by Haskell or DCGs
>     as used by Prolog, cannot substitute for it.
> Not having used any functional language, I don't have an opinion one
> way or the other, but would be very interested to hear what others
> think about this claim.

I can think of one case where pure functional languages make nice
interfaces difficult.

Suppose you've got a function that takes some time to compute, but you
know that once you've applied it to one value, you're likely to apply
it to that same value again soon.  In a stateful language, you can
wrap a cache around your function without changing its type.  But in a
pure functional language, each call to the cached version of the
function must take the cache (or something containing the cache) as an
explicit parameter, and return an updated version; the caller must
thread these values along from each call to the next.

The problem is that the cached version isn't a stateless function any
more.  If you've coded it right, you could prove that it acts like
one, but it's not coded as one; a pure functional language requires
you to reveal that.