
Open source Mono framework brings C# to iPhone and Wii - jawngee
http://arstechnica.com/news.ars/post/20090108-open-source-mono-framework-brings-c-to-iphone-and-wii.html
======
TomOfTTB
As someone whose work life involves a lot of C# development I can honestly say
it's a great little language that would get used much more if it's name wasn't
tied to Microsoft. Beyond that there's no doubt the Mono project has done some
impressive things.

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.

~~~
snprbob86
As someone whose work life involves a lot of development of C# development
tools, I can honestly say that these concerns apply to our team at Microsoft
just as much as they apply to Mono. The only difference is that when someone
asks us a question about some bugs or our direction or policies, we have to
ignore it to appease the lawyers. This is a risk you run if you write any
software at all, no matter the vendor.

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.

~~~
TomOfTTB
"bug" or, if you prefer, there are "bugs" and there are "quirks". I can't say
that I've ever found a full on bug in the .net framework but I have
encountered several quirks that had us baffled but which were solved in 5
minutes with a quick call to Microsoft.

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

~~~
mseebach
I ran into a problem at a previous job with the catch-code in the "global" try
block in an ASP.Net app, itself throwing an exception. IIS just dies with a
8-digit hex code that according to MSDN means pretty much whatever ("try some
or all of these 15 different possible solutions").

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.

~~~
mseebach
And yes, I DO know it's incredibly bad design to put so much code in a global
catch-block that it can fail.

------
peregrine
I work with C# at my work and it is actually a very nice language. If you
haven't checked it out, you probably should. For obvious reasons it hasn't
reached the hip crowd yet, but if you play with it you will see some very
positive things.

~~~
zvikara
C#: Write once, run anywhere.

~~~
chaostheory
In my experience Mono blows for C#, though it could be good for other things.

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?

------
voidpointer
With GCJ, the same should be possible for languages based on the Java VM too
(including Java). Consequently you would be able to get Clojure, Scala, Groovy
or Jython on the iPhone too.

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.

------
tocomment
Please save me from Objective C .... I hope this article isn't just a tease.

~~~
streblo
As someone who has done a minimal amount of Objective-C programming in the
past, I have to agree. That being said, I've also heard a lot of hackers rave
about it. I'm confused over why there's such a love/hate relationship with
this language. Whats the story with Apple's dev environment being so Obj-C
heavy? What's the chance they'll spring for it's replacement?

~~~
pavlov
Apple inherited Obj-C in late 1996 when they decided on NextStep as the
replacement for the aging Mac OS. (That purchase also brought in Steve Jobs as
an "adviser" to CEO Gil Amelio... Six months later, Amelio and the executives
that had made the Next decision were out and Jobs was running the show.)

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 }

------
anuraggoel
HN's duplicate detection not working?

<http://news.ycombinator.com/item?id=427531>

~~~
parenthesis
That is odd: the urls seems to be exactly the same. And when I tried to submit
it again, (just now, as a test,) I was taken to your original submission, not
this one.

~~~
anuraggoel
It would be interesting to look at the exact URL that the OP posted - maybe it
was sanitized after the duplicate check?

