This Week in Programming: Blame the Language or the Programmer?
You know those seemingly endless Windows updates — the ones where you just want to turn off your computer and go home and it’s like “no, wait, I have 73 security updates to do first, don’t go”? Well, according to Microsoft security engineer Matt Miller speaking at a security conference earlier this month, most of those vulnerabilities are memory safety issues, and this point has started a bit of a firestorm on Twitter around just how bad some think C is as a programming language… and others who think the developers are to blame.
For those of you interested, here is a video of the talk Miller gave, starting at the point where he addresses this particular point:
An article on ZDNet first brought attention to this point and since then it has been making the rounds. The article explains that “around 70 percent of all the vulnerabilities in Microsoft products addressed through a security update each year are memory safety issues” and that “memory safety bugs happen when software, accidentally or intentionally, accesses system memory in a way that exceeds its allocated size and memory addresses.”
The article also points out that “the reason for this high percentage is because Windows has been written mostly in C and C++, two ‘memory-unsafe’ programming languages that allow developers fine-grained control of the memory addresses where their code can be executed.”
The question quickly becomes is this the fault of the programming language or the programmer?
In particular, Matthew Garrett, a major contributor to Linux, GNOME, Debian, Ubuntu, and Red Hat, has been leading the Twitter charge against C and taking up arms against arguments that C is a wonderful language indeed and that it’s the coders who are to be blamed.
"No way to prevent this", say programmers of only language where this regularly happens
— Matthew Garrett (@mjg59) February 11, 2019
Humans are capable of practically anything, with sufficient practice.
Nobody goes around saying "playing the violin is hard, therefore humans are incapable of playing the violin." Statements like the below are stupid. https://t.co/aIVYIlppur
— Howard Chu (@hyc_symas) February 12, 2019
Sure, we could require licenses and tests before allowing people to perform C in public, or we could just tell people that C is a fucking awful idea and they should use better languages instead
— Matthew Garrett (@mjg59) February 12, 2019
Now the Twitter thread is worth a gander, but slightly difficult to link here in a meaningful manner. Instead, let’s look to a blog post by developer Sean Griffin titled “No, the problem isn’t bad coders” to drive home the point.
“Let me be clear, I disagree with the assertion that programmers can be expected to be perfect on its own. But the assertion that we just need better C programmers goes way farther than that. It’s not just a question of whether people can catch problems in code that they write. It’s also expecting people to be capable of re-contextualizing every invariant in any code they interact with (even indirectly). It sets the expectation that none of this changes between the time code is proposed and when it is merged,” writes Griffin. “These are not reasonable expectations of a human being. We need languages with guardrails to protect against these kinds of errors. Nobody is arguing that if we just had better drivers on the road we wouldn’t need seatbelts. We should not be making that argument about software developers and programming languages either.”
I've been writing C and C++ for many of the last 35 years and with specific exceptions for some low level work I am convinced that it is past time to ditch it. Once upon a time most code was written in assembler – that's unthinkable today.
— 💧 Phil Sutherland (@philsuth) February 12, 2019
So, what do you, dear reader, think? Is it time to move on from these “memory-unsafe” languages? Or do we blame you, the developer, for not being careful enough?
This Week in Programming
- Whose Things Are These? According to Google, Android Things are not your things anymore — that is, unless your one of its OEM partners who builds smart speakers or smart displays. According to the announcement, “support for production System on Modules (SoMs) based on NXP, Qualcomm, and MediaTek hardware will not be made available through the public developer platform at this time.” As Ars Technica points out,”Google’s stripped-down version of Android named for its focus on the ‘Internet of Things’ (IoT), is now no longer focused on IoT,” calling the the move “pretty strange,” seeing that the OS “just survived a lengthy initial development cycle […] and it only hit version 1.0 nine months ago.” So why kill Android Things? Ars Technica suggests that perhaps “Android Things is just too heavy for smaller IoT devices.”
- Containerizing Java with Google’s Jib: Next up in Google developer headlines this week, the company also announced the general availability of its Java Containerization Tool “Jib,” which the Application Developer Times takes a look at. According to the article, the open source tool for containerizing Java applications “is a fast and simple container image builder that consolidates all the steps involved in packaging an app into a container image, and allows developers to build containers using familiar Java tools.” The tool “effectively circumvents the need to install Docker, run a Docker daemon, and/or write a Dockerfile […] by separating the Java application into multiple layers for more granular incremental builds.” For those of you interested, Google provides “samples and Codelabs for deploying a Spring Boot application to Kubernetes or deploying a Micronaut application to Kubernetes.”
- Automate Tasks with Google Docs API: Last up for Google this week, Google Docs now has an API after being in developer preview since last April. Techcrunch writes that the “new API for Google Docs that will allow developers to automate many of the tasks that users typically do manually.” The API will allow developers to “set up processes that manipulate documents after the fact to update them, and the API also features the ability to insert, delete, move, merge and format text, insert inline images and work with lists, among other things.” ProgrammableWeb also took a look at the news, offering a comprehensive summary, noting that Google has published a quickstart guide and offers a wizard to create or select a project in the Google Developers console, calling the process “straightforward.”
- Python 3.8 Sneak Peek & PyPy: Moving on to Python, JAXEnter offers a first look at Python 3.8 from a peak at an early developer preview of Python 3.8. While 3.8 is still under development, the article notes “a couple of major features we know are coming in the next version,” namely assignment expressions and typed_ast being merged back to CPython. Second up in Python this week, InfoWorld writes that PyPy 7 speeds up Python 2.7, Python 3.5, and Python 3.6 alike. The Python runtime “uses just-in-time compilation to achieve major performance improvements over the stock CPython distribution, is now available in version 7.0 releases supporting Python 2.7, Python 3.5, and Python 3.6.” The post on the official PyPy Status Blog offers full details on the release.
Hold on everyone, let's compromise and find a code style that's somewhere in the middle
– indent three spaces
– start every block with a curly brace on the same line, and another curly brace on the next line
– identifiers should be both camel_Case_And_Snake_Case— Joe Groff (@jckarter) February 11, 2019
- Test the Waters with Draft Pull Requests: If you’re feeling timid, GitHub’s latest announcement of draft pull requests may be a welcome one, as the new feature will let developers “open a pull request to start a conversation with your collaborators as soon as your brilliant idea or code is ready to take shape.” The feature takes away the more black and white nature of pull requests, offering a bit of an in-between and making it more collaborative. “With draft pull requests,” GitHub writes, “you can clearly tag when you’re coding a work in progress.” The new feature also comes with a Draft Pull Requests API.
- A Case for Types: That whole introduction part, where we talked about memory safety and all that? It seems oddly reminiscent of the debate over data types, and so I can’t help but end with this Reddit thread on how 38 percent of bugs at Airbnb could’ve been prevented by using types. Perhaps that’s the fault of the developers too. (I kid!)
https://twitter.com/CarlyRM/status/1095876750763061248
Feature image via Pixabay.
