You misunderstand his argument. He's not arguing that we should replace C with "higher-level languages" that don't give you precise control of the hardware; in

You misunderstand his argument. He's not arguing that we should replace C with "higher-level languages" that don't give you precise control of the hardware; in fact, he bemoans the fact that the PL community at large seems interested only in such high-level languages. Nor is he complaining that C is hard to learn (I'm not sure where you got that impression). In fact, the paper mostly takes for granted that C needs to be replaced, and discusses the challenges in doing so, which may be why you assumed that BitC is (was, really) just another typical research-community high level programming language project. The fact is, C is broken, and we all suffer every day because of it. From a security perspective, C is a nightmare. It is not just an unsafe language (in the PL sense of having undefined behavior), but a rampantly unsafe language. Null pointers (which C.A.R. Hoare famously called his "billion-dollar mistake"), buffer overruns, unrestricted pointer arithmetic, arbitrary casting, manual memory management; all of these are the cause of innumerable bugs in real code, often critical security vulnerabilities. C is also not the nicest of languages to code in. It is terribly verbose. There is no good way of writing generic code in it. The preprocessor is a gigantic ugly hack. Writing portable C is a pain in the ass, and building it portably is doubly so. The worst part is, we know reasonable ways to solve most of these problems. In many cases we have known them for decades. Unfortunately, how to best integrate these solutions into a language and still keep it useful for systems programming was (and is) an open problem. I can't speak for Shapiro, but as I see it this is what BitC was aimed at doing.