39 ms·
Are there any circumstances where starting a new project with perl makes sense today? I am curious because I only encountered perl in legacy codebases.
by metayrnc 2y ago
Are there any circumstances where starting a new project with perl makes sense today? I am curious because I only encountered perl in legacy codebases.
- kukkamario 2y agoAll Perl code I have ever seen, has been "write-only". Just completely unreadable and it was easier to just look at the output instead of the code when converting it to Python to get actual maintainability.
- Kelteseth 2y agoYou are getting downvoted, but for me, it is the same experience. It's a dead language, and we are switching to Python, that is far better to maintain for me and for all our new hires. I mean, Perl doesn't even has a debugger on Windows.
- hpcjoe 2y agoNot true by any stretch. I've used komodo[1] for more than 2 decades as a debugger in Linux, Mac, and Windows. More recently VSCode on all 3, for debugging. Definitely not a dead language. A mature and stable language, which won't surprise you. [1] https://www.activestate.com/products/komodo-ide/ https://www.activestate.com/products/komodo-ide/
- oldpersonintx 2y agosure! 1. you like perl and enjoy coding with it 2. you are good with perl so internet criticisms don't impact your decision 3. you don't care about contributions from other people
- phplovesong 2y agoI guess if the team is (only?) familiar with Perl. But then again, its the same with PHP. Even IF you know PHP you would not pick it over the more modern alternatives in 2024. I guess some people just want to stick with what they know, and refuse to learn anything new.
- victorbjorklund 2y agoWhats wrong with PHP with laravel for a web project? How is it worse than say python with django?
- 7bit 2y agoNothing is wrong. Commenter is generalizing and shelling out "hot" takes
- Sakos 2y agoI think there are worse things than modern PHP (speaking as somebody whose primary contact with PHP is being traumatized by legacy PHP 7 projects). Afaik, the only places that will start a new PHP application today are places where the expertise is in PHP and Laravel/Symfony. I don't see a big enough benefit from migrating to a whole new stack that wouldn't be accomplished by some focused maintenance and refactoring if you're already working with PHP 8.1.
- 7bit 2y ago> Even IF you know PHP you would not pick it over the more modern alternatives in 2024. That really depends on the use-case. If you need a batteries-included web framework, the top 3 that come to mind are Spring (Java), Django (Python) and Laravel (PHP). And Laravel is a very good framework.
- chuckadams 2y agoLet's not forget Symfony, the foundation that at least half of PHP frameworks including Laravel are based on.
- lordgroff 2y agoI run a WordPress site for my wife's business. Would I pick it up again in 2024? Absolutely. It has nothing to do with what I "know", there's still no better CMS/ small diy e-commerce solution for, frankly, peanuts in hosting. I really don't have much issue with modern PHP either, it gets the job done and unlike Perl is still very much evolving.
- ajsnigrutin 2y agoYeah, it's stable. I have perl stuff written literally 20 years ago, that still works without issues, even on modern computers. If you need something to do the job and in ten years be called "legacy codebase", then do it in perl... because if you did it in python, you'd have to fix the 2.6->2.7 stuff, then 2.7->3.x stuff, and maybe even more than that. If you did what people here on HN like, so, use a 'language of the day', you'd have code written in ruby (now rust or go or whatever), which very few machines have installed by default now.
- helf 2y agoAnd you can tell based off all the other comments on here that you and I are in the minority on liking that it's stable. Even with all its faults. I, too, have 20 year old perl scripts that still run fine. I randomly have to bang my head on my desk over bs with python and php incompatibilities between versions. Pets perl
- nocman 2y agoNo, you are not alone. Over 25 years of Perl experience. Still writing new stuff daily, both for work and personal use.
- hpcjoe 2y agoI have perl code I wrote in 1992 that still works properly, without changes. The binary executables have changed ISA from MIPS 4 to x86_64, and are compiled fortran (gfortran). There's even a switch I use to be able to read the large endian binary files in gfortran. My c code from 1996 requires rework. My C++ code from 2014 requires rework (I had to do this with others code as well to use a std capability). Python code rarely survives 3.6 -> 3.12 never mind 2.7 to 3.x. I worked at a company that had (very unwisely) written a massive part of its infrastructure in Py2.7, and was using it a decade past its expiration date. Perl just works.
- szundi 2y agoThis is an insightful comment about maintenance.
- simula67 2y agoEven today, Perl is the only scripting language with more than 200K modules and no Global Interpreter Lock.
- dana321 2y agoGIL is a python paradigm.
- 0xpgm 2y agoI was curious about this and did some casual googling. It spawns an interpreter per thread. However, it seems this is not advantageous performance wise. From docs [1] The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that makes them easy to misuse. Few people know how to use them correctly or will be able to provide help. [1]: https://perldoc.perl.org/threads https://perldoc.perl.org/threads
- chuckadams 2y agoAs of 3.13, Python doesnt have a GIL either. JVM-based Ruby implementations don't have a GIL. Perl on the other hand never had a GIL, it just more or less defeated the purpose of threading by copying the entire interpreter state including all variables in every thread. Modules that explicitly work with threading are as rare as hens teeth on CPAN, it's almost always some flavor of async like Coro (hell I bet POE still works too).
- zzzeek 2y agopython 3.13 most certainly has a GIL, it can just be optionally disabled, and this feature is in experimental status. see https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
- chuckadams 2y agoOh, I thought the experimental state was earlier and that 3.13 was the official no-GIL release. Presumably it's going to eventually drop the GIL entirely (probably Python 4 if there ever is such a thing) but nonetheless I stand corrected, thank you.
- onli 2y agoI'm considering it. It might be a language that does not need constant changes because of useless churn. Especially now, with the Raku split worked out. On the other hand, the changes in my Ruby project have always been very manageable. Both the language and the ecosystem were reasonable those last years.
- stouset 2y agoIf you're already comfortable in Ruby there's very little reason to learn Perl.
- GuB-42 2y agoI don't "start a new project" in Perl, but I certainly write a lot of Perl. Mostly one-liners and small scripts, and mostly throwaway. Perl is a very efficient language for string processing, thanks mostly to its built-in regex engine. Once it grows a little bit more and starts requiring maintenance, I tend to rewrite it in a more maintenable language. Preferably a statically-typed language.
- anothername12 2y agoThe fun factor will be relatively high
- samatman 2y agoPerl as a scripting language remains undefeated. As in, let's say you are considering Awk for some task. It's probably worth learning how to do that task in Perl instead. The same applies to many classic uses of bash scripts: today, the biggest reason to choose to write a shell script is to provide some service which will be universally available on plausible platforms, and Perl isn't that ubiquitous any longer. But for most of what shell scripting was intended for, Perl is a more powerful and less, let's say idiosyncratic, choice. Of course, with a bit more verbosity, any such script could be written in Python. Perl was designed to fit this exact niche, so it has a bunch of small affordances for doing script munging eloquently (not to say elegantly!) but Python, or Ruby for that matter, can also get the job done. Most people who know either of those languages thoroughly would pick what they know: they'll do the job, and that spares learning another language, which is indeed a quirky one. But for those who do know Perl, it remains a very good fit for a Practical Extraction and Reporting Language. For those who do a lot of 'scripting' tasks in the original sense, it's worth learning imho.
- wbazant 2y agoI've started to write my one off scripts with an AI prompt, and Python as a simpler and more verbose language with a bigger training corpus is easier for that. Or I ask for a bash script! Still writing my one liners in Perl but they're getting shorter and shorter.
- SoftTalker 2y agoExcept, I know how to slice and dice text with awk, and can do it without leaning on ChatGPT or studying language documentation. Never made the leap to perl, the few times I tried I was put off because to a newbie the language looks like gibberish. I would never consider perl for anything new in 2024. I still use awk very regularly.
- samatman 2y ago> Except, I know how to slice and dice text with awk I meant to say something more like "if you need to learn awk to do it, you may as well learn Perl instead". I figured from context that if you're "considering using awk", you don't know it, or you'd be "using awk". But no matter. Perl can do everything Awk can, at least as well if not better. As fiddly, arbitrary, and limited, as Awk is, it's a lot less language, and that does come with advantages. But I know from experience that you can learn the Awk subset of Perl as easily as you can learn Awk, and then you have a basis for extension to more tasks of a similar nature. If you want to see what I mean, there's a utility a2p[0] which translates Awk to Perl, this suffers slightly from machine translation, but it's a good demonstration that Perl can do everything Awk can in not just a trivial sense, but in the sense that it's designed to make Awk unnecessary. So if you can get over whatever aesthetic hangup you have about Perlian line noise, you might discover you like it. Anyone using Awk "very regularly" is leaving a lot of potential on the table by refusing to learn Perl. Then again, sometimes it's best to stick with what you know. [0] https://perldoc.perl.org/5.8.6/a2p https://perldoc.perl.org/5.8.6/a2p
- araes 2y agoOne part of Perl, that still largely makes sense, is that Perl is almost always one of the smallest choices for toy program tests. https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Javascript is maybe 150% on average and C++ is maybe 200%. If they're ever gonna do this P7 thing, it would be nice if there was a slight runtime improvement. There's some room available. https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- stouset 2y agoRuby is nearly as good as Perl in this regard, is a significantly more useful skill to learn, and code written in it is immeasurably more readable.
- binary132 2y agoOk, but if you’re comfortable using it, Perl is really fun, pleasant, and easy to quickly express ideas in. One of its conscious design decisions is to be flexible enough to rapidly bang out some quick hack you’ll never look at again in absolute incomprehensible gibberish shorthand, or to use in a very methodical, disciplined, and structured way — so if you write something unmaintainable, that’s because you chose to. I haven’t turned to it as my first choice in years, but it still has a place in my back pocket for if I ever need a quick and dirty text munging Swiss Army knife.
- stouset 2y agoAny language you already know is going to have the advantage over languages you don’t. If you already know Perl, you already know if it’s right for you. If you don’t, you’re probably better off learning Ruby instead.
- binary132 2y agoIt’s not like you have to pick. Both are facile to pick up over a weekend. :)
- shawn_w 2y agoIt's been my first choice for 30 years for anything involving a lot of non-trivial work with textual data (Including xml, json, etc.). And one-liners and any quick throwaway script, of course.
- mbivert 2y agoI've used Perl extensively for a few years professionally. For prototyping, say text-processing stuff, I reach out for awk/sh, which are usually sufficient. If I need more than a prototype, I reach out for Go. I have two major complains with Perl: - it's more difficult to deploy (Go can be cross-compiled to a single binary which can then be scp(1)'d around, solid stdlib, no need to deal with dependencies on the remote, or modules split in multiple files); - lack of static typing. You can get away with writing additional tests, but at the end of the day, that's just more work. So despite being quite confortable with a fair subset of Perl, I (genuinely) can't think of a reason as to why I'd want to use it.
- pjmlp 2y agoFull blown applications, probably not, then again it never made much sense. Now UNIX scripting that has no place being a bunch of sh scripts, definitely.