On Tue, 2006-08-29 at 08:52 +0100, Michael Rigby-Jones wrote:
> >The bar is variable. It's not the NUMBER of bugs that will tip 
> >the scale with me, it's the amount of time I waste BECAUSE of 
> >a bug that counts. In the case of windows it took way more 
> >then 2 bugs to cause me to switch, but that point eventually 
> >came, and now I'm basically exclusively Linux. Linux surely 
> >has bugs as well, but I've found that solving them is actually 
> >possible, and very easy to figure out (google is your best 
> >friend for Linux problems IMHO).
> 
> I don't think I would have a single compiler availble to me if I took that view.  C18 was riddled with bug a few years back, 

Well, with that view both C18 and C30 have been good to me.

> the AVR port of GCC that I've been using has numerous bugs and 
> examples of appalling lack of optimisation (though it's not the 
> very latest version).

I tried getting into AVRs once. I had a bear of a time getting the
software to work at all. Kept getting very weird errors. In the end it
turned out another tool I was using used the same environment variable
as the AVR port of GCC. I did get the tool working, but I had wasted
enough time that I lost interest in AVRs. I haven't gone back.

> Personaly I think their is only one sensible way in which to judge a compiler, at least from a commercial point of view: support.  It doesn't matter is you only wasted an hour finding a compiler bug if the vendor won't fix it.  I have reported a couple of bugs in HiTechs compilers and either it was a known issue and a patch was already available or one was made available very quickly.

Support is useless if you don't know the bug IS a compiler bug. The bank
switching bug took me a day to debug. Only right at the end did I
discover it was a compiler bug. What good was support to me at that
point? I had already wasted a day. By finding out WHAT the bug was, I
also found a solution (setting the bank manually), so support was
useless to me.

The second bug I discovered was found quicker by me since I already
doubted the compiler. And again, once I determined it WAS a compiler
bug, the solution was 5 minutes away (a for loop). Again, support was
completely useless to me in that case since all the wasted work was
spent determining it was a compiler bug.

In my professional work tool issues are a VERY big part of my wasted
time, as such my tolerance for sub par tool quality isn't very high. If
a tool keeps wasting my time I simply switch to another. After all, I'm
not being paid to be their beta testers, why should I spend my time
being one?

TTYL

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist