Slashdot Mirror
The Case For Supporting and Using Mono
snydeq writes "Fatal Exception's Neil McAllister argues in favor of Mono, asking those among the open source community who have 'variously described Mono as a trap, a kludge, or simply a waste of effort' to look past Miguel de Icaza and Mono's associations with Microsoft and give the open source implementation of .Net a second chance, as he himself has, having predicted Mono's demise at the hands of open source Java in 2006. Far from being just a clone of .Net for Linux, McAllister argues, Mono has been 'expanding its presence into exciting and unexpected new niches.' And for those who argue that 'developing open-source software based on Microsoft technologies is like walking into a lion's den,' McAllister suggests taking a look at the direction Mono is heading. The more Mono evolves, the less likely Microsoft is to use patent claims or some other dirty trick to bring down the platform."
Microsoft has a history of using patents to protect its desktop market share. They attempted to scare people out of using open source software because it supposedly violated 235 of their patents. Therefore, I believe it is prudent that the open source community remain sceptical of Microsoft as well as implimentations of any of its technology including the .net platform.
Sigs are too short to say anything truly profound so read the above post instead.
With Mono you can run C# code (even WinForms) not only on Linux, but also MacOS and it seems also on Solaris (http://codicesoftware.blogspot.com/2008/12/plastic-on-solaris-10.html, http://codicesoftware.blogspot.com/2008/12/opensolaris-and-mwf.html). The only thing they miss is a decent debugger on all platforms (currently only on Linux). It's unfortunately not easy to develop on Mono right now, but IMHO only due to the debugger. If they had one, more and more people would be jumping into it. Performance is very, very good, close to C/C++, but coding in C# is easier.
With Qt 4.5 going LGPL in March, one would have to wonder why you would use Mono over Qt or Java.
.msi for the package.
Because you need to consider your target audiences - Windows users vs Linux users.
Not to make this a flamefest about intelligence, but I think we can all agree that, almost by definition, Linux users tend to have a far higher comfort level with trying new things on their machines.
Simply put, Linux users, if they want to use a given package, will install Wine/Mono/Dependency-X to get the package to work. Windows users will not install QT unless it comes as part of the whole one-click
Until Mono gets WPF support there isn't going to be much cross-compatibility. Any Windows .NET developer with any sense is writing in WPF already. WinForms is dead.
This is pretty lame reasoning - new applications are only part of the reasoning behind deciding which apis to support. Supporting the huge number of *existing* applications is also important, and the vast majority of the desktop .net applications out there now use winforms.
But Mono seems quite content to ignore WPF for now. One can't help but think it was part of that Novell/Microsoft deal.
More faulty reasoning - have you seen the WPF api? It's enormous. As one of the people with the most commits in WPF-land, I can assure you, it's not prioritized based on any deal. It's strictly a resource issue. Moonlight is just more bang for the buck. Much smaller api to implement, much quicker adoption than WPF. Makes good business sense. That said, WPF remains a spare time project for me (and others).
The subset of WPF in Moonlight is useless for non-web development. It's great way for MS to pretend their Flash-killer format is multi-platform though.
Again, not really true. Silverlight 2.0's api is more than capable of building apps for both webpages and desktop, and will become more so as WPF and Silverlight converge. It will take some extending on the mono side for desktop integration, but again, when the choice is using an existing technology and extending it slightly (as in Moonlight) or starting fresh on a GIANT api (as in WPF), which would you choose?
I guess all that stuff in the Mono.* namespace that Microsoft's release of their framework doesn't support is just following right along. Like Mono.SIMD. Or Mono.CSharp, which (unlike Microsoft's libraries) contains a fully featured compiler service and runtime evaluator. Or the other Mono stuff that Microsoft's releases can't do, like full static compilation for the iPhone and Microsoft's own XBox 360.
I'm guessing you don't know much about what you're talking about, but hey, it's Slashdot, that's par for the course.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
I am not a Mono dev, just an occasional contributor via Google Summer of Code, but I don't really see a reason you can't do both. I think it's kind of obvious, really--Java's the same way. If you stay "within the lines" (which are usually very clear), your code will be cross-platform. If you do more out-there stuff, it's going to require more and more work to make it work in a cross-platform manner.
(.NET/Mono is already pretty awesome even for projects that require native libraries, though. Package libfoo.dll and libfoo.so in with your executable and assemblies, and it will intelligently grab the right one on Linux/Windows. Not so easy on BSD, Solaris, or OS X, but those really aren't primary platforms for that particular effort.)
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Couldn't agree more. I've tried to develop code using mono and notepad (or vi, whatever) instead of Visual Studio. It's practically impossible.
.NET developer who doesn't use Visual Studio and I'll show you a magician. Visual Studio (which I admin, I think is awesome) is such a great IDE and it generates a lot of useful code and config files (etc etc etc) and crap that makes it a complete nightmare to do without.
.net code using mono and some other IDE, it's technically possible, and you could do it, but it'd be like pulling a shopping cart along with a toddler attached instead of removing the child and then pushing it. Stupid and too much effort.
The microsoft documentation is only useful if you're using Visual Studio. Period. Find me a
Now it is technically possible to write
Just fork out the $$ for VS and you've instantly saved yourself weeks of development. But Mono.... just give up now. Unless things have changed over the past 2 or 3 years. But I doubt it. I don't even really understand why they bother.
I contracted a while at Microsoft, and every blue badge (full-time developer) I ever met ignored VS.NET and used vim or emacs all day (for C#, C++, XML, everything except the occasional dialog edit) with the MSDN docs open on the other monitor. No lead with a clue lets the opaque plumbing inside an IDE determine whether their project gets built corectly (we used build.exe, a make clone from the DDK), WinDbg is far more powerful than the builtin debugger (download and try it), and an editor with too much "assistance" to even keep up with your typing (on desktops fast enough to run internal debug builds of Vista!) was just unforgivably lame.