[vox] things that really suck about C!

[Bill Broadley]

Wes Hardaker wrote:
>>>>>> On Sun, 28 Feb 2010 18:35:28 -0800, Brian Lavender <brian at brie.com> said:
> 
> BL> I think if anything, C has been a certain detriment to the field of
> BL> computer science! 
> 
> The detriment to computer science has been in the continuing acceptance
> of the C language without the background in assembly to go with it.

Agreed.  Then again ASM doesn't really imply knowing anything about
performance.  Seems like a much stronger background in architecture would
really help people understand the memory hierarchy.

> The thing about C is that it is intended to still provide full-service
> access to memory, etc.  You're handed a loaded gun already nicely aimed

Indeed.

> at your foot for you.  You're expected to know how to use the gun.
> However, everyone seems to have forgotten how things work internally and
> are surprised when you can get away with more than you bargained for.  A
> similar thing could be said about much of perl!
> 
> Java, Python and other "safety languages" provide a much much better
> playground to write bad code in and still feel safe.  Unfortunately,
> with such wrapped protection often comes a detriment: speed.  (And yes,
> I'm aware that you can write a good implementation of an algorithm in
> python that beats a bad implementation in C).

The best compromise I've seen so far is Go.  Safety of Java/Python and close
to the performance of C.  Take that and add a nice layer of support for
elegant multiprocessing and it's top of my list for keeping track of.  I've
written a few parallel programs and go and I've seen really impressed how easy
it is go setup a producer, N consumers, and then handle the out of order
output (from the N consumers) and reorder it in an I/O thread.