Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

31–40 of 573 posts

Re: Perl 7 is going to be Perl 5.32, mostly

#31

They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

> Are there actually people that are still deploying new things in Perl?

Anecdote: I found this Perl image-hosting package a couple years ago as a self-hosted alternative to sites like Imgur, and I think it's great: https://framagit.org/fiat-tux/hat-softwares/lutim/tree/maste...

Re: Perl 7 is going to be Perl 5.32, mostly

#32

They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

I think the US Courts still use Perl for Pacer (https://www.pacer.gov/psco/cgi-bin/links.pl) and it seems to be used by the US Cours as well: https://ecf.azd.uscourts.gov/cgi-bin/ShowIndex.pl

Re: Perl 7 is going to be Perl 5.32, mostly

#33
post #16
post #5

Earlier quoted context omitted.

I do. Efficient, cheap and stable. Ported to about everywhere.

What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python. Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?

> it's even slower than Python.

It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.

> Are you saying the language doesn't change much or that it doesn't crash?

Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.

Re: Perl 7 is going to be Perl 5.32, mostly

#34
post #16
post #5

Earlier quoted context omitted.

I do. Efficient, cheap and stable. Ported to about everywhere.

What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python. Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?

- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly.

- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.

- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.

Re: Perl 7 is going to be Perl 5.32, mostly

#35

They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the codebases (old and new) to newer systems and stacks. As you can tell, the SMEs have no interest in learning other things and so any new initiatives that require them to implement it is subject to their preferences.

Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers.

You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way.

So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.

Re: Perl 7 is going to be Perl 5.32, mostly

#36
post #15

This feels like a last ditch attempt to save a dying language. ( https://i.imgflip.com/4676mf.jpg ) I wonder what exactly does Perl bring to the table as a language, why would one consider choosing it over other languages.

People are interested in using it and people are interested in developing it, so it continues to be used and developed.

I got my start with Perl; I wrote a book about it, I spoke at every conference, I did training, I maintained the Emacs mode. I started working at Google and, forced to use static languages, found them to be just as productive as Perl. And, they eliminated a lot of problems with Perl -- libraries were resolved at compile-time, and I just ended up with a binary that could be run anywhere (no @INC madness); types were checked at compile-time, so silly errors that required extensive unit testing in Perl could just be automatically underlined by my editor and fixed before I even saved the file.

Something else that bothered me was how much mindshare the dynamic languages were competing for among themselves. I would prefer to write a Perl program over a Java program any day... but Perl did not seem to be fighting with the Javas and C++s of the world, instead it was always trying to take on Python and Ruby. And Python and Ruby were like that too -- every Ruby programmer was out to kill Perl because they didn't like Matt's Script Archive. (Nobody wrote 1990s Perl in the 2000s, so it was kind of a strawman.) You ended up with a bunch of like-minded people fighting for the small attention share of "we don't really care about runtime performance", and all the factions were just too small to take on the larger issue of entrenched static languages. Java and C++ never felt like they had to take features or ideas for Perl, Python, or Ruby. So it all seemed kind of pointless.

With all that in mind, I do think Perl failed to "win". It is a neat programming language, but probably too complicated for beginners and not productive enough for people that have gotten comfy with C++/Java/Go, which are pretty darn productive these days. Meanwhile, Python found its niche pretty much everywhere -- you can program microcontrollers with it, you can write a video sharing website with it, you can do data science with it -- and it's a great introduction to programming for beginners. And, Javascript kind of came out of nowhere to conclusively "win" the dynamic language war (because a dynamic language needs a runtime, and guess what runtime exists on pretty much every computer and phone around these days?)

TL;DR: I kind of agree that the programming language wars have been fought and lost by Perl. That doesn't stop people from wanting to make it better, or to continue to use what they know. You can make lots of great things with it, so people continue to use and improve it.

Re: Perl 7 is going to be Perl 5.32, mostly

#37

They last line of the article summarizes it well: > Perl 7 is v5.32 with different settings. Your code should work if it’s not a mess. Expect a user release within a year. Are there actually people that are still deploying new things in Perl? The only times I see it is for legacy stuff, and then only because the script is too much of a hassle to be rewritten.

Sure: https://www.theregister.com/about/company/website/

Re: Perl 7 is going to be Perl 5.32, mostly

#38
post #29

Earlier quoted context omitted.

I used to work for a company that used Perl as their primary language. The codebase was millions of lines long, modules (pm files) with like 1000 methods and 10,000 lines, a total mess and it had 0 unit tests too. Almost beyond salvageable. Left a bit of a sour taste. They're trying to migrate to AWS but AWS don't even natively support Perl in their libraries. There's a few third party libraries in CPAN but nothing a…

Your opinion on Perl is based on one code base you worked at on one job?

Honestly that's more than most I think. I've written tens of thousands of lines of perl professionally and I generally share the same opinion.

Re: Perl 7 is going to be Perl 5.32, mostly

#39
post #25

tl;dr - Perl 7.0 is going to be v5.32 but with different, saner, more modern defaults. Perl was great 20 years ago for basic scripts. Where is it still used today who hasn't transitioned to Python/etc?

Perl continues to be great for basic scripts. Why change and throw away 20 years of experience?

The only thing I've noticed that's lacking is decent protobuf support.

Re: Perl 7 is going to be Perl 5.32, mostly

#40

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

Ok, so I wrote tons of Perl and am to this day a fan, but I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_.

It is flexible and fun and I do miss it.

True story: years of passing functions to other functions and map/greps made the switch to FP Scala (another language I fear will die) a lot easier!

Post reply on HN