Re: "Why not? K&R is ~250 pages long"
I started out doing some BASIC (horror!) and then assembly for Z80 (on a ZX-81 - that pretty much dates me) and followed that up with stuff on 6502, 68xx and more. The move to C was natural and relatively painless (there are many gotchas but the language is small enough that you tend to find those out quite quickly). That was even despite getting a rather terrible book (which perversely led me to dig further in search of answers and in a way actually made me better at the language).
Since then I have used a number of different languages, each with its pros and cons. Poor software is not about the language but more about not choosing the right language or not considering the problem space properly. There are others such as totally unnecessary levels of abstraction which is also a programmer problem, not a language problem. I tend to use C more than anything else simply because it fits the problem space I most commonly encounter.
My view is you need to understand one level below what you are doing. Much of my code has been hardware diagnostics and as such I needed (and still need) to have a detailed understanding of all the underlying hardware and hence the use of C.
The major problem I see is the use of inappropriate features of languages; inheritance and abstraction (as provided by C++) can be incredibly powerful and useful in a particular problem set, but bare metal diagnostics is not (usually) in that category.
Python has a well deserved place where it fits the problem space.
Biting the hand that feeds IT
