Open source Mono framework brings C# to iPhone and Wii
arstechnica.com
arstechnica.com
That said, I wouldn't do this on a commercial project. Because when a bug does come up you just have too many layers to contend with. Is it a bug in my code, in the Unity Framework, in Mono, in the device or what? This is a particularly significant problem when dealing with Open Source projects with very little in the area of support mechanisms and Apple which seems to think far too much of itself to offer decent developer support.
So in the end it's a nifty proof of concept but I personally couldn't bring myself to trust it.
EDIT: Although, if you are writing a commercial, big budget game, our game development support staff is incredible. So if you want that, then yeah, you'd have to use one of our official products. My comment was about if you didn't intend to go that big publisher route. I was talking mostly about small ISVs.
Bottom Line: Our contract with them cost us $2500 and no matter what the problem has been (be it code, OS, whatever) they've fixed it.
When we looked at Mono we found only one viable service vendor and that was Novell. Their contract was prohibitively expensive (I think it was like $11,000) and their support stopped at Mono. Meaning to use this solution you'd have to have their support, plus a linux vendor support contract, plus Unity support, etc ...
It took a few days working the support, and I did get on a conference call with some brilliant people, and they figured it out quickly - using a (forget its name) debugger that talks directly to the CRL (which the one in Visual Studio apparently doesn't).
All this because (I think) something somewhere in that stack decided to "protect" me from the cause of the error.
This is generally my problem with Microsoft. No so much the arbitrary discussion of whether or not it sucks, but the difficulty of getting under its helmet, which tends to make problems much bigger than they ought to be.
Mono garbage collection isn't perfect, on mobile devices this could be fatal. It sounds like the Mono boys are trying to find some fame.
C# 1 is Java minus the Java suck
C# 2 is C# 1 minus much of the C# 1 suck
C# 3 is C# 2 plus a ton of totally cool functional language stuff
C# 4 (not yet released) will have some cool dynamic language stuff
I think codeplex is the right direction, but MS needs to give open source for C# stronger support (instead of ignoring stuff like nUnit).
Another criticism, compared to other languages, is the cruft attached to C#. Like Java, C# is a 'you kinda need to use a heavy IDE to make life easier' language.
As for the IDE dependency complaint, I think this applies more towards some of the standard libraries such as WPF, WinForms, ASPX, ADO.net, etc. I think it is a very valid complaint, but I don't think it is about the language itself.
1) it's always behind the current version of C#
2) even for past versions it still doesn't fully support C#
I'm not sure about this one, but to use mono commercially don't you need to get a paid license for SUSE?
I think most of the fame for actually pulling this off for Mono/.NET needs to go to the Unity engineers and not so much to the Mono gang. Although this is speculation on my part.
At first Obj-C's future at Apple seemed far from certain. First there was a proposal to make the syntax more like C++, and later there was a strong push to switch to Java as the main language for the Cocoa API. Next's flagship product WebObjects (a Cocoa-based Web app server and framework) was rewritten in Java by the year 2000. Mac OS X still hadn't shipped, but Obj-C was not getting a place in the limelight as most of the new APIs were plain C (CoreFoundation, CoreAudio, new Carbon) to accomodate both old Mac developers and cross-platform developers.
Apple's Obj-C faith was gradually restored during this decade. The touted Cocoa-Java bridge did work, but there was a fairly fundamental "impedance mismatch" between Cocoa's API design and Java's static nature. Cocoa-Java was deprecated in Mac OS X 10.4, leaving Obj-C as the only native development language for Cocoa.
Carbon on the other hand kept growing up to 10.5, and it gained a lot of features that were effectively plain-C wrapped C++ implementations of Cocoa features (HIViews, NIB support). Clearly the notion of having to maintain these parallel APIs for GUI development didn't please decision makers at Apple, as 64-bit Carbon was pulled at the last minute from OS X 10.5, thus leaving Obj-C and Cocoa as the only game in Mac town for 64-bit GUI applications (which of course sent a clear signal that building new applications on Carbon isn't a good idea regardless of whether you need 64-bit support right now).
So why did Obj-C win? At least one thing that makes it a good fit for publishing OS-level APIs is that it's inherently late-bound and duck-typed. A Cocoa program can thus easily make use of new API features without having to explicitly link against the new version of the framework. (This is particularly important because Apple doesn't update their frameworks separately from the OS, unlike Microsoft with .NET.)
For example, if Mac OS X 10.3 added a -foo:bar: method to NSWindow, an application could easily check for the availability of this particular method while still maintaining compatibility with older operating systems, like this:
if ([window respondsToSelector:@selector(foo:bar:)]) { // do fancy 10.3 specific effects here }
If you want to have fun driving a Ferrari, you better learn driving stick ;)
I think I'm just a high level programmer and I get bored/discouraged really fast if it takes too much work to make something happen on the screen/phone.
(Obviously C# really isn't that much better, but I was thinking .net on iPhone might lead to ironPython?)
I'm using the bookmarklet if that's any help.