42 ms·

The Future of Perl

140 points by bmn__ 6y ago

mlang23 6y ago
The Future of Perl apparently resides on a JavaScript only site. What a weird world.
- gerikson 6y ago
  Perl is nothing if not pragmatic.
- mmcclimon 6y ago
  I work for Fastmail, and helped write Topicbox, the backend of which is entirely written in modern Perl. The frontend obviously uses JavaScript, and talks to the backend using JMAP (RFC 8620), which we helped to develop; Topicbox was using 100% JMAP well before Fastmail itself did.
  - bshimmin 6y ago
    Why can't the back-end of Topicbox do the JMAP stuff and then serve up some HTML? Beyond "because that's how we built it and it must be thus", it's quite hard to see why the front-end would need so much JavaScript to render nothing more than a chain of emails.
    - brongondwana 6y ago
      If you're just loading a single page, then yeah - it's pretty useless. If you're spending any time in Topicbox then the benefits of push updates and dynamic preloading pay off, and it's pretty lightweight as Javascript goes. But yeah, in a perfect world where we had infinite time to develop it, we'd have the backend serve up a non-javascript static version of the content in response to direct links - if nothing else because it makes things a lot nicer for search engines - and then the javascript would load in and take over if enabled to allow you to keep moving through the site like usual.
  - phillc73 6y ago
    > and talks to the backend using JMAP (RFC 8620) FastCGI and mod_perl would have been a better choice.
    - mst 6y ago
      JMAP operates over http and the backend http server is almost certainly PSGI based, which obsoletes both FastCGI and mod_perl as deployment approaches.
      - phillc73 6y ago
        Thank you, I didn't know that. I was also being slightly facetious given the topic.
- chrisseaton 6y ago
  Just because you use Perl doesn't mean you can't use any other languages where appropriate. You don't need to be a zealot about everything.
  - mlang23 6y ago
    Believe it or not, I am one of these people hurt daily by the modern web. I rely on accessibility to do my daily tasks, and accessibility is the thing that goes away bit by bit from year to year. I used to do Perl for server-side scripting, the classical CGI stuff. I know the war is over. But calling a disabled person a zealot is probably a bit overshooting, dont you think?
j4yav 6y ago
I once loved Perl, it was the first language I learned, but reading through the comments and link I don’t see how you turn it into a modern, well loved and well used language (or even stop the decline) through small improvements but no grand vision, or by stepping away from the past in a meaningful and painful way. I wish them nothing but success, and sincerely hope their plan works, but I personally didn’t read anything there that made me think “oh wow, I’ll have to give Perl a try again when they deliver on their vision.”
- dash2 6y ago
  I wonder if they got burned by Perl 6/Raku. That had tons of new features but took so long to deliver that it became a burden. Anyway, I think you're right: they have to be more proactive than just going for "feature parity with a modern language".
  - yabadubakta 6y ago
    I recommend going to https://raku.org/ https://raku.org/ and reading up on the language because Raku actually has features “modern languages” do not. E.G. the grammars.
  - thatwasunusual 6y ago
    > I wonder if they got burned by Perl 6/Raku. I have the same feeling. I've been programming Perl since mid 90s, and I was - as many others - hyped when Perl 6 was announced early 2000s. 20 years later, it's just different programming language in my eyes; I won't spend any time on it, because if I need Perl, Perl 5.x will do just fine. Unfortunately, because of Perl 6/Parrot/Raku, or what the current name is, I think it made many developers get off the Perl train. There are lots of good frameworks for Perl that makes it super-easy to get something up and running really quickly; * Mojolicious (and its multitude of plugins, Minion etc.) * DBIx::Class (not pretty, but still just works) * Moose/Mouse (for decent OOP) * JSON::Validator (and friends, for mocking and validating) The list goes on, but this is the "out of the box"-stuff for me to get up and running with something, if not just a prototype of something.
peteretep 6y ago
https://docs.google.com/document/d/1OxeK0ctbBPtNw7UPG5x9iRYMs2b2kmjM4GWbB1x3QM8/edit# https://docs.google.com/document/d/1OxeK0ctbBPtNw7UPG5x9iRYM... ... is probably a better link than the random discussion in that horrible JS webapp?
- yellowapple 6y ago
  I ain't sure if replacing a horrible JS webapp with a different horrible JS webapp is much of an improvement ;)
- blewboarwastake 6y ago
  I appreciate the effort. If you don't like webapp bloat consider using pastebin: https://pastebin.com/ https://pastebin.com/, or any other text-sharing service.
shrubble 6y ago
JavaScript only website (couldn't even load the page without it) with a link to a Google Docs document. They've lost their way.
- oneeyedpigeon 6y ago
  In case anyone else is unclear on what the objection to the google doc might be, it also requires JavaScript.
  - deleted 6y ago
    [deleted]
cygx 6y ago
v8 will actually change defaults Bad idea, imo. Keep the perl binary backwards-compatible (unless 'use v8' is specified), and add a separate perl8 alias that does so implicitly.
- yellowapple 6y ago
  It'd be interesting to see versions specified by their file extension. Perl 6 already set that precedent with the .pl6/.pm6 extensions, and I don't see any substantial downsides aside from maybe some file association inconvenience (but that's pretty trivial to fix). Plain .pl/.pm files can then always be assumed to be Perl 5 code, and to be treated as such.
  - cygx 6y ago
    Didn't think of that, but it could work. If you only provided the perl8 alias, you'd still need to add a use declaration to modules, whereas that could be absorbed into the file extension...
  - toast0 6y ago
    There's no need to set it with a file extension. You can set the #! or put use v8.
    - yellowapple 6y ago
      Right, but that's extra boilerplate. Granted, it's only one line (two if you do both), but still. Reducing boilerplate is already an explicit goal for v8, so it seems like it's worthwhile to be consistent on that front. Also, not all Perl files have a shebang, and not all files are invoked in a way that'd make a shebang useful. Modules are the obvious example here. In any case, nothing precluding all three approaches from being supported in case Perl hackers really prefer a "use v8;" over changing the filename or vice versa.
- zokier 6y ago
  If the defaults are not changed, then what would be the difference between v7 and v8?
acomjean 6y ago
Perl has really fallen out of favor in bioinformatics. I inherited a bunch of Perl scripts that have been running basically for over 10 years. The input data is the same so they keep working. I’m not great at Perl and I do find them hard to read. While I get the goals I’m not super happy to have these scripts end up on the continuous upgrade as the language changes path. The goals seem good. A language needs users, and fewer and fewer are using it lately. Error messages can be obtuse, the package system while powerful is confusing.. Out cluster upgraded the os a couple years ago. Once you figure out how to a missing Perl library installed everything kept working. (The cpan installation story isn’t easy for a novice). the fact that it hasn’t changed much is kind of nice compared to some other language where a lot of scripts needed a fair amount of touch up when the language had a lot of breaking changes.
- ktpsns 6y ago
  The same is true in many other data science branches (such as physics). Perl was the perfect glue language in the 90s but then got more and more replaced by python. I think one reason for that is Numpy/Pylab, which makes python a perfect replacement for proprietary Matlab codes. All at once, scientists can write most of their codes in a single language/software ecosystem which also feels relatively close to mathematical notation, at least you can write equations similarly readable as in (modern) Fortran. The perl sigils really got out of fashion.
- valarauko 6y ago
  Similar story here - during my PhD my lab worked mostly in perl & C, but for my purposes R was a better fit. Some years down the line, I grew frustrated & moved to python, where I've been ever since. In my postdoc lab we're mostly leaning R, though a few of us are on python. I suspect newer members will be mostly python.
- attractivechaos 6y ago
  > compared to some other language where a lot of scripts needed a fair amount of touch up when the language had a lot of breaking changes. Python, I am looking at you!
lizknope 6y ago
I learned Perl in the late 90's and I still use Perl 5 all the time. The semiconductor industry is held together with thousands of lines of Tcl and Perl code. Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl. Introducing a new language doesn't seem worth it.
- dtech 6y ago
  That's going to work right up until you all retire around the same time
  - n3storm 6y ago
    LoL
  - brokenkebab 6y ago
    There are loads of battle-tested well-working Perl code around, and its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL. So no matter what is Perl's future in terms of evolution, or mindshare there will be Perl programmers until the code is retired, and its unlikely to happen anytime soon.
    - dtech 6y ago
      There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems. [1] If your hypothesis would be true this wouldn't be the case, as there would always be enough smart devs to learn COBOL and keep working on them. [1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancient-computer-language-is-slowing-america-s-giant-stimulus https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
      - clipradiowallet 6y ago
        It's a pay problem. I don't mind learning some random COBOL codebase and maintaining it, but clients don't want to pay consulting rates over the long term, for what they view as "maintaining an old system".
gekkonier 6y ago
It was my first programming language I got things done with - until I discovered ruby. After a ride into lisp/scheme/racket world I'm on ruby again. I have good memories with it, but I wouldn't jump train again.
eddyg 6y ago
Why wouldn’t the future focus be on Raku at this point? Perl is (was?) a great language, but Raku offers so much more. Of course Raku has the “expected” things from Perl like classes and all the fantastic regex and string manipulation features. But Raku brings: * Optional/gradual typing (and unlike Python, declared types are enforced) * Pattern matching, where different function definitions can be defined for different input values, like Haskell * Multiple dispatch, so different function bodies can be defined for different sets of argument types (like pattern matching, but based on types, like Julia) * Lazily-generated sequences, like Haskell or Clojure * Lisp-like AST macros * A built-in syntax for defining grammars and generating parsers Not to mention junctions, autothreading, hyperoperators (vector operators), asynchronous operations, parallelism, concurrency, and multi-core support. The list goes on and on... It’s unfortunate that so many programmers I talk to aren’t even willing to consider looking at Raku, even though it has a lot to offer. But I am confused by this “future” where Perl wants to continue on to v7, v8...
- nickelcitymario 6y ago
  I'm a little ignorant about Raku, so take my comments with a grain of salt, but... Saying Raku is the future of Perl is like saying Objective-C is the future of C. Or Ruby is the future of C. Or Python is the future of C. Or C++ or... really most languages out there, because most of them are built on top of or branched from C. Yet we're all quite capable of recognizing that each as its own place and path and future. They didn't replace C, and Raku didn't replace Perl. And, of course, Perl built on what came before: C, AWK, shell scripting, sed, BASIC, LISP... and Larry Wall never pretended otherwise. So I think Raku is a very interesting project, but calling it the future of Perl seems mistaken. Raku is the future of Raku.
  - atweiden 6y ago
    > I'm a little ignorant about Raku, so take my comments with a grain of salt, but... That makes two of us. Albeit, I began working with Raku in 2015, when it was still called Perl 6. What follows is just my opinion, so take my comments with a grain of salt. > Saying Raku is the future of Perl is like saying Objective-C is the future of C. This isn’t true. From the beginning, Perl 6 was always envisioned as the successor language to Perl 5. The reasons given for this were myriad: Perl 5 would benefit from having a more regular syntax (e.g. `$this{}` would become `%this{}`), a decideably parseable implementation [1], first-class OOP support in the standard library, as well as gradual typing and a concurrency/parallelism story, amongst many other things. Objective-C is more of a bolt-on addition to C. It’s less a separate programming language from C than it is a potentially useful paradigm for programming in C. Objective-C was never designed to “replace C” the way Perl 6 was designed to replace Perl 5. > and Raku didn't replace Perl. Well, it should’ve. Other than nostalgia attached to graybearded Perl developers of yore, you can see ITT the writing is on the wall for Perl 5. IMO Perl 5 looks clearly destined to the same fate as Sed and Awk: a CLI “power tool” — critical to infrastructure in unappreciated ways — but ultimately disposable and not a serious solution. Raku is to Perl 5 what Perl 5 is to Awk, IMO. In my view, it was deeply unfortunate certain loud minorities from Perl 5 were able to derail Perl 6, as if that would be the thing that could save Perl 5 from its destiny of utter irrelevancy. [1]: https://news.ycombinator.com/item?id=5770531 https://news.ycombinator.com/item?id=5770531
haolez 6y ago
Off topic, but the best programmers that I've met so far in my career were Perl gurus. They had this super power where they could implement new tools from scratch and they would feel robust as if they were made by an external vendor or an open source project. It was magic to me.
- cookiecaper 6y ago
  Yeah, I started working at a place where 90%+ of the production codebase is actively-maintained Perl, and it honestly feels great. These guys might have a hard time fitting a recruiter's definition for a "rock star" but they're the best set of colleagues I've had in a very long time, and that's after working at multiple flashy tech companies. Long live Perl. We can only hope to get another generation of programmers as committed and useful as the people who still write Perl every day.
  - haolez 6y ago
    Btw, my gurus are working at Comcast. I was kind of surprised to see Perl demand in a company as big as Comcast nowadays.
- aduitsis 6y ago
  I started using Perl in 2000 to rescue my diploma thesis (which was Java and C). I was working on a piece of software that was to communicate with another system that was the subject of another sister-thesis. The person working on the sister-thesis decided to abandon it. And I could really not demonstrate my work as it couldn't work standalone. In the place of the missing sister-system, I quickly put together something in Perl and was able to salvage the work and deliver my thesis. Compared to Java and C of the day, it felt like magic. To this day, I have never seen anything that can even remotely approach the ability of Perl to prototype something out of thin air. Usually there is a gap between script-like tools (like sh, sed, awk, grep, jq, curl, etc) with which you can quickly put together stuff and a "real" language which usually needs scaffolding and preparation. Perl can do both, you can write excellent one-liners and you can also write complex software with libraries and frameworks and dependencies and tests.
tyingq 6y ago
"We're determined to have improved OO syntax in a future release, and we'd love that to be v8, but we don't want to hold up this plan because OO needs time to mature." I wonder what this means. Especially if signatures are on by default, the OO syntax is pretty straightforward already, with most boilerplate gone. Like: package Some::Object { sub new ( $class, $args = {} ) { bless $args, $class; } }
- chrisseaton 6y ago
  > with most boilerplant gone Boilerplate class variable, boilerplate args variable, both written twice, deliberately cryptic whimsical 'bless' operation that for some reason needs to be done manually. Come on...
  - tyingq 6y ago
    The boilerplate class and args aren't mandatory, @_ still exists. I put them in the example to mean that if you wanted to use them, you don't have to pull them out of @_ with boilerplate. As for bless(), it's what makes Perl OO work. Getting rid of it is an option, but to me getting rid of it makes things more cryptic.
    - chrisseaton 6y ago
      > As for bless(), it's what makes Perl OO work. Getting rid of it is an option, but to me getting rid of it makes things more cryptic. Yeah I get it... but it's still boilerplate. Something you have to write out manually each time which you don't need to do in other languages.
      - tyingq 6y ago
        Yes, but it is significantly less boilerplate than before. If you get rid of bless(), you would need to add some equivalent to "package" that is OO specific rather than just namespaces, and/or a magical constructor method name. That (to me) is no less whimsical than bless.
alexhutcheson 6y ago
Perl deserves credit for being way ahead of the curve: It was a free, widely available, garbage-collected language with good support for strings, during a time when the server-side alternatives were basically (primitive, early) C++ or expensive commercial toolchains. By 1995 it also had CPAN, which was (I believe) the first comprehensive directory of modules available for a language ecosystem. The combination of garbage collection, good string support, and a huge set of easy-to-use third-party modules made Perl insanely productive relative to the other options at the time. Remember - Python didn't release a 1.0 until 1994, and Java 1.0 didn't come out until 1996, and the early versions of those languages were missing a lot of features you'd recognize today, and still had plenty of bugs and performance issues to work out. By 1994 Perl had been out for >6 years, and reached version 5.0 that year. In both capabilities and maturity, it was ahead of the other free alternatives, and way ahead of trying to wrestle with string templating in C or C++. Perl enabled a ton of cool things to be built much more quickly than they would have with the other tools available at the time. At the same time, it's hard to see a viable niche for Perl going forward. The advantages I mentioned above are no longer unique to Perl - they're now table stakes for any mainstream language. Every mainstream language has a package archive now. There are at least 7 mainstream general-purpose languages with a garbage-collecting runtime, with quality ranging from decent to incredible. Every language except C evolved decent support for string manipulation. Perl deserves tremendous credit for leading the way in making these things mainstream, but it has left Perl with very few distinguishing advantages. Without those advantages, Perl seems destined to gradually fade away. The sheer mass of existing code means it will probably never be gone - there will always be important systems still running on Perl. But very few greenfield projects will use it, and fewer programmers will learn it in the future. We can quibble about why Perl has gradually faded from relevance. Personally, I think people generally overweight the importance of the Perl 6 announcement, and underweight the impact of Apache's mod_php in shifting usage away from Perl. mod_php enabled hosting providers to safely enable PHP on shared hosting, while mod_perl couldn't be used in that context, because users could affect the Perl environments of other users on the same system. As a result, PHP hosting was cheap and had tons of options, while Perl hosting required a more expensive option like VPS or a dedicated box. This kick-started the PHP ecosystem, and its growth came largely at the expense of the Perl web development ecosystem. One could imagine an alternative world in which PHP never took off, and Facebook, Wikipedia, Wordpress, etc. were all started in Perl, but that's not the world we live in.
bachmeier 6y ago
There are so many stories from people that used Perl long ago but have since moved on to better languages. My story is the opposite. I tried Perl ages ago and couldn't understand why anyone would use it for anything. A couple years ago I decided to give it a try (it was the best fit for unimportant reasons). What I found was a solid language that was great for working with text, highly performant, a good replacement for Bash, and everything just worked so easily, including CPAN packages. A few days ago, I returned to modify something I wrote last year. I was surprised at how easy it was to read and understand the code. The $ and @ that folks complain about are pretty handy tools to convey what the variable holds. Though I won't be moving most of my code to Perl, I think it's great for what it was originally intended to do.
- cogman10 6y ago
  Perl is great because it makes text processing and CLI tool development really stupid simple. The language was built for that sort of thing. Perl suffers for the same reason. It's early prioritization of text manipulation makes it not great at general purpose programming.
  - bachmeier 6y ago
    > It's early prioritization of text manipulation makes it not great at general purpose programming. Exactly, and that's where I went wrong the first time I looked at Perl. You can tell the language was designed by someone that knew a lot about text manipulation. That means it's really good at solving those problems. Unfortunately I wasn't using it for text manipulation at that time.
- wott 6y ago
  > The $ and @ that folks complain about are pretty handy tools to convey what the variable holds. It doesn't convey much. $scalar or @array, that's all. An array is always an array of scalars. Scalar can be almost anything: any kind of number, a string, a reference (often a reference to... an array or a hash, since you can't have arrays of arrays or array of hashes, only arrays of scalars).
jerf 6y ago
This is a good "patch the holes" plan, but I think it needs to be followed up in short order by some deeper thinking. And some very painfully honest thinking. Paul Graham, whom some of you may have heard of, once wrote an essay about "What Languages Fix": http://paulgraham.com/fix.html http://paulgraham.com/fix.html I think of it a bit differently, which is that languages have a thesis. (Not quite the same but a lot of overlap.) Paul writes that what Perl fixes is "Shell scripts/awk/sed are not enough like programming languages." I would personally rephrase it to something like "There isn't(/wasn't) a language dedicated enough to Getting It Done." If you put yourself in the context of the time, this was absolutely true. Most languages for getting things done involved a lot of drama and boilerplate. Popular languages of the day would require you to implement your own hash table for a quick script, if you didn't have one on hand. Libraries for that existed of course, but the Internet wasn't really up and running the way it is now yet, and things were hard to find. Perl came in and provided a great Get It Done languages. However, landscapes evolve over time and so do language theses. C++ is a great example of something that has changed, going from "C should have great support for object orientation" to something more like "C++ should be the choice for programmers who want zero-cost abstractions". Part of the reason for that change is that the former thesis is no longer a compelling one, on the grounds that "great object orientation support" is now simply table stakes for that sort of language. C++ could not drive forward on that thesis in 2021. That is also Perl's real problem right now. It lacks a thesis. It has very narrow advantages in text munging still, but for almost anything else, I now have an abundance of languages that "get it done" just as well or better. For context, I've got about 15 years of Perl being my primary language under my belt, so that means something; it's not a secondary or tertiary language for me, and I still have plenty of choices to reach for. (Heck, I've even come to prefer Go for JSON munging quite a lot of the time, because with the right tooling it's really easy to parse JSON straight into objects that I can call methods on meaningfully, which is actually more convenient and useful to me than presenting me with a generic hashtable/array representation that I then have to write a lot of code to crawl over from the "outside".) The world has moved on, and Perl's problem isn't necessarily that it lost but that it won. It has successfully convinced the world that Getting It Done doesn't need to come with all the drama and paperwork and complexity of its late 1990s peers. But that means that just like C++ won and it couldn't continue operating on its "good OO" thesis, Perl needs a new thesis. Moreover, it's going to have to be brutally honest in the selection of that thesis, because a lot of the obvious ones are already covered by Python, and trying to chase Python on its own turf is going to be a losing game. Perl 6/Raku also has its own thesis, which is now also essentially unavailable to Perl 5. Unfortunately, choosing a thesis successfully isn't necessarily about what the Perl team "wants" so much as where there is space in the programming language market, and in the intervening, gosh, decade or so that Perl 5 has been floating along without a thesis, a lot of the easy or obvious answers have been fairly well covered by other languages. One thesis option is "Old perl code should degrade gracefully", which is the "declare victory and walk off into the sunset" option. To be honest, it's one that should be seriously considered. I think graceful retirement is a test a lot of language committees fail. Here I'd look for improved refactoring tools to help automatically translate old code into better code to modern standards and other such things being the standard, for instance. But if the Perl 5/7 team wants a different thesis, it's something I think they need to decide consciously. I don't have a suggestion. But I can offer this word of hope; the space of possible theses is really quite large. The point of view where it looks like every possible language exists already is a point of view that is too narrowly stuck in the details of today. With just a bit of change in perspective, there's a lot of untapped fields. Tempering that hope a bit, Perl's new thesis really needs to be something that Perl's existing code and community brings something powerful to. If you come up with a possible thesis, but look at it honestly and say "That's probably something better done with a brand new language entirely", it's probably not a functional thesis for Perl. And this does cut the space back somewhat. But some persistent thought may still find something interesting. Personally, I'd also be looking carefully and honestly at what Perl is still doing and consider shedding old use cases/theses. For example, while Python is not experiencing a popularity crisis, consider a hypothetical world in which the only people still using Python were basically NumPy users. It would be a valid choice to move forward with Python development in a way that privileged such use, at the expense of "general purpose" use going forward. I'm not involved enough with Perl to know what that would be, just offering a meta-option to consider. And let me close on what I opened with... this is a good "patch the holes" plan that should be all means moved forward with, to give space to breathe. I'm positive on the plan, not critical of it.
Pet_Ant 6y ago
What exactly is Larry Wall's involvement with Perl anymore? Has he moved entirely to Rakudo (ne Perl 6)?
- G3rn0ti 6y ago
  Larry Wall designed Perl 6 i.e. Raku and created the original parser. I am not sure if he is still actively working on it. The actual implementations, however, were done by others. So like Lisp or C Raku is actually a specification driven language in contrast to languages like Perl 5, Ruby or Python where the most popular interpreter serves as the specification.
  - cygx 6y ago
    Raku is actually a specification driven language That hasn't been true for a while. The test suite is supposed to be canonical, whereas the 'specification' hasn't been kept up to date with language evolution.
    - Pet_Ant 6y ago
      > The test suite is supposed to be canonical, whereas the 'specification' hasn't been kept up to date with language evolution. This is so disappointing. Feels like the language over time has lost everything that made it interesting. PUGS for example.
      - raiph 6y ago
        I hear you feel disappointed, but it is presumably due to someone having misled you due to their misinterpretation of Larry's design. Roast (the Repository Of All Specification Tests) has, for over 20 years in design terms, and 15+ years in reality, been Raku's canonical, machine readable specification that is versionable, branchable, forkable, mergeable, and which is backed by a PL design that envisages its versioning, branching, forking, and merging. So we now have a suite of approaching 200K tests that provide a principled software engineering way to generate a single boolean True|False that a so-called Raku compiler does or does not precisely implement the machine readable specification. Features cannot be removed or added without not only being specified in language, and if appropriate subjected to formal analysis, but also openly discussed and debated, implemented in a branch, hammered on for however long with beta testers trying it out to see if it's worth removing/adding, and only then arriving in the official master branch of roast. This can and has meant there can be up to a 3 year period before changes become official, or, conversely, a 24 hour period for a security patch to become official, and the system guarantees that any risk of breakage is controlled by users. This is a revolutionary level of centralized/distributed digital governance.
eruci 6y ago
You can build anything in any programming language, even byte code/assembly if you're so inclined. What you end up using is the one that can do the job faster. I built a custom web store yesterday entirely in mod Perl in 2 hours flat ( https://store.poidata.xyz https://store.poidata.xyz ). If you can beat that in some other programming language, like Python, by all means, stop using Perl.
- einpoklum 6y ago
  > What you end up using is the one that can do the job faster. Not necessarily. Maybe you're interested in: * Performance optimization. * Maintainability. * Accessbility to more programmers (= fashion) * Conforming to organization policy on the language to use * Code readability etc. Different target function -> different considerations.
  - eruci 6y ago
    Agreed. These are fair points of consideration. In my case though, the main one to consider is speed of development.
iso1210 6y ago
I've got a perl website dating back to 2004 - from before php5 was out - that is still used by hundreds of people a day on an internal system. Works great, the code is deployed by a deb in the same was as it deployed in 2008. Since initial creation, had about 10 hours effort to put in a mobile view for an iphone and blackberry in 2008/9, and maybe 5 hours effort to replace the <object> with <video> a couple of years ago. Update the 3 files, roll the new deb, and away we go for the next forseeable, until the userbase finally decides that the multi-man-year all-singing replacement that's some javascript heavy frontend and microservice backend actually lets them do their job better (which it seems isn't the case from the complaints it gets) Sometimes a tool just works and enables you to get on and do things beneficial to your product.
throwaway0x1 6y ago
The future or Perl: Python
johnisgood 6y ago
I had fun with Perl and Tcl back when I was 14 or something. I think they may have been the first "serious" programming languages I have used.
stinkfoot68 6y ago
Always ignored perl for default *nix toolbox (bash + awk + sed) utilities that were standard and in place 'by default'. These days unless you have python 2 and 3 + 20 python libraries per version on a system you can't count on a developer being productive. Recently I've seen guys drive ssh remote command execution in java - we are falling into fashionable senility.
rurban 6y ago
So they explicitly laid out their plan for further destruction. Not that is unknown, they did it since 5.8 days, since perl6. No plans for explicit improvements as detailed planned in 2002, for perl6. 90% of those goals should be perl5 goals, just not breaking syntax, because it is cool. So their new plan is to follow the perl6 route, breaking syntax, cpan and backwards compatibility, whilst still having not a single clue how to implement those features. OO? They are still completely clueless. Jit? Not even mentioned. Native types, ffi? Not even mentioned. Abstract the parser for macros and grammars? Not even mentioned. Proper signatures? Only on cpan, not in core. And many such features which I already have implemented for perl5/cperl. There is no future, they killed it. Long time ago. Everybody with a little bit of competence already left at around 2005. Just leave it alone, until you can promise something and those plans are believable. The more you do, the more destruction.

The Future of Perl

140 points by bmn__ 6y ago

mlang23 6y ago

The Future of Perl apparently resides on a JavaScript only site. What a weird world.

gerikson 6y ago
Perl is nothing if not pragmatic.
mmcclimon 6y ago
I work for Fastmail, and helped write Topicbox, the backend of which is entirely written in modern Perl. The frontend obviously uses JavaScript, and talks to the backend using JMAP (RFC 8620), which we helped to develop; Topicbox was using 100% JMAP well before Fastmail itself did.
- bshimmin 6y ago
  Why can't the back-end of Topicbox do the JMAP stuff and then serve up some HTML? Beyond "because that's how we built it and it must be thus", it's quite hard to see why the front-end would need so much JavaScript to render nothing more than a chain of emails.
  - brongondwana 6y ago
    If you're just loading a single page, then yeah - it's pretty useless. If you're spending any time in Topicbox then the benefits of push updates and dynamic preloading pay off, and it's pretty lightweight as Javascript goes. But yeah, in a perfect world where we had infinite time to develop it, we'd have the backend serve up a non-javascript static version of the content in response to direct links - if nothing else because it makes things a lot nicer for search engines - and then the javascript would load in and take over if enabled to allow you to keep moving through the site like usual.
- phillc73 6y ago
  > and talks to the backend using JMAP (RFC 8620) FastCGI and mod_perl would have been a better choice.
  - mst 6y ago
    JMAP operates over http and the backend http server is almost certainly PSGI based, which obsoletes both FastCGI and mod_perl as deployment approaches.
    - phillc73 6y ago
      Thank you, I didn't know that. I was also being slightly facetious given the topic.
chrisseaton 6y ago
Just because you use Perl doesn't mean you can't use any other languages where appropriate. You don't need to be a zealot about everything.
- mlang23 6y ago
  Believe it or not, I am one of these people hurt daily by the modern web. I rely on accessibility to do my daily tasks, and accessibility is the thing that goes away bit by bit from year to year. I used to do Perl for server-side scripting, the classical CGI stuff. I know the war is over. But calling a disabled person a zealot is probably a bit overshooting, dont you think?

j4yav 6y ago

I once loved Perl, it was the first language I learned, but reading through the comments and link I don’t see how you turn it into a modern, well loved and well used language (or even stop the decline) through small improvements but no grand vision, or by stepping away from the past in a meaningful and painful way. I wish them nothing but success, and sincerely hope their plan works, but I personally didn’t read anything there that made me think “oh wow, I’ll have to give Perl a try again when they deliver on their vision.”

dash2 6y ago
I wonder if they got burned by Perl 6/Raku. That had tons of new features but took so long to deliver that it became a burden. Anyway, I think you're right: they have to be more proactive than just going for "feature parity with a modern language".
- yabadubakta 6y ago
  I recommend going to https://raku.org/ https://raku.org/ and reading up on the language because Raku actually has features “modern languages” do not. E.G. the grammars.
- thatwasunusual 6y ago
  > I wonder if they got burned by Perl 6/Raku. I have the same feeling. I've been programming Perl since mid 90s, and I was - as many others - hyped when Perl 6 was announced early 2000s. 20 years later, it's just different programming language in my eyes; I won't spend any time on it, because if I need Perl, Perl 5.x will do just fine. Unfortunately, because of Perl 6/Parrot/Raku, or what the current name is, I think it made many developers get off the Perl train. There are lots of good frameworks for Perl that makes it super-easy to get something up and running really quickly; * Mojolicious (and its multitude of plugins, Minion etc.) * DBIx::Class (not pretty, but still just works) * Moose/Mouse (for decent OOP) * JSON::Validator (and friends, for mocking and validating) The list goes on, but this is the "out of the box"-stuff for me to get up and running with something, if not just a prototype of something.

peteretep 6y ago

https://docs.google.com/document/d/1OxeK0ctbBPtNw7UPG5x9iRYMs2b2kmjM4GWbB1x3QM8/edit# https://docs.google.com/document/d/1OxeK0ctbBPtNw7UPG5x9iRYM... ... is probably a better link than the random discussion in that horrible JS webapp?

yellowapple 6y ago
I ain't sure if replacing a horrible JS webapp with a different horrible JS webapp is much of an improvement ;)
blewboarwastake 6y ago
I appreciate the effort. If you don't like webapp bloat consider using pastebin: https://pastebin.com/ https://pastebin.com/, or any other text-sharing service.

shrubble 6y ago

JavaScript only website (couldn't even load the page without it) with a link to a Google Docs document. They've lost their way.

oneeyedpigeon 6y ago
In case anyone else is unclear on what the objection to the google doc might be, it also requires JavaScript.
- deleted 6y ago
  [deleted]

cygx 6y ago

v8 will actually change defaults Bad idea, imo. Keep the perl binary backwards-compatible (unless 'use v8' is specified), and add a separate perl8 alias that does so implicitly.

yellowapple 6y ago
It'd be interesting to see versions specified by their file extension. Perl 6 already set that precedent with the .pl6/.pm6 extensions, and I don't see any substantial downsides aside from maybe some file association inconvenience (but that's pretty trivial to fix). Plain .pl/.pm files can then always be assumed to be Perl 5 code, and to be treated as such.
- cygx 6y ago
  Didn't think of that, but it could work. If you only provided the perl8 alias, you'd still need to add a use declaration to modules, whereas that could be absorbed into the file extension...
- toast0 6y ago
  There's no need to set it with a file extension. You can set the #! or put use v8.
  - yellowapple 6y ago
    Right, but that's extra boilerplate. Granted, it's only one line (two if you do both), but still. Reducing boilerplate is already an explicit goal for v8, so it seems like it's worthwhile to be consistent on that front. Also, not all Perl files have a shebang, and not all files are invoked in a way that'd make a shebang useful. Modules are the obvious example here. In any case, nothing precluding all three approaches from being supported in case Perl hackers really prefer a "use v8;" over changing the filename or vice versa.
zokier 6y ago
If the defaults are not changed, then what would be the difference between v7 and v8?

acomjean 6y ago

Perl has really fallen out of favor in bioinformatics. I inherited a bunch of Perl scripts that have been running basically for over 10 years. The input data is the same so they keep working. I’m not great at Perl and I do find them hard to read. While I get the goals I’m not super happy to have these scripts end up on the continuous upgrade as the language changes path. The goals seem good. A language needs users, and fewer and fewer are using it lately. Error messages can be obtuse, the package system while powerful is confusing.. Out cluster upgraded the os a couple years ago. Once you figure out how to a missing Perl library installed everything kept working. (The cpan installation story isn’t easy for a novice). the fact that it hasn’t changed much is kind of nice compared to some other language where a lot of scripts needed a fair amount of touch up when the language had a lot of breaking changes.

ktpsns 6y ago
The same is true in many other data science branches (such as physics). Perl was the perfect glue language in the 90s but then got more and more replaced by python. I think one reason for that is Numpy/Pylab, which makes python a perfect replacement for proprietary Matlab codes. All at once, scientists can write most of their codes in a single language/software ecosystem which also feels relatively close to mathematical notation, at least you can write equations similarly readable as in (modern) Fortran. The perl sigils really got out of fashion.
valarauko 6y ago
Similar story here - during my PhD my lab worked mostly in perl & C, but for my purposes R was a better fit. Some years down the line, I grew frustrated & moved to python, where I've been ever since. In my postdoc lab we're mostly leaning R, though a few of us are on python. I suspect newer members will be mostly python.
attractivechaos 6y ago
> compared to some other language where a lot of scripts needed a fair amount of touch up when the language had a lot of breaking changes. Python, I am looking at you!

lizknope 6y ago

I learned Perl in the late 90's and I still use Perl 5 all the time. The semiconductor industry is held together with thousands of lines of Tcl and Perl code. Every day I have to parse some new type of text file and Perl is great for that. Everyone else I work with are also in the same age range and everyone already knows Perl. Introducing a new language doesn't seem worth it.

dtech 6y ago
That's going to work right up until you all retire around the same time
- n3storm 6y ago
  LoL
- brokenkebab 6y ago
  There are loads of battle-tested well-working Perl code around, and its cheaper to hire one smart dev who can learn Perl to maintain than to hire a whole team to re-write in a new PL. So no matter what is Perl's future in terms of evolution, or mindshare there will be Perl programmers until the code is retired, and its unlikely to happen anytime soon.
  - dtech 6y ago
    There is regular news about how one COBOL system or the other has become unmaintainable and is causing problems. [1] If your hypothesis would be true this wouldn't be the case, as there would always be enough smart devs to learn COBOL and keep working on them. [1] example: https://www.bloomberg.com/news/articles/2020-04-13/an-ancient-computer-language-is-slowing-america-s-giant-stimulus https://www.bloomberg.com/news/articles/2020-04-13/an-ancien...
    - clipradiowallet 6y ago
      It's a pay problem. I don't mind learning some random COBOL codebase and maintaining it, but clients don't want to pay consulting rates over the long term, for what they view as "maintaining an old system".

gekkonier 6y ago

It was my first programming language I got things done with - until I discovered ruby. After a ride into lisp/scheme/racket world I'm on ruby again. I have good memories with it, but I wouldn't jump train again.

eddyg 6y ago

Why wouldn’t the future focus be on Raku at this point? Perl is (was?) a great language, but Raku offers so much more. Of course Raku has the “expected” things from Perl like classes and all the fantastic regex and string manipulation features. But Raku brings: * Optional/gradual typing (and unlike Python, declared types are enforced) * Pattern matching, where different function definitions can be defined for different input values, like Haskell * Multiple dispatch, so different function bodies can be defined for different sets of argument types (like pattern matching, but based on types, like Julia) * Lazily-generated sequences, like Haskell or Clojure * Lisp-like AST macros * A built-in syntax for defining grammars and generating parsers Not to mention junctions, autothreading, hyperoperators (vector operators), asynchronous operations, parallelism, concurrency, and multi-core support. The list goes on and on... It’s unfortunate that so many programmers I talk to aren’t even willing to consider looking at Raku, even though it has a lot to offer. But I am confused by this “future” where Perl wants to continue on to v7, v8...

nickelcitymario 6y ago
I'm a little ignorant about Raku, so take my comments with a grain of salt, but... Saying Raku is the future of Perl is like saying Objective-C is the future of C. Or Ruby is the future of C. Or Python is the future of C. Or C++ or... really most languages out there, because most of them are built on top of or branched from C. Yet we're all quite capable of recognizing that each as its own place and path and future. They didn't replace C, and Raku didn't replace Perl. And, of course, Perl built on what came before: C, AWK, shell scripting, sed, BASIC, LISP... and Larry Wall never pretended otherwise. So I think Raku is a very interesting project, but calling it the future of Perl seems mistaken. Raku is the future of Raku.
- atweiden 6y ago
  > I'm a little ignorant about Raku, so take my comments with a grain of salt, but... That makes two of us. Albeit, I began working with Raku in 2015, when it was still called Perl 6. What follows is just my opinion, so take my comments with a grain of salt. > Saying Raku is the future of Perl is like saying Objective-C is the future of C. This isn’t true. From the beginning, Perl 6 was always envisioned as the successor language to Perl 5. The reasons given for this were myriad: Perl 5 would benefit from having a more regular syntax (e.g. `$this{}` would become `%this{}`), a decideably parseable implementation [1], first-class OOP support in the standard library, as well as gradual typing and a concurrency/parallelism story, amongst many other things. Objective-C is more of a bolt-on addition to C. It’s less a separate programming language from C than it is a potentially useful paradigm for programming in C. Objective-C was never designed to “replace C” the way Perl 6 was designed to replace Perl 5. > and Raku didn't replace Perl. Well, it should’ve. Other than nostalgia attached to graybearded Perl developers of yore, you can see ITT the writing is on the wall for Perl 5. IMO Perl 5 looks clearly destined to the same fate as Sed and Awk: a CLI “power tool” — critical to infrastructure in unappreciated ways — but ultimately disposable and not a serious solution. Raku is to Perl 5 what Perl 5 is to Awk, IMO. In my view, it was deeply unfortunate certain loud minorities from Perl 5 were able to derail Perl 6, as if that would be the thing that could save Perl 5 from its destiny of utter irrelevancy. [1]: https://news.ycombinator.com/item?id=5770531 https://news.ycombinator.com/item?id=5770531

haolez 6y ago

Off topic, but the best programmers that I've met so far in my career were Perl gurus. They had this super power where they could implement new tools from scratch and they would feel robust as if they were made by an external vendor or an open source project. It was magic to me.

cookiecaper 6y ago
Yeah, I started working at a place where 90%+ of the production codebase is actively-maintained Perl, and it honestly feels great. These guys might have a hard time fitting a recruiter's definition for a "rock star" but they're the best set of colleagues I've had in a very long time, and that's after working at multiple flashy tech companies. Long live Perl. We can only hope to get another generation of programmers as committed and useful as the people who still write Perl every day.
- haolez 6y ago
  Btw, my gurus are working at Comcast. I was kind of surprised to see Perl demand in a company as big as Comcast nowadays.
aduitsis 6y ago
I started using Perl in 2000 to rescue my diploma thesis (which was Java and C). I was working on a piece of software that was to communicate with another system that was the subject of another sister-thesis. The person working on the sister-thesis decided to abandon it. And I could really not demonstrate my work as it couldn't work standalone. In the place of the missing sister-system, I quickly put together something in Perl and was able to salvage the work and deliver my thesis. Compared to Java and C of the day, it felt like magic. To this day, I have never seen anything that can even remotely approach the ability of Perl to prototype something out of thin air. Usually there is a gap between script-like tools (like sh, sed, awk, grep, jq, curl, etc) with which you can quickly put together stuff and a "real" language which usually needs scaffolding and preparation. Perl can do both, you can write excellent one-liners and you can also write complex software with libraries and frameworks and dependencies and tests.

tyingq 6y ago

"We're determined to have improved OO syntax in a future release, and we'd love that to be v8, but we don't want to hold up this plan because OO needs time to mature." I wonder what this means. Especially if signatures are on by default, the OO syntax is pretty straightforward already, with most boilerplate gone. Like: package Some::Object { sub new ( $class, $args = {} ) { bless $args, $class; } }

chrisseaton 6y ago
> with most boilerplant gone Boilerplate class variable, boilerplate args variable, both written twice, deliberately cryptic whimsical 'bless' operation that for some reason needs to be done manually. Come on...
- tyingq 6y ago
  The boilerplate class and args aren't mandatory, @_ still exists. I put them in the example to mean that if you wanted to use them, you don't have to pull them out of @_ with boilerplate. As for bless(), it's what makes Perl OO work. Getting rid of it is an option, but to me getting rid of it makes things more cryptic.
  - chrisseaton 6y ago
    > As for bless(), it's what makes Perl OO work. Getting rid of it is an option, but to me getting rid of it makes things more cryptic. Yeah I get it... but it's still boilerplate. Something you have to write out manually each time which you don't need to do in other languages.
    - tyingq 6y ago
      Yes, but it is significantly less boilerplate than before. If you get rid of bless(), you would need to add some equivalent to "package" that is OO specific rather than just namespaces, and/or a magical constructor method name. That (to me) is no less whimsical than bless.

alexhutcheson 6y ago

Perl deserves credit for being way ahead of the curve: It was a free, widely available, garbage-collected language with good support for strings, during a time when the server-side alternatives were basically (primitive, early) C++ or expensive commercial toolchains. By 1995 it also had CPAN, which was (I believe) the first comprehensive directory of modules available for a language ecosystem. The combination of garbage collection, good string support, and a huge set of easy-to-use third-party modules made Perl insanely productive relative to the other options at the time. Remember - Python didn't release a 1.0 until 1994, and Java 1.0 didn't come out until 1996, and the early versions of those languages were missing a lot of features you'd recognize today, and still had plenty of bugs and performance issues to work out. By 1994 Perl had been out for >6 years, and reached version 5.0 that year. In both capabilities and maturity, it was ahead of the other free alternatives, and way ahead of trying to wrestle with string templating in C or C++. Perl enabled a ton of cool things to be built much more quickly than they would have with the other tools available at the time. At the same time, it's hard to see a viable niche for Perl going forward. The advantages I mentioned above are no longer unique to Perl - they're now table stakes for any mainstream language. Every mainstream language has a package archive now. There are at least 7 mainstream general-purpose languages with a garbage-collecting runtime, with quality ranging from decent to incredible. Every language except C evolved decent support for string manipulation. Perl deserves tremendous credit for leading the way in making these things mainstream, but it has left Perl with very few distinguishing advantages. Without those advantages, Perl seems destined to gradually fade away. The sheer mass of existing code means it will probably never be gone - there will always be important systems still running on Perl. But very few greenfield projects will use it, and fewer programmers will learn it in the future. We can quibble about why Perl has gradually faded from relevance. Personally, I think people generally overweight the importance of the Perl 6 announcement, and underweight the impact of Apache's mod_php in shifting usage away from Perl. mod_php enabled hosting providers to safely enable PHP on shared hosting, while mod_perl couldn't be used in that context, because users could affect the Perl environments of other users on the same system. As a result, PHP hosting was cheap and had tons of options, while Perl hosting required a more expensive option like VPS or a dedicated box. This kick-started the PHP ecosystem, and its growth came largely at the expense of the Perl web development ecosystem. One could imagine an alternative world in which PHP never took off, and Facebook, Wikipedia, Wordpress, etc. were all started in Perl, but that's not the world we live in.

bachmeier 6y ago

There are so many stories from people that used Perl long ago but have since moved on to better languages. My story is the opposite. I tried Perl ages ago and couldn't understand why anyone would use it for anything. A couple years ago I decided to give it a try (it was the best fit for unimportant reasons). What I found was a solid language that was great for working with text, highly performant, a good replacement for Bash, and everything just worked so easily, including CPAN packages. A few days ago, I returned to modify something I wrote last year. I was surprised at how easy it was to read and understand the code. The $ and @ that folks complain about are pretty handy tools to convey what the variable holds. Though I won't be moving most of my code to Perl, I think it's great for what it was originally intended to do.

cogman10 6y ago
Perl is great because it makes text processing and CLI tool development really stupid simple. The language was built for that sort of thing. Perl suffers for the same reason. It's early prioritization of text manipulation makes it not great at general purpose programming.
- bachmeier 6y ago
  > It's early prioritization of text manipulation makes it not great at general purpose programming. Exactly, and that's where I went wrong the first time I looked at Perl. You can tell the language was designed by someone that knew a lot about text manipulation. That means it's really good at solving those problems. Unfortunately I wasn't using it for text manipulation at that time.
wott 6y ago
> The $ and @ that folks complain about are pretty handy tools to convey what the variable holds. It doesn't convey much. $scalar or @array, that's all. An array is always an array of scalars. Scalar can be almost anything: any kind of number, a string, a reference (often a reference to... an array or a hash, since you can't have arrays of arrays or array of hashes, only arrays of scalars).

jerf 6y ago

This is a good "patch the holes" plan, but I think it needs to be followed up in short order by some deeper thinking. And some very painfully honest thinking. Paul Graham, whom some of you may have heard of, once wrote an essay about "What Languages Fix": http://paulgraham.com/fix.html http://paulgraham.com/fix.html I think of it a bit differently, which is that languages have a thesis. (Not quite the same but a lot of overlap.) Paul writes that what Perl fixes is "Shell scripts/awk/sed are not enough like programming languages." I would personally rephrase it to something like "There isn't(/wasn't) a language dedicated enough to Getting It Done." If you put yourself in the context of the time, this was absolutely true. Most languages for getting things done involved a lot of drama and boilerplate. Popular languages of the day would require you to implement your own hash table for a quick script, if you didn't have one on hand. Libraries for that existed of course, but the Internet wasn't really up and running the way it is now yet, and things were hard to find. Perl came in and provided a great Get It Done languages. However, landscapes evolve over time and so do language theses. C++ is a great example of something that has changed, going from "C should have great support for object orientation" to something more like "C++ should be the choice for programmers who want zero-cost abstractions". Part of the reason for that change is that the former thesis is no longer a compelling one, on the grounds that "great object orientation support" is now simply table stakes for that sort of language. C++ could not drive forward on that thesis in 2021. That is also Perl's real problem right now. It lacks a thesis. It has very narrow advantages in text munging still, but for almost anything else, I now have an abundance of languages that "get it done" just as well or better. For context, I've got about 15 years of Perl being my primary language under my belt, so that means something; it's not a secondary or tertiary language for me, and I still have plenty of choices to reach for. (Heck, I've even come to prefer Go for JSON munging quite a lot of the time, because with the right tooling it's really easy to parse JSON straight into objects that I can call methods on meaningfully, which is actually more convenient and useful to me than presenting me with a generic hashtable/array representation that I then have to write a lot of code to crawl over from the "outside".) The world has moved on, and Perl's problem isn't necessarily that it lost but that it won. It has successfully convinced the world that Getting It Done doesn't need to come with all the drama and paperwork and complexity of its late 1990s peers. But that means that just like C++ won and it couldn't continue operating on its "good OO" thesis, Perl needs a new thesis. Moreover, it's going to have to be brutally honest in the selection of that thesis, because a lot of the obvious ones are already covered by Python, and trying to chase Python on its own turf is going to be a losing game. Perl 6/Raku also has its own thesis, which is now also essentially unavailable to Perl 5. Unfortunately, choosing a thesis successfully isn't necessarily about what the Perl team "wants" so much as where there is space in the programming language market, and in the intervening, gosh, decade or so that Perl 5 has been floating along without a thesis, a lot of the easy or obvious answers have been fairly well covered by other languages. One thesis option is "Old perl code should degrade gracefully", which is the "declare victory and walk off into the sunset" option. To be honest, it's one that should be seriously considered. I think graceful retirement is a test a lot of language committees fail. Here I'd look for improved refactoring tools to help automatically translate old code into better code to modern standards and other such things being the standard, for instance. But if the Perl 5/7 team wants a different thesis, it's something I think they need to decide consciously. I don't have a suggestion. But I can offer this word of hope; the space of possible theses is really quite large. The point of view where it looks like every possible language exists already is a point of view that is too narrowly stuck in the details of today. With just a bit of change in perspective, there's a lot of untapped fields. Tempering that hope a bit, Perl's new thesis really needs to be something that Perl's existing code and community brings something powerful to. If you come up with a possible thesis, but look at it honestly and say "That's probably something better done with a brand new language entirely", it's probably not a functional thesis for Perl. And this does cut the space back somewhat. But some persistent thought may still find something interesting. Personally, I'd also be looking carefully and honestly at what Perl is still doing and consider shedding old use cases/theses. For example, while Python is not experiencing a popularity crisis, consider a hypothetical world in which the only people still using Python were basically NumPy users. It would be a valid choice to move forward with Python development in a way that privileged such use, at the expense of "general purpose" use going forward. I'm not involved enough with Perl to know what that would be, just offering a meta-option to consider. And let me close on what I opened with... this is a good "patch the holes" plan that should be all means moved forward with, to give space to breathe. I'm positive on the plan, not critical of it.

Pet_Ant 6y ago

What exactly is Larry Wall's involvement with Perl anymore? Has he moved entirely to Rakudo (ne Perl 6)?

G3rn0ti 6y ago
Larry Wall designed Perl 6 i.e. Raku and created the original parser. I am not sure if he is still actively working on it. The actual implementations, however, were done by others. So like Lisp or C Raku is actually a specification driven language in contrast to languages like Perl 5, Ruby or Python where the most popular interpreter serves as the specification.
- cygx 6y ago
  Raku is actually a specification driven language That hasn't been true for a while. The test suite is supposed to be canonical, whereas the 'specification' hasn't been kept up to date with language evolution.
  - Pet_Ant 6y ago
    > The test suite is supposed to be canonical, whereas the 'specification' hasn't been kept up to date with language evolution. This is so disappointing. Feels like the language over time has lost everything that made it interesting. PUGS for example.
    - raiph 6y ago
      I hear you feel disappointed, but it is presumably due to someone having misled you due to their misinterpretation of Larry's design. Roast (the Repository Of All Specification Tests) has, for over 20 years in design terms, and 15+ years in reality, been Raku's canonical, machine readable specification that is versionable, branchable, forkable, mergeable, and which is backed by a PL design that envisages its versioning, branching, forking, and merging. So we now have a suite of approaching 200K tests that provide a principled software engineering way to generate a single boolean True|False that a so-called Raku compiler does or does not precisely implement the machine readable specification. Features cannot be removed or added without not only being specified in language, and if appropriate subjected to formal analysis, but also openly discussed and debated, implemented in a branch, hammered on for however long with beta testers trying it out to see if it's worth removing/adding, and only then arriving in the official master branch of roast. This can and has meant there can be up to a 3 year period before changes become official, or, conversely, a 24 hour period for a security patch to become official, and the system guarantees that any risk of breakage is controlled by users. This is a revolutionary level of centralized/distributed digital governance.

eruci 6y ago

You can build anything in any programming language, even byte code/assembly if you're so inclined. What you end up using is the one that can do the job faster. I built a custom web store yesterday entirely in mod Perl in 2 hours flat ( https://store.poidata.xyz https://store.poidata.xyz ). If you can beat that in some other programming language, like Python, by all means, stop using Perl.

einpoklum 6y ago
> What you end up using is the one that can do the job faster. Not necessarily. Maybe you're interested in: * Performance optimization. * Maintainability. * Accessbility to more programmers (= fashion) * Conforming to organization policy on the language to use * Code readability etc. Different target function -> different considerations.
- eruci 6y ago
  Agreed. These are fair points of consideration. In my case though, the main one to consider is speed of development.

iso1210 6y ago

I've got a perl website dating back to 2004 - from before php5 was out - that is still used by hundreds of people a day on an internal system. Works great, the code is deployed by a deb in the same was as it deployed in 2008. Since initial creation, had about 10 hours effort to put in a mobile view for an iphone and blackberry in 2008/9, and maybe 5 hours effort to replace the <object> with <video> a couple of years ago. Update the 3 files, roll the new deb, and away we go for the next forseeable, until the userbase finally decides that the multi-man-year all-singing replacement that's some javascript heavy frontend and microservice backend actually lets them do their job better (which it seems isn't the case from the complaints it gets) Sometimes a tool just works and enables you to get on and do things beneficial to your product.

throwaway0x1 6y ago

The future or Perl: Python

johnisgood 6y ago

I had fun with Perl and Tcl back when I was 14 or something. I think they may have been the first "serious" programming languages I have used.

stinkfoot68 6y ago

Always ignored perl for default *nix toolbox (bash + awk + sed) utilities that were standard and in place 'by default'. These days unless you have python 2 and 3 + 20 python libraries per version on a system you can't count on a developer being productive. Recently I've seen guys drive ssh remote command execution in java - we are falling into fashionable senility.

rurban 6y ago

So they explicitly laid out their plan for further destruction. Not that is unknown, they did it since 5.8 days, since perl6. No plans for explicit improvements as detailed planned in 2002, for perl6. 90% of those goals should be perl5 goals, just not breaking syntax, because it is cool. So their new plan is to follow the perl6 route, breaking syntax, cpan and backwards compatibility, whilst still having not a single clue how to implement those features. OO? They are still completely clueless. Jit? Not even mentioned. Native types, ffi? Not even mentioned. Abstract the parser for macros and grammars? Not even mentioned. Proper signatures? Only on cpan, not in core. And many such features which I already have implemented for perl5/cperl. There is no future, they killed it. Long time ago. Everybody with a little bit of competence already left at around 2005. Just leave it alone, until you can promise something and those plans are believable. The more you do, the more destruction.