Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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."

Yes, but add a few $'s and %'s in the right places, and it turns into a one-line cross-platform implementation of iPlayer written in Perl. (If your Perl code can be understood by humans without extreme effort, you're just not trying.)

Haha, yeah, I've been away from Perl for a while, and I don't think I've ever actually had need to print every element in an array without doing a bunch of stuff with it first, so constructions like that never stuck in my head.

"Long-time users of Perl for their public websites," - an appositive"and having successfully used Ruby on Rails for internal websites," - another appositive, successfully connected with a conjunction"the BBC" - the subject of the sentence (which the appositives are in apposition to)"have fused the two by creating a 'Perl on Rails'" - a perfectly fine predicate"that has the advantages of rapid development that Rails brings," - with a relative clause"while performing well enough to be used for the Beeb's high-traffic public websites." - and another modifying clause.

The short sentences we use nowadays are a more recent innovation. In the past, run-ons were the bloody norm and they totally sucked; people who used them needed to be shot in a most painful and brutal area since they can make it such a bitch to read a paragraph aloud in class when you're thirteen and just wanting to get it over with and go back to looking at the cute girl who sits in front of you.

'Only a moron could believe that there is nothing wrong with a sentence which can be grammatically parsed as valid and comprehensible but which is so long and twisted that only after thirty words, a lot of comas and conjunctions, you can deduce its structure and realize that its beginning was an appositive instead of the subject', is an affirmation that I would not fully approve.

Joining "long time users of Perl" and "having successfully used Ruby" with "and" seems jarring to me, although I'm not confident enough in my grammatical knowledge to say it's definitely wrong. Don't the two clauses have different grammatical structures? "Long time users of Perl" is, what, a noun-phrase? Whereas "having successfully used Ruby" is a sentence fragment with a verb in it. At least, you can say "The BBC are long time users of Perl," but you can't say "The BBC are having successfully used Ruby,"

Clearly you have trouble understanding short and clear sentences because the original poster clearly stated that schools encouraged "short and clear" (emphasis added) sentences as opposed to sentences which were clear because they were short or vice versa and on top of that long sentences like this one aren't always necessarily clear.

Oh, something like that.All of my computer programs are the same "Hello World" application I did for my first project in college. I just rewrite the compiler from scratch to create new programs from it.

Sounds to me like the BBC are using flat files and no database! They're talking about having tens of thousands of files in a directory, and having an archive of data on all shows the BBC is showing, but no mention of using anything other than flat files!

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

They're talking about having tens of thousands of files in a directory, and having an archive of data on all shows the BBC is showing, but no mention of using anything other than flat files!

Flat files that are pre-generated from a database backend, maybe. As in a cron job each night that does something like "for show in db.select(shows): generatestaticpage(show)". I'd be amazed if the whole site was just one big Dreamweaver folder that gets published.

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.

"We have a database engine. We have a template system. We have a language that everyone in-house knows. Let's write a generalized method for combining the three!"

I suspect that happens a lot more often than you'd think. If anything, I consider it a testament to the BBC that they've decided to release their code so that everyone else doesn't have to reinvent it.

Disclaimer: I much prefer Python, and to me the BBC is that extra channel that has "Coupling" and "Ramsay's Kitchen Nightmares". I have no special love for Perl or the BBC. I just think that it's pretty cool of them to do this and wish them luck.

Like most organisations the BBC has its own technical ecosystem; the BBC's is pretty much restricted to Perl and static files. This means that the vast majority of the BBC's website is statically published - in other words HTML is created internally and FTP'ed to the web servers.

And a couple of implication, including an effective hard limit on the number of files you can save in a single directory (many older, but still commonly used, filesystems just scan through every file in a directory to find a particular filename so performance rapidly degrades with thousands, or tens of thousands, of files in one directory), the inherent complexity of keeping the links between pages up to date and valid and, the sheer number of static files that would need to be generate to deliver the sort of aggregation pages we wanted to create when we launched/programmes; let alone our plans for/music and personalisation.

I really think the BBC is running without using a database, I wouldn't have believed it either but it's right there straight from the horse's mouth.

Nice sig, BTW.:-)

Ta (but you forgot the (PBUH) after the smiley face, you insensitive clod)

All the replies questioning my post haven't read the article, which lays it out unambiguously.. How can you debate something which is stated crystal clear in the article?! It probably would have been quicker to read the article than write that reply.

RTFA: They are deploying their Perl on Rails app so that they can have more dynamic content, which they couldn't have before because they're limited to static files and perl scripts. It's basically a hack that allows them to keep their Perl & flat file setup, while allowing dynamic content.

What I'm wondering is why they don't just use an existing framework and scrap whatever restrictions are keeping them using Perl and flat files.

They are deploying their Perl on Rails app so that they can have more dynamic content, which they couldn't have before because they're limited to static files and perl scripts.

Well, I still think the correct interpretation is that they have a huge number of templated pages that are regularly statically generated. Maybe it's not a daily cron job that recreates the whole site, but a script that takes a template you just edited and turns it into a static page by running some Perl magic on it.

I'm guessing that "static" here means "non-interactive", not that each page exists in source form as the complete end-user-ready HTML. A huge advantage of this is that your webserver can e

Sounds to me like a bunch of Perl coders with a few million lines of corporate code who thought this would be easier than learning another language for one specific smallish project.

It's called putting all your eggs in one basket. When the language is no longer popular they'll be begging anyone with experience of it to join and trying to rewrite the entire monstrosity. Don't believe me? Think about Oracle forms. Half my job is replacing legacy code. What you're describing is a neat way of creating a HUGE le

That's a risk you take regardless of the language, and I'd be a lot more comfortable committing to something like Perl which has been around for a very long time and still has very strong advocates, rather than something like Ruby on Rails that's only recently become popular (not to mention PHP which only really seems to appeal to the lowest common denominator).

Perl has pretty much stood the test of time, though. There's a lot of people with "legacy" pre-.Net VB/ASP code, which at the time was hyped as th

If you diversify the range of languages you use, you limit that risk somewhat in as much as you can expect some of your code to die but hopefully not all.Perl won't live forever. No language will. I'd call C the steadiest of the lot and even that's been on the wane for some years (for business apps - I know it's not dead for game development etc.). Languages don't all die together though and by actually using a few different languages and platforms you give yourself some breathing space - as each one dies y

> Sounds to me like a bunch of Perl coders with a few million lines of corporate code who thought this would be> 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?

Why people never learn to admit that some people think Perl looks nicer than the language they love most?

For most of the same reasons that make it hard to admit that their wife is an alcoholic or that their son wants to become a Hari Krishna. There are certain truths that make it difficult to believe in a rational society. Yours is one of them.

Sounds like a bunch of Perl coders who cant be bothered to learn another platform

If you'd read the article[1] you'd have found out that they use Ruby on Rails internally, and that's why they replicated its functionality in Perl. The reason they did that was because they weren't allowed to use anything other than Perl.

This is just word-inflation. in the same way that children nowadays "need" a chocolate bar.

In business, the best way to see if someone really "needs" something is to see how much hassle they're willing to suffer to get it. For example, if they need a $1000 product, then I'd need a 20 page justification. If they need to attend a conference in 'Vegas, I need them to work weekends to catch-up the time etc. You get the idea.

Personally I don't know why people are always jumping to the 'language of the week'. I don't think 'progress' is the answer. I think too many programmers suffer from the 'we want the coolest new gadget' syndrome. Perl is a good and able language and if they have implemented another tool to help them do their job, then good on them. Why the hell should they bother to learn another platform. That is a ridiculous and juvenile argument. Constantly having to learn new languages just because a new flavour comes along reduces productivity, and makes it difficult to hire new people as there will never be enough people who know the languages on the bleeding edge. Meanwhile they probably have tons of Perl code already in place working just fine. So what if they don't like to use your favourite tool of the week and want to advertise their own favourite. No matter what you may say, they still know how to successfully build and implement one of the highest trafficked news web sites in the world. Shove that in you pipe and smoke it. Get a grip for Christ's sake.

The irony is, without the those people you don't understand, Perl would of never existed in the first place.The world needs both conservative people like yourself, as well as the people always looking for the next greatest thing. You would be programming in assembly without them, and a lot less work would get done without people like you.

Ruby and Python are next generation languages that both address issues with languages such as Perl. They exist for a reason. I personally really like Ruby as it does Per

absolutely.The best reason to use the existing technology is because you're currently using it.They could do a bit in Pythin, and another bit in PHP with perhaps a snippet of RoR in there that someone did a prototype in to see if could replace the entire codebase (ha), with a couple of C modules someone wrote for some fast-access parts, maybe with a VB.NET module that was written by someone experimenting with the latest 'coolest' tech, and a slice of Java written by an intern once.

For Perl, there is mod_perl, Ruby runs on Fast CGI. Now I am not the biggest Perl fan, but I would still take it over any Fast CGI application any day.

I know there is Mongrel now, but even the creators don't seem to trust it enough to let it run stand-alone and recommend you run it behind an Apache proxy. Not something I can imagine the BBC - or anyone with a large web farm - wanting to live with.

Perl is readable to those that know Perl. I know Perl and I find idiomatic Perl readable.

And "job security" language choices is just as much a problem with regular employees as consultants. As a consultant there's been more then one occasion where I had to go and clean up the mess after some bored employee made an "interesting" language or framework choice presumably to keep themselves interested.

I don't know perl. I find it daunting and intimidating. The syntax looks like there was an explosion at an ASCII factory.Just like the flamewar that exploded yesterday over HTML/CSS, the success of a language is largely dependent upon how easy it is for newbs or non-technical folk (ie. designers) to pick up. Not all of us have PhDs in CS, or enough time to pour over volumes of texts to learn the language. If you make the language easy to learn, and put in safeguards against common newb mistakes, it's b

As a professional programmer, easy to learn is somewhere on the list of ideal language attributes but it's nowhere near the top.I put a language in my bag of tricks if it gives me leverage to solve a wide class of problems in an effective and efficient manner. I ended up liking Perl syntax just fine once I had learned it.

In any event, it's hard to call Perl an unsuccessful language. Based on the breadth and depth of available CPAN modules, and the fact that Perl support is a given on most web hosts, you hav

Oh, I never doubted that it wasn't successful. PERL *is* a good language. However, I don't foresee all too many new PERL programmers jumping on board, when Python and PHP are easier to learn, and are more or less "just as good" as PERL.However, programmer-friendliness is crucial these days for new languages. The number of fairly apt computer users is quickly growing, whereas the number of professional programmers isn't changing all that much. It therefore stands to reason that languages that don't requi

Perl is readable to those that know Perl. I know Perl and I find idiomatic Perl readable.

I think it more accurate to say that Perl code is readable to the person that wrote that particular piece of code. Since there are a million and one ways to do anything in Perl (and this is considered a 'strength'), then when another Perl hacker comes along and can't understand what the previous Perl hacker did, they rewrite the whole thing the way they know how to do it. That doesn't meet my definition of 'readable.'

The old programmer didn't document the code properly or the new programmer was to lazy, inexperienced or incompetent to take the time to understand the old programmer's work. Whatever the reason the language used, perl or otherwise, is not to blame.

Perl is readable to those that know Perl. I know Perl and I find idiomatic Perl readable.

The question isn't whether or not those who know a language find it readable. Of course they do. The question is how readable the language is to those who haven't studied the language for years, and how much study it takes before the language is readable. In this sense, Perl is quite a poor language.

And "job security" language choices is just as much a problem with regular employees as consultants. As a consultant there's been more then one occasion where I had to go and clean up the mess after some bored employee made an "interesting" language or framework choice presumably to keep themselves interested.

If I seem bitter, it's because 98% of the messes I have to clean up are written in Perl. The best thing I can say for Perl (and C++) right now is that it's a great "crap magnet". That is, if something's n

On the contrary, if a programmer doesn't know Perl well, then he or she is not qualified to maintain Perl code. Such a programmer is plain and simple, a danger to the code base. Maintenance programming is hard. It means getting into someone else's head enough to make adjustment to their implementation without introducing regressions, or rewriting stuff and losing important features or bugfixes in the process.So, what do you know, maintenance work is often given to junior engineers, who are as a rule do not

Why is it that every time somebody mentions Ruby on Rails people have to say it's slow and unscalable? I'm getting kind of tired seeing this myth propagated. Ruby may be slower than $LANG but it's not that much slower, and the Rails shared nothing architecture makes it infinitely scalable up to the point where the database backend can't keep up anymore. And once you get there it's not really the framework that doesn't scale anymore is it?Additionally the expressiveness of Ruby combined with the conventions

This'll be UK-only; probably licensed under the BBCPL, which is like the GPL, but only for people in England, Scotland, Wales, and N. Ireland.

Could be worse. Could be released under the TVL (TV Licence), where you'd
have to pay £135.50 per year to run the software. (Or £45.50
if your web site is in black and white instead of color.)

The good
news then would be that if you live in your parents' basement
and they have a TV Licence paid for, you can host the web site
under their licence as long as the server is located in your
parents' house.

not only that, if you don't use the BBC product but simply own a computer you have to by law sign up to it and pay the £135 license fee, but then you get to proclaim proudly to the rest of the world we have the best gov't controlled BBCPL-licensed products.

Sniff. At the very least, we'd feel better if others could learn that it's Perl and not perl.;-) I'll take this opportunity (in anticipation of the inevitable complaints about unreadable notation) to point out the following:

$ is for scalar, @ is for array, # is for hash

Not so hard, was it? Notice the mnemonic qualities? Much of Perl has a striking resemblance to natural language, given that it's author, Larry Wall [wikipedia.org] is a trained linguist. For

Only Perl programmers think Larry Wall is a trained linguist. It would be more accurate to say he remembered some terms from a few linguistics classes he took as an undergraduate (notably "topicalization") and used them as metaphors to describe the rationale behind some design choices he made in creating Perl. The explanations aren't terrible, and some things in Perl's syntax were indeed "intuitive" by comparison with C, but the notion that Perl "has a striking resemblance to natural language" is a dream

OK, I'm not going to pretend I know more than you about developing Perl, for obvious reasons. And my ignorance about the training of the people developing it is showing. But since I have you on the line, so to speak, are you in fact asserting that Perl is like natural languages? I'm not sure either linguistics or computer-language development is well served by this comparison. Do you think it is? On a day-to-day basis, does it actually guide your choices about the language?

But since I have you on the line, so to speak, are you in fact asserting that Perl is like natural languages?

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'm not sure either linguistics or computer-language development is well served by this comparison.

I agree to some degree, but just because no one has ever done it perfectly doesn't mean it's not worth doing.

On a day-to-day basis, does it actually guide your choices about the language?

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.

Chromatic,From (my) snark to (your) informativeness in two posts. Bravo. Thanks for taking the time; I understand that this is something you are intimately involved with and in a position to speak about authoritatively.

The principle that a programming language should be designed in light of its function as a medium of communication between programmers seems like a very insightful one, and I can understand that with that goal in mind, study of human communication is probably more useful than study of algor

Given %hash, it's called @hash{@keys} when you slice it, and $hash{$key} when you only want one element. References always are scalar, so even though $foo->{bar}[42][2]{baz} is referencing a hash of arrays of arrays of hashes, you have a $ on the front.

Once you know the rules, it's fine... but it's not necessarily Perl's finest point (and this all changes in Perl 6 as a result). Even if you like Perl, you have to admit that there are lots of things wrong with it.

Given %hash, it's called @hash{@keys} when you slice it, and $hash{$key} when you only want one element.

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 c

But how is this substantially different from say Mason (http://masonhq.com)? I understood the Ruby-on-Rails thing is just a framework to get ruby to work with sites; afaik Mason is pretty much the same thing (I have worked with a site that used it in place of CSS stuff in the late 90's, and I know that large sites also use it, like ebay and amazon. it's great for dynamic content generated through perl scripts to be published).

Never mind the merits of perl or ruby, the question inquiring minds in the UK want to ask is, how can we stop spending money on this project? We are not interested in funding the BBC to invent new programming methods, languages or anything else. We do not want to be forced to fund magazines and various news channels we do not watch, and appalling non-stop comedy channels that make our toes curl, and iplayers that don't work with our computers....and so on and so on!How do we stop this train and get off?

Exactly. They should have just went with Catalyst. RoR is overhyped. Perl on Rails just appears to be a way to hype something. Catalyst is actually a nice MVC spirited implementation that has the advantages of well written Perl code.

Seriously though I dont know what the BBC is doing, smoking its way through £130m PA ($260m) of public money on computer "projects", like re-inventing mplayer/iPlayer/MediaPlayer.. Haven't we already done this? Shouldn't Aunty Beeb leave the hard-coding to the free market & concentrate on what it does best - artistic/jounalistic output?

The two frameworks fill different needs. Rails might be great for a completely new product, where you can fully take advantage of its "Convention over Configuration" motto as well as its neat integration between M, V, and C.

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.

Have you ever tried to swap out ActiveRecord in its entirety for something else? The corresponding change in Catalyst is much easier than in Rails. (Rails 2.0 might have changed this; I don't know.) Rails is very proudly opinionated, while Catalyst goes to great lengths not to enforce any single particular component.

... how come the Perl community is tripping over itself to be Rails all of a sudden?