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."
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 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.