Well, if you want "fundamental particles of computing," have some machine code. Assembly is a bit more tolerable, but directly correlates to machine code, so su

Well, if you want "fundamental particles of computing," have some machine code. Assembly is a bit more tolerable, but directly correlates to machine code, so sure, use that. The thing is, the CPU is "imperative" - it's a machine whose state changes according to instructions provided to it. Everything else is abstraction. Abstraction attempts to reduce the amount of stuff the programmer needs to think about all at once (i.e. 'complexity.') A nice procedural language lets you more easily reuse code by referring to procedures which, in turn, are executed sequentially. OOP lets you group functionality with conceptual objects. Every bit of code you write is executed sequentially by a CPU core. So what abstraction works best for you? In some cases, it's not about what works well for the programmer. I'm currently an OS X and iOS developer and I see problems in the Cocoa APIs with an overabundance of OOP. The simplest of iOS apps gets a view, a view controller, an app delegate (which often gets used as an app controller), etc ad nauseum. Now, I come along and look at the code and just want to know how the thing does what it does, but the functionality is spread across dozens of classes and to follow along I actually have to run the app to see that the entry point to the functionality is really -touchesBegan on some deep class... it's obnoxious. What's worse is the design of Cocoa and CoreFoundation lead to many app designs that have magical entry points unless you have more deep knowledge than you ever thought you might. I get that this is an attempt by Apple at keeping the developer more productive by writing less code, but I don't think that idea is being implemented as well as it could be.