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.

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. ;)

you're right, the word to define perl programming is: rewarding.
i could not have said it better


ignorance, the plague is everywhere
--guttermouth

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.

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

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

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.

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*

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

-enlil

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.

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?).

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.

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.

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
   }
   [download]

   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";
   [download]

   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;
   [download]

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 );
[download]

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

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.

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.

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.

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

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.

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.

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