Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

241–250 of 573 posts

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

#241
post #90

Earlier quoted context omitted.

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 wer…

Perl lost the war because it didn't turn-up for the battle. In the 2000s it went into a kind of COVID19 self-isolation phase. First there was Parrot - a half-assed attempt to create a CLR for dynamic languages. When that failed the MoarVM adventure began. There were about 3 implemetations of Perl6 in development simultaneously (MoarVM, JVM & Rakudo) as Perl5 hemorrhaged mindshare. All-in-all it took 15 years to produ…

To my knowledge, only 2 implementations were ever in development simultaneously: Niecza and Rakudo.

Niecza focused on producing a Perl 6 on the .Net infrastructure. Rakudo is based on NQP (Not Quite Perl) and initially ran on Parrot, then also added the JVM as a backend, and then later added MoarVM as a backend.

Niecza sadly stopped being developed as its main developer developer decided it wouldn't be able to come to a full release (around 2012/2013).

So to say that "about 3 implemetations of Perl6 in development simultaneously" is incorrect, and then to name MoarVM, JVM and Rakudo as the three is even more incorrect.

Perl 6 got renamed to Raku in 2019. Since the first release in December 2015, it has become about two orders of magnitude faster.

You can check out the Rakudo Weekly News should you wish to stay up-to-date on developments in the Rakudo world: https://rakudoweekly.blog

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

#242

There used to be a big Python/Perl debate. I'm not sure I could have predicted how well that would turn out for Python, and how poorly for Perl. Readability and ease of use matters?

I think it was really Perl 6 that killed it. Perl had a significant lead over Python, and the Perl 6 announcement just sucked the life out of it.

It wasn't the language, it was Numpy. Everything that is built on top of Numpy is what made Python so popular.

And I guess Perl also never had its Django (or Rails).

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

#243

I love perl, so I’ll definitely spend some time tonight trying to find out more about the plans. From just this article, it’s hard to see how this is different than just making ‘use v5.34;’ flip some switches. That’s just business as usual in modern perl, even if it changed more things than normal. Still, if bumping the major version gets people to take another look at it, it will be a good thing. And maybe there are…

They are making some space for (controlled) breaking changes. It also sends a message that Perl has a clear path going forward. I'll consider it for my next projects, especially the automation ones.

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

#244
post #76

> PHP went directly from 5 to 7, and isn’t it time to steal something from that community? :D

There was a php6... we just do not talk about it. There is a perl 6 also.

No, there isn't. Perl 6 got renamed to Raku (https://raku.org using the #rakulang tag on social media). There's a weekly blog post should you want to stay up-to-date: https://rakudoweekly.blog

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

#245
post #130

Much as people complain about Perl, it is the language which I use when I want to have something which will run 10-20 years from now. I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time ( https://github.com/jwr/ccheck ). Very happy to see a path forward for Perl 5.32.

I don't understand what you mean exactly – couldn't you use any language, even javascript, exactly the same version as you use right now, in 2100? Why not? Edit: nice tool, by the way!

Have you tried? :-) Especially in the JavaScript world, things evolve so quickly, that they become obsolete within single years. If you use node and npm, within months.

To put this in contrast, Perl 5.001 was released on March 13, 1995 — that's more than 25 years ago, and code written in it will largely run fine today.

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

#246
post #95

Earlier quoted context omitted.

> Are there actually people that are still deploying new things in Perl? My personal experience: at one of my previous jobs we've had the need to find a support ticket system (preferably free) that was flexible enough to handle a few hundred email accounts with different signatures, headers, reply templates, queues, filters, and more for each individual account. At the time the "winner" was OTRS [0] [1], a system in…

I actually worked for OTRS for some years. It is quite a remarkable company as it is creating an open source line of business software with a nice team of people and is making a sustainable business out of it. There are not much other software companies that managed to do this. Yes, you can call them open core now. But still many companies are using the community edition and are served well by it. I worked closely wi…

Nice, thanks for the link and for your contributions to OTRS, it has improved workflows tremendously on both companies I've set it up on. I've messed around on some of the source and template files for some dirty hacks over the years and did get the impression of it being very well structured and with pretty clear separation of concerns even though I'm not a Perl coder.

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

#247

Earlier quoted context omitted.

Perl definitely has a lot of non-patterned arcana. For instance, $| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0. In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files…

Sure, it's got lots of historical baggage, but there are more sensible alternatives to $| - like STDOUT->autoflush(1) - it's not like you have to use the obscure versions of every feature.

With any luck Perl 7 with phase out the archaic linenoise features. This is overdue IMO.

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

#249
post #52
post #16

Earlier quoted context omitted.

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?

On my 4-core i7 Macbook Pro: time ./startup_time.pl 0.016s time ./startup_time.py 0.295s Parsing a 20Mb log file with a regex: time ./parse_log.pl 0.683s time ./parse_log.py 1.534s For which metric are you claiming Perl is slower than Python?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Post reply on HN