I’ve been a perl programmer … forever. It’s literally been my entire career. I’m thankful for its existence. Very much so. It’s enabled me to do great things, both personally and professionally.
It’s not cool and shiny any more. Actually, not true. It’s not shiny, but it’s still cool. There are still many, many amazing things being done with perl on a daily basis.
When I look around at the syntax of other languages and the frameworks, I often find myself surprised at how primitive they are, or how hard it is to make perform simple operations. Or how hard it is to perform complex operations - spin up a RESTful web server, pull rows from a database, talk to an API. All the stuff that perl has made incredibly easy.
It’s been a good run.
No, it’s been a great run.
And the run isn’t over. I’m still going to reach for perl all the time - because there is simply no better tool (in my opinion) for solving an awful lot of problems. I’ve been using it a long time, and I know I can get things done with it very easily.
But, I need to eat, I need to pay bills.
And I want to do a few of the things that perl just isn’t very good at.
The “paying the bills” part has not been a problem thus far. But if I was needing to look for work right now, it might be a challenge. “perl” as a keyword comes up an awful lot in job ads, but almost always (these days) it’s one of a long list of “also familiar with” items.
I’m not a one trick pony, I haven’t lived and breathed nothing but perl for the last 25 years. But I have a healthy case of imposter syndrome, and I know what I’d be able to confidently say I’m good at, and what I would struggle to defend as a core skill.
Additionally, I can’t (in good conscience) go into an employer who offers me a green fields project and use perl. I could 5-10 years ago, but not now. I’m only one person and if I’m not around I don’t want to leave that employer struggling to find someone to maintain and improve that project. That doesn’t seem fair.
But even if there’s money in it, I don’t want to be like the Cobol programmers. Those poor bastards.
So - to move onto the technical aspects of moving on. What is perl bad at?
(And to be clear, I don’t consider these necessarily “general” deficiencies, just problems that I would like to solve for my own reasons).
We all know that threads are evil of course. And that there are plenty of ways to do multiprocessing on perl without them, (like this and this or even this).
None of them are baked into the language.
I like writing software for me but I really like writing software for others. Stuff that’s useful, general purpose. I like to solve problems for non-technical people, or at least, people who are less technical than me. Or, lets cut to the chase, people for whom instructions that begin with “step one, install perl” are not going to fly.
Even if I’m writing something for the web, deployment is still not as easy as it might be. I’ve accrued a pretty big bag of tricks over the years of doing this, but none of them beat just throwing at executable file at a person, or at a server.
(BTW - I was heavily disappointed to find that Raku did not prioritise improving on this particular pain point. Maybe I’m the only one with this problem :-)
This one is a bit of a catch-22. I don’t need the fancy tooling on perl because I pretty much know it inside out. An IDE would be useless. I know where the documentation is. I don’t need to be able to look up method calls in a context menu.
But … these things are nice. It’s nice to use a language that can look up method calls inside an editor because the syntax is well defined and the language is introspectible and it can’t create create named methods at run time.
I know that last thing is cool and amazing and I’ve done great and terrible things with it but …. I think I’m over the fancy tricks. People are always going to scream when there is only one way to do things, including me, but even if you have to work harder now, future-you looking at that code is hopefully going to be less surprised.
If you don’t know what I am talking about, this may help.
Back to tooling - those limitations in a language at least mean that the ecosystem of the infrastructure around the language has a much better chance - especially the tools that assist with the nuts and bolts of the actual coding process.
Well, I did kind of give away the punchline with the title.
I’ve been playing around with Golang for years (and Python and Java and Swift and Rust and C) but I think I have finally gotten over the initial “hump” that moves one from “yeah, I know what that is and the basic syntax” into “yeah I know what that is and the basic syntax and I’m almost starting to understand some of the idioms and patterns”.
(Learning a new programming language is “surface level” trivial, “substance level” decades of work)
That hump is arbitrary and so is my declaration that I’ve passed it. I’ve written a couple of toy things. I’m no expert. I haven’t even got my training wheels off yet. But now I’m at least at the point where when starting a new (small) project I can stomach the idea that doing it in perl would be easy, but doing it in golang would be rewarding and a good learning experience (and a lot of hard work).
But it’s fun. And I hope it will also open some new doors.