[cgiapp] Why perl lost steam...

Ron Savage ron at savage.net.au
Wed Sep 22 18:53:22 EDT 2010


Hi Bill

On Tue, 2010-09-21 at 18:20 -0500, Bill Stephenson wrote:
> On Sep 21, 2010, at 12:57 AM, Ask Bjørn Hansen wrote:
> 
> > Looking at job statistics and activity in all the "web related" Perl 
> > projects I think it's more a matter of this list being spectacularly 
> > badly named.
> 
> That may be true. Jann Linder used to host and moderate an active CGI 
> mailing list and I really enjoyed the community involved with it. Now, 
> at www.perl.org there is no list described as devoted to CGI except 
> this "Beginners" list. I'm not really a perl/cgi beginner, but I am far 
> from being a perl/cgi expert too.
> 
> The CGI-App list is for the Framework it's named after and doesn't 
> cover perl/cgi.

True. But the messages are not strictly moderated. I'm sure broader
(i.e. non-CGIApp-specific) questions are acceptable. Check the archives
to details.

Our msgs (your post, my reply) are an example of that. No-one's going to
suppress them.

> But this list is not the only one that's seen an active community 
> evaporate. the MacOSX list did as well and it's not because it was 
> poorly named. I miss these once active communities. I enjoyed the 
> banter, the questions, the answers, and the occasions when I could 
> help.

Everything goes in waves. It's neither good nor bad - just human nature.

And yes it can be misused.

What most people hope is that, in general, the result is an increase in
the quality of our lives and for us programmers, in the quality of our
software tools and apps.

> Personally, I think there was a pervasive trend a few years ago to 
> write the shortest line of code, as opposed to the most human readable, 
> and this is why perl code is now often considered obfuscated, hard to 
> write, and even obsolete for most cgi (web) apps.

True. But there has been a powerful and vital backlash against that
attitude, best exemplified in the wide range of Test::* modules, which
encourage openness, interaction, and clarity.

Personally, I use a huge amount of white space in the formatting of my
modules, and other authors do likewise.

Deliberate obfuscation has become its own little backwater, and can be
safely ignored if you are not interested. It no longer says anything
about Perl in general.

> But perl code does not have to be any of those. Perl code can be easy 
> to read, follow, and change. It's just a matter of style.

Correct.

And a fine style to teach and encourage.

> It might also have to do with a trend towards using an SQL database to 
> store and retrieve date for web apps. I never jumped on that bandwagon 

Now you're way off track. Vast numbers of programmers chose a db
accessible via SQL because of the sophistication of the db server.

> either. I figured that storage would get cheaper and faster and so 
> would processing power, so the efficiencies of database engines like 
> MySQL would become less attractive than less complex methods like using 
> CGI.pm's built-in "save" and "new" routines to store and load data. PHP 

They don't become less attractive, but more attractive, because we dream
up more and more things we can do with them.

This leads to more and more load in the server, supported by the better
and better hardware (specs).

Thing 'Search Engine', etc, etc. I doubt Google is based on CGI.pm's
'save' and 'new'. Rather it's based on 100_000 .. 200_000 PCs.

> may make it easier to deal with that, I don't really know, I never 
> wanted to learn SQL, but the glances I've taken at PHP seem to indicate 
> that is the main point behind it.

Nope. PHP's aim is to simplify web page (content) generation.

Whether or not PHP is the best tool for that is debatable, especially
given our [*] preference for Perl.

[*] By 'our' naturally I refer to denizens of this email list.

> I'd offer that Perl became popular because it offered easy ways to get 
> web stuff done, but a small, vocal part of the community seemed to 
> embrace and promote complexity and actively chased away those who 
> didn't embrace it with them. That could be wrong, but something 
> certainly happened here.

Could well be. But you're free to ignore them the same way the rest of
us do.

> It would seem that if the above is true than the way to fix the problem 
> is to spend some time focusing on what made perl popular in the first 
> place.

We focus on it by writing more and more Perl... And hence delivering
nice apps and hence enhancing the reputation of Perl as a productive and
powerful language.

> CGI::App is a great framework and it offers a lot to experienced perl 
> coders who are creating large, complex, applications. But perhaps some 
> work on smaller apps, for smaller businesses, would be appropriate too.

Not all CGIApp-based code in complex. Probably millions of apps, little
and big, have been written using CGIApp. The actual number does not
matter. The usefulness of the apps does matter, big time.

> With that in mind, "Boulder" is interesting:
> 
> http://search.cpan.org/~lds/Boulder-1.30/Boulder.pod
> 
> I think I want to play with that a bit. It looks like it may offer some 
> usefulness for creating small web apps that don't need the heavy 
> lifting afforded by SQL database engines.

Last updated 2002. Hmmmm.

Naturally that (probably) says nothing about the quality of the code.

However, be warned, software technology becomes ever more sophisticated,
and more modern ways of doing things /may/ be superior.

Your preference to hark back to perhaps obsolete software strongly
suggests your need to rethink the bases of your decision-making ideas.


-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622



More information about the cgiapp mailing list