> Perl just didn't lend itself to well-structured code. … once your CGI script started spanning multiple .pl files, you were gonna have a bad time. You would s

> Perl just didn't lend itself to well-structured code. … once your CGI script started spanning multiple .pl files, you were gonna have a bad time. You would split your app across .pm files (modules) not .pl (scripts). At the control layer this meant classes based in CGI::Prototype, CGI::Application or the like. At the model layer it would be DBIx::Class or Class::DBI. View would be Template. Then in each layer you’d have a hierarchy of classes like every other language (as .pm files). Perl has its issues but simply organizing code in a tidy way was not a problem. Problem had more to do with the readability of code, lack of basic OO facilities, awkward split between “references” (pointers) and direct values. > Along came PHP. It had a few advantages right out of the gate: (a) you could inline it in html, and I really can't overstate just how amazing that was at the time -- suddenly you didn't need templates anymore, you just used the html you already had While this was absolutely a win in terms of convenience when taking a site dynamic for the first time, and made PHP wildly popular especially for replacing old cgi scripts (va apps) it seems to have made PHP worse from a maintainability standpoint than well written Perl when it comes to sizable web apps. In terms of libraries Perl had a very nice standard lib plus CPAN where the code and docs were generally to a very high standard. I don’t think PHP won at a code architecture level, it won at the very things that tended to produce the messiest, most amateurish Perl code that gave the language a poor reputation - hacking up a quick and dirty solution. It was superb at that and I admire it for that. But let’s not overstate the thoughtfulness of early PHP. It was an abomination of a language in many ways.