12 ms·

The Perl Foundation will now be known as The Perl and Raku Foundation

89 points by Amorymeltzer 4y ago

Kelteseth 4y ago
Honest question: Is anybody using perl for new projects? We have a medium (~100k) codebase written in perl and are actively working to convert it to python.
- rrwo 4y ago
  Yes. At my $work, most of our code is in Perl, roughly a half-million lines of it dating back to the mid-1990s. There's no point in rewriting it in something else, since the cost in resources to do that would outweigh the potential salary savings by hiring cheaper programmers who know Python or C# or whatever. (My experience with some other companies is that they want to move away from Perl because Perl programmers are more expensive, not because it's a worse language.) Likewise, there's no point in starting new projects in another language since we'd then have to hire people people competent in both of those languages. My experience is that people who turn their nose up at "old" tech like Perl are not worth hiring. If they don't care to learn about the technology you are using, then they won't care to learn about your industry or your company's business logic.
  - chrisseaton 4y ago
    Aren't you missing advances in programming language technology (performance, tooling, instrumentation) by sticking with such an old interpreter?
    - kamaal 4y ago
      There's quite a bit of legacy running in our industry. Most of it is not even Perl. Think Java, Jquery, and even Python(2.x) these days. Most shops don't have the budgets for total rewrites, or even partial and gradual rewrites. The way old things die, is that new projects don't get started in those languages. To that end, Perl is something of the past already. It is still a very useful technology for a lot of Unixy work on adhoc tasks. But I doubt people learn Perl the way, they learn Python these days. Older people(including me), call upon Perl for lots of work even till date. This is similar to how people continue to use vim/emacs despite things like vscode. There is always going to be a audience for these tools. But the crowd moves on.
    - mfontani 4y ago
      Perl gets new releases on a yearly cadence. We're now at 5.36 IIRC. A far cry from 5.8 or even 5.10. The new releases usually come with bug fixes, speed-ups, additions to the core language, optional syntax features, etc. The only way one gets to use an "old" interpreter is if they're stuck on an old OS release (i.e. RHEL?) and/or they don't build their own version and use the "system" Perl.
      - jsymolon 4y ago
        >stuck on an old OS release (i.e. RHEL?) and/or they don't build their own version and use the "system" Perl. I build my containers and put Perl right in them. Makes the container a little chubbier but no outside dependencies.
      - deleted 4y ago
        [deleted]
    - rrwo 4y ago
      No. The Perl interpreter has been regular updated and improved. There's a new release of Perl every six months, and the libraries on CPAN provide access to various other kinds of technology and tooling.
      - chrisseaton 4y ago
        Doesn't even have a basic JIT does it? Still using a 90s-era basic interpreter and GC architecture. And there's only one implementation. Doesn't seem very healthy.
        School-Cotton 4y ago
        Python (or at least, the implementation used 99% of the time in the real world) doesn’t have a JIT either, so this property isn’t limited to niche, dying languages.
        chrisseaton 4y ago
        Well yeah compare to Python - Python has multiple alternative implementations, an active academic and industrial research community coming up with new ways to improve performance and add tooling, including revolutionary work such as meta-tracing, has new GC work, has a couple of JITs depending on what tradeoffs you want, new explorations into specialising interpretation. Perl doesn't seem to have anyone making this kind of effort? You're stuck with the tech from decades ago.
        rrwo 4y ago
        The implementation is open source and not owned by a for-profit company that could decide to kill it off in the future. This is a good thing, because it means that we don't have to worry about a program running on one implementation vs another. Also, one of the things that Perl is great for (unlike many other scripting languages) is backwards compatibility. A program written in the 1990s for Perl 5.004 will probably run with minimal modifications on Perl v5.36.
        4y ago
  - vultour 4y ago
    I worked at a place like this and it was a nightmare. We had a few dedicated Perl programmers who swore there was nothing better since sliced bread, but there were so many legacy Perl programs it spilled into everyone's responsibilities. I know for a fact everybody else absolutely hated having to go in and decipher decades old Perl code.
    - rrwo 4y ago
      That's a problem with the codebase at your place of work, not the language.
    - juice_bus 4y ago
      You could replace Perl with any language and people would have the same experience.
      - deleted 4y ago
        [deleted]
      - vultour 4y ago
        Most other "popular" languages share a pretty good chunk of their syntax. You can dig through PHP/Java/C#/Go/Javascript/C++/Python pretty easily if you already know one of them. Perl and its magic variables are absolutely undecipherable if you haven't worked with the language before (or in a long time).
        kamaal 4y ago
        >>Perl and its magic variables are absolutely undecipherable if you haven't worked with the language before (or in a long time). Yeah, either the language gives you magic variables, or you make your own one's in the programs you write. Programming isn't sorcery. Somebody has to write the code for features a language doesn't give you. That the is whole problem in essence, the more minimal your syntax goes, the more code you will write for features the language doesn't give you. Good part about the Perl magic variables is at least they are documented.
        4y ago
  - josephcsible 4y ago
    > people who turn their nose up at "old" tech like Perl The problem with Perl isn't that it's old. It's bad in ways that other old languages aren't. Consider all the people who like C but not Perl, even though C is older.
    - rrwo 4y ago
      Please describe those uniquely bad aspects of Perl that other scripting languages aren't.
  - TheDesolate0 4y ago
- jstanley 4y ago
  I have been using Perl (5) for new projects until very recently (and, realistically, I might still use it in the future). I also did some contracting until very recently for a company whose product makes extensive use of Perl. I've been writing Perl professionally for over 10 years. The backend of my network programming challenge[0] is all Perl daemons, including the web API, the solution checker, leaderboard calculation, and new problem announcement mailing. (The frontend is Next.js, but it's not using any server-side JavaScript, it's delivered as a static site). Perl is good because it is very quick to write. Common idioms are very terse, first-class support for regexes is a superpower, and the TIMTOWTDI philosophy ("there is more than one way to do it" - polar opposite to Python) means you can often find a quick and succinct way to make most small code changes you want to make. I am personally looking to move away from Perl for new projects for the following reasons: 1. Perl doesn't have sensible support for multi-threading. There's "use threads", which is quite heavyweight because (as I understand it) every time you make a new thread with "use threads" it creates a memcpy() of the entire interpreter. There's "use forks", which is the same as "use threads" except it uses fork() so that the "copy" is less expensive (because Linux gives us copy-on-write). "use forks" is still bad because inter-thread communication still involves serialising your data and passing it over a pipe, and you don't necessarily notice where you're doing it. Then there's Coro[1], which is actually very very good, for what it is. Coro allows you to write code in a straight-line synchronous style, but allows you to cede control to other threads when you need to wait for a result to become available. Coro calls itself "the only read threads in Perl", but it's still not real threads in Perl because it still doesn't let you take advantage of more than 1 CPU. In my experience Coro also interacts poorly with XS (i.e. native code) modules that aren't reentrant, and it's difficult to predict when you might be using such a module, and sometimes your Perl scripts will segfault or leak memory through no obvious fault of your own. But Coro is a really neat hack. If you actually want to make use of multiple CPUs, the best option (IMO) is to fork() manually and keep inter-process communication to a minimum. 2. Further than multi-threading, Perl doesn't even have sensible support for async/await style concurrency. The closest thing to async/await style concurrency is AnyEvent[2]. AnyEvent is quite good, and I think is the best way to write asynchronous code in Perl. But it still doesn't hold a candle to basically any modern programming language, because you still have the "callback hell" style of passing closures as an argument to anything that has to be asynchronous. This is extremely annoying and results in enormous, complicated, and error-prone refactors if you ever have to change a component deep in your stack from synchronous to asynchronous. For example, if you are moving away from a hash table "database" to an actual RDBMS, and you don't want your database queries blocking your entire application, this is extremely painful, because everything that lives higher up the stack needs to be rewritten in "callback hell" style. See "What color is your function?" for more on this.[3] 3. Lots of things that should be caught statically don't actually cause problems until runtime. This is mainly because Perl is dynamically typed and isn't compiled, but it is annoying, and avoidable in other languages. What language am I moving to? I don't know yet. Probably Go. I don't like how opinionated Go is about a lot of things that Perl doesn't give a shit about, but it is at least quite small. I don't like Rust because it seems overly bloated (the recommended way to parse command-line arguments - "clap" - involves downloading 140 megabytes of dependencies off crates.io, which just seems unreasonable), although the borrow checker is a very interesting idea. I'm also interested in Zig, but I think the Zig community is possibly too small at the moment, and not being fully memory-safe seems overly risky. But I haven't written enough Zig yet to know whether or not I like it. [0] https://protohackers.com/ https://protohackers.com/ [1] https://metacpan.org/pod/Coro https://metacpan.org/pod/Coro [2] https://metacpan.org/pod/AnyEvent https://metacpan.org/pod/AnyEvent [3] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- rrwo 4y ago
  A better question is: is anyone planning on moving from Perl to Raku, or from Perl to another language? At $work, we're sticking with Perl [reasons elsewhere in this thread]. But if we were going start projects in other languages, it would probably be Python or Node. For personal projects, I'm more interested in Rust than Raku.
  - b112 4y ago
    Python is fairly stable, node is prone to fast change. That is, if python isn't using external dependencies. If you are writing an app for decades long usage, node is probably a bad choice. Perl, python, will be around... well, I dunno, decades more at least. But perl? As someone else said, the code you write now, will work 30 years from now. That's its thing, its happy smile. Imagine, just imagine writing code that doesn't vanish 2 months after you leave a place. Imagine code your great grandkids might tough.
- mfontani 4y ago
  I'm working at an all-Perl place, and I'm about to move to another all-Perl place. Neither has any plans to move off it. The opposite, actually. Like them, there's likely dozens of others. Dozens, I say!
  - thatwasunusual 4y ago
    Where in the world is this? I would actually fancy working with Perl, but here in Norway there's nothing to find. :(
    - mfontani 4y ago
      Look on https://perl.careers https://perl.careers or LinkedIn or https://jobs.perl.org https://jobs.perl.org for remote perl development gigs, and you'll find one sooner or later, assuming you qualify ;-)
    - darrenwestall 4y ago
      I’m hiring, email in my profile :)
- forgotmypw17 4y ago
  I started a new project in Perl, which I've commented on before a couple of times in response to a similar question. One of the main reasons I chose Perl is it's commitment to not introducing breaking changes. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=Perl%20forgotmypw17&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... https://news.ycombinator.com/item?id=31261071 https://news.ycombinator.com/item?id=31261071
- shubhamjain 4y ago
  You're doing God's work. Last I used Perl was ten years ago. I decided to give it another shot for small scripting needs. The ability to write one-liners to do stuff is exciting at first, but my brain isn't used to a language with such a complex grammar. Just the number of ways you can write loops is crazy. Oh btw, is there any other language for which writing BNF isn't impossible? [1] It doesn't help that most of the times, Perl fails with a very confusing error message that can leave you scratching your head. And it seems all the Perl wisdom has gradually vanished with very few answers to your questions. It wasn't a bad language for its time, but with the number of alternatives, I just don't see a valid reason to use it. [1]: https://stackoverflow.com/questions/4625408/where-can-i-find-a-formal-grammar-for-the-perl-programming-language https://stackoverflow.com/questions/4625408/where-can-i-find...
- rurban 4y ago
  I'm using perl as glue tool for a lot of my projects. I could write it in python, but then it would turn into a big hairy monster, and I rather want to keep my tools as tools.
- tasty_freeze 4y ago
  I have a side project at work that I'm doing on evenings/weekends that I've written in perl. One part of it parses verilog source code and builds an AST. It is a recursive descent parser that was written in the most straight-forward way and no time has been spent optimizing it for speed. The AST builder and some auxiliary routines that make interfacing to the AST simpler to manipulate is less than 2500 lines of code and took a couple weekends to write and get working. Surprisingly, I timed the parser part and it took only 0.06 seconds to process a 2500 line file. Yes, perl is 30x slower than C, but computers are so fast that performance (for my needs) doesn't matter too much. To be fair, it is only the subset of verilog that one would typically synthesize (so no events and forks/joins, no timing annotation, etc). Doing the whole language would make the code larger but not much slower.
antiquark 4y ago
Sad how perl self-destructed with perl6.
- chrisseaton 4y ago
  I think it was the victim of changing tastes and fashions more than anything else. People used to appreciate that kind of wackiness and linguistic whimsy. I think these days people want more straightforward and simple tools
  - rrwo 4y ago
    Also, there are many more new languages and newer development framework that have appeared in the last 20+ years.
    - forgotmypw17 4y ago
      I prefer something that's been around for 20+ years without breaking changes to something newer that's already introduced breaking changes multiple times.
  - KingOfCoders 4y ago
    I never liked Perl and had to kill two large Perl projects in the 90s because no one could manage them anymore. I do think before Python there was no real alternative. We tried C for web development but it was a huge pain. The Python CGI module changed everything for us (Reading about it in the German iX magazine)
  - ivix 4y ago
    These days when perl enthusiasts say things like 'its terse' and 'there's more than one way to do it' and 'you can find a quick and short way to do interesting things' the reaction is more of faint nausea than anything else. Probably not what they were going for.
    - chrisseaton 4y ago
geerlingguy 4y ago
Honest question: what is Raku?
- mfontani 4y ago
  The Language Formerly Known As Perl6 - see https://raku.org/ https://raku.org/
  - geerlingguy 4y ago
    Thanks! Interesting that in all the time I've done web and infra dev work (mostly Python, PHP, and Go, sometimes Ruby), I've never heard of Raku, nor knew what happened to Perl after the Perl 5-to-7 thing (also similar with PHP 5-7... though no PHP 6 ever got resurrected).
    - cesarb 4y ago
      > (also similar with PHP 5-7... though no PHP 6 ever got resurrected) There's a profound difference: PHP 6 was never released (it was abandoned before its official release), but Perl 6 was released under the "Perl 6" name (https://developers.slashdot.org/story/15/12/26/0354235/perl-6-released https://developers.slashdot.org/story/15/12/26/0354235/perl-... is one reference, you have to use the web archive to look further since the release history became somewhat hidden after the rename).
StayTrue 4y ago
I miss Perl. I managed a startup that built in Perl and C++ simultaneously. The Perl MVP allowed us to get into customer premises right away and we fed that learning back into the C++ version (on which our acquisition was based). In retrospect we would not have succeeded without Perl. I used it recently to generate reports from analytics and it felt good. If there are remote jobs calling for Perl, send them my way.
- mfontani 4y ago
  Look at https://perl.careers https://perl.careers and/or search for Perl on LinkedIn, or look at https://jobs.perl.org https://jobs.perl.org. Plenty jobs for Perl developers.
- nousermane 4y ago
  Perl has some weird quirks - dollar-variables vs. percent-variables vs. at-variables (and sometimes you can "cast" one into other), round-brackets where most others have squiggly (and vice-versa)... But once you get over that, it's a great language. First-class regex, -pine options. A lot to love about it.
  - bitexploder 4y ago
    Many a Unix environment and production system were held together by Perl glue in the late 90s/early 00s :)
- darrenwestall 4y ago
  I’m hiring - email in my profile if you were serious :)
codeflo 4y ago
There’s one common criticism that I don’t get: That Perl 5 is hard to learn. I have a theory about this, but warning, rant incoming. People used to read programming books. I learned both Perl and C from books; for me Perl wasn’t any harder. Yes, the syntax is unique — but you learned to read weirder things, C++ certainly isn’t any more intuitive in a vacuum. But of course, few people read books anymore, so where do people learn languages? I guess universities and blog posts. (And increasingly YouTube videos, which have even less content density.) Universities only teach old versions of Java. Blog posts are limited in size. Sad conclusion: any language that has more than a blog post’s worth of differences to Java 1.x will find it hard to reach very broad adoption.
- rrwo 4y ago
  I don't think Perl is/was any harder to learn than C. Easier, in fact, since you don't have to worry about making a mistake with pointers. I've not found colleagues who learned Java or C# first have had trouble learning Perl. When they've learned "modern" Perl with Moose/Moo, they've been happy with it.
  - 7thaccount 4y ago
    Perl is a scripting language. To me it's very similar to Python and a Lot easier to learn than something low level like C that doesn't have everything built-in and just available for you.
- woodrowbarlow 4y ago
  people conflate "easy to learn" with "familiar" and it's a shame.
- a-dub 4y ago
  i think that's right. perl is ridiculously easy to learn, it just hasn't been as popular in the stack overflow era. also, i think there's a lot of very old and rotted code out there now that is probably very confusing to try to learn from.
- verelo 4y ago
shubhamjain 4y ago
I am surprised by the number of people here praising Perl. I understand it was useful for its time, but the reason why programmers aren't using it is because it's a crap of a language. Fine, it's pretty crazy how much you can do in Perl with just few lines of code, but who cares about that except you? It's an active struggle to make Perl code readable and it not turning into a mess. Perl not only makes it the syntax difficult with all the absurdities (special variables, so many prefixes $,@,%, terse function names, tens of ways to do one thing), it also makes it impossible to Google. Imagine spending your whole afternoon trying to dig what "($fc) = /^(.)/" does; a maintainer's nightmare. I am not that old but from a little searching, it seems to me Perl always had a bad reputation, and for good reasons.
- dale_glass 4y ago
  > Imagine spending your whole afternoon trying to dig what "($fc) = /^(.)/" does The issue with that is that it's a core part of the language's syntax so how are you going to search for something like that? It's a bit like trying to search what the `Obj foo{3};` means in C++, nothing in the text is a keyword, so it will vary from one program to the next and therefore won't be searchable.
  - shubhamjain 4y ago
    Conventional languages follow a pattern and you can get somewhere because the syntax will seem vaguely familiar if the paradigm is the same. I can guess the code you mentioned is some sort of declaration. Perl deviates too much at times and the numbers of choices is seriously high, which makes the job considerably difficult.
    - BaseballPhysics 4y ago
      > Conventional languages follow a pattern and you can get somewhere because the syntax will seem vaguely familiar if the paradigm is the same. Got it, so all languages should look kinda similar so you don't actually have to learn them to grok the code. Let me guess, you also dislike Lisp, Smalltalk, and Haskell?
photochemsyn 4y ago
As someone who started off with Python / C++ (don't blame me, blame current CS teaching programs), Perl's syntax is a bit off-putting. However, learning simpler Unix tools - i.e. grep, sed and awk - is worth the trouble, as those are very useful tools for command line tasks, and work with pipes. Also, that's where Perl seem to have got its syntax from, so if you ever do have to dig into Perl code, it won't be as difficult: http://www.wellho.net/mouth/3902_Shell-Grep-Sed-Awk-Perl-Python-which-to-use-when-.html http://www.wellho.net/mouth/3902_Shell-Grep-Sed-Awk-Perl-Pyt... However, using Python's re module for regular expression matching results in far more readable code than any of the predecessors, particularly as expressions get more complex.
- kamaal 4y ago
  >>Perl's syntax is a bit off-putting. Not sure which parts of Perl syntax you find off putting, but I could guess. 1. Sigils: Why is this bad? Perl has symbols do represent lists(@), associative arrays(%), scalars($). This is actually more readable than Python's approach where there is no symbol to indicate things. The only place where symbol pollution gets out of hand is where you need nested structures. But even there having explicit indication of what's what is better than leaving programmer guessing. Note how this is a program design problem, than a problem with the language itself. To me the only time I deal with this when I'm parsing XMLs and JSONs. Nothing much can be done there because XMLs and JSONs themselves are nested structures. 2. Regular expressions: How else would you represent regular expressions? Do you want Java style string.matchAtStart('x') .matchAtEnd('.') .dontMatchImmediatelyStart(...) .noAlphaNumericChars(...) .exceptChars(...) ... ... See how verbose this gets and very hard to read, it's really the equivalent attempting to do math in words than symbols. 3. References: There are places where you are better of passing a reference to some data, than passing the data itself, for obvious performance and efficiency reasons. 4. Quote words, expressions: Very useful for rapid scripting, and adding data without having it to massage it to a program's syntax. 5. Text utilities: Like chomp, tr, grep. Make it very easy for Unixy work. Why are these even issues? Perl also contains your regular list manipulation utilities, and OO features. Overall very useful. Not sure where this 'hard to read syntax' thing comes from. >>However, learning simpler Unix tools - i.e. grep, sed and awk - is worth the trouble, as those are very useful tools for command line tasks, and work with pipes. There are lots of limitation with those tools, you can't do work with several files. You don't get error handling. You are stuck with a paradigm of working on line/block at a time. You can't do other stuff like make Rest API calls. You can't do XML/JSON stuff, the list goes endless because they are not by definition regular programming languages. In fact Perl exists to address these limitations. >>However, using Python's re module for regular expression matching results in far more readable code than any of the predecessors, particularly as expressions get more complex. No Python got famous, because its users never worked with messy early internet work. Like having to deal with multiple data formats, log files, API responses, database work with no standard data exchange formats. Perl lost a lot of its utility when JSON and XMLs became ubiquitous. And yeah Python was never big in Unix world either. Its main use was for developing web apps(Django, Twisted Matrix etc). For that even today Python is bad at anything which has non trivial data work.
fipar 4y ago
Perl has a fond place in my heart, though I don't use it for new things, but I still like it (some 20+ years ago I proudly wore a t-shirt with a square block of perl code in the back that, should you type it and run it, would print a quote by Larry Wall. This shirt: https://www.flickr.com/photos/codepo8/489597488 https://www.flickr.com/photos/codepo8/489597488 - not my pic). That said, having had to deal with perl professionally a few times in the last 10 years, the biggest drawbacks I find in it for larger-scale projects are: - A lot of people are perl programmers, not programmers. I'm not tied to any language, believe in using the best tool for a job, and believe in using a language I'm not a big fan of if that makes it easier for a wider team. A lot of perl programmers I met don't feel the same and (wrongly, IMHO) think perl is the best language for every use case out there. - It's lacking in instrumentation when compared to other languages and VMs. It's more challenging to debug production problems with perl than with, say, C (and that should say a lot...) - There's no reliable way to limit resource usage of programs, which can be very bad when running on servers. Even worse if your perl code shares the server with other code. I think that's one of the reasons new Percona Toolkit tools are written in Go and not perl (but I could be wrong). It can be dangerous to run some perl scripts on a database server, for example. I suppose cgroups/containers/etc can help there, but only in a circuit-breaker way: I don't think there's an easy way for one to write perl code that can keep its resource usage under a predefined limit and still continue to work when the limit is reached. - Kind of like lisp, a lot of the power in perl also means that if a team is not tight and some coding standards are agreed upon, you end up with multiple custom languages sharing a codebase. Something like python takes care of this because there's usually a single way to do something. That also makes it more boring from a programming language perspective (to some people, to any extent) but as engineers our role is not to do cool, fun, and interesting things; we need to solve problems in a reliable and predictable way. Think of the people who carry a pager and will be waken up when there's a problem involving your code, even if that's you (your 3 AM self will thank your 2 PM self for not being clever with the hacks, trust me). That said, I'm happy the ecosystem seems healthy, I'm glad we have languages like perl that let you take a 25 year old script and run it today without changes. And reading all the people on this thread that work on perl, if it works for you and you get to make a living off of the language you love: cheers to you, and I'm sure there'll be job openings for perl programmers for at least another 2 to 3 decades.
psadri 4y ago
Perl shines once you start using all its thoughtful but quirky features and shortcuts. Eg iirmc, how $_’s value always makes sense given the the surrounding context. Those people who get there tend to become Perl diehard fans. You only get to appreciate that once you invest a fair bit of time writing Perl code. In the heyday of Perl, a lot of people got there because frankly there few other options. Today, there are lots of scripting language options that are arguable easier to pick up so far fewer people reach Perl Nirvana. I do have to say I miss how Perl modules have sensible names that at least try to describe what they generally do.
bachmeier 4y ago
I don't mind Perl, and I like that it's installed on every Linux distribution I'd ever use by default. The problem I have is that I find it unpleasant to work with text files. Examples: https://perlmaven.com/open-and-read-from-files https://perlmaven.com/open-and-read-from-files https://stackoverflow.com/questions/1045792/how-can-i-list-all-of-the-files-in-a-directory-with-perl https://stackoverflow.com/questions/1045792/how-can-i-list-a... I simply cannot remember that stuff, and frankly it's too much hassle. I want to make one call to a simple, built-in function to load a text file, and similarly for looping over the files in a directory. I find Bash plus other Linux tools to be easier than Perl, even though most everything else is easier in Perl.
- Zhyl 4y ago
  I actually find this one of the easier things with Perl. Just add one `while` loop over the diamond operator and then pass the files to it via bash globbing.
  - BaseballPhysics 4y ago
    Agreed, I find the GP comment kind of bizarre. Like, the thing Perl is truly great at is processing text files. Hell, it's one of the main reasons I use it (that and as a general replacement for shell scripting when I need to do anything moderately complex). And if you really wanna deal with files and directories, IO::File and IO::Dir are easier interfaces to work with and there's plenty of other helper modules out there. I'd never use the base primitives as described in that article. Mix in File::Find or equivalent and Perl is incredible for file handling.
- darrenf 4y ago
  Path::Tiny really is your friend here. https://metacpan.org/pod/Path::Tiny https://metacpan.org/pod/Path::Tiny
TheDesolate0 4y ago

89 points by Amorymeltzer 4y ago

Honest question: Is anybody using perl for new projects? We have a medium (~100k) codebase written in perl and are actively working to convert it to python.

rrwo 4y ago
Yes. At my $work, most of our code is in Perl, roughly a half-million lines of it dating back to the mid-1990s. There's no point in rewriting it in something else, since the cost in resources to do that would outweigh the potential salary savings by hiring cheaper programmers who know Python or C# or whatever. (My experience with some other companies is that they want to move away from Perl because Perl programmers are more expensive, not because it's a worse language.) Likewise, there's no point in starting new projects in another language since we'd then have to hire people people competent in both of those languages. My experience is that people who turn their nose up at "old" tech like Perl are not worth hiring. If they don't care to learn about the technology you are using, then they won't care to learn about your industry or your company's business logic.
- chrisseaton 4y ago
  Aren't you missing advances in programming language technology (performance, tooling, instrumentation) by sticking with such an old interpreter?
  - kamaal 4y ago
    There's quite a bit of legacy running in our industry. Most of it is not even Perl. Think Java, Jquery, and even Python(2.x) these days. Most shops don't have the budgets for total rewrites, or even partial and gradual rewrites. The way old things die, is that new projects don't get started in those languages. To that end, Perl is something of the past already. It is still a very useful technology for a lot of Unixy work on adhoc tasks. But I doubt people learn Perl the way, they learn Python these days. Older people(including me), call upon Perl for lots of work even till date. This is similar to how people continue to use vim/emacs despite things like vscode. There is always going to be a audience for these tools. But the crowd moves on.
  - mfontani 4y ago
    Perl gets new releases on a yearly cadence. We're now at 5.36 IIRC. A far cry from 5.8 or even 5.10. The new releases usually come with bug fixes, speed-ups, additions to the core language, optional syntax features, etc. The only way one gets to use an "old" interpreter is if they're stuck on an old OS release (i.e. RHEL?) and/or they don't build their own version and use the "system" Perl.
    - jsymolon 4y ago
      >stuck on an old OS release (i.e. RHEL?) and/or they don't build their own version and use the "system" Perl. I build my containers and put Perl right in them. Makes the container a little chubbier but no outside dependencies.
    - deleted 4y ago
      [deleted]
  - rrwo 4y ago
    No. The Perl interpreter has been regular updated and improved. There's a new release of Perl every six months, and the libraries on CPAN provide access to various other kinds of technology and tooling.
    - chrisseaton 4y ago
      Doesn't even have a basic JIT does it? Still using a 90s-era basic interpreter and GC architecture. And there's only one implementation. Doesn't seem very healthy.
      - School-Cotton 4y ago
        Python (or at least, the implementation used 99% of the time in the real world) doesn’t have a JIT either, so this property isn’t limited to niche, dying languages.
        chrisseaton 4y ago
        Well yeah compare to Python - Python has multiple alternative implementations, an active academic and industrial research community coming up with new ways to improve performance and add tooling, including revolutionary work such as meta-tracing, has new GC work, has a couple of JITs depending on what tradeoffs you want, new explorations into specialising interpretation. Perl doesn't seem to have anyone making this kind of effort? You're stuck with the tech from decades ago.
      - rrwo 4y ago
        The implementation is open source and not owned by a for-profit company that could decide to kill it off in the future. This is a good thing, because it means that we don't have to worry about a program running on one implementation vs another. Also, one of the things that Perl is great for (unlike many other scripting languages) is backwards compatibility. A program written in the 1990s for Perl 5.004 will probably run with minimal modifications on Perl v5.36.
        4y ago
- vultour 4y ago
  I worked at a place like this and it was a nightmare. We had a few dedicated Perl programmers who swore there was nothing better since sliced bread, but there were so many legacy Perl programs it spilled into everyone's responsibilities. I know for a fact everybody else absolutely hated having to go in and decipher decades old Perl code.
  - rrwo 4y ago
    That's a problem with the codebase at your place of work, not the language.
  - juice_bus 4y ago
    You could replace Perl with any language and people would have the same experience.
    - deleted 4y ago
      [deleted]
    - vultour 4y ago
      Most other "popular" languages share a pretty good chunk of their syntax. You can dig through PHP/Java/C#/Go/Javascript/C++/Python pretty easily if you already know one of them. Perl and its magic variables are absolutely undecipherable if you haven't worked with the language before (or in a long time).
      - kamaal 4y ago
        >>Perl and its magic variables are absolutely undecipherable if you haven't worked with the language before (or in a long time). Yeah, either the language gives you magic variables, or you make your own one's in the programs you write. Programming isn't sorcery. Somebody has to write the code for features a language doesn't give you. That the is whole problem in essence, the more minimal your syntax goes, the more code you will write for features the language doesn't give you. Good part about the Perl magic variables is at least they are documented.
      - 4y ago
- josephcsible 4y ago
  > people who turn their nose up at "old" tech like Perl The problem with Perl isn't that it's old. It's bad in ways that other old languages aren't. Consider all the people who like C but not Perl, even though C is older.
  - rrwo 4y ago
    Please describe those uniquely bad aspects of Perl that other scripting languages aren't.
- TheDesolate0 4y ago
jstanley 4y ago
I have been using Perl (5) for new projects until very recently (and, realistically, I might still use it in the future). I also did some contracting until very recently for a company whose product makes extensive use of Perl. I've been writing Perl professionally for over 10 years. The backend of my network programming challenge[0] is all Perl daemons, including the web API, the solution checker, leaderboard calculation, and new problem announcement mailing. (The frontend is Next.js, but it's not using any server-side JavaScript, it's delivered as a static site). Perl is good because it is very quick to write. Common idioms are very terse, first-class support for regexes is a superpower, and the TIMTOWTDI philosophy ("there is more than one way to do it" - polar opposite to Python) means you can often find a quick and succinct way to make most small code changes you want to make. I am personally looking to move away from Perl for new projects for the following reasons: 1. Perl doesn't have sensible support for multi-threading. There's "use threads", which is quite heavyweight because (as I understand it) every time you make a new thread with "use threads" it creates a memcpy() of the entire interpreter. There's "use forks", which is the same as "use threads" except it uses fork() so that the "copy" is less expensive (because Linux gives us copy-on-write). "use forks" is still bad because inter-thread communication still involves serialising your data and passing it over a pipe, and you don't necessarily notice where you're doing it. Then there's Coro[1], which is actually very very good, for what it is. Coro allows you to write code in a straight-line synchronous style, but allows you to cede control to other threads when you need to wait for a result to become available. Coro calls itself "the only read threads in Perl", but it's still not real threads in Perl because it still doesn't let you take advantage of more than 1 CPU. In my experience Coro also interacts poorly with XS (i.e. native code) modules that aren't reentrant, and it's difficult to predict when you might be using such a module, and sometimes your Perl scripts will segfault or leak memory through no obvious fault of your own. But Coro is a really neat hack. If you actually want to make use of multiple CPUs, the best option (IMO) is to fork() manually and keep inter-process communication to a minimum. 2. Further than multi-threading, Perl doesn't even have sensible support for async/await style concurrency. The closest thing to async/await style concurrency is AnyEvent[2]. AnyEvent is quite good, and I think is the best way to write asynchronous code in Perl. But it still doesn't hold a candle to basically any modern programming language, because you still have the "callback hell" style of passing closures as an argument to anything that has to be asynchronous. This is extremely annoying and results in enormous, complicated, and error-prone refactors if you ever have to change a component deep in your stack from synchronous to asynchronous. For example, if you are moving away from a hash table "database" to an actual RDBMS, and you don't want your database queries blocking your entire application, this is extremely painful, because everything that lives higher up the stack needs to be rewritten in "callback hell" style. See "What color is your function?" for more on this.[3] 3. Lots of things that should be caught statically don't actually cause problems until runtime. This is mainly because Perl is dynamically typed and isn't compiled, but it is annoying, and avoidable in other languages. What language am I moving to? I don't know yet. Probably Go. I don't like how opinionated Go is about a lot of things that Perl doesn't give a shit about, but it is at least quite small. I don't like Rust because it seems overly bloated (the recommended way to parse command-line arguments - "clap" - involves downloading 140 megabytes of dependencies off crates.io, which just seems unreasonable), although the borrow checker is a very interesting idea. I'm also interested in Zig, but I think the Zig community is possibly too small at the moment, and not being fully memory-safe seems overly risky. But I haven't written enough Zig yet to know whether or not I like it. [0] https://protohackers.com/ https://protohackers.com/ [1] https://metacpan.org/pod/Coro https://metacpan.org/pod/Coro [2] https://metacpan.org/pod/AnyEvent https://metacpan.org/pod/AnyEvent [3] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
rrwo 4y ago
A better question is: is anyone planning on moving from Perl to Raku, or from Perl to another language? At $work, we're sticking with Perl [reasons elsewhere in this thread]. But if we were going start projects in other languages, it would probably be Python or Node. For personal projects, I'm more interested in Rust than Raku.
- b112 4y ago
  Python is fairly stable, node is prone to fast change. That is, if python isn't using external dependencies. If you are writing an app for decades long usage, node is probably a bad choice. Perl, python, will be around... well, I dunno, decades more at least. But perl? As someone else said, the code you write now, will work 30 years from now. That's its thing, its happy smile. Imagine, just imagine writing code that doesn't vanish 2 months after you leave a place. Imagine code your great grandkids might tough.
mfontani 4y ago
I'm working at an all-Perl place, and I'm about to move to another all-Perl place. Neither has any plans to move off it. The opposite, actually. Like them, there's likely dozens of others. Dozens, I say!
- thatwasunusual 4y ago
  Where in the world is this? I would actually fancy working with Perl, but here in Norway there's nothing to find. :(
  - mfontani 4y ago
    Look on https://perl.careers https://perl.careers or LinkedIn or https://jobs.perl.org https://jobs.perl.org for remote perl development gigs, and you'll find one sooner or later, assuming you qualify ;-)
  - darrenwestall 4y ago
    I’m hiring, email in my profile :)
forgotmypw17 4y ago
I started a new project in Perl, which I've commented on before a couple of times in response to a similar question. One of the main reasons I chose Perl is it's commitment to not introducing breaking changes. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=Perl%20forgotmypw17&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... https://news.ycombinator.com/item?id=31261071 https://news.ycombinator.com/item?id=31261071
shubhamjain 4y ago
You're doing God's work. Last I used Perl was ten years ago. I decided to give it another shot for small scripting needs. The ability to write one-liners to do stuff is exciting at first, but my brain isn't used to a language with such a complex grammar. Just the number of ways you can write loops is crazy. Oh btw, is there any other language for which writing BNF isn't impossible? [1] It doesn't help that most of the times, Perl fails with a very confusing error message that can leave you scratching your head. And it seems all the Perl wisdom has gradually vanished with very few answers to your questions. It wasn't a bad language for its time, but with the number of alternatives, I just don't see a valid reason to use it. [1]: https://stackoverflow.com/questions/4625408/where-can-i-find-a-formal-grammar-for-the-perl-programming-language https://stackoverflow.com/questions/4625408/where-can-i-find...
rurban 4y ago
I'm using perl as glue tool for a lot of my projects. I could write it in python, but then it would turn into a big hairy monster, and I rather want to keep my tools as tools.
tasty_freeze 4y ago
I have a side project at work that I'm doing on evenings/weekends that I've written in perl. One part of it parses verilog source code and builds an AST. It is a recursive descent parser that was written in the most straight-forward way and no time has been spent optimizing it for speed. The AST builder and some auxiliary routines that make interfacing to the AST simpler to manipulate is less than 2500 lines of code and took a couple weekends to write and get working. Surprisingly, I timed the parser part and it took only 0.06 seconds to process a 2500 line file. Yes, perl is 30x slower than C, but computers are so fast that performance (for my needs) doesn't matter too much. To be fair, it is only the subset of verilog that one would typically synthesize (so no events and forks/joins, no timing annotation, etc). Doing the whole language would make the code larger but not much slower.

antiquark 4y ago

Sad how perl self-destructed with perl6.

chrisseaton 4y ago
I think it was the victim of changing tastes and fashions more than anything else. People used to appreciate that kind of wackiness and linguistic whimsy. I think these days people want more straightforward and simple tools
- rrwo 4y ago
  Also, there are many more new languages and newer development framework that have appeared in the last 20+ years.
  - forgotmypw17 4y ago
    I prefer something that's been around for 20+ years without breaking changes to something newer that's already introduced breaking changes multiple times.
- KingOfCoders 4y ago
  I never liked Perl and had to kill two large Perl projects in the 90s because no one could manage them anymore. I do think before Python there was no real alternative. We tried C for web development but it was a huge pain. The Python CGI module changed everything for us (Reading about it in the German iX magazine)
- ivix 4y ago
  These days when perl enthusiasts say things like 'its terse' and 'there's more than one way to do it' and 'you can find a quick and short way to do interesting things' the reaction is more of faint nausea than anything else. Probably not what they were going for.
  - chrisseaton 4y ago

geerlingguy 4y ago

Honest question: what is Raku?

mfontani 4y ago
The Language Formerly Known As Perl6 - see https://raku.org/ https://raku.org/
- geerlingguy 4y ago
  Thanks! Interesting that in all the time I've done web and infra dev work (mostly Python, PHP, and Go, sometimes Ruby), I've never heard of Raku, nor knew what happened to Perl after the Perl 5-to-7 thing (also similar with PHP 5-7... though no PHP 6 ever got resurrected).
  - cesarb 4y ago
    > (also similar with PHP 5-7... though no PHP 6 ever got resurrected) There's a profound difference: PHP 6 was never released (it was abandoned before its official release), but Perl 6 was released under the "Perl 6" name (https://developers.slashdot.org/story/15/12/26/0354235/perl-6-released https://developers.slashdot.org/story/15/12/26/0354235/perl-... is one reference, you have to use the web archive to look further since the release history became somewhat hidden after the rename).

StayTrue 4y ago

I miss Perl. I managed a startup that built in Perl and C++ simultaneously. The Perl MVP allowed us to get into customer premises right away and we fed that learning back into the C++ version (on which our acquisition was based). In retrospect we would not have succeeded without Perl. I used it recently to generate reports from analytics and it felt good. If there are remote jobs calling for Perl, send them my way.

mfontani 4y ago
Look at https://perl.careers https://perl.careers and/or search for Perl on LinkedIn, or look at https://jobs.perl.org https://jobs.perl.org. Plenty jobs for Perl developers.
nousermane 4y ago
Perl has some weird quirks - dollar-variables vs. percent-variables vs. at-variables (and sometimes you can "cast" one into other), round-brackets where most others have squiggly (and vice-versa)... But once you get over that, it's a great language. First-class regex, -pine options. A lot to love about it.
- bitexploder 4y ago
  Many a Unix environment and production system were held together by Perl glue in the late 90s/early 00s :)
darrenwestall 4y ago
I’m hiring - email in my profile if you were serious :)

codeflo 4y ago

There’s one common criticism that I don’t get: That Perl 5 is hard to learn. I have a theory about this, but warning, rant incoming. People used to read programming books. I learned both Perl and C from books; for me Perl wasn’t any harder. Yes, the syntax is unique — but you learned to read weirder things, C++ certainly isn’t any more intuitive in a vacuum. But of course, few people read books anymore, so where do people learn languages? I guess universities and blog posts. (And increasingly YouTube videos, which have even less content density.) Universities only teach old versions of Java. Blog posts are limited in size. Sad conclusion: any language that has more than a blog post’s worth of differences to Java 1.x will find it hard to reach very broad adoption.

rrwo 4y ago
I don't think Perl is/was any harder to learn than C. Easier, in fact, since you don't have to worry about making a mistake with pointers. I've not found colleagues who learned Java or C# first have had trouble learning Perl. When they've learned "modern" Perl with Moose/Moo, they've been happy with it.
- 7thaccount 4y ago
  Perl is a scripting language. To me it's very similar to Python and a Lot easier to learn than something low level like C that doesn't have everything built-in and just available for you.
woodrowbarlow 4y ago
people conflate "easy to learn" with "familiar" and it's a shame.
a-dub 4y ago
i think that's right. perl is ridiculously easy to learn, it just hasn't been as popular in the stack overflow era. also, i think there's a lot of very old and rotted code out there now that is probably very confusing to try to learn from.
verelo 4y ago

shubhamjain 4y ago

I am surprised by the number of people here praising Perl. I understand it was useful for its time, but the reason why programmers aren't using it is because it's a crap of a language. Fine, it's pretty crazy how much you can do in Perl with just few lines of code, but who cares about that except you? It's an active struggle to make Perl code readable and it not turning into a mess. Perl not only makes it the syntax difficult with all the absurdities (special variables, so many prefixes $,@,%, terse function names, tens of ways to do one thing), it also makes it impossible to Google. Imagine spending your whole afternoon trying to dig what "($fc) = /^(.)/" does; a maintainer's nightmare. I am not that old but from a little searching, it seems to me Perl always had a bad reputation, and for good reasons.

dale_glass 4y ago
> Imagine spending your whole afternoon trying to dig what "($fc) = /^(.)/" does The issue with that is that it's a core part of the language's syntax so how are you going to search for something like that? It's a bit like trying to search what the `Obj foo{3};` means in C++, nothing in the text is a keyword, so it will vary from one program to the next and therefore won't be searchable.
- shubhamjain 4y ago
  Conventional languages follow a pattern and you can get somewhere because the syntax will seem vaguely familiar if the paradigm is the same. I can guess the code you mentioned is some sort of declaration. Perl deviates too much at times and the numbers of choices is seriously high, which makes the job considerably difficult.
  - BaseballPhysics 4y ago
    > Conventional languages follow a pattern and you can get somewhere because the syntax will seem vaguely familiar if the paradigm is the same. Got it, so all languages should look kinda similar so you don't actually have to learn them to grok the code. Let me guess, you also dislike Lisp, Smalltalk, and Haskell?

photochemsyn 4y ago

As someone who started off with Python / C++ (don't blame me, blame current CS teaching programs), Perl's syntax is a bit off-putting. However, learning simpler Unix tools - i.e. grep, sed and awk - is worth the trouble, as those are very useful tools for command line tasks, and work with pipes. Also, that's where Perl seem to have got its syntax from, so if you ever do have to dig into Perl code, it won't be as difficult: http://www.wellho.net/mouth/3902_Shell-Grep-Sed-Awk-Perl-Python-which-to-use-when-.html http://www.wellho.net/mouth/3902_Shell-Grep-Sed-Awk-Perl-Pyt... However, using Python's re module for regular expression matching results in far more readable code than any of the predecessors, particularly as expressions get more complex.

kamaal 4y ago
>>Perl's syntax is a bit off-putting. Not sure which parts of Perl syntax you find off putting, but I could guess. 1. Sigils: Why is this bad? Perl has symbols do represent lists(@), associative arrays(%), scalars($). This is actually more readable than Python's approach where there is no symbol to indicate things. The only place where symbol pollution gets out of hand is where you need nested structures. But even there having explicit indication of what's what is better than leaving programmer guessing. Note how this is a program design problem, than a problem with the language itself. To me the only time I deal with this when I'm parsing XMLs and JSONs. Nothing much can be done there because XMLs and JSONs themselves are nested structures. 2. Regular expressions: How else would you represent regular expressions? Do you want Java style string.matchAtStart('x') .matchAtEnd('.') .dontMatchImmediatelyStart(...) .noAlphaNumericChars(...) .exceptChars(...) ... ... See how verbose this gets and very hard to read, it's really the equivalent attempting to do math in words than symbols. 3. References: There are places where you are better of passing a reference to some data, than passing the data itself, for obvious performance and efficiency reasons. 4. Quote words, expressions: Very useful for rapid scripting, and adding data without having it to massage it to a program's syntax. 5. Text utilities: Like chomp, tr, grep. Make it very easy for Unixy work. Why are these even issues? Perl also contains your regular list manipulation utilities, and OO features. Overall very useful. Not sure where this 'hard to read syntax' thing comes from. >>However, learning simpler Unix tools - i.e. grep, sed and awk - is worth the trouble, as those are very useful tools for command line tasks, and work with pipes. There are lots of limitation with those tools, you can't do work with several files. You don't get error handling. You are stuck with a paradigm of working on line/block at a time. You can't do other stuff like make Rest API calls. You can't do XML/JSON stuff, the list goes endless because they are not by definition regular programming languages. In fact Perl exists to address these limitations. >>However, using Python's re module for regular expression matching results in far more readable code than any of the predecessors, particularly as expressions get more complex. No Python got famous, because its users never worked with messy early internet work. Like having to deal with multiple data formats, log files, API responses, database work with no standard data exchange formats. Perl lost a lot of its utility when JSON and XMLs became ubiquitous. And yeah Python was never big in Unix world either. Its main use was for developing web apps(Django, Twisted Matrix etc). For that even today Python is bad at anything which has non trivial data work.

fipar 4y ago

Perl has a fond place in my heart, though I don't use it for new things, but I still like it (some 20+ years ago I proudly wore a t-shirt with a square block of perl code in the back that, should you type it and run it, would print a quote by Larry Wall. This shirt: https://www.flickr.com/photos/codepo8/489597488 https://www.flickr.com/photos/codepo8/489597488 - not my pic). That said, having had to deal with perl professionally a few times in the last 10 years, the biggest drawbacks I find in it for larger-scale projects are: - A lot of people are perl programmers, not programmers. I'm not tied to any language, believe in using the best tool for a job, and believe in using a language I'm not a big fan of if that makes it easier for a wider team. A lot of perl programmers I met don't feel the same and (wrongly, IMHO) think perl is the best language for every use case out there. - It's lacking in instrumentation when compared to other languages and VMs. It's more challenging to debug production problems with perl than with, say, C (and that should say a lot...) - There's no reliable way to limit resource usage of programs, which can be very bad when running on servers. Even worse if your perl code shares the server with other code. I think that's one of the reasons new Percona Toolkit tools are written in Go and not perl (but I could be wrong). It can be dangerous to run some perl scripts on a database server, for example. I suppose cgroups/containers/etc can help there, but only in a circuit-breaker way: I don't think there's an easy way for one to write perl code that can keep its resource usage under a predefined limit and still continue to work when the limit is reached. - Kind of like lisp, a lot of the power in perl also means that if a team is not tight and some coding standards are agreed upon, you end up with multiple custom languages sharing a codebase. Something like python takes care of this because there's usually a single way to do something. That also makes it more boring from a programming language perspective (to some people, to any extent) but as engineers our role is not to do cool, fun, and interesting things; we need to solve problems in a reliable and predictable way. Think of the people who carry a pager and will be waken up when there's a problem involving your code, even if that's you (your 3 AM self will thank your 2 PM self for not being clever with the hacks, trust me). That said, I'm happy the ecosystem seems healthy, I'm glad we have languages like perl that let you take a 25 year old script and run it today without changes. And reading all the people on this thread that work on perl, if it works for you and you get to make a living off of the language you love: cheers to you, and I'm sure there'll be job openings for perl programmers for at least another 2 to 3 decades.

psadri 4y ago

Perl shines once you start using all its thoughtful but quirky features and shortcuts. Eg iirmc, how $_’s value always makes sense given the the surrounding context. Those people who get there tend to become Perl diehard fans. You only get to appreciate that once you invest a fair bit of time writing Perl code. In the heyday of Perl, a lot of people got there because frankly there few other options. Today, there are lots of scripting language options that are arguable easier to pick up so far fewer people reach Perl Nirvana. I do have to say I miss how Perl modules have sensible names that at least try to describe what they generally do.

bachmeier 4y ago

I don't mind Perl, and I like that it's installed on every Linux distribution I'd ever use by default. The problem I have is that I find it unpleasant to work with text files. Examples: https://perlmaven.com/open-and-read-from-files https://perlmaven.com/open-and-read-from-files https://stackoverflow.com/questions/1045792/how-can-i-list-all-of-the-files-in-a-directory-with-perl https://stackoverflow.com/questions/1045792/how-can-i-list-a... I simply cannot remember that stuff, and frankly it's too much hassle. I want to make one call to a simple, built-in function to load a text file, and similarly for looping over the files in a directory. I find Bash plus other Linux tools to be easier than Perl, even though most everything else is easier in Perl.

Zhyl 4y ago
I actually find this one of the easier things with Perl. Just add one `while` loop over the diamond operator and then pass the files to it via bash globbing.
- BaseballPhysics 4y ago
  Agreed, I find the GP comment kind of bizarre. Like, the thing Perl is truly great at is processing text files. Hell, it's one of the main reasons I use it (that and as a general replacement for shell scripting when I need to do anything moderately complex). And if you really wanna deal with files and directories, IO::File and IO::Dir are easier interfaces to work with and there's plenty of other helper modules out there. I'd never use the base primitives as described in that article. Mix in File::Find or equivalent and Perl is incredible for file handling.
darrenf 4y ago
Path::Tiny really is your friend here. https://metacpan.org/pod/Path::Tiny https://metacpan.org/pod/Path::Tiny

TheDesolate0 4y ago