After reading both of them, I found myself with a lot of questions.
1. What would a language that does C's job better than C look like?
2. How can you make a language more communicative than C?
3. In what ways can the tools and systems used when writing and debugging a systems programming language be improved?
4. How can a systems programming language be made more configurable and modular than C, and as safe or as unsafe as you want (or easier to be safe if you want to)?
5. How could a high level programming language be made that is nonetheless closer to assembly language than C? How can it access all hardware features that don't necessarily align with the abstractions which C assumes exist; and how can it allow you to be as platform specific as you want?
6. How can the compiler-linker-loader toolchain be improved?
7. What things are possible in assembly language which are impossible or not easily done in C?
8. How can an operating system be designed to ease and facilitate debugging?
In short: what if you went in the opposite direction from languages that were intended to replace C with something that is more managed and through that safer?
Here's a quote from a book I'm reading on Java I/O.
Should a language make assumptions about data or operating system?The underlying flaw in most people's analysis of Java I/O is that they've confused input and output with the formatting and interpreting of data. Java is the first major language to cleanly separate the classes that read and write bytes (primarily, various kinds of input streams and output streams) from the classes that interpret this data. You often need to format strings without necessarily writing them on the console.
You may also need to write large chunks of data without worrying about what they represent. Traditional languages that connect formatting and interpretation to I/O and hard-wire a few specific formats are extremely difficult to extend to other formats. In essence, you have to give up and start from scratch every time you want to process a new format.
Furthermore, C's printf(), fprintf(), and sprintf() family only really works well on Unix (where, not coincidentally, C was invented). On other platforms, the underlying assumption that every target may be treated as a file fails, and these standard library functions must be replaced by other functions from the host API.
Is it worthwhile to abstract things like String formatting and text I/O apart, or is it better to reflect what actually goes on under the hood?
Should a language should deal with hardware as it actually is?
How can a language be made to better reflect what is going on in the machine?
How can a language/systems designer make it as easy as possible to design small, fast, and efficient programs?