The normal (TM) way to create websites is to keep code from different languages mainly separate. The exceptions I have seen so far include generating Perl classes from database tables, embedding HTML and/or DHTML in Perl and embedding javascript and/or CSS in HTML files. These are low-overhead solutions, though not as elgant as they could be. I have also seen a product that stores all code (UI, processing, database meta-language, triggers of various kinds) in the database and has a form-painting interface. But that last solution was rather inflexible and performed too poorly.
And whereas a popular DB solution is to use DBI to send SQL to a database, it's a bad idea to combine objects with embedded SQL in a mult-user environment instead of encapsulating properly designed transactions (e.g. using stored propcedures instead).
It seems to me that Perl offers the tools to produce a single-language (*) solution which both performs, manages transactions properly and can be easy to use. For example, a framework class could inherit HTML, CSS, javascript and database object generation classes, all capable of generating tables and UI sources from a single Perl class designed by the (user-) programmer.
The question I am seeking wisdom for is - is it worth it to fly in the face of the traditional approach of separate sources for different languages? Or to put it another way, is maximising language integration a holy grail or is it destined to being over-compromised and unpopular?
Update: * I am not considering rewriting one language in another, but instead using Perl to integrate the sources of different languages that pertain to one conceptual class, in the interests of maintanability
One world, one people
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |