45 ms·

What Happened to Perl 7?

249 points by davorg 4y ago

uhtred 4y ago
Cue all the "Perl was my first real programming language but I moved to Python years ago" comments. I wish there were more comments about interesting stuff people are doing NOW in Perl. I'm actually new to Perl and I really enjoy it. Python seems so boring.
lordofgibbons 4y ago
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?
- 7r7292DuMfMz1Rh 4y ago
  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, frankly it becomes hell. The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years.
  - davorg 4y ago
    > The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years. Yes. Very much this. Anecdotally, I'd estimate that, outside of the big, well-known modules, about 25% of the CPAN modules I try to use have bugs that render them unusable and unresponsive maintainers. Here's a description of an example I found last year - https://dev.to/davorg/failing-to-get-product-information-from-amazon-with-perl-5a3g https://dev.to/davorg/failing-to-get-product-information-fro... (my project to write a replacement module has stalled).
  - biorach 4y ago
    > 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.
  - petre 4y ago
    > 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.
    - 7r7292DuMfMz1Rh 4y ago
      > Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop My experience with all of these has been that they've been frustrating to work with, and general support for them in the broader ecosystem is lacking and mutually incompatible. > those modules are probably abandoned and you shouldn't use them anyway. Yes, that's the point, the ecosystem is now lacking because of the number of abandoned modules (even for quite common stuff).
      - petre 4y ago
        Mojo::IOLoop is quite lean and straightforward to work with, but it's quite minimal. If I'd pick something, I'd probably pick this one as the decision to use Mojolicious was very rewarding. AnyEvent is harder because it uses closures everywhere but it works really nicely otherwise. It's not endorsed by some in the Perl community because the author insists that it doesn't need a license and chooses to develop it and track bugs on his own infrastructure. EV is developed by the same author and it requires a compiler, it can be plugged into AnyEvent. They're both very good quality. IO::Async is a different event loop brought to you by the people that do not endorse AnyEvent but are involved with Perl 5 development. I haven't used it, but it has a large number of active bugs on RT, plus past criticism from the author of AnyEvent. There's also POE which we use but it's possibly on life support and you probably wouldn't want to use it unless you want to live in callback hell, so I fully understand your frustration if you've actually tried it. We use POE in a critical part of our infrastructure and has worked fine, but that part is quite frustrating to maintain. Futher criticism of this event framework could be found here: https://metacpan.org/pod/AnyEvent::Impl::POE https://metacpan.org/pod/AnyEvent::Impl::POE As a sidenote, I'm curreny working with Ruby's Async:IO which is a breath of fresh air compared to other event loops that I've worked with in the past.
  - doomvox 4y ago
    > it falls massively short when it comes to anything concurrent or async Perl has some decent CPAN modules for handling multi-process applications-- it is true that it's very weak for threaded applications. (Raku on the other hand has some extremly convenient CAP features in general.)
- asicsp 4y ago
  See this discussion from 2 years back: https://news.ycombinator.com/item?id=25021660 https://news.ycombinator.com/item?id=25021660
- davorg 4y ago
  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.
  - gjvc 4y ago
    what are you going to do then?
    - davorg 4y ago
      I'm semi-retired. I have a part-time contract maintaining a system I worked on a few years ago and I pick up other bits of freelance work from time to time. And I've been prototyping a few project ideas (in Perl) to see if any of them could be a sustainable source of passive income. Of course, if any of them grow to the extent that they need a development team, I'll need to rewrite them in a more sustainable language.
    - 323 4y ago
      Maybe he'll wait for the Y2038 crisis :p
      - davorg 4y ago
        Hey, it worked for the COBOL crowd 25 years ago :-)
  - cutler 4y ago
    I think Ruby is heading in the same direction.
    - reducesuffering 4y ago
      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.
- forgotmypw17 4y ago
  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 vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project. One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.
  - xupybd 4y ago
    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?
    - forgotmypw17 4y ago
      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.
      - scoopertrooper 4y ago
        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.
        forgotmypw17 4y ago
        Java has many other shortcomings which keep me from using it.
- danrocks 4y ago
  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 http://www.masonhq.com/sites Edit: I left in 2013 so I don't know if it's still the case.
  - alfiedotwtf 4y ago
    To be fair, HTML::Mason was probably the most powerful templating toolkit at the time (Text::Template was there too, but from memory Mason was almost everyone's goto).
- samwillis 4y ago
  Not new, but I'm currently working on a freelance project modernising the front end / UI of a bioinformatics platform that's written in Perl. Also I wouldn't say it's in maintenance mode, there are new features being developed for it all the time.
- jwr 4y ago
  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 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 system in 15 years. Compare this long-term approach with the fires in Python or (heaven forbid) Node ecosystems, where things break all the time.
  - hollander 4y ago
    > 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.
    - xmcqdpt2 4y ago
      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.
    - jwr 4y ago
      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.
- petre 4y ago
  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.
- ainar-g 4y ago
  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.
  - johnisgood 4y ago
    Yup, their package manager and related stuff is written in Perl.
- toast0 4y ago
  I've built a few (small) things in Perl recently: a) iCalendar and timezone pre-processing for an Arduino alarm clock; Arduino libraries aren't up to the task (and neither am I! recurring events with recurring exceptions is kind of complex), but cpan iCal libraries and timezone libraries seem to work. b) personally monitoring script, checks a bunch of stuff and sends email (well, cron sends the email, really) if problems persist for long enough c) something to fetch my DSL sync speed and status (uses Net::Telnet), which feeds into the monitor script, but also used to adjust bandwidth limits for fq_codel to reduce bufferbloat.
- nocman 4y ago
  Yes, and not just maintenance, new systems.
- mdaniel 4y ago
  I don't know if they adopted some existing codebase, but DuckDuckGo is the most famous one I know of: https://github.com/orgs/duckduckgo/repositories?q=&type=all&language=perl https://github.com/orgs/duckduckgo/repositories?q=&type=all&...
- ei8ths 4y ago
  yes, I am. Web apps and scripting.
RedShift1 4y ago
Interview with a Perl programmer: https://youtu.be/0jK0ytvjv-E https://youtu.be/0jK0ytvjv-E
- mariuz 4y ago
  Interview with Senior JS Developer in 2022 https://www.youtube.com/watch?v=Uo3cL4nrGOk https://www.youtube.com/watch?v=Uo3cL4nrGOk
- synu 4y ago
  “What happens in the 80s stays in the 80s, except for Perl.”
  - deleted 4y ago
    [deleted]
codeflo 4y ago
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 your valuable beta testers beyond that with a second line that’s entirely redundant with the first one. 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. I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then begin a new (hopefully long) era of backwards compatibility. That makes it easier for users to maintain their code, is probably easier to implement, and also easier for users to learn, since there are fewer sets of rules. Lastly, I hope they also focus on tooling around installation. One paradoxical problem with modernizing Perl is its historic success: every variant of Linux or Unix already comes with an ancient version of it. I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. Maybe that’s already the case for Perl, I wouldn’t know. All that said, I’m not following Perl that closely anymore. These are just some really quick observations about very complex topics. I don’t claim to know nearly as much as the people who made these decisions, and it’s great to see that things are happening.
- badsectoracula 4y ago
  > 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 better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility. How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? Making piecemeal (if needed) changes is much easier than having to update a ton of code and that is even more important when that code wasn't touched for a long time. 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.
tosh 4y ago
The feature pragmas look like an interesting way to preserve backwards compatibility & yet allowing for new language features.
- badsectoracula 4y ago
  Yeah, this is basically what Free Pascal does too. The default language mode is actually kinda obsolete (it is more of a Turbo Pascal 7+), but you can change dialects with the $mode directive (with most common being "objfpc", an extension to the default "fpc" mode that adds more advanced features and "delphi" which is used for Delphi compatibility to allow sharing code). In addition to that many new features are enabled with additional directives, like $modeswitch (e.g. "$modeswitch advancedrecords" enables using methods and management operators in records and "$modeswitch prefixedattributes" enables attaching custom attributes to classes, properties, etc to be accessed via the RTTI later) and $scopedenums (so that when you have an enum like TFoo = (Bar, Baz) it wont create Bar and Baz globals like in classic Pascal, but TFoo.Bar and TFoo.Baz - the fact that it isn't a modeswitch is most likely for Delphi compatibility as AFAIK Delphi doesn't have a modeswitch directive - or mode directive for that matter). It does require having a litany of switches at the top of each source code but it beats having old code break (though i do think that in some cases the FPC devs go a bit too overboard - e.g. attributes would be a syntax error anyway).
kamaal 4y ago
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(<FILEHANDLE>){ .... } close(FILEHANDLE) Sort of work. These days I do good deal of work in Python. Python itself has been heavily Perlified over the years, especially Python3. Its fame seems to have come moving away from Pythonic principles, to Perlic principles. They add lots of features, even syntactic features, libraries and even things like typing. Python isn't the small, minimal core of ecosystem anymore. Every single release of Python gives me the Perl feel from the old days. So I kind of don't miss Perl at all, after all we managed to turn Python into Perl. Long live Python, Long live Perl.
- natmaka 4y ago
  Indeed, and being able to invoke 'perl -ane ...' is sometimes a bliss.
  - doomvox 4y ago
    If you use -E rather than -e you get some new features turned on by default, notably you can use "say" instead of "print".
- cutler 4y ago
  Examples? I don't recognise anything Perlish in Python. Ruby, yes, but not Python.
  - dotandimet 4y ago
    Use the debugger: `python -mpdb` is a very similar experience to `perl -d`, so much so that it feels like a gift from an earlier perl-to-python emigrant. (I showed my co-workers `perl -d`, they later discovered and showed me `python -mpdb`)
  - tyingq 4y ago
    I don't really see it either, but maybe a few things like collections.defaultdict (like Perl's normal associative arrays) and sysconfig (very similar to "use Config;").
jzer0cool 4y ago
Can anyone advocate here their thoughts to "must use" Perl for any scripts / projects?
- ajsnigrutin 4y ago
  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.
- cafard 4y ago
  I don't know about "must use", but now and then I write a short script for some kind of text processing. I've also used it fairly recently for a script pulling data out of SQL Server, mostly because I already had the DBI::Sybase module installed.
- alfiedotwtf 4y ago
  My MO is to start off scripts in bash, but once I get to about 3 functions in or need to do some text processing (but no need to drop down to Rust), I rewrite the script in Perl and go from there. On the flip side, I would never get a Perl script and rewrite it in Bash. Perl <3
- nprateem 4y ago
  About the only thing now is `perl -pie` on the CLI to run some one-liners (especially when you don't want to fight sed).
- perlperson 4y ago
  I haven't seen frameworks in other languages rival mojolicious for rapid prototyping, web scraping, and good event-driven support. It's super easy to make websockets and even quickly have unit tests. Mojolicious still has 0 external dependencies and is rock solid and very scalable. The simplicity is just very nice compared to, for instance, frameworks in which lots of code generation is involved just to get started.
goto11 4y ago
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.
smcl 4y ago
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 https://blog.mclemon.org/missing-version-numbers
- cesarb 4y ago
  That page should have "24th December 2015" for the Perl 6 release date, because it was not skipped, it was actually released. See the Perl 6 release announcement at https://web.archive.org/web/20151225055622/https://perl6advent.wordpress.com/ https://web.archive.org/web/20151225055622/https://perl6adve... and Perl 6 download page at https://web.archive.org/web/20160208204149/http://perl6.org/downloads/ https://web.archive.org/web/20160208204149/http://perl6.org/... (for Perl 6 release 2016.01, there were other releases later). It only appears to have been skipped when looking from today's point of view, since many references to Perl 6 have been scrubbed from the web and replaced with its new name. But for those who were following the saga back then, starting with the announcement that the next major release of Perl would be Perl 6, followed by the many announcements of cool new features that next major release of Perl would have, culminating with its long-awaited Christmas release, it's hard to say that it never existed under that name.
  - jrochkind1 4y ago
    The OP "What happened to Perl 7" doesn't say anything about Perl 6! I'm still confused about what happened to Perl 6! "replaced with it's new name" -- googling, that's "raku". So... what was going to be Perl 6 is considered a different language, and not particularly compatible with Perl. But "Perl 7" is meant to be less of a departure? It is weird OP left Perl 6 out of the story of "what happened to Perl 7". I guess it's just too painful?
    - dale_glass 4y ago
      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 who wanted to do things like releases and steadily approaching functionality. So there were a number of projects, a number of which were abandoned. Things dragged on, and nobody was cracking the whip. It took 15 years for Perl 6 to finally announce its first official release. Perl 6 also turned out to be too different from Perl 5. Different syntax, and no XS, which meant every Perl module interfacing with a library wouldn't work even if some sort of automatic conversion, or compatibility mode was possible. XS is tied to Perl 5's internals, and Perl 6 was an effort to make a new language from scratch, without using the old interpreter. Meanwhile, people started abandoning Perl 5 reasoning that since Perl 6 was in development, 5 would eventually die, and the lack of compatibility would mean current efforts on 5 would be wasted. It took a very long time but finally it was decided that Perl 6 wasn't really Perl 6, but some other, Perl-like language, and renamed to "Raku" to signal this. But by then it was already too late, most everyone had already moved on, and by the time when Perl 6 was finally released it was an extremely niche thing very few people had any interest in. 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.
deleted 4y ago
[deleted]
HeckFeck 4y ago
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 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.
- ggeorgovassilis 4y ago
  > it is very unrestrictive That makes collaboration hard. The freedom I have in putting my thoughts into code, uninhibited by syntax, types and conventions makes it nearly impossible for others to understand and modify my work.
  - mikem170 4y ago
    The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess The perl coding team I was on made readability our #1 priority. We didn't use tricky or out of the ordinary syntax unless it was absolutely necessary (like unusual regex, etc), and in those cases we would document what was happening with comments and maybe a reference to the appropriate man page. We had a style guide, for a consistent look and feel. We paid attention to naming and commented blocks of code, so the reader would not need to run an interpreter in their head while skimming through the code. We'd seek feedback from each other. It worked out well. We had no problems reading our code. We used the flexibility and expressiveness of perl to make our code more readable. We had the freedom to tailor the code to what we were doing, instead of the other way around.
    - ggeorgovassilis 4y ago
      > The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess If one learned how to collaborate on projects which, I think, the perl language does not incentivise. (edit) > The perl coding team I was on made readability our #1 priority. I'd love to read more about that. Have you by chance documented your experience somewhere?
bachmeier 4y ago
None of this makes sense IMO. The point of Perl 7 was not to allow breaking changes. It was to send a signal that Perl was alive and that the Perl 6 messup was behind them. Then two years later they announce that there's still no Perl 7 because they're still working on Perl 5.
- rurban 4y ago
  They are not working on perl 5, neither a perl 7. The biggest excitement might be the design of their new object system. But if you look at it and compare it to the design of their OO designed in 2002 (for their perl 6) it's a serious throwback. not even talking about their inability of a proper implementation. in the meantime I've implemented that, plus types, plus proper signatures, plus unchecked arrays when safe, plus an integrated ffi plus tons more features. their is no development, only maintainance. plus lot of internal fights. plus a CoC, which was used to eliminate the only remaining developer, because he dared to critice the stakeholders which blocked progress, and still continue to make the codebase worse. the less the work, the more the fights.
- unixhero 4y ago
  For all his agreeableness, maybe Larry Wall left behind a chaos of unsolved semantics. Perhaps discussions they never really recovered from. I do not know the story, and this is speculative only.
  - nocman 4y ago
    From what I've gathered, Larry was simply focused on Perl 6 (which became "Raku" in Oct of 2019). It seems to me that he just wanted to let others handle the new development in Perl 5 rather than being directly involved all of the time. I don't think he has done much at all with Perl 5 for quite a long time.
jart 4y ago
It says Larry Wall isn't working on Perl anymore. When did that happen? It looks like the Perl6 thing was announced in 2000 and around 2010 Larry Wall deleted the Perl page from his blog (it's been a 404 link ever since) - https://web.archive.org/web/20100214124540/http://www.wall.org/~larry/perl.html https://web.archive.org/web/20100214124540/http://www.wall.o... - http://www.wall.org/~larry/perl.html http://www.wall.org/~larry/perl.html That butterfly was the worst. Perl would have been better served having an animal like the honeybadger as its logo.
- mdaniel 4y ago
  Since "backronyms" are a thing, I think they should adopt the camel as the logo, given that's what I see in my head when I think of perl: https://learning.oreilly.com/library/cover/0596000278/250w/ https://learning.oreilly.com/library/cover/0596000278/250w/
  - bmn__ 4y ago
    Not as simple as you think: http://neilb.org/2020/12/04/perl-and-camels.html http://neilb.org/2020/12/04/perl-and-camels.html
- doomvox 4y ago
  > That butterfly was the worst. Agree completely. Larry Wall is pretty brilliant, but he shouldn't be doing graphics design. Actually, I tend to dislike cutsey-poo cartoon icons, in general. If you want to pick an animal totem, there are plenty of public domain photos of actual animals courtesy of the NSF and such...
alkaloid 4y ago
I still love Perl as essentially a low-level abstraction layer for C. I can get so much done at the system level without having to compile a bunch of code every time I make a small change. I've heard that Python (and maybe some others) are slowly replacing Perl as a "subsystem" of Linux, but I doubt that will happen before I retire. So, until then, TIMTOWTDI!
mberning 4y ago
A benevolent dictator for life is clearly a very beneficial thing for open source projects.
- rabbits77 4y ago
  Yes! The committee approach does not seem to work well. The “benevolent dictator” is really often just a solid CEO type: sets the vision, acts as head salesperson, and has the final word on all important decisions. What happened with Perl is that, effectively, the “pumpking” held that power but when Sawyer X actually used his discretion to announce Perl 7 there was a mutiny by jealous and bitter collaborators. They felt they should have some say in the matter and formed this Perl Steering Committee. As the brilliant Reini Urban has pointed out elsewhere in the comments, this group are fairly mediocre talent wise and mostly just spend their time sniping at each other. Reini’s cperl or Will Braswell’s rperl are both worthy projects that in a more perfect universe would have long ago supplanted the now rudderless mainline perl interpreter.
  - doomvox 4y ago
    > Perl 7 there was a mutiny by jealous and bitter collaborators Look, I hate to harsh on Sawyer X-- he's done a bunch of good stuff for perl over the years, and I hope to see him around again-- but his Perl 7 push was just a mess. He was getting frustrated about things, and tried to plan and push through some big changes before anyone could complain, but he wasn't really that clear on what the big changes were supposed to be-- he left a couple of weeks to figure it out after that big announcement, and even the inner cabal he had talked to about this stuff first seemed more than a little surprised. One of the major things we got out of all this is it made it clear we needed some work on improved processes and transparency and such, and that's actually happened. There's a steering committee that makes a point of publishing its minutes, and an RFC process to talk over proposed changes. Some of these changes are in fact actually happening, and a number of them are discussed in this v5.36 annoucement (e.g. subroutine signatures are no longer experimental). This actually seems like a really bright crew in charge, and they're making very sane decisions. There's really no reason to think that there's some great benefit to breakage-on-upgrade: its a solution in search of a problem.
rootusrootus 4y ago
I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I've always enjoyed Perl as a language. But I walked out of that presentation thinking "That was so beautiful, and I don't want it anywhere near my business." Because the last thing I need is software written in a language I can't hire anyone else to maintain. At some level that's what I think has happened to Perl in general. 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. But Perl programs are frequently art pieces that take a lot of effort to truly grok.
- cestith 4y ago
  Perl6 is now of course Rakulang. https://raku.org/ https://raku.org/ The folks responsible for that are still growing and improving their own ecosystem. It's a Perl-family language but it's different enough that they stepped away from the name so both Perl and Raku can flourish.
- svachalek 4y ago
  This is one thing I'm certain of after 40 years of programming: successful programs will need to be read more often than they are written. Language features that make programs cool or fun or "easy" to write are generally counter-productive to readability. Even things like this that are meant to make a program "expressive" are in fact just gimmicks if they are unique to one program. Features that make a language expressive in a consistent way are very valuable though. Python is a good example of this, even people who don't know anything about Python can generally read a Python program.
- giantrobot 4y ago
  > 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 a few hundred lines needed a lot of discipline to keep maintainable. Perl encouraged too many line noise shortcuts, reading unfamiliar code was too often an exercise in looking up uncommon operators. It's elegant when writing but frustrating when reading. Python not only read a bit more like it executed but didn't lend itself to unreadable shortcuts. If your code is elegant to write it tends to be straightforward to read. When Perl 6 was still Perl 6 the DSL stuff sounded interesting until like you I realized it would just turn large projects into unreadable messes. It wouldn't help the small Perl scripts be more readable nor would it help the large projects be more maintainable.
haolez 4y ago
An anecdote of my career is that some programming languages attract different kinds of programmers. I've dealt with Delphi in the beginning of my career and while there was nothing wrong with the language, it seemed to attract a lot of bad programmers writing really poor code. And Perl was the opposite of this anecdote: the most brilliant engineers I've met in my career were Perl monks, as they would call themselves. I respect Perl for that :)
- deleted 4y ago
  [deleted]
dinom 4y ago
Lol, here we are again bickering about Perl v. Python. I guess nothing beats a good flame war... Emacs v. Vi anyone?
- doomvox 4y ago
  Since doomacs and spacemacs, the vi folks have discovered org-mode and stopped fighting.
jandrese 4y ago
This seems like a whole lot of bending over backwards to avoid breaking a handful of edge cases that could be cleaned up on their own without too much drama. I would kind of prefer the features be enabled by default if you use a high enough version and if a module breaks you just fix it or dial back the version number at the top of your script until it is fixed. But I'd also run all of the test suites on CPAN against every new feature that comes out and fixing or at least tagging anything that breaks. Maybe even list a "maximum tested version number" for each module and emit a warning if you exceed it.
- sigzero 4y ago
  The majority didn't want the breaking possibility so it won out. It was discussed at length.
nvr219 4y ago
Because 7 8 9!! Ha ha
cosmiccatnap 4y ago
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.
atweiden 4y ago
I’m disappointed in the way this Perl 6 v Perl 7 debate is developing. Perl 6 modernizes Perl with e.g. concurrent and reactive programming, built-in grammars and a reimagined regex syntax superior to legacy PCRE, named function arguments, and gradual typing. Perl 6 was designed to be the successor language to Perl 5. The only technical grounds for Perl 6 being metaphorically sidelined was because Perl 6 lacked the startup and runtime performance characteristics of Perl 5 — fixable problems. Proponents of Perl 5 often contend Perl could’ve escaped developer mindshare loss without Perl 6 in the picture. But to claim Python, Ruby on Rails, Clojure, Go, Rust and JS/TS never would’ve gained serious developer mindshare had _Perl 6_ not existed seems very myopic to me. All the brilliant new languages and web frameworks launching were bound to erode Perl’s early established dominance regardless. Things would be different now if Perl 6 was at least as performant as Perl 5. Perhaps then it would’ve become popular years ago amongst Perl users to switch all greenfield Perl code to Perl 6. Then “Perl” would’ve become synonymous with modern language features.
- dale_glass 4y ago
  I think more than anything it was an error in the messaging. Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying, since people assumed that Perl 5 would be soon dead, and Perl 6 had a new different syntax. And then it took 15 years to happen, during which Python and others ate its lunch. I think a more successful strategy would have been to make it clear very early on that Perl 6 would be some sort of long term experimental project, and that Perl 5 would be expected to be a thing for a long time still. If in 2015 Perl 5 still had a thriving ecosystem, and there was a demand of Perl-like but better, then Perl 6 could have been more successful. But in the current timeline it's a successor to an almost defunct language, and isn't such an attractive proposition.
  - atweiden 4y ago
    Have you used Raku before? The new and improved regex syntax [1] IMHO completely obsoletes legacy PCRE. Writing regexes in other languages feels like stepping into an ICE vehicle after driving a Tesla: so crufty and old and obvious legacy. Raku’s built-in grammars make parsers trivial to write. I effortlessly created two [2] — one for reordering fstab entries, and the other for converting human-readable LUKS offsets into cryptsetup sectors — on a lazy afternoon. Grammars in Raku make this second nature. Then you have Raku’s multi-dispatch. It is more capable than Erlang/Elixir pattern matching: # a list with at least one element, extracting the head and tail multi sub tail(*@list ($head, *@tail)) { @tail } multi sub tail(*@list) { @list } [3] ==> tail() ==> say(); # [] [3, 4] ==> tail() ==> say(); # [4] # pattern matching with arbitrary guards multi sub user($name where { is-valid-user($_) }) { $name.say } multi sub user($name) { "invalid name: $name".say } sub is-valid-user($name) { # notice the additive character class in this regex: “letters plus digits” # fail the match if $name is root try with $name ~~ /(<+:Letter +digit>+)/ { $0 ne 'root' or fail }; $!.not } user('name'); # name user('1234'); # 1234 user('root'); # invalid name: root class Coordinates { has $.latitude is required; has $.longitude is required; } class City { has Str:D $.name is required; has Str:D $.state is required; has Str:D $.country is required; has Coordinates:D $.coordinates is required; } my $latitude = -37.840935; my $longitude = 144.946457; my Coordinates $coordinates .= new(:$latitude, :$longitude); my Str:D $name = 'Melbourne'; my Str:D $state = 'Victoria'; my Str:D $country = 'Australia'; my City $melbourne .= new(:$name, :$state, :$country, :$coordinates); my City:D $sydney = do { my Coordinates:D $coordinates = do { my $latitude = -33.86514; my $longitude = 151.209900; Coordinates.new(:$latitude, :$longitude); }; my Str:D $name = 'Sydney'; my Str:D $state = 'New South Wales'; my Str:D $country = 'Australia'; City.new(:$name, :$state, :$country, :$coordinates); }; # deeply nested argument deconstruction multi sub melbourne-or-bust( City:D $city ( Str:D :$name where 'Melbourne', Str:D :$state, Str:D :$country, :$coordinates ( :$latitude, :$longitude ) ) ) { my $gist = qq:to/EOF/.trim; Welcome to the city of $name. It’s located in $state, $country. GPS coordinates: $latitude, $longitude EOF $gist.say; } multi sub melbourne-or-bust(City:D $city) { 'This isn’t Melbourne.'.say; } melbourne-or-bust($melbourne); # Welcome to the city of Melbourne ... melbourne-or-bust($sydney); # This isn’t Melbourne > Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying, Perl 6 took a long time to make, but how much did that matter? What was Perl going to do about Rails, Clojure, Go, Rust, JS/TS, and more? The world of programming languages used to be a lot smaller than it is today. > Perl 6 had a new different syntax. Inline::Perl5 [3] allows running legacy Perl 5 code in Perl 6 codebases. [1]: https://docs.raku.org/language/5to6-nutshell#Regular_expressions_(_regex_/_regexp_) https://docs.raku.org/language/5to6-nutshell#Regular_express... [2]: https://github.com/atweiden/voidvault https://github.com/atweiden/voidvault [3]: https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5
iostream24 4y ago
I heard seven ate nine

249 points by davorg 4y ago

Cue all the "Perl was my first real programming language but I moved to Python years ago" comments. I wish there were more comments about interesting stuff people are doing NOW in Perl. I'm actually new to Perl and I really enjoy it. Python seems so boring.

lordofgibbons 4y ago

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?

7r7292DuMfMz1Rh 4y ago
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, frankly it becomes hell. The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years.
- davorg 4y ago
  > The ecosystem is also pretty much dead, it's not unusual to find bugs in packages where the issue tracker hasn't been responded to in 10 years, and the issue for the bug you're interested in has been languishing for literally years. Yes. Very much this. Anecdotally, I'd estimate that, outside of the big, well-known modules, about 25% of the CPAN modules I try to use have bugs that render them unusable and unresponsive maintainers. Here's a description of an example I found last year - https://dev.to/davorg/failing-to-get-product-information-from-amazon-with-perl-5a3g https://dev.to/davorg/failing-to-get-product-information-fro... (my project to write a replacement module has stalled).
- biorach 4y ago
  > 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.
- petre 4y ago
  > 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.
  - 7r7292DuMfMz1Rh 4y ago
    > Nonsense, there's AnyEvent, EV, IO::Async, Mojo::IOLoop My experience with all of these has been that they've been frustrating to work with, and general support for them in the broader ecosystem is lacking and mutually incompatible. > those modules are probably abandoned and you shouldn't use them anyway. Yes, that's the point, the ecosystem is now lacking because of the number of abandoned modules (even for quite common stuff).
    - petre 4y ago
      Mojo::IOLoop is quite lean and straightforward to work with, but it's quite minimal. If I'd pick something, I'd probably pick this one as the decision to use Mojolicious was very rewarding. AnyEvent is harder because it uses closures everywhere but it works really nicely otherwise. It's not endorsed by some in the Perl community because the author insists that it doesn't need a license and chooses to develop it and track bugs on his own infrastructure. EV is developed by the same author and it requires a compiler, it can be plugged into AnyEvent. They're both very good quality. IO::Async is a different event loop brought to you by the people that do not endorse AnyEvent but are involved with Perl 5 development. I haven't used it, but it has a large number of active bugs on RT, plus past criticism from the author of AnyEvent. There's also POE which we use but it's possibly on life support and you probably wouldn't want to use it unless you want to live in callback hell, so I fully understand your frustration if you've actually tried it. We use POE in a critical part of our infrastructure and has worked fine, but that part is quite frustrating to maintain. Futher criticism of this event framework could be found here: https://metacpan.org/pod/AnyEvent::Impl::POE https://metacpan.org/pod/AnyEvent::Impl::POE As a sidenote, I'm curreny working with Ruby's Async:IO which is a breath of fresh air compared to other event loops that I've worked with in the past.
- doomvox 4y ago
  > it falls massively short when it comes to anything concurrent or async Perl has some decent CPAN modules for handling multi-process applications-- it is true that it's very weak for threaded applications. (Raku on the other hand has some extremly convenient CAP features in general.)
asicsp 4y ago
See this discussion from 2 years back: https://news.ycombinator.com/item?id=25021660 https://news.ycombinator.com/item?id=25021660
davorg 4y ago
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.
- gjvc 4y ago
  what are you going to do then?
  - davorg 4y ago
    I'm semi-retired. I have a part-time contract maintaining a system I worked on a few years ago and I pick up other bits of freelance work from time to time. And I've been prototyping a few project ideas (in Perl) to see if any of them could be a sustainable source of passive income. Of course, if any of them grow to the extent that they need a development team, I'll need to rewrite them in a more sustainable language.
  - 323 4y ago
    Maybe he'll wait for the Y2038 crisis :p
    - davorg 4y ago
      Hey, it worked for the COBOL crowd 25 years ago :-)
- cutler 4y ago
  I think Ruby is heading in the same direction.
  - reducesuffering 4y ago
    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.
forgotmypw17 4y ago
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 vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project. One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.
- xupybd 4y ago
  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?
  - forgotmypw17 4y ago
    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.
    - scoopertrooper 4y ago
      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.
      - forgotmypw17 4y ago
        Java has many other shortcomings which keep me from using it.
danrocks 4y ago
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 http://www.masonhq.com/sites Edit: I left in 2013 so I don't know if it's still the case.
- alfiedotwtf 4y ago
  To be fair, HTML::Mason was probably the most powerful templating toolkit at the time (Text::Template was there too, but from memory Mason was almost everyone's goto).
samwillis 4y ago
Not new, but I'm currently working on a freelance project modernising the front end / UI of a bioinformatics platform that's written in Perl. Also I wouldn't say it's in maintenance mode, there are new features being developed for it all the time.
jwr 4y ago
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 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 system in 15 years. Compare this long-term approach with the fires in Python or (heaven forbid) Node ecosystems, where things break all the time.
- hollander 4y ago
  > 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.
  - xmcqdpt2 4y ago
    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.
  - jwr 4y ago
    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.
petre 4y ago
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.
ainar-g 4y ago
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.
- johnisgood 4y ago
  Yup, their package manager and related stuff is written in Perl.
toast0 4y ago
I've built a few (small) things in Perl recently: a) iCalendar and timezone pre-processing for an Arduino alarm clock; Arduino libraries aren't up to the task (and neither am I! recurring events with recurring exceptions is kind of complex), but cpan iCal libraries and timezone libraries seem to work. b) personally monitoring script, checks a bunch of stuff and sends email (well, cron sends the email, really) if problems persist for long enough c) something to fetch my DSL sync speed and status (uses Net::Telnet), which feeds into the monitor script, but also used to adjust bandwidth limits for fq_codel to reduce bufferbloat.
nocman 4y ago
Yes, and not just maintenance, new systems.
mdaniel 4y ago
I don't know if they adopted some existing codebase, but DuckDuckGo is the most famous one I know of: https://github.com/orgs/duckduckgo/repositories?q=&type=all&language=perl https://github.com/orgs/duckduckgo/repositories?q=&type=all&...
ei8ths 4y ago
yes, I am. Web apps and scripting.

RedShift1 4y ago

Interview with a Perl programmer: https://youtu.be/0jK0ytvjv-E https://youtu.be/0jK0ytvjv-E

mariuz 4y ago
Interview with Senior JS Developer in 2022 https://www.youtube.com/watch?v=Uo3cL4nrGOk https://www.youtube.com/watch?v=Uo3cL4nrGOk
synu 4y ago
“What happens in the 80s stays in the 80s, except for Perl.”
- deleted 4y ago
  [deleted]

codeflo 4y ago

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 your valuable beta testers beyond that with a second line that’s entirely redundant with the first one. 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. I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then begin a new (hopefully long) era of backwards compatibility. That makes it easier for users to maintain their code, is probably easier to implement, and also easier for users to learn, since there are fewer sets of rules. Lastly, I hope they also focus on tooling around installation. One paradoxical problem with modernizing Perl is its historic success: every variant of Linux or Unix already comes with an ancient version of it. I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. Maybe that’s already the case for Perl, I wouldn’t know. All that said, I’m not following Perl that closely anymore. These are just some really quick observations about very complex topics. I don’t claim to know nearly as much as the people who made these decisions, and it’s great to see that things are happening.

badsectoracula 4y ago
> 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 better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility. How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? Making piecemeal (if needed) changes is much easier than having to update a ton of code and that is even more important when that code wasn't touched for a long time. 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.

tosh 4y ago

The feature pragmas look like an interesting way to preserve backwards compatibility & yet allowing for new language features.

badsectoracula 4y ago
Yeah, this is basically what Free Pascal does too. The default language mode is actually kinda obsolete (it is more of a Turbo Pascal 7+), but you can change dialects with the $mode directive (with most common being "objfpc", an extension to the default "fpc" mode that adds more advanced features and "delphi" which is used for Delphi compatibility to allow sharing code). In addition to that many new features are enabled with additional directives, like $modeswitch (e.g. "$modeswitch advancedrecords" enables using methods and management operators in records and "$modeswitch prefixedattributes" enables attaching custom attributes to classes, properties, etc to be accessed via the RTTI later) and $scopedenums (so that when you have an enum like TFoo = (Bar, Baz) it wont create Bar and Baz globals like in classic Pascal, but TFoo.Bar and TFoo.Baz - the fact that it isn't a modeswitch is most likely for Delphi compatibility as AFAIK Delphi doesn't have a modeswitch directive - or mode directive for that matter). It does require having a litany of switches at the top of each source code but it beats having old code break (though i do think that in some cases the FPC devs go a bit too overboard - e.g. attributes would be a syntax error anyway).

kamaal 4y ago

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(<FILEHANDLE>){ .... } close(FILEHANDLE) Sort of work. These days I do good deal of work in Python. Python itself has been heavily Perlified over the years, especially Python3. Its fame seems to have come moving away from Pythonic principles, to Perlic principles. They add lots of features, even syntactic features, libraries and even things like typing. Python isn't the small, minimal core of ecosystem anymore. Every single release of Python gives me the Perl feel from the old days. So I kind of don't miss Perl at all, after all we managed to turn Python into Perl. Long live Python, Long live Perl.

natmaka 4y ago
Indeed, and being able to invoke 'perl -ane ...' is sometimes a bliss.
- doomvox 4y ago
  If you use -E rather than -e you get some new features turned on by default, notably you can use "say" instead of "print".
cutler 4y ago
Examples? I don't recognise anything Perlish in Python. Ruby, yes, but not Python.
- dotandimet 4y ago
  Use the debugger: `python -mpdb` is a very similar experience to `perl -d`, so much so that it feels like a gift from an earlier perl-to-python emigrant. (I showed my co-workers `perl -d`, they later discovered and showed me `python -mpdb`)
- tyingq 4y ago
  I don't really see it either, but maybe a few things like collections.defaultdict (like Perl's normal associative arrays) and sysconfig (very similar to "use Config;").

jzer0cool 4y ago

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

ajsnigrutin 4y ago
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.
cafard 4y ago
I don't know about "must use", but now and then I write a short script for some kind of text processing. I've also used it fairly recently for a script pulling data out of SQL Server, mostly because I already had the DBI::Sybase module installed.
alfiedotwtf 4y ago
My MO is to start off scripts in bash, but once I get to about 3 functions in or need to do some text processing (but no need to drop down to Rust), I rewrite the script in Perl and go from there. On the flip side, I would never get a Perl script and rewrite it in Bash. Perl <3
nprateem 4y ago
About the only thing now is `perl -pie` on the CLI to run some one-liners (especially when you don't want to fight sed).
perlperson 4y ago
I haven't seen frameworks in other languages rival mojolicious for rapid prototyping, web scraping, and good event-driven support. It's super easy to make websockets and even quickly have unit tests. Mojolicious still has 0 external dependencies and is rock solid and very scalable. The simplicity is just very nice compared to, for instance, frameworks in which lots of code generation is involved just to get started.

goto11 4y ago

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.

smcl 4y ago

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 https://blog.mclemon.org/missing-version-numbers

cesarb 4y ago
That page should have "24th December 2015" for the Perl 6 release date, because it was not skipped, it was actually released. See the Perl 6 release announcement at https://web.archive.org/web/20151225055622/https://perl6advent.wordpress.com/ https://web.archive.org/web/20151225055622/https://perl6adve... and Perl 6 download page at https://web.archive.org/web/20160208204149/http://perl6.org/downloads/ https://web.archive.org/web/20160208204149/http://perl6.org/... (for Perl 6 release 2016.01, there were other releases later). It only appears to have been skipped when looking from today's point of view, since many references to Perl 6 have been scrubbed from the web and replaced with its new name. But for those who were following the saga back then, starting with the announcement that the next major release of Perl would be Perl 6, followed by the many announcements of cool new features that next major release of Perl would have, culminating with its long-awaited Christmas release, it's hard to say that it never existed under that name.
- jrochkind1 4y ago
  The OP "What happened to Perl 7" doesn't say anything about Perl 6! I'm still confused about what happened to Perl 6! "replaced with it's new name" -- googling, that's "raku". So... what was going to be Perl 6 is considered a different language, and not particularly compatible with Perl. But "Perl 7" is meant to be less of a departure? It is weird OP left Perl 6 out of the story of "what happened to Perl 7". I guess it's just too painful?
  - dale_glass 4y ago
    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 who wanted to do things like releases and steadily approaching functionality. So there were a number of projects, a number of which were abandoned. Things dragged on, and nobody was cracking the whip. It took 15 years for Perl 6 to finally announce its first official release. Perl 6 also turned out to be too different from Perl 5. Different syntax, and no XS, which meant every Perl module interfacing with a library wouldn't work even if some sort of automatic conversion, or compatibility mode was possible. XS is tied to Perl 5's internals, and Perl 6 was an effort to make a new language from scratch, without using the old interpreter. Meanwhile, people started abandoning Perl 5 reasoning that since Perl 6 was in development, 5 would eventually die, and the lack of compatibility would mean current efforts on 5 would be wasted. It took a very long time but finally it was decided that Perl 6 wasn't really Perl 6, but some other, Perl-like language, and renamed to "Raku" to signal this. But by then it was already too late, most everyone had already moved on, and by the time when Perl 6 was finally released it was an extremely niche thing very few people had any interest in. 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.

deleted 4y ago

[deleted]

HeckFeck 4y ago

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

ggeorgovassilis 4y ago
> it is very unrestrictive That makes collaboration hard. The freedom I have in putting my thoughts into code, uninhibited by syntax, types and conventions makes it nearly impossible for others to understand and modify my work.
- mikem170 4y ago
  The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess The perl coding team I was on made readability our #1 priority. We didn't use tricky or out of the ordinary syntax unless it was absolutely necessary (like unusual regex, etc), and in those cases we would document what was happening with comments and maybe a reference to the appropriate man page. We had a style guide, for a consistent look and feel. We paid attention to naming and commented blocks of code, so the reader would not need to run an interpreter in their head while skimming through the code. We'd seek feedback from each other. It worked out well. We had no problems reading our code. We used the flexibility and expressiveness of perl to make our code more readable. We had the freedom to tailor the code to what we were doing, instead of the other way around.
  - ggeorgovassilis 4y ago
    > The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess If one learned how to collaborate on projects which, I think, the perl language does not incentivise. (edit) > The perl coding team I was on made readability our #1 priority. I'd love to read more about that. Have you by chance documented your experience somewhere?

bachmeier 4y ago

None of this makes sense IMO. The point of Perl 7 was not to allow breaking changes. It was to send a signal that Perl was alive and that the Perl 6 messup was behind them. Then two years later they announce that there's still no Perl 7 because they're still working on Perl 5.

rurban 4y ago
They are not working on perl 5, neither a perl 7. The biggest excitement might be the design of their new object system. But if you look at it and compare it to the design of their OO designed in 2002 (for their perl 6) it's a serious throwback. not even talking about their inability of a proper implementation. in the meantime I've implemented that, plus types, plus proper signatures, plus unchecked arrays when safe, plus an integrated ffi plus tons more features. their is no development, only maintainance. plus lot of internal fights. plus a CoC, which was used to eliminate the only remaining developer, because he dared to critice the stakeholders which blocked progress, and still continue to make the codebase worse. the less the work, the more the fights.
unixhero 4y ago
For all his agreeableness, maybe Larry Wall left behind a chaos of unsolved semantics. Perhaps discussions they never really recovered from. I do not know the story, and this is speculative only.
- nocman 4y ago
  From what I've gathered, Larry was simply focused on Perl 6 (which became "Raku" in Oct of 2019). It seems to me that he just wanted to let others handle the new development in Perl 5 rather than being directly involved all of the time. I don't think he has done much at all with Perl 5 for quite a long time.

jart 4y ago

It says Larry Wall isn't working on Perl anymore. When did that happen? It looks like the Perl6 thing was announced in 2000 and around 2010 Larry Wall deleted the Perl page from his blog (it's been a 404 link ever since) - https://web.archive.org/web/20100214124540/http://www.wall.org/~larry/perl.html https://web.archive.org/web/20100214124540/http://www.wall.o... - http://www.wall.org/~larry/perl.html http://www.wall.org/~larry/perl.html That butterfly was the worst. Perl would have been better served having an animal like the honeybadger as its logo.

mdaniel 4y ago
Since "backronyms" are a thing, I think they should adopt the camel as the logo, given that's what I see in my head when I think of perl: https://learning.oreilly.com/library/cover/0596000278/250w/ https://learning.oreilly.com/library/cover/0596000278/250w/
- bmn__ 4y ago
  Not as simple as you think: http://neilb.org/2020/12/04/perl-and-camels.html http://neilb.org/2020/12/04/perl-and-camels.html
doomvox 4y ago
> That butterfly was the worst. Agree completely. Larry Wall is pretty brilliant, but he shouldn't be doing graphics design. Actually, I tend to dislike cutsey-poo cartoon icons, in general. If you want to pick an animal totem, there are plenty of public domain photos of actual animals courtesy of the NSF and such...

alkaloid 4y ago

I still love Perl as essentially a low-level abstraction layer for C. I can get so much done at the system level without having to compile a bunch of code every time I make a small change. I've heard that Python (and maybe some others) are slowly replacing Perl as a "subsystem" of Linux, but I doubt that will happen before I retire. So, until then, TIMTOWTDI!

mberning 4y ago

A benevolent dictator for life is clearly a very beneficial thing for open source projects.

rabbits77 4y ago
Yes! The committee approach does not seem to work well. The “benevolent dictator” is really often just a solid CEO type: sets the vision, acts as head salesperson, and has the final word on all important decisions. What happened with Perl is that, effectively, the “pumpking” held that power but when Sawyer X actually used his discretion to announce Perl 7 there was a mutiny by jealous and bitter collaborators. They felt they should have some say in the matter and formed this Perl Steering Committee. As the brilliant Reini Urban has pointed out elsewhere in the comments, this group are fairly mediocre talent wise and mostly just spend their time sniping at each other. Reini’s cperl or Will Braswell’s rperl are both worthy projects that in a more perfect universe would have long ago supplanted the now rudderless mainline perl interpreter.
- doomvox 4y ago
  > Perl 7 there was a mutiny by jealous and bitter collaborators Look, I hate to harsh on Sawyer X-- he's done a bunch of good stuff for perl over the years, and I hope to see him around again-- but his Perl 7 push was just a mess. He was getting frustrated about things, and tried to plan and push through some big changes before anyone could complain, but he wasn't really that clear on what the big changes were supposed to be-- he left a couple of weeks to figure it out after that big announcement, and even the inner cabal he had talked to about this stuff first seemed more than a little surprised. One of the major things we got out of all this is it made it clear we needed some work on improved processes and transparency and such, and that's actually happened. There's a steering committee that makes a point of publishing its minutes, and an RFC process to talk over proposed changes. Some of these changes are in fact actually happening, and a number of them are discussed in this v5.36 annoucement (e.g. subroutine signatures are no longer experimental). This actually seems like a really bright crew in charge, and they're making very sane decisions. There's really no reason to think that there's some great benefit to breakage-on-upgrade: its a solution in search of a problem.

rootusrootus 4y ago

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I've always enjoyed Perl as a language. But I walked out of that presentation thinking "That was so beautiful, and I don't want it anywhere near my business." Because the last thing I need is software written in a language I can't hire anyone else to maintain. At some level that's what I think has happened to Perl in general. 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. But Perl programs are frequently art pieces that take a lot of effort to truly grok.

cestith 4y ago
Perl6 is now of course Rakulang. https://raku.org/ https://raku.org/ The folks responsible for that are still growing and improving their own ecosystem. It's a Perl-family language but it's different enough that they stepped away from the name so both Perl and Raku can flourish.
svachalek 4y ago
This is one thing I'm certain of after 40 years of programming: successful programs will need to be read more often than they are written. Language features that make programs cool or fun or "easy" to write are generally counter-productive to readability. Even things like this that are meant to make a program "expressive" are in fact just gimmicks if they are unique to one program. Features that make a language expressive in a consistent way are very valuable though. Python is a good example of this, even people who don't know anything about Python can generally read a Python program.
giantrobot 4y ago
> 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 a few hundred lines needed a lot of discipline to keep maintainable. Perl encouraged too many line noise shortcuts, reading unfamiliar code was too often an exercise in looking up uncommon operators. It's elegant when writing but frustrating when reading. Python not only read a bit more like it executed but didn't lend itself to unreadable shortcuts. If your code is elegant to write it tends to be straightforward to read. When Perl 6 was still Perl 6 the DSL stuff sounded interesting until like you I realized it would just turn large projects into unreadable messes. It wouldn't help the small Perl scripts be more readable nor would it help the large projects be more maintainable.

haolez 4y ago

An anecdote of my career is that some programming languages attract different kinds of programmers. I've dealt with Delphi in the beginning of my career and while there was nothing wrong with the language, it seemed to attract a lot of bad programmers writing really poor code. And Perl was the opposite of this anecdote: the most brilliant engineers I've met in my career were Perl monks, as they would call themselves. I respect Perl for that :)

deleted 4y ago
[deleted]

dinom 4y ago

Lol, here we are again bickering about Perl v. Python. I guess nothing beats a good flame war... Emacs v. Vi anyone?

doomvox 4y ago
Since doomacs and spacemacs, the vi folks have discovered org-mode and stopped fighting.

jandrese 4y ago

This seems like a whole lot of bending over backwards to avoid breaking a handful of edge cases that could be cleaned up on their own without too much drama. I would kind of prefer the features be enabled by default if you use a high enough version and if a module breaks you just fix it or dial back the version number at the top of your script until it is fixed. But I'd also run all of the test suites on CPAN against every new feature that comes out and fixing or at least tagging anything that breaks. Maybe even list a "maximum tested version number" for each module and emit a warning if you exceed it.

sigzero 4y ago
The majority didn't want the breaking possibility so it won out. It was discussed at length.

nvr219 4y ago

Because 7 8 9!! Ha ha

cosmiccatnap 4y ago

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.

atweiden 4y ago

I’m disappointed in the way this Perl 6 v Perl 7 debate is developing. Perl 6 modernizes Perl with e.g. concurrent and reactive programming, built-in grammars and a reimagined regex syntax superior to legacy PCRE, named function arguments, and gradual typing. Perl 6 was designed to be the successor language to Perl 5. The only technical grounds for Perl 6 being metaphorically sidelined was because Perl 6 lacked the startup and runtime performance characteristics of Perl 5 — fixable problems. Proponents of Perl 5 often contend Perl could’ve escaped developer mindshare loss without Perl 6 in the picture. But to claim Python, Ruby on Rails, Clojure, Go, Rust and JS/TS never would’ve gained serious developer mindshare had _Perl 6_ not existed seems very myopic to me. All the brilliant new languages and web frameworks launching were bound to erode Perl’s early established dominance regardless. Things would be different now if Perl 6 was at least as performant as Perl 5. Perhaps then it would’ve become popular years ago amongst Perl users to switch all greenfield Perl code to Perl 6. Then “Perl” would’ve become synonymous with modern language features.

dale_glass 4y ago
I think more than anything it was an error in the messaging. Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying, since people assumed that Perl 5 would be soon dead, and Perl 6 had a new different syntax. And then it took 15 years to happen, during which Python and others ate its lunch. I think a more successful strategy would have been to make it clear very early on that Perl 6 would be some sort of long term experimental project, and that Perl 5 would be expected to be a thing for a long time still. If in 2015 Perl 5 still had a thriving ecosystem, and there was a demand of Perl-like but better, then Perl 6 could have been more successful. But in the current timeline it's a successor to an almost defunct language, and isn't such an attractive proposition.
- atweiden 4y ago
  Have you used Raku before? The new and improved regex syntax [1] IMHO completely obsoletes legacy PCRE. Writing regexes in other languages feels like stepping into an ICE vehicle after driving a Tesla: so crufty and old and obvious legacy. Raku’s built-in grammars make parsers trivial to write. I effortlessly created two [2] — one for reordering fstab entries, and the other for converting human-readable LUKS offsets into cryptsetup sectors — on a lazy afternoon. Grammars in Raku make this second nature. Then you have Raku’s multi-dispatch. It is more capable than Erlang/Elixir pattern matching: # a list with at least one element, extracting the head and tail multi sub tail(*@list ($head, *@tail)) { @tail } multi sub tail(*@list) { @list } [3] ==> tail() ==> say(); # [] [3, 4] ==> tail() ==> say(); # [4] # pattern matching with arbitrary guards multi sub user($name where { is-valid-user($_) }) { $name.say } multi sub user($name) { "invalid name: $name".say } sub is-valid-user($name) { # notice the additive character class in this regex: “letters plus digits” # fail the match if $name is root try with $name ~~ /(<+:Letter +digit>+)/ { $0 ne 'root' or fail }; $!.not } user('name'); # name user('1234'); # 1234 user('root'); # invalid name: root class Coordinates { has $.latitude is required; has $.longitude is required; } class City { has Str:D $.name is required; has Str:D $.state is required; has Str:D $.country is required; has Coordinates:D $.coordinates is required; } my $latitude = -37.840935; my $longitude = 144.946457; my Coordinates $coordinates .= new(:$latitude, :$longitude); my Str:D $name = 'Melbourne'; my Str:D $state = 'Victoria'; my Str:D $country = 'Australia'; my City $melbourne .= new(:$name, :$state, :$country, :$coordinates); my City:D $sydney = do { my Coordinates:D $coordinates = do { my $latitude = -33.86514; my $longitude = 151.209900; Coordinates.new(:$latitude, :$longitude); }; my Str:D $name = 'Sydney'; my Str:D $state = 'New South Wales'; my Str:D $country = 'Australia'; City.new(:$name, :$state, :$country, :$coordinates); }; # deeply nested argument deconstruction multi sub melbourne-or-bust( City:D $city ( Str:D :$name where 'Melbourne', Str:D :$state, Str:D :$country, :$coordinates ( :$latitude, :$longitude ) ) ) { my $gist = qq:to/EOF/.trim; Welcome to the city of $name. It’s located in $state, $country. GPS coordinates: $latitude, $longitude EOF $gist.say; } multi sub melbourne-or-bust(City:D $city) { 'This isn’t Melbourne.'.say; } melbourne-or-bust($melbourne); # Welcome to the city of Melbourne ... melbourne-or-bust($sydney); # This isn’t Melbourne > Perl 6 was treated as the successor of Perl 5 -- and that was the mistake. It meant Perl 5 started dying, Perl 6 took a long time to make, but how much did that matter? What was Perl going to do about Rails, Clojure, Go, Rust, JS/TS, and more? The world of programming languages used to be a lot smaller than it is today. > Perl 6 had a new different syntax. Inline::Perl5 [3] allows running legacy Perl 5 code in Perl 6 codebases. [1]: https://docs.raku.org/language/5to6-nutshell#Regular_expressions_(_regex_/_regexp_) https://docs.raku.org/language/5to6-nutshell#Regular_express... [2]: https://github.com/atweiden/voidvault https://github.com/atweiden/voidvault [3]: https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5

iostream24 4y ago

I heard seven ate nine