How weird, the dupe detection must have some sort of time sensitivity built in... this was posted a couple of weeks ago with the same URL:

http://news.ycombinator.com/item?id=441485

Funny, though I didn't read it then. Still, it's more to my interests than the rest of the front page...

Yeah, it's totally not a big deal, I just thought it was weird because the URLs matched up completely. It is a good read - I only remembered it because I saw it here a couple of weeks ago.

I've become enamored with PLT Scheme. Clojure main appeal appears to be that it is on the JVM (with all those darn libraries), not that it is a new/beautiful and novel language. I am a proponent of porting Clojure to run without the JVM - has anyone heard of such a project?

Being on the JVM is a very big deal. I have associates who wouldn't think of using a "fancy" language for anything, who are now looking closely at Clojure, and its chief attraction to them is evidently the JVM.

On the other hand, I like it because it is a "new/beautiful and novel language."

What possible benefit would there be to a project like that?

I wouldn't mind a .net version, but other than that I agree that clojure loses a lot of its benefit over other lisps if it isn't tied to an existing runtime and library set.

Back before it was a public project, there apparently was a Clojure on .net. It appears, however, that it is now pretty firmly matched to the JVM.

Given its present state, it would be about as hard to separate Clojure from the JVM as Java.

Perhaps someone will rip off its ideas and create L#.

I heard a rumor a few weeks ago that someone had Clojure running on IKVM. I'm sure it would be slow as hell right now; but it'd probably be OK for toying around with.

Given that clojure "embraces the platform", it'd probably be pretty hard to have clojure.net _without_ ikvm in there somewhere. Performance could be increased by porting the code generator and core classes to .net, but users expect to use arbitrary java libraries, so that capability has to be there.

(Seems like that strategy could also be applicable to a native port, using an embedded jvm to handle whatever has not been ported from java land)

and FWIW (i have little .net knowledge)

    ubuntu:~% ikvm -jar clojure.jar
    Clojure
    user=> (. cli.System.IO.File OpenText "/dev/null")
    #<StreamReader System.IO.StreamReader>

(startup takes about 6x times as long with ikvm than java -client. compiling with ikvmc creates a clojure.exe which instead takes 9x to start. clojure-1240 non-slim, java 1.6.0_07, ikvm 0.34.0.4, mono 1.9.1)

That's pretty interesting... Does mono have a native image generator like ngen? You might be able to get some performance improvements if it does.

It does, but given how quickly it runs, I can't think it's doing that much? I remember playing with it a while ago and not seeing any performance worth remembering.

Apparently the latest version of mono has much better AOT support, and performance improvements as well.

Here are some other ports:

JavaScript: http://code.google.com/p/clojure-contrib/source/browse/#svn/...

Flash: http://wiki.github.com/aemoncannon/las3r

.NET: http://bitbucket.org/stefanrusek/xronos/wiki/Home

Its STM support, persistant types and syntax sugar for vectors and maps seem pretty novel.

I'm coming to agree with him about Clojure being the best language out currently. I've used both it and SBCL and I prefer the former, because SBCL's lack of up-to-date libraries (compared to the JVM) can be frustrating.

I wouldn't call macros a hard necessity, however. You can accomplish quite a lot, quickly, in Ocaml or Haskell, even though they're statically typed languages with no macros. Functors, type classes, and various cool design patterns (e.g. monads) provide a lot of the abstraction and code reuse that macros provide. Also, I'd rather use a statically-typed language for a project with 4+ developers.

I think that 90% of Lisp's headway over a language like Java comes from the functional paradigm, and 10% from macros.

> SBCL's lack of up-to-date libraries can be frustrating.

But on the flip-side, Clojure's lack of a real object system can be frustrating. It is also annoying that you have to actively work around the JVM (for example, when making tail calls). Generally it is a beta-quality languages with some issues that need to be worked out. (I stick with Haskell for now when I want to write in a functional style, and CL for everything else.)

Also, while having Java libraries is better than having no libraries at all, the code that uses Java libraries becomes very un-lispy. It is a reasonable compromise, but certainly not ideal.

Clojure has all the components necessary for an object system: multimethods, hierarchies and structs. It's not quite an object system, but it's not hard to roll your own from these pieces. Someone on the group has made a CLOS-inspired library called Spinoza (formally CLJOS) using these components, which you might want to look into if you're fussed about having proper objects.

The lack of tail call optimization sucks-- I agree. Any language that wants to be thriving in 2015 is going to have to facilitate the full spectrum of functional programming, much of which requires TCO.

Regarding Clojure's object system, people tend to build their own. The tools are there. Within 12-24 months, there'll probably be a "default" object system. Right now, there isn't one because the language is still molten hot right now.

Most Clojure code I've written hasn't been that un-Lispy. Usually the first thing I do is build helper functions to abstract away all the Java classes.