in reply to Prettier Perl websites
Having worked with designers, I can say it doesn't matter which language is easier to learn, because most don't learn it in depth, they just dabble. What matters when building either complex web applications or CMS-based websites is how efficient you can make the workflow between developers (back end) and designers (and front end developers). And that means the interface between the two, which is usually the view, the templating system. How easy it is for a confident designer to get to grips with it to achieve what he wants, to look at an existing template and modify it for a new design, a new section, or some ajax interactions.
And perl is let down on that front by hugely powerful but hugely cryptic languages.
I have written several frameworks, CMSes and ecommerce systems, and have come in as team leader, division head, CTO in several companies. I am no super expert but I consider myself pretty savvy in about 5 or 6 languages, and because I have an interest I dabble in a lot of frameworks, CMSes and app engines. And I have as a result built things (or made people build things) in dozens of different templating languages.
But I still remember in 2004 looking at the code for RT2 (we were using RT1 at the time, heavily reskinned to look like we wanted to), looking at the templates to evaluate how easy it would be for our designers to reskin. It was a shock, since I couldnt figure out how I would start to reskin it myself, let alone get even my most tolerant-of-in-development-trial-and-error designer to get to grips with it (and this would be the guy that managed to make plone not look like plone!).
Get the right kind of templating (both the code itself and the architecture) and your designer can do a lot of work and logic on their own, without needing a developer's involvement. This means that your designer and developer can sit down, play with wireframes, agree on data structures and parameter names, and start working in parallel.
Most often when I came in a company which used perl, I would find that most front end changes were done by the developers. The designer(s) would create mockups and HTML, and the developers would then plug the code in, and make templates. They would also do all changes to the templates. This is hugely inefficient, it makes the devs into double bottlenecks, and is frustrating to everyone involved.
Why does it happen? Because the most powerful and common templating options on Perl are meant for developers, and the result is developers doing the templates. Yes, it allows for all sorts of shortcuts and efficiencies from a developer's point of view, but it also doesn't help really good separation of concerns.
And I am afraid that means that a designer downloading a perl based app, cms, or framework and trying to get to grips with it might get put off right away when they look at the templates (and yes, they look at the first, because once the basics are in place that is where they expect to spend all their time, on an admin screen and in templates). To get some of these people to come and play with us we must not worry about the language itself or the modules and frameworks - we need to start with the templates.
Iphigenie aka Joelle Nebbe-Mornod
(PS: people diss HTML::Template because it is not as powerful, but HTML::Template with custom expressions is more empowering of a normal designer than the Mason / TT can be. Although the best option for me remains Petal. I wish someone would port Kid to perl)