On Thu, 31 Jul 2003, Petri Helenius wrote:
What we need is a new programming paradigm, capable of actually producing secure (and, yes, reliable) software. C and its progeny (and "program now, test never" lifestyle) must go. I'm afraid it'll take laws which would actually make software makers to pay for bugs and security vulnerabilities in shipped code to make such paradigm shift a reality.
Blaming the tools for the mistakes programmers make is like saying "guns kill people" when the truth is that people kill people with guns.
Yep, it is people who choose tools and methods which produce code which is guaranteed to be unreliable and insecure - simply because those tools allow one to be lazy and cobble things together fast without much design or planning.
We╢ve code running, where the core parts are C and has a track record better than the "utopian" five nines so many people mistakenly look for.
A real programmer can write FORTRAN program in any language. The problem is that the even the best programmers make mistakes. Many of those mistakes (particularly, security-related - such as not checking for buffer overflows) can be virtually eliminated by the right tools. As for "code running" - in the course of my current project I had to write code interacting with ciscos - and immediately found a handful of bugs (some of them serious) in the supposedly stable and working code which has hundreds of thousands of users. I'm afraid you're confusing code running stably in a particular environment with good-quality code. (Excuse me for being rude - but my notion of reliable code comes from my early programming experience in an organization which produced systems controlling high-energy industrial processes - where an average computer crash causes immediate deaths of those unlucky to be around the controlled object, and prison terms for the manufacturer's management).
However, since improvements are always welcome, please recommend tools which would allow us to progress "above and beyond" C and it╢s deficencies.
May I suggest Algol-68, for example? Or any other language which actually supports boundary checks in arrays and strings not added as an afterthought? Or using CPUs and OSes which won't let to execute code from stack and data segments? Or doing event-driven programming instead of practically undebuggable multithreading? There's no market[*] for higher-quality software - therefore, there's no pressure to improve tools and methods. If anything, the trend is to use more and more languages lacking strong typing and lots of implicit conversions, specifically designed for "rapid prototyping" aka quick and dirty hackery - all of which was known to be dangerous for decades. --vadim [*] "No market" means that quality is not a differentiator because it is impossible to evaluate quality prior to purchase, and after purchase manufacturers are shielded from any responsibility for actually delivering on promises by the license language.