Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Perl applications

by rje (Deacon)
on Apr 07, 2004 at 17:59 UTC ( #343360=perlquestion: print w/ replies, xml ) Need Help??
rje has asked for the wisdom of the Perl Monks concerning the following question:

Gentlemonks,

Perl has recently come under fire here at work, because the general consensus is that Perl's only cut out for small admin tools. The jabs I've heard go along the lines of "sure, but try to write a complex server using Perl!".

Frankly I don't know how to respond. I suppose if I had the inclination and time I'd write a complex server in Perl "just to show 'em!", but I have neither. Perhaps someone can point me at some Perl contender programs?

Thanks all. And now back to your regularly scheduled program.

Updated after reading post from Neil Watson:

Our company is half Delphi, half Java, with me on the Java side. The chief deprecator is a C++ fan, who is a nice guy and quite a good designer too. He worries about code complexity, maintenance, and project scope when Perl is mentioned. Of course, I told him that good designers produce good code, rather than the other way around. I also informed him that the TK widget set is essentially standard with Perl (is that still true?), though Java appears to have more polished GUIs.

It seems that after pressing hard enough, he finally complains that, because Perl reads in its source code directly (rather than a bytecoded compiled version), it's therefore inferior to 'compiled' languages. Then he maintains his position that Perl was not meant for large application development.

'Nother update

Thanks to the responders so far -- I cobbled together a formidable list from the responses and links given so far. Thank you very much!

  • Spamassassin is Perl.

  • Motorola uses it to test their base-stations by simulating a telco switch. In fact, that tool was used at Ground-Zero to look for cellphone signals. A group-leader strapped a portable base-station on his back and they connected a laptop to it running Cygwin.

  • Perl makes over M$100/year for MasterCard as a reporting tool for their business customers. In that group, it replaced a Visual C++ app. A Java app was written to replace it, but the Java developers are now learning Perl.

  • Another company is using it as a major driver of new sales. They expect around 40% of new sales to benefit directly from Perl apps. They're a M$100+ company, with less than 200 employees, most of which are not IT.

  • Lists of apps and success stories are at: here and here.

  • The Radius server is in Perl.

  • This company translates PDF documents with Perl

  • Then there's Webmin, which uses Perl and Java together.

  • And, of course, a 100% Perl HTTP webserver: small, lightweight, reliable, and secure.


    Yet Another Update acomjean makes the point that
    "I think perl gets a bad rap because if you are not familiar with it the syntax is hard (bad I think) $_ and <> are confusing to those not used to them. I've used a lot of languages and the perl syntax still throws me sometimes.

    He's surely correct. But I wonder if it's deeper than that. Maybe this is some kind of brain-boundary thing, where one wiring prefers one expression, and another to another.

    Programmers already know that learning a language is not trivial (if every language were like every other language, why learn a new one?). There will be unusual formations to any language (except perfectly regular ones, which are prone to being boring in my opinion).

    In Perl's case the unusual formations are the shorthand used to get things done quicker. Larry's Hypotenuses.

    And perhaps some programmers don't like shorthand (Java anyone? How about COBOL?).
  • Comment on Perl applications
    Download Code
    Re: Perl applications
    by esskar (Deacon) on Apr 07, 2004 at 18:05 UTC
    Re: Perl applications
    by Enlil (Parson) on Apr 07, 2004 at 18:20 UTC
      There are a couple of other products mentioned in this thread

      -enlil

    Re: Perl applications
    by jdporter (Canon) on Apr 07, 2004 at 18:21 UTC
      One place you should look is Perl Success Stories on perl.com.

      jdporter
      The 6th Rule of Perl Club is -- There is no Rule #6.

    Re: Perl applications
    by neilwatson (Curate) on Apr 07, 2004 at 18:22 UTC
      And the many extensions of Apache do not count as "a complex server"? There is nothing small about the power of mod_perl.

      Neil Watson
      watson-wilson.ca

        It's also not written in Perl. It just interprets it using compiled C code with some glue to provide Perl code an interface into the rest of the server.

        ----
        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

    Re: Perl applications
    by davido (Archbishop) on Apr 07, 2004 at 18:23 UTC
      There's always The little webserver that does tiny things; otherwise known as "the sleek and popular 100% Perl webserver."

      It's about 10k worth of Perl code that uses no non-core modules. I haven't run it though, but it claims to be a fairly full implementation.


      Dave

    Re: Perl applications
    by dragonchild (Archbishop) on Apr 07, 2004 at 18:28 UTC
      Write a complex server using Perl. Hrmmm ... that seems to be what my career is - writing complex appservers in Perl.

      As for some stories ...

      • Motorola uses it to test their base-stations by simulating a telco switch. In fact, that tool (which I worked on) was used at Ground-Zero to look for cellphone signals. My former group-leader strapped a portable base-station on his back and they connected a laptop to it running Cygwin.
      • It makes over M$100/year for MasterCard as a reporting tool for their business customers. In that group, it replaced a Visual C++ app. A Java app was written to replace it, but the Java developers are now learning Perl.
      • The company I work at right now is using it as a major driver of new sales. We expect around 40% of our new sales to benefit directly from our Perl apps. We're a M$100+ company, with less than 200 employees, most of which are not IT.

      I don't know about you, but those sounds like non-trivial applications.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    Re: Perl applications
    by flyingmoose (Priest) on Apr 07, 2004 at 18:49 UTC
      Sad you have to fight bigotry in the workplace -- this is something I have already tried to fight, but due to people having closed minds, I only can do Perl stuff under the table when I don't have the team engaged. It's very sad, since I love Perl for it's awesome CPAN support, functional programming, and the ability to do some really slick stuff. What's more, I write some really high quality Perl code (if I may so) and the "unmaintainability" jabs I get are not justified. It's rather cruel really.

      Anyhow, a few good apps: Webmin is fine example of both an HTTP web server and some very powerful administration tools. YABB has a very good Perl-based message board. Frozen Bubble will show them that Perl can be used for advanced Linux games with good graphics and sound. I also believe amazon.com is powered by Perl.

      Update: I note you are summarizing things in your article. I never said webmin used Perl and Java together. Last time I checked, webmin uses java only for a little puny applet, and the program is 99.9% perl. In fact, I've never used the java applet. Anyhow, it's best not to mention Java as it gives java too much credit. Webmin is very cool, but I've grown closer to Linux (and vi and find and locate and grep) and I don't use it anymore. It's definitely good if you use a lot of distributions and don't know the differences between them.

        I wouldn't use YaBB as an example - I've looked at the code in detail, and it's really badly written. It's applications like YaBB that get perl it's reputation as being unmaintainable. Of course, those who criticise perl like that rarely look at the horrible mess that is the vim source code^W^W^W^Walmost all C code^W^Wcode anywhere.
    Re: Perl applications
    by neilwatson (Curate) on Apr 07, 2004 at 18:55 UTC
      I think it would be helpful if you clarify what type of applications you are asking about. Client/server, web-based, stand-alone, console, gui...

      Neil Watson
      watson-wilson.ca

    Re: Perl applications
    by Aragorn (Curate) on Apr 07, 2004 at 18:57 UTC
      At the ISP where I work, we use Perl for practically everything, except the most performance-critical stuff. Things like the billing system, business database and automated ordering system are practically completely built with Perl. Of course, it's also used for building system administration tools.

      I find it funny for a C++ fan to worry about code complexity and maintenance when Perl is used. Perl is often castigated for having a lot of quirks and dusty corners. I'm not an experienced C++ programmer, but I do have the "C++ Programming Language, Special Edition" hardcover tome, and it seems to me that C++ gives you at least as much oppurtunity to screw things up royally as Perl does. But that's just my opinion ;-)

      Arjen

    Re: Perl applications
    by perrin (Chancellor) on Apr 07, 2004 at 19:47 UTC
      You should tell the guy who doubts perl can be used for large applications that several large applications he probably uses frequently are partially or entirely written in perl: amazon.com, ticketmaster.com, citysearch.com, yahoo.com, imdb.com, etc.
        Also the always mentioned slashcode (Slashdot) and Everything (perlmonks) It might be interesting to see what the load on Slashdot is I could not find it but I know they post it somewhere.

        Just to add, i think that one of Perl's downfalls is it's the Swiss army knife of programming languages. Its almost too versitile and it spans all needs. Not being the flavor of the month makes people forget it's power. They then jump on other languages. Just like the knife, it can open a bottle of wine, but if you have the latest Digital one-stroke bottle opener with dynamic feedback which one are you going to use.

        But then the digital bottle opener wont help you when you need to open that box sitting on your desk.

        Note: I am in the process of learning a little Java to expand my personal world. Although I don't think I will ever lose my perl bias.
          I don't mention Slashdot because it gets very little traffic compared to mainstream sites like the ones I mentioned. If you notice, the only sites that get "Slashdotted" are ones with very low bandwidth. Slashdot happens to link to lots of personal, academic, or just plain small sites, which is why you see it happen so often.

        Mason HQ has a list of perl/mason sites, with Amazon at the top of the list, IIRC. I can't give a direct link right now because the site is not responding.

        qq

    Re: Perl applications
    by acomjean (Sexton) on Apr 07, 2004 at 20:06 UTC
      I think perl gets a bad rap because if you are not familiar with it the syntax is hard (bad I think) $_ and <> are confusing to those not used to them. I've used a lot of languages and the perl syntax still throws me sometimes.

      Personlly I find perl code hard to read, there are worse, C++(STL) and scheme come to mind. I write mainly in C and ada and use perl/tk for testing. I used to do a lot of java. We also use perl instead of shell scripts because its more cross platform.

      However using perl to program our applications is not an option, as quite frankly its not reliable enough and has too much non-deterministic behavour plus it doesn't have some of the constructs we need. Its not strongly typed makes it easier to write prorgrams, however this can make the software less reliable if not used very carefully. I think exception handling in perl might me somewhat lacking to but I'm not entirely sure of this.

      I can see writing small to medium size applications comfortably in perl. I perfer to write anything with a gui using java/eclipse. I like java alot because I find the class libraries a quite good and cross platform. This is a Personal preference I'll freely admit.

      I'm always an advocate of trying whats out there and using the right programming language for the job. Perl is great for a lot of things, but its not the be-all end-all programming language although cpan has alot of functionality.. No language is best at everything.... yet. Heck I didn't like ada at first, now I like it a lot..

        However using perl to program our applications is not an option, as quite frankly its not reliable enough
        What does "not reliable enough" mean, exactly? A piece of perl code randomly stops working one day?
        and has too much non-deterministic behavour
        Uhm. Like what?
        plus it doesn't have some of the constructs we need.
        Again: What constructs are you missing that you can't possibly implement (easily even) in perl?
        Its not strongly typed
        This is just wrong. Perl is strongly typed: scalars, lists, hashes. This is as opposed to languages like C and java which aren't strongly typed.
          I'm late answering, but I will. Sorry I was away.

          Reliable enough means can not stop. Or if it does stop games over. Without too much detail we disable interupts on some of our processors so we can get quasi real time performance for the lone process on the processor. They must stay running for a long long long time or die gracefully. If they crash we lose the cpu the process is running on till a reboot so that isn't an option.

          One of ada's really cool features is to allow you to rep-spec any record (struct in c). This allows you allign the data structure to match input messages from various bits of hardware (ie the status byte starts at byte 4, bit3 and is 8 bits long). This is harder in perl, although it probably could be done. .

          Stongly Typed. When we compile the compiler checks all the assignment to make sure they're legal and legit and won't cause problems. Its not an end all but it helps a lot. We also contrain types. For example an integer to between 10 and 20. If the variable ever gets out of this range during run time an exception is thrown and handled by other parts of our code. Its excessive but it has to be. especially when you sending data out that might turn a motor etc. That way external hardware is never getting data out of range.

          Ada coding is slow and the support is poor. We have to write some of our own libraries or bind to C. Perl has a much more robust user base and libraries. Perl is great for a lot of things and can be coded to be pretty reliable. For somethings there are better solutions.

        Of course you're right. But I wonder if it's deeper than that. Maybe this is some kind of brain-boundary thing, where one wiring prefers one expression, and another to another.

        Programmers already know that learning a language is not trivial (if every language were like every other language, why learn a new one?). There will be unusual formations to any language (except perfectly regular ones, which are prone to being boring in my opinion).

        In Perl's case the unusual formations are the shorthand used to get things done quicker. Larry's Hypotenuses.

        And perhaps some programmers don't like shorthand (Java anyone? How about COBOL?).
    Re: Perl applications
    by chromatic (Archbishop) on Apr 07, 2004 at 20:26 UTC
      It seems that after pressing hard enough, he finally complains that, because Perl reads in its source code directly (rather than a bytecoded compiled version), it's therefore inferior to 'compiled' languages.

      Does a Perl program run directly not count as a serious program while the same program run from PAR does?

      "sure, but try to write a complex server using Perl!"

      Perhaps POE or Soap::Lite or Stem would do?

      Once the program's running, does it matter what form the program takes on disk? Does a "compiled" and statically typed language block on input from a network socket any faster than an "uncompiled" dynamically-typed language?

      Then again, I try not to argue with people who believe that magic fairies live in your CPU and interpret binaries directly. Eventually, they'll realize that it's not 1970 anymore.

        We had magic fairies in 1970? Man, I was born waaaaay too late. Not only was the music much better then, but even such minor magic creatures as compiler gremlins are hard to come by these days.

        *ducks*

    Re: Perl applications
    by Art_XIV (Hermit) on Apr 07, 2004 at 21:18 UTC

      I find that many, and maybe even most, high-quality developers are intrigued by Perl after trying it even if it is ultimately not their cup of tea.

      A consultant-dude (article here) made the interesting assertion that geeks choose programming languages based upon social/psychological reasons, and then use a language's technical merits to justify their selection. The more I think about it, the more I think this guy is correct.

      If more developers were intellectually honest about their languages choices, the following might be heard when discussing programming languages:

      • "I think we should use language x because I already know Language X."
      • "It's gonna look awful good on my resume if I have a project or two done in Language X."
      • "I don't know Language X, the company is not going to pay to train me in Language X, and I have absolutely no intention of giving up my TV time to learn Language X on my own, so Language X is no good."
      • "I knew this programmer who was a real jerk and he liked Language X. Since it is obvious to me that only jerks like Language X, I shall refrain from using Language X."
      • "The sales-rep/trainer for Language X is a good-lookin' babe/dude. I think that we should use Language X so that he/she can visit us more often."

      Perl is absolutely up to most industrial-strength tasks, as you can see from the postings of others in this thread.

      Although Perl's performance on a machine can be and often is slower than C++, Java (Newer versions!) and others there can be little credible argument against the observation that Perl programs can be created a lot faster, which is very important since development time is the biggest cost in practically every software project.

      As stated by others, the developers are what really matters, anyway. A dedicated, self-disciplined, thoughtful developer with an understanding of the problem-space should be able to create something good and high-quality with any modern language that he or she takes the time to become adept in.

      Besides - in the spirit of being intellectually honest - I think that Perl is just a whole lot more fun to code in than most other languages. I find it to be the most rewarding language that I have ever taken the time to learn. Perl has appealing agility, style, humility, understanding and grace despite its faults... by comparison, most other languages seem more like that guy who just can't figure out how to use the stinkin' ATM machine. You know, that guy. ;)

      Hanlon's Razor - "Never attribute to malice that which can be adequately explained by stupidity"
        you're right, the word to define perl programming is: rewarding.
        i could not have said it better


        ignorance, the plague is everywhere
        --guttermouth
    Re: Perl applications
    by Anonymous Monk on Apr 07, 2004 at 22:06 UTC
      MON - monitoring server used at our site for monitoring of ~150 servers with various tests at ping,telnet,ftp,ldap,radius,pop3,imap,oracle,mysql,... via SNMP - UPS, switches etc mon site
    Re: Perl applications
    by runrig (Abbot) on Apr 07, 2004 at 22:20 UTC

      Java is no more and no less a compiled language than Perl is. Java is compiled to p-code which then requires a separate run-time interpreter (We do the same thing here where I work with 4GL). Perl is compiled at runtime (very quickly) to some sort of op-code tree which is then interpreted by the built-in interpreter. Not having to explicitly complile a Perl program is one of the reasons perl tends to have a shorter development cycle (i.e. we get stuff done quicker).

      OTOH, C is truly compiled, so for specific tasks, it'll run quicker, though will probably take longer to develop some specific application in. And for many tasks, even if some Perl program is 10-100 times slower than an optimized C program, it is usually 'fast enough' in that the user doesn't care if he gets the result in 3 milliseconds or 3/10ths of a second, and the savings in development and maintenance time more than make up for the difference in runtime.

      And as for GUI's, perl has modules for many different GUI toolkits.

    Re: Perl applications
    by elwarren (Curate) on Apr 07, 2004 at 22:45 UTC
      I don't think we'd have the web as we know it today if it wasn't for Perl. I would rank it as the second most important bit of code out there, right behind Apache. Granted, we wouldn't have much of a web without the browser, but the browsers really haven't advanced much in the 10 years we've had them.

      hehe, at one of my previous clients, I was constantly taunted by the Java developers :-) "ooh, mr dba says perl can do this, perl can do that? oh, is there anything perl can't do? Why don't you learn a real programming language instead of that scripting toy? Perl doesn't scale. Java is superior to your puny perl."

      Yeah yeah, my perl does the job every time, I can code in it worlds faster than C, no there isn't anything that perl cannot do, and hey buddy you run bytecode just like I do! It was fun for awhile but it grew boring to hear the same chiding. So the next time it came up I challenged them: put your money where your mouth is. I can do in perl what you can do in java, and just for giggles I'll do it better. They got quiet quick, all bark and no bite.

      Finally after a month of their comments being repeatedly squashed with my challenge, one of them stepped up. We set a start and an end date and program goals. I whipped his ass and was done a day early to boot.

      *sigh* and then it was right back to the same old crud, "is there anything perl can't do?" So I learned Java just to piss them off. I like Perl better.
    Be humble
    by santang (Acolyte) on Apr 08, 2004 at 01:09 UTC

      Just because you think Perl is the best answer to every problem, does not mean that it is the right solution for that company right now. You should always be willing to learn other languages, learn how the established code base operates, and how the team uses the tools they have to work together using the languages that they know. That will be vital in winning confidence and respect with your collegues.

      Do not concern yourself with trying to get Perl everywhere. It will go where it fits best, when it is ready. Once you have attained oneness with the programming team, they will naturally "think for themselves" that Perl is the best way to go, where it is.

      If you do not keep this willingness to understand your collegues' viewpoint, you will only add to the masses of Perl enthusiasts who are so blindly bashing Perl that they miss the opportunity to learn from established code bases, that have solved programming problems in new and interesting ways.

      Ways that will work in Perl too, once you have ported them to CPAN for all of the Perl community to enjoy.

      Forging your own path does not mean that you should avoid asking for directions.
    Re: Perl applications
    by rupesh (Hermit) on Apr 08, 2004 at 03:54 UTC
    Re: Perl applications
    by danb (Friar) on Apr 08, 2004 at 07:03 UTC
      Interchange is an advanced E-commerce platform built on Perl.

      -Dan

    Re: Perl applications
    by adamk (Chaplain) on Apr 08, 2004 at 07:17 UTC
      CVS Monitor reverse engineers CVS data to do all sorts of cool stuff, looks great, has a pretty large, highly structured design, easy to read and highly commented code, and works with very large data sets of highly cross linked objects.

      And it was pretty much written in 2 months in my spare time...

      The unreadable-ness of perl is really because most people don't comment or write clean code.

      I've had a lot of people on reading various applications of mine say "Is that perl? It looks more like ..."

      For the interested, I've been accumulating a code/style guide for writing big-ass perl apps.
        Your code/style guide looks really good. A few notes:
        1. Leave warnings on in production. They are often your only indication that something went wrong. And, if you're sharing your logspace with another app, you have bigger problems.
        2. Don't use Error in production code. It does its work with closures, which can (and does) cause memory leaks. Better is to just do it yourself with eval/die. Example:
          eval { # Code that might die }; if ($@) { # Catch area }
          Perl 5.6+ even allows you to die with an object. (This is what Error utilizes. Read the code sometime, it's not that difficult.)
        3. return undef; will not do what you want. Better is just return;. Here's an example why:
          sub foo { return undef; } my @x = foo(); if (@x) { print "foo() succeeded\n" } else { print "foo() failed\n";
          You even talk about this, but don't realize the issue.
        4. Importing isa() can be neat, but I would still use UNIVERSAL::isa(), anyways, just to be anal. Also, there are many classes that, for whatever reason, need to overload both can() and isa(). Be mindful of them.
        5. You use the word "local" when discussing keeping variables with what they're working on. Use the word "lexical". local means something specific in Perl.
        6. When talking about map, grep, sort, and conditionals, you refer to saving 600 bytes of memory. That's the first time in about 15 years I've seen someone talk about saving bytes of memory, other than my compulsory ASM class in college. bytes!! You seriously think that this is a reason for or against anything? If I'm worried about 600 bytes of RAM, I shouldn't be using Perl. Remember - Perl doubly-indirects every single variable. That's 8 extra bytes overhead, just to even start having a variable. (There's more to it than that ... it's actually like 40 bytes just to have space for a variable, let alone the actual values.)

          The real reason to use post-ifs, as you call them, is to improve readability. You want to have the important bits on the left hand side, closest to the margin. That stands out more. Error conditions should be on the right, where they can get out of the way of reading the main flow of the code.

        7. Don't use a regex to test against many values, use a hash. Not only does it improve readability, but you are documenting why you're testing against these thing. (And, it's faster.)
        8. In your regex-in-a-map, you don't explain why it's important to have $_ at the end. It's because s/// returns the number of changes, not the value changed. (Plus, in your example, the stripping of surrounding whitespace should be in a function.)
        9. I agree with map in your list -> hash example. However, it might be more readable as such:
          # Create an ID to name hash my %hash = map { $_->id, $_->name } @Objects; Becomes: # Create an ID to name hash my %hash = map { $_->id => $_->name } @Objects;
        10. The double boolean negative. Never heard of it. If I saw it, I'd want to hunt you down with an axe. Try $foo = $bar && 1; - simple, clean, and is used in more places.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

          A lot of this is good stuff. To continue

          1. I guess it depends on the context. Certainly in a situation where you can assume full server control, seperate logging would mean warnings can be turned on. I've done a lot of work in shared log uncontrollable server situations, and I've found that in that case more often that not the warnings are just getting in the way in that case, particularly when there's a warning that is relatively unimportant, but which end up filling up 95% of the log.

          2. Interesting. I'll add that in. In my case, I've ended up with my own somewhat lighter Exception class, based around the die'able object ability.

          3. Returning things by list like that has some major problems. Returning by list gives us no way of differentiating a legal null list from an error state. Take a better look at the suggested full map of return conditions, based on the return type and whether it can fail or not.

          My standard is that when a method can error, undef is the error response, 0 the null response, and a list is returned by reference.

          Only in the case of a list return with no possibility for error is the subroutine allowed to be written such that it returns a list.

          Also, consider the problem of 'return' being inconsistent, for example in

          Foo::maximum( $foo->value, $bar->value, $baz->value );
          If an error was returned with just 'return', that code does not fail, but rather continues with an incorrect result. The alternative is create three new variables, save the values to them, check them, and THAN call Foo::maximum.

          In the long term, over thousands of methods, I consider the predictability of having methods ALWAYS return error as undef outweighs any potential for the bug you mention. Return by list has it's own problems, and I choose to go with consistency.

          4. I concur with the be careful, and I certainly agree. Within _my_ code, I generally don't overload isa, so it's save for me. And the VERY large number of times I use UNIVERSAL::isa means that the code is far more readable. When testing external modules, yes, there is reason to be careful.

          5. Point taken

          6. I agree, sort of. Certainly about the legibility being the main reason.

          As for the memory saving, I measure a largish API once, and found 1500 post-ifs ( mostly 'or return undef' though ). That's heading towards a meg of extra overhead. I'm a little more paranoid about saving memory than most I guess. Note Config::Tiny and CSS::Tiny :)

          7. I've swung either way on this one... At the moment I'm still leaning slightly towards regex still, from a flexibility viewpoint ( you can use the regexs for regex stuff ) and for their compactness. ( And they are quite legible )

          8. I concur, I'll add a note. The whitespace example is really just that, and example. I should probably add the grep { regex; 1 } alternative, although using map {} makes it much more obvious as to the intent.

          9. That is much nicer, and I really should have known that :)

          10. The && 1. Never heard of it. If I saw it, I'd want to hunt you down with an axe. Try !!; simple, clean, only two ops, and each to teach as the "boolean context" operator.



          Thanks for all the suggestions
    Re: Perl applications
    by novitiate (Scribe) on Apr 08, 2004 at 07:30 UTC

      and let's not forget the human genome project

      perl also seems to be used widely in the securities trading realm, hence the cpan SWIFT modules...for those unfamiliar, SWIFT is vital to the financial industries...



      humbly,
      novitiate

      "...goodnight you princes of main(e)"  --The Cider House Rules

    Re: Perl applications
    by DrHyde (Prior) on Apr 08, 2004 at 08:48 UTC
      At my previous employer I wrote a telecoms billing application in perl. It ran as a daemon which listened for events from a telecoms switch (like "call started", "call still in progress", "call ended") figured out whether the call was local, single tandem, dual tandem, international, which other telcos were involved, who to bill, how much to bill 'em, how much we would be billed, did descending balance billing for customers, some fraud detection and so on. It could also bill based on historical call data, and I managed to get it down to processing a month of data in 18 hours.

      They also used another perl application - which also ran as a daemon - for controlling the switch. When a call came in, it would look stuff up in a routing database and pick the least-cost route for that combination of caller and recipient and the time of day. This - of course! - had to work in as near as damnit real time.

      All of this was running on decidedly low-endian hardware.

      My current employer makes several million a year from a very simple little perl app which provides a web services interface between one of our biggest customers and our SAP backend so they can place orders automagically.

      Several of my projects for this year are going to involve using perl to talk to an SAP backend.

    Re: Perl applications
    by eserte (Deacon) on Apr 08, 2004 at 09:06 UTC
    Re: Perl applications
    by Paulster2 (Priest) on Apr 08, 2004 at 10:17 UTC

      Something that I haven't seen mentioned in the posts above is probably unspoken, but noted somewhere in the backs of our minds. I have looked upon many "job sites/help wanted" adds while trying to find work (luckily I am not in that situation at the present moment! ;-) and have found that for coding/sysadmin/etc. types of jobs, they all mention Perl. Whether or not Perl is a well thought of language by the coding population in general (although definetly well thought of here!!) may be irrelavent. Perl is definitely a ticket punch to most employers. It may not detract you from getting a job, but it sure as heck isn't going to hurt you knowing it. Those who do not look on it favorably probably are too set in their ways to realize that by knowing Perl, you make yourself worth more in the market place. Those who do not realize this are only cheating themselves.

      Paulster2

    Re: Perl applications
    by Jouke (Curate) on Apr 08, 2004 at 11:28 UTC
      <shameless plug> Of course there's pVoice too </shameless plug>


      Jouke Visser, Perl 'Adept'
      Using Perl to help the disabled: pVoice and pStory
    Re: Perl applications
    by shotgunefx (Parson) on Apr 08, 2004 at 11:50 UTC
      I don't have a link but I remember an article in the Perl Journal some time ago about Perl being used a lot at NORAD and in nuclear missle guidance systems. It might not be a great example as there was a problem after install (not due to Perl, but the author's misunderstanding of the ^^ op). I think it was titled something like "Perl and Nuclear don't mix."


      -Lee

      "To be civilized is to deny one's nature."
    Re: Perl applications
    by sth (Priest) on Apr 08, 2004 at 12:58 UTC

      rje,

      I don't have any more info than what has already been posted. I realize that you are having a hard time fighting for Perl a work, but thanks for posting this question. I love posts like these, the information that are a result of these posts is fantastic! Well done Monks! I hope that you have enough info to present your case for Perl. Thanks for summarizing as well.

      sth

    Re: Perl applications
    by mce (Curate) on Apr 08, 2004 at 13:58 UTC
      If you want a demo of what a perl gui is capable of: frozen-bubble|

      ---------------------------
      Dr. Mark Ceulemans
      Senior Consultant
      BMC, Belgium
    Re: Perl applications
    by husker (Chaplain) on Apr 08, 2004 at 15:17 UTC
      We use this pretty fancy survey software for all kinds of things here. It's all Perl, all the time (compiled Perl, if you are on Windows).

      If he compiles Perl, then does that satisfy his qualms?

      Lastly, to address your angst at having to defend Perl all the time, I give you my advice on how to deal with the chronic Perl-bashing. In your case, I think the last three paragraphs are most relevant to your situation.

    Re: Perl applications
    by flyingmoose (Priest) on Apr 08, 2004 at 18:40 UTC
      Also need to add (former job): AT&T Wireless heavily uses Perl to interconnect their billing systems (FTP based, mainframe legacy stuff) to modern database and Customer Relationship Managment (CRM) and Accounting systems.

      Perl is also heavily used in constructing custom mutli-machine build environments (aka "build labs"), as is the case with my current employer -- due to proficiency in manipulating SQL, SMTP, FTP, SSH, HTTP, and various other protocols -- plus it does great building archives, assembling logs, etc. Perl rocks as a networked applications language.

    Re: Perl applications
    by slowe (Initiate) on Apr 08, 2004 at 18:59 UTC
    Re: Perl applications
    by chanio (Priest) on Apr 09, 2004 at 09:08 UTC
      You should ask your boss why wouldn't people write CGIs in Assembly language.

      I think that it has proved to be very powerfull and complex, etc. But time rules. And, perl is something very practical.

    Re: Perl applications
    by Anonymous Monk on Apr 09, 2004 at 14:37 UTC
      How about POE and any applications written using it. I work for the leader in the student loan industry and we use POE for a high traffic encrypted file transfer system.

      POE Success Stories

      http://danconia.org
    Re: Perl applications
    by a (Friar) on Apr 09, 2004 at 17:08 UTC
      The Federal courts (in the process of migrating from Solaris x86 to RHE for most applications) run the national "Case Management/Electronic Case Filing" (CM/ECF) system on perl/apache/tomcat. Over 2000 separate perl scripts weighing in at about 1.6 million lines of code.

      Developed on the national level by a centralized programming staff (lots of consultants), its delievered to nearly every one of the courts across the country (bankruptcy and district) as a package which we admins can then fix/modify to our heart's (and version controled ;-) content.

      a

    Re: Perl applications
    by emazep (Priest) on Apr 09, 2004 at 17:29 UTC
      If with "servers" you meant also web application servers, it's plenty of them written in Perl. Amazon.com (i.e. the biggest store ever seen on the web) is written in Perl: is it enough for the chief deprecator? Look at:
      http://www.masonhq.com/?AmazonDotCom

      Other poular sites written in Perl are: slashdot, AvantGo, DynDNS.org, Salon.com, TechWeb, just to name a few.

      As for Perl reads in its source code directly (rather than a bytecoded compiled version), as the so-called C++ programmer said, you can inform him that Perl source code can be compiled into bytecode as well (and also translated into C code, if you like.) Furthermore, Perl permits even to inline code written in C, C++, Java, Basic, Python and a number of other programming languages.

      Cheers,
      Emanuele.
        You shouldn't bring up the bytecode or compile-to-C issue here as it isn't something that real programs use. Those are mostly just toys for perl programmers and only the most foolish person would actually use them.
          I would rather say that these compiler backends are still experimental (I apologize for not to have specified it.)

          This does not mean that they don't deserve to be mentioned (or that they should be qualified as "foolish persons toys" ;-) as their development is serious and they'll someday hit a stable state (they are already quite usable anyway).

          Ciao, Emanuele.

    Log In?
    Username:
    Password:

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

    How do I use this? | Other CB clients
    Other Users?
    Others about the Monastery: (5)
    As of 2014-07-29 03:17 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      My favorite superfluous repetitious redundant duplicative phrase is:









      Results (211 votes), past polls