Depending on the definitions of "heavy" and "realtime" I wouldn't always exclude your (1) and (2) :-)

I use Perl for (4) every day, as I suspect to many other Perl developers!

When would I not use Perl?

• I probably wouldn't use it on a project where everybody else on the development team was using another language
• I probably wouldn't use it in an organisation that had standardised on another language.
• I wouldn't use it in all the many places where you cannot run Perl (consoles, many embedded systems, phones, many PDAs, etc.)
• I wouldn't use it where it was too slow (once I had actually verified that it actually was too slow).
• I wouldn't use it for rule based or declarative coding if I had something more appropriate like Prolog sitting around. This is one of the development paradigms that Perl doesn't support nicely. With Perl 6 (and some new grammers) this will hopefully change :-)
• I wouldn't use it to develop with a platform or API where another language is better supported (if I need to do some serious Mac OS X coding I'm going to go brush up my Objective C rather than play with CamelBones in Perl).

In my experience, core perl can be less than optimal for

• Large matrix and vector operations (but see PDL for an excellent speedup)
• Although there are a lot of XS modules out there, interfacing to libraries could be easier.
• Some types of functional programming require efficient handling of tail recursion, which is not a strong point of the current perl.

Tail recursion is entirely possible in Perl, using the construct goto &own_func_name (having updated @_ as desired).

• Operating System design
• Lower-level graphic processing

If I am interested in developing client-side applications and software that requires years of development along with dozens of programmers, Perl would not be high on my list of choices, even though I might still try to sneak it in. ;)

I agree on realtime, as long as it's hard realtime like process control, where you need to know average and maximum times for each program segment. Perl is OK for soft realtime i.e use interaction.

Agree on signals and closed source.

One category I'd add: PalmOS applications. I haven't yet been able to find a Perl that would run on my Tungsten.

I should have said heavy concurrent i/o utilization by multiple threads. sorry about that

Jason

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

I have several applications using I/O multiplexing written in Perl, such as:
• a http based queue system (server/client)
• a gateway for a proprietary billing system.
I have tested my simple I/O multiplexing based http server against ab (apachebench), and it turns out that the performance is very good.
I don't see any point for making a claim that Perl is NOT good at this.

PalmOS applications

You won't use perl for applications on a platform for which it's not available? Surely not! ;-) Well yeah, I suppose I wouldn't consider perl for a CP/M application either. I guess I'll just have to stick with BCPL.

I *do* use perl as part of the build process for my PalmOS apps. There's a nice set of modules (which unfortunately CPAN.pm doesn't like installing) for creating and manipulating Palm databases, so a few lines of perl is enough to slurp data from tha intarweb, parse it, and stuff into databases which my Palm app (written in C) can use.

Surprisingly, one of the areas that I don't use perl much is one which many people seem to think it excels at - one-liners. I'll just use the shell. Here, for example, is how I get a unique list of all the IPs which my mail sewer has refused to talk to today:

grep "connection from" /var/log/exim/mainlog| \
grep "refused$"|awk '{print $6}'|sed 's/\[//;s/\]//'| \
sort|uniq
[download]

The great thing about doing tasks like this in the shell as opposed to in perl is that really it's just applying a succession of filters, and the shell imposes minimal extra syntax. And I can never remember the perl command line switches.

Most of the time, I work on web applications, which are almost never CPU bound. They tend to be I/O bound instead, waiting for a database or something similar, and Perl is very good at that thanks to things like DBI.

Hmm, I quite regularly write intensive number-crunching code in perl - that makes it real easy to prototype and refine (or redefine) the algorithm, and make sure that I know exactly what I'm trying to do before I rewrite it in C. Most times I end up not needing to rewrite it in C.

Hugo

I once wrote a Linux device driver in pure perl, just to see if I could. I wouldn't recommend it, except as a learning experience.

The remarkable thing is that it was possible at all. Not many "scripting" languages offer ioctl. A chunk of the code is posted here at Linux ioctl command module.

I would have whipped out Inline::C for the purpose. But really, when you say you wrote a device driver in pure perl, did you really get something you could insmod? I'm skeptical. As for manipulating device drivers (config apps), etc, yeah I can see it wouldn't be bad at all. But I'd still use Inline or XS to a real C ioctl call rather than Perl's beast with the extra gorp.

• Number crunching. Accessing the value of a number requires following at least two pointers, plus some additional overhead to check to see whether the numeric value is correct.
• Anything that requires to be CPU/register/memory/cache friendly. The flexibility of Perl comes with a price, and that's paid with CPU and memory.
• Anything that requires a small footprint in disk space. Compiling C programs with the right compiler can give you programs of just a few k, meaning you can pack a lot of them on a floppy. There's no way to install perl on a floppy.
• Direct memory access, due to the lack of pointers.
• Locking regions of files instead of the entire file.
• Calling kernel hooks.
• Many things for which there are special purpose languages (music, vector images, etc)
• Real time programming
• Threads
• OO

Abigail

what are some of the things that you wouldn't use perl for?

This is a question that intrigues me. Why? Because I quite often do one of two things:

1. Prototype a project in Perl and then port it to some other language such as C or C++
2. Occasionally start out writing an application in some other language and end up writing it in Perl.

I probably would not use Perl to write a device driver for *nix or *doze. I might however write an interface using XS against a C API to drive the resultant device.

I might not use Perl to do real time data aquisition but I would probably post process the results in Perl to make it presentable.

So while I could think of things that I wouldn't do directly in Perl there are way too many other uses I do have for the language. I don't remember a project in the last 10 years that I haven't resorted to Perl at some point. Even one of my current projects where I am rewriting the startup scripts for a vendor application I am invoking a Perl script from a bash shell script put in /etc/init.d and linked appropriately.

Not for closed source applications? More correctly I won't use Perl for the odd occasion where I write something that I don't want a casual user to see the "naughty bits" of what is going on behind the scenes.

-sam

Nice.

I get the impression that Perl is not yet appropriate for developing massive multi-threaded applications, at least not by the majority of Perl coders.

As for games/graphics, just look at frozen-bubble, a beautiful game written in Perl. The Perl code is only ~2200 lines, and it 'reads' very clearly too.

While frozen bubble is a great game, I don't think it reads clearly at all. Rather than use standard modules, the authors of frozen bubble had to (if you read the code) create their own framebuffer manipulation code, to work around the lack of primatives in SDL, etc. This is not a crack against Perl or FB, just to say that it is not clean. I would have much rather seen the FrozenBubble developers contribute back to the SDL project with lots of CPAN modules than hand-roll the solution they've hand rolled. Now, in order to get good clean SDL, most folks read frozen-bubble, but I argue that shouldn't be neccessary!

As to answering the OP's question, definitely realtime is out for 98% of the languages out there -- and 98% of the operating systems!

Perl *can* invade the GUI space (either through wxWindows, Perl-GTK, or even my favorite Perl/Tk) and the games space, it's been done, but these are only areas that require severe discipline to make Perl OO work. I'm considering one such project right now.

Below someone posts a failed Quake2 mods project. Well, just to throw a wrench in the socket, I know of a University project doing some excellent work using Lisp to control Unreal AI's and mod's. Yes, folks, Lisp. Anything can be done here, if anything, there may be performance conerns (which happens in anything but C/C++ for the most part for things like that) or the developers bit off more than they could chew for the first iteration. If it can be done in Lisp, it can be done!

• GUI: use for cross platform *native* gui client side development - (only if you think Tk is the best you can do.)
  
• PPM: use for gui client side development on MS Windows using CPAN - (because ActiveState ppm is horribly broken and you cant utilise CPAN.
  
• Shipping: problems with MS Windows GUI/Perl apps when shipping - (because existing tools are bloated, proprietary).

I am ambivalent about using Perl for client side *native* gui programming.

There is a great article by Eric Burke on why GUI programming is hard that sums up why nicely - namely server side development (with languages like Perl) allow for automation once the design problem(s) can be defined.

Gui development on the otherhand, cannot be automated as easily. The other thing the mismatch between skill sets between server side and gui client developers.

I would also be interested to know who develops gui apps aside from MS Windows? Any commercial apps or are they all inhouse? How do you ship? What front end do you use?

only if you think Tk is the best you can do.

I don't think Tk is that bad (but not that great, either). But Gtk+ has very nice Perl bindings that work on Perl-Win32 now.

(It should be noted that most of my GUI programming comes from AWT/Swing, of which anything, even Tk, looks better).

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

Note: All code is untested, unless otherwise stated

What's wrong with GUI programming in Perl/Tk? It's not as good as Delphi, but sure beats hell out of Java.

What's wrong with PPM? It has always worked perfectly for me. No complaints at all in 3 years of heavy use.

What are your "Shipping" problems? What can be easier than shipping a Perl app? It is plain text after all?


--
Regards,
Helgi Briem
hbriem AT simnet DOT is

What are your "Shipping" problems?

Well... just to be "devil's advocate" I'll bite on that one. Just in my own little world at work I have troubles "shipping" code from one machine to another. Quite often code that I develop and test very thoroughly on one machine explodes due to missing modules on another machine depending on wheather or not the admins on the target machine have been diligent in keeping their CPAN module list up to date.

While I have developed standards for what belongs on machines, what version of Perl to install, etc. etc. some folks just don't listen until there's a probelm.

Michael

Fortunately, you don't have to. Using Apache2+mod_perl2, you can write a ProtocolHandler in Perl that can do just about anything (</shameless-plug>).

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

Note: All code is untested, unless otherwise stated

(1) might or might not be a problem; I don't really know enough about the problem domain.

After working on this application (about 100KLOC depending on how you count) for the last year and a half, I think my answer is that applications for which correctness is a requirement probably shouldn't use Perl. Most other languages (Python, C, FORTH, assembly, perhaps Java or Ada or Eiffel) are much less likely to hide subtle bugs in apparently-working code. Of these, Python would normally be my first choice, since it has the best power-per-line ratio in my experience.

Perl was and is the right choice for our application, though; flexibility is less important for us than correctness and access to libraries. -- kragen@pobox.com

Also I don't see Perl used in embedded systems

While I haven't tried running Perl on an embedded system (hmm....) I have used Perl to do format conversions and upload byte code to an embedded system board (PIC16 series) and do my testing for me. I've also used Perl to extract data from a very small data aquisition unit (about the size of a small pill bottle) that recorded the acceleration and G forces on a model (large model... over 7 foot tall) rocket and display the results.

As gmax said in his latest seminar he held for our local Linux Users Group, Perl is not good if you are going to do microprocessor programming, otherwise it is ok

Kristofer