Month: August 2008

Why create?

August 10, 2008 Code craft, Community 5 comments

why the lucky stiff encapsulates so much in this tweet:

when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

So much to think about. So much explained on a few short sentences.

It also meshes beautifully with Habit 1.

I’m going to be rolling that around in my head for a while.

Why do designers fail to adopt Perl?

August 8, 2008 Advocacy, Opinion 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.

The first year of Perlbuzz

August 4, 2008 Uncategorized 3 comments

Perlbuzz is a year old today.

I just paid my first renewal for perlbuzz.com. It took about three weeks from when I first registered the domain name one night while brainstorming with Skud about a new newsy sort of site. The first news story: Further reports from YAPC::Europe.

Now, Skud is off doing other things, most recently her wiki at geekfeminism.org. Perlbuzz’s output has slowed some as I try to finish up my book “Job Hunting For Geeks” (not that that’s the title we’ll use) for Pragmatic Bookshelf.

What hasn’t changed at all is my appreciation for every one of you who reads Perlbuzz, or subscribes to the RSS feeds. Keep reading, and I’ll keep writing.

xoxo,
Andy