On Sat, Jun 7, 2008 at 6:43 AM, Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Fri, Jun 06, 2008 at 11:34:04AM -0400, Colin Walters wrote:<br>
> On Fri, Jun 6, 2008 at 4:11 AM, Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>><br>
> wrote:<br>
> > One major reason is that it allows languages to be mixed and to call<br>
> > easily from one language to another. Free software dropped the ball<br>
> > on this (Parrot), and Mono/.Net is the only widely available<br>
> > implementation of this idea.<br>
><br>
> It was *marketed* as such, but in fact many different languages have run on<br>
> the JVM for a long time:<br>
> <a href="http://www.robert-tolksdorf.de/vmlanguages.html" target="_blank">http://www.robert-tolksdorf.de/vmlanguages.html</a><br>
> Some of them date to 1996.<br>
<br>
</div>This is getting pretty tedious. </blockquote><div><br>And offtopic for fedora-devel. But, it's a more interesting discussion than a complaint thread about nVidia drivers =)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In brief, the JVM has design issues<br>
that make implementing non-Java-like languages hard and/or slow. </blockquote><div><br>That's a rather sweeping generalization, which seems to have Clojure (<a href="http://clojure.sourceforge.net/" target="_blank">http://clojure.sourceforge.net/</a>), Scala, and JRuby all as counterexamples. Clojure in particular is wildly different from Java. Whether it was hard to implement is unknown, but the author is from what I've seen an incredibly smart person.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
particular issues are: lack of good support for closures, </blockquote><div><br>Closures are a language level construct - once you have garbage collection in the runtime they're easy, and most of the new JVM languages do have nice syntax for anonymous inline closures. What exactly you mean by "good support" is hard to say.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">lack of<br>
polymorphic types (affects dynamically typed languages in particular,<br>
but also functional languages), </blockquote><div><br>Er...isn't the object system polymorphic? Are you talking about multiple dispatch?<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
inability to<br>
handle tail call optimization in mutually recursive functions (a<br>
serious concern in functional languages), </blockquote><div><br>This one is <a href="http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm">http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm</a> I believe.<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">hideous native code interface, </blockquote>
<div><br>Reaching out and touching libc from the JVM, interactively:<br><br>Groovy Shell (1.5.6, JVM: 1.6.0-b09)<br>Type 'help' or '\h' for help.<br>-------------------------------------------------------------------------------------<br>
groovy:000> import com.sun.jna.*<br>groovy:000> CLibrary<br>===> interface CLibrary<br>groovy:000> CLibrary.INSTANCE<br>===> Proxy interface to Native Library </lib64/libcom_err.so.2@139792604163248><br>
groovy:000> public interface CLibrary extends Library { <br>groovy:001> CLibrary INSTANCE = (CLibrary)Native.loadLibrary("c", CLibrary.class);<br>groovy:002> long clock();<br>
groovy:003> }<br>===> true<br>groovy:000> CLibrary.INSTANCE.clock()<br>===> 6420000<br>groovy:000> CLibrary.INSTANCE.clock()<br>===> 6460000<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
lack of dynamic<br>
method invocation, </blockquote><div><br>What does that mean?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">lack of eval, </blockquote>
<div><br>If any sane application relies on eval it's probably broken, but really once you have a language it's trivial to implement eval, because you probably already have an interactive toplevel which takes strings and turns them into code.<br>
<br>Where are you getting this list from?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">lack of efficient tuples,</blockquote><div><br>Right, I don't think this one is "soon" but it will likely happen; <a href="http://blogs.sun.com/jrose/entry/tuples_in_the_vm" target="_blank">http://blogs.sun.com/jrose/entry/tuples_in_the_vm</a><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
lack of<br>
continuations (eg for Scheme). </blockquote><div><br>Realistically, I doubt there are many real-world Scheme programs out there that actually make *full* use of call/cc, as opposed to indirectly using it by calling into a e.g. green threading library which is implemented with call/cc. Not that there aren't interesting things one can do with full continuations; the RIFE framework (<a href="http://rifers.org/blogs/gbevin/2005/9/23/announcing_rifecontinuations" target="_blank">http://rifers.org/blogs/gbevin/2005/9/23/announcing_rifecontinuations</a>) has some examples.<br>
<br>That said, this one has a working prototype already:<br><a href="http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/callcc.patch" target="_blank">http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/callcc.patch</a><br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Some of these are fixed in JSRs, but<br>
the process is incredibly slow and I'm not aware of any fixes that<br>
actually ship in a JVM.</blockquote><div><br>These things change slowly, that's true.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Of course the JVM is Turing complete, so it is possible to implement<br>
any programming language on the JVM, but that doesn't necessarily mean<br>
it's going to be fast or good or allow you to practically call from<br>
any language to any language.<br>
<div><br>
> Practically speaking there are many modern languages available such as<br>
> Objective Caml: <a href="http://ocamljava.x9c.fr/" target="_blank">http://ocamljava.x9c.fr/</a><br>
<br>
</div>... if you give up all the native OCaml libraries, </blockquote><div><br>Sure, but if we're talking about the JVM versus .NET, you also have to give those up.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
duck typing, multiple inheritence, 64 bit ints, immediate objects, and a bunch of </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
other stuff.</blockquote><div><br>It's not clear to me those are fundamental tradeoffs vs just not implemented for some reason - e.g. what would blocking using "long" for 64 bit ints? Duck typing shouldn't be that hard.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
> Ruby: <a href="http://jruby.codehaus.org/" target="_blank">http://jruby.codehaus.org/</a><br>
> Python: <a href="http://jython.org/Project/" target="_blank">http://jython.org/Project/</a><br>
<br>
</div>Described here as "a slower slightly more out of date version of<br>
Python, with fewer libraries" / "At this moment, writing libraries in<br>
Jython that would be in an attempt to make them usable to Jruby and<br>
Groovy folks seems like a fools errand."<br>
<a href="http://compoundthinking.com/blog/index.php/2008/02/27/jvm-as-platform-for-dynamic-languages/" target="_blank">http://compoundthinking.com/blog/index.php/2008/02/27/jvm-as-platform-for-dynamic-languages/</a><br></blockquote>
<div><br>There is largely never going to be a clean automatic way to do cross-nonnative language calls. Here by nonnative I mean languages which were designed to run on a custom runtime (not JVM/.NET). For example, Python strings are immutable, Ruby strings are mutable; if you were to pass a Python string into a Ruby function it couldn't act exactly like a Ruby string. The corner cases get even more bizarre once you start to look at more languages and more data types.<br>
</div></div><br>The more compelling long-term direction behind the JVM and .NET is taking the *good* things from different languages (e.g. OCaml's type inference and pattern matching, Python's clean syntax, generators) and throwing out the bad stuff (non-Unicode strings, bizarre/broken class models) and creating new languages that are native to the runtime; Microsoft has done this to OCaml with F#, Groovy is a much nicer and more strongly integrated dynamic language than Python/Ruby, etc.<br>
<br>Anyways, the point I wanted to refute is this:<br><br>> > Free software dropped the ball<br>
> > on this (Parrot), and Mono/.Net is the only widely available<br>
> > implementation of this idea.<br><br>And I believe that's been done.<br><br>