You can just think of objects as containers, if you have a bunch of functions that are related, but don't need to hold a specific "state" around them, then the

You can just think of objects as containers, if you have a bunch of functions that are related, but don't need to hold a specific "state" around them, then the class is essentially just a grouping (i.e. classes that just hold static methods), if nothing else, having them in a static class makes code more readable and organized, IMO. Its always been my belief that OO makes code easier to understand in a large codebase but I would agree that not everything necessarily fits cleanly into an object, however I can't envision any other way of making a large project work for a higher level business application, I can see why they may not be as needed in lower level programming. You mention that you're a systems guy, so maybe the type of programming you do isn't necessarily best suited for OO, but for some domains, like business-specific web apps I don't think there would be another logical way of organization, it is a form of fairly "high abstraction" from the 1's and 0's so it only lends itself to certain uses