On 03/12/14 3:25 PM, Eric Smith wrote:
On Wed, Dec 3, 2014 at 9:21 AM, Sean Caron <scaron
at umich.edu> wrote:
But is there necessarily a win in turning a crack
C programmer into a
novice {Smalltalk, LISP, insert your favorite language here...}
programmers?
Of what use is a newborn baby? Of *course* it's of no value if you stop
at turning them into a novice. But if they're actually a *good* programmer,
they'll become proficient in another language. ...
C advocates always claim that a good programmer will write reliable code
in C, and in a vanishingly small number of cases that's true, but the
reality is that 99.9999% of C code has bugs that either:
1) could have been caught by static analysis in a language with even
slightly better semantics (including strong typing)
2) could have been caught at runtime if the language semantics could
reasonably support bounds checking. In this case the software would
still have a bug, but at worst it would result in denial of service rather
than privilege escalation and information leakage. (Then there's the
problem of people that use runtime checking during software testing
to protect their valuable test data, but turn runtime checking off for
production, but that's an argument for another day.)
There has been a huge amount of research into how to solve those
problems in C, with only partial results. It's a difficult and perhaps
intractable problem because C is a portable assembly language, with
correspondingly low level semantics The "easy" way to solve the problem
is not coming up with bandaids for C, or trying to better train C
programmers; it is to abandon C for a reasonable language.
Not only that - the semantics of C can even get in the way of it being
FAST. So there goes one of the brogrammer talking points...
This doesn't happen at least in part due to managers seeing a huge
glut of C programmers on the market. When all you've got is a hammer...
Note that the same arguments apply to C++. While C++ is no longer
a proper superset of C, it still is close to being one. C++ advocates will point
out that a lot of the new stuff in C++ is safer than the old C stuff, but
unfortunately as long as the old C stuff is in there, it gets used and
causes the same old problems. Rather than C++ being a better language
than C, it's a worse language, because it has *all* of the C defects, plus
additional new ones.
Definitely. And Go seems doomed to make a similar plethora of bad choices.
--Toby