“C#, it’s just not portable”
fastchicken.co.nz
fastchicken.co.nz
I have nothing against the language (writing C# is half of my day job), but all of these bridges are second-class citizens and built and maintained at the mercy of third parties just to interface with your target platform. Apple will never release updates for MonoMac or MonoTouch. Google isn't going to release C# Android SDKs or documentation. Mono for Linux always trails the Windows version and has significant community resistance, and Microsoft isn't going to integrate and maintain these bridges.
You're also always losing something in the translation too, be it idiomatic style of the target API or C#, or being totally cut off from new native features, or severely restricting what community support or documentation is available to you. Any way you cut it, it's a second class experience. Worse, some of the bridges aren't free. You get to pay $400 for the privilege of not learning a little bit of Java or ObjC to get MonoTouch for Android or iOS.
C# is good, but it's not so good that I refuse to learn other tools.
Oddly enough it seems like C++ is the only language all three platforms support natively.
Does keeping C# as a constant really solve this problem? (I honestly don't know, I've never done a multiplatform product like this)
I've deployed ASP.NET MVC apps on Linux / Mono and it was a relatively painless experience. The desktop and RIA guys in .NET land are doing their own thing with WPF and Silverlight (google MVVM / Caliburn-Micro), and frankly, it's freaking me out a bit. There's a tendency to overengineer and abstract everything. It might not be as bad as with Java but the tendency is still there.
For instance, the .NET community has been arguing for years about domain driven design and how you should abstract away (or not!) database access. Hundreds of blog posts about which application layer should be concerned with this and that, about generic data access repositories, enhanced query objects and so on. What was "the way to go" one day was suddenly "the new singleton". Some guys eventually came up with the glorious "CQRS" approach (inspired by Betrand Meyer's command query separation) and built entire frameworks such as NCQRS with separate read/write stores, event sourcing and audit trails. The problem is that a lot of people start to use these enterprise models in very simple applications.
I'd also say that the 3 mentioned languages are, in their current incarnations, very different from each other. Java itself looks rather stagnant to me? I don't know, the last time I checked I saw former high school / college friend of mine starting a serious open source effort for easier database querying because he was so fed up with hibernate - it's basically one gigantic DSL / fluent interface that generates sql. Me: "Why don't you use lambda expressions.. oh wait, ...".
Is C# the right language to do that in, maybe, maybe not but it is an option.
With a properly architected solution (and I like to think mine comes close) with sufficient abstraction, I literally can write a game once--with allowances for fundamental platform differences, i.e. "is this a touch device? then show on-screen controls, but wire them to the same backend logic"--and deploy it everywhere. I can't do that with a Java engine on Android and an Obj-C (ugh) engine on iOS, because there is no reasonable lingua franca. C#, on the other hand, works fairly well everywhere. The platform-specific bits are small, clearly delineated, and shouldn't take long to do (it's Windows-only for now).
I'd take re-coding my UI layer over having to write near-identical code for XNA and OpenGL, then writing near-identical code for OpenAL, XNA, and Core Audio, then writing widely divergent input code for XNA and whatever not-well-standardized gamepad layers I can repurpose or build for Linux and OS X and the different touch frameworks...
Having to write all of this stuff is arguably on par, if not more complex and difficult, than reimplementing a UI layer. It's not a "luxury" at all.
Indeed. But it's also quite harder than those to develop in.
I hate to keep on button-mashing, but it would be a big win to have a PlusPlusScript language - as in same philosophy and approach as CoffeeScript, but targeting C++ [1].
Looks are deceptive.
Many people also tend to prefer the language they're strongest in when they need to get things done, especially when they don't know the other languages and frameworks that well.
In my case, I'm a Windows / C# guy at work, at home my laptop is running ArchLinux and I use it to code in a variety of languages. This didn't prevent me from trying to set up a mono / asp.net mvc app with nginx and postgresql on it :)
I work with C# 90% of the time. I also happen to use other languages fluently. I think is a matter of choice.(I also have to admit that there are some developers that just don't want to get out of the comfort zone, but I don't think ALL C3 developers should be judged this way).
For example, I have used Xamarin products for a some projects, and it makes a lot more sense for me, to use C# with Xamarin products than Objective-C. That is a language I have been avoiding for a long time. And the reasons are not the scope of this comment. On the Android side I am definitely using Java.
So cutting to the chase, I think that for a company to support C# without Microsoft involvement is not bad, and it doesn't mean that ALL developers are lazy or mediocre, it just means more choices for developers. Specially if you have big investments in Software developed on C# (either .Net or Mono).
To me it's too heavy. About 10Mb too heavy.
Apple and Android don't ship a "standard" Mono runtime, so you end up having to ship one with your app.
The sweet spot for me is to use Lua: I can build it anywhere that you can build C, and it's TINY. If I want speed I use C++; for the rest I script in a really forgiving multi-paradigm language.
People don't make games in C# because it's C#. They make games using C# and XNA, or Unity, or some other framework. They don't make web apps in C#, but rather in (whatever flavor of) ASP.NET. And it turns out that these frameworks are the important bits.
So when you choose to write something in C#, you are probably going to be choosing a framework that ties you down to a platform, and that's where the cross-platform nature of the language kind of becomes irrelevant.
That's my experience, at least.
If Clojure takes off on other runtimes, it will have this issue too. The JVM is it's "home" platform, and most Clojure software depends on JVM libraries, like how the vast majority of the C# software written thus far depends on Microsoft (and therefore Windows) libraries.
There is a small difference.
The Clojure/JVM runtime is ported to quite a lot of operating systems, where it runs quite well.
First of all, a lot of the C# APIs are written with windows in mind. An example is system mutexes. These just don't exist on Linux, and the mono implementation to emulate them is very buggy. Another example is the process counter API. Although much of this same information is available on Linux via the Proc table, Mono provides no equivalent API because it would be a lot of work to make one that works on all the Unix variants. There are many such examples of C#'s windows-centric API not being ported well in Mono.
A bigger problem with Mono is that it just wasn't stable for us. The more standard library features we used, the more it would core dump on Linux even though it would never crash on windows. We ended up re-implementing a lot of functionality available in the standard library ourselves before the program stabilized on mono, which further incriminates the Mono stack. As a final note, we tried multiple versions of Mono, including 2.4, 2.6, and 2.10, and none of them worked well for us.
If you want to write a fairly performant cross-platform app, the JVM is still a much better place to play in right now than .Net, even though I like C# the language a lot more than I do Java. You can also go the route of combining your favorite scripting language with C for the CPU-intensive parts.
But writing in C does not make a program portable. Neither does writing it in C#.
So yes, C# compiler might be portable, but programs written in C# are not.
So yes, C# compiler might be portable, but C# programs are not.
I would only use C# for window jobs, although I sincerely think it's a beautiful language.
If so, is it stable, fast?
I wonder how it compares speed and stability wise to the Java Play Framework.
I am currently using Play (and it's great!) but I much prefer C# as a language to Java ...
Supporting C# as the programming language, PS Suite SDK can run programs developed in C# on virtual machine equipped on both PS Certified devices and PS Vita. By supporting development for multiple devices and by adopting libraries to create a variety of content not only limited to games, PS Suite SDK will not only help developers save their cost in creating new content but also allow them to efficiently create their content on one SDK and without having to create on several different SDKs.
Through PS Suite SDK, SCE will provide to game developers and publishers the potential to further expand their business opportunities to Android based portable devices.
http://www.prnewswire.com/news-releases/sony-computer-entert...
Also the savings on the electricity bill are not negligeable either.
I sure hope you don't have a server failure outside of business hours :-)