Very interesting response, Rich... Thank you. Comments below. Rich Hickey wrote: > Java has greater platform reach.
Undoubtedly, and I think the work we're all doing will help keep it strong and extend it further. > Java is more dynamic. Java's dynamic loading heritage pervades the > platform in many subtle ways. Interesting...would you care to elaborate? I agree, but for mostly intangible reasons. I have not worked in an environment that did not support dynamic loading of code (or not as dynamic as Java) for a long time. But I remember my C and C++ days, and whenever I look at C/C++ projects now I can't imagine being that statically bound. My impression is that C#/.NET has similar (if perhaps slightly lessened) restrictions. > Java has much more open source activity, many more libraries to > leverage. Java itself becoming open source clinched the deal of it > becoming the open-source target platform of choice. I was also very excited about the open-sourcing. I think as a result we'll see JDKs on a lot more systems, more pervasively distributed, and the platform will grow tremendously. And I think this will be a big year for OpenJDK in general, what with DVM and the OpenJDK Challenge. > Java's core data structure library and concurrency stuff is much > better, and its memory model better defined (a big issue once I got > into STM). > > Java has a simpler VM architecture, greatly easing interop. Things > like CLR value types and the way they do generics might provide a 10% > perf advantage (or might not), but definitely double the complexity. > Java's generics via erasure are a blessing for dynamic languages. AMEN. From Java, I sometimes lament erasure because it limits how intelligently the language can work with generic types. But as a dynlang implementer...I see the contortions IronRuby and IronPython need to do because they're *forced* to support full generic type instantiation, and it makes me weep. Whatever happens with "erasing erasure" the non-parameterized fallback *MUST* remain. > I eventually decided to generate bytecode on-the-fly and found ASM > much nicer than anything on the CLR side, and, again, a better dynamic > loading story. Differences in bytecode between the platforms are much > bigger than between C#/Java source code, so maintaining a port would > have been much harder still. I have not looked at CLR IL generation, but I do like ASM a lot. JRuby uses ASM extensively for generating method handles and obviously for the compiler itself. What bytecode-level differences do you think would have been the largest issues? I understand that CLR has statically-typed local variables at the bytecode level too, so that's probably one (JRuby is *very* liberal about what it stuffs in local variables). And I would imagine IL reflects the much-more-static nature of CLR. Having investigated it yourself, I'd be interested in hearing your take. > Having dropped the CLR, I've never regretted it. Progress on Clojure > proceeded rapidly. I'm very happy with HotSpot, on-the-fly > compilation, library availability, community, portability etc. Well I'm very glad you're on the group. You may want to join the MLVM list as well, since the Da Vinci Machine patches are starting to fly there. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
