something as simple as a JSON-aware guestbook backend for an AJAX website

I've been programming for a few decades, and Perling for 6 years, and that sentence means almost nothing to me. I'm vaguely aware that AJAX is roughly the web equivalent of "raw mode" for http, but I've not the vaguest clue what JSON is. And I've never wanted to write a guestbook. (Nor contribute to one!)

And I'll never understand the need of Perlers to want everyone else to use Perl?

I love my 20 year old Japanese sports car. It is economic to run, 40mpg when driven with a modicom of care, low service costs and barely a sign of rust after 20 years of non-garaged daily use. And yet has enough performance and handling to provide a few thrills on those rare occasions I get to take somewhere I can utilise it safely. But I never felt the need to encourage all my freinds to get one, never mind strangers. Indeed, part of the original reasoning for buying it was the small degree of exclusivity it provided.

If other people are happier to use $Otherlanguage, why does that bother you?

I've been programming for a few decades, and Perling for 6 years, and that sentence means almost nothing to me. I'm vaguely aware that AJAX is roughly the web equivalent of "raw mode" for http, but I've not the vaguest clue what JSON is. And I've never wanted to write a guestbook. (Nor contribute to one!)

For example's sake, a guestbook is much simpler (in general) than, say, a shopping-cart website with payment processing, stock-level monitoring and wishlists.

Another simple example might be a greeting-card website. The example is contrived - don't get hung up there.

JSON is "JavaScript Object Notation" and is in many cases the preferred format for transmitting data from the server to JavaScript running in the browser, since parsing the data is as simple as eval()ing it in runtime (much easier and typically faster than traversing an XML document). It looks very similar to Data::Dumper's output.



And I'll never understand the need of Perlers to want everyone else to use Perl?

I would like to see more people use Perl because:
• It is Free.
• It is very expressive compared to other languages.
• We typically don't have to purchase or license extended functionality, as is often the case with .Net or Java.
• More mindshare means more ideas are pooled together in the long run, further benefiting all who use Perl.
• Perl6 would do well to be met by as large an audience as possible.
• The stigma of Perl as difficult, esoteric or arcane is not a merit, but a detraction.

If other people are happier to use $Otherlanguage, why does that bother you?

I'm not bothered by others' happiness with $OtherLanguage. What I am bothered by is the prospect that my favorite language today is the COBOL (or SmallTalk) of tomorrow. Sure, *I* think it's great and *I* find it to be very expressive, but if $Employer has invested in $OtherLanguage and feels they can't find another Perl programmer in the future for maintenance, I will end up coding in $OtherLanguage instead. Even if it's not the right tool for the job.

I've worked on enough Java or .Net projects to know that's just not what I want to do 5 or 10 years from now. So, anything I can do now to ensure Perl's increased popularity in 5 or 10 years is worth it to me.

Getting started using baby speak means that to do something terribly simple, you don't need to specify a great deal of modules and type in a bunch of syntax. Compare Perl to COBOL or even Java. (The programs were found at the linked sites, and are their respective property. Used without explicit permission.):

print "Hello, World!";
[download]

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID.     HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400     DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500     DISPLAY "Hello world!" LINE 15 POSITION 10.
100600     STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800     EXIT.
[download]

class myfirstjavaprog
{  
        public static void main(String args[])
        {
           System.out.println("Hello World!");
        }
}
[download]

Can you boil your position down to a single question? Even this post raises such diverse issues such as

• .. there is a large number of would-be Perl users that are intimidated by the vast number of (CPAN) options.
• .. in order to get up-and-running with something as simple as a JSON-aware guestbook backend for an AJAX website we have to understand many things:
• .. Ruby and PHP are technically inferior to Perl in several ways, they are very popular with newcomers because they are easy to get started with.
• "Training Wheels Perl"
• Sure, maybe it's just marketing, but I know what I'm doing and it still takes me a few hours to go from a fresh install of CentOS/RHEL/Ubuntu/Fedora/whatever to a working server with the following installed:

And writing a JSON-aware guestbook probably requires you understand what a 500 Internal Server Error is in any web programming language, including PHP and Ruby.

Installing a new server with a bunch of packages takes a while, but are you doing this weekly? And if you are, why not standardize on a set of packages and go with that, updating your standard install quarterly?

I really don't see what problem you're trying to solve.

Hmmm, if one finds doing a JSON-aware guestbook backend for an AJAX website "simple", I don't think such a person should have much trouble finding out what CPAN is, or setting up permissions of paths.

Note that user permissions have nothing to do with Perl, and neither do 500 server errors. But note that '500 Server Error' does have its own entry in perldiag.

Note further that CPAN isn't Perl. CPAN is a user network. Code on it doesn't have Larry permission, nor has it been blessed by the perl-porters. CPAN is not Perl. Repeat. CPAN is not Perl. Nothing can be derived from the existance of code on CPAN. Heck, there's not even a garantee that what is on CPAN is actual Perl code.

I think that if there were a kind of "Training Wheels Perl" environment that included the kinds of things people are doing with Ruby and PHP without too much pain, we would see Perl begin to gain in popularity with the newcomers. Perl could lose that "Difficult" image it has picked up.

So, your conclusion is that having a community that doesn't share code, or makes sharable code hard to find, is actually a good thing? Because it reduces options? Well, I guess it's always possible for a newbie block cpan.org on his/her firewall....

{Setting up a new server} I've streamlined the process a great deal and it still takes a while.

Then you haven't streamlined it enough. It's certainly not Perls task to streamline setting up your server. Most people will want to install many pieces of software that isn't written in Perl anyway. To be able to quickly install a new server, the correct answer is to use a repository, using whatever package manager is appropriate. I use yum and (Solaris) quickstart.

I can imagine what it takes for a newcomer to get up-and-running with some of the more advanced tools like Catalyst + Template + DBIx::Class

Well, they aren't "advanced" for no reason. But how would you solve it? Forbid the existence of Catalyst? Do you have any solutions?

The existence of bicycles with training wheels doesn't in any way prevent the existence of bicycles without. (Unless the EU gets involved.) The "Training Wheels Perl" as I understand it is NOT "this is the way to work, always", but rather "this is the way to start". And as people tend to outgrow training wheels bicycles, they'd likewise outgrow the training wheels Perl.

Jenda


Support Denmark! Defend the free world!

While you and I might be very comfortable plucking the good stuff from CPAN (or rolling our own) there is a large number of would-be Perl users that are intimidated by the vast number of options.

So what? Perl can't be all things to all people. I see absolutely no problem with sending people that can't deal with CPAN to Ruby or PHP. I'd certainly rather do that than lose anything from CPAN. All that diversity is what makes it go!

I think that if there were a kind of "Training Wheels Perl" environment that included the kinds of things people are doing with Ruby and PHP without too much pain, we would see Perl begin to gain in popularity with the newcomers. Perl could lose that "Difficult" image it has picked up.

I doubt it, but feel free to set one up and give it a try. Think of the fame and glory! You might want to re-name Perl while you're at it - the accumulated reputation isn't going to help you sell it as the new hotness. "Perl Lite" perhaps?

Sure, maybe it's just marketing, but I know what I'm doing and it still takes me a few hours to go from a fresh install of CentOS/RHEL/Ubuntu/Fedora/whatever to a working server with the following installed:

A few hours? What are you complaining about? You should try to get all that going with Ruby or PHP sometime! I think you'll be surprised by how hard it is.

-sam