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

41–50 of 245 posts

Re: What Happened to Perl 7?

#41

Post by codeflo »

HelloNurse wrote: post #25
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 effe…

If user = server administrator writing simple scripts, you are probably right. If user = a team of devs, I don’t agree. You often want to use new language features just to simplify a piece of code, and you don’t want confusing rules around when you can and can’t use them.

Re: What Happened to Perl 7?

#42

Post by ajsnigrutin »

jzer0cool wrote: post #32

Can anyone advocate here their thoughts to "must use" Perl for any scripts / projects?

Perl is great for working with text based data and stuff that is a pain to do in bash.

It is also great at stability (ie. code written 20+ years ago, still works on modern systems).

So for me, something that I'll write, put in some cron somewhere and forget, is all written in perl... at the same time, my colleagues are rewriting old python2 stuff, because modern distros come with python3 only. Some of them had to fix stuff even for 2.6->2.7 python versions.

Re: What Happened to Perl 7?

#43

Post by dale_glass »

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…

Unfortunately most of that doesn't really matter for any non-trivial project, because you'll almost unavoidably need a module for something. A lot of the time you'll find out that it's bit rotted 5 years ago, and the bug tracker has a 7 year old issue nobody seems to have read.

It's even worse for anything that interacts with libraries or APIs -- those change over time, and often nobody does the work to repair compatibility.

So I think at this point it's fair to say it's dead. Even if the core language is technically functional, the ecosystem is rotting.

Re: What Happened to Perl 7?

#44

Post by hollander »

jwr wrote: post #38
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?

Perl is very well suited for certain tasks (not large software systems, but programs that process data). It is also one of very few languages/ecosystems where you can expect your code to work after >10 years. This is why I sometimes use it, for example my fs consistency checker ( https://github.com/jwr/ccheck ) was written in Perl specifically because it's a long-term tool and I would like to be able to run it on any…

> because it's a long-term tool and I would like to be able to run it on any system in 15 years

What about Docker and Virtualenv? Both make it possible to keep running code until the end of times.

Re: What Happened to Perl 7?

#45

Post by petre »

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?

Maintainance can mean: reuse most of the business logic and port the software to another MVC framework, so it's easier to maintain and add new features, as opposed to keeping it running on life support.

Re: What Happened to Perl 7?

#46

Post by ainar-g »

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?

Perl seems to still be fairly popular with the OpenBSD folk, since a Perl installation comes with the base system. It seems to be pretty much the scripting language of choice when simple Shell scripts don't do the job or are too slow.

Re: What Happened to Perl 7?

#47

Post by goto11 »

This is the right decision. The primary reason anyone still writes Perl is because they already have a lot of existing code and dependencies in the language. Backwards compatibility is a critical feature for a language in that position.

I doubt anyone would write a greenfield project in Perl when numerous other platforms are available. Raku is there if you like the design philosophy of Perl but don't need to worry about backwards compatibility.

Re: What Happened to Perl 7?

#48

Post by petre »

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

> But it falls massively short when it comes to anything concurrent or async

Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop. If you need parallelism, yes, you'd better use Go or something else.

And the 10 years old bugs are to a large extent an exageration, because those modules are probably abandoned and you shouldn't use them anyway.

Re: What Happened to Perl 7?

#49

Post by tialaramex »

codeflo wrote: post #30
gwd wrote: post #19

Earlier quoted context omitted.

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

Rust 2015 edition is only restricted to the syntax from 2015, all the features of today are available unless they're gated off somehow by syntax. For example the "async" keyword didn't exist in Rust 2015, so, you won't be using that from 2015 edition even today. But even though in 2015 you certainly couldn't go around evaluating u32::checked_div() in a constant, it works just fine in Rust 2015 edition today, because it's not gated by syntax.

Post reply on HN