Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

Post reply on HN
Print view View original

121–130 of 573 posts

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

#121

Post by foobar_ »

noisy_boy wrote: post #83
foobar_ wrote: post #64

This is just bad maintenance. Just pick all the stuff people are complaining about and fix it! 1. Improve threads 2. Improve C API support 3. Give local::lib, cpanm by default ... multiple perl versions by default 4. Give direct support for coroutines / async await 5. Mark experimental features as non-experimental (attributes, signatures) 6. Pick an OO system, package system 7. Make switch cool again 8. Get more core…

One more: add a proper exception handling setup.

Yeah that too! People keep saying perl is a bad language or something and the other languages can't even get implementing closures right.

I've always liked the references syntax, probably the most complained about feature. Its just pointer thinking. You could probably collapse `$array[$x]->{"foo"}->[0]` to `$array[$x]{"foo"}[0]` and save some keystrokes.

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

#122

Post by kungtotte »

cutler wrote: post #68
ricardobeat wrote: post #49

Earlier quoted context omitted.

This seems to be a common experience - people say it felt powerful and modern in the 90s, because it was . For those who started programming in the 00s and 10s it looks clunky and weird compared to the other options.

That doesn't add up because today's most popular languages - JS, Java, Python, PHP and Ruby - were also released in the 90s.

Perl 5.0 was released towards the end of 1994.

Python 1.2 was released in 1995.

The first public release of Java as 1.0 was in 1996.

JavaScript appeared in 1995 as well, but the first ECMAScript standard didn't appear until 1997.

First release of PHP was in 1995, same with Ruby.

Perl pre-dates the initial release of all those languages and was already up to its fifth major version by that time.

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

#123

Post by roywashere »

lgl wrote: post #95
banana_giraffe wrote: post #2

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? 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 with the technical founder and he started the pre-decessor of OTRS in the 90s while working at SUSE, and yeah of course it was in Perl!

I must say that working on the quite significant OTRS code base, with proper code conventions, 'modern' perl5 is not so bad. But when using third party libraries sometimes you'd see arcane language usage and there seems lots of magic involved...

Also, the technical founder started https://zammad.org -- the same idea but started in 2012 or so. So now it's Ruby!

Modern perl5 is ok. But the ecosystem is slowly deteriorating.

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

#124

Post by timwaagh »

fmakunbound wrote: post #53

According to the Modern Perl author, Five things Perl (Still) Gets Right: * Compatibility * Quality * Usability * Scalability * Availability https://pragprog.com/titles/swperl/

Mostly the last one. It's included by default with most linuxes and cygwin. So even if your boss hates you and doesn't let you install anything you can still write scripts.

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

#125

Post by BruceEel »

peterwwillis wrote: post #85
jes5199 wrote: post #48

Earlier quoted context omitted.

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that fig…

> You learn perl, and you've learned nothing but Larry Wall. Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose. Today I can run Perl code writt…

Not a Microsoft fan, but simple C / Windows API code from 25 years ago would likely compile and run on Windows 10 unchanged.

My limited experience with Swift suggests that even 25 hours ago could be a tall order...

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

#126

Post by jrockway »

cutler wrote: post #90
jrockway wrote: post #36

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…

Yeah, Perl 6 was certainly A Thing. I am not sure practicing Perl programmers cared much about it. I went to the talks and thought "neat" but it didn't really seem like "welp, this is taking forever, I'm switching to Python." Maybe if everyone working on Perl 6 decided to work on data science tooling instead, Perl would have "beaten" Python in that area and things would be different, but the world doesn't really work that way, so I don't think Perl 6 really mattered in terms of Perl fading away. A lot of people learned a lot of things about language design, and that will no doubt benefit the entire field for many years to come. (Look at "Go 2" versus "Perl 6", for example.)

On some level, everything is like that. Perl was a better awk/grep and was successful in replacing those tools. Then one day, someone decided to use it for CGI, and it got a huge popularity boost. But the people that decided to use it for CGI could have easily used something else, and it would have probably worked fine and Perl never would have been popular. It was just random chance that they picked Perl and made it popular. I feel like everything works that way. Javascript is popular for web UIs because someone decided to add it to a popular web browser. There is always some intrinsic randomness that plays a part in gaining mindshare. A bad tool with a good mindshare can do well, and a great tool with no boost can languish in obscurity. Perl benefited a lot from luck, but rolling the dice doesn't last forever.

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

#127

Post by cutler »

benbristow wrote: post #67
jschwartzi wrote: post #59

Earlier quoted context omitted.

Yeah, I've got a Perl codebase that's conservatively tens of thousands of lines, and it's honestly a struggle to write anything in it that isn't a big ball of mud. There's about 50 different ways to do anything in the language, the syntax is infuriatingly obtuse, and you can't rely on any documentation because it will recommend doing things that experts don't recommend doing. The system is from like 2013 and still go…

Perl's syntax is really confusing. Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar. Compared to Python for example where you'd literally just pass the array to the method…

For many years Perl subroutines didn't even have method signatures so you had to unroll @ on the first line of every sub. I think even today it may still be considered experimental. Jeez!

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

#128

Post by cesarb »

mfontani wrote: post #96
benbristow wrote: post #67

Earlier quoted context omitted.

Perl's syntax is really confusing. Especially for example how variables have symbols for different types ($ for scalars, % for hashes, @ for arrays). And if you want to for example pass an array to a function you have to send it manually referenced with like method(\@myArray) which then inside the method is contained in a $scalar. Compared to Python for example where you'd literally just pass the array to the method…

> Compared to Python for example where you'd literally just pass the array to the method like method(array). How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter? In Perl, that's the difference between foo(@bar) and foo(\@bar) or foo(1, 2, 3) vs foo([1, 2, 3]).

> How does one tell Python to pass the contents of said array as distinct parameters to the function, instead of as a lone array parameter?

With an asterisk: method(*array)

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

#129

Post by cutler »

smaili wrote: post #20
banana_giraffe wrote: post #2

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.

IIRC Craigslist was written in Perl but that's the only high traffic site that comes to mind.

The fashion retailer Net-A-Porter has been a Perl shop since 2000. Haven't checked if that's still the case. They used to employ quite a few leading lights in the UK Perl community a few years ago.

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

#130

Post by jwr »

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.

Post reply on HN