n order for programming to progress to the next natural level ( i.e programs writing programs for programs ) rather than simply getting bogged down with delivery systems, content management, and business logic, the code itself must be capable of encapsulation in order to managage the complex relationships that need to exist.

You misunderstand. I was *never* debating "encapsulation". I myself work on "large scale" (URGH) enterprise management software for major OEM's. Very large scale. Mission critical. Yes, I can fry your data for you. Java apps of huge behemoth size.

Anyhow, 'encapsulation' isn't the end all beat all -- it's a subset and/or implementation of more important concepts 'abstraction', 'isolation', and 'modularity'. These abstractions need not be defined by classes, but rather, they can be defined by data, for after all, objects are but a way of grouping methods with data that applies to that data. This is often a mistake junior programmers make. They are taught 'encapsultion', 'inheritance', and so on as chief concepts (and can repeat the word verbatim), but they miss the aim of such concepts. Interfaces have been defined (albeit not cleanly) with function pointers and structures for a long time before OOD became more PC than other forms.

Once folks write getter and setter methods for everything, through in a few static accessors (cough...PC globals), or chain objects such that an entire object tree is accessible...essentially encapsulation is just an illusion. It's just harder to get what you want, but you can get it. And if you need it, you'll code in a way to get there. 'encapsulated' interfaces can still cause huge ripple affects with changes, they rarely get isolation & modularity correct -- which are concepts that are not OO specific.