Newbie question on "statefullness"

[Shawn P. Garbett]

> OTOH, if you want to do anything useful with any language you have to learn
> to do IO (and simple IO is tackled early in most languages), and therefore
> you must deal with Monads. I often wish that Haskell books and tutorials
> would introduce IO earlier; it is often near the end, in the "advanced"
> topics (after you've been dazzled/saturated by the magic you can do with
> list functions and comprehensions, and how easy it is to create abstract
> datatypes, and write parsers, etc...).

I think the fact that IO and efficient array updates, etc., are all best (to 
our current knowledge) handled in a pure function language by monads shows 
the actual underlying complexity that is hidden in many imperative languages. 
I drew an analogy between a state machine and an object that contained 
several variables once in a conversation. Vehement denial about an object 
being at all like a state machine came from the other parties. After much 
discussion, they conceded that yes an object really was a state machine but 
they'd never thought about it that way. The human mind is amazing in the 
level of complexity that it can deal with and the computations it can 
perform. Hidden complexity in programming languages however has led to 
numerous software problems that are common throughout the industry.

I just completed a project (with several others) that takes C code and 
crudely converts it into it's functional equivalent. The next step is to 
convert the output in a pseudo-language into true functional code. The number 
of side effects to deal with from some of the simplest expressions has been 
staggering. Most of the effort in the project was spent on the 
increment/decrement operators and switch and loop statements. Don't worry, 
there won't be a c2h (C -> Haskell) anytime soon for those who remember 
dealing with f2c (Fortran -> C) code, that's not the purpose of this project.

On a side note, Stroustroup recently wrote in an article about how the 
"hello, world" example was starting new C++ programmers down the wrong path 
from the beginning. He, of course, advocated using the iostreams and then 
went on to show several examples of wonderful things that could be done with 
iostreams. Iostreams seem to be closer to a functional concept than then clib 
printf variations. I think the book, 
_Structure_and_Interpretation_of_Computer_Programs_, by Abelson and Sussman 
is a much better freshman text because of it's functional approach. Real 
solid examples about the dangers of imperative constructs.

After years of warping my brain on C++ code, I'm enjoying learning the IO 
monad. It's starting to make sense at a much deeper level to me.

Shawn Garbett