Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Why Perl?

by Preceptor (Chaplain)
on Jul 17, 2013 at 15:06 UTC ( #1044833=perlmeditation: print w/ replies, xml ) Need Help??

I'm sure everyone's run into it - the holy war between Perl and the various alternative scripting languages there are out there. As a Storage Engineer, who grew up with Unix, I ... well, sort of fell into it as the next best choice after 'plain' Bourne Shell scripting. Not 'bash' that wasn't always available - 'being installed everywhere' was important, and where it wasn't, well ... why not use something a bit more fully featured?

One of the things I'm thinking of doing, is pulling together some of my colleagues, to introduce them to scripting - and for obvious reasons, that'll be with Perl. I expect one of them will ask me 'why?' - this is from a set of people who have experience will all sorts, up to and including a guy who writes very extensive scripts in 'awk'.

So my list of 'Why Perl':

  • Because it's often installed by default.
  • Because it's readily available on every platform (at least, those I've run into)
  • There are a lot of existing modules to tap into
  • There is a lot of expertise to draw upon (Perlmonks)
  • You don't need to do much to move from 'shell script' to 'perl script'...
  • It's really good for the types of task that you tend to do a lot of, when doing 'systems programming'. Running commands, capturing and parsing output.
  • ... But despite that it's a powerful enough language that you can go a lot further with ease. (OO programming, multithreading, to name a few.)
  • I get along with it better than the other languages I've worked with.

But I thought I'd raw upon the further Wisdom of the Monks - when asked 'Why Perl?' what answer do _you_ give?

Comment on Why Perl?
Re: Why Perl?
by toolic (Chancellor) on Jul 17, 2013 at 15:15 UTC
    In addition to your list...
    • Well-documented (perldoc)
    • Good bug-reporting (perlbug, CPAN RT)
    • Open source: you can contribute new code, patches, etc.
    • Constantly under development
Re: Why Perl?
by ww (Bishop) on Jul 17, 2013 at 15:25 UTC
    Minor amendments -- don't turn off the cow-orkers who might have other preconceptions:
    1. Because it's often usually installed by default on nix-ish boxen.
    2. Because it's readily available on every platform (at least, those I've run into) virtually every significant platform newer than CP/M 86.
    3. There are a lot of existing modules to tap into
    4. There is a lot of expertise to draw upon (Perlmonks,some .edu tuts, other sites).
    5. You don't need to do much to move Start moving from 'shell script' to 'perl script'...
    6. It's really good for the types of task that you tend to do a lot of, when doing 'systems programming'. Running commands, capturing and parsing output.
    7. ... But despite that it's a powerful enough language that you can go a lot further with ease. (OO programming, multithreading, to name a few.)
    8. I get along with it better than the other languages I've worked with.

    Or, to put it another way, it offers a good way to do almost anything other than washing windows and putting the toothpaste back in the tube.

    :-)
    If I've misconstrued your question or the logic needed to answer it, I offer my apologies to all those electrons which were inconvenienced by the creation of this post.
      Because it's often usually installed by default on nix-ish boxen.

      OK, I'll bite. Go ahead and name any nix-ish distro released in the last decade that didn't/doesn't come with perl installed by default. :-)

        No, I take that point - I work with some production systems that it's been necessary to really lock it down. For all the reasons Perl is a really handy scripting language, it's also a security risk. I do have to touch systems that are extremely locked down - I've just about won the war about why 'vi' is an acceptable risk. But compilers and interpreters are fabulous ways to leverage an exploit.

        But in that scenario - the only scripting language that's available is shell.

Re: Why Perl?
by Your Mother (Canon) on Jul 17, 2013 at 15:39 UTC

    Because Java. That's why.

    See what I did there?

      Because PowerShell.

      See what I don't do there :)


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      Actually no, I don't really. You can consider all programming languages to be tools. Some tools are better suited than others to certain jobs.

      I'm not so fixated on Perl that I don't realise there's other tools out there, some of which are better suited. But at the same time, with a programming language there's an overhead to learning a new one. So you end up with a tradeoff between ease of use, and suitability as a toolset. I think Perl does well at that - it may not be as good at a specific job as a specific alternative, but it's pretty good at almost anything you could throw at it. Java... well, I just don't get along with Java. But that's prejudice rather than because there's anything particularly wrong with it as a language.

        Iím sorry if that was too Internetese. The joke is -> Q: Why? A: Because f*** you Java, thatís why.

        You are completely right that itís all just a collection of tools and some have more complete libraries for a given task than others. What follows is nothing but a G thang my take.

        PHP is fine as long as I donít accidentally fall in one its manifold sink holes.

        I could learn to enjoy Python and restrain my design instincts enough to not flinch when I have to look at it.

        I could learn to love Ruby and forgive it for some of its troubling side cars.

        I could be intimidated enough by Lisp to get good at it in defense of my own IQ and self-esteem.

        Et ceteraÖ

        I would rather work retail during the holidays than work with Java full time. I realize it has the best libraries for quite a few things and I use some of them. I would rather rewrite or port any given library from scratch than be stuck using it as anything other than a black box.

        You got good real advice from others though. :P

Re: Why Perl?
by 5mi11er (Deacon) on Jul 17, 2013 at 16:18 UTC
    If you're attempting to get people to move to perl away from what they use now, that may not go over very well.

    What I would suggest is to stress that you're giving them a taste of another tool that is available to them and I suspect it will go over better, and you might come away with one or two people to actually want to try it out; that's better than the n people who will resist if you try to force it on them (where n is the number of people in your group).

    If you get 1 or 2 who have success in the short term, that may prompt others to take a closer look, but I suspect your AWK guy is probably not ever going to be persuaded.

    -Scott

      I've got a mix - some who don't know scripting at all, some who've 'done a bit of shell' and a few others that have done some amazing hacky monstrosities in shell. (which works, but only as long as no one sneezes anywhere near). I'm not trying to convert them - not entirely - more give them an opportunity to learn something that might be useful. I think there's definite advantages to a fairly standard approach, but failing that at least _some_ mutual understanding is useful/necessary. (And I'm not planning on stopping with Perl, just because someone else has only seen VBS).

Re: Why Perl?
by BrowserUk (Pope) on Jul 17, 2013 at 16:35 UTC

    Don't teach, nor preach. Demonstrate.

    If these are "close colleagues", you'll have a very good idea of the type of tasks they regularly encounter, and those that they find most difficult to deal with.

    Solve that problem with perl -- but before you take it to them; post it here and ask for improvements.

    Once you've selected the best approach -- by your personal (assessment of their) criteria -- set them that task; or preferably, challenge them to solve it.

    Then compare notes. Your (PM optimised) solution versus their <insert tool name> solutions.

    Do it right, and you'll get some takers.

    Do it twice -- with one of the early adopters providing the 'winning' solution (by their criteria not yours!) -- and you'll get lots of takers.

    No marketing; deception nor sleight of hand. Just good code demonstrating its worth.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      I'm halfway there - there's a selection of things I've done (in Perl) that have been enough to interest people. A couple of thing sufficiently complicated that doing it in a shell script is a terrifying prospect. A couple of others that some just didn't really realise was feasible. (XML Parsing some command outputs to drive some automated reporting).

      Several have expressed an interest in learning more - not least, because there's at least two scripts I use that whilst not strictly essential, there's a lot of envy of how easy I've made my life. (And then there's one or two scripts that were put in place as workarounds, but the underlying cause isn't going to get fixed any time soon, either).

Re: Why Perl?
by davido (Archbishop) on Jul 17, 2013 at 19:08 UTC

    Because you can.....

    # do really useful things in a few lines of code # using a "baby" subset of the language.

    The implementation of "really useful things in a few lines of code using a 'baby' subset of the language" is left as an exercise for the demonstrator. ;)


    Seriously, the best way to get someone into Perl isn't to tout its undeniable superiority to other alternatives. Doing that will raise the defenses of those who already feel their preference is the "one true language." The best way is to take some task you do every day, and solve it with Perl code while leveraging Perl's strengths and avoiding its more advanced capabilities. If you can do that using core modules, fantastic. If you need a CPAN module, your discussion will need to start by showing the simplicity with which CPAN modules can be installed.

    Here's an outline:

    • Every day I found myself needing to ________________, so I decided to automate it using Perl.
    • I needed This::Whizzbang::Module, so I typed cpan install This::Whizzbang::Module.
    • I also needed These::Other::Modules, and they were part of the standard core Perl distribution.
    • First I created a code framework to start with; it looked like:
      #!/usr/bin/env perl use strict; use warnings; use Some::Core::Modules; use My::Whizzbang::CPAN::Module; ...
    • Then I connected the dots with the following code...
    • Now I relax on the white sandy beaches of Palawan while my 15 line script does my work for me, logs it to a logfile, and emails me when there's a problem (because all scripts eventually evolve to the point of sending email).
    • Thank you... Questions?

    As questions come up, use them as an opportunity to segue into topics like the CPAN smoke testers, Perl's committment to backward compatibility, Perl's leading role in advancing pattern matching techniques, concise syntax capable of rich expression, and so forth. Let those topics "come up" rather than forcing them upon Pythonistas. ;)

    Throughout the discussion, suggest that you actually enjoy other languages too; that you might have done this using XYZ language, but that the module your using already did most of the work for you; that a shell script might have been adequate, but that Perl provides testing tools that helped you to gain a confidence that your code was correct, etc. When people raise opinions that they might have done this using Ruby, Python, C, etc., "Yes, that might be a nice approach also. I'm just demonstrating how simple it is with Perl. I suspect your implementation take a similar course regardless of the language."

    This type of approach worked fairly well when I had to address a Unix user's group once, where we seemed to start off on the wrong foot as one trouble-maker wanted to just scoff at Perl. By the end, his disdain seemed to be more under control, and everyone else seemed to be genuinely interested.


    Dave

Re: Why Perl?
by Discipulus (Deacon) on Jul 18, 2013 at 08:13 UTC
    ..beacause it's really worth the effort to learn it.

    Really you can start doing simple things in a simple way and then discover that there is always a perlish way to front a new problem: complex data structures, DBI, CGI, Tk, sockets, image manipulation, math, LWP, web frameworks, PSGI and Plack, XML, regular expressions, Moose...

    Because Perl let you to be free (as in freedom): from a glue script to an introspected translucent OO system you can choose your way to do the work.

    Beacause there are good book to read about it on every step of your learning curve: my first love (wonderfull for a newcomer to Perl, even if somehow outdated)Perl Cookbook, High Order Perl, Modern Perl...

    Because of oneliners: when you master some switch the console becomes a playground...

    Beacause you can easily write portable programs. More: if you run on win you can produce standalone exucutables and use portable Perl gently Strawberry flawored...

    Because of cpan and perlmonks..

    Because the magic is at your disposal: BEGIN and company,__DATA__,signals, symbol table. The compiler is by your side, invisible but present: eval!

    Because if you learn it well you'll be rewarded in the escathological day of Perl 6 advent... ;=)

    L*

    there are no rules, there are no thumbs..
Re: Why Perl?
by DrHyde (Prior) on Jul 18, 2013 at 10:01 UTC
    I'll counter your points with:
    • So's python
    • So's python
    • Likewise with python (although admittedly not as good as the CPAN)
    • Likewise python
    • But you probably don't want to
    • Yup, but that's not what most people do these days. It might apply to your group, but even then they'd probably be better off using proper APIs instead of "screen scraping"
    • Just like python
    • Your personal taste is not a good reason for other people to use it

    :-)

    Of all your reasons, the only one that I find compelling is that there are lots of useful things on the CPAN.

      Yes, Python is a good scripting language. What point are you trying to make though? Would you assert it's a _better_ choice?

      My personal taste isn't a reason to make other people use it, no. But my knowledge of it means it's something I can teach them how to use, when I can't of something I'm _not_ familiar with.

        In environments like the one that you're describing my main reason for preferring Perl over Python is that typically more people are already basically familiar with Perl. If you want someone to start programming full time then Python is a good choice, but people who just want to automate a small piece of their daily work or move some simple shell scripts into something slightly more advanced usually can make faster progress with Perl.

        One of the reasons behind that I think is that Perl is closer to C. So in companies where the main code base is C that is a big plus point for Perl.

        That's just my opinion, though, maybe in other organisations that looks completely different.

        What point are you trying to make though?

        My point is that the OP's list of reasons "why perl" aren't very good reasons, because they mostly don't separate perl from the herd of other languages. "It's what I know and so it's what I can teach" is, however, an excellent reason for teaching in perl, provided that the desired end point isn't "the students know perl" but "the students know a dynamic language" or something like that.

        They can then use their new knowledge of programming (gained via the medium of perl) in whatever similar language they find is most appropriate for the task at hand. IME the choice of which language is most appropriate is hardly ever determined by technical or linguistic matters, but by what your colleagues are most familiar with and what they've already got code written in. Taking my current job and task as an example, the best language from a technical PoV would probably be something like SML or Haskell, because I'm constantly getting my arse kicked by data type problems. But the rest of the application has already been written in perl, by perl programmers, so the best language from the social PoV (which is more important than the technical PoV) is perl.

      CPAN is both bad and good. For example, how many XML parsing modules are there? Do you know which ones are best? Fastest?

      I personally love the CPAN (name another langauge that can give you Lord of the Rings dates like Date::Tolkien::Shire can or comes with a built-in Enigma machine like Crypt::Enigma can provide). But sometimes there are too many choices, and lots of cruft to wade through.

        CPAN is both bad and good. For example, how many XML parsing modules are there? Do you know which ones are best? Fastest?
        Now that is a strange argument. Would you be happier if your choice was limited to only one mediocre module rather than 10 modules ranging from bad to excellent?

        I have over twenty screwdrivers in my toolchest. None of them will be good for all jobs. Some are versatile, some are specialized; Some I may have used only once (but I was oh so happy I had the right tool at my disposal then), some are used almost daily. Will I throw them away when someone invents a screwdriver that can work more-or-less-somewhat-OK in all circumstances? Of course not! The more choice there is, the better. Yes, it will take a while to get used to your tools and you have to build up experience to know when to use which tool, but after a while your hand grabs the right one without thinking.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        My blog: Imperial Deltronics
Re: Why Perl?
by j0se (Pilgrim) on Jul 18, 2013 at 10:34 UTC
Re: Why Perl?
by eyepopslikeamosquito (Canon) on Jul 18, 2013 at 11:48 UTC
Re: Why Perl?
by blue_cowdawg (Prior) on Jul 19, 2013 at 13:41 UTC

    when I first started my perl blog the first article I posted was on this subject: Why I still use Perl.


    Peter L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
Re: Why Perl?
by perl514 (Pilgrim) on Jul 20, 2013 at 10:07 UTC

    Hi,

    Glad to see a fellow storage guy here !!. As already stated by a few Monks here, that the best way to convince them is do some automation with Perl. That will be the moment that you can get them hooked to Perl. One or two initial automation scripts will have them convinced.

    Perlpetually Indebted To PerlMonks

    use Learning::Perl; use Beginning::Perl::Ovid; print "Awesome Books";
    http://dwimperl.com/windows.html is a boon for Windows.

      In terms of storage, I find hooking into EMC's 'Solutions Enabler' using Perl to be quite effective - most of the commands will give me XML output, which I've been using XML::Twig to parse. Primarily from a view of treating arrays as data sources, and generating reports - allocations, tiers, customers, quotes etc. My next line of though it that I want to start automating the provisioning process, as part of formal change control.

        Hi,

        Even more glad to know that you are a fellow EMC Symmetrix (DMX/VMAX) fellow :)

        Well, I am just about to start with a few things for DMX/VMAX, but the stuff I have done till date is capturing the status output for Celerra, and capturing host logged out records for 3PAR. Net::SSH2 is an awesome module and so is Config::Tiny. Incidentally, compared to 3PAR cli output, EMC cli outputs are much much better. They lend naturally to a lot of slicing and dicing stuff.

        If you happen to face a situation where you have to run the scripts from a windows host, please try out DWIM Perl. It comes with a lot of modules pre installed.

        Once again, good to see a fellow EMC Storage guy here. ;)

        Perlpetually Indebted To PerlMonks

        use Learning::Perl; use Beginning::Perl::Ovid; print "Awesome Books";
        http://dwimperl.com/windows.html is a boon for Windows.

        Little known fact: When you install Solutions Enabler, you get a full Perl installation! It's buried and a little out-of-date, but it includes XML::Simple, which can be a life saver at client sites where installing CPAN modules is difficult due to firewall issues, etc. (This link will be useless to non-EMC employees, but please check out http://one.emc.com/clearspace/docs/DOC-79190 and send me some feedback.)
Re: Why Perl?
by Laurent_R (Vicar) on Jul 21, 2013 at 15:57 UTC

    Just my personal experience. I have been using at least 30 differents programming languages in my life. In the late 1990s, I was using TCL/TK. Essentially because of TK, I did not like too much the TCL semantics, more practical that shell scripting, but the feeling of not being always sure whether I was going to use the content of the variable or its name. I moved to Python in about 2000 or 2001. Loved it. Used it quite a lot at the time. Really excellent to do a quick script. At the time, I had read some articles to the effect that Perl was so ecclectic that you needed a dozen books before you could start to do something. I thought at the time that I would stay away from Perl.

    Then, in early 2002, I started to work on a large data migration project. A very large part of the standard migration suite used at the time consisted of a couple of hundred Perl scripts, most of them with just a few dozens of lines, some with a couple of hundred lines, usually not more. I thought it would be sensible on my part to try to understand this language. With no intention, at the time, to really use it.

    I picked up a Perl tutorial on the Net and spent a few hours reading it, trying to write very small scripts to get a gist of it. I really found it easy and powerful. A few days later, I had to write a one-off script to reprocess some very large files. For some reason, I strangely decided to try to do it in Perl (for sure, it would have been easier for me at the time to do it in Python). In fact, it took me just a couple of hours to write the script in what I would call today baby Perl. I probably would not want to look again today at the ugly piece of code I wrote then. Sure, I had the -w flag switched on, but no use strict, no 3-args file opening syntax, most probably very clumsy formulations, poor awkish regexes, etc. But my point is this: after using a Perl tutorial for about 3 or 4 hours, I was able to write an actually useful program for my job. I no longer have this program, but I would certainly consider today that it was not really looking professional, I would most probably rewrite it completely, but it worked and did exactly what I needed, and did it fast. And, to paraphrase a sentence in the Camel book, what I did not know did not hurt me.

    To make a long story short, I used Perl again next time I needed something similar, and again and again. I am still using some other programming languages, but whenever possible, I am using Perl. And my point is: I have never seen any other language where you can actually do something actually useful for professional purposes within less than a day for learning the language and developping the program.

      Because even on Windows you simply install redhat cygwin and you have it all...
Re: Why Perl?
by sundialsvc4 (Monsignor) on Jul 23, 2013 at 14:41 UTC

    They call Perl “the Swiss Army® Knife of practical computer programming” for, I think, two main reasons:

    1. It’s very efficient at ripping huge files of strings apart (with its excellent regular-expression implementation), building complex data-structures in memory (with its references system and its very powerful hash-tables), and thereby efficiently doing the sort of things that we “do for a living.”
    2. CPAN ... need I say more.   Many thousands of modules which you can “simply retrieve and drop in,” in order to do just about anything you can imagine.   The modules adapt themselves to your system as necessary and rigorously self-test themselves, so you have a high degree of confidence in them.   This one thing is, to me at least, what Perl is all about.

    And I will simply stop short of any “Perl vs. that” arguments, because such a thing just doesn’t make any sense.   Most of us use several languages all the time, and have used many more.   (Given sufficient Pepto-Bismol® and in-flight barf-bags, that even includes Java.)   ;-)   Perl is a well-built system ... a little quirky, sure, but aren’t they all.   When you want to haul a train-load of revenue freight, you look at the power and the dependability of the locomotive, not its quirks.   Asserting that you have found one language to be good in this regard, doesn’t speak ill of any other one, and also doesn’t mean that you don’t regularly use them also.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1044833]
Approved by toolic
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (12)
As of 2014-07-28 14:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (200 votes), past polls