19 ms·

Why Perl?

• jjgreen 3y ago
  In my dreams Python has the stability of Perl, then I'm woken by an alarm that a Python script I wrote 6 months ago uses a now-deprecated feature ...
  • andrewstuart 3y ago
    This is a new one on me …. Python is unstable?
    • qsort 3y ago
      It's certainly less stable and ubiquitous than Perl. These days I'd rather be on Python (better libs, doesn't spook colleagues, very common on Linux boxes), but it's not an unreasonable position.
    • t8sr 3y ago
      Very much so, insofar as code written a few years ago probably doesn’t work anymore. Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years. 10 years ago: range 5 years ago: xrange Today: range again, LOL! I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again.
      • andrewstuart 3y ago
        Maybe Perl is stable cause its dead.
        • meepmorp 3y ago
          Latin and Sanskrit are stable af.
          • jjgreen 3y ago
            Latin is pretty stable, but not entirely fixed: https://www.nytimes.com/2003/05/14/world/vatican-introduces-latin-to-21st-century-with-new-dictionary.html https://www.nytimes.com/2003/05/14/world/vatican-introduces-...
          • drewcoo 3y ago
            I took a medieval Latin course in college that was especially challenging because after the empire fell, Latin was absolutely not stable.
      • Roark66 3y ago
        How about a fortune 300 company I consulted for that uses python pretty much exclusively for the deployment processes of their 200+ web/cloud apps? Some of those apps have 1 VM plus a DB and a dozen users. Some have environments that cost £30k a month and 5k users. Python is the only language used for CI/CD. Plus power shell for stuff that needs windows server. 70% is python 2, 30% written/rewritten recently is python 3.
        • josefx 3y ago
          > 70% is python 2 I hope they are paying for security updates since python 2 has hit EOL 3 years ago and libraries had been actively shamed if they didn't drop support for it long before that.
          • Roark66 3y ago
            Nope, not for python 2, but there was tracking of published vulnerabilities. None that were discovered during my time there affected existing python 2 code. Python 2 code is being transitioned to 3 and there is a plan to do so for all of it, but it's definitely not a highest priority task. Usually done when new features are requested. This isn't ideal, but it's not a reason to panic. None of the code is externally facing, none of it accepts user input directly beyond a press of a button in third party software that triggers it. All it does is pretty simple stuff. Infrastructure provisioning etc.
      • smcl 3y ago
        The criticism is that the Python team will deprecate and remove functionality as it's not needed? Boy, you're gonna hate PEP-594. Also Python 2->3 transition was a one-time thing that developers had over a decade to perform, it may have been painful for some but saying it's a random thing that happens "every few years" is a bit dishonest.
        • fullspectrumdev 3y ago
          PEP-594 is actually causing me some anxiety - I deal with a good amount of code that uses some of those “batteries to be removed”. Some of them (telnetlib) I can vendor in, but I wonder how many people who use them will be caught pantsless?
          • smcl 3y ago
            My feeling is that if you're the sort of org who will update the Python version you use, you're going to be switched-on enough to handle this somehow. From the sounds of things it it's a bit of an inconvenience for you that you'd understandably rather not have, but you have it under control. I don't personally use any of these "dead" batteries though, so I can't speak with any authority on the matter
        • stonogo 3y ago
          Are you saying there will never be a Python 4, or are you saying that the 2->3 transition was so badly flubbed nobody will make that mistake again?
          • smcl 3y ago
            Well yeah given that some people are still talking about issues from a software release that happened 15 years ago, it would be incredibly unlikely that they'd want to repeat that. What has me a little bit confused is that we're in a thread talking about how Python somehow "flubbed" after 2->3, despite an explosion in popularity during that period culminating in it being arguably the most popular programming language around. And the counterexample is supposed to be Perl, a language which I have enjoyed using but which has fallen off a cliff during the same period, and which has had an even more enormous and self-defeating flub (Perl 6 aka "Raku"). As I said, I understand if Python 3.x was painful for some organizations. I think the suggestion that it was a failure and that Perl showed us the right way to go is a pretty silly one though.
      • telmo 3y ago
        > I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again. It is weirdly comforting to observe how certain things never change over the years, even in tech. One of them is the hyperboles people deploy when attacking programming languages that they do not like: "I don’t know of any tech companies using Python for anything serious anymore". I mean, except for being the 4th most popular language amongst professional according to last year's Stack Overflow survey. Only JavaScript, SQL and HTML/CSS are more popular. Yes, yes, I am sure it is dying... any moment now.
        • t8sr 3y ago
          You just read what you want to read, friend. I don’t particularly dislike Python, in fact I wrote about 50k lines of it a few years ago. My claim is that the big names don’t really use Python outside of data pipelines. Where I’ve worked (including an org that had had Guido on it for a while) usually had guidance saying “no new Python projects”. You can ask people at Google, Meta, etc when was the last time they wrote production Python code if you don’t believe me. That’s not mutually exclusive with web devs on Stack Overflow using the language, nor does it take away from its success in academia.
      • raverbashing 3y ago
        > it’s getting rewrote in Go or Rust, not Python again. Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?
        • orwin 3y ago
          Why wouldn't you tag your 1 year old code with the compiler it was written for? And same question for grandparents. I'm not a great dev, average at best, but at least I control my systems.
          • stonogo 3y ago
            If that's what best practices are for these languages, I now better understand my collegues who will not move away from C/C++. Having to identify a specific compiler version for each bit of code sounds like a nightmare.
            • zkldi 3y ago
              it's very easy. you make a file called `rust-toolchain` next to your `Cargo.toml` that contains the version of rust you intend this to compile for. It will then compile for that version.
            • bamfly 3y ago
              C and C++ projects of any notably complexity & size often suffer from those exact same kind of "library or build tool or compiler updated—now the project won't build" problems. Absent some pretty heroic & unusual levels of discipline from all involved, anyway (which is also a way to avoid those issues in most other languages that have them). [EDIT] Check out issue trackers for such projects, some time. "Build broke due to [thing] being too new" is a routine issue to encounter.
          • gkbrk 3y ago
            Why should you need to? Just use a stable language, or a language that has a standard or a specification.
      • BeetleB 3y ago
        > but a lot of it is the language itself making seemingly random changes in direction every few years. Outside of 2 -> 3, I can recall only one or two instances of dealing with this in the last 15 years. One was the introduction of "with" and "as" as a keyword. The other one I can't even remember. None of the code I have written on my personal PC in all these years needed modification due to these changes (all of them were in 3rd party code I needed to patch). I still have Python 2 scripts continually running! I have Python 3.10 installed, and never had to fix a broken script of mine since I switched to Python 3 several years ago. > 10 years ago: range 5 years ago: xrange Today: range again, LOL! Eh? When I began using it heavily (before Python 3 existed), both range and xrange were heavily in use - one was a list the other was a generator. Since Python 3 has been stable and fast (circa 2013 or 2014), it's been only range.
      • rcarmo 3y ago
        This goes against my own experience. I moved from Perl 4 to 5 and from Python 2.x to 3.x and have dozens of projects written in Python that have been constantly updated over the past 10 years, none of which broke due to those things - and they are not all in the ML space. Your sample size of one needs expanding.
      • nerdponx 3y ago
        > Very much so, insofar as code written a few years ago probably doesn’t work anymore. Citation needed? Just a week ago I used a Python library completely unchanged from 2013. > Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years. "Seemingly random" is both wrong and insulting. The BDFL did step down and was replaced with a steering council, so maybe that's what you're seeing. I do agree that `match` was a bad addition to the language, but that's one small example among many supporting the opposite opinion. > 10 years ago: range 5 years ago: xrange Today: range again, LOL! Huh? Python 3.x has only ever had range(), so it's been range() for at least 10 years.
    • jjgreen 3y ago
      Clearly an example of a parallel universe leaking into my own, can I come and live in yours? Please?
    • KaiserPro 3y ago
      One of the things that I noticed when I started python (many many years ago) is that it crashed a lot more than perl. perl you really had to properly abuse it to make it actually crash. Now, some people see that as a feature not a bug (for either perl or python's behaviour)
    • kdklol 3y ago
      Can confirm, recently written scripts require modification pretty much every minor version. Take the limit on the default size of BigInts now. Why? Just... why? I had to look into every script add the override line at the top (or check the entire script it ever assumes unlimited BigInt anywhere). No wonder there are still Python 2 scripts in use.
  • dmz73 3y ago
    I wanted to like Python. Every time I tried to use/learn it, the "program" I wanted to use had some issue. The very first one (some 15 years ago) depended on mutually incompatible libraries so I had to spend time not only learning Python but fixing the libraries to work together. Next one was a dlna server that managed to use up all 4GB RAM available on my NAS and make the whole system unusable. Then there was a "compiler" that worked on all OS-es except that on Windows it would 100% not work due to some path string handling when starting a process. How do you even get to that point...that could have never worked on Windows and it's not like Windows is some marginal never used system so no testing was required. Then I tried to write a simple script to transfer some emails via IMAP...and Python idea of supporting IMAP is for me to read the RFC and build the correct string to sent to IMAP server...WTF???? That is the assembler lever of "support" of something. I did try to do that and then I ended up with multiple pages of something that looked like level of arcade game with climbing hills and cliffs of code where it was hard to tell if code was meant to end or if someone got bored of writing and just gave up. I hate Python.
    • anthk 3y ago
      Heh. On Python and IMAP, getmail was dog slow against isync/mbsync. Same RAM issues.
  • Hamuko 3y ago
    Deprecation doesn't really mean that your script is broken or going to break anytime soon. unittest.UnitTest.assertEquals() has been deprecated since 2011-02 (Python 3.2) and is set to be actually removed 2023-10 (Python 3.12).
    • jjgreen 3y ago
      Not always, but for the sake of your sanity you need to fix those deprecations, if only so you can see the new ones, one of which will break your script at some point.
  • tokai 3y ago
    What? The Perl 6 debacle has gone down even worse than Python 3.
    • G3rn0ti 3y ago
      Perl 6 took longer than expected but „Raku“ is alive and well. It even moved into the Tiobe-Index at rank #48 recently: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ This whole Python/Perl competition was always a bit silly. Both languages had and have their place. I would say Python is so much more popular because it found a niche in ML because of how much more easy it is in Python to interface fast C modules. So you get to write simple Python programs leveraging blazingly fast math libraries. That was always a bit more tricky to do in Perl. But Python as a language is definitely not as flexible as Perl 5. Last time I checked Python didn’t even support multi-line lambdas because its inventor hates those. Python is very much designed in a top-down approach and tries to guide all Python programmers into how there are supposed to solve their problems. Perl 5 was designed with its famous „easy things should be easy, hard problems possible to solve” philosophy. It allows for meta-programming in all the right places which a seasoned Perl developer can reach to when necessary. Perl 5 is a nice middle way between C and Lisp. That being said modern JavaScript turned into a powerful language that fits well into both the frontend and backend side of a web application nowadays and, hence, kind of replaced Perl as glue language for the web. It will also push Python out of web backends at some point I believe.
      • achileas 3y ago
        Having used Python and Perl professionally, I'd have to agree with really all of this. I just want to emphasize Python's niche in ML (since that's what I do with it mostly lately) - it was also helped by a large, early set of libraries specifically for ML that other languages either still don't have or are playing catch-up (Elixir), and its ease of use among academics, a lot of whom went straight from academia to industry.
    • b1c837696ba28b 3y ago
      Really? Was Perl 5 deprecated with prejudice across ecosystems, forcing projects to work with a janky, still-evolving replacement well ahead of production-grade stability? Because the boot marks in my ass from the forced march to Py3 are still bleeding.
  • nerdponx 3y ago
    Which feature? Deprecation warnings tend to be in place for several years before removal. There's a formal policy for it: https://peps.python.org/pep-0387/ https://peps.python.org/pep-0387/ > Unless it is going through the deprecation process below, the behavior of an API must not change in an incompatible fashion between any two consecutive releases. Python’s yearly release process (PEP 602) means that the deprecation period must last at least two years. In practice, it's usually longer than two years, except on features that were considered provisional in the first place.
• lmm 3y ago
  TCL seems like a better fit for the listed requirements. Even more ubiquitous, more stable, scales up better.
  • pjmlp 3y ago
    It never had the extent of CPAN, and that makes a big difference.
    • lmm 3y ago
      I don't disagree, but availability of libraries is conspicuous by its absence in this person's criteria.
• cglong 3y ago
  Extensively discussed 52 days ago: https://news.ycombinator.com/item?id=35646612 https://news.ycombinator.com/item?id=35646612
  • Flimm 3y ago
    My apologies.
• andrewstuart 3y ago
  Friends don’t let friends use Perl.
  • pjmlp 3y ago
    From the point of view of security, I rather have UNIX userspace stuff being coded in Perl than C.
    • habib_k 3y ago
      Which one is older C or perl?
      • pjmlp 3y ago
        Age doesn't play a role in security excuses. If it did, C authors shouldn't have ignored systems languages 10 years older than C.
      • yobert 3y ago
        The perl interpreter is written in C, so that should be a good hint. :)
  • aduitsis 3y ago
    Programming language police, pull over.
  • weare138 3y ago
    Try it. It's fun.
    • hexo 3y ago
      It has some features one should never find in a programming language. Like overuse of sigils and that is not fun, but more like annoying af.
  • deleted 3y ago
    [deleted]
• bluetomcat 3y ago
  Perl can be seen as a middle ground between AWK (and bash and sed) and a more general-purpose language like Python. It prioritises brevity of expression over readability. Using regular expressions in Perl feels more like a "first-class experience", where most other languages treat it as just another library.
  • pjmlp 3y ago
    Additionally it can be seen as a safer C, as it gives access to most UNIX capabilities and C standard library, without the memory corruption gotchas.
• Tepix 3y ago
  For many, Perl is great for system administration related tasks that are more than two or three pages of bash.
  • DonHopkins 3y ago
    Perl's usefulness has a narrow peak like the Balmer curve, because Python is better for system administration related tasks that are more than four or five pages of Perl. And everyone knows how system administration scripts always grow to more than five pages, so it's better to just start in Python.
    • Tepix 3y ago
      I'm not so sure about Python's advantage over Perl regarding sysadmin tasks...
    • ilyt 3y ago
      It's a blessing if you need to manage a range of legacy systems, because Perl "just works" while Python is crapshoot.
    • nocman 3y ago
      That might be true if you already don't like writing Perl, but I have many years of experience writing system administration scripts in Perl, and I'd pick it for that task over Python any day. I can understand why someone who prefers Python would go that route, but it is definitely not more capable than Perl in that domain.
• constantcrying 3y ago
  My father is an extensive Perl user, which still is somewhat of a mystery to me. But it seems to be a language very much suited for IT related tasks.
  • bayindirh 3y ago
    Perl is the undisputed god of text processing and manipulation. Most of the "IT related tasks" are essentially "Get the output, understand what it means, and act upon it", which makes Perl a perfect fit for the situation. You can convert an IP to its hex representation and change a symlink in one line. That's a superpower.
    • louwrentius 3y ago
      Sounds more like something that is difficult to read/understand. Code readability, being able to understand code 6 months from now is much more important to me. Cramming things in one line can sometimes be neat but Perl took that concept and went bananas, and now Perl has because the punchline to many jokes, justified or not.
      • nuker 3y ago
        If the joke fits in one line, there is nothing to justify, no paragraphs.
      • bayindirh 3y ago
        Well, the exact code is as follows: $hexip = sprintf("%02X%02X%02X%02X",split('\.',$ip)); system ("cd <REDACTED_PATH>; ln -fs $boothd $hexip"); That's all. I think, in this case, perl being hard to understand is the joke itself.
        • zkldi 3y ago
          What happens if `boothd` contains a space? or a semicolon? or any character the shell might interpret?
• Roark66 3y ago
  I don't know... I used to use perl as my "default scripting language" over a decade ago. Once I was required to learn python for a new job I had no need to look back.
  • aduitsis 3y ago
    If you feel more comfortable with Python for the task at hand, why not use it? That's good and it's actually the Perl way, Perl was always about helping getting stuff done.
  • jacklbk 3y ago
    Same. My first job was to write perl test script in a fortune 100 company. Then I pretty much used it for every scripting stuff. After I moved on to the next job, working on Python was so much easier. I have never written a line in perl since then.
• jgrahamc 3y ago
  The general joke about Perl is that it's "write-only". When I wrote POPFile I spent a lot of time ensuring that the code was readable and maintainable. I hope it's still understandable: https://github.com/jgrahamc/popfile/blob/trunk/engine/Classifier/Bayes.pm https://github.com/jgrahamc/popfile/blob/trunk/engine/Classi...
  • izietto 3y ago
    Personally, I find it very readable. My only criticism is that its syntax looks "weird" nowadays. I mean, a newborn language would never go with `my` as local variables declaration prefix, or `->` for object method call, or `sub` for function declaration. I think Perl would benefit of a transpiling approach, like what Elixir is to Erlang.
    • zimpenfish 3y ago
      > Personally, I find it very readable. A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes a huge monolithic monstrosity by creating their own ORM and object model with almost zero documentation in or out of the code and hoo boy, that is not going to be a fun time 10 years later when basically nothing has changed because no-one has the time or energy to parse out what they've "crafted".
      • motogpjimbo 3y ago
        The mistake was to think Perl was suitable for those types of applications in the first place. Perl was designed for writing small scripts to glue C programs together in a more convenient way than using shell scripts and AWK. A lot of its idiosyncratic design decisions make sense in that context. But when Perl advocates starting pushing it for writing large applications with OOP (with, of course, multiple competing object systems) it was the beginning of the end. Add in the vapourware that was Perl 6 and it was game over.
      • jlokier 3y ago
        > A lot of Perl can be readable. But sometimes you get a backend where someone with , let's say, a "unique" view of software development writes I agree. Perhaps Perl culture encouraged that kinds of development. But I've a seen number of monstrosities in other, better known languages that are "crafted" that way as well. I'm currently working with a large commercial product in C that would undoubtedly be easier for the 50-strong team of devs to work with if it was written in Perl (though they would still complain), and ironically it would probably run faster in Perl too (and be much more secure). I don't think the problem is the language really, as Perl can be written in a modular and fairly clean way too (compared with many other languages) if the developers are minded to. I think it's the culture in which those large projects were developed. Or rather, the lack of software engineering culture for long-term maintanence, and a disinclination to use frameworks and patterns that would be familiar to new developers coming in later, especially from other environments. It may be that Perl's rise and fall was a product of its timing relative to software-at-scale culture as much as anything. Despite its origins as a glue language, Perl 5 is a Lisp-like once you see past the syntax. Perhaps that's part of its problem: Lisp encourages creative and unique approaches to large projects too, and also isn't widely used any more.
• xupybd 3y ago
  Does ubiquity still count when you have dependencies? I find any Perl application of reasonable size collects a few dependencies and they can cause pain when installing on different systems.
  • WesolyKubeczek 3y ago
    No it doesn’t. And god have mercy on you when you find a transient dependency with an unfixed bug reported a decade ago whose author went AWOL.
• nickdothutton 3y ago
  Many, perhaps most ISPs in the 90s were built out of Perl, including my own. Like any language, there is a world of difference between a codebase written by an experienced, thoughtful, veteran, and something just cranked out by a 1st year student (as we all were once, myself included!). I frequently see Perl described as “hard to read” yet have seen many beautifully written codebases that are a delight to maintain.
  • rcarmo 3y ago
    As someone who maintained Radiator (a RADIUS server) at a few places, I agree. That piece of software alone was enough justification for Perl to be used in critical scenarios, and as far as I know some of those instances are still running, decades after I left (obviously not the same machines or versions).
• sharts 3y ago
  Why not Ocaml?
  • habib_k 3y ago
    What is ocaml?
• qalmakka 3y ago
  Python and Perl areas of strength do not overlap, IMHO. Python is great to write well structured programs with modules, well defined classes, etc. Perl is great to glue stuff together in place of shell scripts. I see way too often people attempting to write Python scripts to accomplish simple tasks and they inevitably end up being full of boilerplate, third party modules, stuff that breaks at every python update, etc. Perl is changing but it always stays backward compatible, it's installed literally everywhere and it has unmatched regex support, so it's super easy to run a few commands and process their output. Perl is also arguably a better awk than awk and a better sed than sed, imho. I haven't used sed in ages because 99% of the time `per -pE 's/reg/ex/g' -i <file>` is way more convenient and portable than `sed`.
  • sgt 3y ago
    It's interesting that people say the same about Java and Python; Java is great for well structured programs and scalability. Python is great for scripts, just don't let the programs grow too much in size. (Not my opinion, I am impressed with how well Python programs can scale in size if using a proper framework e.g. Django)
    • nerdponx 3y ago
      Python is excellent for "medium scale". A little too verbose for very simple ad-hoc scripts, a little too unstructured for very large applications with a large number of developers (but this has improved substantially in recent years).
      • qalmakka 3y ago
        This. Medium scale is what Python excels at - the sweet spot is IMHO between 3K-10K lines. Above that and you start running into sore points (performance, no parallelism, too much dynamic typing, ...) and you maybe start looking into writing some parts of your code in C/C++/Rust (or yet another custom runtime, like Dropbox or Google attempted to do once). Under that it's still very effective but probably not the sharpest tool around - IMHO Python excels at being a jack of all trades, but there are often more specialised languages that tend to be more effective in a specific niche (like, for instance, Perl when writing scripts that glue tools together).
• shubhamjain 3y ago
  > Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms. This is actually a deep flaw, rather than an advantage. There are so many ways to do a single thing in Perl that you just give up seeing them in the wild. It would take months or years of practice to get comfortable with every nuance of Perl. Even Google fails to help often (try Googling what "$_%@" means). I get it; the terseness can feel for an advanced user, but folks like me, the verbosity of Python and Javascript is much more preferable.
  • nuker 3y ago
    What “$_%@" means for the love of god?
    • jlokier 3y ago
      It doesn't mean anything in Perl. The comment is a demonstration of why some criticisms of Perl are unjustified, as people love to make up little things like that, then other people such as yourself end up with the impression that sort of nonsense is ordinary Perl. (You could imagine at a stretch those characters as part of an unrealistic expression, like "print $_%@array" meaning "print the value of $_ modulo the length of @array", but you can write messy code without spaces like that in many languages.) I used to think heavy criticism of Perl's use of punctuation characters were valid, until I looked at PHP, Ruby and Rust, and realised that some of the more popular and even loved languages are punctuation-heavy too. I prefer languages with less punctuation (despite doing expert level Perl), so I think the use of sigils ($variable) is not the best design space, but I think the criticisms of that kind which single out Perl are more like a have-a-go meme than a level-headed comparison by now.
      • azangru 3y ago
        > I used to think heavy criticism of Perl's use of punctuation characters were valid, until I looked at PHP, Ruby and Rust The mandatory dollar sign in variable names looks dumb in php, I grant you that. As well as the dot for string concatenation. But perl insists on the distinction between $variable, @variable, and %variable; which is just wild. How is it that python works fine without all that noise, for chrissake? Or javascript?
• forinti 3y ago
  The first time I loaded data onto an Elastic index, I used Perl. Then I used logstash so that I could do it the proper way. It turned out to be about twice as much text. So this fantastic language was already there and there was already an Elastic module in CPAN. I'm biased, but you can't call this a dead language.
• cryptos 3y ago
  I don't understand the rating in the table. After the Python 2/3 migration I wouldn't expect compatibility problems for the forseable future. And why should Python not work as well for shell scripts as Perl? Why should Java not work for shell scripts? You can even run Java files without an explicit compilation step these days. Why should Python, JavaScript, Java, and C# not be extensible? Honestly the whole post doesn't really make sense to me and it looks like someone is just paying homage to a thing of the past. You can clearly see the decline of Perl here: https://redmonk.com/rstephens/2021/08/05/top-20-june-2021/ https://redmonk.com/rstephens/2021/08/05/top-20-june-2021/
  • KaiserPro 3y ago
    because anything written in 2 wont run as is on 3, anything using async will need 3.4(?) anything using type hints of f strings needs 3.7( or 8, I get hazy)
    • cryptos 3y ago
      I already mentioned the Python 2/3 problem, but the other things you listed sound like usual new features, which won't work on older versions, obviously. However, I'd expect Python 3.4 code to run perfectly fine on a Python 3.8 interpreter.
    • Sohcahtoa82 3y ago
      > because anything written in 2 wont run as is on 3 Not true. "anything" is too strong of a word. There's plenty of simple code that works fine in both 2 and 3. For basic scripts, it's not hard to make code that is compatible with both, with the only odd thing to do is using parentheses in your print calls. You can even use "from __future__ import print_function" in Python 2 code to get Python 3's print() behavior. > anything using async will need 3.4(?) anything using type hints of f strings needs 3.7( or 8, I get hazy) What's the alternative? Should a language never receive new features?
      • KaiserPro 3y ago
        > Not true. "anything" is too strong of a word. technically correct is the best kind of correct.
• habib_k 3y ago
  Is perl, a programming language?
  • MrVandemar 3y ago
    Wikipedia seems to think so: From Wikipedia, the free encyclopedia This article is about the programming language. -- snip -- Perl is a family of two high-level, general-purpose, interpreted, dynamic programming languages.
• eterevsky 3y ago
  I think the author favors Perl way too much. "Scales up": I don't know of any widely used projects written in Perl with tens or hundreds thousands lines of code. I know a lot of big projects written in Python, JS, Java and C#. "Compatibility": Author means stability. Last breaking changes in Python were in Python3, which came out 15 years ago, and no breaking changes are anticipated in the foreseeable future. So I would say it's fairly certain that Python programs written now would work 10 years from now. Incidentally, Perl also attempted to make breaking changes with the transition to Perl 6. The only difference was that it didn't come through. "Extensible": I don't understand this metric at all. Suppose I want to implement a module in C++ or Rust. Is it significantly easier to do in Perl than in other languages? I don't think so.
  • stefanos82 3y ago
    > "Scales up": I don't know of any widely used projects written in Perl with tens or hundreds thousands lines of code. I know a lot of big projects written in Python, JS, Java and C#. * DuckDuckGo * cPanel * booking.com * craigslist These projects use millions of lines of Perl code and trust me, there are lots of other companies, banking infrastructures included (!), that use Perl as their backend or in-house services.
    • eterevsky 3y ago
      I stand corrected regarding big projects in Perl. I still don't think it's as good for big projects as Java, C++ and probably Python.
      • rurban 3y ago
        much better than java, c++ and python for big projects. worked on huge such codebases. only ruby is comparable, but ruby breaks compat way too often.
  • dagw 3y ago
    Last breaking changes in Python were in Python3 Python (or at least the standard library) breaks quite often compared to some other more conservative languages. For example they recently 'broke' dataclasses somewhere between 3.8 and 3.11 by changing how initialisation of default values works and I had to fix some code. Last breaking changes in Python were in Python3 If you only stick to the core language, then yes. If you make use of a lot of the standard library that comes with python by default, then all bets are off.
• petesergeant 3y ago
  I have a couple of decades of Perl, and used it for everything from automating warehouses to building the original BBC iPlayer to big data ETL. I’ve also spent the last five weeks writing Python exclusively for a job, and the two years before _that_ doing TypeScript on the backend. CPAN is better than its equivalents. The consistent documentation style and location, focus on tests, and so on is excellent. Miss CPAN. Python is a fine language. Its type system feels like a toy after using TypeScript, but last time I used Perl in anger there was nothing. The scoping is weird, and I think makes readability worse, but you get used to it. TypeScript is awesome, but setting up the compile step for a new project so it works with testing and so on, weird edge cases about which module system you’re using, these are irritating. I love Perl, and I think in Perl, but given its ever-decreasing mindshare, I’m not sure what major new projects I’d start in it. At both the TS and Python role I’ve written Perl that acts as a superior bash, and it’s been excellent for this, long may it continue. The big issue is that I’m reluctant to share my Perl with the rest of the team because I’m the only one who knows it
  • WesolyKubeczek 3y ago
    > CPAN is better than its equivalents. The consistent documentation style and location, focus on tests, and so on is excellent. Miss CPAN. > focus on tests …which at critical moments may turn out to be just LARPing. I had to rewrite some tests for a dependency of a dependency of my project so that they had any meaning at all. The test suite was unchanged for a decade and it had been talking to some random web services on the internets. There is an unanswered bug report that tests have stopped passing entirely some years ago. Another project failed its tests due to a dependency being bumped, and there was a fixing suggestion unanswered since 2014. I don’t know if the author is actually alive. I guess it’s soothing to see an endless output of “ok test x” from a test suite, makes you believe the project is real solid, or something.
• deleted 3y ago
  [deleted]
• kdklol 3y ago
  I discovered Perl basically by accident. For scripting/systems administration its simply unmatched. It's been clearly designed for speed and utility which is what I always wanted and I'm a bit disappointed nobody ever mentioned it to me. I'm 20-something btw, so it's not just ravings of an old man. I think the catastrophe happened when people mistook this it for a backend development language... and it somehow worked. Not well, but it did, which is it's own quality. I slowly started learning it half a year ago and it's been really useful for scripts. It's indeed more robust than POSIX shell which tends to have baked in assumptions about the system which may not transfer well onto different platforms. No regrets - the grey beards were right!
  • tenderfault 3y ago
    i am a grey beard. i confirm "the catastrophe happened when people mistook this it for a backend development language"
    • jqcoffey 3y ago
      I suppose I’m a grey beard (in industry is 96ish) and I mean, it’s fine as a backend language in so far as dynamically (or even loosely) typed languages go. It’s just as easy (or hard) to write modular well tested code as in any number of other languages in wide use for backend services, in my XP.
  • HybridCurve 3y ago
    Yes, it's a great language for this application. Make sure you read Damian Conway's book "Perl Best Practices" as a guideline for crafting consistent and readable code. People's biggest gripes about this language generally revolve around poorly written code that is hard to read. Also, when writing regexes it helps to paste one or more example lines or matches above the regex so there is no question about what you are trying to do. 9/10 times I've found debugging SA perl scripts comes down to an unhandled pattern in a regex and this is what helps the most when re-writing it to ensure it doesn't break anything else.
    • cjohnson318 3y ago
• kunley 3y ago
  Actually a lot of Ruby's features were like: Perl, but with REPL and objects and easy metaprogramming. I believe Matz intended Ruby to please admins, not only programmers, from the very beginning. Following this, me and few buddies used it mainly for admin tasks for over a decade, doing things somewhat orthogonal to the then-emerging RoR crowd. Although ofc the author is right about Perl's unbeatable ubiquity..
  • stevebmark 3y ago
    Indeed, Ruby is often called "the bad parts of Perl." Ruby made metaprogramming and monkeypatching first class, and somehow made the language even harder to statically analyze.
    • kunley 3y ago
      But there is sorbet, claiming to be very fast and effective. Honestly I don't know how it behaves in practice - still on my list to check. Over the years I more use Go where I used Ruby - for a single feature of delivering a single no-deps binary to the server / container where it's supposed to do something. But I still love Ruby for exploratory stuff. And I see there was a lot of progress with the VM - one of my favorite side activities is to disassemble the opcodes for trivial and non-trivial sources... (doing same in Python, actually..) [Looks like I just answered to several different commenters at once ;)]
  • themodelplumber 3y ago
    I remember being shocked to see someone using Ruby for all their systems scripting back in the 2010s. But it made a lot of sense. Rails definitely sucked up a lot of the use case attention. (Personally for simple admin scripting work, I tend to use ABS-lang.org and turn on Ruby syntax highlighting...)
  • omoikane 3y ago
    Ruby has taken over Perl as my preferred language for small fun projects that I don't intend to update very often. The syntax is more flexible, the libraries are more convenient, and the language just feels more fun overall. It used to be that Perl came pre-installed while Ruby is not, but these days Ruby is fairly available across the systems that I use. Much of the fun was due to influence from Yusuke Endoh: https://github.com/mame https://github.com/mame
• bandrami 3y ago
  There are Perl scripts I wrote in 2000 that are still in commercial use today. This is what annoys me about languages that don't care about backwards compatibility (cough cough)
  • knorker 3y ago
    I have the same with C code. Yet I'm not going to recommend anyone starts a new project in C, outside of very specific use cases like some embedded thing. And even then I'd say a C++ subset.
• tenderfault 3y ago
  >It is installed by default everywhere. I don’t need administrative privileges to deploy Perl code almost anywhere. That is extremely empowering. Not true anymore. FreeBSD dropped it from base. >With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems. History shows different. Perl was never designed for this. >I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators. I concur. I also have 10-ish lines perl scripts running on my systems since 10-ish years, doing exactly what it was written to do. And if the data protocol changes I will just drop 10-ish lines of code and write new 10-ish lines of weird looking, compact and efficient code. I never care understanding my code. If i ever read it again it's just to have a "wow, what does this even do" moment at my own code. For me, write-only is a feature. >Perl can be used nearly as a shell replacement for very quick scripting. Yet there is no generally available shell (like Bash or zsh) written in Perl. This is a weird thing I'm still trying to cope with in 2023. It may be because the term "shell replacement" is used wrong. Did you mean "shell programming"? >Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms. ... I don't know. 27 years later, I still like to flex my reptilian brain reading perlsyn manpage. I like to think of perl syntax as a set of loose rules which you can bend to your liking. And the things you can come out with... oh, boy. Perl is good tool for coming up with a solution really quick. And most of the times, you will just keep running that code for ten-ish years to come. Also, Perl is more of a philosophy than a programming language, like Forth is. Its biggest disadvantage was the community itself. They just kept using it wrong, over and over, trying to serve the greed of a corporate world. The proof of this is Perl 6, the community rewrite of Perl. Looks cool. Won't use it. I think that's why it's now mostly referred to as "raku" instead of "Perl 6". It's not a Perl.
  • Tepix 3y ago
    > >With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems. > History shows different. Perl was never designed for this. I beg to differ - after all, what was Perl 5 about? Adding objects and modules were features only needed for large programs. Just looking at CPAN shows numerous modules of significant size and complexity.
• jinpa_zangpo 3y ago
  The sweet spot for Perl is any problem combining text processing with Unix system calls. It's a system administrator's idea of what a programming language should be. I feel the reason why Perl got a reputation as a "write only" language is because it's easy to write a simple Perl script, so people with no programming background wrote a lot of ugly code. It's simple to write clean, maintainable code in Perl with a little discipline.
  • GuB-42 3y ago
    I have more than a little background in programming, and I love Perl. But I definitely consider it 90% write-only. The remaining 10% are mostly libraries. You can write clean, maintainable code in Perl, but the language simply isn't designed for that, it has other priorities. The whole "there is more than one way to do it" thing is obviously not how you get consistent code, first class regexes which are one of the biggest strengths of Perl are notoriously hard to read, and the "ugly" options tend to be the easiest to use. It is all great for getting stuff done quickly and efficiently, not so much for maintainable code. Languages that favor readability will typically try to go towards the "one true way" of doing things, use more descriptive words in standard libraries, have an annoying "bondage and discipline" compiler, etc... Perl has little discipline built-in, so it has to come from the programmer, don't expect it to guide you to the cleanest way, but you can expect it to help you write everything in one line.
• krylon 3y ago
  I learned Perl just as my shell scripts grew into more than ten-liners, and I switched happily. I never learned awk or sed, Perl is just far too convenient. And I think it is possible to write very readable, maintainable Perl, but one has to really want to and make it a habit. Perl has a couple of footguns, and one needs to be aware of those. The main reason Perl dropped out of favor, IMHO, was the combination of the Perl 6 debacle and Ruby on Rails taking its place for web development. But in its original niche, Perl remains a great choice.
• Qem 3y ago
  Raku Just entered TIOBE rank top 50 languages. Just a statistical fluke, or does it hint at a recovery of Perl family languages?
  • lizmat 3y ago
    I think it's a credit to the hard work many people are doing on the Raku Programming Language.
• Solvency 3y ago
  On the subject of Perl: I've seen HN'ers vehemently beat down any comparison between "serverless" and the old world of /cgi-bin perl scripts. But I've yet to see a reason why. Why, exactly, aren't people using simple and straight-forward run-once cgi-bin scripts? They seem super suitable to so many use cases, even in 2023.
  • jarym 3y ago
    Because developers want to believe they're using something NEW and SHINY. Comparisons to decades old technology doesn't fit into that belief system so some will be hostile towards such suggestions.
  • TylerE 3y ago
    Because they really aren't. Things like not being able to reuse DB connections really hurts. Building the world on every request, 99 times out of 100, is dumb.
    • treis 3y ago
      This is my one big problem with Postgres. Their heavy client/thread model prevents these sort of architecture where you may have a large number of connections. PGBouncer helps a lot, but it's not quite the same.
  • sofixa 3y ago
    You might have a different definition of "serverless", but for me and many others it's "you don't have to worry about the underlying infrastructure". You throw your script/container, it's easy to invoke, easy to scale up to millions rps, or down to zero. Nothing to maintain or update outside of your own code. Useful for unknown or highly variable loads. cgi-bin scripts have little in common with the above model.
    • Sohcahtoa82 3y ago
      > You throw your script/container If you're using containers, then IMO, you're no longer serverless. The reason being... > Nothing to maintain or update outside of your own code Unless your Dockerfile uses something like "FROM python:latest", you'll find yourself having to update your Dockerfile to pull in new images on a regular basis in order to get the latest package updates. People usually like to have reproducible builds though, so will instead use something like "FROM:python:3.7.16-alpine3.18". Except, sorry, that's out of date now. You need to update to "python:3.7.17-alpine3.18."
• cies 3y ago
  I found Ruby to be an acceptable Perl. Easier on the mind. Easier on the reader. Still hard on the IDE (since it's dynamically typed, so hard to implement IDE hints based on the type -- I know some typing is available now). The I found Kotlin to be an acceptable "typed Ruby". :) It's a bit steeper in the learning curve, but apart from that it fits the bill pretty well. Though Ktor is not nearly as rich in ecosystem as Rails is.
• Solvency 3y ago
  Can someone explain the use of "modulo" here? > I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators. ChatGPT says "modulo" means "except for, not accounting for" in this context. I always thought modulo was explicitly a math term to mean the remainder after dividing one number by another. Where did this other "not accounting for" definition / usage come from...?
  • _flux 3y ago
    I don't have an answer for that, but it's been in The Jargon File as accessed by dict atleast since 2003, so it's not a new idiom.
    • jwilk 3y ago
      Backdated to 1981: http://www.catb.org/jargon/oldversions/jarg1-81-MM-DD.txt http://www.catb.org/jargon/oldversions/jarg1-81-MM-DD.txt
  • darrenf 3y ago
    It's been used that way for a long time - it has an entry in the Jargon File: http://catb.org/jargon/html/M/modulo.html http://catb.org/jargon/html/M/modulo.html
  • _dain_ 3y ago
    It's used in the same sense as "up to". https://en.wikipedia.org/wiki/Up_to https://en.wikipedia.org/wiki/Up_to
  • bikenaga 3y ago
    * * *
• justinator 3y ago
  I learned Perl without any math or computer science background. My highest math class was intro to trig. I think I remember the gist of the Pythagorean Theorem. I put myself through school making money writing free software (I can't sell water in the desert, either). But Perl made enough sense to get some work done, after reading a few O'Reilly books. Strings in, strings out - made sense. That was a good, "Why Perl?" for me. YMMV.
• gwd 3y ago
  My biggest issue with both perl and python (apart from no static checking) is third-party libraries: 1. I definitely want to use third-party libraries, so I don't have to re-invent the wheel 2. I hate having to install and manage third-party libraries on all systems where I might want to run something. After using golang and rust, it's really painful to go back.
  • superkuh 3y ago
    >2. I hate having to install and manage third-party libraries on all systems where I might want to run something. I feel the same way. Rust is pretty bad in this sense because you have to install an entire third party compiler and toolchain from outside of your repositories. Usually recommend in the form of, >curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh And if you don't install the third party rustc from out of repos your rustc is only able to compile code written $now till about $now + 3 months. After using perl it was really painful to try to compile random rust code I found. It's not that it's impossible to write forwards compatible rust, it's just that rust devs are mostly hostile towards it. Reactions to this comment will be, "3 months is too old to expect things to compile. You're holding back progress." And that's a legit POV. But one I'm glad Perl doesn't share.
    • inferiorhuman 3y ago
      Typically I dislike having to be forced into a package manager's version of a given language. For example I recently upgraded ansible on my old MacBook and brew decided that it had to install its own version of rust which meant compiling it from scratch. 12GB later and I got ansible installed. Yuck. Likewise I've found CPAN to usually get out of my way… but at least in FreeBSD land I've not had to fight perl packages too much. And I've definitely been missing having Perl in the FreeBSD base system recently. And if you don't install the third party rustc from out of repos your rustc is only able to compile code written $now till about $now + 3 months. If you're not doing things that rely on nightly you generally get a lot more than three months. The catch is, of course, that a lot of things depend on nightly.
• PointyFluff 3y ago
  [dead]
• olodus 3y ago
  I am someone who loves learning new languages (written advent of code in lisp, Haskell, APL, Erlang, zig...). I have thought for a long time to try out Raku as Ive never tried Perl and it feels like the modern version might be easier to get into as it maybe avoids some of the baggage. Is this true, or do I miss something by skipping the original?
  • kraihx 3y ago
    They are completely separate programming languages. Go for the original to get the real Perl experience with all the good and bad.
  • kqr 3y ago
    My personal (but very brief) experience of trying to learn Raku is that most introductory material I came across assumed at least an apprentice-level exposure to Perl concepts and vocabulary.
  • achileas 3y ago
    Just go with Perl, IMO. Raku is completely separate, and would be more akin to learning Ruby or Elixir to get the Perl experience IMO.
  • lizmat 3y ago
    Completely biased opinion: try Raku. It is easier to get into.
• jamespwilliams 3y ago
  > I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators. Yeah, because the ecosystem is dead. The flipside is that the bulk of Perl modules available are stale and don't receive any security updates or bug fixes. If I had a pound for every time I've seen a 10+ year old bug with no comments in the CPAN issue tracker... > Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms. Depends what you call "core syntax". The syntax available to you with a stock Perl install is certainly not small compared to other languages. > With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems. If you're disciplined, you can write complex systems pretty much as well as you could in Python or any other dynamically-typed language. However, it requires a lot of discipline and experience, and with other languages you at least have good formatters and LSPs to help with that. Perl sorely lacks this kind of infrastructure. I also think the lack of static types makes writing complex systems massively harder, but that's not a criticism of Perl in particular.
  • superkuh 3y ago
    Perl was lucky that the Perl 6 diversion happened. If it had stayed the course and popularity it would no longer be perl like python is no longer python (such bad version dependency hell there's actually a layer of package manager hell). Now well after the perl 6 diversion Perl 5 activity has come back and there are new features. But most perl devs and the culture still has the habit of writing for portability and stability instead of using incompatible features a month after the compiler/interpreter/etc adds them.
  • ilyt 3y ago
    I dunno, even for maintained ones I've seen far les breakage, whether now or decade ago. It always seemed like default choice for Perl was getting a warning this way of calling something is depreacated, while in Ruby/Python it was "well, we changed our mind on that API, fuck you and your code". The way Py2to3 migration was handled was also some abomination. Meanwhile if I need my Perl code to work like old Perl I just write use v5.10 in header...
    • 3y ago
• remote_phone 3y ago
  Perl is the worst language I had the displeasure to work with and I’m glad it’s basically dead. The thing I hated most about it was that it had several ways to the same thing, which made it extremely hard to read code because you had to understand the nuances and could cause bugs. For example I vaguely remember that Perl had 2 ways to specify “or” but they had different preferences. The fact that scalars and vectors had different namespaces meant that you could get absurd looking code like $a[$a]. I’m glad that Perl is all but dead.
• troglodynellc 3y ago
  Most of the bickering about this or that programming language is no different than "should I buy the bosch or craftsman table saw". Use whatever has the lowest TCO to you that lets you get the job done. Perl is usually that tool for me, but yanno TIMTOWTDI. Basically every programming language is quite expressive and has adequate tooling to profile, test, cover, format and lint & run thru CI these days. I have noticed pretty much everyone using X language still thinks the others don't have said features though. Good for a chuckle in dev chats.
  • eYrKEC2 3y ago
    > "should I buy the bosch or craftsman table saw" Good question! https://www.garagejournal.com/forum/threads/table-saws-recommendations-for-a-beginner.467570/ https://www.garagejournal.com/forum/threads/table-saws-recom... I too care about my tools. Some feel good in the hands. Some get the job done better. Some I reject outright, despite their ability to get the job done. I care deeply about my tools.
    • dunefox 3y ago
      Bad example, really. Tools do matter.
      • KronisLV 3y ago
        > Bad example, really. Tools do matter. Personally, I'm inclined to suggest that there are definitely "good enough" tools out there and you can get stuff done with those too, instead of spending a lot of money and time looking for the best out there, or getting attached to them. Kind of a utilitarian look, I guess. As an example, I got a Chinese chainsaw (marketed as Lithuanian, but most likely just a white-label product) for cutting trees and prepping firewood, for about 100 EUR. It won't last me decades like a fancy Stihl saw, it will have more engine vibration and the fuel economy won't be great. Yet, none of that matters to me much, because it has the critical set of features that I need (it cuts wood, starts well, has decent throttle response and has a functional saw brake). Whether the same applies to programming and how much is probably quite subjective. Personally I like something like IntelliJ IDEA or other JetBrains tools, but one get by with Eclipse or NetBeans or whatever. In my eyes, the same applies to programming languages - you most likely can write a decent codebase in Rust, Go, Java, .NET, Python, Node, Ruby, as well as languages like Perl and PHP. Some might be more comfortable with one language over another for a variety of reasons and surely the average codebases will be a bit better/worse depending on the language, ecosystem and the community as a whole. But if it lets you pay bills and ship features, then I would be okay with someone picking PHP/Perl/whatever over one of the more favorable languages.
• oalders 3y ago
  Since we're on the topic, the Perl and Raku Conference is taking place in Toronto next month: https://tprc.to/tprc-2023-tor/ https://tprc.to/tprc-2023-tor/ Lots of interesting talks are on the schedule and there's even an introductory course for those who want to learn Go: https://sched.co/1NIEL https://sched.co/1NIEL (This part may be confusing, but lots of folks who work in Perl eventually end up writing some Go as well).
• Crontab 3y ago
  If someone was getting into this today, would you recommend Perl or Raku?
  • lizmat 3y ago
    Raku (https://raku.org https://raku.org). But then I'm biased :-)
    • Crontab 3y ago
      Thank you.
• worik 3y ago
  If only Larry Wall had not promoted "hubris" as a virtue. As a young impressionable programmer I drank that Kool Aid.
• MichaelMoser123 3y ago
  > I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators. Nothing is eternal. Some dependencies, like CPAN modules, need to build stuff in C (during installation). It is impossible to know if these dependencies will install and build 'unaltered 10 years from now'.