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.)
> (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.
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!
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.
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.
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 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.
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 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.
I see a world where /usr/bin/perl will become PID1 and at every system boot will
mv /usr/bin/python /dev/null
I applaud this, standing.