>> And this time I'm not being insulting. Your programming umm techniques seem to involve snuggling right up to the database. <<

Well, I won't argue with that. (Except possibly the meaning of "snuggle", see below.)

>> It is how things like Clarion and XBase worked. <<

I am not really talking about DB-engines embedded into the language itself (although I really seemed to like that). Such is not necessary to rid most of your middle-men structures.

>> However, there are applications where the role of the actual structure of the database is quite secondary. <<

Do you mean that the domain somehow is lacking the need for flexible collections, or some sort of hardware speed constraint?

I view tables no more as "just an add-on" than youses view OOP as a mere "add-on". I don't just talk to them, I surf on them.

>> The programmer(s) writing the application has no need to know or understand how the data is laid out in the tables, only that when his code needs to get and put it, that it can. <<

To me, tables are the most flexible collection interface technique known. If the relationships and views of things are likely to grow or morph, then it is hard to beat a relational table interface.

I notice that many people try to use code to model the domain and relationships between things. I much prefer tables and relational algebra. It is like specifying a formula for a repeating pattern instead of physically repeating the pattern itself. More compact and easier to change. It can be almost likened to using the Manderbolt (sp?) equations instead of carrying around a jillion GIF's.

>> In fact, in a large project, such a separation enables multiple people to easily and reasonably cleanly work on their areas of expertise: for instance, the programmer doesn't have to be an expert in database design and the database designer doesn't have to be a UI expert. This "separation" is one of the under-pinning goals of object-oriented programming. <<

I don't see how OOP helps this. A division between an application programmer and DBA (RDBMS) is quite common. In some cases the programmer only has to call stored procedures and never touch SQL syntax (but I do not necessarily always agree with that technique).

I am not sure what you mean by "UI Expert" here. UI API builder? Application interface designer? Application interface programmer?

P/R offers division of code by "tasks". I have yet to see how OOP makes cleaner and more consistent divisions than this. One can walk into most P/R shops, look at the DB schema and task (module) names, and within half-an-hour or so have a fairly good forest-level view of the application. OOP is harder for this because there is no *consistency* from one OO guru to another. You don't have the world-wide code-by-tasks-DB-for-entities division consistency that P/R has in OOP. Further, the bad habit of excessive protocol-coupling found in many OOP designs is yet another grokability and manageability fault. Just because the implementation is hidden away is no guarantee that the interfaces are not messes. Managing interfaces is just as important to software manageability.

>> Basically, so long as you insist on not having this separation, object-oriented programming will never seem like a good idea and attempts to persuade you otherwise will be fruitless and frustrating for all involved. <<

I just don't find code a good place to manage high-level complexity and repetition from. OOP is too code-centric IOW. My head can grok and manage better when control and relationship information is factored into tables. I find them more compact, more concise, sort-able, filterable, and multi-viewable than code structures. (Fancy IDE's try to approach this in proprietary ways, but still have problems factoring out repeated packaging of items. They are just poorly trying to reinvent the collection management wheel already perfected by relational tables.)

Tablizing control information makes it lean, mean, and clean IMO (relative). If your neurons work better under different information management and representation arrangements than mine, that is fine. Just don't try to extrapolate that onto me. After all these years I know what the hell my head likes WRT org techniques more than you ever can, because you are not me. (I am sure you are relieved about that fact.)