One question is why we want to run all these different languages on
the JVM.  I think the most substantial reason is to have access to all
the marvelous libraries available in Java.  We have those shipped with
the JRE, plus a veritable treasure trove of open source libraries and
frameworks to choose from.  The downside is that the ubiquitous
interchange of objects from one language to the other, via the JVM, is
quite difficult.  Whether it be for language semantics reasons, or
internal wrapper implementations that make objects "look/act" like a
standard object in the bridged language.  The CLR was designed with
language interoperability in mind, while not so much for the JVM.  The
point being, a C# to bytecode compiler and bridge library can be
created, but the result will likely be a language that is implicitly
different from the one that runs on .NET/Mono.  That said, I still
support bringing various languages to the JVM, in that (with a given
set of caveats) it broadens the tools available to the Java community
- not to mention non-Java programmers who benefit from this symbiotic
relationship.

As to merging Java and C# in some fashion:  while C# is an attempt to
build a "better Java," they diverge pretty quickly once one looks
beyond the pure syntactic similarities.  Some aspects of C#, indeed,
address deficiencies as I perceive them in the Java language (structs,
standardized bridging to other languages, and various improvements
mentioned in this thread.).    Others, IMHO, repeat the sins Java has
successfully cast aside in order to address shortcomings in C/C++.  A
previous poster, Lars W., pointed out that "but for my everyday work,
Java does most things I need."  I started out with Java pre-1.0
release, and the language provided a wonderful break from C++ that was
simple and just worked.  The improvements and extensions to the core
libraries since then have only increased the language's value
proposition as a great platform for development.  Using those original
language syntax and features, one has the tools to write at any level
of complexity.  Maybe not as compactly or efficiently as we can with
Java 6 language features, but write it nonetheless.  The problem being
addressed by java.next or the great search for the new "lord of the
ring" language is that Java, C#, what have you can be improved upon
and come up with a next generation language.  One that I personally
hopes addresses parallelism inherently and leaves the broken notion of
threads, processes, and hacks we've used for thirty years behind.

I apologize for going off on a tangent, but there is a relevant motive
here.  We need to ask ourselves if the effort to bend and mold other
languages to run on the JVM is a worthwhile effort, or just a delaying
tactic until the next great thing comes along.  For my 2 cents, I
think we are learning a great deal from the efforts on JRuby, Scala,
Jython, JSqueak/Potato, and many, many other projects - my admiration
goes out to these individuals and their projects.  I'm sure we would
learn a great deal from a similar effort for C#.  But the choices are
clear:  build a new language on the JVM, port an existing language to
the JVM, or go out and build a new language (and VM).  You will get
what you seek - just decide what it is you are seeking.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" 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/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to