Systems Programming

I've come to a realization about programming recently which makes me appreciate my job all the more. What I've realized is that the type of programming that we there do isn't about abstractions (which are helpful nonetheless) but rather about hardware. This is programming not for an abstract machine or where there is a clear denotational semantics, but where there is a semantics in the actual hardware sitting in front of you- the execution on one particular machine and maybe a small class of similar machines. Some parts of the program may be so specialized that they will only ever work on your particular project because of unique hardware or some special case that you didn't expect. In this case, C is actually kind of nice. It isn't safe at all, and maybe another language could do better, but the ability to be unrestricted in what you do is a necessity. In this context it would be nice to have more safety, and I am interested in this concept and I'm reading some papers on type safe systems programming, but it has a clarity of purpose that I appreciate.

This has lead me to realize my problem with Object Oriented Programming isn't so much the idea, which is mostly about a class of data structures and their relationship with each other, but rather in the practice- where I see abstractions that have no foundation in math, that leak, are poorly conceived and ambiguous, and whose authors don't have access to the powerful tools of mathematics and computer science to use. I'm over-generalizing of course, and I'm not saying that math solves everything, but it is no doubt powerful, and it at least gives you a leg to stand on when you program. Starting with something that is well understood and composes well allows you to built something understandable that may compose, but starting with something that is not well understood and does not connect or compose at the primitive level does not give much hope of building reusable software at the abstract level.
So, that my rant for today!