BBC Creates 'Perl on Rails'
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."
I am going to create "PHP off the Rails" for developers of PHP websites. PHP developers will need no training, as most of them are off the rails already!
Sent from my ASR33 using ASCII
So... is this trying to combine the slowness and unscaleability of Ruby on Rails with the unreadability of Perl?
This is proof that there is a conspiracy to make up absurd programming shenanigans to sell overpriced door stoppers! Coming soon...
...at a bookstore near you to burn a hole in your wallet!
"Perl on Rails for Dummies"
"Perl on Rails for Idiots"
"Perl on Rails Bible"
"Perl on Rails in 24 Hours"
"Perl on Rails in a Nutshell"
"Perl on Rails: The Missing Manual"
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.
Strange it may be, but incomprehensible and a run-on it's not.
"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.
In short: it's a sentence. It's grammatical. It's comprehensible. Quit whining.
Its almost incomprehensible by normal, english-speaking humans.
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.)
>north
You're an immobile computer, remember?
Should have preferred Python or Parrot. I mean c'mon. nudge nudge know what I mean... She's a goer.
Some drink at the fountain of knowledge. Others just gargle.
I don't see the problem...
understand it easily if longtime perl programmer($self);
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. Web development is really Ruby supported on the back of Rails."
The developer gave a superior smile before replying, "What is Rails standing on?"
"You're very clever, young man, very clever," said the old lady. "But it's Rails all the way down!"
If it was meant to be easy to understand, we wouldn't have called it "code".
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.
-- John.
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.
how to invest, a novice's guide