There's nothing wrong with theory. It's useful.

It's useful... to theoretical physicists, or theoretical data scientists. It's distinctly not useful to the structural engineer trying to make his structures stand up to earthquakes, nor the coder, trying to make his code run, effectively, on-time and within budget.

It's all very well being told that if a TRDBMS existed, then you wouldn't have a need for an OODBMS or OO extensions to (existing, concrete, usable now) RDBMSs or flat files or whatever. Until a TRDMBS does exist, the theoretical correctness of the Relational Model is exactly as much use to me, as a coder, as String Theory, or Chaos Theory or Heisenberg's Principle. They are simple things that I can read about, wonder at, wonder more at the intellects that arrived at them, but will probably never truthfully, fully understand. And indeed, would probably be foolish to expend too much energy upon trying, as they (including theoretical TRDBMS's) are unlikely to have any impact on my daily lot. I don't doubt the veracity of the claims made, nor belittle the achievements. I was just indicating that until I can use those theories, in a practical way, to get my job done, they have little more than curiosity value to me. The keyword in my previous post, and this one is "practical".

they've spent 30 years on developing SQL DBMSs.

I would argue that most of the effort has gone into the physical implementation of the RDBMS. Optimising the storage, caching, query optimisers and the like, rather than the SQL part. It does seem on the basis of the last two days of reading the D4 manual, that the major source of the problems with existing RDBMSs is (less) to do with the implementation of the physical side of things and much more to do with the inadaquacies of SQL itself.

At least, that is the message I am getting from reading about Dataphor (see: (OT) RFI: Dataphor and/or D4 for more/better links].) If you have any knowledge of it, or decide to take a look (2 days is no exaggeration, and I'm only half way through), then I'd be really interested to hear your thoughts.

My dissatisfaction with SQL and RDMBSs is born entirely of their practical limitations, that I encounter when trying to use them for practical applications. I know the limitations, because I've spent 20 years trying to code around them. It would seem that I have, through my practical experience, arrived at a similar set of conclusions regarding the limitations as those approaching the problem from the purely theoretical level. Indeed, if I read between the lines of Fabian Pascal's ...er...writing, then I can conclude the he and I don't differ greatly on many of the problems. The difference is that his answer seems to be

"Well, if you're to dumb to be able to understand that those limitations are routed in the perversion of the Relational Model, that is the currently available crop of so-called RDMBSs, then your either beyond help, or desperately in need of my book/lecture/white paper/educational services (ring O800-I-COST-ALOT now for your discounted-but-still-exhorbitant access to my superior intellect!"

Man. That guy has forgotten a lot more than just that old adage:)

The Third Manifest is on my book list, currently at position 11. This may change. I did locate a .pdf slide show described as "Background material for The Third Manifesto", which whilst very terse, rang enough familiar bells in my head to warrent my buying the book.

For now, the D4 data language manual is opening my eyes to the possibilities. There are three (and a bit) nice things coming out of what I read there.

1. This is a real (practical) product.

   Cons

   Very pricey at $5000/developer, especially when you consider that you also need a (capable) RDBMS to underpin it.

   The three cardinal sins (with respect to a large proportion of the perl community!)

   1. It only runs on windows.
   2. It needs the dreaded .NET.
   3. It promotes the concept of visual (small v) application development.
2. Given an appropriate DML (query language), an existing RDBMS (Currently MS and Oracle, with MySQL in beta) can support user-defined, compound datatypes (read: classes).
3. There appears, to my eyes, to be a surprising correlation between the fundamental structures of D4 and what (I imagine) P6 will look like. Not at the syntactic nor even semantic levels, but deeper. You might have to squint a bit to see what I mean :)
4. There's not a complete dissimilarity between D4 and some ideas that I've been kicking around for a while, though theirs are way better defined and thought through.

Anyway. Thanks to your original post, I have found (several) new areas and angles to explore in my mindware project. I'm not anti-RDBMSs per se. I think they are over used on small projects, under-used on large ones and badly used almost always. They also don't lend themselves to programming, though they may be extremely valuable for managing data. Scheming that data so that it can be used from programming languages that have to deal with the Less Than Ideal-Real World is, for now, clumsy & awkward and as such makes programming applications harder than it should be.