monad thinking process
Shawn P. Garbett
Fri, 25 Jan 2002 10:46:48 -0600
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 25 January 2002 06:14 am, Cagdas Ozgenc wrote:
> I have very little experience with monads. However my first impression is
> that there is too much thinking process involved in programming with
> monads, and it is very time consuming, at least for a beginner like myself.
> I don't know how productivity changes once you get used to programming with
> them. Also, I have serious concerns about the maintenance of programs
> written in monadic style. Since there is too much plannning overhead, it
> doesn't seem suitable for evolutionary software development process.
> What do monad experts think? What do you think of code readability? How
> easy is it to prove that programs written with monads are correct? How does
> changing one function affect other functions, in terms of maintenance?
I'm no monad expert, but I do have a strong opinion on this subject. I've
been programming for a living for twelve years now and various solutions have
been proposed over the years to the "Software Crisis". Structured
programming was a start, then onto actually designing things before
building them, code audits, client server, etc. The current round of snake
oils include UML, CMM, and object-oriented programming. These things did and
do help, but the core root underlying problems of software development still
seems to persist. Dijkstra refered to current development methods as
"attempting to discipline the undisciplined." I've been looking for
something to make my means of making a living easier for years.
In a discussion of this Dr. Stacy Prowell, he told me an interesting idea.
Imperative programming creates logical structures that have state, yet none
of the mainstream development methods of software directly address any of the
known mathematical properties of state machines. Sure you can make a
state-diagram, but where is there a consistent mathematical approach to
state-machines in imperative programming? Most beginners are encouraged to
just think about the problem, maybe even do a little design and begin coding.
Dr. Prowell's main research into cleanroom software development is the
opposite of this. Cleanroom is a treatment of software development as a
concise mathematical state box.
What's the benefits of the current methods of "Cleanroom" software
development? Reliable well defined software. The space shuttle control code
team uses a variant of cleanroom with an obsessively huge number of code
walkthroughs. The cellular industry uses it to create rock solid reliable
phone switches. Some medical companies are using it to try and prevent
another Therac-25 incident. Even some linux kernel developers apply it to
get rock solid behavior from their hardware drivers. Test cases for a
Cleanroom model are derived in a mathematical way.
What's the problem with it? It's more expensive in time, upfront time costs,
maintenance cost is incredibly reduced and an overall cost savings has been
demonstrated. It's also horribly tedious in addition to not being well
understood or adopted by the mainstream.
I personally have been working on a set of automated tools to take all the
tedium out of the process. I'm quite close to that goal and heading toward
automated code generation.
The state monad is a perfect for application of cleanroom techniques. If one
followed a cleanroom enumeration through to a canonical state box, a state
monad could implement it in a canonical understandable form. The behavior of
that state monad would be mathematically well defined.
Sitting down and writing state monads from scratch just by thinking about it
leads back down the path of the "pitfalls of imperative programming." It's
quite easy to do with a small problem, but the moment you get into a larger
problem--it'll be back to the hack/test cycle. Imperative and state based
programming is necessary for a large number of problems in computer science.
Why not apply computer science to the construction of their solutions? The
use of the Cleanroom model leads mathematically to a canonical construction
of a state monad.
"Evolutionary" doesn't have to mean hack/test. It can be done in a logic
manner. I highly recommend reading the book
_Cleanroom_Software_Engineering_. It's the Cleanroom method covered with a
case walkthrough, without the hardcore math. If you're interested in the
mathmatical reasoning behind the method, then check out Dr. Prowell's
>stepping off the soap box<
 _Structured_Programming_: R.C. Linger, H.D. Mills, B.I.Witt, 1979,
Addison-Wesley Publishing Company, Inc. This book is one of the early books
that advocates structured programming and many of the practices that were
adopted early in computer science. Cleanroom methodology is a logical
descendent of the math in this book.
 Dijkstra's lecture notes
 _Cleanroom_Software_Engineering:_Technology_and_Process_, Stacy J.
Prowell, Carmen J. Trammell, Richard C. Linger, Jesse H. Poore,
Addison-Wesley, 1999, ISBN 0-201-854480-5
 _Sequence-Based_Software_Specification_(Ph.D. Dissertation), Stacy J
Prowell, University of Tennessee, May 1996.
 _Structure_and_Interpretation_of_Computer_Programs_, 2nd edition, Harold
Abelson, Gerald Jay Sussman, Julie Sussman, MIT Press/McGraw-Hill, 1996, pg
You're in a maze of twisty little statements, all alike.
Public Key available from http://www.garbett.org/public-key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----