On Fri, Jun 06, 2008 at 11:34:04AM -0400, Colin Walters wrote:This is getting pretty tedious.
> On Fri, Jun 6, 2008 at 4:11 AM, Richard W.M. Jones <rjones@xxxxxxxxxx>
> wrote:
> > One major reason is that it allows languages to be mixed and to call
> > easily from one language to another. Free software dropped the ball
> > on this (Parrot), and Mono/.Net is the only widely available
> > implementation of this idea.
>
> It was *marketed* as such, but in fact many different languages have run on
> the JVM for a long time:
> http://www.robert-tolksdorf.de/vmlanguages.html
> Some of them date to 1996.
And offtopic for fedora-devel. But, it's a more interesting discussion than a complaint thread about nVidia drivers =)
In brief, the JVM has design issues
that make implementing non-Java-like languages hard and/or slow.
That's a rather sweeping generalization, which seems to have Clojure (http://clojure.sourceforge.net/), 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.
The
particular issues are: lack of good support for closures,
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.
lack of
polymorphic types (affects dynamically typed languages in particular,
but also functional languages),
Er...isn't the object system polymorphic? Are you talking about multiple dispatch?
inability to
handle tail call optimization in mutually recursive functions (a
serious concern in functional languages),
hideous native code interface,
Reaching out and touching libc from the JVM, interactively:
Groovy Shell (1.5.6, JVM: 1.6.0-b09)
Type 'help' or '\h' for help.
-------------------------------------------------------------------------------------
groovy:000> import com.sun.jna.*
groovy:000> CLibrary
===> interface CLibrary
groovy:000> CLibrary.INSTANCE
===> Proxy interface to Native Library </lib64/libcom_err.so.2@139792604163248>
groovy:000> public interface CLibrary extends Library {
groovy:001> CLibrary INSTANCE = (CLibrary)Native.loadLibrary("c", CLibrary.class);
groovy:002> long clock();
groovy:003> }
===> true
groovy:000> CLibrary.INSTANCE.clock()
===> 6420000
groovy:000> CLibrary.INSTANCE.clock()
===> 6460000
lack of dynamic
method invocation,
What does that mean?
lack of eval,
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.
Where are you getting this list from?
lack of efficient tuples,
Right, I don't think this one is "soon" but it will likely happen; http://blogs.sun.com/jrose/entry/tuples_in_the_vm
lack of
continuations (eg for Scheme).
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 (http://rifers.org/blogs/gbevin/2005/9/23/announcing_rifecontinuations) has some examples.
That said, this one has a working prototype already:
http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/callcc.patch
Some of these are fixed in JSRs, but
the process is incredibly slow and I'm not aware of any fixes that
actually ship in a JVM.
These things change slowly, that's true.
Of course the JVM is Turing complete, so it is possible to implement
any programming language on the JVM, but that doesn't necessarily mean
it's going to be fast or good or allow you to practically call from
any language to any language.
... if you give up all the native OCaml libraries,
> Practically speaking there are many modern languages available such as
> Objective Caml: http://ocamljava.x9c.fr/
Sure, but if we're talking about the JVM versus .NET, you also have to give those up.
duck typing, multiple inheritence, 64 bit ints, immediate objects, and a bunch of
other stuff.
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.
Described here as "a slower slightly more out of date version of
Python, with fewer libraries" / "At this moment, writing libraries in
Jython that would be in an attempt to make them usable to Jruby and
Groovy folks seems like a fools errand."
http://compoundthinking.com/blog/index.php/2008/02/27/jvm-as-platform-for-dynamic-languages/
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.
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.
Anyways, the point I wanted to refute is this:
> > Free software dropped the ball
> > on this (Parrot), and Mono/.Net is the only widely available
> > implementation of this idea.
And I believe that's been done.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
