Re: Some more thoughts on Java vs Mono debate
- From: jamie <jamiemcc blueyonder co uk>
- To: Alan Cox <alan lxorguk ukuu org uk>
- Cc: Xavier Cho <fender gnome or kr>, Gnome desktop-devel list <desktop-devel-list gnome org>
- Subject: Re: Some more thoughts on Java vs Mono debate
- Date: Tue, 30 Mar 2004 15:11:36 +0100
On Tue, 2004-03-30 at 14:16, Alan Cox wrote:
> On Maw, 2004-03-30 at 10:13, Xavier Cho wrote:
> > Agreed. But don't you think it is a huge loss if we can't use many of
> > useful 3rd party libraries or tools built around Java or .NET for
> > compatibility reasons?
>
> Definitely. Its equivalent to being able to program in C but not having
> 75% of the standard C library available. Anyone who had the misfortune
> to write C code on VMS can probably relate to exactly what it was like.
>
> I'd like to see the discussion split into the four seperate pieces
> however
>
> #1 Would it be a good idea to have something like XPCOM or the OO
> classes to clean up the language binding issues once and for all
Yes but as I have said before use of OO technologies in C is generally
impractical/nasty (GObject being the exception).
>
> #2 Do java and/or C# as programming languages have a useful place in
> writing apps for Gnome, especially as a required part
Yes because Gnome could become benefit from the legion of available
programmers with those skills.
>
> #3 Does the virtual machine stuff have any place in gnome, especially
> as a required part
As #2, there also many people with languages other than c, java or c#
and they too could benefit Gnome. Having a common VM for all these other
languages makes seamless operation easy (common runtime/java bean style
component system) and reduces workload reqiured to maintain bindings,
interpreters, bytecode generators etc. Plus they all get the benefit of
a high performance JIT or ahead compiler (something Python/Perl could do
with).
>
> #4 What of #1-#3 are justified for the core of Gnome, given the current
> issues with lower memory systems compared with rivals and given the
> tendancy of Linux especially to be used on lower end hardware.
I agree - I dont want managed code to take over everything, I just want
a RAD option to be used in moderation. You would be crazy to try and
write huge memory intensive apps like OpenOffice in managed code cause
the speed degradation and memory consumption would be phenomenal (just
wait and see what Ms Office.Net is like if they are stupid enoough to
release one).
That said all small to medium sized apps (whether in the desktop or
third party) would be suitable for managed code even on lower memory
systems cuz the dfference would be smaller and less significant - memory
consumption (and performance degradation) tends to rise exponentially
with the more objects you create in managed code.
>
> #4 is the big one. It means answering questions like "is there an open
> source java or .net setup available for every platform/cpu supported",
> is it actually usable, is the high overall performance cost justified,
> is the size of the library baggage being added justified etc
>
> The performance issues bother me, both .net and java people sound like
> the (now defunct) OS world of microkernels "Its only 10% slower in our
> carefully rigged demo not measuring system wide impact - but its worth
> it". Native code may well solve this a JIT is unlikely to, however good.
>
Mono has an ahead compiler so JITs are optional. The back end should be
largely irrelevant cuz mono and java can be run on both JVM and CLR. I
just hope people will choose the best VM - the poor performance of the
current free JVMs would certainly fail on point 4 above and I dont think
many people would make use of it if it were dog slow. (assuming of
course the performance of the free Java JITs are not going to
drastically improve in the short term).
jamie.
> Alan
> --
> "My java environment garbage collected and now there is nothing left.."
> -- Anon
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]