Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Perl Programming The Almighty Buck

Call For Grant Proposals In Perl Development 137

On Elpeleg writes "The Perl Foundation is giving out grants for Perl development ranging from $500 to $3,000 in February 2009. You neither need to have a large, complex, or lengthy project nor be a Perl master or guru. You are encouraged to submit a proposal if you have a good idea and the means and ability to accomplish your Perl project. The deadline for proposal submissions is January 31, 2009."
This discussion has been archived. No new comments can be posted.

Call For Grant Proposals In Perl Development

Comments Filter:
  • by schmidt349 ( 690948 ) on Monday January 12, 2009 @09:58PM (#26427093)

    Your proposal must be submitted in the form of a self-aware regular expression with at least 200 backreferences.

    • This is an awesome idea, can I implement the project in Python ;)

  • Wishlist (Score:5, Insightful)

    by coryking ( 104614 ) * on Monday January 12, 2009 @10:17PM (#26427279) Homepage Journal

    1) Better tools... improve EPIC. Perl lacks a good IDE.
    2) Get perl running on IIS using ISAPI (basically, mod_perl for IIS).
    3) Either finish Perl6 or give up. Nobody cares about the CLR thing, give us Perl6 the language. The delay in shipping Perl6 is killing the language.
    4) ????
    5) Create a branch in CPAN called Ponies::*. There are many libraries for ponies such as Ponies::Little or Ponies::Fast.

    • Re: (Score:1, Insightful)

      1. It's perl. You really don't need any IDE.
      2. If you're trying to use perl on IIS, you shouldn't be using perl.
      3. Well, alright, I'll agree there.
      4. !!!!
      5. I'd like to place a vote for ...well crap, I can't actually think of anything CPAN lacks.
      • 1) Good IDE's like eclipse or Visual Studio make a programmer more productive. They have refactoring tools, they analyze your code and make it easy to track down where stuff is, they parse your comments to provide very useful tooltips that describe function parameters (intellesense). Without such tools, it takes significantly longer to learn how a new project fits together. Just being able to right click on a bit of code that calls a method and say "goto definition" is worth the price alone.
        2) Nonsense

    • Re:Wishlist (Score:4, Informative)

      by ImustDIE ( 689509 ) on Monday January 12, 2009 @11:38PM (#26427929)

      1) Better tools... improve EPIC. Perl lacks a good IDE.

      Activestate's Komodo is a pretty decent IDE.

      • Eh, I like Komodo all right, but I wind up writing the majority of my code in plain old gedit [gnome.org]. Actually, almost any editor with syntax highlighting is "good enough" for me. Several of my active projects number in the many thousands of lines of code, too.
    • Re:Wishlist (Score:5, Informative)

      by bcrowell ( 177657 ) on Monday January 12, 2009 @11:51PM (#26427995) Homepage

      The delay in shipping Perl6 is killing the language.

      Perl is dead, Netcraft confirms it.

      But seriously, why does it make perl any less viable a language if a production-quality perl 6 takes a long time? Perl 5 continues to be lovingly maintained. Perl 6 will be able to run perl 5 modules in compatibility mode. Perl 6 is already out, and if you want to use it, you can; it's just not yet up to the same very high standards of quality and performance as perl 5.

      • If you were starting a new project would you base it on Perl5 when you aren't sure Perl6 is just around the corner? No offense to anybody, but Perl6 is a classic example of the second system syndrome and serves as an excellent reminder of why it is never a good idea to rewrite code. While they were busy rewriting code, PHP, Ruby and Python cleaned their lunch.

        Perl 6 is already out

        It isn't out until I read about its release on Arstechnica and Slashdot.

        • by doom ( 14564 )

          If you were starting a new project would you base it on Perl5 when you aren't sure Perl6 is just around the corner?

          You would if you knew anything about perl. In fact you probably would if you knew anything about software -- betting the farm on something that's barely out the door isn't a very bright move.

          As for the second system effect, you're probably correct to some extent, but the solution to that isn't "ship perl 6", the solution is to point out that it's silly FUD -- the perl 5 project is going st

      • "it's just not yet up to the same very high standards of quality and performance as perl 5. "
        I think the moderators missed the humor in your post.
      • by cervo ( 626632 )
        Perl has "shortcomings" depending on taste (for some people it may be perfect and that is fine). Personally I hate Perl's object system. Some of the other languages fix some of the Perl "shortcomings". In particular I like Python's object system. Still I find a lot of things in Python that I preferred in Perl (like the regular expressions, and also I'll take braces over white space or even ruby's end). However for me even with all its flaws (for me) I now prefer Python over Perl.

        Perl6 has potential.
        • by chromatic ( 9471 )

          Some of the other languages fix some of the Perl "shortcomings". In particular I like Python's object system.

          Perl 5's object system came from Python. See Larry Wall's Programming is Hard, Let's Go Scripting [perl.com]:

          I'm not terribly qualified to talk about Python however. I don't really know much about Python. I only stole its object system for Perl 5.

        • by doom ( 14564 )

          Personally I hate Perl's object system.

          Ha. You speak as if there were only one. (I wish). Multiple different ways of implementing Objects exist in the perl 5 world, and there are many, many new attempts at fixing perceived limitations of the earlier styles. You've got your choice of Moose, Object::InsideOut, Class::InsideOut, and so on.

          Whether this is a symptom of perl's glorious diversity or a lack of sane standardization, is of course open to question.

          It's not that Perl 5 is broken, it's that othe

    • Re:Wishlist (Score:4, Funny)

      by somenickname ( 1270442 ) on Tuesday January 13, 2009 @12:28AM (#26428321)

      1) Better tools... improve EPIC. Perl lacks a good IDE.

      Why would you need an IDE to write a single line of code?

    • Re: (Score:3, Insightful)

      by outZider ( 165286 )

      1) EPIC sucks, and so does Eclipse. Try ActiveState Komodo, but they half ass it anyway. Perl does need a good IDE.
      2) Download ActiveState perl, set PerlISAPI.dll as the handler for your pl or cgi files, done. It's free, too.
      3) Shut the hell up. Have you seen the amount of progress on Rakudo lately? Pugs, the reference implementation of Perl6, has been around for a while. The real thing, the real working thing, is in development and you can play with it and actually write scripts now.
      4) Eat crap.
      5) What.

    • Re: (Score:2, Informative)

      1) Better tools... improve EPIC. Perl lacks a good IDE

      Have you seen Padre?. [perlide.org] A Perl IDE written in Perl.

    • Re:Wishlist (Score:4, Insightful)

      by asackett ( 161377 ) on Tuesday January 13, 2009 @01:51AM (#26428897) Homepage

      My Perl IDE is called XEmacs. Perhaps you've heard of it?

    • by bytesex ( 112972 )

      A standard cross-platform GUI library; perl is eminently suited for GUI work but we still have to make do with an interface to GTK. I know this isn't the nineties anymore, but GUI work still has a place.

      Dead on with the perl6 thing. Continue with it, but call it something else. And produce perl6 with new and improved classes and runtime-context-free grammars and regexes without a VM.

      • by Vspirit ( 200600 )

        http://www.wxwidgets.org/
        http://wxperl.sourceforge.net/

        Is a likely solution.

        Is it that you did not know about this,
        or that you did know and found it wanting?

        • by Vspirit ( 200600 )

          Parrot SDL is also quite interesting in this context.

          http://www.wgz.org/chromatic/talks/parrot_sdl/index.html

    • Perl lacks one thing only: a compiler.

      Having to install a metric boatload of modules and runtime on the clients system everytime you deploy an application gets old fast.
      • thats because its designed to be interpreted.

        perlcc does produce binary output though

        • I'm guessing you haven't actually tried perlcc?

          Even on a trivial program it generates several gigabytes of intermediate files. I have tried to compile a normal project once, and when it wasn't done yet after about four days I've stopped this madness.
      • Having to install a metric boatload of modules and runtime on the clients system everytime you deploy an application gets old fast.

        I agree with you on this. I've yet to see a really good "best practices for perl deployment".

        That said, wait until you deploy a PHP application only to find that PHP wasn't compiled with some feature you were using. Good times.

    • by x78 ( 1099371 )

      Heard of vi? lighttpd?

      • Syntax Coloring and auto-indentation is a baseline that every text editor should support. IDE's parse your code and give you useful information about it. They parse your comments (xmldoc for C#) and use them for tooltips. They help you find function declarations. They help you refactor your code. They help manage your files. They integrate into your version control system. And so on.

        To go slightly off topic, I think intellesense was the best invention ever. It gives a programmer a very strong incentiv

        • by dwpro ( 520418 )

          Do you write perl projects in Visual studios? If so, please let me know your setup (visual perl, etc), if not, STFU.

          Perhaps not all (there may be plugins I'm not aware of) but most of what you mentioned exists in VI either inherent or through plugins (refactoring, file management, and version control integration, even intellisense). Granted, some of these aren't as feature rich implementations, but they are there. It also sports some features that VS does not have, like more advanced code folding, more l

    • > 1) Better tools... improve EPIC. Perl lacks a good IDE.

      Padre [perlide.org] is improving in leaps and bounds so that problem should hopefully be gone soon.

    • 5) Create a branch in CPAN called Ponies::*. There are many libraries for ponies such as Ponies::Little or Ponies::Fast

      and Ponies::OMG

    • How about adding tests to CPAN that let you know when updates to your modules break other modules that use it. Probably not easy to do, but it is something that would be great to know.
  • by NewbieProgrammerMan ( 558327 ) on Monday January 12, 2009 @10:45PM (#26427531)

    You neither need to have a large, complex, or lengthy project nor be a Perl master or guru.

    You do, however, have to be able to fit it all on one line.

  • House of glue (Score:1, Interesting)

    by Anonymous Coward

    Perl is the best glue there is. It works on everything. Still, I would not build a house out of glue.

    • Re: (Score:1, Funny)

      by Anonymous Coward

      Perl is the best glue there is. It works on everything. Still, I would not build a house out of glue.

      I thought we were still talking about ponies for a second...

    • by dwpro ( 520418 )

      And C is the best engine. It outperforms anything. I would not build a house out of engine.
      A language is not limited by its most compelling feature(s).

    • Mix the right kind of glue [wikipedia.org] with some gravel and sand, and you've got something you can build a house on.
  • by Anonymous Coward

    someone should make a bullshit undocumented language with fucked up syntax and call it "Eels".

    then someone else can use it to make a bullshit framework for lazy fucks called Hovercraft.

    Guess how many lines it takes in Ruby?

    Does that include the lines to take the cock out of your mouth or not?

  • I think this hackneyed PERL is dead rhetoric is finally starting to annoy me. Is the current development direction moving away from PERL as a language for web development? Absolutely. I find myself using PERL for basic tasks I don't feel like writing code for in say C# or Java because it is annoying to do so and I can do it in a few lines in PERL. So the purpose of the language has changed dramatically and at the same time not at all, since that usage is pretty much at the heart of PERL's origins.
    I say t

  • Worth $500? (Score:1, Funny)

    by MortenMW ( 968289 )
    #!/usr/local/bin/perl
    print "Hello, world!\n";

    How much will I get for this?
    • Sorry, your program hard-coded the path of perl. That disqualified it. I'm going to get the $500 instead with the following masterpiece:

      #! /usr/bin/env perl
      print "Hello world!\n";

      SCNR

  • by Anonymous Coward on Tuesday January 13, 2009 @06:20AM (#26430711)

    The delay in releasing Perl 6 ( shut up with the idiot mantra, "It'll be ready when it's ready" ) has done more to kill off the language than any other factor.

    New scripters have taken up Python or Ruby. Old timers have got frustrated at the philosophical debate about what it means to 'release' a language. Some of the people involved with the project appear to be having a bit of a laugh at the expense of the coders who have been using the language. No goals, no milestones. Some airy fairy notion that it will never be complete. The PR job alone has been a total disaster.

    It would have been better not to mention Perl 6 until it was ready - haven't you Perl people learnt the lesson about announcing the next product before it is ready for sale and while you still have the old product to shift?

    If a stable version of Perl 6 is not released in 2009 then Perl will be left dead in the water. That may already have been the case for some time.

    • Complaining about the long wait for Perl 6 is so 2003!

      In the mean time the core Perl developers have been busy designing and building the programming language (and runtime environment) of the future.

      2009 is the year to start getting excited about Perl 6 again!

      For anyone paying attention, things have been really starting to come together in the last year.
      - Parrot [parrot.org] is nearing 1.0 production release (in March 2009)!
      - Perl 6 on Parrot [rakudo.org] (Rakudo) works and gets new features added every day (see recent note [rakudo.org] say

  • With Perl6 taking almost a decade to complete it doesn't make sense to waste this small amount of money on anything other than getting Perl6 out the door?
    • by ChrisDolan ( 24101 ) <chris+slashdot.chrisdolan@net> on Tuesday January 13, 2009 @07:48AM (#26431273) Homepage

      The primary reason for the longevity of the Perl 6 development effort is shortage of volunteers. To put it harshly, people like you spend their energy complaining instead of helping.

      The money is most certainly well-spent on both Perl 5 and Perl 6. I was a Perl Foundation grant recipient to work on Perl::Critic, a static analysis tool and code quality aid. My contributions are making a positive influence to help with the readability, maintainability and portability of large Perl 5 codebases. (read TFA and you'll see my name mentioned) Perl::Critic is being actively used in improving the Parrot codebase.

      What have you done to help?

      • by cervo ( 626632 )
        I'm going to say that another thing missing is direction from the top. The last time I poked around (admittedly 6 or so months ago) it didn't look like there was a clear path laid out to release. More developers won't fix that. Without someone at the top directing things you have chaos. Not only that, but volunteers will lose motivation after a time. Many are goal oriented and want to see that they are making progress towards a goal.
        • Re: (Score:2, Interesting)

          by chromatic ( 9471 )

          Many are goal oriented and want to see that they are making progress towards a goal.

          The Rakudo spectest chart [rakudo.de] has daily updates of exactly that.

          • by cervo ( 626632 ) on Tuesday January 13, 2009 @01:11PM (#26436455) Journal
            Passing tests is something, but does not in itself equate to completeness.

            Look at http://www.perlfoundation.org/perl6/index.cgi?development_dashboard [perlfoundation.org] that seems to have some goals. But still "Language Definition" is on the todo list. And "Language Definition" seems a pretty big item to me, as changes in that can change the tests. Not only that, would you write a bunch of code in a language knowing that at any moment it could be invalidated by a few small tweaks? I wouldn't, not production code at least.

            They have some other things like the command line (deciding what it is, then implementing it), deciding what the installation package is, etc.. But still until the language design is frozen, you will never be done. And if a major change is made that results totally rebuilding the architecture you could end up throwing a lot of work away.

            This todo list seems more like a brainstorm. Really what is needed is someone like Larry Wall to finish his documentation, then someone to write tests based on the Perl 6 language design (In Perl 6) and then passing those tests can become a chart to Perl 6. Although there will still be issues such as installation package, converting modules in CPAN and getting it working with Perl6, etc... But the most important thing is to get the language down. Then people will start playing with it to get a jump on learning Perl 6. And once the language is finalized it can start to be used in some corporate settings as a piece of beta software.

            Most likely the real Perl 6 revolution won't come until CPAN (or some other entity like it) is made for Perl 6 and has some of the more useful modules (like DBI among others). Right now a large part of Perl's value is CPAN and the various modules available. That is another project that cannot even really fully start until after the language is finalized.
            • Not only that, would you write a bunch of code in a language knowing that at any moment it could be invalidated by a few small tweaks? I wouldn't, not production code at least.

              No one's suggesting you do so for Perl 6 right now. Ask again later this year.

              But still until the language design is frozen, you will never be done.

              Perl 5 is 14 years old, and its language design still isn't frozen. Almost every question of language design in the past year regarding Perl 6 has come from the implementors, whether

  • when I read this post was the Ministry of Silly Walks and their grants, I don't know why :-P

  • What is killing perl (at least at my job) is it's lack of a proper, modern, standards compliant webservices toolkit.

    SOAP::Lite is a sorry mess. It's *simply amazing* that it works *at all*. I've tried to scratch that itch to fix it so many times, but the internals of SOAP::Lite are so *incredibly* convoluted, that it's damn near impossible.

    Perl needs a completely new SOAP toolkit, with real WSDL support for all the different document modes.

    That ONE thing will keep perl entrenched deep in the guts of the cor

    • SOAP::Lite IS a sorry mess..

      Definately what you say is true about how replacing it with something that actually works would be the gift that keeps giving to Perl.

      There are alot of crap perl modules on CPAN with the word SOAP in the title. What a pity, because they do so much damage. A typical perl coder used to glancing at CPAN to see if there is an module available tells his boss, "Yep we can do SOAP," confident in the general high quality of CPAN modules thus far encountered. Then after spending wee

      • Maybe the future will be something more along the lines of Nomadic Pict, or Mozart/Oz or maybe some new experimental linear logic programming language seemingly a perfect fit for exchanging web resources over the internet.

        I'm intruiged. In general about the potential of logic programming languages (I'd love to replace SQL with Prolog in a number of contexts), and specifically about your proposition, but I'm not sure I see how constraint/logic programming is the perfect fit for web services. Can you elaborat

        • Lemme preface that I am not an expert at logic programming but it is what intrigues me at the moment. I'll try and explain why it intrigues me, and why I want to learn more. I'm not saying the following is true, but I will try to convey why I am curious about it.

          Web services are potentially distributed over many places. The coolest stuff I've seen with regards to distributed programming is with logic programming languages.

          Forget openness for a minute and read this: http://www.mozart-oz.org/documentat [mozart-oz.org]

    • So, make something better.

      • by plurgid ( 943247 )

        Indeed. If I had the time and resources.
        Unfortunately, time is something I don't have these days.

        Which is why I bothered posting this. I hope someone who does have the time will pick it up and run with it.

  • Calculate the probability that holding down the shift key and hitting random numbers will produce a valid PERL program.
  • I'm asking my sources for pointers to the some nice government-paid-for-it-so-we-own-it-right? Space Shuttle source code. Or some nice ICBM or IRBM or ABM firmware, that would do. Cruise missile? Cell phone GPS? Whatever.

    Knock out a quick proposal for porting to perl (if it isn't written in perl already, that is), and off we go!

  • What's needed is a perl script that reads other perl scripts and explains them to other programmers.
  • by hachete ( 473378 ) on Tuesday January 13, 2009 @03:48PM (#26439083) Homepage Journal

    Anyone?

  • I write in Perl almost everyday. They should build in a lot of the CPAN modules so that they will be documented better (with another camel) and I won't have to dig on CPAN for things a lot of new languages come with out of the box. Yes, it's easy to install modules, but many are almost standards at this point and should be brought into the language.

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...