Open source Mono framework brings C# to iPhone and Wii(arstechnica.com)
arstechnica.com
Open source Mono framework brings C# to iPhone and Wii
http://arstechnica.com/news.ars/post/20090108-open-source-mono-framework-brings-c-to-iphone-and-wii.html
26 comments
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.
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.
"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 ...
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 ...
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.
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.
And yes, I DO know it's incredibly bad design to put so much code in a global catch-block that it can fail.
Yeah, totally. This is why closed-source software isn't dead :-)
C# is my favourite language, its just right...
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.
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.
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.
To clarify: C# 2.0 and up is a very nice language. C# 3.0 is a totally bad ass cool language.
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
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 agree that the language is essentially a much better Java, but C# is missing Java's (and pretty much most other language's) community; namely the open source part. (Could be my inexperience - only been using it a little over a year but) I've found myself having to make wheels that should have already been built. this would have been fine in the pre-internet era, but nowadays it's just a bit annoying, and no I still don't feel like paying for closed source libs
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.
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.
Most open source C/C++, Java, Python, Ruby, OCaml, and other libraries can be compiled against MSIL and called natively from C# or consumed as binaries and invoked via common C calling conventions.
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.
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.
C#: Write once, run anywhere.
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?
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?
really?
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.
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.
Please save me from Objective C .... I hope this article isn't just a tease.
Objective C is a really interesting language and the Cocoa and UIKit frameworks are designed in a way that makes great use of the features of the language. Is there something like KVO (key-value-observing) available in .NET with the newer versions?
If you want to have fun driving a Ferrari, you better learn driving stick ;)
If you want to have fun driving a Ferrari, you better learn driving stick ;)
Coming from Python, any extra verbosity really drives me crazy. Declaring variables, and having to write the same thing in the header and implementation files hurts me. I could probably live with that though, I guess it's the memory management for iPhone development that really bothers me.
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 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?)
My previous dablings into mobile app development were first with the old Palm OS (plain old C) and a bit of J2ME (oh the horror). Compared to that UIKit is bliss.
I understand the python runtime is pretty compact. Thus I'd expect there to emerge solutions similar to what is currently done with C# code. Just wrapping the runtime in the app and having the code as resouces in the app bundle that get fed into the runtime when the application launches.
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?
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 }
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 }
objective-c has a particular set of strengths that is well-suited to gui development. if you count its beginnings at next, it has been in use in this environment for over 20 years. there is no way in hell apple would abandon it now.
HN's duplicate detection not working?
http://news.ycombinator.com/item?id=427531
http://news.ycombinator.com/item?id=427531
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.
It would be interesting to look at the exact URL that the OP posted - maybe it was sanitized after the duplicate check?
This is my second submission that is apparently a dupe. Many apologies.
I'm using the bookmarklet if that's any help.
I'm using the bookmarklet if that's any help.
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.