Monday, September 14, 2009

iPhone Dot Net

Here's another interesting project, which allows programming iPhone applications in C# using Mono. It's based on the open source Mono project, but is a commercial product.

I have such mixed feelings about projects like this one. On one hand, I have tremendous admiration and respect for the ingenuity and hard work that went into making this work. Yes, it definitely does lower one barrier to entry for a considerable number of people with solid .NET experience, but that's not necessarily a good thing.

Tools like this encourage people to become hammer developers, that is to say, developers who use and are comfortable with only one language and framework. I have a very strong belief that being a hammer developer is, to put it bluntly, bad. I'm a strong believer in the importance of cross-training. I think it's important to see multiple approaches to problems. To become a great programmer, you need to be exposed to the work of a lot of different great (and not-so-great) programmers, and not just ones working in a the same language and toolset as you. Good developers have both breadth and depth of knowledge to draw upon when solving problems.

Although C# has some similarities to Objective-C, C# derives from the Simula object model, like C++ and Java, meaning it's strongly typed and does a lot more at compile time than Objective-C. There's nothing wrong with strongly-typed, static languages, but in many cases, the Simula and Smalltalk models really do require the use of different design patterns to be used most effectively. These differences are not insurmountable; Apple, for example, ported WebObjects from Objective-C to Java several years back. But, there were definitely bumps in the road; some parts of WebObjects 5.0 were necessarily klugey to work around the fundamental difference in the two languages.

Now, before people jump on me, let me just readily admit that I'm biased here. I really like Objective-C and I do think it's the absolute best option for programming on the iPhone. I also fully realize that Objective-C seems like a weird beast when you first come to it, especially after spending a lot of time with languages like C++ and C#.

But I do honestly think that one mark of a good developer is choosing the right tool for the job even (or maybe especially) when it's not a tool you are comfortable with. Learning is good, people. Learning is good. Don't ever say you're too busy to learn a new language or framework. Learning is an investment in your future viability and employability. You can't afford to stop.

Now, obviously, there's more than one opinion on this. The developer of MonoTouch, Novell, has a very different take on it. They believe that C# is so much more efficient than Objective-C that they're kindly willing to sell you a $1,000 toolkit. You'll still need to be a member of the iPhone Dev program, and you'll also still need a Mac for development. So, while this may lower the knowledge barrier for .NET developers to create iPhone programs, it certainly doesn't lower the financial ones any.



24 comments:

FlyingDiver said...

I don't really object to the concept of providing an alternative language/toolkit to programmers, but statements like this really annoy me:

"What's important here is that C# and .Net are considerably more productive development environments than the native iPhone language, which is Objective-C," said Miguel de Icaza, vice president of the developer platform at Novell and the leader of the Mono project.

joe

Timos said...

I think it makes more sense to use the free Xcode that comes with your mac and spend the $400-$1K on getting a couple of good books on Objective C. Novel will always be playing catchup with Apple to make use of the newest edition of the iPhone SDK.

Zenroth said...

I can see this, a lot of developers really dislike Objective C. Thankfully most of us that fall into that camp are doing game development, and just use handful of copy/paste objective C and do everything else in C/C++.

Having said that though, I can't really seeing doing game development in C# on the Iphone.

Having worked with C# on the Xbox 360 the lack of memory control and garbage collection leads to a lot of difficulties. I imagine this would be even worse given the small amount of memory available on the Iphone.

Jeff LaMarche said...

Zenroth:

In my experience, a lot of people who dislike Objective-C haven't spent a lot of time with it. A lot of people take an initial dislike to it because it is so different, but a great many come around after working with it for a while.

FlyingDiver:

Yeah, but that's coming from someone who's trying to sell something. Vice president of developer platforms at Novell? I mean, it's not like that's a division that's been raking in a lot of money for Novell of late.

Timos:

I agree. For $1,000, you could buy every iPhone and Objective-C book on the market and have plenty left over.

But, I'm biased on that account, since I'm an author of books on iPhone development :)

MattBD said...

I would be very surprised if MonoTouch only supports C#. The Mono project as a whole supports loads of languages, including IronPython, Boo, Nemerle, VB.NET and Java, and the MonoTouch FAQ just says that it supports .NET programming languages, which is pretty vague, but implies that it supports more than one.
One thing that attracts me to it is the fact that it supports MonoDevelop. I'm a diehard Vim fan and I can't find too many IDEs that support vi key bindings - MonoDevelop has these and great autocompletion in one package.

Jeff LaMarche said...

MattDB:

My argument doesn't change with any of those languages.

You know you can use vim as an external editor for Xcode, right?

MattBD said...

Fair point about the issue of what language to use, but it does lower the bar somewhat as it allows people to go straight in with their favourite language rather than having to learn a new one.

Also, MonoTouch together with IronPython or IronRuby open up the possibility of iPhone development to those whose only experience is with scripting languages such as Python or Ruby, and these are languages which are already popular in the Mac development community, so I could see these going down well. Whether possibly being able to develop iPhone apps using VB.NET is a good thing is debatable though...

I do know about using Vim as an external editor for XCode, but you do sacrifice the IDE's autocompletion. Personally I'd prefer it if every IDE supported vi keybindings, but MonoDevelop seems to make a good job of integrating autocompletion with vi.

Malcolm Hall said...

Here is what I thought of this news today:

C# the language including all its bells and whistles like anonymous methods is better than Obj C.
Cocoa Touch and Apple's amazing navigation controller beats Windows Forms.
The cross platform benefits of .NET CLR beat natively compiled Obj C. BUT on the iPhone there is no CLR, what they have done is compile to .NET to native in this release, negating this huge benefit.

So thats my pros and cons list, but overall I prefer Obj C, Cocoa and the iPhone over .NET and WM simply because an app that takes me 2 weeks on WM takes 1 day with XCode and the iPhone. This takes into account the poor Windows Forms, the excruciatingly slow Visual Studio, Windows being a terrible OS - all those things add up the burden on the poor Windows developer.

When developing on a Mac and XCode it can actually keep up with the speed I think at which is something truly amazing. Never had that with windows dev.

Matt said...

I understand your comments about 'hammer' programmers but language arguments aside i would imagine that this is likely to appeal to folk developing enterprise iPhone apps in their organisation.
The chances are in those kinds of apps that there will already be libraries of code available in .NET that isn't linked to the UI in any way and if that is the case you have to question the sense in rewriting and maintaining that code in C or Obj-C. Maintaining code really sucks so unless the iPhone and Mac is absolutely central to your business the time required to understand and write good Obj-C code just might not be worth it.

I also agree that initially Obj-C is weird but grows on you. I'm still not sure i like the usage of square brackets but i really do like the naming system that allows you to write lines that read very much like english.

Malcolm Hall said:
The cross platform benefits of .NET CLR beat natively compiled Obj C. BUT on the iPhone there is no CLR, what they have done is compile to .NET to native in this release, negating this huge benefit."

Not sure i agree with this statement. What would be missing by pre-compiling from the MSIL bytecode to native ARM code? When .NET is installed on a Windows machine the core framework is pre-compiled to remove the need to JIT compile and improve app startup performance and memory usage - essentially the same thing that mono on iPhone is doing.

Matt

Jeff LaMarche said...

Matt BD:

I readily admit that it does lower the barriers to entry, my point was that I don't think it's necessarily a good thing to do that. There are certain things you can't avoid learning to be a good iPhone developer, and some of those things get obscured by avoiding Objective-C because the nature of the Objective-C language factors heavily into the design decisions for Cocoa Touch. The world doesn't really need any more bad iPhone apps :) I don't have much sympathy for the "don't have time" argument. Would you let an incompetent doctor operate on you because he didn't have time to get finish school or take the board exams?

If you intend to inflict iPhone applications on the world, you should be willing to put some time into acquiring at least a certain level of competency.

I sympathize with you on Xcode and vim bindings. Since I prefer emacs key bindings, life is good for me. Apple has provided binding sets to emulate several popular environments, but no vim. You should be able to use a combination of text key bindings and menu key bindings to get something close to what you're used to, I would think. (though I, admittedly, am not familiar with vim bindings so can't say for sure).

You could also try the Vi Input Manager to get system-wide vi bindings: http://www.corsofamily.net/jcorso/vi/

Mmalcolm:

I can't necessarily agree with you about C# being "better". It's a good modern language that has had a lot of thought put into its development. Certainly, it's "better" for doing .Net development, which is was designed specifically for, but I'd be hard pressed to agree that it's "better" for doing development in a framework that was designed around another, very different language.

I just don't see how most of the "bells and whistles" would help with development in Objective-C. Anonymous methods, for example, offer very little benefit to a dynamic language like Objective-C (we can already do that with selectors), and to the extent that they offer any benefits, blocks are considerably better (yes, I know - currently third party libraries are needed for blocks, but that'll change now that Snow Leopard has shipped).

That's not to say C# doesn't have things that Objective-C might borrow. Languages cross-polinate. C#'s extension methods are almost certainly borrowed from Objective-C's categories, and Objective-C's properties very likely were influenced by C#s.

Matt:

What would be missing by pre-compiling from the MSIL bytecode to native ARM code? When .NET is installed on a Windows machine the core framework is pre-compiled to remove the need to JIT compile and improve app startup performance and memory usage - essentially the same thing that mono on iPhone is doing.

I'm not an expert on the CLR, so I can't answer the "what would be missing" question very thoroughly, but I can tell you that the CLR and Objective-C's runtime are very different beasts, and the iPhone does NOT do JIT compiling - it intentionally defers certain tasks to runtime to increase the language's dynamism. By compiling down to ARM bytecodes, it seems to me that a lot of the advantages of Cocoa Touch would be unavailable. Maybe not - I'm not sure how they've implemented MonoTouch - perhaps they use a bridge of some sort that allows the compiled code to interact with the Objective-C runtime, though I'd be curious to know what the overhead associated with MonoTouch is, and how they implemented "garbage collection" without the CLR.

MattBD said...

Thanks for the link about the VI input manager, I will check that out!

K. A. Barber said...

I'm late but, what is Novell's point here? I have been writing .net software professionally on and off for a while (C#, C++/CLI) and its all good at what it does. I just don't get paying someone for a shoehorned version of any of it when obj-c is native, easy to pick up and relatively free. Use your $1000 to buy "test assets" (IPhones,IPods,etc) if you already have an Apple computer and have paid the $100 to get going.

I can however see some larger corporate entities buying seat after seat of this thing thinking it will reduce the risk of entry into the IPhone app dev domain. This type of thing is very common in the corporate dev world (this or cleaning house and hiring developers specific for your new products).

Hilariously enough, I remember lots of small companies making money in the same manner as companies tried to figure out was to mitigate the risk of switching to .NET from MFC/VB.

Juan Miguel said...

You forgot to mention that the personal licence is only 399 dollars. This is not free, of course, but it is certainly affordable.

Jeff LaMarche said...

Juan Miguel:

The term "affordable" is subjective. Some people might consider it affordable. Since I don't think it's a good idea in the first place, it's hard for me to think of any price being a good value.

Besides, I didn't say it "wasn't affordable", I said it didn't "lower the financial barriers" since you still have to use a Mac, still have to join the iPhone SDK program, and then you have to pay an additional licensing fee on top of that. That's true whether it's $399, $999, or $3,999 (the three price tiers).

johnmci said...

It's good to see that this is an option, which follows on with the work I did at www.isqueak.org, except instead of C# it's Smalltalk. Which most people agree can be more productive for programming than #C.

We currently have six apps in the store leveraging Smalltalk as the model, one app WikiServer is a very complex Content Management System/Wiki.
http://www.wikiserver.com

Objective-C is still required for the View/Controller logic, but the solution allows the Smalltalk community to leverage existing code bases which have thousands of man years of effort put into them.

Peter Moberg said...

I am a C# developer by day and Objective-C by night and like both languages. I have spent more time with C# than Objective-C but I am starting to really like Objective-C and Cocoa....

Anyways... I also think that Novell has priced this one way to high. I guess Novell management wants the Mono group to start making some money (because the desktop version of Mono is for free). The fact that you are not able to debug your C# code either makes all of this a really hard pill to swallow I think..

stevegibsonNJ said...

In Jeff's quote:
"So, while this may lower the knowledge barrier for .NET developers to create iPhone programs, it certainly doesn't lower the financial ones any."

Corp america has a different take on this, the HUGE pharma company I am helping create iPhone apps for sent out an email with the MonoTouch press release attached stating, "This is great, we can use our off-shore resources to do our iPhone coding"

Why would they do this???? Because they can't get experienced iPhone developers for $29 - $45 an hour and their is sea of .net developer in India.

Roy said...

i think this is a great idea...get as many options for development on the system you can. it's pretty cool. on the other hand, the iphone/ipod touch is not exactly a desktop machine with all the processing horsepower that implies and frankly, .net and the such are pretty durned slow on anything running under about 1500MHz.

hofo said...

My guess is the same thing will happen in iPhone development that has happened in web development. In the beginning all web development was done with a text editor. Then IDEs and wizards became available, until we're at the point where you can use web pages to build web pages. But some people have realized that the level of output is different and have decided to learn how to write webpages with text editors instead of wizards so they can have greate control over the output.

I may be able to write a native iPhone app in Actionscript (a language I know much better than Objective-C) but I bet it will be much harder to get the intangible "iPhone-ness" of a good app with a non-native builder.

jty said...

I heavily program in both environments and here is my take on it. C# and the .NET framework is a truly modern approach to software development and the CLR opens all kinds of wholesome goodness even if that's not exactly what's happening in the end with iPhone. But either way you slice and dice it, it is not to assume just because you know C# and .NET that you can just sit down and start building iPhone applications. When I first messed around with MonoTouch one of the first things that crossed my mind was how useful my knowledge of Xcode, ObjC, and Cocoa were in knowing my way around or how to approach a problem. Both the CocoaTouch framworks and ObjC runtimes are wrapped into binaries in MonoTouch and knowing them is a must.

Do I think MonoTouch is the ultimate answer to everything iPhone? Nope. Am I glad to see it? Of course! Programming in C# is great and in of itself solves many problems. I like using it when I can but have no problem rolling up my sleeves and doing it in Xcode. Knowing both is a must in my opinion.

Now I just need to figure out how to get them to drop the damn price! :)

Graham said...

I think the position that lowering the barrier of entry on iPhone development is a bad comes from a position of arrogance. Where exposure to other methodologies and languages generally is not a bad thing (except when it is, and there are those cases where knowing too much enabled over-engineering), the assumption that it will be produce better applications is off base. Being a good programmer is only a part of having a good application, and not even necessarily an essential part.

A good concept that fulfills a need (from a business need, to the need for a diversion, and everything in between) is the core discriminator between good apps and crappy ones, and the implementation only needs to be “sufficient”. Lowering the barrier will allow a greater number of people attempt to prove they have that concept.

Personally I would rather see some Business Analyst who is a so-so programmer with a kick-ass idea have the tools to try and succeed, versus having only uber-programmers who spend so much time staying well abreast of technology that they don’t have time to experience that vastness of the rest of the world. Yes, this may be led to greater “less than perfect” applications, but dramatically increases the chances of truly great ones.

In other words…
Most of the time: Great idea + okay programming > okay idea + great programming. A wide set of tools for development is a bigger net to catch more ideas, leading to more great ideas.

Edwin said...

scrub m65 kamagra attorney lawyer body scrub field jacket lovegra marijuana attorney injury lawyer

JeansPilot said...

JeansPilot offers the chance to buy a large variety of men’s and women’s jeans clothing from the world famous Italian Brands.
Online jeans clothing store looks for original fashion clothing sales and clearances of worldwide known designers. We participate in fashion auctions to get the lowest possible price for Top quality Clothes, Shoes and Accessories.
Buy Jeans

h4ns said...

What youre saying is completely true. I know that everybody must say the same thing, but I just think that you put it in a way that everyone can understand. I also love the images you put in here. They fit so well with what youre trying to say. Im sure youll reach so many people with what youve got to say.

Arsenal vs Huddersfield Town live streaming
Arsenal vs Huddersfield Town live streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Wolverhampton Wanderers vs Stoke City Live Streaming
Notts County vs Manchester City Live Streaming
Notts County vs Manchester City Live Streaming
Bologna vs AS Roma Live Streaming
Bologna vs AS Roma Live Streaming
Juventus vs Udinese Live Streaming
Juventus vs Udinese Live Streaming
Napoli vs Sampdoria Live Streaming
Napoli vs Sampdoria Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
Fulham vs Tottenham Hotspur Live Streaming
AS Monaco vs Marseille Live Streaming
AS Monaco vs Marseille Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Alajuelense vs Perez Zeledon Live Streaming
Technology News | News Today | Live Streaming TV Channels