Davblog

In which someone you've never heard of writes about things you have no interest in

Posts Tagged ‘perl’

Light Bloggage

I’ve just realised that it’s two weeks today that I go off to this year’s YAPC::Europe and I still have two talks to write – one of which is a three hour tutorial. So don’t expect much writing from me over the next couple of weeks. I’ll be far too busy working on other things.

In the meantime, Nik’s series of posts on the benefits of OO programming looks like it’s going to be well worth reading. The first two articles (on data hiding and separation of concerns) are already available and three more will appear over the next few days.

What’s Wrong With ORM

Last night I gave a talk to the London Perl Mongers about “What’s Wrong With ORM”. It was a first draft of a talk that I hope to be giving a few times this year. There’s also an article in preparation (well, I say “in preparation” but I actually mean “slowly coalescing in my brain”).

Anyway, the slides are online. I’d be interested in hearing any comments that you have.

Templating Systems

I’ve been thinking about templating systems a lot recently. By templating systems I mean technologies that allow you to mix some data with some fixed text to produce some kind of output. One obvious use is in creating dynamic web pages where, for example, you would create a row in a table for each item that you pulled out of a database table. Templating systems form the view component (the ‘V’ in ‘MVC’) of many web frameworks.

There seem to be two schools of thought on templates. Some people think that the best language to use for templates is the same language that you use for the rest of the system. This is the approach taken by Ruby on Rails, where the you templates will contain a lot of Ruby code. Other people, and I’m one of them, think that it’s better if your templating language is completely different from the rest of the system. We believe that presentation logic is (or, at least, should be) much simpler than the rest of your code and that using a deliberately simplified language forces you to separate your business logic from your presentation logic and that leads to cleaner systems. Also, it’s often the case that templates are written by a different set of people than the rest of the system and you shouldn’t really require the template developers to be experts in the programming language that is used for the rest of the system.

It seems that this separate language approach is starting to catch on. Perl has the Template Toolkit which has its own presentation language. PHP now has a separate templating language called Smarty. Django (a web framework written in Python) has uses a similar approach. And even Ruby on Rails has just gained a new separate templating language called Liquid.

But that’s not all. As I noted when I wrote about the recent web frameworks night, all of these templating languages look very similar. And that’s what got me thinking.

Consider the (common) case where the templates are written by a different team of people to the backend code. We’ve already established that this team shouldn’t need to know whatever programming language the rest of the system is written in. If we assume that this is a web-based system then those people will already be experts in HTML, XHTML, CSS and JavaScript. There’s really no reason for them to be experts in Perl, Python or Ruby as well.

But the way things are currently they might not need to know Perl, Python or Ruby, but they do need to know whatever templating system is being used. So the choice of backend language is effecting what the frontend developers are using. And that seems wrong to me. Given that many of the templating languages seem to be converging on a similar syntax, isn’t it worth giving them that extra push so they just become the same language? That way, frontend developers can just become experts in “templating” and it doesn’t matter to them what language is being used at the backend.

We don’t expect frontend developers to use a different type of HTML because the backend is written in a different language. Surely it’s a bit weird to expect them to use a different templating language.

Oh, I realise there would be a lot of work to do. Working out a “best of breed” syntax across all the existing templating systems would be difficult. And then you need to work out how each individual programming language would interface with the templates. But isn’t it something at least worth investigating?

Web Frameworks Night – Report

So last night was the Web Frameworks NIght. A great time had by all. Many thanks to the organisers.

We had talks on three frameworks – Catalyst, Django and Ruby on Rails. My overwhelming impression was how similar all three frameworks are. There really seems to be little to differentiate them.

As always the Perl community shot itself in the foot a bit. I know that Catalyst is a great framework and I know that Matt Trout knows a lot about Catalyst. Unfortunately he doesn’t know enough about how to sell Catalyst in a presentation. As a result his talk had a lot of slides full of code which would have been almost inpenetrable to anyone who didn’t already know Perl. He also failed to give any demos of Catalyst in action. But I thought his biggest mistake was to overlook the one area where Catalyst scores heavily over the other frameworks – the ORM tools that Catalyst are much more powerful than the ones used by the other frameworks. For example, with Class::DBI::Loader you can automatically pull the relationships between your tables out of the database.

Django looked interesting. In particular the default admin screens that it creates had everyone in the audience going “oooh”. Django templates use a language that looks a lot like the Template Toolkit, but apparently they are based on the PHP templating system Smarty – so it must have been them that borrrowed the ideas from TT.

Then there was Rails. I don’t really think anyone in the audience was there to find out about Rails. It’s been getting quite enough publicity recently so I think every has at least a basic knowledge of how it worked. I think most people were there for a first look at the BBC programme catalogue that Matt Biddulph is building. And it didn’t disappoint. It looked lovely. I foresee a few wasted days when that is released next year. Oh, and it was nice to hear that some Rails programmers are moving away from the idea of using embedded Ruby as their templating language. A new templating language called Liquid has just been released. This is based on the Django templating language (which is based on Smarty, which is based on TT).

So, to summarise.

  • All MVC web frameworks look very similar
  • Catalyst has the best ORM capabilities
  • Django has the best default admin templates
  • Rails has the mindshare
  • They are all starting to use templates that look like the Template Toolkit

Update: blech points out that I missed out Catalyst’s big advantage. By building on Perl’s existing DBI framework, it already comes with connectivity to far more database systems than any of the other frameworks.

Update: Here are links to all the presentation slides:

Java Programmers Embrace Ruby

Bruce Tate’s book Beyond Java has been published and there’s quite a lot of publicity for it appearing on the web. For example this article by Chris Adamson on the OnJava site. In the article Adamson interviews a number of well-known Java programmers about the future of Java.

The replies seem pretty unanimous that Java’s dominance is nearing it’s end. They seem to think that Java has become too top-heavy and that it’s becoming too complex to be usable. Oh, they all agree that it’ll still be around for some time (much as COBOL was for many years) but it’s surprising how many of them are looking closely at Ruby on Rails.

As someone who has never been a big fan of Java and who has always preferred the freedom of “dynamic languages”, it’s interesting to see so many respected Java programmers coming round to my way of thinking. The advantages of Ruby that they talk about are exactly the advantages that you’d get from any dynamic language. Sure, we get the same old tired nonsense about how Perl encourages untidy code but all in all it’s all starting to look like a good time to be a programmer specialising in dynamic languages.

Now, if only we can start marketing Catalyst as well as the Ruby on Rails people market their framework.

London Web Frameworks Night (Update)

The London Web Frameworks night has proved to be very popular. So popular, in fact, that the organisers have had to change venue. It will now take place in the New Cavendish Street campus of Westminster University. See Dean’s post for more details.

This means that signup has been re-opened for the time being. But places are still going fast, so sign up now if you’re interested.

Should be a good night. Say hello if you’re there.

London Web Frameworks Night

November is shaping up to be an interesting month in London. Not only is there the London Perl Workshop that I mentioned yesterday, but Dean Wilson has organised a London Web Frameworks Night on November 17th. Three experts will be discussing the major MVC frameworks for Perl (Catalyst), Python (Django) and Ruby (Rails).

And it’s at Morgan Stanley too, which is a very cool place to hold a meeting. More details as soon as I get them.

Update: Sign up here.

London Perl Workshop

Those nice people from the London Perl Mongers have announced the 2005 London Perl Workshop. It’ll be on Saturday 26th November at The City University. More details from the web site.

I expect I’ll be giving some kind of talk. Hope to see some of you there.

Update: 2005. It’s 2005!

Flatterer

From an interview with Gregory Wilson where he talks about his recent book Data Crunching.

I was also inspired by David Cross’s excellent book “Data Munging with Perl“, which taught me most of what I know about how to actually use the language. If he’d written a cross-language version of that book, I probably wouldn’t have bothered writing mine.