Wither imperative programming?

I write imperative code. Code with reassignment statements. Code that mutates data structures. Code with side effects. There. I said it.

In fact, it's even worse than that. Most of the time, the primary purpose of my code is the side effects. I don't write much code to figure stuff out. Sometimes I do, and when I do I try to program in a purely functional style as much as I can. But the fact is, most of the time, most of my programs exist for the purpose of doing something, not figuring something out.

Sometimes I structure my code using objects. Sometimes I just make libraries that each contain related utility functions. Sometimes I use closures. Whatever route I take, there are almost always important parts that are shamelessly imperative.

I mentioned in my last post that I mostly read old books. This is partly out of interest in history, partly because I have a greater interest in the subjects that were popular in the 1960s and 1970s than the subjects that are popular now, and partly because some of them are just great books that happen to be old. But I recently noticed something else that distinguishes my old books from my new books. The old ones talk about imperative programming!

They talk about how to use assignment statements and side effects, and how to write loops that contain assignment statements and side effects, and how to think about this code and how to write it and how to convince yourself (with a formal proof, if necessary) that it does what you want it to. I don't know of any recently published books that discuss this stuff. Do you?

Why is this? Are recent authors under some kind of delusion that because imperative programming is difficult we aren't doing it, and thus there's no need to talk about how to do it? Are the academics so focused on type systems and concurrency and functional programming that they no longer consider imperative programming interesting enough to write about?