The “Next” Eclipse CDT

CDT Summit at EclipseCon Europe 2016

In my last article, I walked through a bit of the history of the Eclipse CDT project. It’s a great story of the trials and tribulations of community building, working with a group of like minded platform vendors, even competitors, who just wanted a great IDE and who knew the only way to get that was to work together.

What sticks with me most looking back on my ump-teen years on the project is the people. Each of these vendors were led by passionate tools developers who put aside any hint of corporate agenda and just wanted to work with other developers from around the world, to solve hard problems, and build something they would be proud of. Through the semi regular face-to-face CDT Summits and CDT days at EclipseCons past we were able to build relationships and become great friends. Even after some have moved on, I still remain in contact with many of them and we still share a laugh or two, and even the odd beer!

So I offer no apologies if, as participation has dwindled on the project in recent years, I yearn for those days. But my personal enjoyment working in this environment is one thing, I don’t think the job is done. The C++ language continues to evolve and become more usable and powerful than ever before. Even C continues to receive updates. And more importantly, the IDE landscape is changing and we need to keep up to keep our users and customers happy.

Over the years, I have always had to deal with users and even colleagues, who are hard core engineers, who refuse to give up their text editors and custom bash scripts. In the end, it’s been hard to argue with them. For these folk, IDEs don’t work the way they want to work. And, initially at least, it does slow them down as they fight the paradigm and they just end up frustrated and toss it aside losing all those gains we are trying to give them.

But in the end, I guess it was only a matter of time that an IDE platform would come along and offer the best of both worlds. Be a great unopinionated text editor, facilitate hooking up users’s bash scripts, be super extensible to add in little accelerators. It’s been brewing for a while. Sublime was the first such thing I saw developers really enjoy. And now, today, we have Visual Studio Code, which is becoming the dominant editor platform.

And funny enough, an interesting thing happens when you take a bunch of IDE developers and tell them to build a great editor, they end up building an editor so extensible that it slowly becomes an IDE. The VS Code team, many of them former Eclipsers, has managed to create a mechanism to add powerful language services to the editor. And, of all things, add support for debuggers. OK, you add debug support, you’re no longer an editor, you are an IDE. Stop pretending :).

But even greater, the VS Code team has done this by creating standardized APIs and protocols that other IDEs can use. You can build common services and then plug them into your favorite IDE, even Eclipse!

With this new architecture, the path forward for the Eclipse CDT project is clear. We need to take all that C/C++ IDE knowledge we’ve built over the years and use that to build common components that can be used by other IDE platforms. It means growing beyond our Eclipse IDE roots to give users that great experience in the IDE that best works they way they want to work.

We as the CDT community have a lot to offer, and there really isn’t a community like it, that focuses on the needs of the C/C++ developer. The challenge will be to harness that energy again, to work together for the greater good that we can only accomplish together. It really is an exciting time to be an IDE developer and Eclipse is a great home for us to come together.

In my next article I will start getting into the technical meat of what this new vision entails and what fun we can have building it! Time to roll up our sleeves and get to work.