If you're interested in the story behind why some languages and specs (PHP 6 and IPv5 and a few others) appear have skipped a major version number I wrote a little bit about them: https://blog.mclemon.org/missing-version-numbers
What Happened to Perl 7?
51–60 of 245 posts
Re: What Happened to Perl 7?
#52Earlier quoted context omitted.
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.
I've also used Perl for small utility programs (basically as a "enhanced" shell script). The problem with Docker or virtualenvs is that they greatly increase the installation complexity of your script.
For example, two years ago I wrote a small (50 LOC) Perl script to convert between two text format. On Unix you could install it by just putting the one file in /usr/bin. It would run in less than 1 ms, which was critical because it was repeatedly invoked by another (legacy) program. It was mostly a bunch of regex so it was natural to write it in Perl (or awk maybe but I don't know awk).
The python equivalent would have been at least 30x slower, significantly longer, less portable etc. Using docker just for this script would have been overkill. The only real alternative IMO would have been to make a statically compiled Go or Rust binary.
Re: What Happened to Perl 7?
#53[deleted]
Re: What Happened to Perl 7?
#54I'm curious to know if anyone out there building new systems in Perl or is it all just maintenance mode for Perl based systems?
Speaking as a London-based freelancer specialising in Perl, I can tell you that the number of companies developing new systems in Perl is tiny (like, maybe, half a dozen). Until four or five years ago, there was still plenty of maintenance work to be had, but even that has pretty much dried up now.
I think Ruby is heading in the same direction.
Re: What Happened to Perl 7?
#55Earlier quoted context omitted.
Speaking as a London-based freelancer specialising in Perl, I can tell you that the number of companies developing new systems in Perl is tiny (like, maybe, half a dozen). Until four or five years ago, there was still plenty of maintenance work to be had, but even that has pretty much dried up now.
I think Ruby is heading in the same direction.
Yes, the trend of usage metrics don't look promising. It's basically only used for Rails and the heyday was 2010-2016. People are much more likely to reach for Django/Python or Javascript backends, especially with the ubiquity of React. Ruby jobs are going to generally be maintenance of older projects.
Re: What Happened to Perl 7?
#56Ah 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…
Examples? I don't recognise anything Perlish in Python. Ruby, yes, but not Python.
Re: What Happened to Perl 7?
#57Earlier quoted context omitted.
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?
You're right, and this is why I don't use third-party modules. If I need something I can't write myself, I use the shell version instead of a module.
Seems like you're jumping through a like of hoops to write thing in a Java-like fashion when you could be using Java, which has a much healthier ecosystem.
Re: What Happened to Perl 7?
#58I’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…
> EDIT (i put it here since i already got three replies on the same thing): i understand that you can mix two different files with different "editions" but it still makes it hard to update these files themselves.
It does not, though? You have to update the entire file (really crate) at once, but that’s really not much of a challenge as it’s near exclusively syntactic, and syntactic changes are easy to make, just fix compiler errors.
I feel like you didn’t go through the Python migration yourself and just go off of the echoes you got from it, but the issues in the Python migration were not “updating code is hard”. It was really the easiest part, and could mostly be done mechanically (which incidentally `cargo fix` provides for when migrating between editions).
The challenges of the Python migration was:
- You had to wait for all your dependencies to be updated before you could migrate yourself, commonly this was mixed with API updates while at it especially at the start, this is not an issue in Rust because there is no dependency between crate editions, I can use edition 2018 and depend simultanously on edition 2015 and edition 2021 crates.
- Many changes were semantic in nature, there was no way to check them statically, instead they were runtime changes (in types or behaviour), which made ensuring they were correct a lot more challenging; editions do not cover or allow for this.
The Python migration wilfully included fixes to long-standing semantics issues of the language (though whether all were improvements, or whether they went far enough remains a matter of debate), and this as well as the incompatibility are what made it an issue.
If it had been entirely syntactic and a per-package or per-file thing it would have been much less of an issue (not an entirely non-issue as things like library contents are a runtime concern in python, but still…). And that’s what rust editions are.
Re: What Happened to Perl 7?
#59I'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've also found it very convenient for any sort of data shunting I find myself doing, it can easily manipulate and convert XLS, Json, other formats I encounter in my work.
I hope it doesn't go away. There's a mindset to Perl that clicks with me and just isn't present in many other languages.
Re: What Happened to Perl 7?
#60Earlier quoted context omitted.
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.
I do use Docker for freezing dumpster fires like CSS toolkits that need to be built using node. And that works well to a certain extent, but there is still the complexity of Docker, having to set it up when you want to use the tool, having to deal with changes happening in it over the years, setting up filesystem sharing, etc.
Whereas with Perl it's easy: any UNIX system (and I do mean UNIX in a wide sense, as I've run perl on systems like HP-UX, Solaris, Unicos, IRIX and others) will normally have perl5 installed and you'll be able to just run your software. If it doesn't have perl5, installing it is usually very easy and you don't have to deal with horrors like the python2->python3 transition.