Re: [eclipse-incubator-e4-dev] Some food for thought

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

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 _javascript_, 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" <kenneth.westelinck@xxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

06/20/2008 02:31 AM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	mike.milinkovich@xxxxxxxxxxx, "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
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 <mike.milinkovich@xxxxxxxxxxx>
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

mike.milinkovich@xxxxxxxxxxx

 

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev