on Feb 8th, 2010My thoughts on eclipse e5
Let’s assume for the moment, that in an alternate reality I can travel back in time to 2008. Once there, I meet a bright bunch of people that work on something called e5 (executive summary.odp). My summary:
“the runtime platform that is simple and appealing to _____ application developers”
Here’s what I would say to them:
e5 should take risks
When I became interested in Eclipse it was cool and disruptive. A real game changer. It is now the established tooling platform and understandably locked into perpetual refinement mode (Entrenched Player’s Dilemma). Make sure that e5 is equally game changing. Otherwise we are setting ourselves up to be disrupted.
At the EclipseCon 2008 we committed a “strategic sin”. We agreed that e4 would be compatible with 3.x. This limited the potential for e4 by forcing it to be something that is “in the box” vs. “outside the box”.
(taken from Death by risk-aversion by Kathy Sierra)
For e5 to be successful it needs to take risks. I don’t think that we need a better tooling platform. We already have a very good one with 3.x. And it’s still improving and not going away. Instead we need a runtime that provides something unique and remarkable. It must kick-ass in a new way.
e5 needs a driver
If you try to be everything to everybody, you will at best be mediocre at everything. e5 should be laser focused on being the best runtime for ___________ developers.
People tend to avoid specialization. It is perceived as a risk. However, if you ask a marketing person he / she will tell you that specialization is good. It’s your way to get noticed. It’s your foot in the door. You build a niche, become unbeatable and expand. Eclipse 3.x first became the tooling platform of choice, then client platform of choice for Java devs, then the modeling technology of choice for Java devs.
Unfortunately e4 lacks a driver that would help it specialize and focus. A driver, like the JDT was for the Platform. As far as I know, there is no major product build on top of e4. I believe that the current e4 (Feb 2010) is not yet appealing enough for web development or client development. It will not lure web-side Java developers away from Spring / J2EE / GWT. Or client-side Java developers away from RCP. Or Javascript folks away from jQuery / Prototype / Dojo. Or Rubyists away from Rails.
It is hard to pick the right driver. I don’t want to attempt providing an answer and limit your thinking. But feel free to share your thoughts in the comments.
e5 must be easy to learn & master
If you believe Eclipse 3.x is easy to get into, attend a beginner’s training. You will see how experienced Java developers struggle with the learning curve. And it’s not becoming easier with e4.
That is a problem, because it limits the mass appeal of Eclipse as a runtime solution. If you think it is a popular runtime, go to a Java User Group and see how few of the people who use Eclipse have written a plug-in for it.
It is in our human nature, that we tend to take the path that has the least resistance (read: easy) not the path that offers the most rewards (read: complex technology).
For e5 to be broadly successful it must kick-ass AND be easy to learn & master.
Looking forward to your comments,
Elias.
Related posts:
I replied on http://tomsondev.bestsolution.at/2010/02/09/e4-why-you-dont-need-e5/
please consider adding the following things to Eclipse:
1.during debugging , when mouse hover over a variable , show its value.also show a value of an expression which is marked by the mouse .
2.allow more options for portability of the program, including setting the workspace and settings to relative folders, saving/loading of settings,…
3.update the javadoc for a lot of missing classes and methods, and put links in them too.
4.allow versions tracking, by having a comment block in the beginning of each file which each line in it has information of the time the file was modified (first line is the most updated, so that it could fold into just the first line) .
5.make it easier to develop in C++ . currently, everyone needs something to install in addition for the C++ CDT, in order for developing in C++ (like mingw) . allow us to choose an option to install via Eclipse itself, so that we won’t need to go through this annoying process. also allow it to be portable (at least for same OS) .
6.allow “region” tags like on C# , so that we could fold areas of code which belong to different things. for example , if we have some fields which belong to graphical stuff we put them in a graphical region, and the rest in logical region. since Java doesn’t have this feature (at least not yet) , we could use a comment usage for this, for example:
/**region: graphics*/
…
/**endregion*/
7.make a (short and easy version of) RCP wizard.
8.allow to navigate between tabs via hotkeys (like CTRL+TAB) .
9.allow to zoom in and out of the text code, using CTRL+mouse wheel.
10.when debugging, if the line includes multiple expressions, do not go over all of them. instread, mark the expression currently worked on by the program, and allow us to go over each of the expressions. for example:
if(x>3 && y3″ , then , if it’s true and we continue stepping, the expression “y<2" is marked, and if that's true, the print function is marked .
this way it's easier to follow the order of things, and also easier to find bugs.
11.when exiting from a function/method , show what was the returned value of it.
12.add a special mode for the debugger, which shows a user-specified data structure in a graphical way . i mean that if you created (for example) your own kind of List, and you wish to see for yourself that it seems ok, you choose the head field of the list, and the debugger will show you in a graphical way all of the nodes from the head to the tail in a horizontal way.also, if you wish to see that removing/adding is performed well, you can monitor the references of the method/function that does it, and this way you will see arrows that point to the correct nodes .
this is very useful for sophisticated data structures, since the current debugger is hard to work with for this kind of problems.
oh, and almost forgot, please consider buying the Window-Builder plugin , so that everyone could use it.
this is a very essential tool for GUI-creation, and is far better than any other GUI creation plugin out there.
@someone:
point 4: It is just cluttering and blowing up your sources unnecessarily. You have a version control, use it’s history to track versions. Why have it in the sourcecode?
If you really want that bloat in your sources, why ask for Eclipse to do that? Why not use CVS’ keyword substitution? Place /*$Log$*/ as your first or last line of sourcecode and let CVS replace it with your version history.
point9: You should consider adjusting your font to a size you can actually read.
Also I think Elias was rather talking about Eclipse as a platform, not as an an IDE.
Great post, Elias. These are indeed the two main problems of the Eclipse 3.x platform:
Focus on desktop applications: Sure, we have the RAP project, but a central focus on dual sourcing (desktop&web) that e4 promises looks like a very good thing.
Steep learning curve: It’s a complex platform which requires lots of documentation. That’s why sometimes it’s difficult to find up-to-date information about various features. There should be a simplified and extremely well documented layer on top of the existing API that would make it very easy to develop basic plugins and applications. Something that a regular Java developer can pick up and master in a short time. I think that the application model in e4 is a good start in this direction because it offers a centralized representation of the application structure.
I admit that I don’t follow closely the e4 project (and many don’t – another problem here), but I follow various pieces of information available through blog posts, so my understanding might be lacking in some areas. However, if e4 would make it easy to create rich Web applications in a very productive manner, it could establish itself in the enterprise space currently dominated by the Spring/GWT/JSF stacks.
Unfortunately the suitability of e4 for developing Internet applications is limited seriously by Java’s failure in small scale hosting. Can I easily and cheaply deploy a Java application on the Internet? Trust me, not really and most certainly not even close to the options available for deploying scripting language apps. There’s the Google AppEngine though, but that one needs special design requirements to use the Google APIs, especially storage. Hmm, maybe a special deal between the Eclipse Foundation and Google could make things easier though.
@someone else :
about point 4 : it’s not cluttering the code since it’s a comment block.it won’t do anything to the code.
plus , since it’s a block, it can be folded by default, showing only the first line which shows the current version.
about point 9:i know changing font is possible, but the thing is that it’s much less comfortable than using a simple CTRL+mouse wheel .
about Eclipse as a platform, i don’t get it. what is the plan of making Eclipse to? i mean, shouldn’t Eclipse be better as an IDE too? where can i suggest those suggestions ?
I think part of e4 should be a tool which shows which parts of the API are really in use. With that information, all the old cruft (which almost no one uses anymore) can be identified and cut away. Since Eclipse has all these great AST tools, it should be pretty simple to supply a tool which replaces the old API with the new one (either by adding TODOs or just fixing the code).
I really dislike the myth of “throw everything away and start over from scratch”. A lot of knowledge went into the 3.x code and you’ll throw that away too. That you “learned a lot and can do better now” is a myth, too: It will take almost the same time to build most of the old functionality again from scratch because you will have forgotten a lot since you wrote that code, too — the human brain is not without limits and just because you can forget code that you have already written and tested doesn’t mean you can remember how you write it and why.
Therefore, it’s almost always less effort to add tests to the old, crappy code and then polish it than to write it again from scratch.