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."
It's not really free if you are using Microsoft, because they anticipate that in order to use C# compiler, you will need other Microsoft products that cost money. They aren't a non-profit organization! That's a great reason to make YAC#C.
stuff |
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
He understands why you need to do that, at least he says so. It's just that he doesn't see the point in the compiler in the first place.
As for me, I think it's a cute project, but it's only use I see is cross-platform GUI applications. (a good thing for Linux adoption by the masses) And Mono is way off for doing that.
The implementation you are taking about - Rotor - is also ported to support Mac & Linux
You can download the Rotor source free and compile/run it on Windows XP, FreeBSD and Mac OS X. Or maybe you meant on Linux.
Theoretically you could write C# applications for those platforms just like you could write C, C++ etc. applications for them. I don't see how you would need any other Microsoft products to use their C# compiler, though obviously Microsoft currently produces the most comprehensive development environment for C#.
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.
The trick is that C# code is compiled to the
Common Intermediate Language, so you compile in
one platform, and you run in another one. All you
need is a virtual machine running on the target
system
That is correct.
But we have. We support SPARC, SPARC 64 bits, HPPA (32 and 64), StrongARM and PPC in a wide range of operating systems.
...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...
We are aware of a bug in the JIT compiler in the PPC,
something that we are actively fixing.
(We do not officially support the MacOS X for this
very reason: we are not done yet with the port,
the technical detail has to do with the patching
of generated methods to point to new methods that
are JIT compiled on demand, and the issue there
is that the PPC needs more room to do calls that
span the +32/-32 meg barrier, so you need to build
some thunks, not hard to fix, and on our todo list)
The Mono C# compiler works on OS X, we use it to
build all the class libraries and Gtk# as well.
Miguel
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.
This problem has been in existence forever - how can it be that C compilers can be written in C? (Hint: the first one wasn't)
Carpe Daemon
Well if you want a J2ME equivilant, then there is the .net Compact Framework. Already built into the latest PocketPCs and Microsoft "Smart"phones, as well as CE.Net 4.1 which is marketed for embedded systems
Mono _IS_ the .NET Framework. So how is it not a knock off? Because it runs on Linux?
.NET for non-Windows environments. Its a .NET Knock off.
And just because Mono uses GTK which can also run on Windows does _NOT_ mean that there is no work involved in porting it to another architecture. The fact of the matter is that porting from windows to linux to bsd to solaris will always involve some sort of functional changes.
Mono is simply
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.
Java is available for MS Windows (95,98,ME,NT,2000,XP,CE), Linux, Apple MacOS, FreeBSD, IBM AS/400, IBM OS/390, IBM AIX, IBM OS/2 (yes, some people are still running it), Sun Solaris, SGI IRIX, PalmOS, Nokia cell phones and numerous other embedded devices. I'm sure I've missed a few but that's just off the top of my head.
When .NET allows me to run a program on everything from a mainframe to a cell phone then I'll be impressed. I doubt that will ever happen because Microsoft is too afraid to put .NET on any platform it can't dominate.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
Calling Mono an extension to .NET because it uses Gnome is like calling a Ford car chassis with a Yugo engine an enhanced vehicle.
.NET.
.NET as a Framework. They are also nowhere near completion of implementing the entire Framework. Right now Mono is a "neat tool" which might let you run your C# app under Linux (no offense to your work and efforts intended, Miguel).
Mono feeds off of the various Linux GUI libararies in order to implement the windowing requirements for
Mono offers no improvements to
In Mono we took a different approach, we created, integrated and built our own standalone stack ;-)
Look at: http://primates.ximian.com/~miguel/tmp/map2.png to get an idea of what we have to offer today
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
Further, we only need to find one practical use of mono to demonstrate that the conclusion is categorically wrong. That mono ships with commercial products such as Virtuoso suggests that there is at least one practical use of mono.
On Davidson's second point, I think he misunderstands patronage. Microsoft does not currently fund mono in any way in which I am aware. They do fund some competitors to mono such as rotor and (at least at one time) Corel's attempt to bring dot net to Linux. His only example of Microsoft being a patron consists of a hypothetical chain of events that is exceedingly unlikely. I suspect that perhaps Davidson meant forbearance instead of patronage. If he did, he would do well to explain exactly how Microsoft's patents threaten mono because some people (including people far brighter than me) do not see any clear and present danger.