We still have a few projects running Perl under mod_perl. They are about absolutely wonderful to manage, and the developers love working on them. Still, you're right, reality is that there are no new Perl projects. In our case Flask and FastAPI has taken the role of as default framework for APIs and with Java and Springboot being the default for everything else.
Some days you just want to work on something simple, something old-school, and for those days, Perl is happiness.
I started with Perl but moved to Ruby in the mid 00s. Ruby always felt like it gave me everything Perl did (performance aside, at the time), but with syntax that felt more intuitive.
Ruby's the most intuitive language I've ever used and my favorite to write in, but Perl and raw JavaScript are just dirty, tough, cowboy languages that are a blast to code in. You can just let go with all the best practices and write some gnarly stuff.
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.
I was introduced to Linux, Vim and Perl when I joined a semiconductor company back in 2007. Used them as part of writing tests in asm, automated test generation and other text processing.
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.
One of my early jobs in the industry, some 20 years ago, was at a little company that had a stock trading system mostly written in Perl. My experience with Perl prior to that had been simple CGI programming and odd scripts. The trading system was for the exchange side. Working on that system taught me a lot of things ("wtf is bless?"). Perhaps most importantly it showed me that Perl can be beautiful.
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.
One of my earliest jobs while still in high school was working for a laser printing and microfiche shop. We got all kinds of tapes from customers in all sorts of formats so I built a skillset of parsing and manipulating data in the tools available which were Snobol, PL/1 and Fortran. Lol.
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.
I've been maintaining a large perl codebase that I and some friends wrote for 20 years now. It sure has some cruft, but I am often blown away by how massively productive I am in it. And in 20 years, Perl has never broken compatibility for us that I know of. (Though a few spooky CPAN that relied on unsafe internals did require fixing.)
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.
Slightly related to your question, if you do get started with Perl you might find Task::Kensho[1] useful. It is a curated list of recommended CPAN[2][3] distributions for various tasks. CPAN is vast, so it is useful also as an introduction to CPAN itself.
I wish I could be confident that Perl 7 was actually going to see the light of day. Honestly, I was extremely excited when they announced it, and hoped it could make a real difference. The lack of real status information since then (even past the proposed initial release date) along with the implosion of the a lot of the core community and steering, is honestly what finally broke me from thinking anything could be salvaged for the future.
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 original proposal for Perl 7 was good at grabbing attention, but not good at being something that could reasonably be accomplished by the current set of core developers - it would require either maintenance of two forks of the language (not feasible), or sunsetting of Perl 5 (risking it all on unlikely adoption and migration to the new fork, and likely losing several volunteer developers).
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
The way I read it (which might have been reading between the lines), is that whatever 5.3x was released with Perl 7 would be the last in that line, but it would never die, and just get bug fixes.
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).
You were reading between the lines, and the initial announcement was writing between them. But like I said, it is not feasible to maintain a LTS Perl 5 next to a fork of the interpreter. The actual proposal was only even to maintain Perl 5 for a few years before sunsetting it. CPAN would not have been compatible with Perl 7, it would require a separate ecosystem of code and installed libraries. The ideas sound nice but I don't think a lot of people would have been happy with how the details would have worked out. 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.
> But like I said, it is not feasible to maintain a LTS Perl 5 next to a fork of the interpreter.
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.
> That it would be maintained is all that really mattered to me, and there's no doubt in my mind that it would be.
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.
Yes, this is "the Llama book" -- Learning Perl. Next to read would probably be Intermediate Perl, and then probably "the Camel book", which is Programming Perl.
(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.
> 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.
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've written a bit of Perl and have read quite a few Perl books (I legit probably own 10+), but generally prefer Python. I can't understand how someone open minded enough to be cool with Perl and it's strangeness, would be upset by something as trivial as whitespace. It obviously isn't that much of a problem as it's one of the most popular languages ever and used in so many domains with users ranging from children to Google's chief scientist and with it being a critical backbone of many companies and the defacto language to build an API for. It's fine to find it aesthetically displeasing if that is what you want.
> 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.
With perl you have to add all sorts of junk like "use strict;" and "use warnings;". There is no REPL to incrementally test small snippets. You have to remember all kinds of things such as context for sigils. I still don't have a problem with the language, it's just different.
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.
Edit: adding here since I can't edit the original article.
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.
Thanks for your reply. I think your tone was fine. But you went a little astray.
We were just talking about whitespace being promoted to logical operator, which was your interesting psychological point. Now you have unpacked your full set of criticisms. (o:
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).
"I think Go will devour all the interpreted languages eventually"
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 started with the one-liners book, and I recommend others do the same. It’s quick and useful for pretty much anyone who isn’t an AWK master. Then go learn more advanced stuff.
Looking back on it, I probably have those blue O'Reilly books ( and Perl Cookbook https://www.oreilly.com/library/view/perl-cookbook/156592243... ) to thank for starting me off on my programming career and influencing so much about how I grew as a programmer. Very informative books and fun to read. What a great set of authors.
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.
Ive read your other comments in this thread and was amazed to see you referring to yourself as an advocate.
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.
> it's a poor representation for the Perl language.
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.
There is no more a well-defined “Python people” than there is a “Perl people” – both of their user bases span industries and computing architectures, hobbyists and professionals, old bones and young bloods, true believers and weary journeymen – and they overlap significantly, for that matter. Talk about cutting off your nose to spite your face.
For the record, shitting on other languages does not represent the values of Libera #perl. Though I personally would not use python or PHP, use whatever gets the job done.
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.)
> One interesting thing I've noticed about perl is that almost all the examples of how to do something online are absolutely terrible.
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 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
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 think the programmers toolbox/toolbelt can be seriously improved by starting with education.
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.
They got good info, but good luck finding anything. It's like a Sanford and Son junk yard where you have to dig for things. Your best hope is just linking directly into a forum post that solves your problem.
Python is the ugliest garbage language ever created. The fact that it forces indenting alone is a reason to never use it. Let alone all other garbage features it has that no one needs (all PEPs that are irrelevant and should be left to users).
I guess this is a big difference between perl and python. Perl gives you a powerful concise syntax and relies on you to either try quite hard to keep things sensible and readable or deal with the monstrosity you create. Python tries to coerce you into producing something more reasonable. Language preference might come down to whether you have to read/debug other people’s code which was not written in an empathetic manner. Years of dealing with horrendous buggy legacy C is probably why I’m currently so enthusiastic about rust right now.
I use Python all the time and I think it sucks. But I don't feel the need to be obnoxious about it, and definitely am happy. Also please read the HN guidelines.
Perl has been rewarding me for decades. I will be paying for my kids' college with money I made with Perl. P5P is still active. The packages I use are still updated regularly. Perl itself is released like clockwork. Perl isn't going anywhere! Thank you Larry for building the tool that paid for my family's life
happy birthday Perl! I think it is a very nice programming language. If you manage to write junk in perl, then you will probably manage to write junk in any language. I think it's not so much a problem of the language, it's a problem of of how to approach things.
Could you please stop carpet bombing this post with identical, substanceless comments? The fact that other folks here are posting snippets to mute you indicates that you're dragging the quality of discussion down for the rest of us.
We get it. You like perl and dislike many other languages. You can stop now.
The oldest thing still running I have ever written is a small Perl program that uses OLE to access Word and convert docs to PDF.
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.
Perl already had libraries for those, and zillion more in CPAN.
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).
Thank you, Perl. I can still run my perl5 scripts from 1995. Perl is one of the very few software systems that take backwards compatibility seriously. That is especially visible when compared to some recent languages that are in fashion today, where if you so much as sneeze after several months, all of your software and dependencies are suddenly broken, and you need to rewrite your software, just because somebody thinks that This is How it Should Be Done.
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.
I'm really glad that EXTERN.h was in the first release. If you've ever written a Perl extension, you have to include EXTERN.h, perl.h (also there) and XSUB.h (not there).
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.
My project [1] still running on Perl, and it is 23 years old and still works and millions of people use it... Back then we wrote custom template system from scratch, and we never upgraded to anything.
Holy cow, didn't expect the founder of this amazing service here. I'm a super super happy customer! Thanks for making the project and for using Perl. Without Perl it would be a complete disaster, I'm sure.
> Perl is kind of designed to make awk and sed semi-obsolete.
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.
Perl has always been and will always be the greatest language. I still use Perl daily and get things done fast. While you are matching your types in your fancy garbage language (Rust, Haskell, etc), I already did the job, solved 25 other problems, and signed up 10 new customers.
Before I turn to python for many C library projects of mine, I rather use a short mkstuff.pl generator to prepare proper data structures.
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.
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.
Happy birthday from me as well! Perl 6 was a huge mistake. Catastrophically bigger than Python's version 3. Somehow developers put up with upgrading to Python 3, but ain't nobody upgrading to Perl 6.
On Unix systems people rarely used file extensions like this. Any program that you would run simply had no extension. It’s the shebang line that would launch the correct interpreter. Extensions denoting the file type was more of a Windows thing so it knew what app to use to open the program.
Sadly it has bit rotted away, but Steve Yegge made a passing reference to my short blog entry on “perlaphobia” some fifteen-ish years ago. Perl had a strange, mystical effect on my generation of developers, truly a frenemy kind of relationship where you need to constantly relearn it and undergo cycles of love, loathing, confusion, and rediscovery.
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.
163 comments
[ 2.8 ms ] story [ 216 ms ] threadI 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.
:)
[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...
Using what's now called Test Anything Protocol[2] (TAP).
[1]: https://github.com/Perl/perl5/commit/8d063cd8450e59ea1c611a2... [2]: https://testanything.org/
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.
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.
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.
[1] https://metacpan.org/pod/Task::Kensho
[2] https://metacpan.org/
[3] https://en.wikipedia.org/wiki/CPAN
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.
Perl, the friendliest cult I ever did see!
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
there shall the snake finally be consigned eternally.> 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?
[1] https://en.wikipedia.org/wiki/TCP/IP_Illustrated
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.
https://www.perlmonks.org/
http://www.modernperlbooks.com/mt/
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.
I've seen things, you see, terrible _ things.
I was sure everyone who engaged in thin and baseless language flame wars in the 90s grew up and moved on. It appears I was wrong.
Compatibility what?
We get it. You like perl and dislike many other languages. You can stop now.
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.
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.
[1] https://fotki.com
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.
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.
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.)
https://sites.google.com/site/steveyegge2/decision-time
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!
https://www.youtube.com/watch?v=C_Tz6U5jJ9M