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.

[Anonymous Coward]

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

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.

[Bengie]

against what the senior people advice

Most senior people are equally incompetent. Senior programmers tend to be pattern-anti-pattern cargo-cult programmers. They seem competent to those who are incompetent themselves. They also like to use buzzwords. "I'm going to use a no-sql database to increase the scaling performance" only to reinvent a relational database on top of a no-sql database and get strange data oddities because they didn't realize that "transactions" in their chosen no-sql DB does not mean the same thing as "transactions" in a proper relational database. Then after fixing the transnational issues, the no-sql DB is now slower because synchronization is more expensive in no-sql.

Knowledge in an of itself is useless. The Google datacenter is more knowledgeable than any human, yet it is stupid, about as smart as an insect. Wisdom is what one gains from making mistakes, talent allows you to skip making mistakes in the first place. A wise person can correctly recreate what they have already done in the past, talented person can correctly create something entirely new.

Re:A poor craftsman blames his tools.

[Anonymous Brave Guy]

I think Bjarne Stroustrup, among others, could reasonably challenge your claim.

But as I said, the reasons for C's continued popularity aren't technical. There's a huge ecosystem around it, including using it as programming's lingua franca. For that to change, either we need an industry heavyweight with enough resources to create not just a better language but the tools and libraries and developer ecosystem around it, or we need some sort of external pressure to drive the change, so that enough professional developers start caring enough about improving quality to switch to new languages and tools despite C's established presence.

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.

Re:A poor craftsman blames his tools.

[ZenShadow]

In the application space, you can argue all you want for better languages. There's nothing stopping it there. I'll still disagree with you, but there is no technical reason why the average application can't be written in whatever language you choose. Why? Because the low-level stuff is already done, far beneath your application.

If you're dealing with hardware (eg. writing an operating system, or code for a microcontroller that manages the brakes in your car), then using those higher level languages is a non-start. Every CPU cycle counts, especially in the latter case. Hardware does not understand the high level string constructs (not even C-style NULL terminated ones!) and data structures present in ANY high-level language. Hardware is a collection of registers in specific places that you have to poke and prod in specific orders to make things happen.

Good luck enforcing a safe memory access when that access involves poking raw numbers into sixteen different registers (some bit-level options, some addresses), and then going off to do something else while the DMA hardware (hopefully) executes it the way you intended. At the low level, you're going to be dealing with bounds-unchecked pointers whether you like it or not.

There is none of this safety you want in hardware.

Unless and until someone invents hardware that directly handles "managed code", languages like C are *very* necessary. They are the bridge between the hardware and whatever hipster silver-bullet language you've chosen to solve all your problems today.

Re:A poor craftsman blames his tools.

[cheesybagel]

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.

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?

Re:what a waste of article

[Rockoon]

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.

Re:Formal verification is worthless IRL.

[Halo1]

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.

Re:Software isn't enough, hardware must change

[gtall]

And then Intel happened, and we've suffered ever since.

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.

False Analogy

[stoicio]

First of all it's a programming language not a saw.

Secondly, almost all other languages are compiled using a 'C' compiler.
If the 'C' language were a flawed language then producing code for all those other languages, using 'C' would make all of those languages inherently contain the same systemic flaws.

'C/C++' gets a bad rap from programmers because most programmers lack the skills necessary to make reusable patterns or program securely in any language let alone 'C'.

A better analogy would be that programming has become a lot like carpentry. All manner of people claim to be carpenters and joiners just because they own a hammer. In computing, all manner of people claim to be programmers because they own a computer, have a Comp. 150 or 250 course, became a Microsoft Certified Engineer (what ever that means), or downloaded a free compiler and read a manual once. Such is our culture.

It takes a great deal of experience to understand where problems can be produced in any programming language. Unfortunately the under-informed masses of under skilled programmers tend to be negative about the technologies they understand the least.

The industry needs job entrance tests to demonstrate efficacy in programming rather then simply accepting that people are 'qualified' because they dicked with code for 20 hours in high school.

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.

Credential-itis

[stoicio]

To a certain extent this can be true. Our society, however, also suffers from anther problem at the other end of this scale.

This is what I refer to as 'Academic Credentialitis'. This disease is pervasive in our society and needs to be stamped out.

There is no certainty that anyone achieving academic standing in any subject actually makes them good enough at that subject to be 'fail-safe' .
There is a systemic myth that somehow links academic standing with actual skill.

Another question is in the context of the design of academic programs. Programs can only be developed reactively based on social context. This means that any new technology that may be disruptive can only have curriculum developed once it is known. If we look at the top 20 historic developments of technology, that have shaped human history in a disruptive way, the majority of those were non-credential-ed developments.

Consider if you will the rise of the desktop computer. It was **NOT** a degreed professional who designed the first broadly successful consumer P.C..
(Wozniak only finished his engineering degree in 1986.) Even If we only consider the commercial success of the PC from an academic perspective, there were no business academics who predicted or persued the development of a consumer personal computer until after it had already arrived on the business scene from a garage. So, in the context of the computing world that we now live in, academia had little to do with the early development and adoption of the PC technology except to claim it after the fact. In short, if we had all adhered to academic credentials as the basis for the development of this technology, none of us would have it right now. We would all still be using tele-type and reading paper newspapers delivered by hand.

The academic myth has been created as a socio-economic filter to ensure that only those with suitable amounts of cash may achieve status in industry or government. This does not scale well to either skill or aptitude.

It has been suggested that aptitude testing would be a better way to validate skill level rather than degrees. The question is, "who designs the test?". There would be a strong bias to load the content of tests with useless information that only a degreed academic would know in just the same way as requests for proposals are biased toward favoured contractors.

The credential is a problem, not a solution. We need to remove our social addiction to that particular social snake oil and get back to skills assessment instead.