On 12/26/2010 8:33 PM, Robert McIntyre wrote:
That's really cool. I was _just reading_ your comments from 2006 at http://www.mail-archive.com/gardeners@lispniks.com/msg01006.html and wondering about how hard something like this would be to write. If possible, could you expand on how one might use this in a development work-flow with emacs or texmacs? Is there some sort of lisp-pamphlet mode that could be extended to clojure? I'm assuming you've already solved all these problems and more while working with Axiom. I'd appreciate any pointers or best practices you might have found.
Wow. That's an old reference. Most of those links are dead. Try http://en.wikipedia.org/wiki/Axiom_computer_algebra_system or http://axiom-developer.org As I mentioned in my other email on this subject I don't use Emacs modes. I don't want the computer editing my text. I just want it to do exactly what I told it to do. But I'm a curmudgeon :-) My style of programming is to change one thing and then do a complete system rebuild and test, which takes about 1 hour on my fastest machine, 5 on my slowest. I "work a pipeline" of changes so the build/test time is overlapped with changes. I can have up to 5 machines doing build/test while I'm working on the 6th change. (Git helps a LOT here. I strongly recommend git also.) I usually use a split screen with the literate latex document (I call it a "pamphlet") in one buffer (not a slime setup) and the REPL in the other buffer. I use the REPL to hand-check the code before modifying the pamphlet. Thus, if (when :-)) it fails I know what I broke and where I broke it. When it works, the code is already documented in latex and pdf. The build/test automatically regenerates the pdf. The goal is to make the smallest change possible and concentrate on getting it right. It might require writing or updating test cases which are also in the same literate document under a "test" chunk name. The automated build extracts and runs all "test" chunks. So the essential loop is: edit the pamphlet in a split buffer define the functions in the REPL buffer change the function hand-test the change in the REPL update the pamphlet with the changed function write/update the test code save the pamphlet do a full system build and test check that the test pass check the pdf documentation The second step would be a lot easier if Clojure knew how to load a latex file. I'm thinking of writing a load-pamphlet function to do this. It could specify a chunk name to extract as in: (defn (load-pamphlet [file] (load-pamphlet file "*")) (load-pamphlet [file chunk] (tangle file chunk))) Thus, to do step 2 above I just need to (load-pamphlet...) the file. I could run the tests with (load-pamphlet file "test") \begin{rant}{ \tl;dr{Let's move programming out of the dark ages.} We of the Clojure community are trying hard to move Lisp out of the 60s programming model. We can also move programming out of the 60s code-then-maybe-document model. The Knuth technology is 30+ years old. When I started 40 years ago (http://www.dilbert.com/fast/2010-12-23/) we had limits like 8k of memory so no file was bigger than 4k. Thus, C programs were "tiny piles of sand" with include/overlay linkers/etc. Few of you have ever worked on a fully loaded PDP 11/40. Why do you program like you only have 4k? Now we can have a machine with 128Gig of memory. Its about time for programmers to lose the "one function-one file" idea based on keeping the machine happy. We need to think about one-program-one-document to keep the humans happy. For a perfect example, see the book: "Lisp In Small Pieces by Christian Queinnec" [1] Queinnec's book is my ultimate example. He MOTIVATES every piece of code that gets introduced and he talks about everything. The code contains a complete lisp system including the interpreter, compiler, and garbage collector. If you want to know lisp, read this book. If you want to learn literate programming, study this book. I want "Clojure In Small Pieces", a literate form of Clojure that I can execute from the book. Then I can open to the chapter on PersistentHashMap and read all about log32 tries, why they matter, and how Clojure implements them, with literature references and a good index. Oh, yeah, and the ACTUAL code that gets executed. Forget the jar file. Send me the pamphlet containing Clojure. Programming will come out of the dark ages when we employ English majors as project leads with the title "Editor in Chief". If you can explain it to an English major in text, you probably understand the problem :-) Let's move programming out of the dark ages. \end{rant} Tim Daly [1] http://www.amazon.com/Lisp-Small-Pieces-Christian-Queinnec/dp/0521545668 -- 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
