I've moved

I got tired of dealing with Blogger's crappy spam management system and I wanted to play with a little server I have in the cloud. I'm now at http://cdtdoug.ca and a happy WordPress user. See you there.

A Great Comment about the Eclipse IDE

My favorite thing about blogging is the comments that come in telling me I'm full of crap and here's why :). It's a great way find out whether I am full of crap and I usually learn from those comments which helps me make decisions. It's a great resource and highly recommended, assuming you don't mind being told you're full of crap.

Anyway, BrunoM commented on my post about the Eclipse IDE being dead-ish and I thought I'd repost them here so everyone can see and he's given permission to do that. He makes some great points. I think I end up agreeing with him. Making the Eclipse IDE cool is just to get people looking again. At the end of the day, it just needs to be a great multi-language IDE. And bringing the IDE community together, break down the project silos, is a great idea on how we could do that. More on my ideas on that later. First, here's Bruno.

"Hello Doug. It's an interesting post you have here.

"First, like many others here, I do agree that Eclipse is losing a lot of momentum, even regressing in some aspects (more on than later). But I don't agree with your vision of what Eclipse should look forward to be. I've been following your Twitter and blog posts for quite some time, and I see this recurring pattern: the desire to make Eclipse more exciting, but exciting not necessarily in a functional and technical sense, but more in a visual way: by means of making it more "cool" or "hip". You often draw comparisons to the all the new "sexy" and cool games, mobile apps, and "Web 2.0" websites and technologies we see out there.

"Again, I respectfully disagree with this vision. Eclipse is a tool a for developers, as its goal should be first and foremost to be as productive, easy and functional to use as it can be. Cool and interesting, but in matter of *substance*, not style. (PS: I'm quite the gamer, but it doesn't change my opinion. Eclipse is not a game.)

"Now, second, regarding the main subject: Is Eclipse, as an IDE, losing momentum? It sure feels that way! And not just because it is a large and accomplished project that achieved a lot already... if it was just that case it would be okay to lose momentum in a sense, but it seems that the quality of Eclipse has actually been regressing (and a lot of opportunities have been missed). Let me be more concrete about what I mean here.

"I am an user of the Eclipse IDE in two ways. Both as a user of the JDT IDE, to develope Java, but also I am user/consumer of the Eclipse IDE API, as I develop plug-ins for Eclipse. (I worked on Eclipse RCP apps, but more significantly I head the developer of an Eclipse based IDE for the D programming language: DDT)

"As a user of JDT, and the Eclipse IDE in general, let me tell about my experiences. I've always loved Eclipse, but when I started trying out the 4.x series, I felt a bit disappointed. The new themes looked horrible, to be honest. Not just in a subjective sense, but there was several visual/rendering bugs as well. This was the 4.1 release if I recall correctly. I decided to stick with 3.x as long it was the main Eclipse release. Then 4.2 came, and Eclipse 4 became the main version. I decided to switch finally. After several months of use I noticed it was way buggier than the 3.x series. A few JDT bugs, but most where Platform bugs (views getting lost, icon/action sets getting lost or misplaced to wrong places, view setting not getting saved/persistend, workbench broken with views/editors getting partial focus - they would receive the normal keystrokes, but command shortcuts would be sent to a different view/editor! This last one drove me nuts, as it happened quite frequently, and after the workbench was broken like this I had to restart Eclipse to fix it).

"The frequency and severity of these bugs, for very common tasks, left me with a bad taste in my mouth. This was compounded by the fact that this was the 4.2 release, ie, there had been two previous releases of the 4.x series already! I know that Eclipse 4 involved a major rewrite of Platform internals, but two releases should have been more than enough to wring out nearly all of these major issues.

"This (combined with news like IBM not investing as much in Eclipse as it used to) gave me the impression that the technical excellence of the core components of Eclipse was not as good as before.
Other news do not looked favorably on this either, such as the recent one about ADT moving over to IDEA... Guys that should have been a major wake up call!

"As a user of the Platform and IDE API to develop new plugins, I also think a few opportunities are being missed. I was in love with Eclipse since the early days of 3.x, and by then, it was one of the best options to develop IDEs for other languages. I was involved with this area since 2008, which was when I first started working with Eclipse to develop an IDE for the D language. But this area appears to have stagnated ever since, despite the fact that a lot of improvements and technology could be developed. Whereas a fair amount of innovation has happened for developers of RCP applications, what new developments have occurred that make it easier or more powerful to write new IDEs in Eclipse?

"None really, with the exception of Xtext, and the DLTK (Dynamic Language Toolkit) project. There was also another project similar in scope to DLTK, IMP, but it pretty much seems to have died. Xtext has been quite interesting and looks fairly mature, but I would argue that it is not that adequate for more complex, general purpose programming languages.

"DLTK is actually a great idea for a project, and very useful. And indeed target for programming languages. The way it's done, at least with most of it's codebase, is that it copies a lot (really, a lot) of JDT code, and adapts it to be usable to other languages. Code such as JDT's project model, indexing functionality, compiler/interpreters setup, source editor, and lots UI boilerplate code. So for example, DLTK IDE projects usually have a project layout and view similar to JDT: with source folders, hierarchical packages, source modules, model elements nested within, etc.. The D IDE I work on is actually based on DLTK as well, even though D is not a dynamic language at all. It just happens that a lot of DLTK functionality is useful for non-dynamic languages as well.

"The problem here is that DLTK is quite rough on the edges, both in terms of functional limitations, API limitations, bugs, and brittle documentation. That's not surprising, it is a massive undertaking, and it doesn't have that much manpower allocated to it, from what I understand. It has been improving steadily, which is good at least, but at a slow rate.

"Now, the point to take from the comment above, is that there is a huge missed opportunity here. You see, I understand that it's not reasonable to expect a faster rate of progress with a project like DLTK, since it's mostly developed by people from one or two smaller companies with their own specific commercial interests, goals, and resource limitations. The thing is, why couldn't the JDT team work toghether with DLTK? Why couldn't all (or some) of those components of JDT be adapted for more general IDE use, by the JDT team itself? It's likely a major undertaking still, but it certainly would have been more effective than having a third party team adapt JDT for general purpose use, in hindsight (and the gains could have come much sooner). There are also a lot of problems with code duplication here. How bad these will be in practice, will depend, I guess, on how often the affect JDT code based changes in the future.

"As a participant in the D community, I've also been taking a look at developments of D IDEs in other platforms. There are two quite significant D IDE projects based on Visual Studio and MonoDevelop. People have toyed a bit with Netbeans and IntelliJ IDEA, but nothing signicant has come of it so far. I was quite surprised with the MonoDevelop one though: both the base platform, and the D IDE for it are quite full featured. And this is for a platform (MonoDevelop) that is a quite recent newcomer in the scene.

"Guys, the way I see, Eclipse feels like Subversion. It's fairly good and useful, and it's much better than CVS (which could be say, Visual Studio or CodeBlocks or something). But one day, a team with superior technical excellence could well create the equivalent of Git for an IDE platform, and it will just blow away Eclipse completely, in a heartbeat... :/"

CDT Community Survey

One of our CDT committers had the great idea to put together a survey to gather input into what contributors could be working on. Please feel free to give your input at the link below:

CDT Community Survey

"Eclipse smells kind of dead"???

There was an interesting comment on an old CDT bug that raised my eyebrows.

it's only been 3 years. other eclipse bugs that I reported
are are still open after 9 years.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=76646
https://bugs.eclipse.org/bugs/show_bug.cgi?id=114003

Sad to say, but Eclipse smells a kind of dead.

Of course, those of us who work in the Eclipse community know that isn't true, but it certain isn't as alive as it was in the early years. Even from my experience on the CDT, we have a small handful of dedicated and productive committers, but we do have lots of bugs that don't get addressed.

Building an IDE, especially one that supports so many environments, requires a lot more contributors that we currently have. It's an age old problem that I've struggled with for all my years involved in Eclipse and many of those as a project lead. How do you grow your contributor community?

And there are some good answers that generally revolve around lowering the barrier to entry: having active mailing lists, good documentation, committers that help bring in new people. And these things definitely help when you have a contributor interested in contributing.

But let's back up a step, assuming you do those things, how do you get potential contributors interested in contributing? You have to make your project something they care about, something that they will feel rewarded contribute to. For the people who contribute to Eclipse now, that's certainly a strong motivator. And, of course, it's important to get companies to see the value in it too, and that's of course another strong motivator, you're boss tells you to contribute :).

To that end, I think we need to figure out ways to make the Eclipse IDE exciting again, to be so alive that it's hard to miss that fact as our commenter did. I think there are a couple of ways to do that. First, make it technologically interesting and modern. Make it a good learning experience that contributors can take with them so they not only get the value of having a great IDE but the value of adding knowledge to their tool chest.

Of course it's a chicken and egg problem, we can't do these things without new contributors, but we should start talking about and planning out features and rearchitecture they'd like to see. And, yes, e4 was supposed to be that, and maybe I'm getting this wrong, but e4 was more focused on adopters than users. And it's really the users who I'd like to see get more involved. There's so many more of them. And they're the ones who really have a vested interested in making a great IDE.

The second idea that I've started pursuing is to have Eclipse release more often. We've decided this for the CDT. Yearly releases are way too far apart, especially when you want to inject innovation into our product. If you release more often, contributors get the reward of seeing their contributions in action sooner. And again, it's that reward that we want to give them. At any rate, you can follow the thread here. It's good to see like minded people in our community leadership think the same way.

We know first hand that Eclipse is not dead. But it could sure use some love.

One IDE to Rule Them All

So, yeah, I promised I would blog more and then four months later, here we are. But now is probably a more important time for me to be doing this. I have a lot of things I need to share with the Eclipse community.

As I get deeper and deeper into mobile development with my work as architect of the QNX/RIM Momentics IDE, the more I appreciate the decision we made 10 years ago to build with Eclipse. The frameworks, the ecosystem, and the community are very rich and we all benefit from it. But its not without it's warts and I really need to do what I can to clean that up.

As an example, I'm building a grocery list app for my wife and I so I don't forget things as too often happens. I'm using node.js for the server-side and both a web front end for our laptops, and a mobile front end for our phones, both native Cascades for BB10 and mobile web for others.  The challenge is to use a single Eclipse workspace to build all of those components. So far it's OK and there are enough pieces to get started at least. But it's an awkward setup and there are a lot of pieces missing or don't work well, or at least, are very hard to use.

And then I have some long time gripes. Launching in Eclipse is a thing for magicians and witchery. How poor newbies are picking this stuff up boggles my mind. And that's just the one of the usability problems we see. Tool bars seam like random collections of buttons with unclear and often duplicate meanings. Users coming over from Visual Studio and Xcode are faced with a very foreign environment. There, usability experts have driven much of the complexity of project setup and launching down to a few simple concepts. We need the same level focus on usability applied to Eclipse.

One IDE to Rule Them All

I have a vision. I call it "One IDE to Rule Them All". My focus is on mobile apps, but it's clear that the best mobile apps include components in the cloud. We will continue to leverage and contribute to the great frameworks and ecosystem that we've built with Eclipse for as much as we can. But we will have a renewed focus on making sure all those things combine into a Great IDE with a Great user experience.

We have some early ideas on how to make our vision happen. New technologies like e4's modeled UI look promising. But there are a lot of experts in the Eclipse community and we could use your advice. Hopefully working together we can achieve this vision, not just for my needs but for everyone. The greatest asset at Eclipse is it's community and working together is what communities do. And build the One IDE to Rule Them All, we can (sorry Yoda :).

Where do we go from here?

Hi! Long time no see, or at least write here in my blog. It's been a crazy last few years since I used to write a lot. I still dump my brain from time to time on Twitter @dougschaefer (sometimes too much - beware the drunken tweets, but yes I love electronic music at the moment). But I'm not sure why I stopped writing in the large. I love to write. It's therapeutic and helps me work through my thoughts to make sure I'm agreeing with myself. So it's time to start again, especially now that I'm settled in my new position as architect for QNX's Momentics/Blackberry NDK (BB10 is going to rock, BTW).

Over the last couple of years I've been thinking more and more about usability. The whole idea of being in the IDE business is to help software developers with productivity and to help them understand their code better so they can make it better. Yet I still often hear complaints that our tools, Eclipse based tools in particular are too hard to learn and are very quirky, especially for native development, even with all the work we've put into the CDT to take a Jave-centric IDE and make it work for them.

Now some of this is just, again, quirkiness of how Eclipse manages projects and resources and builds and debug and launch. And there are things we can do there to make incremental improvements. And we will continue to do those things.

But there is something bigger, and bigger in many ways. A bigger problem requiring a bigger solution but potentially a much bigger game changer. Eclipse as an IDE is looking really old. Even with Eclipse 4, it still looks like an MFC app from the 90's. That in itself isn't a bad thing, but we need to understand the reasons why modern apps don't look like that any more. It's all about usability, about making the important things obvious. It's about making the app visually appealing, ensuring the user is comfortable and not overwhelmed by choice the first time they fire it up. These are the things I'd like to see Eclipse the IDE exhibit out of the box. But as we all know it's huge mountain to climb to get there requires expertise we as engineers don't naturally by rule have in our DNA. That is: understanding the humanities, how people think, especially people not always like ourselves, empathizing with them.

So how do we start? My first reaction is to throw away every plug-in with a .ui component in it's name. Or take everything that depends on SWT and toss it. That's pretty dramatic and I thought way too hard if not impossible. Until, that is, I saw Tom Schindl's work with JavaFX and how he built a mini IDE reusing the core components from JDT. It's something I had thought of but he actually made it work and proved that it could be possible. The powerful core platform components of Eclipse and the language plug-ins, CDT included, can be used that way. It is one thing I've always mentioned when someone asked why we break out core and ui into separate plug-ins. The door is opened.

So where do we go from here? My plan is to play more with JavaFX and try out some different UI layouts and paradigms. I need to understand what is possible, how would users benefit from organizing things differently. And I can do so with the confidence that once we plug in core Eclipse, we could take this IDE we love to the next level and extend it's life to the foreseeable future. Of course one or two people can't do this alone. Any changes of this magnitude require a significant community, but something this exciting has the natural ability to create one. We'll see where we end up.

Debugging Vert.x apps with Eclipse

+Pascal Rapicault has me hooked on Vert.x, http://vertx.io. It looks like it can be a great competitor to node.js allowing you to use the same asynchronous web programming model not only with JavaScript by any of your favorite JVM languages, including Java believe it or not!

At any rate, tonight I started to see if I can use Eclipse to develop apps in Vert.x. It turned out to be a lot trickier than I thought so I figured I'd capture what I did here.

First, you need to create a User Library for Vert.x. I just looked at the bin/vertx script to see what it added to the Java classpath to see what jars to add to the library. After that I was able to create a Java project and add the library to the build path and code up my little hello world app (which indeed is very node.js like).

Launching is pretty tricky. First, Vert.x doesn't want your app to be on the classpath when it starts up. Weird and that means you have to remove your project from the Classpath. But you do then need to add in your Vert.x user library using the advanced option so it can launch Vert.x's main, which is VertxMgr.

And you need to add your project build output with the -cp application option, which I passed ${project_loc:/vertxHelloWorld}/bin, so it can find your Verticle class.

Finally when you debug, the Default source path matches your Classpath. Since you removed your project from the Classpath, you have to add your project to the sources manually in the Source tab.

I imagine someday, someone will create a Launch Configuration that will do this all for you but if you put some muscle in it, you can get up and debugging your Vert.x app in Eclipse now. Now, if I can debug my client-side JavaScript in the same session...