> My extremely biased opinion: Clojure is not a scripting language. One can spent a lot of time debating the definition of 'scripting language', but sure. The bigger issue though:
> The "binary" is java. System-wide classpaths are a bad idea. In theory I agree with you. The concept of site-local (system wide) python paths, ruby library paths, and linker paths for C, are horribly and completely broken. (It is somewhat acceptable in the case of native libraries since they map to the underlying platform and performance optimizations such as read-only mmap:ing apply, and there is a system in place for versioning.) Unfortunately, because of the practical reality that the vast majority of the software that needs packaging for a platform are written in languages and using tools that make prohibitively problematic to try to coerce this set of arbitrary software into a world view where the system-wide stuff does not exist, all major packaging systems (debian packages, rpms AFAIK, freebsd ports, pkgsrc, etc) operate under the assumption that this is how you package software. What this means is that there tends to be a pre-existing infrastructure to handle packages that install files in some particular system-global location. Coercing a packaging system to handle a situation where the same software can be installed in multiple versions and appropriately selected by some particular version of some software that depends on other software, is problematic. I suspect that a key feature of clojure that has contributed to it's very promising level of popularity and use, is that it is comparatively easy to get going writing real software with it, and the fact that things that "should" be available, *are* available (in the form of Java libraries to some extent, but also largely due to being based on the JVM). I submit that adopting something similar to python's/ruby's system of loading code may be conducive to lowering the barrier of entry and increasing acceptance of Clojure as a platform to build on. As a developer, I have no problem with using leinigen for example (it's great!). But while an executable uberjar is extremely convenient, it does not tie into the packaging system of a platform (and there may be licensing issues with e.g. GPL libraries and re-distribution of uberjars). As a system administrator, you want to maintain some number of systems in some consistent fashion. This includes having a set of software that is supported, upgraded and maintained using a consistent tool set. Python and Ruby applications are well-behaved from this perspective. Clojure is not. This is why, even though Ruby has gems for example, there are still ports of specific ruby gems at specific versions in the FreeBSD ports tree - because that means they are suddenly integrated into the platform's packaging system. The fact that a random user can "gem install XXX" does not obviate the need for such integration. All forms of change management tend to be difficult, and software installation is a form of (particularly complicated) change management, assuming you need to keep stuff up-to-date. As a user, you want to use some piece of software without spending time figuring details out that should be left the programmer and the packagers for your platform. A project I started a few months ago, I wanted to write in Clojure. There were two major reasons why I ended up going with Python, and this is one of them (the other was POSIX Integration issues). I knew that I wanted something which the user could easily install and use using the tools that are integrated with his or her platform, without knowing anything about Java or Clojure or mucking about with things manually. Something which could just *be there* by default, as part of the regular experience of the operating system. In summary, I think one should not underestimate the importance of making sure users can just "aptitude install your-application" (substitute for whatever with freebsd//redhat/etc). Making it as easy as possible for applications writers to in turn make it as easy as possible for packagers to make that happen, is, I think, important. Having said that, this does not necessarily mean that one has to adopt the the Python/Ruby style of system-wide library paths. But I think it does mean that there needs to be some sensible way for an operating system's native packaging infrastructure to interface with the infrastructure of the language. And any random blackbox doesn't cut it; certain demands are imposed on the blackbox in order for it to play nice with the packaging infrastructure. At this time I haven't thought this through enough in the case of Clojure to offer a practical suggestion that does not involve system-wide library paths. -- / Peter Schuller -- 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
