Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Happened to Perl 7?

blogs.perl.org

Post reply on HN
Print view View original

21–30 of 245 posts

Re: What Happened to Perl 7?

#21

Post by biorach »

7r7292DuMfMz1Rh wrote: post #4
lordofgibbons wrote: post #2

I'm curious to know if anyone out there building new systems in Perl or is it all just maintenance mode for Perl based systems?

Unfortunately, yes, people are still building new systems in Perl. In my experience, it's been because existing infrastructure that new systems need is already written in Perl. I'll note that if you use a strict subset of Perl, and write it well, with lots of unit tests, it's bearable to use. But it falls massively short when it comes to anything concurrent or async. And if you stray into the "clever" subset of Perl,…

> And if you stray into the "clever" subset of Perl, frankly it becomes hell

Yeah, this is the thing... it's very very easy to go down a one-way street to an endless hell of incomprehensible line-noise code and "clever" tricks that are incomprehensible and unmaintainable.

On the plus side, having dealt with the hell of "clever" perl early in my career (and, ahem, maybe having been guilty of writing some), it has beaten into me the absolute necessity of writing the simplest, clearest, not-clever code possible. In some other language.

Re: What Happened to Perl 7?

#22

Post by viraptor »

badsectoracula wrote: post #15
codeflo wrote: post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

For all the buzz about python3 fiasco, we're pretty much migrated now and py2 gets dropped from supported versions and system repositories. Perl devs would be in a better situation with a "fiasco" like that. Ruby went through its own big breaking changes at least 2 times before as well. So... if people have good reasons to stay, a big change won't drive them away.

Re: What Happened to Perl 7?

#23

Post by codeflo »

badsectoracula wrote: post #15
codeflo wrote: post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

Think about applications, not one-off scripts. It should be easy to always stay on the latest language version, with good tooling to migrate your code, and importantly, the ability to do it piece by piece. (Python 3 was all-or-nothing for the entire ecosystem.) Also, many migrations are trivial in practice, like renaming an identifier to avoid the new keyword.

What this gives you is high confidence that when inserting a few lines somewhere, that fancy new for loop simply works. No need to scroll to the top if the file and remember which exact release of the 27 in the last year introduced the feature.

Re: What Happened to Perl 7?

#24

Post by badsectoracula »

codeflo wrote: post #23
badsectoracula wrote: post #15

Earlier quoted context omitted.

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

Think about applications, not one-off scripts. It should be easy to always stay on the latest language version, with good tooling to migrate your code, and importantly, the ability to do it piece by piece. (Python 3 was all-or-nothing for the entire ecosystem .) Also, many migrations are trivial in practice, like renaming an identifier to avoid the new keyword. What this gives you is high confidence that when inserti…

Yes i know, in fact i thought about it when writing that line but i thought it'd be obvious that the issue still remains, especially if said files are too big. It might be easier but you are not really solving the problem as well as opting in to the new functionality when and if needed.

Re: What Happened to Perl 7?

#25

Post by HelloNurse »

codeflo wrote: post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

Users do not "want to keep getting new features"; they occasionally decide to make an effort to upgrade the Perl interpreters on their servers and personal machines because they want some new features.

A "use v5.36" directive is going to be very opaque for many users, but it doesn't need to be understood to serve the purpose of determining the minimum Perl version to install in order to run a certain script very effectively.

Re: What Happened to Perl 7?

#26

Post by natmaka »

kamaal wrote: post #20

Ah Perl! The old friend, you can always rely on to do quick scripting work. I've written non-trivial quantities of Perl in the past, and maintained other people's Perl code too. Contrary to popular opinion, I've always found it easy to maintain. I still call upon Perl to do open(FILEHANDLE, $file) or die; while( ){ .... } close(FILEHANDLE) Sort of work. These days I do good deal of work in Python. Python itself has b…

Indeed, and being able to invoke 'perl -ane ...' is sometimes a bliss.

Re: What Happened to Perl 7?

#27

Post by badsectoracula »

viraptor wrote: post #22
badsectoracula wrote: post #15

Earlier quoted context omitted.

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

For all the buzz about python3 fiasco, we're pretty much migrated now and py2 gets dropped from supported versions and system repositories. Perl devs would be in a better situation with a "fiasco" like that. Ruby went through its own big breaking changes at least 2 times before as well. So... if people have good reasons to stay, a big change won't drive them away.

> For all the buzz about python3 fiasco, we're pretty much migrated now and py2

Python 3.0 was released in 2008, the fact that 14 years later 2.7 is still widely available (and often the default python, e.g. in my openSUSE Tumbleweed system here) means that the "buzz" was more than warranted.

Also of course things would migrate, it isn't like there was any choice on that matter (and projects like Tauthon that tried to provide a choice had several "Pythonistas" attacking it).

Re: What Happened to Perl 7?

#28

Post by danrocks »

lordofgibbons wrote: post #2

I'm curious to know if anyone out there building new systems in Perl or is it all just maintenance mode for Perl based systems?

Amazon's language for storefront UI templates is Perl [1]. When I joined, I couldn't help but laugh that poor developers are dragged through the hell of 5 leetcode interviews to end up working on a UI framework that is 25 years old.

[1] http://www.masonhq.com/sites

Edit: I left in 2013 so I don't know if it's still the case.

Re: What Happened to Perl 7?

#29

Post by xupybd »

forgotmypw17 wrote: post #14
lordofgibbons wrote: post #2

I'm curious to know if anyone out there building new systems in Perl or is it all just maintenance mode for Perl based systems?

I chose to build in Perl because of its ubiquity and committment to backwards compatibility. I was extremely frustrated with existing projects having dependency issues and frequent breakage and wanted to avoid that at all costs. Perl's flexibility has allowed me to develop my own coding style, which is basically Java-like, and I rarely have trouble figuring out what something does, even months later. I think Perl is…

I found Perl suffered from dependency issues as well. Not the language but the modules you tend to want to use. Especially when they're underpinned by c libraries. I'd preference operating system libraries then fall back to Cpan. Over time it got harder to maintain older applications as the libraries dropped out of repositories. Have you found anything similar?

Re: What Happened to Perl 7?

#30

Post by codeflo »

gwd wrote: post #19
badsectoracula wrote: post #15

Earlier quoted context omitted.

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

> How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? AFAIUI you can mix Rust 2015, 2018, and 2021 crates; so a developer can update their own crate to 2021, while not having to completely re-write the dependencies which are still Rust 2015. With Python 2 -> 3, my understanding was that everything had to be updated recursively. That said..…

Your last two paragraphs describe Rust’s process differently than I would in comparison to this suggestion.

First, significant new language features are introduced all the time, even in stable, all of them enabled by default (indeed, there’s no way to turn them off).

Nightly’s #![feature(…)] is strictly for experimental stuff that is buggy and/or will change until stable release. I’m sure you know this, but all of those are intended to be backwards compatible! I think that’s a big difference.

Incompatible changes in Rust never happen with “features” (as you know, stable doesn’t even have those), but only with “editions”. The goal of an edition is to carve out a large chunk of future design space, like introducing some keywords for planned features, or rarely, fixing really annoying inconsistencies that require a breaking change. They feel a lot more proactive (we want to do this, we need an edition) than retroactive.

Post reply on HN