Separation of concerns (the Model, View, Controller) approach is, of course, the primary goal of all of the modern frameworks (including Catalyst, Dancer, and Mojolicious, as well as those popular in other languages). And I agree that the notion of embedding the bulk of an application in the HTML (ie, in the template) is the wrong way to go. But I think you're taking it a little far when you say:

If you are still "embedding programming_language into HTML," then I cordially advise you that you should re-consider that approach.

Surely you must mean that the application's business logic should reside in "model" code, the web application's minimal wiring should exist in "controller" code, and the view should reside in the templates, wherein embedded logic is kept to the minimum required, no more, and no less (which is different from reconsidering the concept of embedding altogether).

Maybe it would help me to understand the line you're drawing if it were accompanied with an example.

Sure, Dave.   What I am referring to is the original concept that a PHP file would consist of HTML code with <?..php code here..?> tags stuck all through it.   For instance, if you wanted to generate an HTML table, you literally enclosed the <tr> tags and so-forth inside of an inline PHP loop.   The idea was that the output would consist of the un-bracketed (HTML) content interspersed with the output that may be produced by any PHP code wherever it appeared.   There was (by design, actually), no separation between the two.

That turned out to be a really bad idea, and the PHP community quickly moved away from it to adopt MVC strategies that are in many ways quite similar to what one now sees being done in Perl, et al.   The language itself also sprouted many new features, including many similarities to Perl and an openly-acknowledged copy of its regex technology.   I guess good word spreads fast... ;-)   Plus, the Zend folks include some really crackerjack coders.   PHP now does MVC along with the best of them, but the language emphatically didn’t start out that way.   (But hey, it sure seemed like a perfectly good idea at the time ...)

I think you're being awfully generous in suggesting that "the PHP community" has moved away from the everything-in-one-file method. Outside of some big projects like Drupal and work being done by some elite coders, I think most PHP scripts still mash it all together. From what I see, although there are still plenty of CGI/HTML scripts out there, Perl is way ahead in that regard.

That ability to toss a little code into an HTML file is what made PHP popular, after all. You didn't have to deal with file permissions or any of the stuff that made CGIs tricky at times; just stick your code in the page. That method makes large projects nearly impossible -- systems like Drupal and Wordpress are a mess, even with separation of code and layout -- but it makes the quick-and-dirty stuff quick. Take that away, and you're left with what, about a thousand inconsistently named functions?

Aaron B.
Available for small or large Perl jobs; see my home node.

these days, neither does PHP(!)

I really wish that were true, but it isn't, at least in my limited experience. The worst offenders seem to be some of the big guns like Drupal and Joomla (I've not looked at WordPress in sufficient detail to know)!

Those systems positively encourage template files that are a sea of PHP immersed in an ocean of HTML with the result that you can generally find neither the forest nor the trees.

Having worked with PHP extensively over the last few months I can confirm all the rumours that suggest PHP took only those parts of Perl the author understood (not very much actually), reimplemented badly those bits that weren't understood, provided multiple inconsistent implementations where there were several alternatives, and then added functions for anything anyone ever asked for. The result is not good!

That's the templates though. Intermingled code and HTML are par for the course when it comes to templates. (TT2 does this just as much. Example from the documentation. It's not Perl code intermingled - it's worse; its a whole other Turing-complete language.) The files that the browsers actually hit start with <?php and don't contain a ?>, so they're PHP all the way; not HTML with little chunks of PHP.

There are plenty of awful things about the design of Drupal. This is not one of them though.

Update: in case anyone doubts the Turing completeness of TT2...

use Template;
my $template = Template->new({
    POST_CHOMP => 1,
    EVAL_PERL  => 0,  # note: false!
});
$template->process(\*DATA, {}, \*STDOUT)
    or die $template->error;

__DATA__
[% MACRO fib(n) BLOCK                    %]
[%   IF (n < 2)                          %]
[%     n                                 %]
[%   ELSE                                %]    
[%     fib(n - 1) + fib(n - 2)           %]
[%   END                                 %]    
[% END                                   %]

Fibonacci sequence...
[% FOREACH i IN [ 1 2 3 4 5 6 7 8 9 10 ] %]
[%   fib(i)                             +%]
[% END                                   %]
[download]

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

I`ll most certainly reconsider what you`ve said. Thanks.