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

361–370 of 573 posts

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

#361

Post by cutler »

proverbialbunny wrote: post #341
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…

Keep in mind TDD wasn't really invented yet, so it's understandable. Also, CPAN had better libraries than pip did all the way up until I last used Perl in 2015. Ofc, it depends on what you're doing. My point is, there was a reason to use Perl once upon a time ago. The alternatives back then were PHP, C, C++ (the old bad kind), BASIC, assembly, FORTRAN, and others like Smalltalk. Seeing this, it's understandable why J…

I don't know about TDD specifically but we have the Perl community to thank for setting the bar for rigorous testing back in the ealry 2000s with the numerous Test:: modules on CPAN.

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

#363

Post by syx »

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…

Thank you for sharing this story, it's really eye-opening

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

#364

Post by hpcjoe »

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.

Lots of new things. Perl is an immensely powerful language. If you know how to write code well, it will be fully comprehensible by even casual programmers.

Many orgs ship perl based tools as current, up-to-date products. Mellanox OFED is one I was using earlier today.

My own github[1] has a plethora of perl projects.

[1] https://github.com/joelandman

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

#365

Post by jschwartzi »

rlpb wrote: post #101
earthboundkid wrote: post #84

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…

I'm no fan of Perl, but you can use $OUTPUT_AUTOFLUSH instead if you "use English;". So this isn't really a Perl language thing; it's a style thing. Other languages can be made to look really bad with poor style. The question then becomes what is culturally accepted, and what is not.

The problem is that nobody ever tells you these things, the documentation doesn’t cover them and as a result everyone still uses the terrible original syntax.

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

#366

Post by daotoad »

cutler wrote: post #127
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…

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!

The reason for the @_ is that it is a simple way to get both pass by value and pass by reference semantics.

The values in @_ are aliased to the values in the subroutine call.

Most of the time, you want pass by value semantics, so you unpack the array and copy the values into function variables. If you want to modify an argument, it's typically passed in as a reference, and you can mess with it that way.

However, there are times when it would be horribly inefficient to make those copies, or when you need to do some magic (generally best avoided in 99.999% of your code), that this makes possible.

Also, since Perl functions are always variadic, it means that it's easy to work with a variable list of arguments in a function. For example, if you are expecting a list of key value pairs for your function, you can simply write:

  my %args = @_
Making signatures default will be a big improvement, but the power of the simple abstraction @_ provides should not be underestimated. It's actually an elegant solution to a complex problem.

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

#367

Post by mfontani »

cesarb wrote: post #128
mfontani wrote: post #96

Earlier quoted context omitted.

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

Right, which I sorta kinda get why coming from C - a *something is the thing pointed to by that something.

How is that more understandable than @ vs \@ without knowing the language? My guess is it isn't.

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

#368

Post by hpcjoe »

papito wrote: post #149
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.

IMDB was written in Perl, notoriously. Seeing that the layout has not changed in ages, I can only assume it's still Perl. I'd imagine a bigger rewrite effort would have led to a more slick iteration on the UI, and it seems the legacy HTML templates are still baked in.

Hmm ... don't conflate the presentation UI with the underlying language. I wrote my companies website (2 jobs ago) in Mojolicious (perl web framework), with a responsive UI, based in part upon bootstrap. Very modern (for the time) UI. All backed by a very fast implementation.

IMDB seems plenty fast to me. UI isn't great, but that's more of a presentation layer design thing than a language thing.

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

#369

Post by hpcjoe »

yellowapple wrote: post #208
papito wrote: post #149

Earlier quoted context omitted.

IMDB was written in Perl, notoriously. Seeing that the layout has not changed in ages, I can only assume it's still Perl. I'd imagine a bigger rewrite effort would have led to a more slick iteration on the UI, and it seems the legacy HTML templates are still baked in.

DuckDuckGo's also written in Perl, and doesn't seem to have any trouble maintaining a reasonably-modern-looking UI.

And their interview process is apparently, contribute a useful feature to the code base. Which, IMO, is brilliant.

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

#370

Post by Konohamaru »

DonHopkins wrote: post #173
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.

That certainly doesn't solve the problem of other people showboating their knowledge of obscure Perl sigils by using those ridiculous line-noise abbreviations in code you're trying to use and understand, so you have to look up each bit of obscure punctuation in its particular context in order to understand the code. If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to u…

> If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.

Just like every human language that ever existed. And last time I checked, programming languages aren't used or written by AI's or aliens.

Post reply on HN