On 18/04/2009, at 11:51 AM, mikel wrote:
>> It's not clear how to use the stuff in clojure-contrib, which >> certainly seems like the 'standard library' of useful tools that >> makes >> clojure into something other than a lispy language using Java >> libraries. > > > This is a good point. Using clojure.contrib is in fact extremely easy, > but it's hard to tell that from the point of view of a new user. I was > a new user recently enough to remember my initial confusion about how > to set up my development environment and how to arrange it so that > clojure.contrib was as readily accessible as it should be. I wasn't talking about how to get it on the classpath so much as documentation for the individual components in clojure-contrib. IMO those components should be broken out, and documented. I have commercial experience developing Smalltalk applications which has shown me that you *can* survive without extensive documentation iff you have fantastic code navigation and exploration. I'm not talking about find-doc et al, but some way of navigating live code. So when I say that documentation is necessary, I admit that one alternative would be a code navigation tool as part of the core. One way to do this would be an ultra-lightweight server as part of core that serves up a hyperlinked cross-ref view of the source, ala the Smalltalk Browser. I don't think this should be relegated to the individual IDEs. The weakness of the Smalltalk approach as compared to javadoc (say) is that it's easy to cop out and regard functional-level documentation is being sufficient, whereas you also require architectural/expository documentation, and that really needs to be rich e.g. package level javadoc as opposed to class/method level documentation. I think some mechanism to do that is required. My overall point being that there is a conflict in knowing that documentation is absolutely required for mass-acceptance and arms- length use and yet knowing that documentation generally won't be written and even when it is, it needs to be integrated. IMO javadoc is a significant reason for the success of java, and something at least as good, and preferably live and reflective, is required for Clojure. I get the feeling that for the purposes of a book about the language, 1.0 is pretty much ready now, although wasn't there something about method dispatch / hierarchies that Rich was looking at? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it very easily and for a very reasonable price, but I don't want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and hours of my precious time. -- Slashdot response to an enquiry --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
