BBC Creates 'Perl on Rails' 216
Bogtha writes "Long-time users of Perl for their public websites, and having successfully used Ruby on Rails for internal websites, the BBC have fused the two by creating a 'Perl on Rails' that has the advantages of rapid development that Rails brings, while performing well enough to be used for the Beeb's high-traffic public websites. This is already powering one of their websites, and is set to be used in the controversial iPlayer project as well."
Great another framework (Score:1, Interesting)
Re:Madness, I say (Score:4, Interesting)
I seriously doubt they have very much Perl code around; there's not much dynamic content on BBC. I really can't imagine what their circumstances would have to be for it to be a sane option to rewrite Ruby on Rails in Perl
Re:Great another framework (Score:4, Interesting)
IMHO another example of management red-tape costing developers time and resources.
Re:Great another framework (Score:4, Interesting)
Catalyst aims to be an extensible framework. Sure, there are recommendations for new projects, such as using DBIx::Class as the ORM, or Template Toolkit for your view, but these aren't written in stone. Each layer is flexible. You can use CPAN modules to build your own models and views. Want world GDP data? Make a model that calls WebService::CIA. Have your own custom database model already? Use it! (SixApart did this with Catalyst + their partitioned database system + Memcached).
Catalyst is a little rough around the edges for some of the simpler cases that you might use RoR for, such as a plain old CRUD form system, which Rails will nicely generate for you, but for more complex applications Catalyst is not a bad choice.
Re:Thanks a lot Beeb.. (Score:2, Interesting)
I know you know this, but others don't.
The hash is always called 'hash'. The sigil provides datatype information for the intended return value of your access to the variable -- just about everything in Perl is an expression and has a return value. Program evaluation follows a model remarkably similar to what a functional language might use, evaluating sub-expressions as needed. I'm sure the internals could be better or smarter, but they definitely aren't bad.
Sigils also provide a simple namespacing mechanism, so you can have $hash (say, a reference to a hash) and %hash in the same scope.
And because there's that layer of indirection between the variable's raw values and its return value, you can inject code to make variables act differently than they normally would when accessed, by using the Tie mechanisms. As a result, a fair amount of Perl's OO syntactic sugar can in principle be defined in terms of Perl code instead of having to be a part of the interpreter. This mechanism is obviously open for abuse,
In fact, I'm starting to think that a closure-based object system could be made to replace Perl's "standard" OO system with minimal syntax changes through the use of ties.
Re:Thanks a lot Beeb.. (Score:4, Interesting)
Yes, to some degree. The primary goal of Perl, like other programming languages, is to communicate with other programmers. There appear to be two schools of thought on how to do this. One of them comes from the mathematicians, who appreciate simplicity and uniformity of expression (as least per their on definitions of both) as a primary design criterion. The other comes from the linguists, who (in my opinion) have somewhat better ideas of how people (not just mathematicians) really communicate.
I'm not saying that one is bad and the other is good. You'd never likely get the Turing model or the lambda calculus out of a linguist, for example, and COBOL and AppleScript aren't great examples of applying linguistic principles to language design either -- so there's a balance to strike between them.
I agree to some degree, but just because no one has ever done it perfectly doesn't mean it's not worth doing.
Yes, actually. Remember that Perl is an artificial language, so it can simultaneously be more and less a pastiche than English. Consistency and syntactical similarity of semantics are important in natural language (avoid false cognates) but even more so in a programming language. The Perl 6 designers believe strongly that similar things should look similar and dissimilar things should look dissimilar. As well, concepts such as noun markers and subject-verb agreement (context) are present in Perl, as well as pronouns (topicalization). This brings up other problems such as ambiguous antecedents.
The designers evaluate new operators and concepts in terms quite heavily. Mnemonics are important, as well as the proper length of identifiers and semantics of their names. For example, Perl 6 uses say instead of println because we believe it will be a frequent operation -- more frequent than print and as such deserves a shorter identifier. Whatever the syntax for accessing the current continuation will be, it's likely to be somewhat longer, as it's not something we want people to need to use more than a few times.
Re:Great another framework (Score:1, Interesting)
I've used Ruby on Rails to write a threaded message board, a web monitoring system for camera equipment at a university lab...to imply that it can only be used in simple cases would seem to me to be an indication that you really don't know what you're talking about.
Catalyst, now this "Perl on Rails..." If Perl is so much better for rapid web application development, how come the Perl community is tripping over itself to be Rails all of a sudden?
Re:Great another framework (Score:1, Interesting)
Aside from the fact that the Catalyst developers and a few people at the BBC are not "the Perl community", better than what? If you're referring to people who think that Perl is better than Ruby, then it's entirely logical that they would prefer "Perl on Rails" to Ruby on Rails (assuming they like the ideas behind Rails in the first place). If you mean people who think that Perl is better than Rails (never mind that it's a meaningless comparison), they're probably not the same people that are trying to emulate it.
Re:Madness, I say (Score:3, Interesting)
> easier than learning another language for one specific smallish project.
Sounds to me like a bunch of Perl coders looked at their friends' code and find their ideas interesting, and is worthwhile to implement in their favorite language. Why people never learn to admit that some people think Perl looks nicer than the language they love most?
Re:Never mind the merits of perl or ruby (Score:3, Interesting)
Complain to your elected representatives, perhaps? Now THAT's thinking outside the box!