Typesafety versus Worse is Better - was Re: Fwd: is there any word processing software for the pdp11?

[Sean Caron]

Clearly you're on a religious crusade here.. I just don't buy the line that
were it not for everyone using this pesky C language, we could live in this
mythical world where exploits don't exist... You must be a professional
programmer? Certainly you have strong ideas of what's right and what's
wrong in programming practice... but I feel like you are faulting the
language here while giving what are essentially (sorry, strong language)
hack programmers a pass... Why should it be the responsibility of the
language to save programmers from themselves? Not necessarily the best
metaphor because I totally appreciate languages like Smalltalk, LISP, et al
but I'm too old to be restricted to safety scissors!

Best,

Sean


On Wed, Dec 3, 2014 at 3:25 PM, Eric Smith <spacewar at gmail.com> 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. I would go so far as to say
> that if they don't become proficient in another language, given a
> reasonable
> chance to do so, they aren't actually a good programmer, any C programming
> ability notwithstanding.
>
> > Given a short time frame, perhaps it's more effective to spend
> > those hours writing code in a language with which you're already
> familiar,
> > rather than spending them picking up a new language...
>
> And continue writing software that has vulnerabilities. When the tools
> don't
> provide support for writing reliable software, reliable software mostly
> doesn't
> get written.  For every CERT advisory of a vulnerability, there are still a
> huge number that have gone undetected so far.
>
> 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.
>
> 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.
>