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

471–480 of 573 posts

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

#471

Post by abiogenesis »

petre wrote: post #442
proverbialbunny wrote: post #428

Earlier quoted context omitted.

Both. Perl is around 20x slower than C for common tasks, while Python is around 133x slower than C for common tasks like looping, depending on what you're doing of course. Perl is the ultimate mockup language in that you can crank out code very fast and get good bug free results. It lets you write in the way you think where other programming languages force you to write a specific way. Ofc you can get good at Python,…

> Ofc the Perl is going to look like garbage and not be maintainable Please stop perpetuating this myth. It really depends how you write it. Perl isn't going to do the tidying up for you, you'll have to properly structure the code yourself. If you still write Perl code like it’s 1991 then maybe itcs not maintainable. I work on a largeish Perl code base and I can assure you it's quite maintainable, moreso than most Js…

> If you still write Perl code like it’s 1991 then maybe itcs not maintainable.

This is probably one of the issues with Perl. You can still write Python code like it's 1991 and it will still be readable and maintainable.

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

#472

Post by throwaway777555 »

Lazare wrote: post #403
py_or_dy wrote: post #306

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven. I…

I feel you. I'm currently at a startup that, somewhat by accident, ended up writing their backend in PHP. Modern PHP is actually fine; it's largely avoided the issues perl has; adoption of the latest versions is quite high, and it's...fine. Not the best, not the worst, broadly comparable to other languages, and a far, far, far cry from what most people may think of when they hear "PHP". My last job used Node, the one…

My experience has been the opposite. I work in a PHP shop and with each new version update, a handful of us are excited about the new changes that get made to the language. Our DevOps team has been on top of keeping our servers running the latest production-ready versions of PHP. So many of the refinements are a welcome change. I'm eager for stronger type hinting and other features that are still coming down the pipe.

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

#473

Post by singingfish »

cutler wrote: post #426
singingfish wrote: post #284

Earlier quoted context omitted.

> And I guess Perl also never had its Django (or Rails). It’s got two of them - Catalyst (older still works fine) and Mojo - newer and shinier. I think python is a better fit for mathematical work. I like to say that python helps you think more like the computer does, and that perl helps the computer think more like you.

Catalyst was no match for Rails. Mojolicious could have been had Miyagawa's PSGI/Plack appeared on the scene half a decade earlier.

rails as far as I understand is opinionated and optimised for CRUD / database type applications. Catalyst is much more agnostic about the model you use. It provides the flexibility and a way of structuring the code and providing debug tooling that makes structuring a decent size app well reasonably easy to do.

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

#474

Post by sinsterizme »

lmm wrote: post #438
throwaway373438 wrote: post #309

Earlier quoted context omitted.

If what you're saying is true, then why aren't similar criticisms raised against Ruby? Most of the same obscure variables are also present in Ruby. "If hard-to-read-and-remember syntax exists, people WILL use it" This statement doesn't appear to hold up under scrutiny.

> If what you're saying is true, then why aren't similar criticisms raised against Ruby? Most of the same obscure variables are also present in Ruby. Not with the sigil names, are they?

Indeed, there are a lot of them actually https://ruby.fandom.com/wiki/Special_variable

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

#475

Post by amirkdv »

fgasper wrote: post #415
cogman10 wrote: post #400

Earlier quoted context omitted.

I mean, the combinations of $%@ are really astoundingly bad. $ alone has so many different meanings and operations depending on context. You won't find that sort of thing in any other language. Not even PHP which for some bizarre reason brought $ along for the ride. Here's a fun exercise, write a dictionary of arrays. Now write a dictionary of 2d arrays. In any other language, that's hardly a challenge to both read a…

> Here's a fun exercise, write a dictionary of arrays. Umm … ok: my %dict = ( foo => [ 1, 2, 3 ], bar => [ 4, 5, 6 ], ); > Now write a dictionary of 2d arrays. my %dict2d = ( foo => [ [1, 2, 3], [4, 5, 6] ], bar => [], ); It’s pretty much identical to JS. Not sure how that’s supposed to exemplify how hard it is to write Perl.

I'm not the original comment author, neither am I fluent in Perl. But I suspect they meant nested hashes and not a hash whose values are arrays of arrays. As you point out, the latter is trivial.

To be clear, even a nested hash is all well as long as the depth and the keys are literals (as in your example). It is when keys are dynamic that things get unruly. And god forbid if the _depth_ of nesting is dynamic. All of these are trivial to implement in Python, Ruby, JS, PHP, ...

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

#476

Post by sundarurfriend »

Ovid wrote: post #155

As a short summary about Perl 7: If your Perl is old-school, that's OK. Use Perl 5 and we'll keeping supporting you. If you your Perl isn't old-school, use Perl 7 and get new features. If you're not sure, ask us and we'll hold your hand to help you understand. We're here to make sure you're OK.

> ask us

What's the best way to do that these days? IRC was the most active Perl place back in the day and the best place to get help, where's the best place for people to ask for help these days?

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

#477

Post by triangleman »

p1necone wrote: post #436

I'm trying to work this out but not having much luck - Perl 6 was a "lets make a bunch of breaking changes and modernize Perl a bit", and now that's branched off as a new language called Raku. Now there's Perl 7, which is sort of the same idea as Perl 6 was, but less radical with the changes? Are the same people working on both? Is Larry involved with both?

I believe it's not radical at all compared to the Perl 6 idea. It's basically "strict Perl 5" if I'm reading it right.

If Larry had said from the start "Let's make a new language and call it Raku" we would have had Perl 6 long ago, it would have been called Perl Enterprise Edition in the business world, and you'd never have heard of Python or PHP because everyone would be using Perl. Oh well, better late than never.

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

#478

Post by boring_twenties »

bch wrote: post #185
joosters wrote: post #104

Earlier quoted context omitted.

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.

Some things are unavoidable though. Perl hijacking a user space variable to do internal sort management? Bizarre to my mind, and utterly confounding the first time one accidentally runs into it. [0] https://stackoverflow.com/questions/26127617/what-exactly-ar...

I take it you've never done much shell scripting? This part of perl's baggage comes from its roots as a "better" shell/awk/sed. I don't like it any more than you do, but I must say, I wish people would reserve some of the vitriol they have for perl for the shell. Because I gotta tell you Rabbi, perl is a hell of a lot better than shell scripts. And that's even if you compare perl4 (1991-1994 or so?) to the very latest bash or zsh.

edit:

BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)

Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)

Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.

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

#479

Post by greggman3 »

py_or_dy wrote: post #306

I've been a perl zealot since 2005. I didn't even know "python" existed until around 2008 when I found a script file with a ".py" file ending in a fresh ubuntu install. I started going to perl conferences sometime after 2010 when someone on irc informed be about them. I learned so much in those conferences, mainly about the alternatives to cgi and the modern OOP "framework" named "moose". I thought I was in heaven. I…

I have disliked perl since I first started using it because it clear it's a hack with hack upon hack of fixes to try to wallpaper over how bad it is.

For example, IIRC it's pretty clear it used to be all variables were global. The solution was a manual command to push a variable onto the stack. That's a horrible solution as it requires perfection everywhere.

Another is all the special meaning but global variables like $_, $. $/ $, $\ $" $; $: $# etc etc.

Any one with any engineering experience learns quick that features like that are an anti-pattern. They're super fragile. Some lines of code down stream are expecting one of those variables to have a certain value. A simple edit somewhere can break it all.

The only languages worse are sh and dos batch files.

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

#480

Post by cutler »

singingfish wrote: post #473
cutler wrote: post #426

Earlier quoted context omitted.

Catalyst was no match for Rails. Mojolicious could have been had Miyagawa's PSGI/Plack appeared on the scene half a decade earlier.

rails as far as I understand is opinionated and optimised for CRUD / database type applications. Catalyst is much more agnostic about the model you use. It provides the flexibility and a way of structuring the code and providing debug tooling that makes structuring a decent size app well reasonably easy to do.

Catalyst was painful to work with in my experience. Just getting it setup was an achievement. Subroutine signatures as routes is an ugly hack.
Post reply on HN