http://qs321.pair.com?node_id=11138781


in reply to What technical benfits perl offers over python + few more questions.

Cool. I use Getopt::Long for dealing with command line arguments, and in the past I have used Spreadsheet::ParseExcel for reading Excel spreadsheets. Both modules work very well.

OK, those are valid comments .. but it would be nice to see a link to the articles in which these claims are made, so that we can answer the specific issues that are raised. 1. Perl does a pretty good job or error handling (Try::Tiny comes to mind); 2. I'm not sure I understand how a function can be thought of as a second-class citizen; and 3. One of the things that Perl does an excellent job at is reporting. (I think reporting was one of the tasks it was used for, very early on). So at this point, I'd quote wikipedia.org and say, "Citation(s) required".

If you want the most bang for the buck, I would suggest continuing with the language you already know (Perl) so that you can be as effective as possible at your job. If you have time after work, you could spend an hour here and there learning Python, starting off with simple programs, and perhaps moving on to more complicated tasks, such as parsing command line arguments.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

  • Comment on Re: What technical benfits perl offers over python + few more questions.

Replies are listed 'Best First'.
Re^2: What technical benfits perl offers over python + few more questions. (first class functions)
by LanX (Saint) on Nov 13, 2021 at 15:46 UTC
    > 2. I'm not sure I understand how a function can be thought of as a second-class citizen;

    because that's FUD

    "First class object" aka citizen basically means you can pass functions around as arguments to other functions. E.G. most BASIC dialects I've seen couldn't do that.

    It's a necessity for functional programming...

    Perl is actually better in functional programming, since Python is restricting lambdas to one expressions only, while anonymous subs are free.

    And Python doesn't offer any block prototype to make it even easier like sub foo (&) { $code = shift; ... }

    Superficial people will claim that the need to explicitly reference named subs in Perl with ...

    \&foo

    means they are not first class.

    Superficially so because almost everything in Python is implicitly a reference.

    Now, who said explicit is better than implicit again ...???

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

        because that's FUD

      Huh .. too bad. I dealt with FUD with Microsoft continually slamming OS/2 in the late 80's, where we slagged Windows NT on the Canopus form on Compuserve. Good times.

      I developed code in C before moving to Perl in the late 90's, and was advanced enough that I was comfortable using function pointers in my code .. so when I wanted to do the same thing Perl, it was there already. Perfect, because being able to declare a callback function (one example of a function pointer) is extremely handy.

      And I don't really care what the TIOBE results say .. if a CTO contacts me to say 'Perl developers are really hard to find' and 'Are you available?', I don't find the burning need to go learn a different language. And, of course, the Perl community has been very supportive and welcoming. So I'm not going anywhere anyway. :)

      Alex / talexb / Toronto

      Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Re^2: What technical benfits perl offers over python + few more questions.
by perlfan (Vicar) on Nov 13, 2021 at 16:34 UTC
    OP - in addition to the advice above, I'd like to point you to the concept of a modulino. If you're doing mostly scripts, this approach will allow you to walk the line between scripts and modules (libraries). Which is good for "code reuse" when it makes sense. I also highly recommend you take a look at Util::H2O. It is great for cleaning up old crust scripts that heavily use hash references (the sign of a mature Perl developer) and can make your modulinos even more pleasant to work with.

    Finally, I must also point out. A lot of times it's okay to use bash. I maintain a mix of Perl and bash scripts; your tolerance and own needs will guide you where the "line" for that decision is.

      Which is good for "code reuse"

      Doing

      package Modulino; sub main { } caller() ? 1 : main;
      perl "$( perldoc -lm Modulino )"
      is not better for code reuse over the traditional
      package Modulino; sub main { } 1
      perl -MModulino -emain