[EMAIL PROTECTED] (Alex Martelli) writes: > I do have (some of:-) that experience, and am reasonably at ease in > Haskell (except when it comes to coding monads, which I confess I still > have trouble wrapping my head around).
I recently found the article http://en.wikibooks.org/wiki/Haskell/Category_theory which had (for me anyway) a far more comprehensible explanation of monads than anything I ever saw about Haskell programming. Don't be scared by the title--the article is very readable. It's much clearer than many Haskell tutorials I've seen, whose monad explanations simply wouldn't fit in my mind, with weird analogies about robots handling nuclear waste in containers moving around on conveyor belts, etc. I think right now I could write an explanation of monads understandable by any well-versed Python programmer (it would be based on showing the parallels between Python's list type and Haskell's List monad, then moving onto sequencing with the Maybe monad, instead of trying to start by explaining Haskell I/O), so maybe I'll try to do that sometime. > Eckel's and Martin's well-known essays on why good testing can replace > strict static type checking: > <http://www.mindview.net/WebLog/log-0025> > <http://www.artima.com/weblogs/viewpost.jsp?thread=4639> Those are pretty unpersuasive since they're based on Java and C++. Eckel's example would have been much easier in Haskell, I think. Did you look at Tim Sweeney's presentation "The Next Mainstream Programming Language: A Game Developer's Perspective"? I wonder what you thought of it. It's here: Powerpoint version: http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt PDF version: http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf He advocates a mixed functional/procedural language with even fancier static types than Haskell. > Me, I'm always worried about significant code revision _unless I have > good tests in place_. Strict static typechecks catch only a small > subset of frequent mistakes -- good tests catch a far higher quota. It seems to me that the typecheck is sort of like a test that the compiler provides for you automatically. You still have to write tests of your own, but not as many. Also, Python-style unit tests usually are written for fairly small pieces of code. They usually don't manage to cover every way that data can flow through a program. E.g. your program might pass its test and run properly for years before some weird piece of input data causes some regexp to not quite work. It then hands None to some function that expects a string, and the program crashes with a runtime type error. Static typechecking makes sure that a function expecting a string can never ever receive None. I also sometimes have trouble figuring out how to write useful tests, though maybe there's some understanding that I haven't yet grokked. However, a lot of my programs crawl the filesystem, retrieve things over the web, etc. It's hard to make any meaningful tests self-contained. Last week I needed to write a 20-line Python function that used os.walk to find all filenames of a certain format in a certain directory tree and bundle them up in a particular way. The main debugging hassle was properly understanding the output format of os.walk. A static type signature for os.walk, checked against my program, would have taken care of that immediately. Once I got the function to work, I deployed it without writing permanent tests for it. An actual self-contained test would have required making some subdirectories with the right layout before running the function. Writing a test script that really did that would have taken 10x as long as writing the function took, and such a complex test would have needed its own tests (I'd have probably used something like dejagnu). For functions that simply transform data, I've been enjoying using doctest, but for functions like the above os.walk thing, I'm not sure what to do. I'd be happy to receive advice, of course. > Typechecks do catch some mistakes "faster", but, in my experience on > today's machines, that tiny difference is becoming insignificant, > particularly when you consider that typechecks typically require > whole-program analysis while, as Van Roy and Haridi point out, dynamic > typing affords "totally open coding". I don't know if this holds in Haskell, but at least in C, the compiler could usually find several errors in one pass, while dynamic types often mean running the program, seeing some function crash from getting None instead of a string, figuring out and fixing the error, running again, getting a similar crash in a different place, and repeating all the above several times. Lately I've been looking at a somewhat highbrow book on programming language theory: http://www.cs.cmu.edu/~rwh/plbook/book.pdf I don't understand that much of it, but the parts I can make any sense of are giving me a better picture of what PL designers these days think about. It's really nothing like how it was in the 1970's. -- http://mail.python.org/mailman/listinfo/python-list
