I think this discussion would greatly benefit from some hammock development time ;) The original post was quite precise in its scope, but we quickly side-stepped into related issues, so it feels like we have lost some focus. On the other hand I think many of us get the feeling we can't provide some satisfactory answer by just narrowing our discussion to the original proposed scope. We sense there's a bigger picture here and that's why we easily get carried away. So since the first step in hammock development is to state the problem, understand it, provide facts, context, constraints, trade-offs, etc. I propose we just do that.
Let's start by naming the related areas that are at play here: 1. The design paradigm: How to design libraries with the right level of granularity and dependencies. How to make dependency layers (e.g. core libraries, then common utility libraries, etc.). This is the level where this discussion started, but it quickly went into the other complementary aspects below. 2. The programming model: How we logically organize the code into elements such as packages and namespaces. How we physically bundle the code into deployable units such as jars, wars, bundles, etc. The tools and api for defining and composing units, defining and resolving dependencies, such as leiningen, maven, ejb, spring, etc. 3. The runtime model: How the deployable units are discovered and loaded. Whether they can be loaded at boot time or dynamically at runtime (e.g. hot-deploy). Whether dependencies can also be resolved at runtime. Whether separate versions can coexists at runtime. That's just one way to decompose the problem into related areas, inspired by [1], and there are certainly other ways to decompose the problem. So the above is just a start that may provide more context to this discussion. Of particular interest is that fact that since Clojure is a hosted language, each host language has its own story to tell about 1,2, and 3. In the case of Java we're talking jars, classloaders, osgi, jigsaw in jdk9, etc. In JavaScript we're talking about namespaces, script loading, google closure dependency management, etc. I don't know about CLR but they certainly have their own story. So the key point here is that, while building the Clojure story on modularity, we need to be aware of how it maps to each host language. And if we were to better see the trade-offs we make, it could be a good exercise to come up with the ideal story for Clojure regardless of host languages, and then compare. My guess is that we'll discover we don't need much on the Clojure side of things, but that the real challenge is in how to integrate with the OO-twisted way of doing things in each host language. Which brings me to this: I think there's a window of opportunity between now and jigsaw in jdk9, because we won't be able to ignore their story. Rather than wait for it to be complete, it may be wise to be proactive and see what they're up to. I say this because by providing some input into the relevant JSRs we could avoid a stronger impedance mismatch between the Java/OO way of doing things, and the FP/Clojure way. For example: will the way of generating/loading classes at runtime be made easier? Will jigsaw make it easier to load separate versions of Clojure? At boot time or at runtime? Are interfaces the best and only way to define services, or would some form of duck typing be supported? Out of all the JVM languages Clojure is probably the one that has the most interesting things to say on FP best practices. Other languages are either hybrids, and therefore lack motivation for purity, or don't have the weight of the Clojure community. Finally, I can't help but think about Rich's presentation on the Language of Systems [2] and how this discussion fits into it. It seems to me there's some overlapping somewhere... Anyway, how about a wiki page we could use to keep some sort of blackboard on how to better state the problem, provide facts, context, constraints, trade-offs, etc.? Then we can each have our own separate and private hammock time to hammer this down. [1] http://www.kirkk.com/modularity/ [2] http://www.youtube.com/watch?v=ROor6_NGIWU -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
