Carried away in the monads? was: RE: Running out of memory in a simple monad

[David Bergman]

Richard wrote:

> some are using Haskell for "systems programming", as a better C
> than C.  some, including me, would like to see more of that,
> with Haskell or another pure functional language with an IO monad
> taking systems programmers away from the C and C++ communities.

That is good, I would probably call myself a C++ developer primarily,
but Haskell + the IO monad is a much better choice (even better than
Perl...) in most situations.

> Hugs is completely useless for *that*.

Yes, it is, although it is great for testing the validity of one's
Haskell programs.

> for an example of Haskell as a better C than C, see Chak's Gtk+
> bindings.  to use them you must write your whole GUI in the IO monad
> in a style where the basic data structures and control structures
> closely resemble what you would write in C.

I have seen it, and it is a bit imperative in its style.

> many Haskellers have a negative opinion of such heavy use of the
> IO monad, but in systems programming you need more control over
> when (relative to other interactions) your program performs an
> interaction with a file, network or UI resource than is available
> in Haskell without the IO monad.

I must confess that I belong to that "theoretical" group, although I am
a systems programmer (i.e., developing real systems for real customers,
paying real money).

In my opinion, the use of categorical monads in a programming language
is a brilliant intellectual achievement, combining the "pure" and "real"
in programming, at least on paper... This is where the Haskellers
divide: one group (me included) consider the hidden state in monads as
falling back to imperative thought patterns. In some cases, as in IO, we
need to have a state, obviously, but it would be beneficial if we could
divide the logic into state independent (defined outside the monads) and
state dependent code (defined within the monads; such as IO).

It is a bit like some "C++" developers I meet, who consider themselves
to develop in C++ just because they use "const" or "&" (reference):
functional programming is about choice of language and choice of
programming style.

/David