Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

What is Perl *NOT* good at?

by jfroebe (Vicar)
on Apr 20, 2004 at 20:39 UTC ( #346790=perlquestion: print w/ replies, xml ) Need Help??
jfroebe has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

While we would like to believe that Perl is good at everything, there are some things that it does poorly or not at all. In order to avoid wasting time on writing scripts to do a task that Perl is ill suited for, what are some of the things that you wouldn't use perl for?

My list

Task
1.heavy i/o tasks or tasks that would require async i/o
2.realtime operations
3.tasks that would require timely signal handling (sigalrm for example)
4.closed source applications

Any others?

Jason L. Froebe

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

Comment on What is Perl *NOT* good at?
Re: What is Perl *NOT* good at?
by matija (Priest) on Apr 20, 2004 at 20:47 UTC
    I often use Perl for heavy I/O tasks - processing gigabytes worth of logs, for instance.

    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
      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.
Re: What is Perl *NOT* good at?
by diotalevi (Canon) on Apr 20, 2004 at 20:48 UTC
    Perl is really horrible at being embedded into Microsoft Office documents.
Re: What is Perl *NOT* good at?
by kvale (Monsignor) on Apr 20, 2004 at 20:53 UTC
    I generally program it in perl first and see what happens. I have rarely been disappointed :)

    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.

    -Mark

Re: What is Perl *NOT* good at?
by adrianh (Chancellor) on Apr 20, 2004 at 21:05 UTC

    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).
Re: What is Perl *NOT* good at?
by jacques (Priest) on Apr 20, 2004 at 21:12 UTC
    That's easy. Anything that C excels at, Perl generally does not. Two things that come to mind:

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

Re: What is Perl *NOT* good at?
by perrin (Chancellor) on Apr 20, 2004 at 21:14 UTC
    I wouldn't use it for an application that is all about number-crunching or some other CPU intensive task if performance is a serious concern for the application. There have been examples on perlmonks of people who re-wrote a CPU-bound app in C and got major speed gains as a result.

    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

Re: What is Perl *NOT* good at?
by asdfgroup (Beadle) on Apr 21, 2004 at 00:04 UTC
    IMHO, Perl is not good if you made some system programming at low level (like Linux Kernel Modules) and if you wonna to minimize memory usage.

    I hapilly use Perl for 1), 3), and 4) every day :)
    2) can't be made on Linux kernel without patches at all (if you need realtime maybe you need Qnix or RTLinux ?. And as soon as real realtime will be guaranteed by kernel, you will be able to write realtime things in Perl,

Re: What is Perl *NOT* good at
by g00n (Hermit) on Apr 21, 2004 at 00:36 UTC
    • 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?

    update: sp.

      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.

Re: What is Perl *NOT* good at?
by leriksen (Curate) on Apr 21, 2004 at 00:38 UTC
    Realtime is the only one I wouldn't try to use Perl for directly. But what I would use Perl for is for generating realtime code - that is I would design a small language to abstract what I want to do in the low-level realtime code and write a little Perl-based parser to generate the appropriate code. I think we can all think of examples of this kind of paradigm.

    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.

    +++++++++++++++++
    #!/usr/bin/perl
    use warnings;use strict;use brain;

      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!

Re: What is Perl *NOT* good at?
by Anonymous Monk on Apr 21, 2004 at 01:10 UTC
    I agree with (2) and (3), and depending on your definition, (4). My company ships a large shrinkwrap enterprise application in Perl as proprietary software; the source is there and visible, but it's certainly not open source according to any common definition of the term.

    (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

Re: What is Perl *NOT* good at?
by Zaxo (Archbishop) on Apr 21, 2004 at 01:17 UTC

    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.

    After Compline,
    Zaxo

      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.
Re: What is Perl *NOT* good at?
by blue_cowdawg (Monsignor) on Apr 21, 2004 at 02:26 UTC

        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.

Re: What is Perl *NOT* good at?
by Anonymous Monk on Apr 21, 2004 at 02:33 UTC
    I wouldn't use Perl for writing advanced 3D grahics software, I tried it didn't work out. Also I don't see Perl used in embedded systems or real time systems. Let me know if I am wrong.

          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.

Re: What is Perl *NOT* good at?
by samtregar (Abbot) on Apr 21, 2004 at 02:37 UTC
      Nice.
Re: What is Perl *NOT* good at?
by bronto (Priest) on Apr 21, 2004 at 09:43 UTC

    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

    Ciao!
    --bronto


    The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
    --John M. Dlugosz
Re: What is Perl *NOT* good at?
by Abigail-II (Bishop) on Apr 21, 2004 at 10:08 UTC
    My list (the list may have items on it for which there are "Perl" modules doing the thing mentioned, but typically such modules contain large parts of C and/or XS code - which isn't Perl).
    • 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
    And all other things I forgot.

    Abigail

Re: What is Perl *NOT* good at?
by mpeppler (Vicar) on Apr 21, 2004 at 10:35 UTC
    I wouldn't write a heavy-duty multi-threaded server in perl - mainly because perl's threading and signals are still iffy, and because of the overhead that perl adds.

    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

Re: What is Perl *NOT* good at?
by dragonchild (Archbishop) on Apr 21, 2004 at 11:35 UTC
    If I wouldn't use Perl for it, I'm probably not going to want to do it. I don't like doing the heavy lifting when it comes to writing algorithms in C and the like. I'm just not motivated enough, I guess. :-)

    ------
    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: What is Perl *NOT* good at?
by krisahoch (Deacon) on Jun 14, 2004 at 20:19 UTC
    I wouldn't use it for writing Java programs (although you can see Inline::Java).

    Kristofer

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (17)
As of 2014-09-17 15:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (90 votes), past polls