Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

381–390 of 573 posts

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

#381
post #343

Earlier quoted context omitted.

> Can you imagine a budding musician complaining that musical notation should be made "easier for beginners"? You mean like string instrument tab coloured by finger instead of sheet music? Yes, exactly like that.

But you would still have to master notation if you were to become an accomplished jazz musician, for example.

Sure. The context is "dumbed down to make it easier to learn" not dumbed down and forced on everyone. If you want to go full Brian Eno, you can. (https://public-media.si-cdn.com/filer/2b/e0/2be067d0-c428-40...)

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

#382
post #73

Earlier quoted context omitted.

Perl 6 is basically a totally different language than any other Perl, and it took a very long time to go from announcement (2000) to release (2015). It was renamed to Raku last year.

String parsing - Perl5's forte - is still dog slow with Perl6/Raku and year after year we hear that will change in the future. Don't hold your breath.

Raku's big strengths lie, IMO, in the command line scripting capabilities (the MAIN function), parsing with grammars and powerful new regex syntax, and as a glue language. It's relatively easy to bind to external libraries and work with them.

Look at how easily raku binds to a python charting module in this article: https://www.perl.com/article/plotting-with-perl-6/

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

#383

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…

> perl has been the same since 2002

if you ignore perl 6 then you might as well ignore python 3. And even still, python 2 is dead. There are only a handful of languages as well maintained as Perl 5.

https://en.wikipedia.org/wiki/Perl_5_version_history

Perl maintains strict backwards compatibility. I can run code that was written decades ago. I really am curious what features you think Perl 5 lacks.

> Another issue is just the bit rot of cpan.

Sure. But NPM exists. There is unmaintained JS code that was created only 6 months ago. Github is littered with orphaned garbage. I could probably find a dozen or so packages within my company's node_modules folder. Perl is less used today so of course the packages are outdated. But in terms of purely giving a crap... no one gives a crap about NPM. No one. It's largely abandonware on the day it's created. I never really found that sentiment to be the case with CPAN. You had to make an effort to get a package out there. The care people put into packages like DBI was incredible, compared to anything I've seen on NPM.

I don't use Perl much these days. But the hate it gets on HN is insane. It's had a lot of what people consider "modern" features as far back as the 1990s. I really haven't seen a single thing Python, Ruby, or PHP have done that much better.

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

#384
post #239

Earlier quoted context omitted.

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.

PHP has object since v3 ('97).

Wasn't it then limited to stdClass ?

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

#385
post #185

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

That's not so much Perl hijacking a user space variable as Perl having some single character globals that have special behavior. Really, you usually learn about those early (sorting is common), and if you're using strict like you should be, if you define them and use them they will work as expected until you use a custom sort, in which case you'll track down the error.

In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.

> utterly confounding the first time one accidentally runs into it.

Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.

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

#386
post #338

Earlier quoted context omitted.

Python? That doesn't make sense. Anyone who appreciates Perl would surely choose Ruby over Python.

Ruby is just as dead. Only thing it had going for it was Rails.

Ruby is doing well as a configuration format. Look at Vagrant and Homewbrew, for example.

Also, there is Crystal, for compiling something very similar to Ruby, to native.

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

#387
The proposed defaults are a good idea, and I hope some or most of 5.32 long standing experimental features become core features (or just go away entirely).

But I'm afraid that the badly needed core C code refactoring and restructuring is being left out, and that will make it very hard to introduce new features into the language.

I also had this secret hope that Perl 7 would be a tidier, simplified Perl 5 with little or no relation to Perl 6. Less confusing syntax would go in sync with the refactoring of the core to create a smaller language that could perform better and be easier for beginners to learn.

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

#388

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.

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…

> There's a few third party libraries in CPAN but nothing as comprehensive

There's 194,000 modules, which is probably the most of any language:

https://www.cpan.org/

> Nothing against the language but I don't know why you wouldn't use literally anything else nowadays.

Gee, let me see:

- Perl's Mojolicious web framework is probably the most powerful today.

https://mojolicious.org/

- Perl has moderate static typing with use strict;

- Perl allows forward references, unlike Javascript or Python.

The question is why would I use anything but Perl?

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

#389
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…

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

Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.

Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.

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

#390

Earlier quoted context omitted.

Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.

Agreed. Regex is a “part of the language” not a bolt on library like you have in Python. It’s one of those cases where you don’t even know how crap regex is in another language if you’ve never used Perl.

I mentioned Boost's Regex in C++ (boost is essentially a different language), but I didn't bother to mention my experiments with regex in C, for example:

http://web.archive.org/web/20160308115653/http://peope.net/o...

I mean, you can do it, it just lacks elegance. And TBH, I still prefer C for lots of things.

Post reply on HN