Was that an example? ;)

There is a real cost to setting up a framework that nicely separates different kinds of code. This cost is seen in additional up front complexity in design, the need to be sure that tools which are used for each component play well with whatever system (eg templating) you use to get the components to interact, additional layers to worry about, etc.

Well, in the general case I would agree enthusiastically. But in the specific case...

HTML::Template has very little cost. There isn't the design complexity of other template systems, and it really doesn't try to do much. It's about like SSI, with simple loops, and in the CGI instead of the web server. I've never seen or heard of compatability issues. Anything running in apache using CGI.pm can work just as well using HTML::Template, because all you're really changing is the print call(s), and how you generate the strings to print.

I guess I am just too lazy to run from a marginal upfront complexity, if it means less calls on my cell phone, "I updated the login CGI and now nobody can connect!"

Maybe it is just because I usually get idiots for project managers. :) Someday... Someday...

Actually if you look closely, I made sure to make my statement not a categorical statement. That is why I said "most", not "all".

But to the real question. In this specific case I definitely disagree. A set of glorified marked up HTML pages that parallel a set of CGI scripts does not necessarily a maintainable design make. Suppose, for instance, that you are putting together website where several of the pages have a large chunk (say about a third) of the page in common. What approaches would you take? Well here are some options:

1. Maintain the HTML for those pages as HTML.
2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages.
3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common.
Here are some of the maintainability implications.
1. Maintain the HTML for those pages as HTML. Well HTML has no real include mechanism so that common chunk needs to be maintained in parallel between those pages. If that chunk includes dynamic content, this could be an ongoing issue. But you do preserve the ability to use standard HTML WYSIWYG tools to modify the page.
2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages. Tools like the Template::Toolkit make this easy and natural to do. You now lose the maintainance problem of maintaining pages in parallel. However you have also lost the ability for designers to conveniently use WYSIWYG tools on your pages as a whole (they can on each component, but more knowledge is needed to work this way), and now people maintaining the HTML or code needs to understand the layout of your templating system to work on your site.
3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common. Again you lose the maintainance problem of maintaining pages in parallel. On the flip side you now have code and HTML mixed together. But you don't have the conceptual overhead of a template system to work with and the mix of skills required is fairly readily available.
IMHO any one of these solutions could turn up best in a real project depending on the skillsets of available developers, and the scope of what needs to happen. I would be inclined to go with the first in a small site where layout developers have considerable input and want to keep changing the look and feel of the site. I would be inclined to go with the third in a small site where the look and feel of the site was pretty much fixed but there are a lot of developers and a large variety of dynamic content. (Pages almost the same but different data sets and different fields driving it.) I would want to go with the second for any significant site with both ongoing data and design maintainance required.

This is a classic maintainance problem, just restated in terms of the web. Maintaining parallel content either requires ongoing extra work, or it requires that you find a way of factoring your problem. With the web your issue is that the design tools that designers like to use tend to not play well with trying to factor the problem. The three answers I gave trade off differently depending on what resource you can most easily waste: HTML designer's time (on synchronization), programming time (on figuring out how to modify code to produce different HTML), or a bit of everyone's time (on setting up and maintaining a clean separation).

Well, to beat a dead horse a little... my statement was catagorical, and "smoke alarms are always good to have in your home" is also catagorical. :) (though really, "home" is a qualifier, as was the exception for programming communities I gave, so maybe neither are really catagorical enough to make them probably untrue on that basis.)

I am not sure about your "parallel" idea. With the straight HTML sollution it could be, but also you could just use an SSI for the common chunk, making some sort of intersection.

I think restating the classic problem in the terms of HTML doesn't work, because HTML isn't a programming language, and non-programmers like/need to change the way it looks. That's the point I was trying to make. It is not a point I would be making in a typical programming case; in a typical case, I think that it is okay to expect people to put the time in to understand the tools they are going to use, and that expectation totally changes the values of the tradeoffs. Then I would be looking for the simplest sollution. In web design, though, I am looking for the simplest sollution for two groups of people, and I think the choice ends up being between mediocrity for all (HTML with SSI, or CGI.pm) or seperate quality sollutions for both groups (simple templates).