Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Don't Write That In Perl!

by Ovid (Cardinal)
on Dec 19, 2007 at 14:13 UTC ( #657875=perlmeditation: print w/replies, xml ) Need Help??

So we've all heard the example of "don't write device drivers in Perl", but frankly, I don't hear about a lot of real-world examples of people's Perl projects failing because they insisted on using Perl in an area where it's clearly not suited. Can anyone provide examples, preferably where I can read more about 'em?


New address of my CGI Course.

Replies are listed 'Best First'.
Re: Don't Write That In Perl!
by jettero (Monsignor) on Dec 19, 2007 at 14:30 UTC

    I successfully embedded perl in foxpro. When you unload the .dll foxpro segfaults. I then rewrote the app to not use perl because foxpro isn't stable enough to handle unloading perl...

    I also maintain a hideous and evil Sendmail::Milter application. Perl threads just don't seem to have the juice required to make that work. They run pretty solid (as long as you don't exit and get those mysterious memory leak messages), but you can't use signals in a threaded app -- so you don't get to use timeouts for things that block. Perhaps I just suck at perl threads... In any case, I'm re-writing that legacy app to not be a sendmail milter (which requires threads).

    In short, due to limitations with sendmail and foxpro, I find perl doesn't fit well in them.


Re: Don't Write That In Perl!
by kyle (Abbot) on Dec 19, 2007 at 15:48 UTC

    Something like ten years ago, I wrote a RADIUS authentication server in Perl. The RADIUS protocol involves sending blocks of binary data in UDP packets.

    My skills being what they were ten years ago, I lived in constant fear that my carefully crafted numbers and strings would be converted from one to the other behind my back. I've sadly forgotten the details of this ordeal, but I've carried the "don't write a binary protocol handler in Perl" scars around with me ever since.

    As I think about it now, if I were writing it today, I don't think I'd have much problem. I'd make a RADIUS packet object to abstract away all kinds of headaches. I still would have to study pack and unpack a while before I got it right, but I'd do a lot of testing to help guide my way.

      I had the same fear, probably derived from some convincement that "Perl is for text". I then had many occasions to be more than happy with Perl's abilities to treat binary data. And, by the way, one involved some RADIUS message exchange!

      Hey! Up to Dec 16, 2007 I was named frodo72, take note of the change! Flavio
      perl -ple'$_=reverse' <<<ti.xittelop@oivalf

      Io ho capito... ma tu che hai detto?
Re: Don't Write That In Perl!
by KurtSchwind (Chaplain) on Dec 20, 2007 at 14:16 UTC

    Well, not to interrupt the name calling going on with Perl6, but:

    I was working on ETL for a datawharehouse. At the time, it was in the top 10 largest warehouses in the world. I was getting streamed binary data that was pretty complex. I had prototyped it in perl, but it was taking longer to process the data than it took to receive it. I ended up using my main ax (C/C++) to get it up and running.

    This was, however, about 10 years ago. Although I can't cry poor in terms of CPU and RAM (as I recall, I had an E10K with 40CPUS and 20G of RAM or something. I'd love to give it another shot with a newer version of perl. But I don't recall perl being really good a bit-manip.

    Example: I'd get 4 numbers to decode. The first was 3 bits, then 4 bits, then 7 bits, then 2 bits. This wasn't pretty in any language, but really nasty in perl. Not to mention the little/big endian issues to compensate for and getting data that doesn't line up nicely with byte boundries is pretty yucky as well.

    Footnote: That was some of the most fun I've had in programming ever.

    I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.
Re: Don't Write That In Perl!
by zby (Vicar) on Dec 19, 2007 at 18:24 UTC
    I once tried to write a Point of Sale application in Tk. I don't know how it is now - but back then there were so many bugs in Tk or in between Tk and screen managers that it was taking forever to have a reasonable layout and work with Polish letters.

      Ovid and I actually extended L'ane five and a half years ago, and it worked almost perfectly for us. The biggest problem we had was the binary blob credit card processing code, which segfaulted on exit until a nice pair programming session.

      While Perl/Tk now seems to get along reasonably well with unicode (try installing and watch what happens during "make test"...), alas it will probably never be able to tackle bidirectional text, let alone the proper ligatures for Arabic script. (If someone knows this to be false, please tell me more about that.)

      I have yet to try the other GUI library API's (Gtk and Qt), but I know the Perl modules exist for these, and I know that people have used these libraries to create reasonably successful bidi/Arabic interfaces. (And if you can do that, you can do just about anything.)

Re: Don't Write That In Perl!
by weismat (Friar) on Dec 20, 2007 at 14:57 UTC
    From my pov I would not write the following things in perl:
    - Complex multi-threaded programs (because objects/structures can not be shared and function pointers can not be used cross-threads) as well. Library support for simple multi-threaded things like async IO is not good. It is also not acceptable that it is unclear if a CPAN module supports multi-threading or not.
    - Complex GUIs - Tk has a old-fashioned look-and-feel. Other GUI kits need to improve on stability and documentation. The thread issue is even bigger with complex GUIs as you need to pass around objects between the two things.
    - Shared objects - nearly impossible to roll out perl as a COM object or a shared library for other platforms. It is also very painful to acess shared objects.
Re: Don't Write That In Perl!
by suaveant (Parson) on Dec 20, 2007 at 17:15 UTC
    I think there are lots of cases out there, and they are backed by Perl modules wrapped around C code.

    For example, I'd never use XML::XPath in any project that used a largish XML file and needed to get done somewhere near quickly... but XML::LibXML works great, and still allows me to do my work in Perl.

    Usually where the projects are going to fail is where speed becomes an issue, or where Perl isn't available, or memory issues. For the speed most people turn to wrapping C, the other two are a little tougher :)

                    - Ant
                    - Some of my best work - (1 2 3)

Re: Don't Write That In Perl!
by sundialsvc4 (Abbot) on Dec 20, 2007 at 18:19 UTC

    The way that I tend to think of “very-high level languages” like Perl is that they represent a large wad of very cleverly-written "C" and assembler code that I didn't have to write or debug. The moment my program starts, it's running within the envelope of what is actually a very complicated runtime environment... no thought required. Tools like Perl allow us to focus on what matters to a particular application, and to ignore (or simply take for granted) all the rest. For all its warts, Perl definitely moves the freight.

    I'm very reluctant to blame any project failure at all upon the language(s) or tools that were used to build it. The true cause of the failure usually has two ears, and a vacuum in-between. :-D

A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://657875]
Approved by marto
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2020-10-25 03:43 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (249 votes). Check out past polls.