Comments are hilarious, especially knowing some of those people commenting most critically had recently been working at FM&T.
At the short stint I did at the Beeb I spent a lot of time doing code for date maths using SSI and Perl before they decided to completely rewrite what we were doing in Flash.
Perl is a great language, and Catalyst and Mojolicious are rock solid, as is DBIx::Class. I work all day with TypeScript now, but I miss working with Perl.
I don't write Perl often, which probably explains why every time I go back to it (we have a legacy Perl app), I get tripped up, over and over again, by the sigils, and the rest of the visual noise — and I can't help wondering, why?. Why can other scripting languages deal perfectly fine with the ambiguity that Perl resolves with a dollar sign as opposed to a percent sign, or an at-sign, or a backslash. Why do I, as a programmer need to remember that when I assign a hash as a value to another hash, I want to write it with curly braces; whereas in other contexts I want to write the hash using parentheses and assign it to a variable prefixed by the percent sign? Why do I then need to prefix the variable with "my" or "our" at the time of declaration? Why don't I have to do this in other scripting languages, not even in php, which has preserved the dollar sign? It's utterly bizarre.
Don't forget there's also "state $var" and "local $var", which declare other types of variables. They're there because they.. are useful.
Same as why there's "var", "let" or "const" in JS. Different scoping / types of variable slots for the interpreter.
A "my" variable declares a variable valid in the current scope; an "our" variable will be available at the package level; a "state" variable is initialised only once, but has the same scope as a "my" variable; a "local" variable "locally overrides" for the current block (and any code called by the current block) the value of said variable.
They all have their uses, and that's why they exist.
`let` and `const` expand and replace `var`; and make variable declarations more intuitive by removing var's hoisting and adding block-level scoping (which the programmer doesn't need to care about if he doesn't wish to). What this means is that one can just use var if they are happy with it, or use let and const without the var. Not so with Perl. There is no "legacy mode", with all the awkward punctuation of decades ago, as opposed to a much saner "convenient modern mode" in Perl.
(Although I agree that a javascript programmer might get confused by declaring an object or an array as a const and then being allowed to mutate it.)
> ..every time I go back to it I get tripped up, over and over again, by the sigils, and the rest of the visual noise
From what I remember of writing Perl - it is a lovely language to write, but not to read. I remember going back to my own code and thinking what the hell am I doing here.
The sigil is there because Perl is made for text templating, like bash and PHP. Similar to f-strings in Python 3. Having several sigils is because Perl has language context as first order feature. It is a form of operator overloading.
I have the opposite reaction than the one you describe. Why haven't other languages picked up on contexts?
It's an elegant to solution to the fact that casts can be ambiguous in late-bound dynamically typed languages. PHP specifically can suffer from this where the automatic casting gives you a different type than you expected and no one notices because it isn't an error with dynamic types. It eliminates a class of errors.
The other things I miss most from Perl are taint mode, and Moose. Metadata for objects is such a good idea, where you can see all the traits and other properties in one place.
What I don't miss about Perl is that complex data structures are overly verbose. Multidimensional arrays and hashes are much too hard to read. Ruby did that much better.
> Why do I need to [declare variables prior to use]
Given the zen of python specifically says "explicit is better than implicit" I've always been stunned that python doesn't require that.
I've spent enough years writing perl that, believe me, I can hate its foibles more extensively and more accurately than most of the anti-perl people, and generally when I read criticisms of perl my first thought is "this wasn't wrong but it doesn't go nearly far enough."
But not requiring something like 'my' is python abdicating its own stated principles and while I don't feel I know python well enough to criticise it appropriately in general, this has always struck me as, in fact, a deeply un-pythonic attribute of the language.
Yeah, Perl 6 was so <s>fantastically compatible</s> it took so many decades to come out they had to rename it something else so as not to confuse people.
Just in case you missed it, Mojolicious is also available for TypeScript now, and the developer experience is pretty close to the Perl original. ;) https://mojojs.org
Having released SQL::Abstract 2 people are trying to convince me to port things.
Since the SQLA2 expr layer was deliberately designed to be JSONable I have a horrible feeling I can actually do so and I might actually crack and do it, but if I do I'll be writing vanilla ES6. If you love typescript enough more, a commit bit will be yours for the asking.
I wrote mostly Perl for nearly ten years of my career and I miss it. It was so easy to transition between writing big codebases and doing little command line stuff. The super power was how easy it was to write little command line stuff that could quickly include all the enterprise libraries.
I really can't stand PHP but as a veteran perl hacker I really do need to say "that's my personal opinion and I am -amazingly- impressed with what people have -done- with PHP even if I don't like it myself."
Mojolicious::lite is amazing; I'm using it on a personal project at the moment.
I love Perl, it's exactly what I need in a programming language. I picked it up this year as I wanted a versatile and fast scripting language in my toolkit.
Every time I try to write Perl, between the sigils, weak support for numbers, and the archaic-feeling way of handling parameters in subroutines, I come away slightly disgusted. The convenience of the text processing routines is not a novelty or productivity improvement compared to other languages nowadays. And Perl seems slower than Python now on the kinds of workloads where I would be tempted to use Perl. What am I missing?
I don't have good ones offhand, but whenever I write a script that spends a long time looping and doing a mix of numerical calculations and text processing, CPython beats Perl. I think this is partly due to how Perl treats numbers as a kind of second class data type.
However Perl handily beats CPython in startup time, so it's much faster for short-lived programs.
I worked at the beeb around 2003 and built a very high traffic Perl application for Radio 1 called OneMusic to launch unsigned bands. It was interactive, not static, hit MySQL directly and blazingly fast. Was a huge success using existing libs. This was pre nginx on our public facing Apache/modperl and it handled very high traffic.
BBC did have non static Perl applications so this whole thing is a false premise. They wanted to build a framework.
In 2007 Perl had thousands of MVC frameworks in CPAN. The idea that the solution to static file hosting is to build yet another MVC framework is absurd. They did and were surprised Perl is fast. Yeah. It always was. And they reinvented the wheel.
One, I fixed all of that team's problems but because I swore a lot under my breath about their existing code while I was doing so that team decided to be offended and made a decision to never invite me back (note, I quite possibly deserved that reaction, I'm still a blunt bastard but in those days I had the social skills of a thermonuclear device even as compared to now.)
Two, I helped fix the iPlayer 2.0 rollout by spending two days teaching them how to DBIx::Class better and then spent the third day ripping through their code (with the team's encouragement) and managed to save the "show all programs of the same series" feature by breaking (with the PMs and the team's encouragement) its ability to be correct down to the hour across daylight saving time changes by replacing DateTime with Date::Calc.
Damn good fun, and some of the most satisfying in the "I have earned what you paid for this and it makes me happy" days of my career.
I think the only days of work I've enjoyed more were the time I spent two days diagnosing a problem with an NHS cancer lab sample tracking system that turned out to be a weird interaction between three different bugs in various things.
Note: If you were a shadowcat.co.uk customer at the time and were one of the people to whom I said "sorry about this but this is a cancer lab, my previous commitments to deadlines are dead until I get this fixed" and replied with "well, yeah, of course they are, we knew who you were when we hired you, good luck", I love you all.
Buried amongst the comments was this from one of the creators:
> On the live environment we were told at the time we had Perl 5.6, and a few BBC approved perl modules. Nothing more! So that meant that catalyst a other solutions were out.
I guess this could have been a defensive security policy. I think CPAN has had relatively few supply chain attacks like npm, pypi, et al. But that's probably due to it's popularity.
I don't think there are any other scripting languages that allow you to write very concise one-liners that can do very complex things. That's also where perl got its bad reputation from, but it's more a discipline issue than a language problem. I always rewrote my explorative one-liners more cleanly when I committed them to a final program, but nothing forces you to do it like python does.
It becomes language issue when you need to manage code written by others.
Yes, the majority of bad rep it gets is because people picked it as first language and "just started coding", without reading up how to write stuff in readable way but that's... most developers.
Not many start their new language adventure with code style guide and while say Python at least nudges you toward semi-readable code, Perl gives you enough rope to shoot yourself and nuke a nearby city along the way. And any of you that goes "well, ropes do not explode" clearly don't know Perl deep enough.
That births a lot of shit code.... that new developers in a year or two now need to deal with too (which is bad) but also use as example on how to write it (which is way worse).
I still crack up about this. Context is that in the early days of Rails, they did a lot of screencast showing how easy it was to create a blog and tons of code was generated for you making seem like with just a few commands you could create anything.
> The vast majority of the BBC’s webpages are rendered on AWS, using React. React’s isomorphic nature allows us to render the pages server-side (for best performance) and then do some further updates client-side.
> Increasingly, the rendering happens on AWS Lambda. About 2,000 lambdas run every second to create the BBC website; a number that we expect to grow
I picked the first job that came up [1] and seems like at least one team is using Delphi with Oracle for the database. But the BBC isn't exactly small, so I'm not surprised there's a range.
I'm guessing the main part of the content (for example the news story) is rendered server side, the client-side adds any personalisation if the user is logged in etc and adds panels for 'related'/most liked/read more news stories etc.
This means the content can be both crawled for SEO and cached (there's cache hit and fastly headers in their responses)
That's the piece of information I miss in a lot of those stories. What happened X years later? We all love reading about strange projects, but it's not until someone sits down and writes a blog post about some old, custom system that you get the important insights (X was good, Y didn't work because reasons and nobody ever understood Z).
Sadly so. Still Perl around the organisation though in internal systems from that era which continue to work and still in daily use for producing news if nothing else.
Ruby is well known as the “bad parts of Perl” so there’s a beautiful horror here. It’s also funny that Ruby is the slowest of the dynamic languages, and that Perl is much faster. They created a magnificent mind bending nightmare.
Sort of. When I think of "which language is fast", I think of "when using idiomatic style". That, to me, is a good measure of how fast the language is, in general.
Benchmarks on aggressively optimized code are fun and interesting too, because they can tell you the hard lower limits of performance in the language runtime. But most people will never end up optimizing their code so thoroughly, so it's not particularly useful if you're interested in how a real working program will perform.
At the short stint I did at the Beeb I spent a lot of time doing code for date maths using SSI and Perl before they decided to completely rewrite what we were doing in Flash.
Perl is a great language, and Catalyst and Mojolicious are rock solid, as is DBIx::Class. I work all day with TypeScript now, but I miss working with Perl.