On Fri, 10 Sep 2010 17:29:24 -0400 Stuart Halloway <stuart.hallo...@gmail.com> wrote:
> Hi Mike, > > I think this is more about convenience than simplicity. In both Unix and Java > deployment is complex, and often complicated as well. In spite of this, > small, one-off things should be convenient to deploy, and Unix does this > better in some contexts. > > There is no reason we can't make one-off scripting convenient in Clojure. The > specific example you raised (deploying one-off scripts) could be addressed by > a standard launcher. Several have been written, and we need to take the > simplest design and include it in Clojure. There is already a ticket for > this: > https://www.assembla.com/spaces/clojure/tickets/366-multiplatform-command-line-clojure-launcher, > and I would love to see it in the next release. > > That said, your example was one representative example of a general problem. > Inconvenience bubbles up from the Java ecosystem in many places. Fortunately, > these inconveniences are easier to fix in Clojure that elsewhere, since > Clojure is such a simple language. :-) Bingo. I think it's deeper than that. The reason that the Unix version is so simple isn't just a simple launcher script, or the #! hack, or any one things. It's that "simple things should be simple" is axiomatic for those tools (I'm not sure which came first - the software tools project or unix, but they both share this philosophy, and software tools project ran on damn near everything when they were still supported). All those things derive from that philosophy, and combine to make simple things simple. I.e. - someone claimed that this boils down to not being able to tweak CLASSPATH in the program. Well, that would help, but it's not quite enough. Most simple/simple programs don't have to tweak their search path for loadable modules, because - no matter where they are running - the default path to look for loadable modules includes the current directory, possibly the directory the application was launched from, and the appropriate library directory for that installation of the system. Which means that 95% of the time, you don't have to worry about the path at all. Simple things - loading standard modules (even if they're optional), loading application-specific modules, or even invocation-specific modules - are simple, because the appropriate elements are *already* in the search path. Ditto for compiled binaries: if they're built properly, they know where to find all their shard libraries, and you don't have to muck about with LD_LIBRARY_PATH. The default CLASSPATH is ".", so to do anything more complicated than running a .class file from the current directory (and really - how often do you do that?) you have to do something complicated. Ok, fixing this in clojure would require the ability to change the class path - or a smarter classloader - that looked in the right places to start with. So that ability is a first step in this direction. <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.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
