Ian pointed out that I actually didn't state what my vision for Eclipse was. I noticed that after I posted, it was probably the wrong title for what I ended up writing. I'll try again, maybe sooner than later, I'll actually get my point across.
I do have a vision for Eclipse, or rather, Eclipse as an IDE. Eclipse is so much more these days, I really need to differentiate myself. I am an IDE guy. Eclipse started as an IDE, turned into a great IDE, let's keep it that way. Maybe that's my vision. Keep a good thing going with focus on stability and quality.
I also have a vision on where IDEs are going, and I mentioned that in a previous blog where I stated the prediction that the desire for software developers to write software using mobile devices will drive that vision. But in the end, I think it's more than that.
This vision comes from watching the Google I/O keynote on Google Wave. If you haven't seen it yet, do so. Whether Google Wave is the right technology or not, the workflows they present are the future. I have no doubt of that. And it's all about collaboration, including real-time collaboration, through your web browser. And that let's it run on any platform with a web browser, which is pretty much everything.
I was especially struck with the demo of the team working and commenting on documents. Everything becomes a document, or a Wave in Google's terminology, and everyone can contribute to it. And it keeps track of who contribute what and when.
The first thing that popped into my mind, being the IDE guy, what if the document was a source file? Wouldn't it be cool to post a source file for review, have people attach comments to it, maybe even edit it to propose changes, maybe even work on it together live? Pair programming accross the internet? Doesn't that make sense in the global world we live in with software teams spread accross the world? Working in the same environment I do other collaboration. A bugzilla front end in Wave is a natural, integrated with my source in Wave, a truely integrated development environment?
Given that as a vision for IDEs of the not so far away future, how does Eclipse fit in. We have so much invested in making Eclipse a good IDE, I'd hope to keep as much as I can. And I think we can, removing the UI front end, which would be handled in Wave, and providing services that provide access to all the good information that our indexers and such provide. Even providing access to remote build and test machines to complete the edit, build, debug cycle. I think there's a significant role for Eclipse there, and thanks to Jetty and the HTTP Equinox/OSGi service, we could do that today.
So that's my vision, long and short. In the short term, though, I need to keep customers happy and try and convince new customers that Eclipse is right for them. And that's where stability and quality are criticial. And that's where I'm coming from. I'm Walt Mossberg, uh never mind :).
Having written IDEs (not Eclipse) and a ton of tools, I'm an IDE guy too. I wonder if Eclipse has reached the end of the line as a code editing tool and it's time to let the app platform have its time in the sun.
ReplyDeleteI mean, we can keep tacking tools onto and tweaking workflows, but I think editing long source files may not be the future of software development. Could it be that we're back to VB 1, circa 1991? The "real" Visual Programming that we've been promised for 25 years since I started commercial work?
Nope. We still need an editor and tools that tack onto it. Maybe we fork Galileo as the IDE and let the "Application Platform" people do their thing with e4. I'm not begrudging them their needs, but maybe the amicable split is what we all need.
I'll stop typing now as my beliefs may not (and certainly do not) reflect those of my employer.
Well said EC. And maybe that's where it goes. But that's the fork I worry about. Is there enough investment in Eclipse to keep two platforms going?
ReplyDeleteBTW, my opinions in the blogosphere rarely reflect those of my employer, thus the statement at the top. But in this case, I think they do. At least on the e4 front.
Hi Doug. As you are probably aware, ECF is all about delivering on your vision of rt team collaboration seemlessly integrated with IDE tooling (in an open rather than proprietary way). For example, see Cola work for pair programming: http://live.eclipse.org/node/543. I think what's needed is for the EF corporate membership, e4 team, IDE tools vendors, and wider community to get behind ECF in support of your (and our) vision for IDE open collaboration...instead of persuing proprietary versions of same.
ReplyDeleteNot the central point of your post, but I don't think pair programming is as generally as appealing as "offline" code reviews, were author and reviewers work at different times.
ReplyDeleteIgnoring that many people can't do it and that most don't, pair programming requires people to synchronize their schedules, just as meetings, and that is a pain. Geographically distributed teams usually means time zone differences, and that makes it even harder.
Web-based code review tools these days (such as Crucible, which is amazing) already provide a great environment for collaboration in development. And with many of the benefits of pair-programming.
"But that's the fork I worry about. Is there enough investment in Eclipse to keep two platforms going?"
ReplyDeleteWas that an intentionally rhetorical question? Seeing as practically every project publicly acknowledges the "resources constraint" problem (ie, not enough people to get done all the pending work), it seems silly to think that Eclipse could survive a split. I happen to think it would behoove both sides to more severely split the app platform projects from the IDE projects, but I just don't see how it could work out in practical terms.
I often disagree with Doug's opinions and predictions (we have very different perspectives and motivators), but this is one thought that I find myself agreeing with wholeheartedly. When I see the e4 demos and blogs and New & Noteworthy lists, I think "that's pretty cool" immediately followed by "who's clamoring for this? What's the big commercial or user benefit?" I certainly could and should become involved to try to learn more, but it's not easy to garner the vision or other nebulous aspects of a huge project like e4 unless you've been in on the initial formation of those nebulous things. Perhaps some more blogging about that side of e4 would help settle the stomachs of those of us who are uneasy about the investment that's being made...
FWIW, I agree with rchaves that asynchronous collab is useful in many circumstances (web based and non web based), but IMHO there will never be a substitute/replacement for real-time communication (and collaboration)...whether it's called 'pair programming', 'group collaboration', 'google wave' or a 'phone call' :).
ReplyDeleteI agree with this post and the last two completely. Count me among those that do not understand e4 and worried about what it will mean for the future of the platform.
ReplyDeleteYou will pry my natively-run IDE from my cold, dead hands. Even then you are not safe, as I vow to rise from the dead and eat your flesh if you ever try.
ReplyDeleteDoug,
ReplyDeleteYou say you're worried about e4's impact and that you have a unique vision. Then you basically describe...e4's vision.
Enabling web-based tooling across the lifecycle requires re-architecting the platform in exactly the ways that the e4 team are doing. It requires separating the model from the UI and service-enabling the underlying platform. All goals of e4.
On the broader question of e4's impact, please remember that there is a very strong commitment to both 3.x stream longevity and backwards compatibility in e4. The ecosystem will have a very, very long time in which to continue on the 3.x stream.
In this world, if you do not innovate you die. I am awfully glad that the e4 team is working as hard as they are on exploring new innovations in the Eclipse platform.
Thanks, Mike. At the end of the day, with respect to e4, I am relaying the message from the CDT community. I started this by stating my fears. Others have commented since in agreement. I've been struck by how little disagreement there has been, outside of McQ and the Foundation staff. And yes, Eric Rizzo has blasted me in the past for statements I've made. His agreement means a lot to me.
ReplyDeleteWe can talk about what whether e4 really is innovation, or at least the right innovation. I think it's important for the community to really take a look and make a judgement. I know a few that have and have walked away scared. You should really be asking around to the technical experts and ensuring e4 really is doing what you hope. We did have a good discussion of this at the last Architecture Council. This shouldn't be a surprise.
As for my vision for web based IDE, I have not completed blogging my message. That will take a few posts. But to give a hint at the ending, Google's GWT provides a much better architecture for that than e4. And I think some of the community should be looking at it for the benefit of Eclipse, and not treat it as a threat.
Doug,
ReplyDeleteI agree with you. I too was blown away by the Wave demo. A smack upside the head with the realization that everything I'd been working on was suddenly old-school. E4 is good stuff, but it's derivative: it's not knock-your-socks-off innovation.
Without being too discouraging, I'll just say that a Wave-like IDE is not going to happen without resources (money) and that doesn't seem to be happening.
I look forward to reading and thinking about your ideas...
Thanks, Bjorn. You're right on the money. That's the feeling I'm getting. e4 isn't much new, just a better way of implementing the same thing, which does have it's merits.
ReplyDeleteBut in 5 years, the things will be changing. Wave and web-based collaboration environments could be driving those changes. The more we take advantage of Eclipse technologies in this new architecture, the more likely it will happen. But I'd pick GWT over e4 for the UI part.
Anyway, it'll only happen if it makes good business sense. And that's the real challenge.
But first, we need to understand what it is, and how it can benefit customers.
For some years (look for my question at http://cdtdoug.blogspot.com/2006/11/microsoft-novell.html) I keeping an eye on the Eclipse CDT waiting for the moment it will be usable in our developer team. All Java coding happens in Eclipse but for C/C++ we are until now working with the (dead) SNiFF+ IDE. CDT make big steps in version numbers but I see no real progress.
ReplyDeleteUntil today the CDT has an over sophisticated toolchain concept so there is no acceptable way for us to use it in a multi platform environment. We have the need to code today under Linux/gcc and to morrow to open the project under Windows to compile it with the Microsoft Compiler or under HP UX or under Tru64 Unix using the platform specific compilers.
What are the biggest problems in my opinion:
- The toolchain is a property of the project. This is simply wrong for C/C++. The tool chain should be the property of my workspace.
- The toolchain settings can only be done for certain projects, not for the workspace, why that?
Of course I can read the "Managed Build System Overview" document. For an "overview" it is lot of paper. And it is to much for doing some simple things i.e. t set some compiler options for all projects.
WindRiver bought TakeFive an let SNiFF+ die. Very pitty! SNiFF+ had a very strong and simple concept for multi platform developement. These concepts could be a better guide for a useful CDT. Simple is beautiful.
Thanks for the feedback, Jörg. I do multi-platform development using the CDT every day. Our Wind River Installer has some native code that runs on Windows, Linux, and Solaris. And I'm enjoying the experience.
ReplyDeleteThe trick though is not to use managed build, but use the power of GNU make in hand with Makefile projects. I'm planning on doing some screencast tutorials on how I do this and post them here. Stay tuned.
The good news is that the SNiFF team lives on and has contributed a lot to CDT, but, of course, their focus is on Wind River platforms now and you don't get to see much of their good work.
I beg your pardon but it is a very pure answer when I have to use a trick (!) doing multi-platform development. There are also other missing features in CDT as automatic generation of the include directories, automatic generation of the -L clauses for linking, dependency generation without GNU compiler. My proposal is to put the entire tool chain concept in the trash and let the SNiFF team completely redesign the build system using the simple and ingenious ideas from SNiFF+ (file types, platform as a workspace property describing the tool collection in a simple configuration file, automatic generation of dependencies and include directives based on project references etc.) I'm sure that the SNiFF+ people know what about I'm speaking.
ReplyDelete