Perl on Rails (2007)
bbc.co.uk
bbc.co.uk
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.
Haha
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.
Because that’s how it started, and it maintains absolutely fantastic backwards compatibility. All languages have foibles…
> Why do I need to [declare variables prior to use]
Because this isn’t Python
You don't need to if you don't use strict mode, which I think it is ok for small scripts.
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.
>Because this isn’t Python
Perl 6 isn't Perl, either.
A perl in the sense that, say, Common Lisp, Scheme and Clojure all count as a lisp.
But no further.
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.
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.
(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.)
For instance:
my @arr = ("Larry", "Moe", "Curly");
my $len = @arr;
will store 3 in $len. Application codebases and libraries make use of this kind of thing everywhere.
You can find some of the reasoning why in interesting essays like this: http://www.wall.org/~larry/natural.html
Larry Wall was trying to incorporate some natural language features in Perl, unsuccessfully in this case but I would say it went very well in others.
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.
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.
They are a useful visual indicator that something is a variable, so they don't bother me.
Newer versions of Perl add post-dereference syntax which reduces the line noise.
[1] https://perldoc.perl.org/perlsub#Signatures
[2] https://www.effectiveperlprogramming.com/2015/04/use-v5-20-s...
Do you have some examples? Outside of some specific python extensions that are written in C, Perl is almost always faster than Python for me.
However Perl handily beats CPython in startup time, so it's much faster for short-lived programs.
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 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.
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.
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).
Ruby maybe? It feels like a saner Perl to me
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.
https://www.bbc.co.uk/blogs/internet/entries/8673fe2a-e876-4...
https://static.files.bbci.co.uk/core/storybook/index.html?pa...
> 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
1: https://www.totaljobs.com/job/senior-software-engineer/bbc-j...
I am curious, how does this imapct SEO?
This means the content can be both crawled for SEO and cached (there's cache hit and fastly headers in their responses)
https://programming-language-benchmarks.vercel.app/python-vs...
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.