You can argue that globals are sometimes a reasonable solution, but you damn-sure can't argue that you *need* singletons in application-level code. Singleton's enforce *singleness*, they have no other useful property that isn't represented by simple globals. To even get that singleness, particularly in a thread-safe manner, you have to jump through all kinds of extra hoops and, having achieved single-ness, still have to pay the tax of rigidity imposed by said singleton. If you're of the mindset that "globals" and "singletons" are interchangable, and that the latter is just an OOP version of the former, then you are dangerously misinformed.

99% of the time, singletons are not needed and, in fact, undesirable. Most often the programmer is confusing the "want" for singleness with the "need" for singleness -- most often in the form of lazy coding: "But I don't *WANT* to pass that manager as a parameter!" and somewhat less often in the form of believing that singletons are better or "more excusable" than a simple global, both of which are actually in the exact opposite direction of good design.