Clojure reactions?

Has anybody yet done any serious programming in Clojure? I have read the docs and there are a lot of interesting ideas there. I'm excited that somebody had the stones to actually create another Lisp-based language and put it forth for general usage. I haven't tried to actually use it for anything interesting, though.

Also, how do people feel about it being hosted in the JVM? This was cited in some of the descriptions of Clojure as an advantage. Personally, I'm not sure that's the case, but I can see that the ability to snarf a bunch of Java libraries instantly would greatly help productivity when using a new language. I'm not against VMs in general, just that the JVM was written to specifically run Java and I have heard a lot of stories of people trying to port Lisp/Scheme to it and being frustrated because it wasn't very suited to doing anything but run Java.

Anyway, it would be interesting to hear people's experiences with really using it.

I haven't used Clojure for anything, but thought I would mention that Sun is interested in getting other languages to work well on the JVM. e.g. they have hired JRuby and Jython developers.

See also the da Vinci Machine project:

We are extending the JVM with first-class architectural support for languages other than Java, especially dynamic languages.

I can't decide between Clojure and Scala.

I've played with Clojure a bit. It's very nice. I love how lists and vectors etc. all have a common "sequence" abstraction. I have vague plans to use Clojure to write a multi-threaded GUI/networking app. I'll have to see how that works out.

I think (and hope) Clojure has a bright future. A cross-platform Lisp with tons of libraries, and a potentially huge user base of Java developers... seems like there's a lot of potential there. I can't stand writing Java but I don't have any problems with the JVM per se. It might be hard to get something other than Java running on the JVM, but Clojure already exists and appears to work well, so perhaps it's a moot point.

I've was playing with Clojure a while back for fun. I mean to get back into it so I can help benchmark Rich's parallel operators.

For me, the main reason for using an existing runtime (e.g., the JVM or .NET) is to avoid reimplementing a runtime It's nice to know that your garbage collector is tuned and well-tested, for example.

hilbertastronaut wrote: For me, the main reason for using an existing runtime (e.g., the JVM or .NET) is to avoid reimplementing a runtime It's nice to know that your garbage collector is tuned and well-tested, for example.

I agree with that as long as the rest of the system isn't dog-slow because you're having to box all your integers with a crazy number of indirections and such. As you say, the biggest reason to reuse it is because it's done, it works, and somebody else built it and will maintain it.

hilbertastronaut wrote:For me, the main reason for using an existing runtime (e.g., the JVM or .NET) is to avoid reimplementing a runtime It's nice to know that your garbage collector is tuned and well-tested, for example.

Steve Yegge gave an interesting talk about Rhino, Javascript and the JVM - apart from the efficient garbage collector, there's also native, fast threads and more importantly, the fact that every language implemented on the JVM can talk easily with any other JVM language. It's a common ground, a documented and powerful machine above (most of?) the hardware/OS-level idiosyncrasies and differences.

I've been using Clojure in my spare time and I love it. I think being in the JVM is great for a number of reasons, and while I'm not a fan of the Java standard library at all (implementation-wise) it is very robust. It's a great language for functional programming and has really awesome support for parallel programming.

I have been mostly playing with it in my spare time, but recently I have folded its use into my job as a nice way to perform unit testing as well as providing a more intuitive build system.
-m

fogus wrote:I have been mostly playing with it in my spare time, but recently I have folded its use into my job as a nice way to perform unit testing as well as providing a more intuitive build system.
-m

So, what's your reaction, fogus? What do you like most about Clojure, and what do you think still needs improvement?

Catching up on the Clojure group, I saw this message:

http://groups.google.com/group/clojure/ ... b58782ca0b

I found this part interesting:

Proxy generation was the last runtime code-gen/classloader
requirement. So the path is clear for building Clojure apps without
runtime codegen, for delivery in those environments that preclude it
(e.g. Android, unsigned applets). Looking forward to feedback from
people trying to reach those targets.

findinglisp wrote:So, what's your reaction, fogus? What do you like most about Clojure, and what do you think still needs improvement?

I am loving it so far, although there are a few minor points that annoy me from time to time. Probably the most annoying (although it's probably my own psychosis) is that it does not seem that Clojure quite knows how it wants to treat Java. Surely, it puts Java at the forefront of it's thoughts with its strong support for using and extending Java libraries and even extending them -- that's not my issue (instead, I see it as a great strength). Rather, I dislike that there is a blurring between understanding Clojure and Clojure's Java implementation. That is, in order to really (IMO) get to the heart of Clojure you literally have to know many of its implementation details. For example, Clojure uses the sequence abstraction instead of the cons cell which proves to be extremely powerful. However, there is a hard difference between things that are sequences and sequence-able and the only ways to know which is which is by hacking around with them and/or reading the Java source. It's a minor thing most likely, but it puts an unnecessary conceptual burden on someone trying to learn Clojure.
-m

fogus wrote:

findinglisp wrote:So, what's your reaction, fogus? What do you like most about Clojure, and what do you think still needs improvement?

I am loving it so far, although there are a few minor points that annoy me from time to time. Probably the most annoying (although it's probably my own psychosis) is that it does not seem that Clojure quite knows how it wants to treat Java. Surely, it puts Java at the forefront of it's thoughts with its strong support for using and extending Java libraries and even extending them -- that's not my issue (instead, I see it as a great strength). Rather, I dislike that there is a blurring between understanding Clojure and Clojure's Java implementation. That is, in order to really (IMO) get to the heart of Clojure you literally have to know many of its implementation details. For example, Clojure uses the sequence abstraction instead of the cons cell which proves to be extremely powerful. However, there is a hard difference between things that are sequences and sequence-able and the only ways to know which is which is by hacking around with them and/or reading the Java source. It's a minor thing most likely, but it puts an unnecessary conceptual burden on someone trying to learn Clojure.
-m

This issue has more to do with the fact that the Clojure implementation is very young rather than with the language itself. As the implementation matures and more documentation becomes available, I think those problems will disappear.

By the way, the following was just posted to the Clojure mailing list by Baishampayan Ghose:
http://java.sun.com/developer/technical ... index.html

It's an article about features of JDK7 that are designed for dynamically typed languages. The article doesn't mention Clojure, but it does mention Armed Bear Common Lisp, Groovy, Jython, JRuby and something called Yoix that I've never heard of.

The Summary says:
Over the years, the JVM has been host to a growing number of languages, including implementations of dynamically typed languages such as Ruby and Python. Support for dynamically typed languages in the JVM is very attractive to application developers who build applications in these languages. That's because dynamic typing gives developers a lot of flexibility and the JVM delivers a lot of execution efficiency.

However, implementers of compilers for dynamically typed languages have found it difficult to meet the JVM bytecode requirements for method invocation. JSR 292 addresses that problem by providing a new bytecode, invokedynamic, and a new linkage mechanism based on method handles. Also being investigated for inclusion in JSR 292 is interface injection, the ability to modify classes at runtime so that they can implement new interfaces.

It seems Rich doesn't think the above will have much impact on Clojure:

* rhickey would much rather have TCO and tagged numbers than invokedynamic

Bummer. It would be nice if the JVM was a bit more open to other languages. The JVM itself just has so many Java-specific assumptions embedded into it. That's understandable given its history, particularly early-on when JVM performance was so bad, but it really hurts when you're trying to implement a non-Java language on top.

findinglisp wrote:Bummer. It would be nice if the JVM was a bit more open to other languages. The JVM itself just has so many Java-specific assumptions embedded into it. That's understandable given its history, particularly early-on when JVM performance was so bad, but it really hurts when you're trying to implement a non-Java language on top.

Well, I think the point of the article is that they are working on it. More slowly than would be nice, but they are working on it :)