Re: [cdt-core-dev] Call for Input For CDT Fall Conference: CDT Usability

[John K <johnk_dev@xxxxxxxxx>]

Martin & group,

I'm a newbie to Eclipse, and I think I have a lot of
comments and input based on my first experience. 
Unfortunately, I think there are too many to list. 
Also, I think most of them are attributed to my lack
of knowledge of GCC, Unix style shells, command line
compiling, Java, makefiles, and all of the other
things that aren't found in any Windows-based IDE's
that I've used.  I have to believe there are many more
developers out there with a background similar to
mine.

Overall, I'm very excited about the idea of Eclipse. 
I'm using it right now to customize the CDT to use our
custom toolchain and debug tools, so we can leverage
off of all the other powerful Eclipse IDE plug-ins. 
Then we can concentrate on the nuts and bolts of our
platform rather than a formatter, editor, project
manager, etc.

Instead of having me type a laundry list of specific
comments, I'll try to concentrate on my overall
impressions, and how I see Eclipse gaining "market
share" and support.  So let's all take a step back -
what I see is that there are at least two different
mindsets when it comes to developing software:

The first is "mine" - double-click an icon to open
your IDE, write your code, click the "compile" button,
and you've got a piece of software you can sell to Joe
Shmoe User.  

The second is "yours" (not meant to be insulting, but
in general, this is my impression of all the
developers in the *-nix and open-source world) -
install Linux or a bash shell, spend hours and hours
configuring your environment, read a ton of man pages,
use a text editor like vi to write the code, create a
makefile, learn Perl for the heck of it, build the
project, discover a bug in the compiler, create a
patch, figure out how to use CVS, submit the patch to
the open source community, re-compile, and finally
you've got a piece of software you can only give away
to other developers exactly like yourself (it's way
too complicated for Joe Shmoe User to even attempt to
use).  And you also only give away the source and
binaries for *-nix, not Windows.  On top of all that,
there's a completely different lingo/language of words
and acronyms used that nobody but yourselves can
understand.

To illustrate it another way, there are the people who
read slashdot regularly, and there are people who
can't understand 2 words of what's on slashdot.

My general impression of Eclipse is that all you've
done is strapped a GUI on the second mentality that I
described above.  Out of the box, Eclipse takes weeks
to figure-out for a Microsoft-molded developer like
me.  People like me have had their hands held by
pretty user friendly GUIs that hide all the big-bad
details.  This is where I feel Eclipse is not getting
the support and following that it could be getting. 
It's not something "most" developers understand or
have the patience to spend weeks figuring out.

BTW - everyone that I've talked to in "my world" ever
since I started looking at Eclipse hadn't even heard
of it.

Prior to trying to use Eclipse, for example, I had
never heard of the following things, just to name a
few: Build-file Generator, Dependency Calculator, Ant,
Refactor, Working Set, Launcher, Make Target, Binary
Parser, Error Parser, Project References, CVS, C/C++
Indexer, Artifact.  I had heard of makefiles before,
but up until a month ago, I had never seen one.  Other
IDEs don't use/reference all this stuff and it's
enough to scare users of those IDEs away from Eclipse.
 I know there are a lot of developers like me out
there - I'd say that 95% of my developer friends,
co-workers, customers, etc. are like me.  I'm sure
that 95% of your acquaintances are like you.  So - how
can we merge the two worlds??  

I'm not going to try answering that question here and
now, but hopefully it's food for thought.  That's what
I believe Eclipse is up against.

Just in case at this point you're thinking: "who is
this noob? he's probably a lousy coder! I'm
embarrassed to hear that he calls himself a
developer!", in my defense, I have a recent MSE from a
top 5 university and aced my programming classes. 
When it comes to understanding "your world", I'll
admit, I suck.  I've never had a reason to enter your
world until now.

I do have some comments that come to mind regarding
the CDT Usability.

** Embedded/Remote Targets - I'm currently in the
embedded tools/products market, and it's clear that
Eclipse is tailored for host side apps.

** Documentation - I have diligently read most of the
documentation for Workbench, PDE, CDT, & CDT Plug-in
Dev *twice*, and in general, I'm still lost.  It
assumes a lot of background knowledge from "your
world".

** Specifications - I recently read a post where
someone asked if there was a spec for the CDI and the
response was along the lines of, "no - you have look
at the source for how gdb is implemented".  This just
*baffles* my mind.  How can a group of distributed
developers create a generic API that is intended to be
applied to any & all current & future debuggers
*without* a spec?  Maybe there is just some magic
concept of open-source development that I don't
understand.  Or maybe this is part of the reason why
it isn't easy to integrate a non-gdb debugger with
Eclipse?

** MBS - For my personal needs, it seems that
everything I don't want/need to deal with is
configurable and everything that I *do* need to
configure is buried in a deep dark corner or it's
locked down and assumed that everyone wants it that
way.  

For example, in a project's "Properties" page, in our
vision of our final Eclipse "product" for our
toolchain, almost all of the things on the left-hand
side of of the properties window (Info, Builders,
Documentation, File Types, Indexer, Project
References) are of no use to us.  What we'd rather see
is all of our custom toolchain Option Categories out
there, not buried down inside one little "Tool
Settings" tab inside "C/C++ Build".

Also, the concept of "Configurations" is something we
have no use for.  Never have and don't see how we
could.  Yet the MBS forces us to specify a
"Configuration", and it forces a certain project
structure on us based on the selected configuration -
i.e. it automatically creates "Debug" and "Release"
directories and places the makefiles and output
binaries there.  I think a better concept is that of
"Targets" rather than "Configurations", where you can
specify a sourcepool of code modules for each target
and set build/compile options for each individual
target.  Within one project you could have a .lib
target and 3 different kinds of .exe targets, all of
which share the same sourcepool of code.  You should
also be able to set destination directories for
intermediate files and final binaries, or set one
target with debug options and another with release
options.  Maybe there's a way to configure this stuff,
but all I know is that after a couple of months, I
still haven't found it.

Last one, for a user to create a new project for our
toolchain, they need to follow: File -> New -> Managed
C Project (or Managed C++ Project) -> Then pick our
project type from a bunch of useless GNU project
types.  I haven't figured out how yet (so if it's
possible, my comment = it's not easy to do), but I
want to remove all of the GNU stuff since it will just
confuse the majority of our customers.  But
furthermore, MBS should allow my custom project type
to be created directly from File -> New -> MY C/C++
PROJECT.  The whole idea of Standard vs. Managed and
even having C separate from C++ is far from intuitive.

Summary for MBS - I want my customers to have an easy
time using our Eclipse-based toolchain.  That means
they should be able to sit down and create a new
project without having to read extensive
documentation.  Intuition should be able to lead them
through at least the basics.  I know which IDEs they
are all used to using, and unless I make drastic
changes to the CDT's MBS layout for them, they'll have
a lousy experience like I have had so far.  We'll
either get flooded with support calls or we'll lose
them as customers.  Or they'll continue using the old
IDEs.  My suggestion - nothing should be there unless
I put it there, and it should be more flexible as to
where I can put it.

Final conclusion, if I didn't believe in the concept
and theory of Eclipse so much, I would have dropped
Eclipse long ago due to the experience I've had thus
far.  I do appreciate all the work that has been done
and I definitely appreciate that it's essentially done
by volunteers.  Like I said, I am in full support of
this idea & framework and I would love to see it gain
more momentum and support.  Please understand that my
feedback is strictly meant to suggest improvements and
spark ideas - NOT to slam anyone for not doing a good
job.  I realize that creating an IDE to end all IDEs
is not a walk in the park.  I also definitely hope I
can contribute to the effort in some way soon.

I hope some of that helps.  I could probably type a
bunch more for another 2 hours, but I have to get back
to learning Java, GNU make, and GDB/MI...

--John


--- "Imrisek, Martin" <mimrisek@xxxxxx> wrote:

> All,
>  
>  
> For the CDT Developers Conference I am putting
> together a presentation
> on the CDT End User Experience.  Although this
> session was orignally
> motivated by our experiences with CDT as end users
> migrating from MSVC6
> I would like to gather up as much feedback and
> comments as possible from
> a wide audience of CDT users and ISVs for this
> discussion.
>  
> Send me your comments on end user likes/dislikes
> from your or your
> customers experiences on any the following areas:
>  
> 
> *	What do you/your users find effective/not
> effective in various
> workflows?
> 
> 	*	Project create/import/build
> 	*	Launch and debug workflows
> 	*	etc.
> 
> *	Debug views features 
> *	Debug views behaviour
> *	MBS
> *	Large project development and debug (I'd really
> like to know the
> size of typical projects as well as the largest for
> which CDT is used)
> *	Any other area
> 
>  
> Since CDT is both a product platform for ISVs as
> well as a complete
> C/C++ development environment on several hosts I am
> very interested in
> getting perspectives from host side C/C++
> application developers as well
> as users of embedded tools based on the CDT.
> Comparisons to your favourite IDE are welcome
> whether it be Emacs or
> MSVC or whatever are welcome. :^)
>  
> Regards,
>  
> Martin
> --
> Martin Imrisek
> Software Systems Designer
> Texas Instruments
> 416-340-2096 
> 
>  
> > _______________________________________________
> cdt-core-dev mailing list
> cdt-core-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cdt-core-dev
> 



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/