Re: functional languages ill-suited for large programs?

[Jim Blandy <address@hidden>]

"Perry E. Metzger" <perry@piermont.com> writes:

> Jim Blandy <jimb@redhat.com> writes:
> > 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.
> 
> That's not necessarily the case. The optimizer for a pure functional
> language will know that a function is pure and can handle
> memoization/caching behind your back. That requires more work on the
> part of the compiler, but there is no reason that it can't be done.

Sure.  But the question wasn't whether users would find a given coding
technique unavoidably necessary under every implementation.  It was
whether pure languages could require people to use less intuitive
interfaces.

That is, whether or not it's *worthwhile* to memoize a function, a
pure lazy language doesn't even allow me to *express* a memoized
function behind a purely functional interface, even though the
resulting behavior is purely functional.

In general, I'm not fond of the "sufficiently advanced compiler"
argument.  It can be applied to so many circumstances, but it sheds so
little light.