[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] Re: [cdt-debug-dev] My annual rant about why refactoring and C/C++ indexing sucks
|
Oyvind,
I am packaging both messages together and forwarding it to the CDT
developers list:
In my experience CDT fails miserably to be adopted as an IDE when
compared to
Eclipse JDT.
I've seen that CDT is quite successful in getting adopdated as GDB GUI.
First some observations(from embedded developers point of view) and then
some
speculation about what's going on:
- Focus is a lot of the time on hardware issues: voltage supplies,
phase lock loops, high-frequency signalling issues, power consumption,
part cost, etc. Some time is left over for software issues: choice of
embedded operating system(if any), writing or selecting drivers for
hardware
parts, etc. The application itself is oftentimes not very big. How
much can you fit into 10-100k's of RAM anyway? :-) Java is probably
nowhere on their radar before encountering Eclipse CDT.
- Users get angry and frustrated about Eclipse CDT "freezing up"
and being "really slow". Some manage to make the connection that they
are being hosed by CDT C/C++ indexing that is slowing down the
machine.
The first reaction is "how do I turn it off?". When using CDT as a
debugger
there is no need to enable C/C++ indexing. Also regressing to
Insight is common. Insight *really* sucks, so this forces them kicking
and screaming to reconsider CDT as a GDB GUI.
- Refactoring is a MASSIVE undertaking in C/C++. Even more so than in
Java.
It's the only human artifact visible with the naked eye from space :-)
Java developers who also do C++ are all hot and bothered about this,
but
embedded developers who *barely* do C++(they are used to CPU's which
use
10-100kBytes of RAM), refactoring is just lightyears away from what
interests them.
- Programs are built using existing build systems. Eclipse CDT will not
influence the decisions on how programs are built. CDT managed build
is
not on the radar in any form or shape. Developers *might* be
interested
if CDT has some simple way of allowing existing build systems to be
invoked from CDT. E.g. running make, eCos build programs,
automake(Linux),
etc.
- Eclipse itself is very intimidating. This ranges from navigating the
Eclipse web-pages to understanding which plugins that need to be
installed,
installing Java in the first place, understanding perspectives,
possibly
first exposure version control/CVS, etc.
Some open questions:
- Is it a goal of CDT to get embedded developers to adopt CDT?
- Does CDT care whether or not C/C++ indexing is used as long
as CDT otherwise gets adopted?
- Does CDT care whether or not CDT is involved in the build
process as long as CDT is otherwise used?
- Does CDT care whether or not CDT is being used for editing,
refactoring, etc. as long as CDT is otherwise used?
Some (my) conclusions:
Assuming it is a goal to get as many embedded developers on board
as possible, I think the following would be effective:
- Package CDT as Insight killer. This will be the minimum threshold,
first encounter to CDT. Ultimately this requires CDT packaged as
a GDB GUI frontend without C/C++ indexing, CDT project build
capabilities,
etc. with a standard Windows installer. Probably it would be a good
idea to include the Java JRE in the Windows installer package.
Package Eclipse CDT as an RCP app. This problem is being attacked
from several fronts(at least a dozen PR's are open and several of
them are being actively worked on).
- Stop trying to convince developers to use CDT to build their
applications. This is a dead end. Instead treat developers existing
build procedures as first class citizens. Abandon the CDT project
concept and add a capability to invoke existing build scripts and
capture output(to pick up errors) + capability to terminate build.
CDT can most humbly be told basically three things:
1. Where to find the source for the purpose of editing it and looking
up relative paths
2. How to invoke the build procedure(oftentimes as simple as executing
"make" with pwd in a particular place)
3. Where to find the output(oftentimes the .elf files).
Øyvind
----- Original Message -----
From: <oyvind.harboe@xxxxxxxxx>
To: <cdt-debug-dev@xxxxxxxxxxx>
Sent: Thursday, March 23, 2006 3:06 AM
Subject: [cdt-debug-dev] My annual rant about why refactoring and C/C++
indexing sucks
In my experience CDT fails miserably to be adopted as an IDE when
compared to
Eclipse JDT.
I've seen that CDT is quite successful in getting adopdated as GDB GUI.
First some observations(from embedded developers point of view) and then
some
speculation about what's going on:
- Focus is a lot of the time on hardware issues: voltage supplies,
phase lock loops, high-frequency signalling issues, power consumption,
part cost, etc. Some time is left over for software issues: choice of
embedded operating system(if any), writing or selecting drivers for
hardware
parts, etc. The application itself is oftentimes not very big. How
much can you fit into 10-100k's of RAM anyway? :-) Java is probably
nowhere on their radar before encountering Eclipse CDT.
- Users get angry and frustrated about Eclipse CDT "freezing up"
and being "really slow". Some manage to make the connection that they
are being hosed by CDT C/C++ indexing that is slowing down the
machine.
The first reaction is "how do I turn it off?". When using CDT as a
debugger
there is no need to enable C/C++ indexing. Also regressing to
Insight is common. Insight *really* sucks, so this forces them kicking
and screaming to reconsider CDT as a GDB GUI.
- Refactoring is a MASSIVE undertaking in C/C++. Even more so than in
Java.
It's the only human artifact visible with the naked eye from space :-)
Java developers who also do C++ are all hot and bothered about this,
but
embedded developers who *barely* do C++(they are used to CPU's which
use
10-100kBytes of RAM), refactoring is just lightyears away from what
interests them.
- Programs are built using existing build systems. Eclipse CDT will not
influence the decisions on how programs are built. CDT managed build
is
not on the radar in any form or shape. Developers *might* be
interested
if CDT has some simple way of allowing existing build systems to be
invoked from CDT. E.g. running make, eCos build programs,
automake(Linux),
etc.
- Eclipse itself is very intimidating. This ranges from navigating the
Eclipse web-pages to understanding which plugins that need to be
installed,
installing Java in the first place, understanding perspectives,
possibly
first exposure version control/CVS, etc.
Some open questions:
- Is it a goal of CDT to get embedded developers to adopt CDT?
- Does CDT care whether or not C/C++ indexing is used as long
as CDT otherwise gets adopted?
- Does CDT care whether or not CDT is involved in the build
process as long as CDT is otherwise used?
- Does CDT care whether or not CDT is being used for editing,
refactoring, etc. as long as CDT is otherwise used?
Some (my) conclusions:
Assuming it is a goal to get as many embedded developers on board
as possible, I think the following would be effective:
- Package CDT as Insight killer. This will be the minimum threshold,
first encounter to CDT. Ultimately this requires CDT packaged as
a GDB GUI frontend without C/C++ indexing, CDT project build
capabilities,
etc. with a standard Windows installer. Probably it would be a good
idea to include the Java JRE in the Windows installer package.
Package Eclipse CDT as an RCP app. This problem is being attacked
from several fronts(at least a dozen PR's are open and several of
them are being actively worked on).
- Stop trying to convince developers to use CDT to build their
applications. This is a dead end. Instead treat developers existing
build procedures as first class citizens. Abandon the CDT project
concept and add a capability to invoke existing build scripts and
capture output(to pick up errors) + capability to terminate build.
CDT can most humbly be told basically three things:
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
