Such tools work in a very similar way to what is already being done in many modern language compilers (such as javac). Basically, they implement semantic checks that verify whether the program makes sense, or is likely to work as intended in some respect. The keywords here, for the purposes of good static analysis tools, are "work as intended". Knowing what code is intended to do isn't trivial, and it can be severely limiting in what static analysis tools can check for (or, alternatively, they can spit back a lot of false positives). A good solution is provide the static analysis tool with some hints as to what the programmers intentions are -- that means annotations as used by splint, or ESC/Java2, or something similar. The benefits for static analysis (and API documentation depending on the tools) can far outweigh the "extra" work*; consider the sorts of errors ESC/Java2 can successfully catch for instance. Of course you have to be interested in doing static anaylsis to begin with, btu the benefits are definitely available.
* Note that "extra" is in scare quotes because ultimately most of the annotations are usually things you should be documenting anyway, so it's not so much "extra" work as documentation that gets done sooner rather than later.
Think about what it would be like if the command "ls" was named something different in every linux distribution. Part of Microsoft's success is that there are GUI contracts that are very rarely broken so you almost always know how to do basic tasks with a new program. Sigh. Time to trot out the screenshot yet again. All those Microsoft applications in that screenshot all work the same right? The menu in notepad is just like the complete lack of a menu in Word and Media Player? And while IE and Windows Explorer look the same at first glance, having the spacing and arrangement ever so slightly different is all part of some master plan? The (complete lack of) consistency in how toolbars are presented in Word, Outlook, IE and Blend is carefully arranged?
In the meantime GNOME and KDE both have Human Interface Guideline documents that spell out how applications should work to be consistent, and, oddly enough, most applications for the respective desktops hew to them rather well. You can certainly expect a more consistent environment than Windows apparently is these days (even if you stick to MS software)!
Microsoft... mostly consistent, but there are some old windows 3.1 holdeovers (control insert to paste) and a lot of their apps don't adhere to the look and feel (Expression, for example). X is probably the worst in this regard, being a hodge podge of different toolkits, raw xlib, control-v vs alt-v vs middle click to paste, etc. Right, yes, Microsoft has a very consistent GUI. Those are the latest versions of Microsofts own appliactions. Not only is the look different from one application to the next, but how the program actually operates is different. Some have menus, some don't. The menus aren't even consistent across the set of applications that do have them. Several applications, while similar, just work slightly differently for various things like opening files, or setting preferences. Hell, they can't even decide whether the text of the titlebar is supposed to be centered to left justified!
But what about X11? Well, these days, if you're using GNOME, or KDE, or Xfce, and applications written for those environments (which is to say most modern applications for X11 desktops) then you only have two toolkits, which can be themed so they render using the theme of the other (using either GTK-Qt theme, or QtGTK Style), and has consistent cut and paste that works across (and between) them all. Yes, you can get some Xlib applications if you hunt around, but then you can get ugly Tk applications on Windows if you hunt around (or X11 applications on the Mac). The reality is that, these days, the Linux desktop really isn't that much more inconsistent that Apple or Microsoft. Actually, I would go so far as to say that it is actually more consistent than what MS is currently producing.
I think the best thing that could happen for Linux on the desktop is for one of the two major environments (I don't care which) to become THE standard, supported Linux X desktop standard.
I know, choice is good. So is focusing your efforts on making one usable product that people can standardize on. People keep bringing this up, but it just isn't going to happen. FOSS developers will work on whatever they want to work on, and as long as there are different philosophies involved different projects will attract the interest of different developers. And there are very different philosophies driving the different desktop environments: GNOME is pitching for something simple and elegant above all else; KDE is far more interested in being configurable and cohesive; Xfce has efficiency as one of their primary goals; and the list goes on. With such divergent focus you are not going to get people (neither developers nor users) to all agree on one philosophy.
What you can do, however, is work on standards and interoperability of protocols that underly the environments. You know, like Freedesktop do. That means common standards for inter-application communication (from cut and paste to DBUS), standards for how applications expose themselves to menus, standards for syustem trays, and so on. This effort is still ongoing, but the end result is that GNOME, KDE and Xfce can share application menus, system trays, clipboards, icon themes, and more. With other things like the GTK-Qt theme and the QtGTK Style, we're steadily heading toward the point where applications will be able to slot in seamlessly competing desktops.
So in some sense what you want is being done, but it is not going to involve one desktop to rule them all. For that you need dictatorial control from on high to simply say what is "right". You won't get that in FOSS; it's just not how it works. If you want that you need something like Apple or Microsoft, and the consequences that come with such choices (although, to be honest, I'm not sure they offer models of perfect consistency either).
I don't really care to quibble over most of this, but you have a rather weak point here:
The only facts we know are that he translated 116 pages, they were lost or stolen, and he refused to translate them again. Either he was less capable of faking something twice than once or he was afraid of being framed.
I really don't think you have a strong case for the former, and my only point is that the latter is just as plausible. I'm under the impression that Joseph Smith was illiterate; that means that, presuming he was faking, anything he "translated" would have to be a narrative he simply made up as he went. That means that faking it twice (producing identical text as "translations") is going to be very hard indeed, so yes, it seems very reasonable to expect that he was less capable of faking something twice than once -- making up a story is easy, but remembering the exact words you made up the first time is hard. That makes for a fairly strong case for option one, so I don't see how option two is "just as plausible" given, as the OP pointed out, there were other options available than simply refusing to ever translate that passage again.
Doom 2 was in no way shape or form the least bit revolutionary; it was Doom souped up a little. Doom 3 was, to my mind, very clearly going to be more of the same, albeit with better sgraphics and sound. Doom was revolutionary because it really opened up/created the FPS genre (other games, Wolfenstein for instance, existed, but Doom was the first to really mine that territory). How exactly were you expecting Doom 3 to be revolutionary? It was clear from the outset that it was going to be and FPS game, and in the spirit of Doom; that doesn't leave much, if any, room for a revolutionary new style of gameplay to fit in. It seems to me that anyone with expectations of something utterly revolutionary simply weren't thinking.
Wow, talk about bitter. I forked over the cash for the game, but didn't need to upgrade my PC. Doom3 didn't run at maximum quality, but it wasn't bottom end either. And I enjoyed the game; it was, to my mind, what the original Doom had aspired to be, but couldn't because of the relative lack in computing power at the time. It was tense, scary, and fun, and the quality of the graphics and sound were what made it the experience it was.
Having said all of that, I also understand some of the complaints. It was repetitive, and it certainly didn't bring anything new in the way of gameplay to the table (I didn't mind because I was looking for "Doom done right", but I can certainly understand that others would appreciate more creativity). I don't understand the bitterness though; it seemed pretty clear what Doom3 was going to offer in the way of experience (especially given that it was following after Doom and Doom2 which were repetitive, had fairly simple gameplay, and were pitch black at times). I don't really see that the game was ever misrepresented in what it was going to be, so I'm not sure where you got your expectations and feeling of entitlement from.
One of the nice things from this article was actually this nice screenshot of a selection of current versions of MS software running on Vista. The thing to notice is that not a single one of those applications has a GUI the same as any of the others. There are different toolkits, completely different look and feel, some have menus, some don't; it's a horrible, horrible mess. And yet despite that, we still get people complaining about GNOME vs. KDE and the clash of different toolkits and how that's what is holding Linux back. You can run GNOME and KDE apps side by side and, while they'll have differences, they'll sit together far more elegantly than the mishmash that is Windows. I think I'll have bookmark that screenshot so I can bring it up the next time a Windows fanboy starts decrying the excessive number of GUI toolkits on Linux.
Good luck trying to overthrow your corrupt government with those arms you're allowed to bear, Jim Bob. I dunno, a minority of Iraqi's seem to be giving us a hard time with AK47s and IEDs... They are hardly at the point of overthrowing the government, or defeating the US military. Sure, US forces may soon be vacating Iraq, but that's far more to do with a lack of will to send US troops abroad to occupy a foreign country. I doubt you'd find similar antipathy toward combatting "terrorism at home" (and make no mistake, that's what it would immediately be branded). If you want a revolution what you really need is popular support -- and you won't get that by taking the violent approach that results in collateral civilian deaths.
IF Ubuntu (or release of your choice), WAS more like Windows, just think how much higher the adoption rate would be for it. Imagine how EASY it would be if you could show people with only a Windows background, "look, you do the same things and get the same result - only this one is free, doesn't come cluttered with DRM, isn't susceptible to malware etc etc". Except that adoption rates would very quickly plateau at the small range of people who are cheapskates and want a free Windows clone. Other users either wouldn't care ("I already got Windows for free with my computer"), or would be frustrated by the inevitable differences (no matter how much you make it superficially like Windows, there will be differences; e.g. the inability to run Windows applications etc. will always be a barrier). A Desktop Linux that is just a cheap clone of Windows doesn't offer much at all since it will always be playing catch-up to try and be exactly like the latest Windows.
No, the real long term answer is to not be like Windows; do things your own way with the aim of doign them better. I use Linux not because it is free, nor because it lacks viruses (though it's nice bonus) but because, for my needs, it is better than Windows. To be better you have to be prepared to b e different. The reason there isn't huge uptake of desktop Linux is because of that "for my needs" clause. For my needs it is better than Windows, but every user has slightly different needs. The number of users for whom Linux offers something better is expanding, but is still pretty small; since needs tend to include all sort of weird little niche requirements (which differ from person to person), the expansion is very slow (but reasonably steady). There is not going to be a "year of the Linux desktop"; rather there is simply going to be a slow but steady increase in the use of Linux on desktops (was there a "year of the Linux server"? No).
Trying to make something superficial that will get more switchers now is pointless; be patient and cosider the long term of goal of simply being as good a desktop as you can. Compare RedHat 5.2 and Windows 1998; then compare Ubuntu 7.04 and Windows Vista; the gap in quality and usability as a desktop has been closing steadily.
Or mostly because building a large tree of assumptions has fallen out of favor. Requirements and technologies change. The world is not static. That presumes, of course, that by "think first" I mean "design the entire application from soup to buts in your head" as opposed to "get a clear idea in your head of exactly what you want this next function you're going to write is supposed to do. The latter, of course, is perfectly compatible with agile development. TDD asks you to design a test for the code block you're about to write. Literate programming asks you to think enough about the code block you're about to write that you can write the documentation up. DbC asks you to provide the requirements you intend to have on the code block you're about to write. All of this can be quite agile, and none of it asks you to use a waterfall "design everything first" approach.
No, it's quite clear, and I agree, everything has its costs and tradeoffs, and won't make sense for every project. You have to evaluate what's going to be most useful. I will maintain, however, that a mix of several is often going to be better than picking one as the silver bullet (which these days seems to be unit testing; who knows why -- it takes just as much time as the others as you point out).
Unless you are doing a rewrite at several iterations you are still ending up with "evolved" code, which is almost always a lot less pretty and a lot less maintainable than the same design written cleanly with the ultimnate final design decisions in mind right when you start.
Sure, if you like, just stick "document properly" in the "clean up and refactor" step and you can happily include literate programming. As much as you like to talk about being completely agile, a great many software projects do have distinct milestones and aren't simply in a constant state of flux. Not every software project is like the projects you work on.
Summary: Documentation has a cost; most people write code to be consumed by machines, not other people; and not all projects justify the effort. Documentation does indeed have a cost, and certainly not every project justifies it. I would contend, however, that most people write code that will spend a great deal of time being consumed by people (for the purposes of maintenance and debugging); just think of how many projects are still kicking around and still being maintained longer than the original author might have forseen.
Unfortunately there's not much you can do with a short term, next quarter, driven outlook that fails to do any accounting for maintenance and expansion. If your managers are that stupid then yes, you probably are screwed.
Well it's only incompatible if you just ship whatever the last iterating happened to be, rather than taking away all the lessons learned from those iterations (including, potentially, large chunks of the code) and writing a nice clean final version with good documentation (the documentation can, of course, include many of those "lessons learned", particularly why various design decisions wwere made etc.); that version can make good use of literate programming. In that sense literate programming is actually pefectly complementary to iterative/agile design. The other complementary technique that many agile/iterative/TDD fans seem to think is incompatible for some reason is lightweight formal methods -- it's actually very nicely complementary and goes espcially well alongside TDD. Google "lightweight formal methods" + "agile" sometime.
Yes! I like writing code to see how things pan out, it's one of my ways of thinking about what the problems and goals are. But I don't intend that to be the final code - make a cheap throwaway prototype, then make the final product, possibly salvaging bits of the prototype. Don't get me wrong, and not arguing against that. Neither is Knuth. He mentions such scenarios as one of the cases when he does find a use for unit testing. That's part of the "thinking" stage. From what I gather from the interview Knuth tends to do that with pencil and paper, but you can do it just as well by mucking out some example code and test cases. The point, as you note, is that it isn't your final code: it is that "final code" step (once you've figured out what you want to do) that literate programming really comes in (and in this sense is orthogonal to TDD and similar approaches).
One would hope that you get to the final system design by iterative prototyping, which you then clean up, refactor, and rewrite into a nice codebase that doesn't have the evolved and iterative cruft, and is suitably documented (it's this last step where literate programming an come, though you can introduce some incrementally as modules and subsystems get frozen and rewritten). Who knows, maybe you do just ship the first thing you can get to work. What I do know is that in the business world where time is money, the clean well documented final version is going to involve a lot less time (and hence a lot less money) to maintain and debug and patch. And what if I want a new version next year? Well I would certainly prefer to have a clean readable well documented codebase to work from than "whatever worked" code. Maybe that's just me though. Different people work differently, and I'm sure you do what works best for you.
Well yes, and as someone else pointed out, the underlying idea of TDD bears some similarities in mentality with the ideas driving literate programming. It's a think first approach in many ways. I would add that they aren't really so much competing and complementary ideas. If you think TDD is good, then you might want to look at literate programming (or lightweight formal methods) and see if there aren't some ideas you can extract and make use of in conjunction with your TDD.
I've seen RSpec. Personally if I'm going that route I would prefer stepping up to proper specifications like JML. It's definitely better for providing documentation, at least in the form of API documentation. Then again, Eiffel or Spec# wold also fit the bill. I'm not really knocking RSpec: it's really very nice -- I'm more trying to point out that there are a few more strings you can add to your bow if you like that sort of approah (ad that literate programming is still one of them).
Good tests *are* documentation. To me, what you're saying is that TDD and literate programming are just two variations of the same approach. Good tests are a form of documentation, but I wouldn't suggest that they're an especially good one. Tests as documentation are certainly better than no documentation, but they do have serious shortcomings. First and foremost, they're not the easiest to read since they're code, not English (or your preferred native language). Tests also suffer from being case specific; they tell you how the code should function under some circumstances, but generally don't provide clear bounds on when and how it won't work, and why.
Now, that's not to say that TDD and literate programming don't have some similarities -- they both have a mentality of putting your intentions down in some clear fashion before providing the code, Of course there are similarities between TDD and lightweight formal methods (in the form of specification driven design) and design by contract. In general I think all of these ideas are good, and given that they are either orthogonal (as TDD and literate programming are) or compatible (as TDD and SDD and DbC are) it makes sense to use all of them in as much as they make sense for the project at hand.
I think, perhaps, you're missing the point. Go ahead, build a prototype and try out ideas. Do the Brooks thing, and build one to throw away. Work out exactly what it is you want to do via experimentation. None of that contradicts literate programming, or "thinking first": the prototypes, the messing around, that's part of the thinking (stage one really). Once you've gone through your iterations and want to finalise something... well at that point you do have some specs, you should know what you want to build; and at that point you can use literate programming, and you can do some design by contract, and make the finalised version robust, well documented, and easily maintainable and reuasable. Building prototypes is not failing to "think first"; not "thinking first" is shipping the nth iteration of the prototype as is and calling it done.
Excuse my ignorance, but please explain how this this different (or superior) to doxygen or any of the many systems that do just this. I'm not meaning to be rude, I'm just asking. I think the prime difference is that literate programming allows you to re-order the code; that is, you include snippet of code within the documentation, and attach tage to the snippets that allow them to be reassembled in a different order. That doesn't sound like much, but it means that you can just write the documentation have code appear as i is relevenat to the documentation rather than having the program structure dictate things. Take a look at someexamples (in various languages) to see what I mean. The key here is that documentation is (or should be) first and foremost in the writers mind, and it is the documentation that dictates presentation structure. This means that you are concentrating on writing the documentation, and will thus write it well, as opposed to concentrating on code, and adding documentation as an afterthought if you get around to it. Well, that's the principle at least.
Slashdot Mirror
* Note that "extra" is in scare quotes because ultimately most of the annotations are usually things you should be documenting anyway, so it's not so much "extra" work as documentation that gets done sooner rather than later.
In the meantime GNOME and KDE both have Human Interface Guideline documents that spell out how applications should work to be consistent, and, oddly enough, most applications for the respective desktops hew to them rather well. You can certainly expect a more consistent environment than Windows apparently is these days (even if you stick to MS software)!
But what about X11? Well, these days, if you're using GNOME, or KDE, or Xfce, and applications written for those environments (which is to say most modern applications for X11 desktops) then you only have two toolkits, which can be themed so they render using the theme of the other (using either GTK-Qt theme, or QtGTK Style), and has consistent cut and paste that works across (and between) them all. Yes, you can get some Xlib applications if you hunt around, but then you can get ugly Tk applications on Windows if you hunt around (or X11 applications on the Mac). The reality is that, these days, the Linux desktop really isn't that much more inconsistent that Apple or Microsoft. Actually, I would go so far as to say that it is actually more consistent than what MS is currently producing.
I know, choice is good. So is focusing your efforts on making one usable product that people can standardize on. People keep bringing this up, but it just isn't going to happen. FOSS developers will work on whatever they want to work on, and as long as there are different philosophies involved different projects will attract the interest of different developers. And there are very different philosophies driving the different desktop environments: GNOME is pitching for something simple and elegant above all else; KDE is far more interested in being configurable and cohesive; Xfce has efficiency as one of their primary goals; and the list goes on. With such divergent focus you are not going to get people (neither developers nor users) to all agree on one philosophy.
What you can do, however, is work on standards and interoperability of protocols that underly the environments. You know, like Freedesktop do. That means common standards for inter-application communication (from cut and paste to DBUS), standards for how applications expose themselves to menus, standards for syustem trays, and so on. This effort is still ongoing, but the end result is that GNOME, KDE and Xfce can share application menus, system trays, clipboards, icon themes, and more. With other things like the GTK-Qt theme and the QtGTK Style, we're steadily heading toward the point where applications will be able to slot in seamlessly competing desktops.
So in some sense what you want is being done, but it is not going to involve one desktop to rule them all. For that you need dictatorial control from on high to simply say what is "right". You won't get that in FOSS; it's just not how it works. If you want that you need something like Apple or Microsoft, and the consequences that come with such choices (although, to be honest, I'm not sure they offer models of perfect consistency either).
I really don't think you have a strong case for the former, and my only point is that the latter is just as plausible. I'm under the impression that Joseph Smith was illiterate; that means that, presuming he was faking, anything he "translated" would have to be a narrative he simply made up as he went. That means that faking it twice (producing identical text as "translations") is going to be very hard indeed, so yes, it seems very reasonable to expect that he was less capable of faking something twice than once -- making up a story is easy, but remembering the exact words you made up the first time is hard. That makes for a fairly strong case for option one, so I don't see how option two is "just as plausible" given, as the OP pointed out, there were other options available than simply refusing to ever translate that passage again.
Doom 2 was in no way shape or form the least bit revolutionary; it was Doom souped up a little. Doom 3 was, to my mind, very clearly going to be more of the same, albeit with better sgraphics and sound. Doom was revolutionary because it really opened up/created the FPS genre (other games, Wolfenstein for instance, existed, but Doom was the first to really mine that territory). How exactly were you expecting Doom 3 to be revolutionary? It was clear from the outset that it was going to be and FPS game, and in the spirit of Doom; that doesn't leave much, if any, room for a revolutionary new style of gameplay to fit in. It seems to me that anyone with expectations of something utterly revolutionary simply weren't thinking.
Wow, talk about bitter. I forked over the cash for the game, but didn't need to upgrade my PC. Doom3 didn't run at maximum quality, but it wasn't bottom end either. And I enjoyed the game; it was, to my mind, what the original Doom had aspired to be, but couldn't because of the relative lack in computing power at the time. It was tense, scary, and fun, and the quality of the graphics and sound were what made it the experience it was.
Having said all of that, I also understand some of the complaints. It was repetitive, and it certainly didn't bring anything new in the way of gameplay to the table (I didn't mind because I was looking for "Doom done right", but I can certainly understand that others would appreciate more creativity). I don't understand the bitterness though; it seemed pretty clear what Doom3 was going to offer in the way of experience (especially given that it was following after Doom and Doom2 which were repetitive, had fairly simple gameplay, and were pitch black at times). I don't really see that the game was ever misrepresented in what it was going to be, so I'm not sure where you got your expectations and feeling of entitlement from.
One of the nice things from this article was actually this nice screenshot of a selection of current versions of MS software running on Vista. The thing to notice is that not a single one of those applications has a GUI the same as any of the others. There are different toolkits, completely different look and feel, some have menus, some don't; it's a horrible, horrible mess. And yet despite that, we still get people complaining about GNOME vs. KDE and the clash of different toolkits and how that's what is holding Linux back. You can run GNOME and KDE apps side by side and, while they'll have differences, they'll sit together far more elegantly than the mishmash that is Windows. I think I'll have bookmark that screenshot so I can bring it up the next time a Windows fanboy starts decrying the excessive number of GUI toolkits on Linux.
No, the real long term answer is to not be like Windows; do things your own way with the aim of doign them better. I use Linux not because it is free, nor because it lacks viruses (though it's nice bonus) but because, for my needs, it is better than Windows. To be better you have to be prepared to b e different. The reason there isn't huge uptake of desktop Linux is because of that "for my needs" clause. For my needs it is better than Windows, but every user has slightly different needs. The number of users for whom Linux offers something better is expanding, but is still pretty small; since needs tend to include all sort of weird little niche requirements (which differ from person to person), the expansion is very slow (but reasonably steady). There is not going to be a "year of the Linux desktop"; rather there is simply going to be a slow but steady increase in the use of Linux on desktops (was there a "year of the Linux server"? No).
Trying to make something superficial that will get more switchers now is pointless; be patient and cosider the long term of goal of simply being as good a desktop as you can. Compare RedHat 5.2 and Windows 1998; then compare Ubuntu 7.04 and Windows Vista; the gap in quality and usability as a desktop has been closing steadily.
Only if you're doing it wrong...
No, it's quite clear, and I agree, everything has its costs and tradeoffs, and won't make sense for every project. You have to evaluate what's going to be most useful. I will maintain, however, that a mix of several is often going to be better than picking one as the silver bullet (which these days seems to be unit testing; who knows why -- it takes just as much time as the others as you point out).
Unless you are doing a rewrite at several iterations you are still ending up with "evolved" code, which is almost always a lot less pretty and a lot less maintainable than the same design written cleanly with the ultimnate final design decisions in mind right when you start.
Sure, if you like, just stick "document properly" in the "clean up and refactor" step and you can happily include literate programming. As much as you like to talk about being completely agile, a great many software projects do have distinct milestones and aren't simply in a constant state of flux. Not every software project is like the projects you work on.
Unfortunately there's not much you can do with a short term, next quarter, driven outlook that fails to do any accounting for maintenance and expansion. If your managers are that stupid then yes, you probably are screwed.
Well it's only incompatible if you just ship whatever the last iterating happened to be, rather than taking away all the lessons learned from those iterations (including, potentially, large chunks of the code) and writing a nice clean final version with good documentation (the documentation can, of course, include many of those "lessons learned", particularly why various design decisions wwere made etc.); that version can make good use of literate programming. In that sense literate programming is actually pefectly complementary to iterative/agile design. The other complementary technique that many agile/iterative/TDD fans seem to think is incompatible for some reason is lightweight formal methods -- it's actually very nicely complementary and goes espcially well alongside TDD. Google "lightweight formal methods" + "agile" sometime.
One would hope that you get to the final system design by iterative prototyping, which you then clean up, refactor, and rewrite into a nice codebase that doesn't have the evolved and iterative cruft, and is suitably documented (it's this last step where literate programming an come, though you can introduce some incrementally as modules and subsystems get frozen and rewritten). Who knows, maybe you do just ship the first thing you can get to work. What I do know is that in the business world where time is money, the clean well documented final version is going to involve a lot less time (and hence a lot less money) to maintain and debug and patch. And what if I want a new version next year? Well I would certainly prefer to have a clean readable well documented codebase to work from than "whatever worked" code. Maybe that's just me though. Different people work differently, and I'm sure you do what works best for you.
Well yes, and as someone else pointed out, the underlying idea of TDD bears some similarities in mentality with the ideas driving literate programming. It's a think first approach in many ways. I would add that they aren't really so much competing and complementary ideas. If you think TDD is good, then you might want to look at literate programming (or lightweight formal methods) and see if there aren't some ideas you can extract and make use of in conjunction with your TDD.
I've seen RSpec. Personally if I'm going that route I would prefer stepping up to proper specifications like JML. It's definitely better for providing documentation, at least in the form of API documentation. Then again, Eiffel or Spec# wold also fit the bill. I'm not really knocking RSpec: it's really very nice -- I'm more trying to point out that there are a few more strings you can add to your bow if you like that sort of approah (ad that literate programming is still one of them).
Now, that's not to say that TDD and literate programming don't have some similarities -- they both have a mentality of putting your intentions down in some clear fashion before providing the code, Of course there are similarities between TDD and lightweight formal methods (in the form of specification driven design) and design by contract. In general I think all of these ideas are good, and given that they are either orthogonal (as TDD and literate programming are) or compatible (as TDD and SDD and DbC are) it makes sense to use all of them in as much as they make sense for the project at hand.
I think, perhaps, you're missing the point. Go ahead, build a prototype and try out ideas. Do the Brooks thing, and build one to throw away. Work out exactly what it is you want to do via experimentation. None of that contradicts literate programming, or "thinking first": the prototypes, the messing around, that's part of the thinking (stage one really). Once you've gone through your iterations and want to finalise something... well at that point you do have some specs, you should know what you want to build; and at that point you can use literate programming, and you can do some design by contract, and make the finalised version robust, well documented, and easily maintainable and reuasable. Building prototypes is not failing to "think first"; not "thinking first" is shipping the nth iteration of the prototype as is and calling it done.