Edd Dumbill and Niel Bornstein - interview

From LXF Wiki


Mono linguists

Linux Format met up with Edd Dumbill and Niel Bornstein, recent authors of a book opening up the delights of Mono.

The Mono debate has galvanised the free software community. Should we be writing software that depends entirely on a Microsoft invention? Would we be opening ourselves to the possibility of patent lawsuits? Would we be forever playing catch-up with new Microsoft innovations? Some believe that the .NET innovations are too great to take the "not-invented here" approach and believe that Mono the open source port of the .NET framework ­ and C# could well be the best choice for future development.

Edd Dumbill and Niel Bornstein are two such people, and paired up to write Mono: A Developer's Notebook, which is a hands-on lab-style guide for coders wanting to take the first step on the path of Mono. We caught up with them at OSCon to ask about their motivations, why they avoid C++ and, of course, their book.

Linux Format: You guys have been hacking on Linux for years now. How did you get into Mono, and what were you doing for all those years before it came along?

Edd Dumbill: I was hacking on the Gnome desktop project, and working pretty closely around the sort of things that Ximian people were doing anyway. I came to Mono because it made me much more productive in writing Gnome apps with the leap in productivity from C# over C.

So for me, it wasn't really the cross-platform thing, it was just that it was a nice environment to work in. I participated in a project that [Ximian and Mono co-founder] Nat Friedman was running called Dashboard, which had been on hold for a time and eventually morphed into a search tool called Beagle. But that's what got me into hacking on Mono.

Niel Bornstein: For myself, I'd come from Java to .NET on Windows, and was always interested in the possibilities of open source in that space. Ed came along and told me he wanted to write a book [on Mono], so I sort of picked it up. I came to Mono from the book as opposed to coming to the book from Mono.

LXF: There are still people who don't really trust Mono because they think there all sorts of patent issues surrounding it. You guys must have been fairly early adopters in comparison. Did you know that the threat of restrictive patents was around, but still decide to dive in with both feet?

ED: People who I trusted, Nat and Miguel [de Icaza, Mono co-founder], were investing a lot of time in it, and in some senses that's almost a good enough guarantee for me personally. At that point I was not a corporation, I was just a hacker. But also, every time you write a program you are almost certainly trampling on somebody's patent. And even if they don't have a patent that looks like you've violated it they can probably make one of the ones they've got look a bit like it and take you to court anyway.

LXF: But surely that wouldn't be wilful infringing?

ED: No, the problem is that if you're a small fish, and if someone has a patent couched in broad enough terms ­ and a lot of them are couched in broad terms in the US ­ they can go after you. The point is, even before you get to court you're not going to have any money to fight. The consideration about patents is really more on the side of Mono that's not ECMA [European Computer Manufacturers Association]-standard, the stuff that emulates Windows, and I'm not using that bit of the platform anyway. The Windows forms, ASP .NET... NB: Microsoft published these standards, or sent them to ECMA so they are public standards ­ so why not use the parts that are the standards? The rest of it... who knows what'll happen? It won't stop me from using those parts, and it hasn't stopped me from suggesting people use them when it's appropriate.

LXF: Having made the switch to Mono, what would you say are the biggest improvements for you?

ED: The main difference would be moving from using C to using C# and writing desktop hacks for Gnome. That's what a lot of people have been doing in the Gnome space with some really interesting and useful applications that have been pretty rapidly developed.

One of the main advantages of moving to a mature object-oriented language is that there are a lot of features. The [Mono] desktop apps are now first class, with inheritance, events and so on. You'd get a lot of that if you went to Java, obviously, but C# still feels like it's got a C-programmer's heritage in there. I could never get the hang of Java because there were too many constraints for what I did.

NB: Also, C# has lots of nice sugar that Java, until recently, didn't have, and some of it still doesn't have. So for me coming from Java, it was very nice to be able to continue with C# (which I had grown to like on the Windows side), and use it on Linux and the Mac and all the other platforms.

ED: One other big advantage is that you don't have to lose all your investment in C code because of the P/invoke stuff. That allows you to invoke native code directly from a C# program without writing all those wrappers and so on, whereas if you were in Python you'd probably get SWIG involved. It'd be a long, long route round. That's the big advantage.

With a lot of scripting languages and dynamic languages you tend to hit a roadblock, because you can't find a code library you want ­ which happen quite a lot with a young language. So that's a nice escape.

LXF: But you say switching to C# gives you inheritance, which you could also have in C++. Would that not have been just as easy a move?

ED: I think you need to be a masochist to switch to C++. There's a reason why the Gnome project never did it. It brings a lot of heavyweight inconvenience that I personally don't want. It's a religious issue, I suppose.

There's also a lot more sanity in having a language that has refactored programming experience taken from C, taken from C++, taken from Java. So in a sense, it's taking the good things and throwing the bad things out because they got in the way. You know all the random stuff with header files, the stuff from C, C++... That was just a big pain. You needed to have the prototypes, two places for your class.

NB: It's kind of sad. I've forgotten a lot about pointers. You can use them [in Mono] but I don't know any really good reason to if you're writing portable code and aren't using some legacy libraries. I haven't written in C for five or six years at least.

ED: I suppose the memory management is the big thing; working in a managed code environment.

LXF: That's like Miguel said: "There comes a point in your life when you realise that you've spent too much of your life doing your own garbage collection."

ED: Yes, it's time to trust somebody else, and we've got to that point. NB: I think memory and processor time are cheap enough that you can afford the time for the garbage collector to run. You don't have to tune your code as much as you used to.

LXF: Do you find, though, that if you are going to do some GTK programming you reach for Mono straight away? Or would you say, "C fits in better here"?

ED: I don't think anyone sane would go for C any more. One major reason a lot of the Gnome stuff is still in C is because it's the only thing people agreed on. Or rather, everybody agrees that they want to use a higher-level language, [but] is it Python? Is it C#? Is it new classpath Java? I still think that C has this role for fundamental libraries. But if you tried creating objects in C or GTK you'd soon find out how painful that is.

I think Mono and Python both have advantages. Python is possibly quicker for prototyping, but the type safeness in C# gives you a lot of assurance that your program isn't going to crack out at some point. There is actually a nice middle ground now ­ with Boo and IronPython, we're at a point where you can have decent interpreted languages that run in the same runtime. I'd happily use those for prototyping too: I'm not really fussy.

LXF: Have you been following the movements of other high-level languages in the Gnome project?

ED: Well, I was involved a little bit in the debate the first time round, which was about a year ago. A lot of people got tired out and no decision was ever made. We're still in that limbo really. The people involved in the Gnome project all work for different corporations: Red Hat has a big Java thing going down with its work in classpath and so on. Then you've got the guys from Canonical who are big into Python ­ they're not going to leave that in a hurry.

LXF: Novell, Red Hat and Canonical: three different companies, three different languages!

ED: But so what? DVDs have plenty of capacity; people have more bandwidth these days. If we have to ship three virtual machines, three runtimes and create the bridges, then that's fine. If that's the cost of getting decent Gnome apps in progress, then we'll pay that tax. That's not a problem. I think that's where we're going to have to go ­ just do the work to connect it at the bottom.

What makes a Gnome app isn't what language it's written in, it's that it adheres to the style guide ­ the fact that drag and drop works in a certain way, that the theme is themed in a certain way and so on. Really, what language it's written in isn't germane as far as the user is concerned.

The debate that's left is about what the development platform will be, but I think that's answering itself, because the platform developers will choose the one that they can get the support for and the one that maybe they feel comfortable with for corporate reasons. I think Mono is seriously ahead on that front because of the vast amount of support it gets from building on top of Microsoft's platform.

LXF: For end users, Mono is just about cool applications: F-Spot ­really cool. Beagle ­ really cool. Blam is... very cool! In fact the closest thing I've seen to really useful stuff is iFolder. Is that because there are cool hackers working on Mono and you only want to do cool things?

NB: Enterprises that are already using .NET and want to move to open source platforms are starting to adopt Mono for that purpose. I've talked to loads of companies in the last six months that are interested in Mono ­ they're not necessarily going there yet, but they want to know: "What do we have to do? What is it all about? Is this the answer for us moving off Windows servers for ASP .NET, or maybe not moving away but writing portable .NET code?" So there is movement out there in the corporations, but maybe not so much in the products.

ED: Those projects you mention have been built for the Gnome desktop in Mono. You're got to realise that a large number of open source projects that started in .NET run on Mono anyway, so there's not much point in writing another version. There's a good chance that most projects will either trivially run on Mono or just need a small bit of recompilation to avoid Windows-only assumptions ­backslashes in filenames and other stupid stuff that programmers shouldn't be doing.

And also, you always see the cool stuff because that's what people can show you in five minutes!

LXF: Is the recompilation needed for situations such as calls to P/invoke, where a programmer might want to get back to the Windows message loop?

ED: It's not even that actually. We've had this problem in Java too: rather than use the path class to make a filename path, a developer just appends backslashes to things.

[It's because developers] make assumptions about stuff, like how many disks there are, where people will be saving stuff, how to get to the home folder and so on. But if you do these things the right way, you're portable. We have some ground rules in the book for writing portable apps. It's not too difficult but you'd be amazed at just how many lazy hackers there are.

LXF: Let's talk about the book. Is it part of a series?

ED: Yes, O'Reilly's Developer's Notebook series. I think it reflects how a lot of developers work: you get your hands-on examples, work through them, maybe look a bit at the references and then go on. Most developers really do employ a `code by example' mentality a lot of the time.

The book reflects that [with] a series of `labs'. There's an exercise, we say how it worked and present more continuation information ­ what if you want to do this? What if you want to do that? ­ then we end with where to find out more. We've tried hard to make sure that there's always extension material for each of the labs, to enable you to go on to an advanced state, teaching yourself.

NB: One of the other nice things about the format is that it gives you the chance to inject a little humour and not be so dry and technical. There are little marginal notes where you can make little jokes and keep it light and easy to read, as opposed to dry, technical writing.

ED: It was also a lot of fun to write, which I think makes a big difference. If you're having fun writing a book, it comes across.

LXF: I only had two hours to read it last night but my impression was that it came across as a little short.

ED: Well, I daresay you didn't pay for it, but the price reflects the length. It's not an encyclopaedia...

NB: ... it's a starting point.

ED: There is actually some really good advanced stuff in there, so it's not that we don't go on to advanced topics, but what we do is provide you with enough to get the example going, so you feel confident about this particular area, then provide pointers for you to go off on your own and do more.

This book makes certain assumptions about who's reading it. Probably the most important one is that they're not someone who needs to be spoon-fed. They're developers and are capable of learning for themselves. It's a book you really need to read with a keyboard alongside you.

NB: And it's not intended to be exhaustive, by any stretch.

LXF: What can you tell us about a Mono-designed replacement for Glade [an interface builder for Gnome and GTK]?

ED: There are two successors to Glade being developed. One one them is called Stetic, for some reason. A successor will be chosen ­ one of them will be written in Python and one in C# and that's probably the answer to what's going on there. It'll probably be integrated.

MonoDevelop is getting some really good integration. There was recently an NUnit add-on, so that in the side panel you could see all your unit tests, how many are failing, how many are succeeding and a graph of how that's happening over time. I think that will get better, but it's got a long way to go before it's as good as Visual Studio or Eclipse, for instance. If we're going to move people over from Windows to Linux there need to be more things that they're comfortable with, all the facilities that they have in Visual Studio. And a decent forms designer is definitely one of those things.

There are other issues there because you're moving across from the Windows world, where you've got this horrible, absolute pixel-placement layout of graphical forms, to GTK, which is a box model. Everything can stretch, it's much more adaptable. It's the same kind of thing that designers face when coming over from doing print work to HTML in that sense: the same need to adapt.

LXF: What's the best bit of advice you can give to people currently using Qt or GTK who are considering trying Mono? Apart from, "Read our book, it's great"?

ED: I would say, get your hands dirty with code as soon as possible. I mean, whenever you're moving from one place to another, the best thing to do is to get hands-on experience. Some of the Mono projects, such as Blam and Monopod (which is my podcast client), are small enough to get your head around. Just download them and poke about in the source. Tweak them, send a patch. There's no substitute for getting your hands dirty in my opinion.

NB: Read MSDN [1] (http://msdn.microsoft.com). The best documentation for the C# language and the framework class libraries is on Microsoft's website. So if you really want to learn about the language and the libraries, that's the place. LXF