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

91–100 of 573 posts

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

#91

Post by ed25519FUUU »

nchelluri wrote: post #45
w0m wrote: post #38

Earlier quoted context omitted.

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.

I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all. To quote myself from a recent discussion: I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ al…

Under that standard it’s true, but it’s also true for virtually any language and is therefore not a good defense of whether or not a language lends itself to unreadable code.

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

#92

Post by _sbrk »

papito wrote: post #82
sumanthvepa wrote: post #24

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.

Perl was a great fun scripting language back in the day of CGI and "webmaster@". It died a noble, honorable death. RIP.

It's not even close to dead.

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

#93

Post by earthboundkid »

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 was released in 1987. The languages released in the 90s all stole Perl/Awk's good idea (have an associative array/hash map/dict type as a builtin data type) but had much nicer syntax.

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

#94

Post by briansteffens »

ugexe wrote: post #29
benbristow wrote: post #27

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?

How much and what kind of experience do you think someone should have with a language before beginning to form an opinion?

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

#95

Post by lgl »

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 Perl that is super flexible and had a free version (more recently renamed to community edition since it detached a bit from their enterprise version).

It served us well enough that I have deployed it again on my current job when a similar but smaller need arose (both jobs in tourism industry). It's a pretty big and complex thing but does it's job well once configured correctly which does take a bit of work.

> 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.

That can possibly be the case here since it is "old" (changelog lists the first public beta at 2002) but has had pretty much continuous development until this day. Any company trying to develop something like this these days would probably choose something else but I guess they're a Perl shop now.

[0] - https://github.com/OTRS/otrs

[1] - https://otrs.com/

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

#96

Post by mfontani »

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…

> 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]).

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

#97

Post by dragonwriter »

NortySpock wrote: post #86
QuesnayJr wrote: post #26

Earlier quoted context omitted.

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.

So it's the Osborne effect? Where you stop using Perl 5 because you're waiting for Perl 6 (announced in 2000, released never? As Raku? As a rolling release? The history appears confusing in Wikipedia.) https://en.wikipedia.org/wiki/Osborne_effect

Perl 6 was released as language spec and on the Rakudo implementation; the rename to Raku was kind of a backformation from the name of the Rakudo implementation, but it was after the first stable release.

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

#100

Post by orf »

cutler wrote: post #52
smabie wrote: 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?

Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.
Post reply on HN