It is a fact in any project with more than one user. Either it is open source, and there will be lots of maintainers, or it is a commercial project and will also have other maintainers. So, rather than being an opinion, it is a general known fact in programming that mixing languages in a single file is less maintainable than having seperate files for seperate technologies.

The part that is opinion is, if it is important enough to make it so that it can last. Maybe it is a page that won't be around long anyway. Or maybe it is a personal project. Or a project for a perl-centric website where there will always be people who can maintain it. But it is still good to acknowledge the real life difficulties of each choice.

Like most categorical statements, this is false.

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.

Now I do not deny that when you mix languages together, that makes that piece unmaintainable unless you have people who understand and can easily switch between all languages in question. I likewise would agree that any good program is factored and a natural factoring into kinds of tasks should show a fault line where you switch languages. Furthermore I absolutely agree that the decision of whether or not to separate your HTML from your code has huge implications for how you continue to work from then on.

However I strongly disagree that the trade-offs are so clear that in any project with more than one user it is best to split along that line. I even disagree that the answer is always obvious for projects with many users and multiple developers. For very large projects with ongoing maintainance and customization going on among separate teams, it would be insane to not have that split. For small tasks of the form, "Gimme a working web interface to do X, it doesn't have to be pretty." it would be insane to insist on that split. Between these clear extremes there are definitely some shades of grey.

Like most categorical statements, this is false.

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...

I still humbly disagree. Separating Perl and HTML into separate files does not have inherent advantages -- unless it is a multiuser project AND some of the users are HTML designers but not programmers.

This is naturally the case when developing (as you say) a commercial project or an open source product. But I refuse to believe that the majority of Perl/CGI programs fall into these categories. I'm not just talking about short-term web pages or personal web pages, but intranet web pages and applications where the HTML is simple enough for the programmer(s) to handle.

Is this really that uncommon? Am I alone in being a Perl programmer who can handle his own HTML without outside interference from non-programming web designers?

buckaduck

The programmer understanding the problem isn't the problem. :)

The problem in the intranet scenario is that it is very regular for another person to try to make changes.

In an ideal world these other people would keep their grubby fingers off... if you know of the secret trick to taming project managers, please post it for me so I can re-simplify my dynamic content methods. :)

--Paris