Re: C / C++ skills

"mc" <look@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6q8Eg.20173$bo6.13016@xxxxxxxxxxxxxxxxxxxxxxxxx

C is better than assembly language, but not a lot better. Most of the
unreliability of software as we know it is due to C, with its lack of
bounds-checking, uninitialized pointers, etc.

I disagree. Most of the unreliability of software is down to poor design and
poor coding. Don't blame the tool; blame the workman.

I'm not a fan of languages that provide me with a nappy whether I want one
or not. My ideal language is neutral and expressive; C suits me fine. And
even the most nappy-laden language would still produce buggy code when
driven by a sloppy coder.

(That's not to say that the principles of defensive programming could not be
better implemented in a future language. But, fundamentally, defensive
programming is a Good Thing in any language.)

Steve
http://www.fivetrees.com


.

Relevant Pages

  • Re: C / C++ skills
    ... C is better than assembly language, ... Most of the unreliability of software is down to poor design ... Don't blame the tool; blame the workman. ...
    (comp.arch.embedded)
  • Re: C / C++ skills
    ... C is better than assembly language, ... Most of the unreliability of software is down to poor design ... As I've said many times before, I separate design from coding. ...
    (comp.arch.embedded)
  • Re: Weekly series after 52...
    ... it is you that needs to take up English as a primary language. ... blame his failure to understand on the other poster. ... With your mangled English, I can't tell what you mean. ...
    (rec.arts.comics.dc.universe)
  • Re: Why I dont believe in static typing
    ... >> language. ... I blame this failure on the mindset that because the compiler ... > least with regards to concurrency. ...
    (comp.lang.lisp)
  • Re: What about turbos?
    ... post increment operators and their ilk..... ... the problems caused by such easy to use and labour saving ... Of course, we don't blame the language when we have such a problem, we ...
    (borland.public.delphi.non-technical)