Are Flawed Languages Creating Bad Software? (techcrunch.com)

"Most software, even critical system software, is insecure Swiss cheese held together with duct tape, bubble wrap, and bobby pins..." writes TechCrunch. An anonymous reader quotes their article: Everything is terrible because the fundamental tools we use are, still, so flawed that when used they inevitably craft terrible things... Almost all software has been bug-ridden and insecure for so long that we have grown to think that this is the natural state of code. This learned helplessness is not correct. Everything does not have to be terrible...

Vast experience has shown us that it is unrealistic to expect programmers to write secure code in memory-unsafe languages...as an industry, let's at least set a trajectory. Let's move towards writing system code in better languages, first of all -- this should improve security and speed. Let's move towards formal specifications and verification of mission-critical code.
Their article calls for LangSec testing, and applauds the use of languages like Go and Rust over memory-unsafe languages like C. "Itâ(TM)s not just systemd, not just Linux, not just software; the whole industry is at fault."

Comments

A poor craftsman blames his tools.

[Anonymous Coward]

It's not the language, it's the programmers and the rush to produce easy code. Speed and simplicity trumps security and efficient coding these days.

Re:A poor craftsman blames his tools.

[Anonymous Coward]

A good craftsman doesn't blame his tools because a good craftsman doesn't use poor tools.

Re:A poor craftsman blames his tools.

[allo]

A good craftsman chooses good tools.

Of course you can create excellent work with very bad tools.
But the first a good craftman does is to search for the right tools. He checks his budget, then starts to search for the right tools and if they are too expensive, he searches for replacements, which are for him (but not for everyone) similiar useful. If he cannot find a tool he needs for good work, he's honest about it and tells his client before starting to work.

Re:A poor craftsman blames his tools.

[Dunbal]

On the other hand, the tools don't make the craftsman. You give sophisticated tools to an idiot and you will still get something idiotic - although sophisticatedly idiotic.

Re: A poor craftsman blames his tools.

[Anonymous Coward]

Give me a crappy handsaw and nothing else and expect me to do perfectly mitered crown molding in no time at all? You get shit.

Same tools with more time? Now we can talk about my skills I.e. can I do it properly with just that handsaw but time to make it right?

On the other hand, give me a nice table saw where I can simply set the saw to miter correctly and I can do these crown moldings perfectly in no time at all.

The moral of the story? Yes in scenario 2 the poor craftsman will still blame the tools but a good one will also do it because he does know how to do it but he also knows that the table saw exists.

Re:A poor craftsman blames his tools.

[Anonymous Brave Guy]

It's not the language, it's the programmers and the rush to produce easy code.

Well, I think it's a lot the language as well. To a first approximation, every major piece of system and networking software written in C has had serious security issues at one time or another, even the ones written by the best programmers of their generation and hailed as being exemplary in their code quality. I think after the first few decades of evidence we're allowed to call this one now, and say that writing critical software in unnecessarily dangerous languages produces less than optimal results.

Re:A poor craftsman blames his tools.

[Joce640k]

Yep. Too much 'critical' code is written by the boss's nephew just because he "seems to be good at computers".

Bjarne said it best:

The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained. Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
- Bjarne

Re:A poor craftsman blames his tools.

[Anonymous Brave Guy]

A good craftsman doesn't insist that his tools necessarily do the job for him either.

As programmers, automation is the essence of what we do. Any programmer who isn't insisting on their tools doing work so they don't have to do it themselves isn't making very good use of those tools. That is as true for safety, security and defensive programming as for any other aspect.

Re:A poor craftsman blames his tools.

[Anonymous Brave Guy]

What happened with "We rely on the developer to do a good job?"

We tried that experiment, and it failed when roughly 0% of professional programmers turned out to be more reliable than an automated tool designed specifically to prevent certain types of programming error.

Can we just stop finding excuses to deliver crap quality code?

You're implying a false dichotomy. There are plenty of programmers who produce generally decent code but still make mistakes that better tools will catch before they go into production.

Re:A poor craftsman blames his tools.

[Spazmania]

Java is a memory safe language. Great error handling too. The language does so many things right, it's scary.

Intermediate result: java attracts incompetent programmers who find that their java code doesn't outright crash the way their C code tends to. Because their code works, more or less, it becomes hard for a non-programmer manager to tell the difference between a java guru and an incompetent boob.

Final result: most java code is utter crap riddled with errors compared to typical C code.