http://www.perlmonks.org?node_id=561252


in reply to Perl is dying

Well, there's a few things you can do, personally, to save perl. First thing, stop thinking of mod_perl when you think of a faster CGI. Instead, think of FCGI. It's everything you say you wish mod_perl was.

Also, while you've got some points with perl6, I think the community can show at least as much by getting 5.10 out the door, and good work is being done by the perl5-porters on that front.

Thanks for the post, though. Esp. the link.

Edit: The link I meant was How Does a Programming Language Stagnate, by chromatic. The replies are particularly interesting. Thanks, jdporter, for pointing out that I didn't specifiy what link. (And thanks for correcting my spelling too.)

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Replies are listed 'Best First'.
Re^2: Perl is dying
by rodion (Chaplain) on Jul 16, 2006 at 14:27 UTC
    The link that theobtwo identified is well worth looking at, especially the second reply by Peter Scott.

    There is definitely a need for a pre-packged collection of those modules with features that are expected to be part of Perl6, but exluding the filters and such that are not production-level reliable. As Peter Scott observed in that link,How Does a Programming Language Stagnate, ease of use by those who don't yet have extensive knowledge is an area where Perl5 could use some catching up reletive to competitors. Among other things, he says

    So you've got to be clued into which "hip" modules to load just to get Perl behaving the way many people think it should. The standard documentation doesn't have a roadmap leading people in this direction; they pretty much have to dig around and keep up with the latest Perl news and books.
    While the synopses and exegeses are quite well written and quite satisfying for the many in this forum with the necessary interest and background, a summary for those programmers that are less a part of the process could be wise insurance. It would take time from someone with authoritative knowledge, so it might be stealing resources from the speedy advance of the Perl6 project, but I think it would be worthwhile insurance that the full complement of users is still there when Perl6 is production-ready.
[reply]
Re^2: Perl is dying
by Anonymous Monk on Jul 14, 2006 at 16:54 UTC

    Oh, of course, FastCGI, that project that's been virtually dead for years, with a homepage that looks exactly like it did back in 2001. Certainly this can standup to the enormous hype of Ruby on Rails!

    Look, CGI is old and boring. It doesn't matter if you tack on "Fast" to it; people see "CGI" and walk away. Perl needs something like Ruby on Rails. It can even be assembled from existing technology (FastCGI, if you like), but it needs a new, catchy name, and it needs to be marketed. Look at AJAX. AJAX is pretty much Dynamic XHTML. It's 5-year-old technology, but slap a new acronym on it and all of the sudden people take notice.

[reply]
      Uh, Ruby on Rails runs on FastCGI.
[reply]
        Which is, ironically, why I use FastCGI. mod_perl is too heavy for my needs (80% of my web requests don't require Perl in every HTTP process). I tried PersistentPerl/SpeedyCGI, liked it, but found a couple of bugs and the maintainer seems to have disappeared. I thought FastCGI was pretty much dead, then discovered that it's what Rails uses. Since it seems to be getting a new audience, I figured that I wouldn't be left in the lurch like I was with PersistentPerl.
[reply]

      Hype isn't just generated by having a flashy homepage; it's also something generated by lots individuals. If you keep pointing out mod_perl, you perpetuate the myth that mod_perl is the best way to do not-CGI with perl.

      Would a better name and a better homepage fix things? Possibly, but not if people keep talking about mod_perl instead of fastcgi.

[reply]

      All web based applications are CGI. Arn't they? Did I miss some change? Could be, dunno.

      AJAX: Actualy AJAX is new becuase it involves a new process (retrieving data from the server after the page has finished loading.

      Are you realy saying now that it doesn't even matter if the code/language is good or bad, it just doesn't have enough hype? Realy if your only concern is hype then start hyping the language instead of saying its dieing.

      Honestly if your the same AM as the OP then I'm very disappointed because the original rant was actualy quite well written and thought out, while this argument was just lame.


      ___________
      Eric Hodges
[reply]

        Actualy AJAX is new becuase it involves a new process (retrieving data from the server after the page has finished loading.

        Well to be fair the XMLHttpRequest API (or rather its MS equivalent) has been available for about five years in IE and there were methods of doing similar things before that using tricks with frames and stuff. The API became available in Mozilla in 2002. I can't quite put my finger on when AJAX was first coined, but it was quite recently and the use of this raft of technologies certainly predated the naming.

        Update: The Wikipedia article on Ajax clearly indicates how far the use of these technologies predates the coining of the name.

        /J\

[reply]
      Except Rails uses FastCGI for deployment too....
[reply]
      AJAX stands for Async Javascript and XML... not XHTML
[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations