Money quote: "Comparing eclipse to [NetBeans, IntelliJ, .NET...] is like comparing apples to a bowl of fruit and a deli" - Me
The whole 80/20 (80% of users use only 20% of the functions) thing has been hashed to death on the web. The upshot is, as you point out, that everybody's 20% is different, leading to -apparent- bloat. This is even more true when we truly cross application domains; BIRT & WTP are fundamentally different animals and WTP in particular can involve cutting a fairly wide swath through the development stack...a little java, some java script, some database development, lotsa HTML/CSS editing and some Ant glue (and debugging support for all of it). Also, we should differentiate between install/disk size and running footprint see here for reasons why the disk size doesn't matter anymore (and the download size is quickly becoming as irrelevant except, as Kim's just pointed out, for wireless folks) If we can somehow manage to keep the -in memory- footprint down (with the corresponding decrease in load times) we're way better off than simply cutting large chunks out of the final deliverable (we could save lots of disk space simply by cutting various projects from Ganymede...which ones?). Note that we arguably have more experience in dealing with this particular issue than anybody else in the world.; 'lazy loading' is our religion, forced upon us by necessity. At one level it's a fairly straightforward granularity issue; how do I get access to -my particular- 20% without incurring the *run time* cost of the rest? Some astute refactoring -might- be able to mitigate this; at one end of the spectrum is an environment where every extension is defined in its own plug-in, at the other is a complete tooling stack in a single plug-in. We're currently somewhere in the middle (of course...;-) but perhaps we're not at the right place. There are also a number of coding practices/patterns that can be used to limit the amount of 'fat' (extra stuff not associated with your particular feature) that you incur when loading the bits necessary to support your desired operation. Perhaps, if we were to define a metric, the BMI (in this case the Bloat Mass Index...;-) that gave a ratio for each functionality bit and *publish* them then at least developers would become more aware that keeping footprint down is something that all projects must work on. Finally there's the question of caching. Loading cached info, while it affects both the load time and memory footprint, it is sometimes necessary in order to provide a responsive UI, particularly in large workspaces. Of course it they're loaded unnecessarily then they constitute 'fat'... Off in dreamland would be an environment in which the plug-ins for currently unused features are aggressively unloaded, root and branch. This would mean that if I opened and ran a BIRT report (i.e. my daily bug list) and subsequently closed it then eclipse would dynamically unload any related plug-in(s). This would get us out of our current 'high water mark' approach where the footprint continually grows but never shrinks... I too would like to be able to -quickly- fire up eclipse to accomplish a task and shut it down...the startup times for Word and PPoint are essentailly sub-second on my box but eclipse takes...um...significantly more time. Onwards, Eric "Kenneth Westelinck" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/20/2008 02:31 AM Please respond to E4 developer list <[email protected]> To [EMAIL PROTECTED], "E4 developer list" <[email protected]> cc Subject Re: [eclipse-incubator-e4-dev] Some food for thought I remember James Gosling telling in a keynote on Java Polis about Java NetBeans, that Emacs was a good IDE ... 20 years ago :-) Of course you could develop Java code in Textmate. You could even write code in Notepad or VI if you want. True, over the years, Eclipse has become bloated with features that _maybe_ no one really uses anyway. Over the years, the memory footprint of Eclipse has become larger and larger. Especially when doing large projects with a lot of seperate modules. I definetely use Eclipse for more than just it's code completion or ease of refactoring. It is a whole development environment to test and debug web applications for instance. I am not sure how you would debug code and inspect variables from a tool like Textmate or Notepad. Intellij on the other hand feels a lot more snappier then Eclipse and requires a smaller memory footprint. My colleagues at work often have 2 or 3 Intellij instances running at the same time, I haven't even tried to do this with Eclipse :) The availability of plugins and Eclipse, like Textmate or Emacs, being verry extensible is also one of the reasons why I'm using Eclipse. Since all the projects I am working on are using Spring / Hibernate, I find the availability of tools like SpringIDE indispensable. In the past I have also done .NET projects, requiring me to use _their_ IDE, being VisualStudio. VisualStudio has less more features than Eclipse, In fact, at the time I was using it, VisualStudio 2003 probably had lesser features than Eclipse 2.0 :) Like Eclipse, VisualStudio requires a large memory footprint, but not being extendable in any way (or maybe the ResharperPlugin) and lacking the most basic stuff like refactoring. But Eclipse, maybe unfortunate for some of us, is much more than an IDE. It is a platform you can use to build your own applications. Netbeans is trying to do the same thing, but I haven't found any Netbeans RCP applications out there (maybe I am not looking). The platform serves me well to develop RCP applications. But, as already noted on this mailing list, there are 3 or more ways to implement this or that. Tables and their editors is an example of this. So, to conclude, Eclipse indeed looks very bloated and maybe too feature rich, but I'm not sure there are a lot of features that can be left out. The most important things that need attention in e4, for me, are: - smaller footprint for RCP applications - not having 3 or more ways to do stuff in JFace, probably breaking backwards compatibility, but who cares - a better and snappier debugger (like Intellij's) - integration with Maven2 On Fri, Jun 20, 2008 at 1:31 AM, Mike Milinkovich < [EMAIL PROTECTED]> wrote: Two interesting and thoughtful blog posts from developers who have [1] left Eclipse for TextMate and loves it and [2] from someone who points out that few developers use all of the functionality provided. Money quote: The simplicity of the application and the ease of its extensibility is too inviting to ignore and I'm very excited about seeing how far I can push this little editor. It's beautiful, lightweight and speedy?attributes that weren't associated with my old Eclipse IDE. They may be unscientific data points, but they are also thoughtful and reasonable points of view. I am still personally hoping the IDE portion of E4 is targeted at being Faster. Smaller. Simpler. [1] http://particletree.com/features/eclipse-to-textmate-an-ideological-change/ [2] http://www.ericdelabar.com/2008/06/hammering-screws.html Mike Milinkovich Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 [EMAIL PROTECTED] _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
