Re: functional languages ill-suited for large programs?

[Jan-Willem Maessen <address@hidden>]

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.

This is actually a fair critique of Haskell.  You have a choice: write
programs in the beautiful, purely-functional part of the language (in
which case you have to use unstable but widely-known hacks to hide
certain sorts of side effects), or write programs in the much clunkier
monadic sublanguage, where you need to name all your subexpressions,
the order of evaluation is fixed, and you can use as many side effects
as you like.

It's a problem.  Another problem is that you end up writing at least
two versions of higher-order library functions---the monadic version
and the non-monadic version.  There are Haskellers who are deeply
uncomfortable with this and are trying to come up with clever ways to
fix it [I've tinkered a bit here with moderately encouraging results].
I can't think of a non-Haskell-like functional language where this
criticism applies (I can't comment on Prolog et al).  Most
"functional" languages I know about incorporate unrestricted side
effects of some sort.

Meanwhile, Rishiyur S. Nikhil is giving a talk on Bluespec at LL3.
Bluespec is (roughly) Haskell for hardware.  The compiler is written
in Haskell and the language is Haskell-like.  Last I heard both the
compiler and the language itself were running into exactly these
issues.  This would be a great topic for discussion there.

-Jan-Willem Maessen
jmaessen@alum.mit.edu