Slashdot Mirror
Reasons To Use Mono For Linux Development
Nerval's Lobster writes: In the eleven years since Mono first appeared, the Linux community has regarded it with suspicion. Because Mono is basically a free, open-source implementation of Microsoft's .NET framework, some developers feared that Microsoft would eventually launch a patent war that could harm many in the open-source community. But there are some good reasons for using Mono, developer David Bolton argues in a new blog posting. Chief among them is MonoDevelop, which he claims is an excellent IDE; it's cross-platform abilities; and its utility as a game-development platform. That might not ease everybody's concerns (and some people really don't like how Xamarin has basically commercialized Mono as an iOS/Android development platform), but it's maybe enough for some people to take another look at the platform.
I work on a embedded Linux system running Debian Jessie armhf on a Cortex-A5 processor. At some point someone programmed a Web user interface for the system using Mono for Linux. The installation of Mono was difficult, requiring several hundred Mo of space on the filesystem and some trick to get the last package revision. Then the application was started and take all the processing load for almost 4 minutes. At his point it was eating near half the memory available on that embedded system. This was socking, especially for me that like to use qooxdoo for WebUI because it's basically a static file that need no compilation and have a very minimal memory footprint. Finally the guy switched to node.js for the WebUI on that system. The installation was easy, the startup compilation last now less than a single minute and the memory footprint is below 20%, all of that with a more complete demo that with Mono.
There are patent issues with every technology.
there are no patents on C++ and even if there were they would have expired by now.
Anons need not reply. Questions end with a question mark.
Microsoft has always been fairly smart about courting developers with excellent tools and development platforms, and making it quite easy to build applications for Windows
Maybe you don't remember history the way I do.
Remember VB? An excellent toolkit that gained widespread acceptance in the Enterprise world for it's tight IDE, integration environment and easy forms. But then MS came out with VB.net which was about as related to VB 6 as javascript is to java. It was a horrible mess, everything had to be re-written to be compatible because it was really an entirely new language. Developers were left in the lurch, oh well, perhaps you shouldn'ta Microsoft, you know?
Remember Silverlight? The "Flash Killer", it was an excellent toolkit for writing distributed applications quickly. Performance was excellent. Many big names "bet the farm" on it. Until Microsoft walked away from it, too. Netflix will *never again* bank on a MS technology, I'm sure.
But that's not where it ends. Remember Windows Phone 7? The next big thing (tm) and they ditched it, for WP8, and all the devs were screwed. Again.
But that's not where it ends. Why is the XBox 360 not compatible with the original XBox? Why is the XBox "One" not compatible with the XBox 360? With every console generation, MS has been screwing the developers.
And so it goes. Over and over, the devs get the shaft any time they bet on Microsoft's newest, highly promoted technology.
What's next?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
If you mean can you write graphical Linux programs the run on x11 out Wayland, the answer is yes absolutely. Gtk and Gnome bindings were some of the earliest tools for mono. In fact monodevelop is a gtk app, written in c#. Gtk turns out to be a pretty good fit for c#
Remember Silverlight? The "Flash Killer", it was an excellent toolkit for writing distributed applications quickly. Performance was excellent. Many big names "bet the farm" on it. Until Microsoft walked away from it, too.
In favor of HTML5. Its funny how the tables turn as soon as Microsoft does something, now pushing open standards in favor of proprietary blobs is a bad thing. They pushed Silverlight until HTML5 was capable then stopped supporting it and released it as open source.
Remember Windows Phone 7? The next big thing (tm) and they ditched it, for WP8, and all the devs were screwed. Again.
Please explain why you believe "devs were screwed", here is the experience documented by an actual dev.
Why is the XBox 360 not compatible with the original XBox?
Because the 360 has a completely different architecture to the original. This is not something new in the console world, developers want to write games specifically tailored to the hardware using architecture-specific strategies. The hardware improvement between the consoles was not enough to fully emulate the original XBox hardware in software on the new console.
Why is the XBox "One" not compatible with the XBox 360?
For the same reasons as above, however they have manage to get enough performance out of an emulation layer of sorts to be able to do backwards compatibility, it just requires the permission of the developer for distribution reasons. This is made easier since much of the games of today rely on GPU programming and while the GPU architecture is improved in the more recent console it has an AMD chip that shares many of the underlying subtleties with the AMD GPU used in its predecessor.
With every console generation, MS has been screwing the developers.
If you write software that depends on specific hardware obviously you can't expect that software to work when the hardware is different...duh!
"Chief among them is MonoDevelop, which he claims is an excellent IDE; " ... which made my jaw drop.
Monodevelop is a fucking awful, AWFUL piece of software. Bloated, slow, and broken hundreds of ways.
How about "C# has pointers" or "C# has unsigned types" or "C# has direct native code interoperability through function imports and exports" or "C# has proper reified generics" or "C# has allocated-on-the-stack value types" or "C# has a properly unified type system which means that you don't have to go out of your way to make an int behave like an Object or an array behave like a collection" or "C# has generator coroutines" or "C# has asynchronous coroutines" or "C# has deferred query comprehension" or "C# has transparent expression tree generation allowing for custom interpretation/execution of C# code on heterogeneous data sources" or "C# has dynamic dispatch".
And you know what? We don't use any of that stuff, because we want our code to be COMPREHENSIBLE. Lambdas don't do anything for me that I can't do with a loop, and at least I can see instantly "Yep, that's a loop!" For the very few cases where it might be helpful, that's great, but its really VERY few cases. I have yet to write one.
Yeah, yeah. We've heard this before. Back in the day, people were saying the same things about those new-fangled "for" and "while" loops. After all, we want our code to be comprehensible! A loop doesn't do anything for me that I can't do with a goto, and at least I can see instantly, "yep, that's a control flow transfer!".
Meanwhile, people have embraced the new tools (which are the majority outside of the Java land - even the C++ guys have and use lambdas now), and they became idiomatic, and standard libraries were upgraded to rely on them - making them both more powerful and easier to read. As it happens, I use both C# and C++, and it's a rare day at work that I don't use a lambda anywhere. Looking at other people's [quality] code, it's mostly similar. And guess what? It's all still perfectly readable, so long as you take some time and learn how it works. In most cases, in fact, it's more readable than the code that it replaced, and more maintainable to boot (because DRY).
Java's generics are fine. They do the most important part of being generics perfectly well. Again, the things that you seem to want of them are things that negatively impact maintainability in most cases.
I was referring mostly to type erasure, obviously. How does getting read of that negatively impact maintainability?
In the meantime, Java now has this beauty. Because they can't just say Func<T>, and have it work well for primitive types.
As for DRY... I'm at a loss why anyone would think that you'd repeat yourself in Java.
If you don't have first-class functions in a language, you'll be doing a lot of of DRY for that reason alone (yes, you can use anon classes instead, but no-one actually does because it's so verbose it defeats the point). If I have to explain how and why that works, then you should probably go read some FP tutorial.
I think MS certainly looked carefully at Java and in some very minor ways improved on the syntax, but at worst the difference is small,
You think wrong, and you didn't bother to investigate enough to make such a conclusion. This was kinda sorta true 14 years ago. It's not true now. Things that C# has that Java does not include e.g. dynamic and async/await, neither of which are "very minor ways".
with Java's vast arrays of libraries, frameworks, and tools, its hard to beat.
It's kinda like the iOS app store. Sure, it has 3 million apps, but in practice you need maybe 30 for any particular case, and 300 across everything. I won't dispute that Java has more libraries, but pretty much any mainstream language/platform these days, including .NET, has all the libraries that matter, for the simple reason that all of them have a fairly large community that will write or wrap one if they need it. I don't recall ever running into a situation where I couldn't find a library to do something that I needed to do, in any popular language.