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

Re:A poor craftsman blames his tools.

[awe_cz]

While your statement is correct, it kind of misses the problem. With current demand we need more quality craftsmen than there is or ever will be available (in foreseeable future). In this regard, having safe languages looks like a good choice. Not all pieces of software needs to be written by the best of the best anyway. We just need to make sure someone's badly written GUI application does not crash the whole OS. If if it crashes, make sure there is an output from that crash that even sub-standard programmer can understand and fix.

Yes

[MichaelSmith]

Every programming language I have used commercially has had a few things it does well and a whole bunch of limitations. Bad code gets written all the time to work around language limitations. Consider the lack of data type declarations in python, java script, coffeescript, etc. Terrible for code readability.

Its all religious theory and habit with very little up front thought and design. RIP Pascal and Ada.

Software isn't enough, hardware must change

[Required Snark]

Back in the early days of computers, when the world had many hardware architectures, there were machines that had co-designed hardware and software. They were designed from the ground up to avoid certain types of problems, and they worked really well.

Burroughs Large System stack machines were one example and Symbolics Lisp Machines were another. Burroughs had array descriptors that did bounds checking at run time and tagged memory. Tagging added non-user accessible bits to each memory word. The tag defined what kind of data the word contained and the hardware detected any attempt to use a memory value illegally. Symbolics machines also had tag bits, but their implementation was microcoded, so the tag interpretation was also in microcode.

Until computer implementations include features like tagged memory and hardware array bounds checking they will never be truly secure. Some problems cannot be addressed by an isolated software layer: they can only be made secure by hardware enforcement of fundamental features that prohibit some classes of software errors.

Re:what a waste of article

[mccalli]

How many rock solid kernels, games or video editing suites are you aware of? I'm aware of zero. Do you not install your updates?

Memory-unsafe is a BS meme

[perpenso]

This meme, that certain languages are memory unsafe, is BS. The programmer is free to add all the memory checking that a so-called memory safe language automatically inserts. However the programmer using the "unsafe" language is free to use knowledge unavailable to the compiler to decide when and when not to perform such checks.

Furthermore the suggestion that memory-safe languages are faster is bogus. You don't get faster by automatically generating more code.

These memory-safe languages are only more of a necessity for apps written by amateurs. Less of a necessity, and more a convenience, for system software and more important apps written by the knowledgable and experienced.

Re:Executes more code but runs faster ?

[Anonymous Coward]

There is nothing preventing a programmer from adding their own memory checking in such languages.

Sure there is: ignorance and laziness.

One of the problems is that programmers generally view PEBKAC as a "get out of jail free" card. Once a problem is diagnosed as PEBKAC, they wash their hands of it and say "not my problem". But ask any UX expert, and they will disagree with this - if a user is having problems with a computer system, it's the computer system's fault (or at least an opportunity for the computer system to be better). Heck, ask any *security* expert about it. You can't just ignore issues because the user did something they shouldn't have -- especially when the line between incompetence and malice is oh so easy to cross.

But guess what: compilers are programs too, and programmers are users of the compilers. Everything about best practices in making interfaces for end user software also applies to the interfaces to programmers' software. And there is no bigger interface to a compiler than the actual language itself.

Let's face it: "you're holding it wrong" is a fucking lousy excuse. Not for one minute would we tolerate a word processing program where the program crashes when you save a file to a USB drive unless you click Edit->Preferences->"Enable USB interface subsystem" first. Or one where saving a file had a 10% chance of failing, and you had to go to About->"Error Messages" to double check whether you saved successfully or you have saved a completely corrupted copy.

While programmers may be smarter than the average bear, that doesn't mean they're smart in an absolute sense. There are plenty of stupid programmers out there, and, sorry to be blunt, Dunning-Kruger means that you're probably one of them.

Only an idiot would recommend go/rust over C.

[Anonymous Coward]

Bad languages are creating bad software precisely because too many buggy "me too"-languages are constantly being created to solve problems that don't exist.
Usually, the least buggy implementation of any given software is the C version.
So please stop making shit up to sell your latest langue-du-jour.
The industry as whole would benefit from everyone using standard languages such as C.

Market pressures contribute to the problem

[charronia]

I think part of it is that software developers simply do not have seas of time to optimize their code to perfection. There's a strong culture of cranking out features as quickly as possible, because otherwise competitors might beat you to the punch.

Re:False Analogy

[gweihir]

Indeed. And just look at what pretty impressive, secure, stable and fast code is written in C by people that know what they are doing. This whole idiocy about "we need better languages" comes from the same morons that want to teach everybody how to code: They still believe that coding is a menial task that can be done very cheaply, when in actual reality it is among the hardest engineering disciplines known to man.