Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl?

by autarch (Hermit)
on Dec 10, 2003 at 21:03 UTC ( #313870=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl?
in thread J2EE is too complicated - why not Perl?

None the less, by their own admission, there are no pure Relational Model DBMs available, and so my judgment is based upon my experience of those things that do exist. It could not be otherwise. I tend to be extremely suspicious and slightly dismissive of "theoretically pure" arguments and propaganda in general. Until I, as a run-of-the-mill coder am given the opportunity to use a practical implementation of such theories, they are nothing more than that, in the practical sense.

That's a bizarre attitude. So you have something against theoretical physics? There's nothing wrong with theory. It's useful. If the theory has yet to be implemented, that's not necessarily a condemnation of the theory.

However, a large number of very clever people have put the best part of 30 years getting RDMBSs to where they currently are. Whilst some of the marketing decisions taken may have been done on the basis of commercial greed and/or in an absence of a full understanding of the pure Relational Model, not all those that worked on all the current implementations will have been totally ignorant of, nor blind to the theoretical goals.

Actually, they've spent 30 years on developing SQL DBMSs. Unfortunately, for whatever reason, SQL became the standard way back when (in the 70s), presumably because it's "simple". And since, in comparison to what came before it (network & hierarchal DBMSs), SQL is indeed a huge improvement, it quickly became the dominant player in data management. That strongly discourages the creation of a truly relational DBMS, since it could not be 100% SQL-compatible. Market forces being what they are, the big 5 would rather spend time and money on more sure things, despite the technical problems.

Anyway, I'd strongly suggest reading The Third Manifesto. If you don't want to buy the book, reading most of the articles on Database Debunkings will introduce many of the same ideas.

I should also point out that I think Pascal's tone is terrible. It's too angry and condescending, which turns a lot of people off. Nonetheless, the technical content is excellent. Too bad he doesn't seem to understand the old adage about flies and honey.

  • Comment on Re: Re: Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl?

Replies are listed 'Best First'.
Re+: J2EE is too complicated - why not Perl?
by BrowserUk (Patriarch) on Dec 10, 2003 at 22:31 UTC
    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.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://313870]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2022-01-26 18:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (69 votes). Check out past polls.

    Notices?