Lpc2000

I won't make any more comments than below on this subject.
IDE choice is such a religious issue that it can burn a lot of very valuable 
effort.

However, I am driven to write because I beleive the posting has bias and is 
misinforming.

On Sunday 15 May 2005 21:57, you wrote:
> Charles and co,
>
> Am I correct that you are just embittered about the way the development
> tools industry is going?

No I am not at all embittered.If an IDE works for you, fine, use it.

> I think you are are totally wrong on the subject of IDEs, and I don't
> believe you've ever used a modern IDE  properly on a real project (from
> start, to completion), or would ever want to.

I have a few times. What I didn't particularly like was that the IDE worked 
"its way" and did not give me the flexibility I wanted. Typically, IDEs lock you in, limit what you can 
do, and provide a very bland way of looking at software development.

For the same reason I get the mutters about using compiler/vendor specific 
pragmas etc. 


By using unbundled tools I essentially get myself an IDE on the fly that I 
can fiddle with and gives me lots of options.

For example, I will often use three different debuggers depending on what I 
am doing. I use ddd, insight and raw gdb, because each has a particularly 
valuable way of doing a few things, so I regularly switch debuggers depending 
on what I am doing. I find "one size fits all"  mentality that exists in IDEs 
is just too limiting.

Example 2: I work with multiple host OSs. IDEs are typically Windows only 
(except eclipse) and the unbundled tools approach allows me to work across 
platforms. In this age of globalisation at the project level, these 
flexibilities are becoming more important.

I also believe that effective embedded development requires a good 
understanding of what the tools do, how they work etc. IDEs make that harder 
because they hide so much. I don't believe all those Wizzards etc do much 
that is very useful. I have used them a few times to generate a start-up that 
I have then modified, but so often they have generated wrong stuff and I have 
lost faith.

>
> You should not be sending the wrong signals to younger generation
> programmers who are getting used to IDE based products from birth (well
> pretty soon in any case). Please stop this nonsense.

Just because they are getting used to it does not mean it is right.  Just 
because I say "there are altentatives and I don't like them" does not make 
them wrong.

I don't particularly care if people use IDEs or not, but I feel compelled to 
state my experiences (I have over 20 years of embedded programming 
experience). There are alternatives to IDEs and many people use these 
alternatives with great effect.


>
> Here's what I think you should do:
> Try out Rowley Associates CrossStudio**** for a couple of projects. Let
> everyone know at LPC2000 how you get on, and whether you still think
> IDE's are waste of time.  You have no excuse, because there is a 30 day
> evaluation of the FULL package available from the Rowley site which you
> can try out:
>
> http://www.rowley.co.uk/arm/index.htm

My excuse it this. It is a waste of my time. I already have a perfectly 
acceptable set of tools already.  If you or Rowley pay for my time I might.


> As engineers we should be concentrating on delivering commercially and
> technically successful projects, striving to save on development time,
> but not spending too much time  pondering about what's under the hood of
> a compiler suite. (Though I am not necessarily saying one should have
> blind faith in dev tools, and not take note of what is being generated!!!)

I too deliver multi-k-line solutions using command line tools.

The tranparency is far more difficult with IDEs.
I find that so often the lack of transparency robs you of development time 
etc.

If you don't ponder what is under the hood you will never get sufficient 
understanding to build effective embedded products. On one product I worked 
on, using command line tools has allowed me to do all sorts of configuration 
and compression steps that IDEs would not allow (or at least only do 
reluctantly).  

Not everyone in the team needs to do this. In the projects I work on, only 
one or two people need to know the low level grubby stuff and the rest just 
know "add your C file name to this file".