Page 1 of 1


PostPosted: Tue May 06, 2008 9:38 pm
by Charles
I took a look at writing a Cobra plugin for Visual Studio 2008. I found the API to be rather arcane and the docs to be obtuse. When I peeked at the IronPython plugin, I found that 24,000 raw lines of C# code were required to pull that off!

Another IDE of interest is #develop. It's Python plugin is not much better at 19,800 raw lines of C#, but then the Boo plugin was about 10,000 and I'm guessing Cobra would be similar. I'm inferring Python has an impedance to overcome from being neither static nor designed for .NET. Strangely, the Boo plugin is written almost entirely in C#... Perhaps they didn't want to use Boo prior to having IDE support for it.

(I suppose another IDE of interest is MonoDevelop which was forked from #develop way back when.)

So Visual Studio extensibility is not as friendly as I would like. That's not the only problem. While I'm doing any IDE work, the language is mostly sitting still (but not entirely thanks to contribs). Which is why I didn't write a Cobra plugin for #develop even though it's API, docs and examples felt cleaner.

I know that earlier I shooed people off any IDE effort due to wanting to implement it myself and sell it as shareware/indie software. I no longer want to do that. I want to return to focusing on the core language and compiler, and let others charge ahead with the IDE integration. Getting IDE autocompletion and debugging sooner rather than later will really boost Cobra. Maturing the language in parallel will amplify the benefits and we'll be in a really great place some number of months from now.

I can worry about Cobra-based income down the road with a book, support contracts, consulting, begging, etc.

The main IDE choices are Visual Studio (VS), #develop (SD) and MonoDevelop (MD). VS will boost Cobra popularity more and it *is* a damn nice environment to use. SD will be easier and quicker to get up and running (unless you already had the VS experience). SD comes pretty close to VS including the important editing and debugging features. I haven't investigated MD.

Which ones are pursued depends on who takes the lead. Any of these environments needs or will benefit from a CodeDom and MSBuild support, so some work can be shared.

Some links:



As always, I'm interested to hear your thoughts. Of course, I'm especially interested to hear if anyone will pursue this.



PostPosted: Mon May 12, 2008 11:23 am
by mchean
There was an attempt at BOO to VS integration here: ... tudio_2005. It was put on hold due to some licensing issue that has since gone away, but I don't think it has progressed any further.


PostPosted: Mon May 12, 2008 1:46 pm
by Charles
There was also a comment on the Boo list that someone had taken a look at the VS integration and found it to be not-so-straightforward and to require some significant work.


PostPosted: Mon May 12, 2008 1:48 pm
by Charles
I've added a couple tickets whose completion would be useful regardless of which IDE Cobra was integrated with:

MSBuild support:
CodeDom support:


PostPosted: Fri May 16, 2008 3:50 pm
by greg7w
How about creating a plug-in for Eclipse? I have heard good things about the PyDev plug-in, however, I don't know how much effort this would involve.


PostPosted: Mon May 19, 2008 9:46 pm
by mchean
Not to harp on the Boo language aspect, but I noticed that Codeplex has a recent implementation for 2008 (May 19th) at


PostPosted: Tue May 20, 2008 3:33 am
by Charles
Nothing wrong with your post, that's interesting news. They already had some of the bits like MSBuild and CodeDom from previous IDE efforts, so this was destined to come around sooner or later. Although this first version is pretty basic per

It's still the case that I don't have time to work on the core language and the IDE. I'm sticking with the core language for all the obvious reasons (it's what I know best, it still needs work, etc.). So we still need someone to step up for a #develop or Visual Studio plugin.

Regarding Eclipse, I'm guessing that it would be more work and/or have feature deficiencies due to Cobra being a .NET/Mono language, not JVM. But that's speculation, not experience.