Tony Smith wrote:
> I originally wrote 'almost no-one', but changed it to see who'd bite.

I can only respond to what you wrote, not what you considered writing.

> 'Blatantly' is a bit much,

No, you made a absolute statement which a single counter example can
disprove.  There are many counter examples of which I listed a couple.  If
you'd said something like "most programs don't need a compiled language
because speed is not the issue" I wouldn't have argued and even agreed, but
that's very different from what you actually said.

> sure Eagle needs to run fast, but you're
> not the one writing the auto-router.  Out of the thousand of Eagle
> users only one needs C, and that's the author.

And only one example disproves your blanket statement.

> It's also been true for a while that it's cheaper to buy more CPU
> power then spend days fiddling with something to make it faster.
> That offends people too, but a new PC divided by your hourly rate is
> a small number.  Which is better?

Again you're making a absolute claim, which of course is false.  Have you
really never run into programs that took longer to run than you wished, even
if you had the latest computer?  Even if you haven't, are you really saying
you've never heard of any or can't imagine any?  If so, then there's a big
world of computing you've managed to miss somehow.

The Eagle autorouter is a good example.  Some runs I've done have taken a
couple of hours, some overnight.  Let's say for sake of argument I have a
real problem that takes my current PC 1 hour to run.  Of course I'd like it
to be instant, but let's say 10 seconds would put it into the good enough
range so that I wouldn't have to alter my workflow around the program.
That's a factor of 360.  My PC is a few years old.  Maybe I could get 4x out
of a current mainstream model.  Let's be generous and say 8x.  That brings
the one hour down to 7.5 minutes.  That's still a "long" time in my context
and I'd definitely want it to be faster.

Thru the history of computing there have always been problems that taxed the
computers of the time where people had to wait inconveniently long for the
computer to finish or compromises were made to limit the problem.  As
computers got faster some problems could be solved fast enough so that
nobody cared anymore, but others could now be solved with a few less
compromises but are still a long way from good enough.  Generally the ones
that remain pushing computing limits today have to do with many passes over
large arrays.  Surely you've at least heard of some?

> C is rarely needed these days.

That's better, although I think you meant to say the extra performance of a
compiled language is rarely needed these days.  I agree with that, but note
that this doesn't make a compile language a bad idea, only that it makes
other alternatives viable.  There are still plenty of reasons for using a
particular language when performance isn't the issue and a wider choice is
therefore available.  Familiarity and investment in a particular toolchain
is probably top of the list.  For example, for PC programming I use my
Pascal to C translator with C compiler environment.  For some things I do, I
definitely need the power of a compiled language.  For most things I don't.
However, having everything written to the same toolchain is a huge
advantage.  It wouldn't make sense to write the programs that aren't CPU
critical in Java, for example, just because I could, keeping in mind that
occasionally I'd still have to go back to writing truly compiled code to get
the performance.

> PICs are the same, you have "slow cheap Pic + Assembler" vs "faster $
> PIC + compiler".  Not everyone needs assembler for PICs.

Right, but some do.  Even if you haven't encountered them, there are high
volume projects out there where $.05 microcontroller cost is significant.

> (and in reference to the subject line, BREAK is probably the dumbest
> idea ever, every other language got switches right)

I agree with that.  The C switch statement could have been designed better
with no more burden on the compiler or loss of machine code performance, but
with less likelyhood of a programmer screwup.  Worse, this same thing can be
said about too many other aspects of C.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist