literate programming and the rational unified process

The wikipedia article on literate programming is very well laid out and was a good read. There are a lot of literate programming "languages" out there! I wonder if there is any style that generates test cases as well as code. It may be good and all to interweave thoughts and comments with the code in a natural-language type flow, but I think it would be hard to debug this, given the amount of text you have to search through, and all of the chunks of the same piece of code being scattered about. Maybe you compile it into source code, and then debug it, and then figure out the pieces you debugged and inject them into the original? Sounds a little too hard...

I would like literate programming if we designed a language that could take natural language and produce code, resolving ambiguities in the natural language by waiting until the last moment to evaluate and dynamically type any portion of the program, interpreting the language by the surrounding state at the time of execution. If it still can't be resolved, throw an error and let the user revise their language, or be more specific, or whatever.

Of what is out there right now, I think noweb would be good to learn.

On to RUP:

Developed by IBM, this process is very detailed, and seems interesting to learn. A summary of it is very interesting (about 20 pages). It turns out that it is all about using UML as a way to communicate design, requirements and architectures across teams. A bunch of tools are employed to keep the models up to date and to support bookkeeping.

I definitely see how important an easy tool for bookkeeping would be!

And the IBM 6 best practices for a software development team are:

1) Develop software iteratively -- agile methods I think work just as well here
2) Manage requirements -- they emphasize use cases and scenarios, as in agile!
3) Use component-based architectures -- I think Python is a great example of this in practice; developers of Python have made dozens upon dozens of robust and useful components for the language
4) Visually model software -- this is where UML comes into play. I think we need to use this more.
5) Verify software quality -- Here I think agile is better - test first!
6) Control changes to software -- this is what good version control software is all about, right?

Here's a visual of how they envision the "process":




















I think our team could do better with a vision document and a bigger overall picture of what we want to create.

The rest of the doc goes into details about this process.