[Catalyst] RFC: The paradox of choice in web development

[Octavian Râsnita]

From: "Jay Kuri" <jayk at ion0.com>
> I think it's a mistake to try to compete with Rails for the newbie.
> Some large percentage of newbies will never do anything more than
> occasional tinkering if they stick with web development at all.  We
> have limited resources and we don't want to waste our time there.  To
> make Catalyst accessible to the rails-like newbie, we have a TON of
> work to do and it's the wrong direction, in my opinion.

I think most of Catalyst users agree with this.

I think Catalyst shouldn't target the market of small personal web sites 
stored on free web servers, or on $5/month web servers.

But I also think Catalyst shouldn't target only the very big sites like 
Amazon or Ebay, but all the software companies that create web applications 
for their clients, but of course, the serious software companies, not those 
that have 1 or 2 developers.

We should find why those companies prefer using DotNet and Java even for web 
sites, and try to show them that Perl/Catalyst is better.

Most of them prefer Java/DotNet because they can find more programmers that 
know those languages, and we can't do anything to show them that there are 
many Perl programmers also, because there aren't, but we can show them that 
the productivity of Perl/Catalyst is much bigger than of Java/DotNet, so 
they won't need to hire so many programmers and finally they will be more 
efficient.

Most of the software companies, or simple programmers know very well that 
Perl is a language very hard to maintain, because it is not strict, and each 
programmer can have its own way of doing things, and this is true.
But at least we can show that Catalyst is not Perl, like that kind of Perl 
used in CGI scripts, but it is a "language" object oriented, it can reuse 
the code very easily and it is very clear and because of this... easy to 
maintain.

It wouldn't be bad if the next Catalyst book would have a section for "Good 
practice" and for "Recommended modules", or even better, if these sections 
would be promoted on the Catalyst's web site.
That section shouldn't list a single module for a single operation, but 
there could be 2, or 3 modules with clarifications for when it is helpful to 
use one of them and when to use the another, but not let the users to choose 
from tens of modules of the same kind on CPAN.

Another advantage of using Java/DotNet is that now most of the existing 
software companies already have their own created libraries that can be used 
on all their projects, so the productivity would be bigger if they would 
continue to use those languages.
But we can show that most of the modules they've made, probably higher level 
libraries that help them to connect to HTTP and FTP servers, send email, do 
authentication, and other things, already can be done with modules from 
CPAN.

But if we just tell the world about how "great" CPAN is and nothing more, it 
would be a disadvantage, because they will really see how great CPAN is, and 
they won't know what's good for them in there, and if the combination of 
modules they found is a good one that really works without having problems 
in the future.

I know a few people that started to learn perl very few years ago, but 
they've started to learn to create CGI scripts, of course, because almost 
all the Perl books teach that, at least as an example, and this is not ok, 
because if they'll pass to Ruby, they would start immediately to create Ruby 
on Rails apps, and if we compare Perl's CGI with Ruby on Rails... it is very 
clear who wins.

Maybe what I think it would be a good idea might be too aggressive, but I 
think we should also tell the potential Perl/Catalyst programmers what to 
not do, something like:

"The list of books that you should not read, because they are outdated:"
and
"The list of CPAN modules you shouldn't use because they are not good:"
or
"Don't create CGI scripts, because they are slow, hard to maintain and 
require too much work"

and put a very short explanation about why it is not good for them to do 
those things (and others).

And of course, we should also show what the users should preferably do.

This way, there are bigger chances that there will appear if not just a 
single way, at least a limited numbers of ways to create programs with perl, 
and not an infinite number like now, and if someone will see that a certain 
site made with Perl is not working fine, he might also see that there was a 
warning for not making the site that way, because it is not recommended, and 
the site doesn't work fine not because it is made in Perl, but because it 
doesn't follow some recommendations.

I think that this way of using negative and positive recommendations is the 
only good way, because otherwise, nobody will convince all the perl 
programmers not to create new CPAN modules, and reinvent the wheel.

Octavian