I'm glad to know I'm not the only person who works this way. My source files often have a paragraph or two at the top that explains my intentions for that class/module as well as explains the usage of my domain language. I never see this in other people's code though.
I agree with people who say that the code itself should read very clearly, but the fact is that even when writing an article or paper you have to disambiguate your own writing, clarify your usage of terms and present some context up front. Otherwise people can take away a very mistaken impression of your text, and it is certainly no less true for code.
Quite interesting, I do something similar to that on a smaller scale.
When I do a class/method, I usually just put comments describing what's going to happen and that makes me thing of cases I might have missed otherwise and then I add the code below each comment.
Will try literate coffeescript next time I use it.
When the paragraphs have code below them that does what they say they do, the thing works. When I end up coding myself into a corner, I rewrite the paragraph and change the code. It's really a very different process than usual. It's also definitely more work than just doing code and omitting comments -- it takes a bit of elbow grease to prevent the comments from becoming lies ... but it's the same type of work as preventing bits of your codebase from becoming dead code.
For me, it seems to make me organize code into smaller functions grouped together into sections, use less classes, and care more about putting things in the place where you're talking about them, and less about putting similar things together in one block of code. For example, I started to require things close to the paragraph where I first mention them, instead of putting all requires at the top of the file. At least, that's how it feels so far.