On Tue, 2012-03-20 at 12:27 -0700, Tim Dysinger wrote: > I'm using org-mode, org-babel & swank for a "living" document I'm > writing. I'm generating a PDF which includes documentation, working > clojure code that generates incanter graphs. Also the generated > incanter graphs are included in the generated (latex) PDF. > > On Monday, January 23, 2012 3:14:09 AM UTC-10, Colin Yates wrote: > Hi all, > > > There are some excellent resources on this mailing list > regarding literate resources, but they are more based around > the theory rather than actual use. You might find this of interest:
Literate Programming example with Clojure http://youtu.be/mDlzE9yy1mk It is a quick video of my normal literate programming workflow (ignoring the usual git commits) It shows 3 things: 1) Extracting Clojure from the book and rebuilding the book PDF 2) adding code chunks and rebuilding clojure and the book 3) making text-only modifications and rebuilding only the PDF > > > Has anybody got any "real world usage reports" regarding using > literate programming in emacs? In particular, does paredit > and slime work inside the clojure "fragments" when using > org.babel for example? > > > Finally - how are people finding practising TDD with literate > programming? I imagine that Clojure's excellent REPL (+ > evaluating clojure forms from within a buffer) mean there are > far less "type, extract tangled code, run tests" needed. > Hmmm, not sure that is clear. What I mean is, do people find > that the ability to evaluate a clojure form from within > org.babel (assuming that is possible!) is sufficient for TDD > or do you find you need to type, extract the tangled code and > then run lein (for example) to run the tests? When you run 'make', as shown in the video, it rebuilds the program and runs all the tests. > > > Basically - how do y'all get on with TDDing in emacs following > the approach of literate programming - any advice welcome! Here is an interesting quote from Greg Wilson (http://vimeo.com/9270320) >From a IBM 1970s study: "Hour for hour - the most effective way to get bugs out of code is to sit and read the code, not to run it and not to write unit tests. Code review is the best technique known for fixing bugs. Get somebody else to read your code. Sixty to Ninety percent of errors can be removed before the very first run of the program. And hour for hour, if you have a choice of writing unit tests and reading code, read the code." Thus, literate programming, which explains the reasoning behind the code and the issues involved, would seem to make code reviews be much more effective. I would love to do a study about this but so far I have not found any professors interested. Tim Daly d...@axiom-developer.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
