Slashdot Mirror
Mono and dotGnu: What's the Point?
joeykiller writes "The Register features an opinion by Neil Davidson, asking 'Mono and dotGnu: What's the point?' Some of the points he raises may seem irrelevant for open source supporters (like why make a C# compiler while Microsoft's is free anyway), but others are thought provoking and maybe a little bit controversial. You may not agree with his opinions, but it's an interesting read anyway."
just now El Reg published some of the angry letters in defence of .GNU:
.GNU, just presenting a counterpoint.
http://theregister.co.uk/content/35/35557.html
not that i'm trying to defend
The implementation you are taking about - Rotor - is also ported to support Mac & Linux
Concerning Java GUIs: Take a look at SWT (Standard Widget Toolkit). You might be interested in it :-)
You are incorrect.
We have turned Wine into a library, very much like Gtk+ is a toolkit on top of X, or Motif is a
toolkit on top of X, we have turned Wine into a toolkit on top of X.
The reason for doing so is that Windows.Forms is not a perfect API, it is modeled after the
Win32 API, and this Win32-ism is exposed at various points, for example every Control in
Windows.Forms can override the Wndproc method and handle Win32 messages itself to implement
some of the advanced features that are not possible with the simple binding provided.
Most GUI special effects are achieved in this way, and most third-party libraries that you can
download from the network will call into the Win32 layer, skipping the Windows.Forms API.
It is certainly possible to emulate a lot of this without using Wine, but you would just end up
replicating a lot of the work that has been done in Wine.
So instead, we chose to turn Wine into a library that we dynamically load whenever a
component needs to use Windows.Forms.
We made Wine work on multiple platforms (so you can run your Windows.Forms applications on
MacOS X for instance), and we also are integrating it with the Gnome desktop,
so things look and feel the same to end users.
You can learn more about the technical details here: http://www.go-mono.com/winforms.html
Well, J2ME seems to be the alternative choice for embedded apps, so I don't really see why not. It's not like they are going to implement an RTOS kernel in it. The point of these kind of managed code is to provide a sandbox for 3rd party apps to run on embedded devices, so they don't mess things up, and to provide a cross platform environment so app developers don't need (in theory at least) to have separate products for every single device out there. Sure it's slow, but it's also safe.
...Second of all, every user interface I've ever seen done with Java stinks. Maybe I've been seeing bad examples, ...
Most Java apps are not client side apps. Java is (at least at the moment) still heavily server-side. So looking at GUI apps as a mark of quality of Java as a development language is highly misleading, although understandable.
However, take a look at Swing Sightings for some examples of truly outstanding Java GUI apps...
The language is an ECMA standard, but the runtime libraries are not. Without those, C# is pretty useless.
BTW, ECMA accepts all standards that companies care to pay for, they are hardly neutral.
Like SharpDevelop for example?
Programming can be fun again. Film at 11.
I'm sorry you don't find it to be true in the real world. I develop JSP/Servlet java on a windows 2000 box and deploy it to red hat linux. And every time it works exactly the same on each of them, so I would say it is true, at least in my experience.
I agree that going our own path is a more robust
and better solution. And that is exactly what we
have done with our own toolkit called "Gtk#".
Gtk# not only is very nice to program with, but it
is also cross platform and people are using it
in some cases instead of Windows.Forms on Windows
itself.
That being said, our effort to support the Windows.Forms
API is not driven by a need to have that API at all,
we believe it is one ugly API. Our drive to support
it comes from the fact that people are using it,
and have made certain assumptions about it.
So to us Windows.Forms is a compatibility play,
and one that we have to support to assist people
who want to try Mono as a way of moving their apps
to Linux.
The API we are recommending developers to use is
the Gtk# API.
Hope that answers the question