Slashdot Mirror
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."
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."
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.
Seven puppies were harmed during the making of this post.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Sorry but people that know how to program do have families they want to actually be with too. Nothing to do with a thousand side projects. Just with actually knowing your shit.
Its very hard to find good people. Most either run away from our very standard do it at home test or they fail it miserably. And these are all solvable by googling "standard programming interview questions" and they get them wrong or they say "I dont know". Nevermind the freeform programming question where all you need to do it to show off what kind of programming patterns you know, how clean you can code etc. And they all show off the worst spaghetti nightmares you can imagine. Disgusting.
When you say "memory safe" languages surely you mean managed languages like Java...
Java is of course a completely safe language. There has never been any question about how safe and reliable Java is, and nobody has ever recommended un-installing Java to make your system safer.
"His name was James Damore."
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
No sig today...
When you write a program that needs to print the primes up to a certain number, you can easily create a formal proof that your program program is correct.
But when your program is say "apache", that needs to interact with many different browsers on one side, and interpret PHP scripts that interact with databases, this formal proof becomes impossible. Similarly, you cannot write a formal spec for the interaction with the user in for example, a web browser.
While things like the halting problem obviously prevent fully formally proving the correctness of programs, you can go much farther than we generally go today. For example, I participated in an EU project where they constructed a formal model of the PikeOS separation kernel (kind of like an embedded real-time hypervisor). They also generalised this model, which includes support for things like interrupts and context switches.
Donate free food here
C++? It's crap. How many memory allocation methods does it have now? Do you think it makes it easier to debug?
Good luck debugging C++ code heavy with templates and its multi-line warnings/error messages.
C++ is too complicated for little good reason. And complex languages are always harder to debug and more error prone.