From: "Jay Kuri" <j...@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
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
