Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

131–140 of 573 posts

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

#131
post #68

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.

As far as i know Java and PHP became popular later in the 90s / early 2000s. Javascript was browser only until 2010, Ruby only became popular after Rails came out mid-2000s. There is a decade gap there.

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

#133
post #68

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.

There's a subtle difference between being released in the 90s and maturing in the 90s.

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

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

Perl is still unmatched for one-liners, and by extension, one-liners that graduate to short scripts.

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

#135

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

a = [1]

def f(b):

   print(b)
f(a)

f(*a)

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

#136
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!

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

#137

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.

I also quite enjoyed perl. There are a lot of us that cut their teeth on perl and know it well, even if we are currently working in other languages. We also tend to de-emphasize it on our resumes for obvious reasons. But if I had a contract opportunity to spend months or years on a large perl codebase, refactoring it or porting it to something else, I'd probably snap it up in a heartbeat.

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

#138

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…

One can also: use IO::Handle; STDOUT->autoflush(1); STDERR->autoflush(1);

TMTOWTDI!

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

#139
post #68

Earlier quoted context omitted.

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.

To be honest Perl 5 isn't really like Perl 4. They are quite different languages - Perl 4 didn't have objects, and Perl 5 places heavy emphasis on them.

Up to you to decide when you think it started, but I'd say the current language we think of as "Perl" started with the release of Perl 5.

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

#140
post #48

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.

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…

> And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call

That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.

Post reply on HN