I guess you and I are reading the OP differently. You seem to think that the OP wants some kind of magical anything to anything converter. I think the OP just wants something better than what he or she already has.

I'm rather puzzled that you think so negatively of POD, XML, and SQL. Are you really saying the world would be better off without them? That they are pointless because they don't eliminate the need to think about markup, serialization, or data relationships and integrity constraints? Marketing hype aside, I rather thought the purpose of all of these was to set us free (or at least make us more free) to focus on essentials - the things that make a difference, the little bits that really, really, need custom treatment.

Or are you being rhetorical? You do mention at the end that they brought compatibility and interoperability. Even if you are being rhetorical, I think we need to balance the picture a bit.

Ok, POD only provides a framework, but why is that a failure? And how is that a straight-jacket? With POD at least you have options to use many different markups and you have a framework that can be used to add new ones as you see fit.

XML has its limitations, but it opened up a generation of machine independent serialization - YAML, JSON, SOAP, and many others to come. We may still have to write custom interpreters for each and every XML schema, but at least we don't need to write them for each and every schema and machine architecture. And we only need to write the actual interpretation of the schema - we don't have to hand parse the file itself. Do you really want to go back to the days where everyone believed that "real data" gets transferred in hand-crafted binary formats? Where comparing your dumped data to expectations almost always involved squinting at control characters?

As for SQL - the standardization process is a mess. But SQL, dialects and all, gave us a common core language for expressing data relationships. I can still remember projects back in the 1980's where we had to hand craft queries in C to navigate linked lists because the DMBS didn't support SQL. It wasn't fun and it meant that anything you did was not 20% or 30% locked into a particular DBMS but 98% locked in. Would the world really be a better place without the (mostly) common DBMS interface we have today?

Best, beth

Update: acknowledged that BrowserUk may be taking a rhetorical position.

In reply to Re^4: polymorphic data-driven rendering? by ELISHEVA
in thread polymorphic data-driven rendering? by metaperl

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.