Slashdot Mirror
Miguel de Icaza Explains How To "Get" Mono
LeninZhiv writes "It's perhaps the most controversial project in the open source world, but this mostly stems from misunderstanding: Mono, the open source development platform based upon Microsoft's .NET framework. Immediate reactions from many dubious Linux developers have ranged from confusion over its connection with .NET to wondering what the benefits of developing under it are. Throughout the course of its four years of intense development, sponsored by Novell, Mono founder Miguel de Icaza has had to frequently clarify the .NET issue and sell the community on it. In this new interview, Howard Wen asks Miguel to explain himself one more time."
Well, interesting. This tells us the CLR is pretty good. But what about the libraries? Did you use Microsoft's Windows.Forms or Monos?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Good question. Every time I look at the site to see how it's doing, what's implemented and what's not I go cross-eyed. And elsewhere.
.NET environment is fundamentally very well designed and, despite its origins in the evil empire, actually has a lot going for it. And Mono should give the FOSS movement a chance to play their own game of "Embrace and Extend".
Which is a shame, because the
First, release a C# compiler for linux. If you can get developers to user C# that compiles to native code so that it's not dependant on the CLR, then you can introduce the cross-platform aspects of it.
I get the impression that while RMS would tell us to beware the Microsoft Whore, Miguel would ask us to suckle at her teats. The rest of us are somewhere in the middle.
OT, I know.
As mono is only a reimplementation of .NET and the actual implementation can differ, why not compile the source into native executables rather than bytecode? Surely it would be faster that way.
That's my primary problem with it. You shouldn't need gnome libraries running just to run an application. Unfortunately almost every GTK app compiled today depends on having gnome daemons running too.
Why not combine GNUstep and MONO. Allow for full compatibility in both MacOS X and Windows on their native copys?
"Love is like a trampoline, first it's like "SWEET!!" then it's like *BLAMM!*"
Well here is the problem of Mono from a GCC prospective:
Why another back-end, yes GCC does not support JIT but you could have used LLVM for that.
Another thing is Mono developers don't seem to listen to some of the GCC developers when it comes to algorithms, one example is their PRE implementation is based on much slower and not as good algorithm as the one which GCC uses GVN/PRE.
From gcj prospective:
(again) Why another back-end?
Why another ABI, instead of hooking gcj and Mono together, there is another static ABI?
I've been a C# developer for a couple of years now, and have been keeping an eye on Mono. Now that I have a Mac mini, the idea of using a language I know vs. having to learn Objective C, combined with the Cocoa# GUI framework, is very attractive.
I'll be doing some serious downloading this weekend!
Chip H.
It was easier for me to setup XSP and Mono than Tomcat and Struts/Java etc. It might be because XSP/Mono is still relatively immature compared to the bevy o' java frameworks we have to choose from. But sometimes having too many choices wastes lots of time for us newbies. Makes it hard to choose the best solution and causes confusion etc.
Here is the Ajax style Japanese/English dictionary site I'm building with it.
On the other hand, Eclipse is way beyond Visual Studio right now and it makes devel with Java almost fun.
Best Regards,
Interactive Visual Medical Dictionary
JUST TELL ME HOW I GET DOCUMENTATION FOR GTK# AND ALL THE OTHER BINDINGS!!!!!
.NET wrapper "should" look like.. Bah.
I'm serious, you have to wade through old C based documentation, then guess what the
Oh, and monodevelop is still useless. Kudos for the effort, but I pretty much have to develop with #Develop under windows, then copy my exe to linux for testing.
And whats with the libicu version it requires? An emerge -u world pretty much broke everything mono related on my gentoo box.
I don't need no instructions to know how to rock!!!!
IMHO the true benefit of Mono is not in its intrinsic value as a langauge (althought I think that, in general, C# was very well thought out--the Framework was less well thought out, but still pretty good), but in its value (eventually) as a tool for cross platform development.
You can write an application using GTK# and have it run on Windows, OS X, Linux, Solaris, etc. Its the Java promise all over again, but reworked to run better. For this reason alone I am considering doing a non-trivial desktop database application for a publisher in Mono, since they have many platforms, and I think the overall effort of using this system will be easier that trying to pull a Mozilla on my budget.
...En að Besta Sem Guð Hefur Skapað Er Nýr Dagur
This is a bit long-winded, bare with me, I'm practically a ./ virgin ;)
:P Be that as it may, enough flames have been traded on this subject in the past; for me, operator overloading is a major point when doing scientific algorithms, so java is not an option.
.Net framework beta indicates that this will still be present in the next version of the MS .Net JIT.
.Net app, but I'm still dissapointed with the performance compared to other JITed languages like, say, Java.
:)
Some time ago, getting spontaneously fed up with C++ with managing memory, obscure STL bugs and so forth, I decided to check out if Mono 1.1.4 (C#) would cut if for my application performance-wise.
Now, this application is a quite performance hungry scientific comptation app wich makes heavy use of vector and matrix operations so the first thing I did was port a sub-set of my home-grown library for this to C#.
The classes use operator overloading to facilitate greater readability in the main code. I then proceeded to implement a fairly simple set of algorithms to test the performance of C#/Mono vs C++. Although I did expect some sort of overhead and slowdown in C#, I was quite surprised and discouraged to find that overall, compiled C++ was faster than Mono's JIT by several orders of magnitude (i.e. 0.018s vs. 1.2s). As is well-known, in theory a good JIT should be able to handle some things better than a static compiler can - and I expected this to be the case with Mono's JIT as well, so to at least lessen the performance impact somewhat.
Now, I have seen what Sun has been able to do with their JIT compiler the last couple of years. I many cases Java code executing under their JIT will have a acceptable (small) overhead compared to native C++ code - and the productivity increase of dealing with managed code will more than make up for this. Unfortunately, the powers-that-be in the Java language community decided to ban operator overloading, apparently because it can be mis-used. As if one cannot create functions that don't do what you would think they do as well
I started to dig a little to find out why Mono's JIT fared so poorly in my case (which admittedly probably is a fairly untypical use). The reason seems to be that pracically none of the operator overloaded operations were getting inlined. And the objects returned from e.g. a vector addition operation were actually being created instead of being temp-used by the caller (I forget the term for this type of optimization). Also, it seemed that only extremely basic loops/brances would be optimized.
A bit of googling shows that this is a known problem in Microsofts JIT as well. The reason is supposedly the need for a balancing of application-startup and JIT time. Reports pertaining to the new JIT shipping with the newest
Now, I appreciate that my kind of app is probably on the fringes of what could be considered "a typical"
I also tried the Mono AHT compiler with various settings with no significant performance gain for my examples (and quite a bit of slowdown in some cases).
So, end of story; I'm back with C++, with it's irritating - but familiar - quirks and methodolgy. As for now, there still are no other (OO) languages that meets my needs for high performance and language convenience (operator overloading) - and yes, I've looked at Python+Pyrex/Psyco as well.
Hopefully this issue will be address in a future Mono JIT, but I have a feeling it may not be high on the priority list as most "ordinary" apps will not suffer from this kind of problem.
YMM, of course
Or, at least that's what I intend to do it.
.NET seems a fairly good choice.
.NET looks like a good choice for future programs. The language looks pretty good, and if I properly separate UI and logic, it should be a lot easier to migrate stuff to Linux. Besides, by the time Microsoft drops support there will be mature and well tested alternative implementations out there.
Here I maintain some old apps written in VB6. Mainly interfaces to a SQL Server database and such. Microsoft is dropping support, so it seems logical to start thinking of something else to write stuff in, and
We have a very MS-centric environment here, but it doesn't seem that anybody particularly cares if it's Windows or not. Simply, stuff works with MS at the moment, and of course nobody is going to let me rewrite it all on Linux on company time without some very good reason.
So, I'm thinking
I'm not going to start making a switch to Linux right now, but my idea is that eventually somebody is going to ask me what to do when our VB6 stuff won't run on the newest Windows version, and I'll be able to answer "We can switch to Linux, and it will work without having to rewrite it".
Yeah, I was coding an IRC bot in C# using .NET 2.0 beta on Windows with Visual Studio 2005 Beta 1, and thought it'd be interesting to see if Mono can handle it. I'm a Windows user, but have Gentoo installed to play around with. My experience:
I have yet to test Mono with .NET 1.1 code, mainly because I don't have anything interesting since moving to 2.0 beta. But given what I've seen with its implementation of a beta framework, I have a feeling 1.1 is well-implemented. Maybe other areas such as Winforms are poorly implemented at the moment--I don't know--but they've made excellent progress already.
As for Mono versus C++, this is basically a .NET versus C++ question, which has led to large flame wars everywhere I've seen it asked. My personal opinion? Well, C++ was the first language I learned, and I had been using it for 6-7 years before I gave C# a try. I've been using C# ever since, around 2-3 years. Maybe if you're doing something that requires crazy amounts of performance C++ would be a better fit, but I don't do that, and the simplicity gained through C# and the .NET libraries far exceeds any performance penalties I experience (which aren't even large in the first place for the work I do).
Mono versus .NET C#: Of course Mono is behind since Microsoft is driving the development of C# 2.0. But from what I see, it seems Mono is mainly behind in the implementation of the .NET libraries. All of the C# 2.0 language features I used worked fine.
C# 2.0, .NET 2.0, and Visual Studio 2005 will likely be released later this year. Mono has reached impressive levels of compatibility already with C# 2.0, and compatibility with .NET 2.0 classes seems to be coming along fine. I'll definitely be keeping my eyes peeled for future releases.
There is a very simple solution to all this.
Rather than Miguel having to repeat himself over and over in defense of Mono, why doesn't Novell just release the legal opinions they have on the important issues related to Mono?
Instead of telling us not to worry, just give us the facts.
I realize that this is a lot to ask of a company, but the FLOSS community is hard to satisfy. It wants to get the real info, not just the marketing.
Novell doesn't need to release their whole Mono legal opinion. Just enough to answer the questions that concern OSS developers. For example, could the EMCA parts of Mono ever require a license other than the GPL? What is likely to happen with the Mono implementation of ASP.NET?
Now, why would I want to rely on software that will get stopped in court? Why would I want to buy from a Linux vendor that might get shut down (bankrupted, etc.) via court action?
Serious!
I make my filthy living doing enterprise Java apps. I love my Linux servers and my Powerbook. But I don't go around preaching the gospel of Java to the unconverted. And that's exactly the point: Linux already has two useful and proven languages for desktop apps - C/C++. Make those better!
I almost feel like Miguel has been living in the corporate world a little too long, thus, like you said, his preaching of something else - a typical thing in the real world is not to fix it, but to re-do it in some other language. I see this stuff all the time and just roll my eyes. Then I spend ridiculous hours helping various teams meet their goal.
This is actually classic if you think about it. At first, KDE, namely Qt, was not open source. So instead of trying to fix it they made an entirely new desktop system. Of course, Qt later dropped those restrictions and now Gnome is the fat dog that can't get off the porch. So the mantra is if it doesn't go our way, we'll re-do it, but make it worse! Deja vu anyone?
Linux does not need sloppy developers porting all their crap from Windows. I mean, I think of all the junk out there on download.com.com.com.com and try to visualize that on my Mac (fortunately that's not possible) and a chill runs up my spine.
If you want to program a Linux app, learn C - it's not that hard and it can actually be, dare I say, fun! If you find something you don't like or you see is broken, submit the changes/fixes back to the community. Yay, you're an open source developer now!
C aside, sure, people will use Python, Perl, Ruby, nothing wrong with that. But these are languages with a Unix history, not a VB one. So I think the whole premise of wooing developers from a flawed platform design - ergo flawed programming logic - over to something that has much more academic exposure and a very rich history (I'm talking Unix here), is a disaster waiting to happen.
When I first started being interested in programming desktop Linux I didn't go look for Java bindings (altho, I did look for a JDK for server stuff), I used what was out there; in other words, I didn't try to re-invent the wheel! That said, yeah, sure, the C/C++ libs aren't perfect nor are they the holy grail of software development. I dunno, it just strikes me as odd, like some alien invader trying to convince me feverishly to get on board his space ship but won't tell me why(if you can imagine that), that there is so much push for Mono. Does make sense, I suppose from a corporate control point of view. Mono's roots are in the devil and that's enough for me. Yeah, sure, Sun owns Java, but Sun's also a Unix (yes, somehow that DOES make it milimeter better, esp compared to M$!) company and I have a little more faith in their corporate sesspool than Microsoft's. Altho, Schwartz is kinda dorky.
Anyway, the last line of the above post says it all; anyone invoking the name of Mr. Graham in a way that's pure and simple has the last word in my book.
Wake up.
I hate to say it, but given the current software patent regime, that is the strongest guarantee ANY software project can give (Free or otherwise).
Let's say you're writing a piece of software. Can you guarantee that you aren't violating any patents?
Probably not -- you're almost assured that there are already patents in place, even for relatively trivial things; your safety from those depends wholly on either the patent-holder's ignorance or good graces.
Oh, and by the way, don't go looking for yourself to make sure there aren't any patents covering what you want to do. Once you've read a patent you're liable for triple damages if a court later determines that you violated it. That you think you're safe (per your interpretation of the patent) doesn't matter; before the law only patent lawyers are deemed legally competent to make those evaluations.
Yes, Virginia, things really are that bad.
In Mono's case at least Novell had patent lawyers look at the situation before proceding.
DNA just wants to be free...
Believe it or not, Objective-C and Cocoa still have advantages that C# has yet to catch up to.
.nib files are actual serialized object graphs, so there is no code-generation. At run-time, the objects are just loaded into memory automatically as though they were created in code. Which keeps my project clean and seperated from the GUI (that whole model-view-controller thing) and really makes prototyping a GUI easy. I just hit Cmd-R to test the GUI in Interface Builder.
I still shake my head when I use the Visual Studio beta and create a form, and look at the code to see it instancing classes in an InitializeComponent() function. Anyone whose used Visual Studio before knows things can go haywire if you dare touch any of that code. You have to leave it alone or the editor gets pissy.
In Cocoa, the
I also like the way method parameters are self-documenting in Objective-C. It's easier to understand a "[something doThis:parameter1 usingThis:parameter2 forThis:parameter3]" then it is a "something.doThis(parameter1, parameter2, parameter3)".
Just my opinion, and I'm sure there are those who have valid reasons to use C#/.NET instead. But I used to be a C# guy too until I learned Cocoa. The flexible messaging system alone keeps me using it.
MS would NEVER let this happen. Have you ever heard of J++? Once .NET grabs hold MS would extend it in such a way as to make apps written in C# incompatible with their non-ms bretheren. Exactly what they did with J++. The difference here is that Sun owned Java and sued MS for extending Java without their permission. In this case will Mono sue MS for extending C#? MS owns it!
FUD. MS owns an implementation of the C# standard. They do not own C#.
- AMW