Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

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

by autarch (Hermit)
on Dec 09, 2003 at 06:25 UTC ( #313371=note: print w/ replies, xml ) Need Help??


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

Some parts of your post read a little like "I have a relational hammer, so the whole world looks like a Codd defined nail":) Please take that in the humourous manner in which it was intended. If you do have any interest in looking at an alternate viewpoint, you might like to read The OODBMS manifesto. The word "manifesto" kind of put me off reading it the first time I was refered to it, but I bit the bullet and read it anyway and was glad I did. It's not a that long. A hour or so should do it as a first pass.

In response to this, and some other OO manifesto thingy, Chris Date and Hugh Darwen wrote The Third Manifesto, which details what a truly relational DBMS should provide. SQL does not adhere to relational theory, and so comments to the effect of "I've used relational DBMS's and they don't do what I need ..." are incorrect, because AFAIK there are no truly relational DBMS's.


Comment on Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl?
Re: Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl?
by BrowserUk (Pope) on Dec 09, 2003 at 15:25 UTC

    Thanks for the link. I will pursue follow up on it vigorously.

    It seems that the guts of the argument is only available by purchasing a book -- which makes me a little suspicious --, but various snippets and stuff I've run across whilst trying to track down further information have intrigued me enough that I will be adding the book to my list.

    It looks like it will be interesting to track the two sides of the argument through and see which one wins out in the long term. Unfortunately, it looks like the long term is likely to be really quite long:(

    Trying to track down further information I did come across this rather pertinent quote.

    I use relational databases in my work every day. Bricolage of course runs on PostgreSQL, and I've done some work on DBD::Pg. But after using various RDBMSs over the years (Access, MS SQL Server, DB2, MySQL, Oracle, PostgreSQL), I've come to one inevitable conclusion: RDBMSs are all just total crap. Don't get me wrong, I think that they have their place. I just don't know what that place is. But no decently designed object system that I've worked on (let alone a poorly designed system) has found an elegant way to interact with databases. Sure, DBI makes things easy for Perlers in that it provides a pretty standard, uniform interface for accessing databases of all kinds. But if you're designing even a moderately sophisticated application, you still run up against the complete incompatibility of object-oriented design and relational storage. They're just completely orthogonal to one another. --Online Exchange, http://use.perl.org/~Theory/journal

    As the current Quote of the Week at www.dbdebunk.com. I'm not sure if it is being quoted as a good or a bad example, but it is at least good to know that I am not entirely alone in my thoughts that RDBMSs and OO are not a good fit.

    It is quite possible that I fit into one or more of the categorise of people described by this snippet from apro true relational model wiki

    Drawbacks: It's never been fully implemented. This is by far its biggest handicap. In spite its simplicity, it's likely you'll find lots of developers, architects, DBAs, book authors, committees who have no clue, but pretend that they have. After all, it would be quite embarrassing for someone to admit that he doesn't know what the RelationalModel is. The fore mentioned category of people who have no clue usually enlist a ton of invented drawbacks like: it has limited expressive power, doesn't support "complex data models", joins are slow, doesn't support navigation, doesn't support complex and/or directional "relationships", doesn't support object identity. Number 1) and 2) usually generate a vicious circle, because DBMS vendors react to what the market demands and spend money and time implementing purportedly useful extension, which are in fact not only less useful than having a true implementation of the relational model, but they are actually harmful. These extensions tend to be generically called Object/Relational features.

    In which case, it may well be that despite my years of trying to understand them, I have allowed my judgment to be impaired on the basis of my experiences with trying to make those RDBMSs that exist now, and the features they offer and the awkwardness that I have encountered on trying to use them in the OO context, to influence my judgment about the Relational Model too hastily.

    It may well be that I am simply incapable of understanding the full implications of Codd's vision, and that the current big 5 implementations of that vision are nothing more than half-hearted attempts at it driven solely by commercial need/greed rather than Relational purity.

    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.

    Whilst it may be true that given a real-life implementation of the full Relational Model, as so insightfully envisioned, and mathematical proved by Codd, that the problems I (and others) have encountered trying to utilise those apparently poor substitutes that currently exist might disappear.

    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.

    That, despite all their combined efforts, huge amounts of money and the considerable amount of time that has passed, there is still no True Relational DBM available, for money nor love, tends to indicate (to me at least) that maybe that model is too grounded in its mathematically provable, theoretically correct high place. That maybe today's computers, or maybe your average Joe Coder are simply not ready or capable of implementing that ideal. There are other examples of such theoretical, technical ideals that human kind hasn't yet succeeded in reaching. The one that comes to mind is the Nuclear Fusion Reactor.

    In the meantime, your average Joe Coder has his daily task of trying to earn a living, producing systems that work now (and are usually wanted yesterday:). It's inevitable that he will continue to use the best substitute that is available now. And he will continue to utilise, possible flawed, practical approximatations to "full understanding" of the relational model in order that he can make use of the RDBMS. If that means that his practical approximation is less than a full understanding and places him in that "...fore mentioned category of people who have no clue...", then he, like me, will probably accept that condemnation openly, in the knowledge that he is almost certainly one of a great many like him. In fact, I would say that he is probably in the majority.

    Whilst it may well be that there are a small group of people that "know better". One has to wonder why they are busying themselves writing books and presenting lectures, lauding their superior knowledge and decrying Joe Coders lack of understanding, rather than implementing the full Relational Model in a practical, usable product?

    Update: After posting this, I came across this artical]. The artical sets out to explain why there is nothing wrong with the Relational Model and why all the things that people claim are wrong with it are simply the miunderstandings of the misinformed masses. However, it does, through it's tone, words, conclusions and context, illustrate exactly why I am actively dismissive of those that expound this view -- much better than I ever could.


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

      The primary author of the dbdebunk website places quotes he considers to highlight issues in understanding of the relational model by the unwashed. Fabin Pascal hates OODBMS and considers the whole of OO to be a dead end in computer science that should have been aborted awhile ago. He links to several sites critical of OO. He does bring up several issues that makes you think and he should be read, but all he says should be taken with a grain of salt. My personal experence with OODBMS is that they do under load grow very slow, much slower then a equally loaded RDBMS(or as Pascal would rather put an SQLDBMS)
      MADuran (who forgot his password)

        Thanks for the insight. I was rapidly arriving at similar conclusions:) In fact, just prior to reading your post, I made an update to my post which links to an article by said Fabian Pascal which, in his own words exemplifies exactly why I am skeptical of him, and those who share his POV.

        As you say, definitely worth reading, but there is an underlying tone that makes doing the reading more than a little grating.

        It could be countered that the problem with the majority of the current crop of OODBMSs is that they are little more than a thin veneer upon incomplete implementations of the RM. As such, I too have experienced the downsides they exhibit. However, the problems I have encountered with the performance are addressable, and become lessened by the continued action of Moore's Law. The inherent inefficiencies of the OO to RM mappings are lessened by the continued performance improvements in hardware.

        The problems that result from the misfit between the OO view of programming and the RM are not so lessened. Being solely within the domain of each individual programmers ability to utilise a consistent model to store, access ad manipulate his data, the problem is one rooted entirely within the "wetware" part of the overall software development equation, which until we coders can upgrade our WiROMs (What i Remember Only Memories) with silicone implants, the problems will persist regardless of how powerful our workstations and servers become:)


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

        The primary author of the dbdebunk website places quotes he considers to highlight issues in understanding of the relational model by the unwashed. Fabin Pascal hates OODBMS and considers the whole of OO to be a dead end in computer science that should have been aborted awhile ago. He links to several sites critical of OO.

        The main thing to take away from his criticisms, IMO, is that OO is not suitable for data management. OO as an application programming paradigm is not necessarily a bad thing, and Pascal doesn't really get into that area, since his interest is in data management.

        ... then a equally loaded RDBMS(or as Pascal would rather put an SQLDBMS)

        By saying this, are you trying to imply that there's no difference? There is a huge difference. You may not know what makes them different, but you cannot equate the two.

      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.

        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
Node Status?
node history
Node Type: note [id://313371]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (9)
As of 2014-12-22 11:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (116 votes), past polls