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
There's simply no overwhelming reason to use this when alternatives exist.
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."
Lucky for Windows users, Windows will always search the current directory first for DLLs that an app needs. So just include them. QtCore4.dll and a few others. Many apps ship their own version of Microsoft's DLLs just to make sure the app will call the correct version without worrying about a newer version being in system32 or the wrong version being called from WinSxS.
No, there is no case for using Java or Qt now. Qt looks sleek on every OS and is SO incredibly easy to program. It is native and is very fast.
Java has already been made to run on .NET. I wonder if it'd really be that hard to get standardized C# running on the JVM?
The longer answer is that for anything written targeting the .NET Framework (Mono or otherwise) version 2.0 and beyond, it would extremely difficult if not flat out impossible. The first thing that comes to mind is the runtime erasure of the type parameter(s) for Java's generics. This does not exist in .NET and that has some significant implications. There would simply be no straightforward way to get the following C# class to work in the Java Runtime:
class MyClass where T : new()
{
public T GetNew() { return new T(); }
}
To be fair, I have similar gripes about Java. Not so much the javadoc as making sense of the "enterprisey" marketoid bullshit smeared throughout Suns web presence. The entire thing feels bloated, an entire programming ecosystem to keep middle managers in jobs. Naturally Microsoft's Java knockoff expands upon this with their typical NIH aplomb.
I tried Mono and PNet years back, even then it seemed to me like a solution in search of a problem. If an app isn't performance critical and you can get away with running on the CLR, then for most real world stuff you probably can do it as a webapp. If it can't be done in a browser, an embedded scripting engine (lua, js) and C/C++ (or Vala/genie) would make more sense.
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.
Yeah, that's because most ARM platforms can execute Java bytecode natively.
The processor IS the JVM.
Mod me down, my New Earth Global Warmingist friends!
Untrue. You can run 1.1 applications in 2.0. The default is to install both side-by-side.
And .NET 3/3.5 both run on the 2.0 CLR.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Honestly? I don't use .NET/Mono specifically for cross-platform programming, although it's a nice plus when you can get it "for free," or nearly so. I use it because it's a single language and coherent system for a lot of different stuff.
Rich web content? Silverlight. C# (or any other CLR language), most of what I'm familiar with, without having to worry about relearning my tools or language.
Websites? ASP.NET. C#, most of what I'm familiar with, without having to worry about relearning my tools or language. (Bad example, though, because I personally use PHP and mod_mono isn't really good yet. ASP.NET MVC makes it a lot nicer to use though.)
Desktop apps on Windows/Linux? Bog-standard .NET/Mono. C#, most of what I'm familiar with, without having to worry about...you get the idea.
I used Java for much the same reasons when I used Java. Same language, same framework, different application for it.
(Plus, when it comes to Mono.CSharp and Mono.SIMD, I'm pretty sure you can package those specifically with your program to run them on the Windows .NET CLR. For Mono.SIMD in particular, it actually falls back to managed code on platforms without SIMD code support, which is a really nice feature.)
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Objective-C
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."
Politically, Mono/.Net is a win. For the reason for NOT jumping onboard the Mono bandwagon, look no further than Microsoft's attempt to hijack Java.
Java and .Net are actually a lot alike. They're both language systems based on virtual machines that come from sponsors who also happen to market operating systems.
The crucial difference is that Sun had made repeated and determined efforts NOT to link Java to any one OS - even going so far as resisting for years the idea of giving Java apps access to OS environment variables on OS's that support such a thing (which is most of them).
Microsoft, on the other hand can't seem to field any product without hooking it intimately into Windows. I've yet to see what making IE "an integral part of Windows" does for it that the more loosely-connected Firefox doesn't. Except, of course, for facilitating the spread of malware.
Java has enough OS-neutral infrastructure behind it that Sun probably couldn't wrench it into a Solaris-only architecture if they tried. I'm less sanguine about .Net.
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.
Here's one that covers ADO.NET and parts of ASP.NET:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6920461.PN.&OS=PN/6920461%3Cbr%20/%3E&RS=PN/6920461
Is that good enough for you? Because there are more. Lots more. Search the US Patent Office site for them.
Basically, Microsoft could enforce its patents to make Mono drop support for ADO.NET, ASP.NET and WinForms. Sure, they aren't part of the CLR, but Mono would be useless without them (especially in the eyes of Windows developers who the Mono team thought would flock to Linux if it had .NET support). It would basically kill Mono (although it seems pretty much dead now anyhow).
There are some pretty significant differences between the two technologies actually. While there are analogous tool types available for both, the implementations of each are quite different. Certainly enough for a difference to be noticed. Just in terms of windowing toolkits, WPF and WinForms are quite different from Swing and SWT. Microsoft's control of the CLR has upsides and downsides. It does allow them to very quickly add new features to the framework. However, this tight control leads to complications with alternative compatible runtimes. Java has the JCP, which is also has it's benefits and drawbacks. While open and transparent, changes are made quite slowly. However, this openness, coupled with now being open source, allows for viable alternative runtimes with no concern over patent infringement. I'm not quite sure what there is to fail to understand or be annoyed by. Computing is a finite thing. Therefore, there is simply no "best" solution to all problems. Compromises must always be made and they are going to serve one end to the detriment of another.
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.
Clone with a beard... Let's see...
Things C# does that Java has no concept of:
Delegates, multi-cast language support for events, closures/lambdas, generic constraints, scoped resource usage (using), partial methods/classes, LINQ queries, extension methods, expression trees, operator overloading, custom compilation attributes attached to fields, classes and methods, first class value types/structs, out/ref support and many more.
Java is to C# as the Special Olympics are to the real thing.
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
Really?
http://www.indeed.com/jobtrends?q=linux+.NET%2C+silverlight%2C+ruby&l=
This search is moot, the querry ignores the '.', you just searched for Linux network-related jobs.
Comment removed based on user account deletion
One word: cython.
Actually, I'm inclined to agree that WebApps generally suck when compared to a Windows App performing the same task.
Faulty logic, because I could say that Windows Apps generally suck when compared to an OS/2 App performing the same task. This is true in my experience, but has absolutely no bearing on the current state of computer applications.
You qualify this with
when the situation doesn't make it necessary to create a product as a WebApp, I think it's generally stupid to do so.
and later state
I can't understand why you would run software on something other than its native platform.
Both of these statements ignore the constantly changing face of the personal computer marketplace (which is rapidly including more and more portable platforms). Companies who use multi-platform technologies are better configured for the long term. OTOH, the newer multi-platform technologies can hurt in the short term due to the performance issues you've described.
They have a niche. The idea that all applications should be web apps is stupid. The idea that all applications should be locally installed is stupid. Once people can accept that and define the things that web apps are and are not good at, maybe we can get some really well built apps that leverage the abilities of the platform.
I'll throw out my anecdote, because, as always, my anecdote is better than your anecdote.
I've since moved on, but I worked for a company in the financial sector that needed to input customer information for lease applications. Previously this was handled by a (admittedly kludgy) thick client application. It was replaced by a web app, which, while probably a little slower gave several advantages. 1) It was consistent between several groups. Sales people could access it in-house and remotely and have the same interface, and it was generally pretty fast in both cases. 2) Third-party partners could now put their own information in because it was available remotely. 3) It was consistent internally and remotely, so that if partners had trouble or needed help all the staff was familiar with the same interface and could walk them through things.
It wasn't as fast as a locally installed terminal session for data input, but it was good enough, and the other benefits far outweighed this deficiency.
This is not true.
The majority of .NET code is bizlogic stuff. It stays within its "box", using only framework APIs and such. Stuff that's well-documented and, important for this discussion, already implemented in Mono. You get a lot of "woah!"'s when you copy their bizlogic app onto a flash drive, plug it into a Linux machine, and run it without even a recompile. Of course, there's no perfectly write-once, run-anywhere architecture, and sometimes you will encounter oddities from OS to OS in applications (though, like Java, bizlogic stuff tends to work right out of the box without trouble--it's when you get into more complex stuff that there can sometimes be issues). But these quirks exist everywhere, and rarely are they so significant that the applications don't run straight off the top. Now, the problem with cross-platform capabilities with Mono (at least before the Foundation frameworks like WPF and WCF, which very few people actually use because they're overengineered crap) is native code libraries. People find something they want to snarf up into a managed code app, so they do it. But if you've got builds of that library on multiple platforms they can be ported and packed with the executable to intelligently pick the native code library based on which OS it's being run on (picking libfoo.dll on Windows, libfoo.so on Linux, libfoo.dylib on OS X).
Regarding "might work on Windows"--Mono has a build for Windows. It works fine. Some small theming issues, but it works. System.Windows.Forms is supported on Windows, OS X, and Linux, although I personally am looking into the Qyoto QT libraries for easier use (because WinForms, though easy, has problems).
Mono already works on "Mac's various phone platforms". (It runs very well on OS X; right now I'm testing an app for use on OS X 10.5.) It runs on the iPhone, too, thanks to their newish static compilation stuff.
So...sorry, but no. It works and it works fine. Nice work on the Insightful mods though. I suggest actually reading what you're talking about if you want to actually be insightful, though. :-)
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."