On Jul 5, 11:07 pm, faenvie <fanny.aen...@gmx.de> wrote: > note on the original posting: > > > First, he shouldn't be porting Java code to clojure, Second, Clojure IS > > fundamentally different from Java, and third, such said users who > > don't want to touch Java should not touch Clojure. > > to port java-code to clojure-code is certainly not the > right thing to do in most cases ... but > > the fact that clojure is not determined to use the jvm as its > hosting-language could certainly be a driver for the reimplementation > of popular components. > > even memory-management (gc), io-functions and process-management > may be candidates for a (re)implementation in clojure some day.
I recently read this and I think it's a very sensible position: Fogus: Different target hosts would naturally support different subsets of Clojure’s functionality. How do you plan to unify the ports? Hickey: I don’t. It has not been, and will not be, the objective of Clojure to allow porting of large programs from one host to another. That is simply a waste of time, and needed by almost no one. Currently, you often have to change languages when you change hosts— from Java to C# or Javascript. This is better than that, while short of some full portability layer. The idea is to be able to take one’s knowledge of Clojure and its core libraries, and of the host du jour, and get something done. Certainly, non-IO libraries, like Clojure’s core, can move between hosts. The JVM and CLR have rough capability parity. We’ll have to see how restrictive a Javascript host might be. -- 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
