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."
No, QT is a library. It provides (very good) APIs to C++ programmers to do most of the really onerous crap that C++ developers are tired of doing, and are doing in a hundred different ways already.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
Wow....what? .NET is pretty much everywhere now...and parts of Windows -ARE- in it...not the kernel, no (thats like saying C/C++ are failures because you still need assembly for performance critical parts...), but a significant chunk of the user land tools, and a very very big portion of the various tools Microsoft provide are in .NET... from PowerShell, to Sharepoint, going by parts of Visual Studio, SQL Server, Biztalk, the UI of most of their new tools and components, etc.
The huge chunks of legacy code (Office...) can't easily be ported for obvious reason, but abandoned platform? Thats amusing as hell.
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.
I write .NET code and support other developers doing the same as my day job, and we fully support mono. In fact, one product that's due for release soon by a third party that I support is running mono on a headless linux box (it's intended as a sort of "black box" from the customers point of view - the choice was made for Linux and Mono purely because of price - this thing is to be MASS distributed, so Windows licenses would bump up the price too much). This product will be very widely used by our customers, so to me at least, it's clear that mono is mature enough now to be used in the 'real world'.
As far as developing it without Visual Studio - I use VS at work (although still on VS2005 - haven't found a compelling reason to upgrade yet), but at home, where I also do a lot of work when I can't be bothered heading in to the office, I use MonoDevelop. And, for Mac Specific projects, I generally write my back-end in MonoDevelop, compile as DLL(s) and then write the GUI with XCode (Cocoa#). I think I COULD do it with a plain ol' text-editor and get by okay, but I prefer to use a real IDE. With MonoDevelop existing though, Visual Studio is definitely NOT a requirement.
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan
SharpDevelop is BSD licensed, and quite excellent. There is very little preventing you from using this as your primary development environment. SharpDevelop on Mono is also possible.
The sole reason I still buy the VS licenses, is because I also keep juniors using Resharper (a VS refactoring/quality addin) and Diamond Binding (a database access addin/library, again VS only), which pretty much add 20% on the productivity of a bunch of noobs.
Sometimes (rarely) the place I go into uses MS Project Server "properly", and the TFS changeset/issue tracking makes VS worthwhile over SVN as well.
The reasons against using Mono (if you are going for minimising cost of development, and putting ideology aside), is being able to use things like WPF/WCF/WF. This is above and beyond what you need to develop most applications though.
3laws: No freebies, no backsies, GTFO.
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.
So basically, you're ranting against something you haven't tested for close to 3 years. But you 'doubt' it has changed, so you are sure your opinion is still valid.
And you've been modded Informative!
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original. Even if .Net is technical nirvana, if your platform's only implementation comes from a third party, your platform is a second-class citizen.
Only if you care about or need the "latest whizz-bang features". For most serious development I've never needed anything over .NET 2.0 so far, which Mono implements very admirably (plus a bit more).
Yes, it does mean I need to be a little more careful if I want things to run cross-platform - mono isn't in itself a final solution for cross platform stuff, and it's VERY possible to write Windows only code, Linux only code or even MacOS only code when using the .NET Framework and/or mono, but if you're targetting being cross-platform it really isn't too hard to do, and you definitely don't feel "second class" with the current mono versions (definitely did before there was much .NET 2.0 support, but because everything above that is "fluff" to someone developing core back-end stuff, there's been plenty of time for catch-up on the stuff that matters).
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan