Home » Eclipse Projects » Technology Project and PMC » Complexity growing
| Complexity growing [message #29514] |
Fri, 04 October 2002 12:22  |
Eclipse User |
|
|
|
Originally posted by: user.guest.no
Hi,
I'm fond of Eclipse but I've in mind some thought about the future of
Eclipse. It seems to me that the Eclipse framework grows quite fast (a
good thing) but this growing could also involve a growing of the
complexity. Is there not a hazard to build a too complicated
infrastructure, to try to build the hyper-meta-generic tool? Libraries
like EMS, XSD, and so on, are zwar interesting but they are also very
complicated and not tool-supported. I fear that community efforts be
disseminated in exploring all these new libraries, instead of focusing
their efforts on main useful primary goals like :
- db access
- GUI builder
- Jsp and xml editing
-...
(these are examples from my point of view)...
I think there is a question to ask for ; why so much people continue to
use tools like emacs, ultraedit, textpad, even if those tools are not so
powerful than Eclipse? IMO because they want a very light and
quick-to-launch tool... It is not either this kind of tool "xor" eclipse ;
I think it could be both... But we have to think about avoiding to build
today a developping plant by adding everyday a new module... It is
important to define today which kind of tool we want to target in the
future, and to be able to know if every our needs must be included in one
tool, or in a set of simple collaborative tools...
Axel
|
|
|
| Re: Complexity growing [message #30040 is a reply to message #29514] |
Sun, 06 October 2002 12:07  |
| Eclipse User |
|
|
|
Originally posted by: alf.ifb.bv.tu-berlin.de
I believe that the choosen architecture, where the whole platform is
actually
one (hopefully) small base system, with a bunch of plug-ins, is a good
approach
to keep complexity low. Users that want a small and fast eclipse may just
throw out all the plug-ins that they don't want. However eclipse will for
sure
never be as small and handy as an UltraEdit.
I am not afraid of growing complexity at all but rather impressed of the
quality and
stableness of eclipse, which is a result of this architecture and
organization.
So far the developement process seems to be under control, and nothing to
worry about.
However, looking at the already overwhelming number of available plug-ins,
it might be a good idea to ship eclipse in different distributions, like one
for the
Web-developer, one for the Java-developer and one for C++ and so on. There
might be other approaches of course, too ...
When looking at all the plug-ins it would also be nice to have an even
better
overview of all available plug-ins. Though, this will be a rather tough
task,
when having in mind all those different companies and organizations with
their different philosophies.
I am afraid that one will always have to try three or more XML editor
plug-ins
to actually find the one that fits his needs :-(.
Alf
"Axel" <user@guest.no> schrieb im Newsbeitrag
news:ank15g$7l6$1@rogue.oti.com...
> Hi,
> I'm fond of Eclipse but I've in mind some thought about the future of
> Eclipse. It seems to me that the Eclipse framework grows quite fast (a
> good thing) but this growing could also involve a growing of the
> complexity. Is there not a hazard to build a too complicated
> infrastructure, to try to build the hyper-meta-generic tool? Libraries
> like EMS, XSD, and so on, are zwar interesting but they are also very
> complicated and not tool-supported. I fear that community efforts be
> disseminated in exploring all these new libraries, instead of focusing
> their efforts on main useful primary goals like :
> - db access
> - GUI builder
> - Jsp and xml editing
> -...
> (these are examples from my point of view)...
> I think there is a question to ask for ; why so much people continue to
> use tools like emacs, ultraedit, textpad, even if those tools are not so
> powerful than Eclipse? IMO because they want a very light and
> quick-to-launch tool... It is not either this kind of tool "xor" eclipse ;
> I think it could be both... But we have to think about avoiding to build
> today a developping plant by adding everyday a new module... It is
> important to define today which kind of tool we want to target in the
> future, and to be able to know if every our needs must be included in one
> tool, or in a set of simple collaborative tools...
> Axel
>
|
|
|
| Re: Complexity growing [message #30066 is a reply to message #30040] |
Sun, 06 October 2002 19:52 |
| Eclipse User |
|
|
|
Originally posted by: axel.guest.no
Your comment is not actually so far from mine ;-) Maybe a solution should
be to have for main plugin a coordinator(OTI or a group of coordinating
people , including every developper) which defines some functional
requirements which could be implemented by everyone wants to implement
these requirements. Maybe for achievng this goal, could it be interesting
to have a place on the eclipse.org web site where writing these
requirements, discussind, deciding and prioritizing them. I think it is
needed to offer a frame to "strategic" developments for eclipse.
Another "idea" shoud be to offer a very simple and quick-to-launch editor
based upon eclipse.. The main difference should be not to open the whole
framework and plugins, but only to open an editor view on file selected in
the windows explorer for instance(so we should have a shortcut for that
;-) ). What is the interest of that ; to have minimal functionalities in a
very light editor. The goal of such an editor is not to replace the
eclipse workbench(which is needed for important development) but only to
offer to the developper to open quickly a file and edting it quickly too,
but also by providing the user by certain functionalities of eclipse like
local history, and file completion for instance....So we could achieve two
goals ; large development, and quick modification of a file...
Axel
Alf Schiefelbein wrote:
> I believe that the choosen architecture, where the whole platform is
> actually
> one (hopefully) small base system, with a bunch of plug-ins, is a good
> approach
> to keep complexity low. Users that want a small and fast eclipse may just
> throw out all the plug-ins that they don't want. However eclipse will for
> sure
> never be as small and handy as an UltraEdit.
> I am not afraid of growing complexity at all but rather impressed of the
> quality and
> stableness of eclipse, which is a result of this architecture and
> organization.
> So far the developement process seems to be under control, and nothing to
> worry about.
> However, looking at the already overwhelming number of available plug-ins,
> it might be a good idea to ship eclipse in different distributions, like one
> for the
> Web-developer, one for the Java-developer and one for C++ and so on. There
> might be other approaches of course, too ...
> When looking at all the plug-ins it would also be nice to have an even
> better
> overview of all available plug-ins. Though, this will be a rather tough
> task,
> when having in mind all those different companies and organizations with
> their different philosophies.
> I am afraid that one will always have to try three or more XML editor
> plug-ins
> to actually find the one that fits his needs :-(.
> Alf
> "Axel" <user@guest.no> schrieb im Newsbeitrag
> news:ank15g$7l6$1@rogue.oti.com...
> > Hi,
> > I'm fond of Eclipse but I've in mind some thought about the future of
> > Eclipse. It seems to me that the Eclipse framework grows quite fast (a
> > good thing) but this growing could also involve a growing of the
> > complexity. Is there not a hazard to build a too complicated
> > infrastructure, to try to build the hyper-meta-generic tool? Libraries
> > like EMS, XSD, and so on, are zwar interesting but they are also very
> > complicated and not tool-supported. I fear that community efforts be
> > disseminated in exploring all these new libraries, instead of focusing
> > their efforts on main useful primary goals like :
> > - db access
> > - GUI builder
> > - Jsp and xml editing
> > -...
> > (these are examples from my point of view)...
> > I think there is a question to ask for ; why so much people continue to
> > use tools like emacs, ultraedit, textpad, even if those tools are not so
> > powerful than Eclipse? IMO because they want a very light and
> > quick-to-launch tool... It is not either this kind of tool "xor" eclipse ;
> > I think it could be both... But we have to think about avoiding to build
> > today a developping plant by adding everyday a new module... It is
> > important to define today which kind of tool we want to target in the
> > future, and to be able to know if every our needs must be included in one
> > tool, or in a set of simple collaborative tools...
> > Axel
> >
|
|
|
| Re: Complexity growing [message #584145 is a reply to message #29514] |
Sun, 06 October 2002 12:07 |
 Alf Schiefelbein
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
I believe that the choosen architecture, where the whole platform is
actually
one (hopefully) small base system, with a bunch of plug-ins, is a good
approach
to keep complexity low. Users that want a small and fast eclipse may just
throw out all the plug-ins that they don't want. However eclipse will for
sure
never be as small and handy as an UltraEdit.
I am not afraid of growing complexity at all but rather impressed of the
quality and
stableness of eclipse, which is a result of this architecture and
organization.
So far the developement process seems to be under control, and nothing to
worry about.
However, looking at the already overwhelming number of available plug-ins,
it might be a good idea to ship eclipse in different distributions, like one
for the
Web-developer, one for the Java-developer and one for C++ and so on. There
might be other approaches of course, too ...
When looking at all the plug-ins it would also be nice to have an even
better
overview of all available plug-ins. Though, this will be a rather tough
task,
when having in mind all those different companies and organizations with
their different philosophies.
I am afraid that one will always have to try three or more XML editor
plug-ins
to actually find the one that fits his needs :-(.
Alf
"Axel" <user@guest.no> schrieb im Newsbeitrag
news:ank15g$7l6$1@rogue.oti.com...
> Hi,
> I'm fond of Eclipse but I've in mind some thought about the future of
> Eclipse. It seems to me that the Eclipse framework grows quite fast (a
> good thing) but this growing could also involve a growing of the
> complexity. Is there not a hazard to build a too complicated
> infrastructure, to try to build the hyper-meta-generic tool? Libraries
> like EMS, XSD, and so on, are zwar interesting but they are also very
> complicated and not tool-supported. I fear that community efforts be
> disseminated in exploring all these new libraries, instead of focusing
> their efforts on main useful primary goals like :
> - db access
> - GUI builder
> - Jsp and xml editing
> -...
> (these are examples from my point of view)...
> I think there is a question to ask for ; why so much people continue to
> use tools like emacs, ultraedit, textpad, even if those tools are not so
> powerful than Eclipse? IMO because they want a very light and
> quick-to-launch tool... It is not either this kind of tool "xor" eclipse ;
> I think it could be both... But we have to think about avoiding to build
> today a developping plant by adding everyday a new module... It is
> important to define today which kind of tool we want to target in the
> future, and to be able to know if every our needs must be included in one
> tool, or in a set of simple collaborative tools...
> Axel
>
|
|
|
| Re: Complexity growing [message #584158 is a reply to message #30040] |
Sun, 06 October 2002 19:52 |
| Eclipse User |
|
|
|
Originally posted by: axel.guest.no
Your comment is not actually so far from mine ;-) Maybe a solution should
be to have for main plugin a coordinator(OTI or a group of coordinating
people , including every developper) which defines some functional
requirements which could be implemented by everyone wants to implement
these requirements. Maybe for achievng this goal, could it be interesting
to have a place on the eclipse.org web site where writing these
requirements, discussind, deciding and prioritizing them. I think it is
needed to offer a frame to "strategic" developments for eclipse.
Another "idea" shoud be to offer a very simple and quick-to-launch editor
based upon eclipse.. The main difference should be not to open the whole
framework and plugins, but only to open an editor view on file selected in
the windows explorer for instance(so we should have a shortcut for that
;-) ). What is the interest of that ; to have minimal functionalities in a
very light editor. The goal of such an editor is not to replace the
eclipse workbench(which is needed for important development) but only to
offer to the developper to open quickly a file and edting it quickly too,
but also by providing the user by certain functionalities of eclipse like
local history, and file completion for instance....So we could achieve two
goals ; large development, and quick modification of a file...
Axel
Alf Schiefelbein wrote:
> I believe that the choosen architecture, where the whole platform is
> actually
> one (hopefully) small base system, with a bunch of plug-ins, is a good
> approach
> to keep complexity low. Users that want a small and fast eclipse may just
> throw out all the plug-ins that they don't want. However eclipse will for
> sure
> never be as small and handy as an UltraEdit.
> I am not afraid of growing complexity at all but rather impressed of the
> quality and
> stableness of eclipse, which is a result of this architecture and
> organization.
> So far the developement process seems to be under control, and nothing to
> worry about.
> However, looking at the already overwhelming number of available plug-ins,
> it might be a good idea to ship eclipse in different distributions, like one
> for the
> Web-developer, one for the Java-developer and one for C++ and so on. There
> might be other approaches of course, too ...
> When looking at all the plug-ins it would also be nice to have an even
> better
> overview of all available plug-ins. Though, this will be a rather tough
> task,
> when having in mind all those different companies and organizations with
> their different philosophies.
> I am afraid that one will always have to try three or more XML editor
> plug-ins
> to actually find the one that fits his needs :-(.
> Alf
> "Axel" <user@guest.no> schrieb im Newsbeitrag
> news:ank15g$7l6$1@rogue.oti.com...
> > Hi,
> > I'm fond of Eclipse but I've in mind some thought about the future of
> > Eclipse. It seems to me that the Eclipse framework grows quite fast (a
> > good thing) but this growing could also involve a growing of the
> > complexity. Is there not a hazard to build a too complicated
> > infrastructure, to try to build the hyper-meta-generic tool? Libraries
> > like EMS, XSD, and so on, are zwar interesting but they are also very
> > complicated and not tool-supported. I fear that community efforts be
> > disseminated in exploring all these new libraries, instead of focusing
> > their efforts on main useful primary goals like :
> > - db access
> > - GUI builder
> > - Jsp and xml editing
> > -...
> > (these are examples from my point of view)...
> > I think there is a question to ask for ; why so much people continue to
> > use tools like emacs, ultraedit, textpad, even if those tools are not so
> > powerful than Eclipse? IMO because they want a very light and
> > quick-to-launch tool... It is not either this kind of tool "xor" eclipse ;
> > I think it could be both... But we have to think about avoiding to build
> > today a developping plant by adding everyday a new module... It is
> > important to define today which kind of tool we want to target in the
> > future, and to be able to know if every our needs must be included in one
> > tool, or in a set of simple collaborative tools...
> > Axel
> >
|
|
|
Goto Forum:
Current Time: Thu Apr 25 00:56:20 GMT 2024
Powered by FUDForum. Page generated in 0.03224 seconds |
] 
Search
Help
Register
Login
Home
