Live data from Hacker News

What Happened to Perl 7?

blogs.perl.org

211–220 of 245 posts

Re: What Happened to Perl 7?

#211
post #199
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…

> opting in to an experimental feature could be a one-liner This exists since 2013. https://metacpan.org/pod/experimental > Probably not much of a problem currently, but might be if releases get more frequent. Very unlikely. Perl switched to a yearly release in 2010, it has been in use since and there is no indication for this to change. https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22... > focus on tooli…

> This exists since 2013.

Good to know, but maybe it’s not my fault that I assumed an official post by the Perl Steering Committee on perl.org would show the best solution.

> Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions.

That’s great, but you might notice that you’ve given me, who is new to these approaches in Perl, exactly no information on where to start.

> It is evident.

Yes, I was very transparent about the extent and recency of my experience. Luckily, that combative attitude to a mostly interested/positive comment isn’t representative of the Perl community as a whole, or there really wouldn’t be any users left.

Re: What Happened to Perl 7?

#212

Earlier quoted context omitted.

Perl is excellent for data analysis in a terminal. It is built to work with pipes, it's fast, concise, stable, and easy to extend. The REGEX integration is superb. It seems to me that we have a couple of generations of programmers who turn up their nose at anything that isn't Python notation and then repeat vague arguments about Python's superiority. But like all dogmatic systems, there is no agreement among the zeal…

Python wins out the popularity contest because of ease of readability that I think we can take for granted. Perl is true wizardry, I mean 'sigils' and stuff you need to know in order to make it work... Plenty harder to get at first glance for sure but it's truly occult in a lot of ways. I think that's kind of cool. The way I see it is that you can do interesting things in pretty much every computer language written o…

Ruby is a more natural transition from Perl, especially if your usage of Perl is Moose-based.

Re: What Happened to Perl 7?

#213
post #65

I'll speak up for Perl. I learntbit voluntarily in my own spare time and actually get a lot of delight out of the language. I like that it is very unrestrictive. The sigils make sense when you wrap your mind around them and you miss them in other languages. It is excellent at parsing text. I wrote a static site builder using Perl along with a very rudimentary templating system ( https://soft.thran.uk for the curious)…

I wouldn't worry much... the reports of Perl's death have been greatly exaggerated! The blog post seems to indicate that the steering council simply wants to to avoid being bitten by Zawinski's "CADT" model. And who could blame them after seeing the kind of stunts pulled in other language communities?

Perl has died a thousand deaths, yet lives to die a thousand more.

Re: What Happened to Perl 7?

#214
I never understood this argument. If you have code that only runs on perl 5 then install perl 5. If breaking changes objectively make a language better then break it! Nobody is forcing you to migrate to perl 7 and you can always just maintain binaries for perl 5 for legacy use.

The amount of time spent on this seems absurd and could have been spent getting a perl 7 release candidate ready. It's sad to see OSS eat itself alive so often over a desire to keep something that people just assume is desired.

Re: What Happened to Perl 7?

#215
post #199

Earlier quoted context omitted.

> opting in to an experimental feature could be a one-liner This exists since 2013. https://metacpan.org/pod/experimental > Probably not much of a problem currently, but might be if releases get more frequent. Very unlikely. Perl switched to a yearly release in 2010, it has been in use since and there is no indication for this to change. https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22... > focus on tooli…

> This exists since 2013. Good to know, but maybe it’s not my fault that I assumed an official post by the Perl Steering Committee on perl.org would show the best solution. > Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions. That’s great, but you might notice that you’ve given me, who is new to these approaches in Perl, exactly no information on where to start. > It is evident. Yes, I was…

> I assumed an official post by the Perl Steering Committee on perl.org would show the best solution

Different people have different opinions on what constitutes "best". The post author is conservative and values compatibility over conciseness.

> no information on where to start

If one doesn't know the difference, then likely local::lib is appropriate. It's already built into the installation tools: https://metacpan.org/pod/cpan#-I https://metacpan.org/pod/cpanm#-l,-local-lib

> combative attitude

The assumption of me wanting to fight comes as a surprise, but you got hold of the wrong end of the stick.

Re: What Happened to Perl 7?

#216
post #30

Earlier quoted context omitted.

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 th…

Yeah, the crucial trick is that Rust is a single language but the Editions system lets people keep older syntax in source code, knowing it will be transformed into the single abstract syntax of that language. Rust editions are not versions of the language, they're just syntax. New features of the language in a new library or compiler version work fine in all editions unless they require syntax which isn't in your cho…

> the Editions system lets people keep older syntax in source code

Perl 'features' are lexically scoped, and could be applied in a finer-grained style, if you like. Shutting something off locally is done pretty commonly (e.g. to silence an ignorable warning).

The Perl devs have a deprecation cycle to remove mis-features, even if that breaks backwards compatibility. They don't, as far as I know, make much effort to line that up with major version changes[1], it's more a matter of making sure there's a long period of warning.

[1] The difficulty of course, was that for a long time the language now known as Raku was squatting on the next major version, "6", hence the need to jump to "7" to avoid confusion with Raku.

Re: What Happened to Perl 7?

#217

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.

> Perl devs would be in a better situation with a "fiasco" like that.

Well, the hang-up in the roll out of "Perl 6" (now, Raku) gave people ammunition to shout about how "Perl is dead", but the central trouble was a lot of people wanted to spread that word. Myself, I think the success of a weirdo outsider language was making some insiders very upset, and they were fighting back any way they could.

Supporting older, variant behavior isn't really causing problems for the devs, from what I hear, when it does they go after it with the deprecation cycle.

Re: What Happened to Perl 7?

#218

Earlier quoted context omitted.

> I never liked Python much, until I got forced to use it on a new team. Now I'm convinced that it has a really distinct advantage -- there aren't too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. This is why I picked up Python many years ago. I had been using Perl 5 for my scripting and system administration needs. While it worked just fine any project larger than…

"It's elegant when writing but frustrating when reading" As a person who used to use Perl 5 rather extensively back in the day for all sorts of things, I fondly remember the joke that Perl is a "write-only language" :)

I'd joke about Perl 5 being write-only until I had to go read my own code from only months prior. I would get so mad at myself for making it so hard to follow but then for expediency I'd go and do the same damn thing in the current batch of code. Then months later curse myself. I've opened Perl files that I swear had bitrot but nope, not corruption, just a bunch of sigils and weird operators.

Re: What Happened to Perl 7?

#219
post #23

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…

> It should be easy to always stay on the latest language version

With perl you can upgrade your language version whenever you like, and do it reasonably safely, because there's a lot of emphasis on backwards compatibility.

Perl may actually have a "always gimme the latest features" option, but I don't know what it is, because things like that aren't really that popular in the perl world-- we want old code to keep working the way it always has.

Re: What Happened to Perl 7?

#220

Earlier quoted context omitted.

Long ago (~year 2000), Perl 6 was announced with great fanfare. Larry Wall set out to start producing a bunch of specs ("Apocalypses", "Synopses" and "Exegeses"), while a bunch of people set out coding. Then two things went wrong. First, the Perl 6 development had bad project management. According to the reports, the culture attracted experimentalists with interesting ideas, but didn't get along with boring people wh…

Meanwhile, Perl 5 development continued in the background, and they decided that it'd jump version from 5 to 7 to avoid confusion. Perl 7 is the direct descendant of Perl 5, with the same syntax, new features and very few deprecated things. Did you read the FA? They decided that, "Yeah nevermind: we're not going to call it Perl 7 ", until some future time where it may make sense to do so to somebody again - but maybe…

I think quite a few people are confused by the line about it becoming Perl 7 "sometime in the future". I think it is unlikely that that is the distant future, myself. I think the main hang-up is they'd like to get the new built-in object system (Corinna) working.

If you're a "move fast and break things" kind-of guy, watching the perl devs in action will annoy you, because they're committed to not breaking things, and if they have to move slow to avoid it, they will.

On the other hand, if you want to be sloppy with your own perl code, or work with CPAN modules that move faster, that's up to you.

Post reply on HN