Cagdas, Is it possible for you to give an example where you think there is too much thinking involved? I dont see it. Writing haskell IO with monads (with the Do notation) is just a straightforward as writing C code for the same steps, isnt it? Just try not to think about it too much :) Cheers! --- Cagdas Ozgenc wrote:

Greetings.

I have very little experience with monads. However my first impression is that there is too much thinking process involved in

__________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 25 January 2002 06:14 am, Cagdas Ozgenc wrote:

Greetings.

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[1] 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."[2] 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[3] is the opposite of this. Cleanroom is a treatment of software development as a concise mathematical state box[4]. 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[5]. 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."[6] 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_[3]. 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 dissertation[4].

stepping off the soap box< Shawn Garbett

[1] _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. [2] Dijkstra's lecture notes [3] _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 [4] _Sequence-Based_Software_Specification_(Ph.D. Dissertation), Stacy J Prowell, University of Tennessee, May 1996. http://www.cs.utk.edu/sqrl/publications.html [5] http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html [6] _Structure_and_Interpretation_of_Computer_Programs_, 2nd edition, Harold Abelson, Gerald Jay Sussman, Julie Sussman, MIT Press/McGraw-Hill, 1996, pg 234-6. - -- 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 iD8DBQE8UYv5DtpPjAQxZ6ARAsmDAJ9kCqNTSZY12fY8L4WP5z6YD8qPjQCfS6VL udCs4jlc3ppHYSvu/ai22Po= =1HMT -----END PGP SIGNATURE-----