[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: functional languages ill-suited for large programs?
Vadim Nasardinov <email@example.com> 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
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.