Today is my first day at my new employer, Xamarin, sponsors of the Mono project and developers of MonoTouch and Mono for Android. Mobile cross-platform C#: long-term readers will probably see why this is the perfect job for me. (Well… short of a gig doing AI on a robot submarine with an indoor Ultimate Frisbee field, but Larry Ellison tells me that will have to wait until he builds enough infrastructure in Lanai to support both his lair and a submarine pen.)

Tears in the Rain

Our industry has the wonderful characteristic of restructuring itself regularly. This is married with the not-as-wonderful characteristic of pitiless obsolescence of skills and strategies. The publishing company I worked for in the early 90s was more than 100 years old, had 90% of the market in software development ads, and was utterly incapable of adapting to the Web: they’re gone (but not Game Developer! ). I’ve known developers whose livelihoods were tied to Visual Basic, or dBase, or COBOL and who sat out a restructuring because their companies or clients “could never afford to rewrite” their codebases to accommodate the new market. Let me tell you one of the few things about the software business I’ve learned: the market wants software that runs on their new hardware and has the native user experience. And if your company doesn’t provide that, either your competitor or some startup will.

Some Tools I’ve Known

My first multi-month programming job tracked article submissions through the peer-review process of a journal of Marine Biology. I programmed it in a database language called Paradox, which was from a company called Ansa. At the time, most people doing that kind of development were using Ashton-Tate’s dBase, but Paradox was a better tool: it had a GUI drawn with ANSI characters that allowed you to look at your data and application in different ways and it had something called Query By Example that was just awesome. The tool was key to the win. (Ansa was eventually bought by Borland, which also ended up buying Ashton-Tate, but that’s a whole other story.)

A little later, when I was 25, I was hired as Product Review Editor for Computer Language and AI Expert magazines. This solidified my belief that tools matter. I knew that “object-oriented programming” was The Next Big Thing. So I broke the shrink-wrap on a copy of Digitalk’s Smalltalk/V 286 (as in 80286, because I had the fastest damn computer in Miller Freeman). It took me a little while (and exposure to C++) to “get” OOP, but holy crap was Smalltalk a tool that clearly was vastly more powerful than any IDE that I’d seen before (it took until the 2000s until mainstream IDEs had comparable navigation and even now, I miss the scratchpad-like capabilities).

Again and again I’ve seen it played out: moving from translator-based C++ to native-compilation gave Zortech and Borland developers an advantage, IntelliJ’s IDEA IDE gave Java developers an advantage, Raima had high-performance NoSQL before the term was coined, etc. Tools matter.

A few years ago, when I programmed my first commercial iPhone App, I chose to use MonoTouch. Why? First, to be honest, simple familiarity: I know C#. But the reason why I know C# as well as I do is due to its merits: I think it’s the best-designed of the mainstream languages. I don’t think it’s ever been correct to call C# a “clone” of Java but it’s certainly not correct now. While the evolution of Java languished, C# not only evolved, it advanced in a directed and strategic manner: lambdas, LINQ, type inference, and the new async semantics are tools that work together powerfully: they aren’t random features but instead are pragmatic implementations of the sometimes-obscure functional programming world.

It turned out that C# and MonoTouch were great tools for programming iOS. Although MonoTouch binds Objective-C APIs so they “look right” to C# developers (object.Method(arg, arg) not object method: arg:) you still use the native APIs. So existing Obj-C and iOS documentation and examples make perfect sense: you can still rely on excellent resources like Erica Sadun’s excellent “iPhone Developer’s Cookbook” with hardly a pause.

And the resulting application runs at native speed and looks like a native application because it is a native application.

It Takes A Village

I didn’t make a fortune on my Kailua Kona tour-guide application. I did have very predictable sales: 1 per day at $2. The good thing about my sales is that they were so pitiful that it was clear that there was no business model: a tour-guide framework targeting cruise ship shoregoers is no Angry Birds.

But other people have had better fortune and a thing you quickly learn about the MonoTouch community is how friendly they are: the #monotouch room at irc.gnome.org is incredibly helpful and there are always very experienced developers hanging out there.

Even more importantly, I think that the Mono community has a special feel and it’s this, more than anything else, that makes me so incredibly excited about joining. Although Mono is an implementation of a Microsoft-controlled technology stack, the Mono community is different than the Microsoft community. Microsoft has great people and some of the best minds in software, but I think that the Mono community benefits from being smaller: it’s nimbler and more personal. I think it’s more excited and more exciting. I think its technology is great and I think its strategy is great. A shorthand that some of you will get is that I imagine that this is what it must have felt to be at Borland in the mid-80s.

More Words tk

I will be working on the documentation team, particularly API docs for iOS. In other words, drinking the ocean. We want to make the MonoTouch programming experience as clear and straightforward as possible and that means not only thorough and accurate documentation, but clear and, dare I say it?, enjoyable. My inspiration is, again, the Borland documentation of the 1980s, when there was the sense that everyone — the company, the users, and the “gurus” — was exploring the brave new world together.

Hopefully my job will spin off more blogposts on this site — probably things that aren’t directly related or that are too opinionated for official docs. I’ve also talked to my Editors at SD Times and Dr. Dobb’s and it looks like I’ll continue my “Codewatch” column and be able to continue as a Jolt Award judge in certain categories.

I’ll continue to post inane babble on Twitter at @lobrien and possibly-helpful answers on Stack Overflow. Otherwise, you can always contact me at lobrien@knowing.net or… larry.obrien@xamarin.com