On Tue, 2012-01-10 at 10:24 -0800, Kai wrote: > Hi Tim, > > > I found your post very compelling in the questions, analogies, and > possibilities raised - something like a "Clojure Etudes" is really > needed to move beyond learning just the syntax and general concepts, > and into the next level of skill with Clojure - or any other language. > Perhaps that level is akin to "idioms and basic design patterns," but > whatever it is, it can be very valuable when learning/studying alone.
One thing I've identified, as mentioned in my post, is the ability to change the style of a solution without changing the basic character of the solution. So I've been looking at Knuth's Sorting and Searching book and thinking about trying each algorithm in different styles. That is, write bubble sort in a functional style, a procedural style, an Object oriented style, a rule based style, a table driven style, a spreadsheet style, a call/CC (scheme continuation) style, in a threaded, concurrent style, in a parallel style, as a DSL style, as a Hadoop/MapReduce style, etc. Clearly some of these are going to be rather artificial for any given problem but the same is true of trying to write a romantic love song in heavy metal. The point is the style, not the solution. The next Etude does the same thing with a merge sort. Eventually it should become clear what the "style idioms" are, independent of the task. In my opinion, someone "skilled in the art" and trying to master it would be able to move between styles fluidly without changing the problem. If these Etudes are done as literate programs then someone can pick up the bubble sort booklet and get each style explained in the context of the problem and understand how the solution was constructed. > > > How many people are interested in this idea? If there's interest, how > could we start and collaborate? I noticed there's a "Clojure in Small > Pieces" book by you; is that the current go-to for this level of > study? Thanks, Clojure is Small Pieces is intended to bridge the gap between the ideas in Clojure (e.g. immutable data structures) and their implementation. It has been my observation over the years that many projects die (Sourceforge has about 100k dead projects) once the original authors move on. It has also been my observation that literate software is a potential way to make programs that can be maintained and modified, that is, programs that "live". I want Clojure to live. I have also personally observed that literate software is of much higher quality. Of course, these are only conjectures that need to be tested. I have been trying to find places that are willing to create real human factors experiments to test these conjectures. This is one example letter: ================================================================ It is clear that Literate Programming can improve code quality in three ways. First, the programmer finds mistakes in reasoning while explaining the code. Second, the code review team can question the reasoning as well as the implementation. Third, code can "live" beyond the lifetime of the original authors because the information necessary to modify and maintain the program has been communicated as part of the development. Since there are no studies to confirm or deny these statements they are just opinions. However, the second claim can be tested in a well designed study. The basic idea would be to take an existing program, telnet for example, and create a literate version. The extracted output of the literate form (the "tangled form" ala Knuth) would be byte-for-byte equal to the non-literate form. A proper study would evaluate the comprehension of programmers when given equivalent blocks of code, some literate and some not. For instance, there could be questions about telnet's buffer management scheme to try to highlight security flaws such as DOS attacks that use up the buffer pool. Would the literate group have a better understanding of the ideas and be better prepared to answer detailed questions about behavior? Such a study would underpin the improvement in quality of the source code and raise the quality and professionalism of programmers. Would you be interested in participating in such a study? =================================================================== Such a study could be done with Clojure. For instance, take the implementation immutability using a Red-Black Trie structure. Make a literate form. Now create 2 groups, one reading the usual code containing only comments and one reading the literate form. Ask questions like, why are the 5 bit masking sequences used? When should they be 6 bit? What effect would this have on the O(x) complexity? Imagine if every Clojure programmer could answer those questions simply because they "read the book". I believe it would set a standard for code excellence that would outshine every other project. Tim Daly -- 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
