Why do designers fail to adopt Perl?

| 12 Comments

A Perlbuzz guest editorial, by Dave Everitt

As the "the glue/duct tape/chainsaw that holds the web together", Perl is all but invisible to most web users. It is still one of the best-established languages of choice, yet remains behind the scenes and out of the limelight. This "brand invisibility," coupled with the factors outlined below, has contributed to the erroneous perception that Perl is outdated or unfashionable in the glaring light of other more energetically-promoted solutions. Despite the continuing dominance of LAMP, what do most web designers think the "P" stands for? Not Perl.

Cultural perception and perceived popularity don't help anyone to make a logical evaluation; this is an attempt to put the record straight.

"Design? That's for designers!"

Many Perl monks (and other alpha-geek programmers) hold design in some kind of contempt. Here are some comments by Perl coders:

  • Don't trust designers with code:
    "...now you can pass "helloworld.tmpl.html" to your web designer to modify it in her/his favorite HTML editor. (Just tell her/him not to touch the HTML tags starting with "<TMPL_")" -- HTML::Template Tutorial
  • Design is trivial:
    "If you find yourself lacking as a web designer or generally couldn't care less, you can give your templates to a web designer who can spice them up. As long as they do not mangle the special tags or change form variable names, your code will still work." - HTML::Template Tutorial

This kind of wilful separation from design is a big put-off factor to newbie web programmers, and is endemic throughout the Perl community: "designers can't come in here until they're willing to learn serious code". In other words: "the aspirant must show humility". Understandable perhaps; and, once you start trying, the community is as helpful and friendly as can be. Just not overly welcoming to "designers"; in fact, some Perl websites appear almost deliberately or even proudly ugly. Perl templating solutions like HTML::Template or Template Toolkit get ignored by most web designers in favour of comfy, close-to-hand solutions like PHP, ASP.NET, whatever Dreamweaver offers, or younger and prettier models like Ruby on Rails or Python's Django.

Here's a more rational approach to the "design vs. code" separation:

"...the best Perl programmers are rarely the best HTML designers, and the best HTML designers are rarely the best Perl programmers. It is for this reason that the separation of these two elements is arguably the most beneficial design decision you can make when devising an application architecture." -- Jesse Erlbaum, Using CGI::Application

This remains true, except that increasing numbers of people and teams are becoming good enough at coding and design to handle both passably well, They're choosing to invest the time necessary to learn both, as the Ruby on Rails explosion demonstrated. The Perl community needs to respond with a makeover and, maybe, some key "we're cool" websites like Catalyst's website to help rescue Perl's dated image, even if many Perl programmers don't care about it.

Most designers want to be included in the "our site is cool, therefore we're cool crowd," not shoved in next to an ancient HTML website in ANSI colours.

Where are my web pages? How do I know what does what?"

Programmers know that effective templating separates logic from content from style. However, designers familiar with web pages and visual appeal are often used to working with actual files, unlike programmers who can hold everything in their heads, and in lines of code that don't look at all like what they're going to produce.

Instead of these cosy actual files (the static web pages), most templating means that a site's links call a script that generates the pages. In other words, your website becomes a web application program, with all the power and flexibility. The literal, clunky file-for-every-page website disappears in the process, and this is just where many designers get a bit lost in starting the journey.

Both the original DHTML and current Ajax are effectively still attempts to turn web pages into dynamic web applications. What isn't obvious to the designer is that these technologies have been around for ages. They don't see that secure and reliable interaction with the server, solid yet flexible programming in Perl can drive a zippy Web 2.0 site as easily as Ruby on Rails.

Designers who want to start programming sometimes fail to make the conceptual leap from web pages as static files, to web applications consisting of components and screens. Failing to make this leap means they fall instead between logic and content by defaulting to PHP, Dreamweaver templates, Cold Fusion, etc. Perhaps this failure to make the complete leap happens because designers feel uncomfortable without seeing the actual "pages" they're working with, or because the dominant web design software makes it easy to adopt its own default solutions.

Where are the "Perl tools" for Dreamweaver? All the publiclity and books read "Dreamweaver CS3 with ASP, ColdFusion, and PHP." If Eric Meyer can improve CSS support in Dreamweaver, could the Perl community do the same towards integrating Perl tools? A million design houses across the world might then at least see a menu item containing the word "Perl" in their favourite software.

"Perl is impossible to read!"

Perl itself can be no harder to learn or read than the PHP to which many designers default. Learning Perl is far from dead, now in its 5th edition, and is regarded as one of the best books for anyone learning programming in general.

However, Perl programmers often delight in the potential economy of the language, and their concise code can appear obscure and impenetrable. I've even heard good programmers, fluent in other languages, say "Perl is horrible" or "unreadable". Yet to a beginner, Java (to take one example) is far more "horrible", verbose and complicated -- just compare "hello world" in both languages.

Actually, beyond that initial step, how easy code is to understand depends on who does the coding. Precisely because there's more than one way to do it, Perl can be written as readably as any other language. Most times this isn't obvious to a beginner because Perl coders don't need to keep it obvious when they can use powerful shortcuts or write one-liners. With this in mind, my Perl monk friend replied to a draft of this article with a "line noise" of caution:

I wouldn't recommend it as a first language. It's a second or third language. That's when it becomes powerful. I wouldn't want to put people off programming by making them look at @s=map{s/_/!/gi}grep{!~/^#/}@p.

"Perl/CGI is slow (and gets slower with increasing server load)"

This isn't true with FastCGI FastCGI or mod_perl. But try telling a designer who may only just be discovering the unforgiving nature of the command-line that these are an easy install. Or persuading a popular shared hosting provider (where many designers are hosting) to supply them on their list of default options.

To complicate the issue, there's also a groundswell of opinion against the complexity of frameworks in general, with sites prototyped in Rails being redeveloped with other tools. Then there's the shared hosting debate.

Isn't there a gap opening up here for tried-and-tested but nicely packaged Perl solutions for web development? Can't we fit between a designer's static pages and a full-blown framework? But just try finding a good-looking Perl templating tutorial that shows off the kind of tidy, well-crafted and semantic XHTML and cutting-edge CSS that the best designers produce, or a one-click Perl template install with a good-looking promotional website.

Rails has demonstrated that speed isn't initially the issue. Ease, buzz, style and ubiquitous market presence are. Perl doesn't have to remain the dowdy elder sister -- given the same kind of push, it can go to the ball too.

"So what's a poor designer to do?"

If you want to develop your skills, ask "will I be using a programming language at least 2-3 times a week to actually do something; that is, as much as you currently use (X)HTML/CSS?" If not, you'll almost certainly forget what programming you learn and might be better off leaving it to "real programmers".

However, if you do want to develop those skills, a good route is to experiment with a templating system that encourages the separation of logic and presentation, like HTML::Template or Template Toolkit. Work through the tutorial websites and just get something working. All you need to know for starters is that HTML::Template fills HTML templates dynamically with data according to the logic in your Perl, or that Template Toolkit generates static pages from your Perl.

What you, the designer, must learn first

You do run Apache locally on your machine, don't you? Okay. Now get CPAN and use it to install Perl modules for your platform. Be mindful of case-folding if you're on Mac OS X Yes, I know there should be a guide to all this, but like all learning curves in big territories, there's no authoritative manual. To make it easier, perhaps there could be.

To make an intelligent comparison, you might want to try Ruby on Rails. The latest OS X already has RoR bundled. If you've done all this and are still committed to PHP, keep the logic apart from the design or tears of despair will follow. Steer clear of the convolutions that PHP allows, and note the following well:

PHP has full support for classes, attributes and methods, and supports object-orientation, but the key problem is that no one seems to use it! There is a vast body of sample PHP code on the web, but nearly all of it is absolutely dreadful. HUGE long procedures, no structure, little code refactoring, and intermixed code and HTML that is impossible to read and must be impossible to maintain.
-- Tim Roberts, Python Wiki

Anyone who has been there will echo "yes, it is impossible to maintain," but that's not the language's fault. It might not all be squeaky-clean, but there isn't a vast body of "absolutely dreadful" Perl on the web. As a designer looking to settle on a language, that's a very valuable pointer. If you've ever had to plough through lines of "impossible to read" and "impossible to maintain" PHP, you'll understand that although PHP can be written as well as any other language, it often isn't.

If ways can't be found to improve the overall quality of PHP authorship, well-styled bridges just need to be built for designers serious about programming to visit the Perl community. When they get there, they'll need to feel at home.

Dave Everitt is a print-turned-web designer/developer who internalised HTML and CSS in the last century and steadily developing Perl skills in this one. His work includes the roles of web designer, educator and new media academic.

12 Comments

There is a persistent fantasy among programmers of strict separation between design and coding. In this notion we hand our templates through an opening in the bulletproof glass and get them back outfitted in a spiffy new design.

There are tools and skills that can bring you closer to that state, but you never truly achieve it. There is always some tedium involved in decomposing a design into its parts and fitting in presentation logic. You wouldn't know that by the way some folks talk about templating solutions, as if they were cookie cutters.

As a programmer charged with animating a design, think more in terms of writing small, flexible tools (as you can in Template::Toolkit) to keep the presentation logic portions small. As a designer charged with bringing harmony to engineering's work, think of producing designs which adhere to standards, is readily decomposed into parts, and is amenable to automated acceptance testing.

Dave,

You have hit something here. I have been wondering the same thing (why Perl is near invisible in the general buzz area) even though I see the demand for Perl higher, by atleast a factor than the nearest so called "web languages". It definitely is not due to a lack of passion, I can personally attest to the passion of the perl user community but there is work to be done by the user community to pass the message to the extended community of designers, architects and managers.

Also, I am including an updated, Perl vs PHP vs Ruby job demand & salary comparison, which shows data from Q1-2007 upto Q2-2008.

Gone are the days where there is a distinct declination of responsibilities between coding and page design. I've worked in a number of shops and programmers, designers, and marketing all have to work together in order to have a successful product.

This isn't to say that this symbiosis is easy to achieve and maintain. There is always going to be a struggle between coders, designers, and marketing regarding the amount of "logic" within template, and there should be, because maintainability is a real issue. However, instead of seeing this as a negative, as a threat to one's empire, treat it as a good problem to have - it's a sign that folks want to get things done!

Naveen makes a good point about getting the word out to the extended community, there needs to be more marketing about Perl to let folks know that it hasn't gone away. Ruby on Rails gets tons of press, yet there is almost know press of Catalyst. A Perl shop I used to work in tried a RoR experiment, porting a portion of an existing Perl app to RoR. The primary reasons, I think, were a perceived lack of qualified Perl programmers (there's a lack of qualified programmers, period) AND a lack of knowledge of Catalyst.

Perl is incompatible with young programmers with brains accommodates to point-click-drag mouse operations.

Maybe a scalable redesign of PerlMonks would be a good, high profile, "look at how cool we are!" project for Catalyst that would serve two great purposes:

  • Show the world (and the Perl community) what kind of awesome site Catalyst can build.
  • Make PerlMonks usable and therefore more adoptable by the general public, including Perl newbies.

Perl has many features that ease the programmer's task at the expense of greater CPU and memory requirements like the automatic memory management; dynamic typing and so on.

I think you should use some of that Perl Foundation money to make some of these 'well designed, cool sites' because until somebody actually sees one it's only a myth.

Have a contest every so often and offer prizes - designers love to enter these contests to show off their skills.

just my 2 centavos

Are some designers just lazy? I work with designers who I can hand them a TT2 template, Smarty, PHPTemplate, etc... and they get done what they need to in a timely fashion with no complaints. I just tell them to make it look like the spec, and I'll make it work. I don't make them learn anything except what not to mess with (which is [% usually %] <?= 'pretty' ?> {obvious}). But, they seem to learn a little as time goes on which is very symbiotic.



The willful separation of code and display shouldn't be a put off to any newbie. They should embrace it. Ever try to read a PHP "system" where templates aren't being used? Or some very elegant Perl code with heredoc's for HTML sprinkled around? As the kids would say, OMG.



I prefer MVC to OMG.

As a designer who moved into coding, I found Mason (HTML::Mason, http://masonhq.com/) to be the templating/coding solution that worked best for me, though I did start with good, old-fashioned CGI programming.

Now, I'm moving on to Catalyst, but there's some serious learning curve, both in learning to to think MVC, and digesting ORM, which seems to be a stock part of all the tutorials.

I've done some PHP, an one place PHP has a clear advantage over Perl, and it's a big one, is in installation. One installer, one configure-make-make install run, and a small change or two to your Apache config and you're on your way.

Compare that to installing mod-perl/FastCGI and Mason and Catalyst. Even with CPAN helping out, it takes a long, long time. And every time you want to use expanded functionality, it's back to CPAN for another exercise in dependency chaining.

Part of the problem here is that CPAN installations are biased towards saving disk space, as opposed to providing maximum functionality. 10 years ago, that was a defendable bias. Now though, disk space is no longer dear, so there at least needs to be an option to tell CPAN that you want maximum functionality.

For example, I'd like to be able to simply install all of Catalyst: all plug-ins, modules addons and whatever, and all the necessary prerequisites, all in one go. By all means, warn me about the disk space I'm about to use, and ask me if I really want to do this. But give me the option of getting all the pain out of the way at once, so I can then focus solely on development.


Thanks for all the well-considered comments. Due to problems signing into PerlBuzz, I've saved up all my comments in a text file, but they're now long enough for an article so I've just submitted them to Andy asking him to put them up in response. When they're up, I'll add a link to them here.

But there's noone forcing you to use throw Perl 5 off your system to install Perl 6. The two can happily coexist, much like you work with Flash 4 at the same time as with newer versions.

Im using Perl for almost 2 years. Haven't encountered any problems in regards to design.

Leave a comment

Job hunting for programmers


Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.