9 ms·

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.

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.