Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

You Used Perl to Write WHAT?! 307

Posted by kdawson from the tool-that-fits dept.
Esther Schindler writes "Developers spend a lot of time telling managers, 'Let me use the tool that's appropriate for the job' (cue the '...everything looks like a nail' meme here). But rarely do we enumerate when a language is the right one for a particular job, and when it's a very, very wrong choice. James Turner, writing for CIO.com, identifies five tasks for which perl is ideally suited, and four that... well, really, shouldn't you choose something else? This is the first article in a series that will examine what each language is good at, and for which tasks it's just plain dumb. Another article is coming RSN about JavaScript, and yet another for PHP... with more promised, should these first articles do well."
This discussion has been archived. No new comments can be posted.

You Used Perl to Write WHAT?! More

You Used Perl to Write WHAT?!

Comments Filter:

  • Both sides... (Score:5, Interesting)

    by Aladrin ( 926209 ) on Friday January 25, 2008 @09:53AM (#22181280)
    I always see both sides of the 'right tool for the job' problem.

    Having the right tools is great for current productivity, but it's hell on expenses and new recruits. If you use a different tool for every job, you need to maintain all those tools and a task force that's able to use all of them. Sometimes the 'right tool' is one that fits the company as well as the job.

    • Sometimes the 'right tool' is one that fits the company as well as the job.
      You hit the nail right on the head. Take it or leave the pun, our mid-sized company is stretched tight on IT skillsets and bringing new ones in isn't an option.

      • Re:An Intelligent FrI$T Psot. (Score:4, Insightful)

        by Schraegstrichpunkt ( 931443 ) on Friday January 25, 2008 @10:47AM (#22181962) Homepage
        You have to be careful, though, not to miss newly-developed cost-cutting/quality-improving technology (e.g. Pylons [pylonshq.com] and Django [djangoproject.com], neither of which existed in any useful capacity more than 3 years ago) or your competitors will eat your lunch.
        • Of course, Django has its own share of shortcomings.

          I didn't use it on a site I worked. This site relied on user uploads. However, Django's FileField doesn't allow you to put anything but static strings and date formatting characters in the upload directory, or even offer a method to move files around. The files on the aforementioned site were supposed to be organized by user, so that other scripts could easily zip entire directories / directory trees.

    • Re:Both sides... (Score:5, Insightful)

      by AKAImBatman ( 238306 ) <`akaimbatman' `at' `gmail.com'> on Friday January 25, 2008 @10:19AM (#22181618) Homepage Journal

      If you use a different tool for every job, you need to maintain all those tools and a task force that's able to use all of them.

      That's why the "right tool for the job" is sometimes the tool that meets the greatest cross-section of a company's needs rather than a jumble of tools that are ideal at a lot of little tasks.

      e.g. While it's fashionable to hate Java these days, you have to admit that it does have a rather massive cross-section of needs it can meet. Thus one of the reasons why it's so popular in large companies. Yet a smaller company might find more value in using Ruby toolkits to do all their work. Ruby may not be ideal for some of the less glamorous back-end tasks, but tools like Rails gain so much on the front end that Ruby meets a greater cross-section of needs than Java would.
      • Rails has a very specific set of things it is good for. What it gains on the front end is speed in development. What in loses on the back end is scalability and flexibility. We have a mixed environment, php on the frontend and java on the backend, with c++ on the back end for some tasks that require very fast performance. Rails would not in its normal form meet our needs. Rails is fun to develop. And you are right, if you are a small team developing an app that doesn't need to scale past maybe a hundred th

    • Re:Both sides... (Score:5, Insightful)

      by hardburn ( 141468 ) <hardburnNO@SPAMwumpus-cave.net> on Friday January 25, 2008 @10:57AM (#22182080)

      I hate the "right tool for the job" cliche. Not because it's necessarily wrong, but because it tends to be used by people who automatically assume that their tool is the right one and wish to stop any serious discussion about other possibilities.

      • language vs library (Score:5, Insightful)

        by bzipitidoo ( 647217 ) <bzipitidoo@yahoo.com> on Friday January 25, 2008 @01:29PM (#22184520) Journal

        I wonder if this whole discussion is off the mark. Languages are for the most part trivial. And universal. "It's the libraries, stupid" is sometimes how I feel. If it was easy to link in or call any library function from any language, then half of this discussion would immediately be seen to be irrelevant. So Perl is "the right tool for the job" because it has the ability to apply regular expressions to strings? But, you know, C can do that too thanks to this PCRE library. Hashes? C can do that too via another library. In case anyone has forgotten, Perl itself is written in C. I read that Perl 6 has vastly improved the interface to other languages, especially C libraries.

        These day, whenever I write a new program it often feels as if I'm creating yet another language. A simple, superficial, limited language, but nonetheless, a language. Program needs a configuration file? Whip up a suitable format (language) for that. Needs to save data? Barf out this big data structure into a YML file. Want some way to run the interface from a batch process, or otherwise automatically? Start turning the user interface into a language. Want to connect Perl 5 and C? Get acquainted with XS, a "language" the Perl folks felt it necessary to create for that purpose, because Perl 5 wasn't good enough alone. Want to compile a large project written in C? Get familiar with the language of Make, because while C certainly could do it, C isn't so good for that. Is ANT a "language" for building Java projects? Where's the line between language and library?

        I suppose where things lead to a new language is when someone wants to implement a new concept and the established ways aren't good enough. Or has a way to eliminate a bad programming practice, but some elements of an existing language must be dropped to do it. For instance, wouldn't be nice to have variable length parameter lists in C, as C's own printf function does? Too bad it's such a pain to do that in C. How about lazy evaluation and currying so we can have infinitely long parameter lists? Oops, guess the C call stack can do recursion, but isn't too well suited to expressing that sort of thing, time to make another language, Haskell. Do we want to pass along a pointer to a structure, or a copy of a structure? Java defaulted to pointers where C did not, but then said Java didn't use pointers. Nice not to have to type in ampersands and asterisks all the time, but still, I find the thinking misleading. Then there's garbage collection. The consensus is that garbage collection is overall a good thing, but that a good programmer can do better than the automatic garbage collector. And so on.

        • Re:language vs library (Score:4, Interesting)

          by myvirtualid ( 851756 ) <pwwnowNO@SPAMgmail.com> on Friday January 25, 2008 @02:28PM (#22185370) Journal

          Languages are for the most part trivial. And universal.

          How about lazy evaluation and currying... ...time to make another language, Haskell.... Do we want... a pointer?

          Please do forgive me (hee hee hee: Please ==> forgive $ me) if I haven't quite gotten your point, but I cannot square your first and last paragraphs, specifically the parts I've quoted.

          Perhaps if you'd written "Imperative languages are for the most part trivial and universal? Perhaps then could easily equate C and Fortran and Perl and sed, and leave Haskell and Lisp out of the mix. Or perhaps if you'd written "OO languages are for the most part trivial and universal? Perhaps then I could equate (more or less easily, don't think it's quite NP) Objective C and Java and C++. (But see below....)

          But the bold unqualified "they're all languages, get over it" sort of assertion doesn't parse.

          My intro was Fortran, then F77, then Pascal, then C (OMG! Pointers! The Bomb!), and it was evolution, a little more cool, a little more flexibility all along.

          Then I learned C++ at work by day and Java for fun at night, and my head hurt, 'cause I liked the imperative style and OO was weirdly different but everyone was swilling kool aid so I stuck it out...

          ...and every night I'd discover something in Java that was THE BOMB that would solve that day's problem and every next day I'd find that C++ didn't have that feature (does today, AFAIK, but STL was busted then, so everyone rolled their own)... ...but I moved out of real programming before I got my head around OO.

          And now I'm learning Haskell, just 'cause I've learned that making my head hurt from time to time is a great way of stretching myself, of getting better at everything....

          And I don't understand - at least, I haven't wrapped my head around Monads yet, though I get what they're for. And you know what? No pain.

          None. I can feel the approach of enlightenment. SYB and reflect, baby, introspection and lazy evaluation and side-effect free (or reliably and provably constrained side-effect management) via implicit state passing.

          Whoa.

          I feel like Neo after the roof but just before the hallway - I'm starting to believe.

          I've read the "SYB in C++" paper. I get what they're doing. But they admit the gap:

          SYB in Haskell depends on... features... not available in C++, most notably rank-2 types, higher-order functions, and polymorphic type extension....

          Scrap++ is a great exercise, but how do you get to SYB without those? You don't.

          There's a guy out there that /.ers love or hate, no middle ground, so I won't reference him directly, but he's right: Different programming models change how you think of problems, and the right model opens so many doors you didn't even know existed. Doors you couldn't even have described until you knew they were there, but you were unable to find the hallway until you squinted, looked sideways at the world, and watched it shift... ...and were freed from the imperative....

          "Hello World" is a cool teaching aid in Fortran and C and even perl (do it 15 different ways, without string literals or character types, preferably with a program one column wide :->)

          But Haskell? No. When you learn Haskell, think big. 'Cause its programming model is so way different you have no idea. I'm at the point I almost consider Monads harmful... ...but I'll get the other side of the koan soon.

          And when I have a simple repetitive task that I need to automate, I'll stick to bash, 'cause it's clean and readable, and sufficiently fast and sufficiently limited that I have to force myself to be literate, which makes it so much easier 6 months later when I need to tweak $ remember script.

          I won't use Haskell for that. No way. But that replacement for scrabble/scribble I've been thinking of? That tool for edit

          • Re: (Score:3, Interesting)

            by bzipitidoo ( 647217 )
            Try this for squaring things. There are times when you really do need a new language to express and use concepts that are cumbersome to do in existing languages. LISP, Haskell, Prolog, and those are perhaps different enough to justify this status, and perhaps only Prolog is really different enough, being declarative while all the rest are imperative. Anyway, it's only cumbersome, not impossible. Most of the time, the "right tool for the job" is trivial hairsplitting among very similar languages, as if t

          • What you're really talking about here is the difference between the Turing machine model of computation and the Lambda Calculus model, and you're absolutely right. Even though the two are provably equivalent (try expressing one of your Haskell programs as a while loop with a stack; it works but it sucks having to write it!), the very mentality that you use when programming in a language like Haskell is so totally radically different from how you program in C that it's useless comparing the two.

            In college I

    • Agreed. Our company has an extensiove engineering department, and has always used a lot of in house software. Unfortunately, you have two different peices of related software that really should be combined, but they were written in two different languages. That had gone on for years with software falling into disarray after the engineer that wrote it left. We now have brought it all together and have been standardizing it. We've been converting all client side apps to Visual Studios (flame all you want

    • Re: (Score:2)

      by plopez ( 54068 )
      but it's hell on expenses and new recruits

      How is it hell on expenses if you focus on open source solutions? Also, if you hire people who cannot learn a new technology then you hired the wrong person. Technology will always change. You don't want people who will become dinosaurs in a few short years.
    • If your shop thinks it's "Hard" to learn a few programming languages, then I would worry about hiring you.

      There is a difference between keeping a well stocked and maintained tool-box that covers the basics and being a compulsive tool collector. There's also a difference between keeping a well stocked and maintained tool-box that covers the basics and using a screwdriver for everything. That's the same mentality that tries to use the tip of a hunting knife to turn a precision screw.

  • Its simple (Score:5, Insightful)

    by dintech ( 998802 ) on Friday January 25, 2008 @09:56AM (#22181314)
    It's obvious that perl is best suited to some tasks over others. So is just about any language. The reason you can't use it in most cases is because it's harder to find developers to support it after you disappear than say Java or C#. That's why I won't be writing our new trade routing system in D. [wikipedia.org]

    • Re: (Score:3, Insightful)

      by Phillup ( 317168 )

      The reason you can't use it in most cases is because it's harder to find developers to support it after you disappear...
      But... as a consultant... that is one reason to use it!

      ;-)

    • Glue and objects (Score:5, Interesting)

      by goombah99 ( 560566 ) on Friday January 25, 2008 @01:45PM (#22184772)
      The list missed the most important part of perl. A glue language. Python and a few other languages claim they can be glue languages but that's pretty much a joke to anyone who knows both fluently. Perl is the ultimate glue language for combining diverse output so different programs from different sources, written decades apart in different languages can all work like a well oiled machine.

      The other really odd experience for me was learing object oriented programming. I had been programming in objects since I was first introduced to them when the first NeXT computer came out. I used java. And C++ and such. I thought I understood objects.

      Then one day I learned to program object oriented in Perl. An I learned that while I was fluent in object oriented usage, I really had a pathetic understanding of how they worked and what was actually possible with objects.

      Perl objects are sort of like owning a copy of grey's anatomy or "the visible" man. You son't just see that arms connect to torso's from outside but you see all the sinews and bones and blood.

      It's actually amazing how so many things we think of as different concepts in object oriented programming and data bases are actually different reflections of the same trick. And that's the trick perl use to make objects.

      in perl, an object is any variable that has an attribute that can store a list of package names.

      Let's see what you can do with that.

      Hmmm.... well that list can be your inheritance heirarchy so each package is what you search for methods. But notice that since it's a mutable list a perl object can do something else that most object oriented languages cannot. A variable can change it's "inheritance" list after the fact. it can change it's own class.

      Okay Now this is just a single variable so where to we get attributes of the object? Well, if that variable is say a hash (dictionary) then we can just use the key's as the attribute names. so if were to write self.foo in C++, you would write self->{foo} in perl.

      More fun: let's say you call a method() or ask for an attribute on a variable that does not exist. Well, a perl object can just add more packages to it's inheritnace list. Or it cold write the method on the spot and add it too it's own inheritnace. "I'm my own grandpa". I've used this trick many times to create tables. I don't write any of the "get" or "set" methods. instead I just intercept the call to the method "setfoo()" which never existed cause I never wrote it, then I have perl create an attribute called foo: Self->{foo} = "something". then I have perl write a subroutine called "setfoo" and add that subroutine into a package namespace and put that in it's inhereticnace list.. ("like adding methods to a C++ package outside the declaration". (programming tip: obviously this is could lead to problems with typos, so I also provide the variabel with a list of all allowed attribute names--- but of course I can always add to that list later).

      Now something more exotic. The hottest thing in Data base programming is the realization that sometimes column centric data bases are better than traditional row-centric data bases structures. In perl an object can change which it is, transparently. For example, if I'm a traditional object with a row organization then all my attributes are stored as self->{foo1}, self->{foo2}, self->{foo3}. and so on, just as you might right self.foo3 in python. But I did not have to do it that way. What if instead of making the self variable a hash (dictionary) I had made the self-variable a simple scalar, say an integer. Well at fist this seems stupid, where did all the instance variables go? Well, I just store them in the class. I make the scalar self-variable's integer just an index. The class keeps the instance variables in arrays--that is column based storage--.. SO for example if self = 4, then the attibute foo for this instance now becomes self->class->foo[4].

      The beauty of this is that si

  • ob (Score:4, Insightful)

    by Hognoxious ( 631665 ) on Friday January 25, 2008 @09:57AM (#22181338) Homepage Journal
    A perl interpreter. Wasn't as hard as I thought.

  • 1 Page Version (Score:5, Informative)

    by The_DoubleU ( 603071 ) on Friday January 25, 2008 @10:00AM (#22181384)
    http://www.cio.com/article/print/175450 [cio.com]

  • idiots (Score:5, Funny)

    by Anonymous Coward on Friday January 25, 2008 @10:02AM (#22181402)
    I've heard stories of some idiots using Perl to write a high volume technology website/blog. I'm still trying to find out what site it is.

  • Ray Tracing (Score:5, Insightful)

    by DrWho520 ( 655973 ) on Friday January 25, 2008 @10:12AM (#22181532) Journal
    3D ray tracing using Perl...what? Why?!?

    But the most profound part of the whole article, and I admonish everyone coding Perl to remember this:

    Remember that the full version of Wall's quote states, "Perl is designed to give you several ways to do anything, so consider picking the most readable one." Break up long lines into several statements, store intermediate values rather than passing them down a long chain of functions and use comments and whitespace to make the code clear.

    This applies to any language. If you can do it multiple ways, pick the readable one.

    • Re:Ray Tracing (Score:4, Interesting)

      by Lodragandraoidh ( 639696 ) on Friday January 25, 2008 @11:15AM (#22182336) Journal
      That is why I love python; in most cases there is only one way of doing it - which improves readability, testability, and debugging.

      I was a long time perl programmer before I made the switch to python. All my headaches with perl went away, and no new headaches of similar magnitude have surfaced. So for me it has been an net improvement.

      KISS, DRY, and various other good engineering/development paradigms are embodied in python's development model.

      Perl made it easy to shoot yourself in the foot. Python makes it hard to shoot yourself in the foot -- but you can if you want to. That probably best sums up their differences.

      • Re: (Score:2, Funny)

        by Tsiangkun ( 746511 )
        I dislike python because I have to check if my collaborators used a series of space or tabs to indent their code.

        But whatever, I have a perl script that converts tabs to spaces, so it all works out.

    • Re: (Score:3, Informative)

      by SanityInAnarchy ( 655584 )

      Larry Wall doesn't exactly follow his own advice, there... But I digress.

      I'm not really sure a raytracer was such a horrible idea.

      When looking at a potential application, if it seems to be characterized by a lot of tight loops over intensive calculations, you should probably be looking elsewhere.

      If you can isolate those tight loops, there's a good chance you can do just that part in C. High-performance should be possible.

      It's the real-time response that would be difficult. I wouldn't have a problem writ

      • I mean, yes, it's a bad pattern, but frankly, PHP is "more modern" in the sense that Vista is "more modern"...
        You made me chuckle. :-D

      • Re:Ray Tracing (Score:5, Insightful)

        by ivan256 ( 17499 ) on Friday January 25, 2008 @11:31AM (#22182508)

        If you can isolate those tight loops, there's a good chance you can do just that part in C. High-performance should be possible.


        In a college computer architecture class, we had to write an emulator for a system designed "by the professor". Basically all tight loops performing really basic operations, and a lot of synchronization. We were given sample microcode and programs to test with, and when we turned it in he ran it with different microcode and programs to guarantee accuracy. Accuracy was required to pass, but your grade was based on performance and clarity.

        They only perfect score went to an emulator written in Perl. The built-in hash tables, and some smart programming combined with the ease of parsing the microcode and program data created not only the fastest (some classmates used C, C++, lisp, or Java to write their emulators) emulator, but also the easiest to read of the group.

        It's the programmer that creates slow, unreadable code, not the language.

        • Re: (Score:2)

          by jandrese ( 485 )
          That could well be an indication that the complexity of the program the Professor was asking you to write was a bit too much for the time and skill level of his students. The person who used Perl leveraged a lot of the built-in features of the language to cut his development time down unlike the C/C++/Java guys who were forced to implement their own. That's Perl's biggest virtue: the ability to quickly write programs that work. They won't be the fastest or the prettiest, but they'll tend to be done first

        • Re: (Score:3, Interesting)

          by tyler_larson ( 558763 )

          They only perfect score went to an emulator written in Perl. The built-in hash tables, and some smart programming combined with the ease of parsing the microcode and program data created not only the fastest (some classmates used C, C++, lisp, or Java to write their emulators) emulator, but also the easiest to read of the group.

          It's the programmer that creates slow, unreadable code, not the language.

          Yes, that reminds me a bit about a class I used to teach for a former employer. I was teaching old-time

      • If you can isolate those tight loops, there's a good chance you can do just that part in C.

        Unless your interpreter can detect inner loops and compile them to native code for you. This is one advantage of using a language that targets the JVM or CLR: the widespread interpreters for these targets are designed to do just that. Why should inner loops and outer loops be written in different languages?

        And PHP has been notorious for SQL injections, if undeservedly.

        In my opinion, a language is "deservedly" notorious for security holes if many of the code examples in the language's official documentation are subject to these security holes. For example, if a langua

    • Re:Ray Tracing (Score:4, Insightful)

      by Chelloveck ( 14643 ) on Friday January 25, 2008 @02:57PM (#22185794)

      3D ray tracing using Perl...what? Why?!?

      To the contrary, I think everyone should write a ray-tracer in Perl. Or, more generally, every programmer should take his or her favorite language and use it for something it's spectacularly bad at. Like ray-tracing in Perl.

      Part of the reason is to show that yes, you can use just about any language for just about any task. But that doesn't mean you should. Using a language unsuited to a project gets you familiar with the bounds of the language, so you have a pretty good idea before you start whether or not the language is a good fit for a given task. And it can often teach you a lot about the language, because you'll have to explore the little nooks and crannies to figure out how to get it to do what you want.

      The other part of the reason is that everyone needs a little humbling. This is especially true for anyone who says, "I used to use {language_x} until I discovered {language_y} and realized that {x} is TEH SUCK!" That usually just means that {y} is more suited to what you're doing now. Go code something non-trivial that {y} is unsuited for, and see if you don't end up cursing your new favorite just as much as you curse your old favorite.

  • I wrote a BASIC interpreter (Score:4, Interesting)

    by thomasdz ( 178114 ) on Friday January 25, 2008 @10:17AM (#22181590)
    a few winters ago so I wrote a BASIC interpreter in Perl which wasn't hard, but then from the lessons I learned from that I then wrote the same BASIC interpreter in VMS DCL which was a really interesting week project. (VMS DCL is the Cshell of the VAX/VMS world)
    Why? I dunno, but I did learn a whole lot about Perl.
    I think that's the best way to learn things... make up a fake project for yourself (say, a database, or a simple flight simulator)...then implement it. Then revise it.

  • refund (Score:5, Insightful)

    by darkvizier ( 703808 ) on Friday January 25, 2008 @10:25AM (#22181690)
    TFA:

    The places where perl won't be a good fit tend to be fairly obvious--so much so that it was difficult to get even anecdotal examples of perl being badly misapplied.
    So... you're saying there's really no point to this article. Thanks. I want my five minutes back.

  • According to the article.. (Score:5, Funny)

    by Idaho ( 12907 ) on Friday January 25, 2008 @10:25AM (#22181700)
    ..you shouldn't use perl "In an obfuscated fashion".

    Wait...there are ways to use perl in a non-obfuscated fashion!?

  • My favorite example (Score:5, Interesting)

    by jc42 ( 318812 ) on Friday January 25, 2008 @10:28AM (#22181738) Homepage Journal
    My favorite "You did WHAT in perl?" response is: On several projects, when there were portability problems, I've created a Makefile entry that runs a "man foo" command and pipes the data to a perl script, which generates C files for that system. It's typically just header files, but sometimes also a few .c files with data structures and/or simple functions to intercede with variant library routines.

    It's fun to watch people's reaction when they realize that "You wrote a perl script that reads the manual and generates the code?" I just respond something like "Uh, yeah; you got a problem with that?"

    Especially fun has been the couple of discussions in which I expressed a great deal of skepticism of various "AI" claims. Then someone brings up the fact that I write perl programs that read English-language docs and generate code from them. They're obviously puzzled by the fact that I do this while looking skeptically at "AI" proposals. It's like they expect me to just shrug and write other impossible things in perl.

    • Re: (Score:2, Insightful)

      by Bongfish ( 545460 )
      Pfft. That make your compiler and interpreter AI, too.

      Just sounds like text processing to me, which Perl (and most scripting/shell languages) are designed for.

  • Inline C in Perl (Score:3, Interesting)

    by wbav ( 223901 ) <Guardian.Bob+Slashdot@gmail.com> on Friday January 25, 2008 @10:32AM (#22181778) Homepage Journal
    So there was a case where I needed to create a big recursive data structure in Perl. It could be a hex tree about 8 nodes deep or a binary tree about 32 nodes deep (I say about as some nodes were rolled up into others based on metrics). Anyways, we had about 100,000 items being stored in these trees and I was told to use Perl so that the data coming in could be manipulated in a sane way and we could get some stats on how the data structure performed (memory wise, not speed wise). So, it turns out gathering stats on 32*100,000 nodes is very slow in Perl so I was told to boost performance using inline c. The difference was well beyond two orders of magnitude. The difficulty? There was very sparse information about following recursive objects in inline c at the time. Perl had references but that didn't translate directly to pointers in c. Even so, it was possible and makes a great story for later. You know, "Back in my day we didn't have all this processor power. We couldn't just follow the reference down in native Perl, we had to translate them references to pointers by hand and still we felt blessed."

    • Re: (Score:2)

      by joggle ( 594025 )
      Am I missing something or was that not the best choice by your manager/boss? Why use Perl with inline C (esp. back then) rather than just writing a C/C++ program to do the job other than being told you had to use Perl?

  • Quick repair tool (Score:3, Interesting)

    by oliderid ( 710055 ) on Friday January 25, 2008 @10:55AM (#22182060) Journal
    The last time I have used Perl:
    I'm currently writing a server based application written in c# (mono). The email class of c# was good...but enough flexible for the multipart graphically enriched email I had to send (a report not a spam...Mind you). I couldn't properly configured the MIME Parts (especially "inline"). If I had just c# the only available would have been a commercial library.

    So I end up with Perl. perl -MCPAN -e shell . install MIME::Light (if I remind well)
    a couple lines after I had a tool ready to send emails (based html pages written by my c# application). The script is fired up by my c# application with several parameters. It works.

  • Comment removed based on user account deletion

  • Bollocks (Score:5, Interesting)

    by bytesex ( 112972 ) on Friday January 25, 2008 @11:10AM (#22182276) Homepage
    Skipped right down to the stuff that perl isn't supposed to do: not supposed to be used in high performance/real time stuff - check, as a replacement for shell scripts where shell scripts are shorter - check (obvious-meter off the scale though), it isn't supposed to be used in CGI. Eh. Right. Because, according to the author, we should be using ruby on rails for that. Eh. Right. Again. Why didn't he just outright say that we should be using j2ee with struts and beans and xml based style sheets ! Oh that was 2007 ! My bad.

    Perl was, and is (IMHO) the first and foremost thing you grab when you write web-stuff. CPAN is nothing if not infinite, the web is a text-based thing the perl was designed for, and its speed makes ruby blush. So why ?

    Why try to write off perl all the time. Is it because they can't seem to /win/ ?!

    • Re: (Score:3, Insightful)

      by tknd ( 979052 )

      Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit [cpan.org]. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the

    • Re:Bollocks (Score:4, Informative)

      by VGPowerlord ( 621254 ) on Friday January 25, 2008 @01:40PM (#22184674)

      it isn't supposed to be used in CGI. Eh. Right.

      I can think of a combination of three factors to support this assertion:
      1. CGI.pm is a memory hog, so you really need some sort of acceleration.
      2. mod_perl breaks if you look at it funny.
      3. Any other way of speeding it up locks you into using that particular method, as you end up rewriting your scripts to use it. See: FastCGI or SpeedyCGI.

      For all the things PHP does wrong, these are things that it has done right.

  • When to use Perl? (Score:5, Funny)

    by mlk ( 18543 ) <michael DOT lloy ... AT gmail DOT com> on Friday January 25, 2008 @11:28AM (#22182480) Homepage Journal
    When someone has deleted AWK, and not before.
  • But I've written a Media Center for use on my TV with PHP/PHP-GTK.

    Originally it was just a small project to get through a week of stagnated work. It's actually pretty hacked together but is separated into a client/server setup for use of a single backend and multiple frontends.

    Eventually I plan to port it to C/C++... but for now it seems to be working fine.

  • Another useless article (Score:3, Insightful)

    by outZider ( 165286 ) on Friday January 25, 2008 @12:24PM (#22183384) Homepage
    Articles like this really annoy me. There are indeed tools best suited for each job. Most people are not going to write an end user application with a GUI in Perl, because it's just not normally suited for it. Needless to say, with wxPerl, I've done it. Fancy that, it's readable, too. But, I'm aware it's not good for that.

    What people tend to forget is how extensible a language can be, especially Perl. Blanket statements like "Perl should not be used for the web" is misinformed at best. No one wrote web scripts in Ruby before Rails -- it's all about the framework. Go give the Catalyst framework a try, and tell me again not to use Perl for the web.

    As for high performance computing, remember that the perl interpreter does a few things very well, very fast. We ended up rewriting our web crawling infrastructure at $WORK from Nutch and Lucene in Java to a custom distributed Perl architecture against Xapian. Not only is it much more 'pluggable' than the original solution, we ended up getting a huge increase in speed out of the deal, even putting it up against 64-bit Java. It's anecdotal, and mileage will vary, but there are times that Perl is just better at crunching text than anything else.

    Too many people write off Perl as a relic of the past. What people fail to see is the new Perl renaissance that is quickly approaching. It's a good time to be a Perl developer, judging by the job market. :)

  • 4 Signs You're An IT Tool (Score:3, Insightful)

    by keytoe ( 91531 ) on Friday January 25, 2008 @12:41PM (#22183732) Homepage

    I was expecting the standard litany of anti-perl 'wrong tool for the job' comments in this article, but the 'four things' you're not supposed to do made me laugh:

    1) Real-time or high-performance applications.

    Check. No discussion necessary, but did it even need to be pointed out? Really, if you're even thinking about doing real-time apps in any interpreted language, you need to have your head examined.

    2) As a replacement for shell scripts.

    The example provided points out that using a simplistic perl script that calls 'system' to move files around generates a lot of needless sub shells and processes. OK - good point. However, in the example he provides, he replaces the inefficient perl script with an efficient perl script. How does that help make your point? Unless the point is 'try to write good code' - which isn't language specific.

    3) As a web scripting language

    This is just short-sighted and stupid, and the author suggests we use PHP or Ruby on Rails. OK - there are a lot of choices here, and all of them have advantages and disadvantages. But after reading that I should be using PHP, this quote made me spit coffe on my keyboard: "You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code." Clean, elegant and properly designed code can be written in any language. Some languages encourage this, some make it difficult. Ruby encourages, but I'd stake my reputation on the claim that PHP makes it very hard. Perl is neutral on that spectrum.

    4) In an obfuscated fashion

    Check. No discussion necessary, but did it even need to be pointed out? Oh, I used that one already.

    • Re: (Score:3, Insightful)

      by julesh ( 229690 )
      1) Real-time or high-performance applications.

      Check. No discussion necessary, but did it even need to be pointed out? Really, if you're even thinking about doing real-time apps in any interpreted language, you need to have your head examined.

      Yes. It needed to be pointed out. Look at where the article is published: a magazine targeted at _IT managers_. Many of these people don't really understand the basics of what the languages the programmers they employ are. Articles like

      • Re: (Score:2)

        by keytoe ( 91531 )

        Not really. I've written MVC applications using a homebrew template engine as the view component in PHP, and it wasn't hard. The only real issue with PHP is that it makes it too easy to program badly... programming well in it is no harder than other languages.

        The lack of namespaces and the dizzying array of functions included in the core libraries makes it difficult to write clean code. I didn't say it couldn't be done. In fact, I started the comment by saying that you could write good code in any languag

    • Perl is neutral on that spectrum.

      No [cpan.org] it [cpan.org] is [cpan.org] not [cpan.org].

      Perl has far more tools to support making clean MVC web separation stuff than ruby. The issue is that what represents "good" or "clean" code is domain specific. All the things are showed you are things that are good for the specific problem of document templating for the web. I'd be willing to say that Perl's flexibility lets you code in pretty much any domain cleanly...if you set up your environment to facilitate that.

      • Re: (Score:2)

        by keytoe ( 91531 )
        I've been writing clean MVC based Perl code for web applications for years - I know that it's well suited for the job and I'm not disputing that in the least. However, it is quite easy to write obfuscated garbage in Perl - just as easy as it is to write clean and elegant code. Thus, I declared it 'neutral' on that spectrum.

    • Re: (Score:3, Insightful)

      by sco08y ( 615665 )
      2) You also didn't mention that his inefficient perl script does the same thing bash would have to do: launch cp for each file copy. And it doesn't help the guy's case that he doesn't know any Perl. His efficient example is could be rewritten as use File::Copy; copy($_, "$_.bak") for glob "*.doc"'; Frankly, the fact that Unix shells require that I remember obscure syntax to do what DOS could do with ren *.foo *.bar makes me go to Perl for anything more than a trivial script.
  • From TFA:

    One of the worst things about shell scripting--whether in bash, sh or csh--is that the syntax of the scripts themselves is fairly hard to read.
    So he's saying PERL is easy to read? You're kidding me, right?

    • Re: (Score:2)

      by joggle ( 594025 )
      You're kidding, right? Here's an excerpt from a bash script generated by the auto tools:

      # Parse our command line options once, thoroughly.
      Xsed="sed"' -e 1s/^X//'
      while test "$#" -gt 0
      do
      arg="$1"
      shift

      case $arg in
      -*=*) optarg=`$echo "X$arg" | $Xsed -e 's/[-_a-zA-Z0-9]*=//'` ;;
      *) optarg= ;;
      esac
      done

      Perl can be written in a way that's fairly C-style whereas that's not the case for bash. Bash is great for simple tasks but for more complicated ones it can be

  • Perl is my Swiss Army Knife. Anything that I can reasonably fit in one to five files, I'll do in Perl. If I need a web app of less than 5 or 10 pages, I'll use PHP. Complex webapps, long running heavy daemons are Java.

    That's the 10,000' view, anyway.
  • As part of a senior project that was actually the visualization piece of somebody's thesis, I wrote a data visualization/analysis frontend (for software performance analysis data storied in a database) in perl. Full GUI, Perl/Tk, graphs/charts/etc. This was in the 1999-2000 timeframe.

    It ran quite well on the hardware of the day, and had the advantage of actually behaving on just about everything in a very mixed-platform campus (Linux, Windows, Solaris, AIX, etc).

  • I wrote an enormous script that takes two XML files as input, one describing data structures I want to encode and another that describes the binary format I want to encode it as (such as a starting byte, the number of bits to store for the length of the message, the type of CRC/checksum to use, etc.). It then creates all of the necessary C code to encode and decode these records bitwise with options for using simple compression algorithms as well. It also has options for generating C++ code wrappers and ano

  • Sheesh... (Score:3, Insightful)

    by idontgno ( 624372 ) on Friday January 25, 2008 @02:06PM (#22185076) Journal

    First, and more than sufficiently, of all: who the $curse is going to be taking coding language advice from CIO Magazine? If it's a real practicing software developer, they need to turn in their geek card and coder license immediately. And if it's a CIO or other PHB-level entity, for the love of $DIETY, don't let him start dictating software tool choices on the basis of stuff like TFA!

    Second, the author of the article sounds like he has only ever dabbled with Perl, sysadmin-tool-like. He betrays a disturbing unawareness of the recent development in frameworks and methodologies in the Perl universe that track most of the major software development trends and tools available in other communities. His advice, positive and negative, seems stuck in basic out-of-the-box Perl 5.6 or something. Most of the time, that's plenty good enough for the ol' sysadmin "Swiss Army Scripting Language" approach, but certainly missed out on a lot of good work. (The reader comments after the article call him out on this pretty well, so I won't rehash.)

    Third, a lot of the advice is universal, not Perl-specific. I mean, stuff like "Don't use Perl in an obfuscated fashion" is like "Don't drive a 1973 Dodge Ram pickup truck while drunk." Very true, very sage advice, but the problem is not Perl (or the truck), it's the obfuscation (or the drunkenness). Code readability is a timeless, domainless, endless problem. The only reason Perl gets picked on for readability is basically bad PR.

    Frankly, a lot of TFA just sounds like an excuse to fill up a few column-inches the editor needed filled in.

  • They forgot #6 (Score:3, Funny)

    by blantonl ( 784786 ) on Friday January 25, 2008 @02:14PM (#22185176) Homepage
    #6 - Slashdot

  • one of my proudest moments... (Score:3, Interesting)

    by UID30 ( 176734 ) on Friday January 25, 2008 @02:20PM (#22185248)
    was in using perl to perform an xsl transform converting xml directly into executable perl code. hooray for eval. surprisingly it was one of our most stable jobs and ran for years with no problems. i think this was mostly because everybody was afraid to touch it once it got going... is there anything perl can't do?

  • Real World Counter Example (Score:3, Informative)

    by localman ( 111171 ) on Friday January 25, 2008 @02:44PM (#22185614) Homepage
    Sure, Perl is pretty much on everyone's shit list these days. But as the Director of Development for Zappos.com from 2000 through 2006, I have to take exception with his claim that perl is unacceptable for high-performance applications. Of course it depends what type of high performance applications you're talking about, but for high performance web applications it's actually quite good.

    Specifically, the Zappos site, built with Perl, was rated the fastest retail website in the world [internetretailer.com] for broadband customers for much of 2006. It beat out Amazon, Dell, Best Buy, etc, etc, you name it. It was also the most consistent speed and the fewest errors. Search Internet Retailer for the more numbers. It always places in the top 5.

    Also, the claim that one might mix HTML in scripts is a sign that this guy hasn't actually used Perl in the past decade. Everyone switched to powerful templating systems sometime in 98. There are several very nice web development frameworks for Perl these days. Just like almost any other language.

    The rest of his criticisms are more valid. I wouldn't try writing graphic intensive applications, or anything with heavy math processing in Perl. And the most common complaint, that it doesn't prevent you from writing messy code, is certainly true. Of course, just because your code looks neat doesn't mean it's good code either :)

    Cheers.

Slashdot Top Deals

To communicate is the beginning of understanding. -- AT&T

Close