Newbie question on "statefullness"
Shawn P. Garbett
Tue, 13 Aug 2002 08:34:24 -0500
> 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.