Perl Turns 34 Today
github.com
github.com
One interesting thing I've noticed about perl is that almost all the examples of how to do something online are absolutely terrible. Our codebase is good because we learned how to write perl clearly, and it looks nothing like how we started out from examples.
Anyways, I don't really have a point, except to say Perl really is amazing, even if it's not really growing nowadays. I think it will be around for ages to come.
If Perl 7 is actually still coming and there's real progress there, then there's a spectacular messaging fail going on.
Perl's been my go-to language for well over 20 years, and it's the first thing I reach for when writing anything new. The problem is I'm having a harder and harder time justifying that decision. I built something small with Deno for the first time a few months back because I both wanted to try out typescript and I wanted something that I could easily turn into an executable on windows. The built in features (compile to an executable, limited security exposure based on runtime flags) and the ability to go far past JS because it as TypeScript built in all put a lot of stuff with Perl in stark relief. These are features you get when you have people actively trying to solve people's problems, iterating on substantial new and better things, and you have users (or potential users) with problems to solve. Perl 7 is/was possibly Perl's last chance to pull itself out of the ashes and try to offer something new to pull new people in and bring old users back, and I'm just not sure there's enough of a community left to pull it off. That's extremely sad, but ignoring it won't make it any less true as I see it. Hopefully I'm wrong.
The current status is, roughly, planning for Perl 7 to be a compatible release with good features, and waiting until such a featureset is ready. See https://perl7faq.grinnz.com
I viewed Perl 7 as a way to break from the expectations of the two types of existing Perl users. Those that use it for stuff they expect to continue working without fail in perpetuity, relying on Perl's exceptional forwards compatibility, and those that are willing to break that to usher in new features that are long overdue.
At work we have Perl in production that's well over two decades old, and all stages in-between because it's always been the core language of our department. The expectation that it "just works" for the most part on newer OS distro releases with newer Perl is extremely valuable to us. At the same time, new development in it has gotten more and more cumbersome over the years, both in relation to other options and in itself, as modules for newer services and APIs are less likely to be available and well maintained.
Perl 7 as an idea was exciting to me because I viewed it as a way to both satisfy the needs of the job I'm in (through a static Perl 5 version), and also my personal tastes by allowing Perl to evolve and change as needed, and add some long overdue features (or even just change defaults to be sane for the current time).
I know, but even if the Perl community didn't want to maintain it, it would be maintained. Some company would take that up and provide it (ActiveState maybe?), because there's a need for it and companies that would pay for it. That it would be maintained is all that really mattered to me, and there's no doubt in my mind that it would be.
> Most of the problems you're talking about are more a deficiency of perception and tooling, and these can be addressed without such drastic measures.
I'm not sure they can be. There's a decade of the past of evidence that they wouldn't be, even if it is theoretically possible. As soon as you make breaking changes, you would possibly lose a lot of corporate users because you force work on them where there wasn't previously, and that means deciding whether that time is better spent moving away from the aging language with an unsure future. Losing those users would gut what little was left of the community.
That's long been the catch-22 of Perl, and getting past that has long been the hardest problem facing the community, IMO.
Nor mine, but because I know that Perl 7 would die as most of the maintainers stayed working on Perl 5. Or the worst case: too many leave Perl entirely to maintain either fork. Perhaps some corporations would take up the funding, but it is not a simple piece of software you can throw new developers at and expect progress; it's an enormous C program built on thousands of macros and decades of history, as anyone who has tried writing XS code probably sees in their nightmares.
> As soon as you make breaking changes,
I am referring specifically to doing it without breaking changes, as is the current plan, and the only option at this juncture.
Start with the greatest books every written:
Programming Perl - https://www.oreilly.com/library/view/programming-perl-4th/97...
Continue with the second greatest book ever written:
Intermediate Perl - https://www.oreilly.com/library/view/intermediate-perl/05961...
Followed by equally amazing book by the greatest programmer in the world:
Higher Order Perl - https://hop.perl.plover.com/
And of course:
Mastering Perl - https://www.oreilly.com/library/view/mastering-perl/97805965...
To get super quick in the command line, also you might want to get my book:
Perl One-Liners Explained - https://nostarch.com/perloneliners
Finally, join #perl on Libera Chat.
AS A NEW USER WE LOVE YOU WITH GREAT HUGE LOVE.
(Also screw all Python programmers, what a bunch of losers with their indenting rules and PEPs. Weirdos. Whenever you hear somone say Python is good or interesting, run.)
As a somewhat "new" sysadmin/coder back in the early 2000s, those blue O'Reilly books were like a business card, comfort blanket, and encyclopedia all in one.
I'd add "Mastering Regular Expressions" and maybe "Perl Best Practices". Oh and definitely "The Perl Cookbook", because it mirrored the way I learn best; from needing to do "a thing" and finding an example that mostly fits what I need.
I think "Mastering Regular Expressions" can be almost completely replaced by 'man perlre', but perhaps not for utter neophytes.
Which makes me wonder how easy it is to make a pipeline for man pages to my Kindle device/app. Hmm. Another rabbit hole to follow, joy!
Amen. This is my credo.
I had to program Python in my last job and I ran as fast as I could from that world of artificial limitation, and landed squarely in the land of camels and onions: The Promised Land.
I see a world where /usr/bin/perl will become PID1 and at every system boot will
mv /usr/bin/python /dev/null
> I can't understand how someone open minded enough to be cool with Perl and it's [sic] strangeness, would be upset by something as trivial as whitespace.
Thank you for the compliment of open-mindedness. Every language is strange to some degree until one becomes proficient. Notice your own grammatical error above. English too is strange until one masters it. But we won't blame people for making mistakes because bad code can be written in any language.
Whitespace is not trivial in Python. It has been promoted to logical operator.
Now everything that I type gets broken unless I use an editor to protect me. Oh, you might say, any modern editor should be capable! This leads to IDE dependence like Eclipse and PyCharm (both written in... Java).
There is none of this nonsense with Perl. I work on systems of every size with the simplest, most robust set of tools. I don't need a complex baseline just to write my code.
> It obviously isn't that much of a problem as it's one of the most popular languages ever and used [...] from children to Google's chief scientist [..] critical backbone of many companies [..] defacto language to build an API for.
C, C++, Java, Javascript and Bash are also very popular languages. The first three are more important that Python. And they are all unlike Python. Google has formally sponsored Python for some time, which certainly helps Python. Google has also been developing Go, which is itself a better language than Python in many ways. And Go solves the problem of formatting for readability in a sane way (go fmt).
An API can be expressed in many ways.
> It's fine to find it aesthetically displeasing
The above criticisms are objective.
However, I don't like how many lines idiomatic Python requires because of the whitespace promotion. At its best, Python allows clear, compact expressions such as lambdas.
At worst, Python is needlessly puffed with emptiness. Perl is as compact as the coder wishes it to be. It is easy to run perltidy and colourise the output for a formatted view if one prefers.
I don't think anyone would compare Python to C or Java. C is good for microcontrollers and drivers (that sort of thing), while Java is good for large enterprise systems. Python on the other hand is an excellent scripting language. Much more popular than perl by the numbers where nearly all scripting, data science (well, R too), and ML is used. Every application I've seen in the last decade has had a Python API, but none use a Perl. I've literally never heard of a Python developer switching to Perl, but I've lost count of the number of folks switching to Python from Perl over the years (HN threads). Simply speaking, the numbers show that the faults of Python (there are many) are still less than those of Perl (also many). As far as whitespace goes, it means it's easy for all Python coders to read each other's code once you adjust for a spacing difference. No need to run something like "perltidy". I've never once needed a fancy editor like eclipse. I've used the little Tk editor IDLE, Spyder, just notepad ++, and Vim + Command Line just fine over the past decade, just like how I've used Perl.
All in all, they're both great languages with several warts. Google isn't replacing Python with Go. Their uses are very different. Obviously Go makes for a more performant backend, but requires significantly more code, so there is a trade off. I would bet that Python and Perl have a pretty similar amount of semantic density (or whatever it is called). Saying it is puffy nothingness makes little sense. Just something like iterating through a file is pretty much the same in both languages. The use of lambdas was discouraged by Python's creator as it means more stuff for developers to learn and keep in their head. Larry Wall's TIMTOWDI means that the developer gets more power, but there are 10 different ways to do something and a lot of folks REALLY don't like that as it makes maintenance and learning more challenging.
I hope the tone didn't come off as condescending or too argumentative. I was just doing my best to essentially say that all software stinks in it's own way (including both Python & Perl). The few times I've reached for Perl over the years, it has worked fine. Some of the issues such as having a fairly primitive OO system out of the box without reaching for Moo or Moose on CPAN are more than addressed with the very advanced Raku (formerly Perl6), but at this point, that's a perl inspired sister language and not a viable upgrade path.
I will argue that it isn't primitive, but that it is composable and as lean as you want it to be. If I want a dict with just two methods, I can build it easily and with small memory usage. (This is important when scaling objects into the hundreds of thousands... or more!)
TBH, Perl5 OO is easy and tractable. I would agree that the "bless" artefact is unusual, but it does make sense from the point of view of C structs.
Oh, as far as REPLs go, there are some easy solutions for Perl, from trivial to more complex. Python's REPL is limited because it doesn't handle multi-line structures well. That is in part a consequence of using whitespace as a logical operator.
A couple of things attract additional comment from me:
> With perl you have to add all sorts of junk like "use strict;" and "use warnings;"
You named two things, and you call them junk. Maybe you don't recognise that these statements do toggle functionality in a useful way. Perl can be used effectively as a piped-command language. Perl's notation makes it terse and powerful.
> I don't think anyone would compare Python to C or Java.
But you made an argument from popularity. If popularity is to be taken as a rational, enlightened movement, other very important languages have converged on different notation from Python. (If we are still talking about notation and whitespace.) Python's notation is not the most popular, as much as its evangelists insist. Add Go lang to the bigger group as well.
I think Go will devour all the interpreted languages eventually.
> data science (well, R too)
Yes, in this field (data science may be a marketable construct), C++, SQL, R, Python, and Jupyter play the major role. Other languages may offer more in the future. Folks talk about Julia, for example. Perl's PDL has not been adopted as widely. Of course, once you have data, you can science it with any fast, robust tooling. I often use awk and Perl too.
Do you dislike awk and sed as well? I find that common among Python programmers.
> they're both great languages with several warts.
No language made by monkeys is going to be "perfect". Go fmt and perltidy make more sense than building an ecosystem for a personal preference. We both know that bad code can be written in any language.
I use both languages daily. Python has a better threading story despite the GIL. But I can find better tools that don't have Anaconda-size dependencies. (I cannot easily summarise my contempt for pip).
This discussion was amusing to read, but I have to butt in days late. Go will not devour any interpreted language without an available interpreter of its own.
I now program almost exclusively in Python (it's good and interesting) and Java. But occasionally I fall back to Perl for something that is just so much simpler - almost muscle memory.
I think you do the language a disservice and associate Perl with childish views on other languages.
May explain why Perl is struggling.
I really hoped unintelligent bashing of languages died out after those of us who were 12 in the 90s grew up and realised peoples tooling isn't a personal statement.
> (Also screw all Python programmers, what a bunch of losers with their indenting rules and PEPs. Weirdos. Whenever you hear somone say Python is good or interesting, run.)
Even as a jest, it's a poor representation for the Perl language.
Python has problems but has enjoyed success for a few reasons.[1] I think one of the worst side-effects of Python is that Python programmers tend to look at any powerful language with disdain if it has any non [a-zA-Z] characters. "Can't we just replace everything with Python?!"
Becoming a language bigot -- or joking like one -- does not help.
Perl can stand very tall on its expressiveness, stability, speed and simplicity.
[1] I'm going to say...
a) Python is more readable, but makes the crazy compromise of using whitespace as logic.
b) Python has adequate threading for many use-cases.
c) Python's built-in OOP has better affordance than Perl5 OOP. BUT... Perl enables building anything you want. If you want a dictionary with only two methods, you can build it. And Perl5 will have a more modern OOP implementation.
The Python people started this fight in 2000 and have since said much worse and heaps more, most of it untrue and libellous; turn-around is only fair. Those who live in glass houses shouldn't throw stones.
I applaud this, standing.
Yeah, that's definitely a problem with systems that have evolved over so long. I feel like C++ is kind of in the same boat: certainly what I learned 20 years ago is not relevant to how its done today.
The Internet is a wide repository of knowledge, but Perl really needs a "How To Perl in the 2020s" repository. A book would be good, but for wide reach, it'd really need to be online.
I'd like to see a site, perhaps a wiki, that has sections for various technologies (programming languages, operating system, applications, frameworks, libraries, protocols, etc).
For each, it would have some sort of list that lets you tell what from X years ago is still relevant when using that technology today.
In particular, I'd like it to include a list of good past books on that technology and for each tell you what from it would still be applicable as is, what would require minor modifications, what would not be useful, and what would be harmful if you were to try to use that book to learn that technology at the level covered by that book.
For example, it has been 20 years since I did any serious low level networking. If for some reason I needed to get back up to speed on that for some new project could I reasonably start by grabbing my copies of Stevens' "TCP/IP Illustrated" series [1] from my library and rereading them?
I’m in college and just took a course including Perl and I suggested to the instructor that students get taught functional programming skills through real life applications that are progressive learning skills.
How do I tell it to just put shims in ~/perlBin?
You can use a known good env manager like perlbrew, perlenv, bootstrap-perl, perlall to work around the problem you're seeing until HB is fixed.
It has had a few tweaks over the years, and is now nearing 20 years of age. I've used it in different companies I have worked for.
The job I had the most fun at was probably one in which I had to extract data from various documents (xls, doc, etc). All with Perl, of course. I don't think any other language or library would have enabled me to be so productive at this particular task.
So congrats to this wonderful language and its creator, Larry Wall.
Nowadays it would be rather easy to do it on python or ruby with a library that reads these filetypes.
With Rivescript you could even write a chatbot, and OFC the "original" one for Perl was "MegaHal". Also, it made pretty easy to bind the chatbot to an IRC network (and later, MSN and Jabber).
Good times.
The only other comparable language is Clojure, where backwards compatibility is treated as a priority, and I can still run my programs from 12 years ago without a hitch.
This is important, and it is something that you learn to appreciate as you get older. When I was 25 I also didn't care.
Using what's now called Test Anything Protocol[2] (TAP).
[1]: https://github.com/Perl/perl5/commit/8d063cd8450e59ea1c611a2... [2]: https://testanything.org/
Migrating hundreds of thousands of email accounts from one system to a new one. Source information was variously LDAP, custom information systems, Lotus crap, etc etc. Destination was another LDAP server. Perl took all that text in, munged it around, then loaded it into the destination. Back then I didn't know it was called ETL, and to me it was like magic that I had written.
Out of all the ETL systems and languages I've encountered over the years since then, Perl has been the fastest to develop and most flexible. The "text in, regex or otherwise select into objects, transform stuff, then transmit to server" abilities of Perl were just so slick.
Also, Perl is partly responsible for my move to the USA. Slashdot and its associated Everything2 site were written in Perl, and I met my (now-ex) wife through Everything2.
Thank you, Perl, for being pretty danged awesome and oh so flexible. :)
EDIT: and thank you Larry Wall for showing me that programming doesn't have to be stodgy and boring, that language has beauty.
That really takes me back!
Paradoxically, Perl 6/Raku's extremely long development cycle has led to Perl 5 "stagnation", in other words stability, which is a good thing.
Personally, I didn't like that Perl has spoiled the concept of regexps with (Turing-complete?) constructs when it originally was beautifully aligned with the regular/context-free-and-above language dichotomy.
And that Perl came to replace my beloved, and portable, awk/shell scripts.
Aaand that Perl, for a while, usurped the ".pl" file suffix, when everybody knows it belongs to Prolog programs.
(Nowadays, the most common filename size limit seems to be either 255 bytes or 255 characters, depending on the filesystem.)
It turns out some people have been studying this for Java: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94...
That system ran a few small exchanges for many years. I doubt anyone who traded on them knew that their orders were handled by a big Perl system.
Later after devouring the dragon book and learning YACC and so on it was hella fun to write parsers in 'C' for my new employer. In fact I got a contract to do some data munging for a gas pipeline because their processes needed some serious help, and that's when I discovered PERL. Larry Wall's reporting language turned me into a super hero because although I was already fast dealing with data, PERL meant I could turn around any request in a few hours. It was (and still is) amazing.
// ==UserScript==
// @name Mute users
// @namespace Violentmonkey Scripts
// @match https://news.ycombinator.com/item
// @grant none
// @version 1.0
// @author -
// @description 12/18/2021, 9:43:19 AM
// ==/UserScript==
const mutedUsers = ['usernamehere']; // <== CHANGE THIS
window.addEventListener('DOMContentLoaded', mute);
function mute() {
for (const mutedUser of mutedUsers) {
const result = document.evaluate(`//*[@class="hnuser" and text()="${mutedUser}"]/ancestor::*[contains(@class, "comtr")]`, document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE);
for (let i = 0; i < result.snapshotLength; i++) {
const el = result.snapshotItem(i);
el.remove();
}
}
}This isn't a "wait a bit and things will be fine" situation.
Flagging and voting has always been controversial on HN, but when it doesn't work at all even with those — I have no idea how it could work with slightly controversial political stuff.
news.ycombinator.com##tr[class="athing comtr"]:has(a[href="user?id=usernamehere"])Then in 1999, Red Hat files an IPO and offers free shares to open source developers. That blurb in the perl source got got me included in the Red Hat IPO but the email was so strangely worded I assumed it was spam and deleted it. Oh well.
I routinely use awk and sed today, and avoid Perl like the plague. My experience says that something went very wrong in trying to achieve that initial design goal.
I mean I still write Perl for my day job, and I like the language, but unfortunately that doesn't change the reality.
Some days you just want to work on something simple, something old-school, and for those days, Perl is happiness.
If anyone reading this is looking for a new challenge and loves Perl, do give me a shout.
Happy Birthday my old friend!
I started using it in the early 90s and it's paid the bills ever since.
Thanks to Larry and the whole community.
Jokes aside, Perl is the swiss-army knife of programming. It can do anything, most Linux variants have some version of Perl installed, and you can cut yourself very easily.
Most of my work goes through evolutions depending on eventual use. Many staying in the first phase.
Proof of concept/one shot work just needed by me: Perl
Needed by internal or external developers who know what they are doing: Python3 rewrite
Needs to be robust: Java/C/C++/Rust
The speed with which you can prototype by piecing together micro C programs mixed with Perl orchestrating them is really something that has benefited me throughout my career!
Where I work our most popular site is written in Perl. It keeps running.
Our previous intern wrote the processing pipeline that I just ran this week in perl that processes 100s of gigs of NCBI data into our database tables. It’s totally the right tool for this job.
I find it a beautiful and at times difficult to maintain. CPAN is amazing until it’s not. Though the fact Perl 6 failed means less having to update these backend scripts which is nice).
I've heard that these days they've moved to Python (which reflects my own preference for writing scripts). I still use Perl for cli one-liners when sed/awk aren't enough.
I have written some pretty nasty Perl code, and some that I thought was pretty clean. I have saved massive amounts of my and other people's time with Perl.
But over the last several years, I have written more Python, to the point that I run "perl -c" on a one-off script, and wonders why it objects to "def myfunc {...", and I leave out semi-colons. I write the Python because the young now seem to have learned Python in middle school, and they're going to be in the workforce a good deal longer than I am.
[edit: added URL for SATAN]
So gradually over the years I've dipped in and out of Perl. I've found the learning curve much steeper than Python, or even C, but once surmounted the payoff is immense.
So I eventually wrote my own static website generator in Perl, available here for the curious:
https://github.com/lordfeck/rsru
A sample of what it generates is here:
Even lately at work, I was tasked with the tedious job of manually converting JSON files into Excel for a customer to review, then we'd have to convert them back to JSON.
Guess what I did instead ;)
The few python test runners I maintain cause much more trouble and do much less, than my dejagnu, autotools, cmake, or shell test runners. But when I'm needing a mock service to test against, I happily use python (or just C). A multithreaded C server is still easier written in C than python or perl. And 100x faster.
Wrote my first CGI script in 1998 to be hosted on Hypermart.
I’m still maintaining a large Perl project these days. Mostly out of love, not money.
But my heart is in TypeScript these days :)
I recall struggling to get the correct GD libs installed that supported GIF and JPG so I could build the GD Perl mod.
That obviously didn't age well.
I've never programmed in Perl, but a couple years ago I read a Raku book and was delighted with the language. At the time, I was interested in learning a new scripting language. Raku and Tcl were at stake. I built a small script to compare the run speed and Raku was about 40 times slower than Tcl for my use case, if my memory is not betraying me. So, I went for Tcl that I also like very much.
Still, there's some opportunity for Perl, as I may need it in the short future.
From the features of Raku that are mentioned in the home page, namely: 1. Object-oriented programming including generics, roles and multiple dispatch 2. Functional programming primitives, lazy and eager list evaluation, junctions, autothreading and hyperoperators (vector operators) 3. Parallelism, concurrency, and asynchrony including multi-core support 4. Definable grammars for pattern matching and generalized string processing 5. Optional and gradual typing
what are the ones that will be available for Perl7, which I've already read that will be similar to the last Perl5 with saner defaults?
:)
[1]: https://www.perl.com/article/announcing-perl-7/?ref=alian.in...
https://github.com/Raku/problem-solving/pull/89#issuecomment...
There was the personal realization that the two factions in what was then the Perl community, would never see eye to eye on what the language called "Perl 6" was. And that all of my efforts of reconciliation, such as the Perl Reunification Summit http://blogs.perl.org/users/gabor_szabo/2013/02/perl-reunifi... had been in vain.
Which lead me to open an issue https://github.com/Raku/problem-solving/issues/81 which in the end resulted in the rename to the Raku Programming Language https://raku.org .
I'm sorry about your efforts being in vain. That sounds exhausting and demoralizing.
What are you up to now?
Focussing on the Raku Programming Language, being a member of the Raku Steering Council, writing a weekly blog post (https://rakudoweekly.blog/blog-feed/), writing blog posts for the Raku Advent Calendar (https://raku-advent.blog/category/2021/), creating and maintaining modules (https://raku.land/zef:lizmat), doing Rakudo core development (https://github.com/rakudo/rakudo/graphs/contributors), setting up a IRC log server (https://logs.liz.nl, still in alpha), posting on Reddit (https://reddit.com/r/rakulang) tweeting a bit (https://twitter.com/liztormato).
The usual, I'd say :-)
https://perl6advent.wordpress.com/2015/12/25/christmas-is-he...
I've seen things, you see, terrible _ things.