Today, I came across the following site (in Japanese) in which the
author made two claims about certain tasks that he believes that
purely functional programming languages are weak at. His claims are
interesting, and I would like to evaluate these claims through
discussion here:

Haskell $B$H$O(B ("About Haskell") [Japanese-language site]
http://www.shido.info/hs/haskell1.html

Specifically, he made the following claims concerning Haskell (after
describing that Haskell code is written so as to specify what value to
return):

>$B$3$N$3$H$+$i!"2<$G<($9$h$&$J<oN`$N%W%m%0%i%`$G $OM-8z$G$9!#(B
>
> * $B?tCM7W;;(B: Numerical Recipes $B$K:\$C$F$$$k$h$&$J%"%k%4%j%:%`!#(B
> * $BC5:w(B: $B5M$a>-4}$J$I$N7PO)$r5a$a$k$h$&$JLdBj!#(B
> * $B9=J82r@O(B: Haskell $B$N6H3&I8=`%3%s%Q%$%i!<(B GHC $B$O(B Haskell $B$G=q$+$l$F$$$k!#$^$?!"(B Perl6 $B$r(B Haskell $B$G=q$$$??M$,$$$k!#(B
>
>$B0lJ}!"0J2<$N<oN`$N%W%m%0%i%`$K$O8~$-$^$;$s!#=q$1$J$$$3$H$O$"$j$^$;$s$,!"(B $BB>$N8@8l$G=q$$$?$[$&$,3Z$G$7$g$&!#$^$?!"(BHaskell
$B$G$3$l$i$N%W%m%0%i%`$r=q$/$H!"(B $B<jB3$-7?8@8l$G=q$$$?$N$HF1$8$h$&$J%3!<%I$,=PMh>e$,$j$^$9 !#(B
>
> * $BIQHK$K(B IO $B$r9T$&%W%m%0%i%`(B: IO $B$J$I$NIT=c$J9T0Y$O(B Haskell $B$O6l<j!#(B
> * $BBg$-$J%G!<%?%Y!<%9$r07$&%W%m%0%i%`(B: Haskell $B$O=c?h$J4X?t7?$J$N$G!"%G!<%?%Y!<%9$r>/$7$7$+(B
$BJQ99$7$J$$$H$-$G$bA4BN$r99?7$9$kI,MW$,$"$k!#(BIO $B7?$N%G!<%?9=B$$r;H$($P$3$NLdBj$O2sHr$G$-$k$,!"(B $BC1=c$G$O$J$$!#(B

In translation, he claimed as follows:

>Therefore, it is valid for the following types of programs.
>
> * Numerical calculation: Algorithms such as those listed in Numerical Recipes.
> * Searching: Problems in which a path is to be obtained, such as the Shogi Mating Problem.
> * Parsing: Haskell's industry-standard compiler, GHC, is written in Haskell. Furthermore, there is a person who has
written Perl 6 in Haskell.
>
>On the other hand, it is not suited for the following types of programs. While these can still be written, it is probably
easier to write them in another language. Furthermore, if such programs are written in Haskell, code similar to that written
in a procedural language will result.
>
> * Programs performing frequent I/O: Haskell is weak at such impure behavior as I/O.
> * Programs handling a large database: Since Haskell is purely functional, even if only a small portion of a database
needs to be modified, there is a necessity to update the entirety. If an I/O-type data structure is used, this problem can
be avoided, but it is not simple.

In particular, I would like to investigate his claim concerning
"Programs performing frequent I/O," since currently, my main interest
is in creating a virtual world using a collaborative multi-user online
virtual world application, such as Croquet (see
http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
create an massively multi-player online virtual world in a functional
programming language, because it seems that a multi-user online
virtual world application might be easier to write in a purely
object-oriented programming language such as Smalltalk, rather than in
a purely functional programming language, such as Haskell or Clean.

Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?

(My intuition is that since a purely functional programming language
would try to preserve referential transparency, it would discourage
side-effects, which would be necessitated by most I/O (unless a
special mechanism to preserve functional purity were provided, such as
monads or uniqueness typing), whereas in a purely object-oriented
programming language, even atomic operations would be performed as
messages passed between objects, and that therefore, for this type of
application, a purely object-oriented programming language would be
better suited than a purely functional programming language, but I
could be wrong. If you think that my intuition is mistaken, please
explain your reasoning.)

-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^