Jb in a nutshell

If there’s one thing I’ve come to learn about life, it’s that most things are neither completely black nor completely white. There’s an infinity of shade of grays in between.

And if the announce of the Visual Studio (VS from now on) 11 beta taught me something, it is that VS 11 is exactly that. Neither completely black, nor completely white. But very gray. Oh so gray.

I won’t comment about the new look here, as the object of my ire with VS and its apparent roadmap lies at a completely different level. And boy am I annoyed to see where the VS team puts its focus.

Do you remember Steve Yegge’s rant about the need of a programmable platform at Google? It’s a tad long (euphemism of the day), but it’s well worth the read. And with Visual Studio, Microsoft is exactly failing at that.

Visual Studio 11 will be the sixth iteration of Visual Studio with .net support. And for a .net programmer like myself, it’s still a terrible platform to extend. I want to be able to have complete control over my environment by programming it. I’m a firm believer in meta-programming, I want to be able to program my IDE all around, automate tasks, manipulate my projects and my code, and complement the UI myself. Have you ever tried to write a plugin for Visual Studio? To keep on going with euphemisms, let say it’s not a pleasant experience at all.

It’s quite a shame from the company that brought us the .net framework and C#. Most of the APIs to plug into VS are poorly documented COM wrappers from another age. VS 2010 introduced some managed APIs that are addressable from MEF, and they’re actually pretty cool, but they only cover a small surface of what VS has to offer. And even those too are poorly documented, compared to the level of documentation for the .net framework. Roslyn is also going to somewhat improve things. But it’s not planned for VS 11, and it’s also restricted to a subset of what VS offers.

If you want to interact with the project system for system, you can use the disgrace that the MPF (Managed Project Framework) is. It’s a buggy piece of code that you have to dig from codeplex, with terrible documentation. If googling for documentation about it brought you to the MSDN, you can read that the types there are in:

Assembly: MPF.Project.NonShipping (in mpf.project.nonshipping.dll)

How friendly. And because no one really knows about all those obscure APIs, your only source of knowledge is the Microsoft VS extensibility forum. Which is also another source of frustration entirely : you have to wait for MS employees to help you out.

For anyone who wrote eclipse plugins for instance, VS is a huge step back. No wonder the plugin ecosystem of eclipse is so flourishing, it has been designed to be pluggable.

I think it is actually hurting VS itself, and as a consequence, the .net platform as a whole. I really think that the experience of the .net programmer would be quite different if from the beginning VS would have exposed a proper managed API, with the same quality and care that you can find for the .net framework. Or if at least, they would have seriously worked towards that during the years.

Folks from Microsoft said they value feedback for betas. Here’s one: invest in making Visual Studio a great platform for the .net programmer. Expose real managed APIs, let us plug into as much features as possible. .net programmers all around will take care of improving the experience of developing with Visual Studio much faster than what it takes you to add a better search into VS.

Also, don’t value feedback only during betas. Interacting with microsoft connect most of the time result in huge frustration. It’s the only place where I, a customer, have been told that my bug won’t be fixed because someone was scared of getting customer complaints.

Or “What I have been up to since last September”.

It is no secret that the middle of 2011 was a bumpy time for the Mono team. But let’s not babble about something that happened months ago. Suffices to say that September the 15th was my last day at Novell.

I started contributing to Mono in 2005. In 2007, at 24, after being part of the two very first editions of the Google Summer of Code, I was hired full-time. I had an amazing time working this long on a project I deeply care about.

I’m proud of what we’ve accomplished during this time. And I’m super happy to see how great my friends at Xamarin are doing. Yesterday I was stuck on a plane for quite a long time, and a guy in front of me tinkered for an entire hour in iCircuit, an amazing application based on MonoTouch. As a member of the original MonoTouch team, it felt awesome!

Yet, after the dust settled, I felt like it was time to try something new. Something I’ve been thinking about for quite a while now. Even though I’ve been doing a lot of thinking and planning, it took quite a leap of faith, and quite a bit of work.

Introducing SyntaxTree

SyntaxTree is a company whose mission is twofold: write great developer tools and help other companies doing so. We obviously have a very strong background on the Microsoft .NET and Mono platforms, but we’ve already been helping clients target some very different platforms. You’re more than welcome to check SyntaxTree’s services page out to have a look at the kind of work we’ve been doing.

And today we announce our first product, UnityVS, bridging two amazing tools, Unity, and Visual Studio.

If you don’t already know about it, Wikipedia defines Unity as “an integrated authoring tool for creating 3D video games or other interactive content such as architectural visualizations or real-time 3D animations”. It uses Mono as a scripting engine and Unity has been part of the Mono community for a long while now.

Our product, UnityVS adds support in Visual Studio for the languages that programmers can use in Unity to write scripts for their game: UnityScript and Boo. UnityVS also adds support for debugging your scripts inside Visual Studio, even when running inside Unity’s editor.

I can not stress enough how big of a Unity fan I am. I think that what those guys are achieving, especially towards beginners, is nothing short of amazing. Would Unity have been around when I was 15, instead of writing PHP and JavaScript code, I’m pretty sure I would have spent nights tinkering in Unity, and my career would have ended up to be quite different.

And they happen to have a fantastic taste when it comes to third party code. Using Mono as a scripting engine? Awesome. Using a JavaScript like language based on the Boo compiler infrastructure? Still awesome. Using Mono.Cecil to the point that they use the word “to cecil [in|out]” as a verb internally? Even more awesome. Using ILSpy’s engine to retarget .net code to ActionScript for their Flash port? Mind blowing.

I’m very excited to work on a product which complements the Unity ecosystem, I hope you’ll like it.

Just as everyone, I learned yesterday via Jimmy the near death experience that IronRuby is undergoing. And spent some time thinking about it.

For those of you who will stumble upon this and don’t follow this blog regularly, let me add a pinch of background. I implemented the .net 3.5 version of System.Linq.Expressions in Mono, I signed the IronRuby contributor agreement on day one, and regularly made sure it runs fine on Mono along with the DLR and IronPython. In the process of doing so, I contributed fixes and improvements to IronRuby. If I’m far for being the largest external contributor, at least I have a clue about how contributing to IronRuby works. And doesn’t work.

Also I spent the last two weeks working on making the IronRuby 1.1 test suite pass on Mono. Which may be the biggest reason I feel like I have something to say, as it involved countless hours of diving into the IronRuby code to extract simple test cases.

But now to the point. The IronRuby team currently consists of one hacker. We don’t know much about the IronPython team. And everyone who wanted to work on .net with their favorite dynamic language is freaking out. To a reason.

The good news is that the code of IronPython, IronRuby and the DLR is open source, and has recently been re-licensed under the Apache2 license. The official message is that IronRuby’s fate is now in the hands of the community.

That doesn’t sound like a bright future. So far, the community has been excluded from the development process of IronRuby. It’s impossible to contribute code to the core compiler of IronRuby, let alone to the DLR which is now part of .net 4.0. The code in github is a mere mirror of an internal TFS repository, and may or may not be up to date. And until IronRuby’s divorce with Microsoft is completely consumed, it will stay like this. So, sure we can contribute to external libraries, but that’s definitely not where the fun lies, and from now on, nor where the real work will be required.

So is the solution a fork?

It’s indeed a possibility. But for knowing first hand, IronRuby’s code source is far from being a simple piece of code to comprehend and to hack on. So what will happen in a couple of months when the buzz will have settled? Who will be able to take over the development of IronRuby? I for one am interested in helping, but I have already a lot on my plate. With Microsoft excluding the community from the core development process from day one, there’s no real knowledge of the insides of IronRuby outside of Microsoft, yet.

If Microsoft employees keep working on IronRuby occasionally, and keep the current setup, the community will still be excluded, and no one outside will contribute, besides Jimmy. IronRuby will simply fall into oblivion.

Yet I think that until Microsoft completely stops funding any work on IronRuby, they will be the only one really able to make something out of it. As Jimmy suggested, letting Microsoft know that there’s an important demand for IronRuby and IronPython, is probably the best course of action. Who knows, there’s maybe still time for Microsoft to correct its course. Special bonus points if we can get Microsoft to not only accept that there’s a demand for IronRuby, but also for accepting external contributions as it would make them move forward faster.

What about this petition (deleted since) to ask the Mono developers to take over IronRuby?

Actually that’s maybe what I’ve found the most tragic, and one of the reasons that triggered this post. It’s a bit along the line of “we don’t quite want to work on it, but we definitely want to have it, so let’s ask for someone else to steer the project”. If I can’t talk for my boss Miguel, I can say that we already have a lot on our plate, and that I don’t see us taking over IronRuby. I of course will continue to make sure it runs fine on Mono. But really, if the community wants IronRuby, it will have to do something about it itself. Either by contributing code or begging Microsoft.

A possibility of course would be for Microsoft to enter a development agreement with the Mono team as they did for Silverlight and Moonlight, and I’ll gladly volunteer to join the effort, but I don’t see that happening.

As a conclusion, and on a personal note, I find the situation extremely disappointing. In my opinion, Microsoft is making a strategic mistake. The Iron* projects were somehow the fun and hip face of the .net development (outside of Mono, of course). They had a true potential to attract developers that would traditionally stay away from Microsoft and .net.

Quite a number of friends pinged me about the recent release of the CCI, under the Ms-PL, and were curious about my take on it, and its effect on Cecil and its ecosystem.

First of all, there’s a bit of a story here, and I’ll write it here for those who like me, love software history. Back in the years 2003 and 2004, I was working with Thomas Gil, one of my mentor and programming hero, on one of the first static aspect weaver on .net, AspectDNG, now abandoned. I was actively researching better ways to do CIL injection.

We went from raw IL text manipulation, to Reflection and Reflection.Emit using Lutz’s ILReader library, to RAIL, until I decide to work on Cecil.

In the meantime, I’ve stumbled upon ILMerge, a tool from Mike Barnett, and mailed him to ask what powered the tool, and he put me in contact with Herman Venter, the man behind the CCI effort. I wrote Herman a couple of mails, in a terrible English, and begged him to push for a release of the CCI under a license we could use in AspectDNG. That was in March 2004.

As you can guess, it quite didn’t work out at that time, so I started working on Cecil. A few weeks after, Miguel blogged about the need of such library. He already had the Mono Linker in mind. I mailed him, got SVN access, checked in the beginning of Cecil, got Sébastien interested, etc.

I had the opportunity to be invited by Microsoft to attend an informal AOP workshop the year later, and to met with Herman, which I remember as a very nice person. I am not sure he remembers the terribly shy kid that did a terrible presentation in a terrible English. But all in all, I’m happy that five years later, my request went through.

Now the CCI release in its own CodePlex page is not really a big event, as it was already released and licensed under the Ms-PL, as it’s part of Sandcastle.

Anyway, Cecil is quite mature in its current form, it’s used by a fair number of (known) applications (please help to improve the list), and I’m currently working on two things.

The first one is a refactoring of Cecil, which vastly reduces memory consumption as well as reading/writing time. Hopefully I’ll have a beta in a month or so. We have great plans for this version of Cecil, and it’s consuming a lot of my time, more on this later.

The second one is an extensible decompiler, Cecil.Decompiler, that will greatly benefit from the Cecil refactoring. The time I dedicate to it is a bit phagocyted by the Cecil refactoring right now, but it’s certainly one of my favorite project.

The CCI is a combination of Cecil, the decompiler, and something to write a decompiled AST back, which will be the natural evolution of the Cecil decompiler. Note that the CCI decompilation/compilation process is not extensible. Now that it’s open source, you can hack it yourself, sadly, the CCI code is well, a bit messy to be polite, or not exactly a joy to read. Also you probably won’t be able to contribute back to the CCI.

Anyway, it does its job alright, and so does Cecil. Choice is always good, let’s welcome the CCI in the small family of such tools. I, for one, will surprisingly keep hacking on and with Cecil :)

To conclude on a very positive note, the fantastic thing about this release is that the CCI contains a fully managed PDB reader and writer. That’s great news as so far, we failed to get any details about this file format. This means that we can now implement a fully managed Mono.Cecil.Pdb support, and that’s just great.

UPDATE: it appears that only the PDB reader is fully managed, the PDB writer is just a wrapper over the COM stuff, just like the current implementation of Mono.Cecil.Pdb. Well, at least it’s a start.