On Mon, Feb 28, 2005 at 03:01:46PM -0500, Sean Quinlan wrote:
> > The last time Perl had an upsurge in popularity, it
> > was because Perl solved a new class of problem better than anything
> > else. Might I suggest that the best way to increase adoption is to
> > learn from our past successes instead of admiring the green fields in
> > Redmond or Santa Clara?
>
> What can we learn from our past successes that will help future success?
> What new problems are there that Perl might be able to be a better
> solution for? You mention making mod_perl easier to manage (maybe we
> should aim down the road a bit though at mod_parrot?) - what other areas
> might increase Perl's usefulness?
I'll be silent on mod_perl, parrot and web stuff.
When CGI took off, Perl was the first tool to grab because CGI was a
text problem, and Perl is great for slinging text.
The area where I see a lot of growth is in testing. I just got finished
writing a column for login about writing a couple of scripts to write a
few hundred thousand regression tests. (No joke.) Perl's great for
that, because testing requires three basic things:
- a solid test framework (Test::More)
- text munging (um, tr///)
- glue into everything (DBI, Mech, XML, SOAP, REST, MD5, ....)
And if you want to run your test suite from the web, it's not like you
don't have options. :-)
<ob-perl-is-great>
I don't know about anyone else, but every time I look at macros in Lisp,
the backquotes and quasiquotation really knots my brain. But in Perl,
writing code that generates code is much easier to comprehend:
print $test <<"EOT";
use Test::More qw(no_plan);
use LWP::Simple;
my \$page = get("$url");
is (length(\$page) > 1024, "Page is longer than 1K");
...
EOT
Let's see. Where are the variables that are expanded _now_, and where
are the variables that are being dropped into the generated code? :-)
</ob-perl-is-great>
Z.
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
