Firefox and Moonlight (Mono) "Free Software" Status?

Colin Walters walters at verbum.org
Sat Jun 7 18:21:23 UTC 2008


On Sat, Jun 7, 2008 at 6:43 AM, Richard W.M. Jones <rjones at redhat.com>
wrote:

> On Fri, Jun 06, 2008 at 11:34:04AM -0400, Colin Walters wrote:
> > On Fri, Jun 6, 2008 at 4:11 AM, Richard W.M. Jones <rjones at redhat.com>
> > 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.
>
> This is getting pretty tedious.


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),


This one is http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm I believe.

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 at 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.
>
> > Practically speaking there are many modern languages available such as
> > Objective Caml: http://ocamljava.x9c.fr/
>
> ... if you give up all the native OCaml libraries,


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.


>
> > Ruby: http://jruby.codehaus.org/
> > Python: http://jython.org/Project/
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20080607/96e46dd7/attachment.html 


More information about the devel mailing list