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

Sean Caron scaron at umich.edu
Wed Dec 3 18:02:20 CST 2014


I suppose not. Perhaps more that using a language that Isn't C and offers
(1) and (2) will ameliorate 99.99% of the problems that follow from using C
incorrectly. Certainly that's true. Can't shoot yourself in the foot if you
don't own a gun. But that's not much to talk about :) I have a habit of
using hyperbole and I guess I really shouldn't because 99.99% of the
population of Earth apparently finds it simply discrediting, rather than a
come-on for a debate!!

I have a lot of hang-ups from my experience in school and in the
new-millennium job market... there are so few opportunities these days; the
people that get the chance to take them; who get to be real programmers and
real engineers; they had better be good. Otherwise you can just play on
nights and weekends like I do. To me, part of being a professional and
doing the job right is not making mistakes. Certainly that's the standard I
hold myself to as a Systems Administrator. People who nail up their shingle
as a professional and subsequently ship buggy garbage don't need a new
language to save them from themselves; they need a new line of work (whoa,
polarizing!)

Best,

Sean




On Wed, Dec 3, 2014 at 6:38 PM, Josh Dersch <derschjo at gmail.com> wrote:

> On Wed, Dec 3, 2014 at 3:09 PM, Sean Caron <scaron at umich.edu> wrote:
>
> > 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...
>
>
> That's not the line that was given.  No one here is claiming there is a
> language that prevents all exploits.
>
>
>
> > 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?
>
>
> The reality is that we're all "hack programmers."  Everyone makes
> mistakes.  Sometimes these mistakes get caught by others, sometimes they
> don't.  Some programming languages can help catch more of these mistakes
> sooner, or to make some of these mistakes impossible.
>
> In a perfect world, we wouldn't need languages to take responsibility to
> "save programmers from themselves," but we don't live in that world and
> it's pretty evident that deficiencies in C have resulted in many exploits,
> even in the hands of experts.
>
> - Josh
>
>
>
> > 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.
> > >
> >
>


More information about the cctalk mailing list