Game over. We lost. Nothing to see here, move along.

[Simon Wistow]

On Thu, Nov 17, 2005 at 11:17:12PM +0000, David Hodgkinson said:
> Django and Rails demonstrably solved problems. In a kewl and
> entertaining way. With stories.

Almost all the best talks I've ever been to have been narrative based - 
the stand out examples for me have been Damian's "Life the Universe And 
Everything" talk, Jos' "Confessions of a Script Kiddie" and the 
first talk I saw by Jouke about pVoice.

Let's face it - Catalyst, Maypole, Rails, Django etc etc are all much of
a muchness when it finally comes down to it. I remember writing a
similar thing to Django's Admin interface (although not nearly as
polished or cleanly seperated) ages ago in PHP (I was young, I needed
the money). By that I'm not trying to brag about my studliness, what I
mean to say is that there's clearly convergent evolution going on here
and the surprising thing is not that all 4 started roughly at the same
time 2 odd years ago but more that none of them were written before 
that time.

That said the important differences were highlighted last night.

Part of the 'problem' is is that both Matt Biddulph and Simon Willison
are excellent speakers who have honed those particular talks on the
conference circuit this year. They know what the crowd wants and how to
spin a good lecture - don't go into too many details, show a bit of
leg^W eye candy and hang it all off a natural structure. And always
leave them wanting more, leave them thinking "ooh! I could take that and
do this with my thing and ..."

Matt Trout's talk spent a long time enumerating the different backends
available, some of which even he didn't know the purpose of. His slides,
not that it should matter in an ideal world, were not as visually
arresting as the other two. He talked of possibilities, of a framework
that allowed you to do anything. Which is very rarely what people want. 
Developers sort of want it but actually, they largely don't. 99% of the
time they just want one thing that does something with the minimum of
fuss. Which explains the continuing success of *::Simple modules on
CPAN. 

CPAN is, IMO, Perl's greatest strength and its biggest weakness. As oft
debated before, the completely free for all nature of it is a double
edged sword. We fill every niche at the expense of a definitive answer
which everyone can stand behind and which gives us a common,
transferrable skillset. We have 90 different templating solutions -
everyone else has one. Which they stole of us anyway. Ruby has nothing
else to crow about apart from Rails and so the whole community gets 
behind it. We have a hundred and one and we stand divided. It's like a 
small hicksville town being proud of the fact that one of its denizens 
grew the worlds largest potato compared to, I dunno, Milton Keynes and 
its concrete cows.

Part of the problem, to blow our own trumpet here, is that we have
become used, in many ways, to excellence. We take CPAN and things like,
as a specific example, DBI for granted. DBI.pm - perhaps the most useful
bit of code I've ever seen in my entire life. Oh it's got its warts and
its interface weirdness. But I could barely supress a snigger when Simon
and Matt talked about having MySQL *and* Postgres *and* SQLite support!
Maybe in the future Oracle and MSSQL! HAH! We barely even register the
fact that, by and large, we can change one line in our code or config
file and connect to a squillion different databases. Just like that. And
we can do that because the standard interface for databases in Perl is
DBI.pm. Anything else is just kind of kinky. And not in the good way.

So, back to the Catalyst talk - a barrage of information and lists. 
Class::DBI, DBIx::Class and then, later, bewilderingly added as part of
tangential monologue, Class::Sweet and Tangram. Hell, I barely know what
some of those are, have never used any except Class::DBI. How the hell
are the other people in the audience supposed to know?

What were the strengths of the frameworks last night? Django's was
clearly its admin interface although, unless I'm mistaken, that will
tend to limit it slightly to content management sites (as, I believe,
Simon pointed out). Rails has its steadfast, resolute way of doing
everything. Which, as Matt pointed out also annoyed members of its
community.

So what did Catalyst have? Well this was never enumerated but I'll 
infer. On its plus side it has the whole of CPAN so that, should you 
wish to add functionality, there's likely to be at least part of the leg 
work done. It also has its flexibility. You're unlikely to ever hit a 
situation where you can't fix it.

And so, what are its downsides. Well, its flexibility - the vast 
majority of people want to be hand held all the way to the 80% solution 
which suits 90% of the people 95% of the time (warning numbers might be 
arbitary). And, you could argue, it lacks the polish of the Rails and 
Django experience (which have both benefitted from a professional 
designer).

But these are both solveable without compromising the core value of
flexibility. Have sensible, sane defaults that most of the time people
won't change. Don't be afraid to say that this is the standard way of
doing things and if you deviate from that then there may be dragons. 
Build a Opinionated Catalyst or a Catalyst on Rails or whatever you want
to call it. And not just in the usual geek way of "anything you can do
we can also do" but because it's the right thing to do. And hire a
designer, or bribe one by saying that you'll do his (or her) site if
they do the Catalyst website and default templates and then make a 
automagic admin interface that's as showoffy as the Django one.

And when giving talks - be more enthusiastic. Matt Biddulph spoke with
more passion despite having only used Rails for 2 months. Even when he
was describing how horrifically slow it was. And instead of enumerating
the $n different caching mechanisms - show a couple of cherry picked
example classes and the (by now) slick looking site they produce. Show 
that they can rival the AJAXiness of Rails and Django despite the fact 
that AJAX largely has nothing to do with the framework behind a site. 
And then, and only then, make a virtue of the flexibility. Show Leon's 
Catalyst based web debugger. I'm willing to bet that it would be largely 
impossible in either of the other two. The simple stuff? Yeah we're as 
good as the other two and just as slick. By the way, can we show you 
this demo that will blow your fucking mind? Noting that there are 89 
plugins already is not an attention grabber.

A few years ago I came to the realisation that no matter what I did with 
some code I was working on (in this case, the Yahoo! search engine which 
is kind of a big deal) - whether double blind test conclusively proved 
that our results were better than a certain other leading brand of 
search engine. That we gave faster results. That we were less blog 
spammed. That we were ... it just didn't matter. Because what it came 
down to was perception. And I can't code my way out of that. And it's no 
use pissing and moaning about that fact and it's better to accept it and 
work with it.

Oh and drop the .pl from the scripts - in my mind it look 
unprofessional. I don't care if an executable I'm running is compile C, 
Pascal, handrolled Assembler, BF, TCL, Perl or Python. It's an 
executable. The OS can work out how to run it from the shebang line and 
I don't need to care.

This long, incoherent rant has been bought to you by the unholy 
combination of NyQuil, Benylin, Ibuprofen, Halls Soothers and Camomile 
Tea.

Simon