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

I also agree with Dan.

Catalyst tries to solve that problem in the RoR way - it offers a default
ORM, a default template in its manual, but there are much more other perl
tools which are not defined as the recommended ones.

For example, HTML::FormFu is a very good form manager, but it doesn't create
(yet) the javascript code for client-side validation. Instead of improving
this form manager only (if it is the considered the best) to also create the
JS code, other similar modules are improved, so finally becomes harder and
harder to choose which is the best one, but none of them would be perfect.

So finally the programmers might prefer to move to RoR or Django or
something else, because it is prefered to eat a medium-good apple, than to
find a very good apple after trying tens of bad-taste apples.

Unfortunately I don't know if there is a solution for this, but less perl
sites means that the demand for perl programmers is lower and lower each
year, and this is one more reason for programmers of not beeing interested
in perl.

Octavian

----- Original Message -----
From: "David Steiner" <***@technikum-wien.at>
To: <***@lists.scsys.co.uk>
Sent: Saturday, February 14, 2009 12:01 AM
Subject: [Catalyst] RFC: The paradox of choice in web development

Post by David Steiner
Hi there,
here's an interesting article that dandv (from #catalyst) has posted on his
wiki [1]. it explains how TMTOWTDI can be bad for people starting out in
catalyst, and how compareable webframeworks (RoR/Django) deal with this.
[1]
http://wiki.dandascalescu.com/essays/paradox-of-choice-in-web-development
i added my comments to the article, suggesting that we step up on the
documentation and marketing! we need to give the layperson a easier ride in
starting out with catalyst. and that requires more tutorials/screencasts,
better official documentation, and more books being written. tell me what you
people think of the article and how we can get catalyst more used and known.
Greetings,
David
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

Jay Kuri

2009-02-15 10:55:49 UTC

I've been watching this discussion and I have ranted my less than
constructive ravings in #catalyst.

My more constructive ravings are below...

First: Perl jobs are not decreasing. While there is not a ton of
'Buzz' around perl anymore... If you look at actual jobs stats:

http://tiny.cc/kkcCM

(or http://www.indeed.com/jobtrends?q=+perl+engineer%2C+perl+developer%2C+php+engineer%2C+php+developer%2C+ruby+developer%2C+python+developer%2C+&l=
)

Perl is above all the others by some margin. It's hard to see all
these other languages getting the buzz, when the one we all love is
practically ignored in the press... but that doesn't make it any less
good and though it's hard to tell right now, buzz does not equal real
world usage.

There are two problems I see, really. One problem I think David
points out correctly... there is precious little 'easily accessible'
means to learn about catalyst and what the conventional 'preferred'
pieces are... so those that learn it are those that really need it's
power, and have come searching for it. Those that are just trying to
pick something and go will piss off to some more spoonfeed-easy-to-
learn framework.

I'm not convinced that's a bad thing. The second problem I see is
that we don't seem to know who we want to market Catalyst to. We look
over and see Rails and Django getting a lot of press and raves and
such, and think 'I want to go to there.'

Overall, though, I think that most of us who have used Catalyst for
any period of time know that it is not a beginners platform. It is a
powerful set of tools to solve difficult and complex problems.

I think we need to take a page out of the old Unix'ers handbook.
Stop looking to be as accessible to newbies as the other options, and
embrace our true position... which is simply Catalyst is better. Not
because it's easier to learn, and certainly not because it forces you
into one (easy or not) way of doing things.... but because you can
bend it to whatever form you need to solve whatever problem you have,
even the ones that are less computer science-y and more computer-room-
in-the-office-y. (though we can certainly do the former as well)

In my opinion, we should embrace the fact that Catalyst is bigger,
more complex, and more able. When someone says 'well, Why isn't
catalyst as clear-cut and simple to use like Rails?' we should
encourage them... tell them 'Go... Go play with rails... and when you
grow out of it, we'll be waiting for you.'

We should position Catalyst as the big-sister framework, the one whose
there for you when you are ready to take on big problems that can't be
solved by a bit of automatic CRUD, the ones that can't be stuffed into
the channels that someone else has already dug. We should
communicate an attitude of 'yes, we can solve easy problems too, but
we are particularly good at solving the harder ones.'

The fact is that Oracle does not try to compete for the low end of the
market with MySQL. They don't want it. They never did. Why do we?

Jay

Post by Octavian RÃ¢snita
I also agree with Dan.
Catalyst tries to solve that problem in the RoR way - it offers a
default ORM, a default template in its manual, but there are much
more other perl tools which are not defined as the recommended ones.
For example, HTML::FormFu is a very good form manager, but it
doesn't create (yet) the javascript code for client-side validation.
Instead of improving this form manager only (if it is the considered
the best) to also create the JS code, other similar modules are
improved, so finally becomes harder and harder to choose which is
the best one, but none of them would be perfect.
So finally the programmers might prefer to move to RoR or Django or
something else, because it is prefered to eat a medium-good apple,
than to find a very good apple after trying tens of bad-taste apples.
Unfortunately I don't know if there is a solution for this, but less
perl sites means that the demand for perl programmers is lower and
lower each year, and this is one more reason for programmers of not
beeing interested in perl.
Octavian
Sent: Saturday, February 14, 2009 12:01 AM
Subject: [Catalyst] RFC: The paradox of choice in web development

Post by David Steiner
Hi there,
here's an interesting article that dandv (from #catalyst) has
posted on his
wiki [1]. it explains how TMTOWTDI can be bad for people starting out in
catalyst, and how compareable webframeworks (RoR/Django) deal with this.
[1] http://wiki.dandascalescu.com/essays/paradox-of-choice-in-web-development
i added my comments to the article, suggesting that we step up on the
documentation and marketing! we need to give the layperson a easier ride in
starting out with catalyst. and that requires more tutorials/
screencasts,
better official documentation, and more books being written. tell me what you
people think of the article and how we can get catalyst more used and known.
Greetings,
David
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

Octavian Râsnita

2009-02-15 14:41:40 UTC

Post by Jay Kuri
I've been watching this discussion and I have ranted my less than
constructive ravings in #catalyst.
My more constructive ravings are below...
First: Perl jobs are not decreasing. While there is not a ton of 'Buzz'
http://tiny.cc/kkcCM
(or
http://www.indeed.com/jobtrends?q=+perl+engineer%2C+perl+developer%2C+php+engineer%2C+php+developer%
2C+ruby+developer%2C+python+developer%2C+&l= )
Perl is above all the others by some margin. It's hard to see all these
other languages getting the buzz, when the one we all love is practically
ignored in the press... but that doesn't make it any less good and though
it's hard to tell right now, buzz does not equal real world usage.

In my country there are no jobs for perl developers. There are jobs for
Java, C#, C++ and PHp developers.
The knowledge of perl is considered as an advantage in very few job
announcements, but it is wanted mostly for administrative tasks, not for web
development, and there are very few programmers that even heard about
Catalyst.
Maybe that's why I wrongly thought that this is the same in other countries.

Post by Jay Kuri
Overall, though, I think that most of us who have used Catalyst for any
period of time know that it is not a beginners platform. It is a
powerful set of tools to solve difficult and complex problems.
I think we need to take a page out of the old Unix'ers handbook. Stop
looking to be as accessible to newbies as the other options, and embrace
our true position... which is simply Catalyst is better. Not because
it's easier to learn, and certainly not because it forces you into one
(easy or not) way of doing things.... but because you can bend it to
whatever form you need to solve whatever problem you have, even the ones
that are less computer science-y and more computer-room- in-the-office-y.
(though we can certainly do the former as well)
In my opinion, we should embrace the fact that Catalyst is bigger, more
complex, and more able. When someone says 'well, Why isn't catalyst as
clear-cut and simple to use like Rails?' we should encourage them...
tell them 'Go... Go play with rails... and when you grow out of it, we'll
be waiting for you.'
We should position Catalyst as the big-sister framework, the one whose
there for you when you are ready to take on big problems that can't be
solved by a bit of automatic CRUD, the ones that can't be stuffed into
the channels that someone else has already dug. We should communicate
an attitude of 'yes, we can solve easy problems too, but we are
particularly good at solving the harder ones.'

If we want to compete for the niche of big sites, we should see why Google,
Yahoo, Amazon, Ebay and other big sites like these don't use Catalyst, what
they are using and why.
Maybe they also have some reasons, because I guess they have developers that
know very well about all the possible options.

Catalyst shouldn't compete for the low end sites not because it wouldn't be
nice, or because Catalyst can't be used for simple web apps, but because it
uses perl and it requires shell access to install it and third party
modules, and this option is not available for most low end sites, so it is
not an option for everyone.

Post by Jay Kuri
The fact is that Oracle does not try to compete for the low end of the
market with MySQL. They don't want it. They never did. Why do we?

The comparison is good, but not very exact. I know companies which don't use
PostgreSQL but Oracle, because Oracle is better known (because it offers
discounts to the software companies that distribute it, so they have the
interest of promoting it), and because Oracle offers tech support.
The big companies usually want to pass the responsability to others, even if
they need to pay some more.

Octavian

Russell Jurney

2009-02-15 14:50:38 UTC

Yahoo has posted some Catalyst specific job listings, so presumably
they use Catalyst for something.

Russell Jurney

Post by Octavian RÃ¢snita
If we want to compete for the niche of big sites, we should see why
Google, Yahoo, Amazon, Ebay and other big sites like these don't use
Catalyst, what they are using and why.
Maybe they also have some reasons, because I guess they have
developers that know very well about all the possible options.
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

Kieren Diment

2009-02-15 14:58:24 UTC

Post by Russell Jurney
Yahoo has posted some Catalyst specific job listings, so presumably
they use Catalyst for something.

I can't say much because of confidentiality, but from the Catalyst
survey late last year, I can say that there are some pretty high
profile places using Catalyst around about. It's public knowledge
that two of the biggest streaming media websites in the world use
Catalyst.

David Wright

2009-02-15 18:27:06 UTC

Post by Kieren Diment
I can't say much because of confidentiality, but from the Catalyst
survey late last year, I can say that there are some pretty high
profile places using Catalyst around about. It's public knowledge that
two of the biggest streaming media websites in the world use Catalyst.

Aye, that it is:
http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html

David

Dan Dascalescu

2009-02-15 18:39:38 UTC

Post by David Wright
http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html

Thanks for the link. I added it as a support URL to
http://www.appliedstacks.com/website/Bbc_Iplayer

Tobias Kremer

2009-02-15 19:12:18 UTC

Post by David Wright
http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html

Thanks for the link. I added it as a support URL to
http://www.appliedstacks.com/website/Bbc_Iplayer

Cool, I've updated the "Sites using Catalyst" page in the wiki.

--Tobias

Alexander Hartmaier

2009-02-17 00:21:38 UTC

I thought you refer to youporn.com ;-)

- Alex

Post by David Wright
http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html
Thanks for the link. I added it as a support URL to
http://www.appliedstacks.com/website/Bbc_Iplayer
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

Octavian Râsnita

2009-02-15 20:09:40 UTC

Post by David Wright

I can't say much because of confidentiality, but from the Catalyst survey
late last year, I can say that there are some pretty high profile places
using Catalyst around about. It's public knowledge that two of the
biggest streaming media websites in the world use Catalyst.

http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html
David

I think it could be good to have a link to a "Success stories" page in the
main page of catalystframework.org that also show it.

Octavian

Cosimo Streppone

2009-02-16 15:32:47 UTC

Post by David Wright

http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html

I think it could be good to have a link to a "Success stories" page in
the main page of catalystframework.org that also show it.

We're not BBC of course, but I took some time
to add the My Opera community site (developed by our team
in Opera Software) to appliedstacks.com.

I never heard of this site before, but since it's mentioned
here I assume it's somewhat "trusted".

http://www.appliedstacks.com/website/My%20Opera

We use Catalyst not for the main backend stuff, but for
the administration tools. We used it as a "pilot project".

If you want to mention it, you're welcome to do so.

--
Cosimo

Dan Dascalescu

2009-02-16 16:30:46 UTC

Post by Cosimo Streppone
We're not BBC of course, but I took some time
to add the My Opera community site (developed by our team
in Opera Software) to appliedstacks.com.

Nice, thank you.

Post by Cosimo Streppone
I never heard of this site before, but since it's mentioned
here I assume it's somewhat "trusted".

I have no idea who's behind AppliedStacks - I discovered it
accidentally while doing the research for the Paradox of choice essay.
I contacted their support e-mail with a bunch of bugs but no reply so
far (it's been 4 days). AppliedStacks is a structured wiki and seems
decent. Most of the sites added have been crawled by bots from pages
listing "Web sites powered by...", and those include our
http://dev.catalyst.perl.org/wiki/sitesrunningcatalyst and
http://www.catalystsites.org/

These two are the trusted places for listing Catalyst applications.

Dan

danielcer

2009-02-18 04:40:30 UTC

Post by Cosimo Streppone
I never heard of this site before, but since it's mentioned
here I assume it's somewhat "trusted".

Hi everyone,

The applied stacks wiki is actually a hobby site of mine. As Dan Dascalescu
mentioned, most of the sites listed there include a citation so you can find
out what the original source material was for whatever tool set claim is
being made.

Other sites have been submitted as "Self reports". Here, someone is claiming
that they were involved in building a site and thus are a credible source
regarding what was used to build it.

In any case, I do my best to monitor new submissions and changes to existing
entries. Besides deleting obvious spam, I try to keep an eye out for any
questionable claims.

So, hopefully, things should be relatively accurate overall.

-Dan

--
View this message in context: http://www.nabble.com/RFC%3A-The-paradox-of-choice-in-web-development-tp22005769p22067963.html
Sent from the Catalyst Web Framework mailing list archive at Nabble.com.

Dan Dascalescu

2009-02-18 05:48:14 UTC

On Mon, Feb 16, 2009 at 2:25 AM, Dan Dascalescu

Post by Dan Dascalescu
I have no idea who's behind AppliedStacks

Update: it's Daniel Cer - http://dmcer.net.

Post by Dan Dascalescu
I contacted their support e-mail with a bunch of bugs but no reply so
far (it's been 4 days).

Update: Daniel responded to all my e-mails and promptly fixed the
smaller issues I reported. Other enhancements are in the works.
AppliedStacks is a very cool idea, I think.

Dan

Jay Kuri

2009-02-16 21:43:25 UTC

Hey all,

Cosimo: Cool.

I wanted to add that Denny de la Haye has put up perlisalive.com. He
is looking for some success stories to cover. It'd be great if
anyone who has some success stories / perl liveliness to share could
submit them there.

Jay

Post by Cosimo Streppone

Post by Kieren Diment
I can't say much because of confidentiality, but from the
Catalyst survey late last year, I can say that there are some
pretty high profile places using Catalyst around about. It's
public knowledge that two of the biggest streaming media websites
in the world use Catalyst.

Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html

I think it could be good to have a link to a "Success stories" page
in the main page of catalystframework.org that also show it.

We're not BBC of course, but I took some time
to add the My Opera community site (developed by our team
in Opera Software) to appliedstacks.com.
I never heard of this site before, but since it's mentioned
here I assume it's somewhat "trusted".
http://www.appliedstacks.com/website/My%20Opera
We use Catalyst not for the main backend stuff, but for
the administration tools. We used it as a "pilot project".
If you want to mention it, you're welcome to do so.
--
Cosimo
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

Tobias Kremer

2009-02-15 18:28:38 UTC

Post by Kieren Diment

Post by Russell Jurney
Yahoo has posted some Catalyst specific job listings, so presumably
they use Catalyst for something.

Maybe we can get permission from the respective companies to publicly
state that they're using Catalyst? For now, a good starting place
would be the "Sites using Catalyst" page in the wiki (which by the way
really should become a featured, maybe even standalone page on the all
new Catalyst site which Jay is working on AFAIK). Having popular
companies on your side is always a big plus - especially for
undecided, buzzword-aware managers :) RoR has a lot of high-profile
sites on its site, too ...

--Tobias

Tobias Kremer

2009-02-15 18:43:30 UTC

Post by Octavian RÃ¢snita
In my country there are no jobs for perl developers. There are jobs
for Java, C#, C++ and PHp developers.
The knowledge of perl is considered as an advantage in very few job
announcements, but it is wanted mostly for administrative tasks, not
for web development, and there are very few programmers that even
heard about Catalyst.
Maybe that's why I wrongly thought that this is the same in other countries.

Same here in Germany! The big companies mostly choose Java for
whatever, whereas the agile new web startups go with either PHP or
RoR. I can only think of one important (German) site from recent times
that is built with Perl and AFAIK they're in the process of
transitioning to RoR, too. Apart from the US and UK there aren't many
countries in the world still using Perl for big web development
projects and high-profile sites. I'm already starting to get angry
every time somebody pulls out another chart or statistic which is
supposed to show that Perl is as strong as ever because this simply is
NOT true - at least not for every place in the world.

--Tobias

Robert L Cochran

2009-02-15 21:12:26 UTC

Post by Jay Kuri
The fact is that Oracle does not try to compete for the low end of
the market with MySQL. They don't want it. They never did. Why do we?

The comparison is good, but not very exact. I know companies which
don't use PostgreSQL but Oracle, because Oracle is better known
(because it offers discounts to the software companies that distribute
it, so they have the interest of promoting it), and because Oracle
offers tech support.
The big companies usually want to pass the responsability to others,
even if they need to pay some more.
Octavian

Well said. Availability of support, tons of free documentation, very
flexible pricing options, plus extremely good education and
certification programs, is what puts Oracle ahead. There is a huge mass
of getting-started type documentation in favor of Oracle, and they make
it freely available on the web. They have excellent formal certification
programs. I can speak from actual experience -- I've taken several
Oracle University classes.

In my company, the selection of programming languages is determined by
what is specified in our Enterprise Architecture. That specification
does not include perl or perl-ish frameworks. It does include .NET and
Sun Java. For frameworks at Tier B, we use Rational Application
Developer and various Rational tools. Yes, they cost a lot of money, but
there are a lot of people trained in their use and there are a heck of a
lot of free tutorial resources available. That means an applications
programmer faced with a deadline can get support fast. And while we are
relatively small customers to IBM (which markets the Rational Suite), we
still get fairly good pricing because we already contract for so much
IBM support and we have used IBM mainframes since they were first
produced many years ago. Choices are driven by price and support. We
have a lot of Microsoft and Sun-certified people. We buy heavily into
Sun and IBM equipment. We don't have any perl people. Large enterprises
want new projects to follow the Enterprise Life Cycle. I'm not sure how
perl fits in the ELC, because so many different reviews from different
IT areas are required in the ELC and I'm not sure how perl would pass
scrutiny in these areas.

Without the training, without the documentation, without the tools
needed to educate positive masses of programmers, Catalyst will not go
very far. It is very hard to use right now, unless you have training.

A wise fellow out in California once compared two word processing
products, Microsoft Word and WordPerfect, many years ago. He wrote, in
part: "..it is hard to beat the top quality documentation that is
produced by Microsoft." That is why Microsoft Office is the most widely
adopted officeware platform now. Microsoft provided great documentation
from the start, made Word and other tools very easy to use, and people
bought. I think Microsoft's dominance in the market is testimony to the
effectiveness of their superb documentation. Pricing is certainly
involved too, but Office was never a closely guarded secret made
available only to an elite few. It gained dominance because it was made
available to everyone. Microsoft went one step further when it wanted to
push adotpion of Internet Explorer: it gave the product away for free
(at a time Netscape was charging a lot of money) and it provided a lot
of documentation there, too.

Bob Cochran

Post by Octavian RÃ¢snita
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

Octavian Râsnita

2009-02-15 22:39:46 UTC

Post by Robert L Cochran
In my company, the selection of programming languages is determined by
what is specified in our Enterprise Architecture. That specification
does not include perl or perl-ish frameworks. It does include .NET and
Sun Java. For frameworks at Tier B, we use Rational Application
Developer and various Rational tools. Yes, they cost a lot of money, but
there are a lot of people trained in their use and there are a heck of a
lot of free tutorial resources available. That means an applications
programmer faced with a deadline can get support fast.

Many companies do the same because if there are more programmers, it means
that they won't depend on a few persons.

Post by Robert L Cochran
I'm not sure how
perl fits in the ELC, because so many different reviews from different
IT areas are required in the ELC and I'm not sure how perl would pass
scrutiny in these areas.

It is hard for perl to pass anything, because perl is just a term, but
nothing more.
10 different programs made using 10 different combinations of perl
frameworks and templates, form managers, ORMS, and other modules can create
10 different languages, and I think there are very few perl programmers in
the world that know them all, to be able to tell that they know "perl" in
general.

Post by Robert L Cochran
Without the training, without the documentation, without the tools
needed to educate positive masses of programmers, Catalyst will not go
very far. It is very hard to use right now, unless you have training.

This is true. There is a lot of documentation in the POD docs, but the
beginners and not only them, don't even know in which POD documentations to
look for... say the list of all the methods of $c object when using certain
Catalyst modules.

Of course, this is just a part of the problem, because at least in my
countries I've seen only 2 books translated that talk about perl, one of
them "Bash and Perl" that has a single chapter about Perl, and another book
that teaches only about Perl, book that appeared originally in 2001, beeing
very old, and not a very good quality in my opinion anyway.
(The books are copied, scanned and read for free anyway, so there are no
many book writers that want to write books here.)
In these conditions, I don't know how many would buy a book about
Catalyst...

Post by Robert L Cochran
part: "..it is hard to beat the top quality documentation that is
produced by Microsoft." That is why Microsoft Office is the most widely
adopted officeware platform now. Microsoft provided great documentation
from the start, made Word and other tools very easy to use, and people
bought. I think Microsoft's dominance in the market is testimony to the
effectiveness of their superb documentation.

Well, I never liked any of the Microsoft Press documentation or their
documentation for the exams of certified professionals.
I always thought that there should be somewhere another documentation that
really tells at least to the certified professionals what's happening behind
the GUI, but I couldn't find such a thing.

Octavian

Jay Kuri

2009-02-15 22:46:19 UTC

I think a lot of folks make good points.

I am not arguing that we do not promote things. I am arguing that

A) it's not as bad as it first seems.

-- and --

B) before we can promote Catalyst / Perl, we have to know where we
want to position ourselves.

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.

Catalyst is a solid framework with lots of available options, I don't
think we should hide that fact. I've worked with Rails, it is what
led me to Catalyst in the first place. Rails is great for greenfield
projects. Using Rails to replace an existing system is a nightmare.
Their 'framework' requires too many adjustments to the problem space
(db changes, changes to how authentication occurs, etc.)

To be sure, Catalyst works easier if you can make those kinds of
decisions / changes. Catalyst has the advantage, though, in the
existing system space because it can be made to fit, and in most
cases, rather easily.

I just went through this process with a client. I had to explain why
we chose Catalyst and Robert is correct here. In the enterprise, it's
a hard sell. It really comes down to total cost and maintainability.
I sold them on Catalyst for a few reasons:

1) There are other perl programmers out there.

2) There are other big companies using perl / Catalyst (iplayer, etc.)

3) Speed of development will increase dramatically.

4) There is commercial support outside of my organization.

5) Catalyst is maintainable and there is a focus on remaining
compatible with past deployments.

It was not an easy sell by any means, but the biggest issue was not
Framework related, but language related.

In my opinion, these are the things we need to highlight.

We have two markets we are selling to, the developers and the
executives / decision makers. The executives need to see the above.
A failed project means their job, and that's what they are looking to
ensure doesn't happen. This is the information that needs to be out
there front and center.

We also have to sell to the developer. This is an easy sell for the
clueful, but we I agree we don't do a very good job of promoting what
Catalyst can do for a developer. I think the key points here are:

1) Catalyst can do greenfield apps very easily, but can also be made
to fit in to an existing system.

2) There is a ton of integration to various systems (Authentication,
Databases, other sources) that save you huge amounts of time when
developing.

3) There are a number of 'helpers' that make it easy to get a basic
app up and running.

4) A premium is put on keeping backwards compatibility. Though
Catalyst is moving forward all the time, once you build it, it will
stay working.

5) We have a hugely helpful community. While they expect you to have
a basic clue, beyond that they will go out of their way to help you
figure things out. The irc channel should be showcased here. Perhaps
even a #catalyst-help should be created with a focus on helping
newbies (a web interface to #catalyst-help would be good)

If we can communicate these things to newcomers (both developer and
executive) we will be in good shape. Again - I don't think we should
compete with Rails for the newbie, Catalyst requires some clue and we
don't have the time / resources to guide people in learning perl.
Again, I think if we really want to compete we should focus on what
Catalyst is... and that is more flexible and capable than other systems.

Jay

Post by Robert L Cochran

Post by Jay Kuri
The fact is that Oracle does not try to compete for the low end of
the market with MySQL. They don't want it. They never did. Why do we?

The comparison is good, but not very exact. I know companies which
don't use PostgreSQL but Oracle, because Oracle is better known
(because it offers discounts to the software companies that
distribute
it, so they have the interest of promoting it), and because Oracle
offers tech support.
The big companies usually want to pass the responsability to others,
even if they need to pay some more.
Octavian

Well said. Availability of support, tons of free documentation, very
flexible pricing options, plus extremely good education and
certification programs, is what puts Oracle ahead. There is a huge mass
of getting-started type documentation in favor of Oracle, and they make
it freely available on the web. They have excellent formal
certification
programs. I can speak from actual experience -- I've taken several
Oracle University classes.
In my company, the selection of programming languages is determined by
what is specified in our Enterprise Architecture. That specification
does not include perl or perl-ish frameworks. It does include .NET and
Sun Java. For frameworks at Tier B, we use Rational Application
Developer and various Rational tools. Yes, they cost a lot of money, but
there are a lot of people trained in their use and there are a heck of a
lot of free tutorial resources available. That means an applications
programmer faced with a deadline can get support fast. And while we are
relatively small customers to IBM (which markets the Rational
Suite), we
still get fairly good pricing because we already contract for so much
IBM support and we have used IBM mainframes since they were first
produced many years ago. Choices are driven by price and support. We
have a lot of Microsoft and Sun-certified people. We buy heavily into
Sun and IBM equipment. We don't have any perl people. Large
enterprises
want new projects to follow the Enterprise Life Cycle. I'm not sure how
perl fits in the ELC, because so many different reviews from different
IT areas are required in the ELC and I'm not sure how perl would pass
scrutiny in these areas.
Without the training, without the documentation, without the tools
needed to educate positive masses of programmers, Catalyst will not go
very far. It is very hard to use right now, unless you have training.
A wise fellow out in California once compared two word processing
products, Microsoft Word and WordPerfect, many years ago. He wrote, in
part: "..it is hard to beat the top quality documentation that is
produced by Microsoft." That is why Microsoft Office is the most widely
adopted officeware platform now. Microsoft provided great
documentation
from the start, made Word and other tools very easy to use, and people
bought. I think Microsoft's dominance in the market is testimony to the
effectiveness of their superb documentation. Pricing is certainly
involved too, but Office was never a closely guarded secret made
available only to an elite few. It gained dominance because it was made
available to everyone. Microsoft went one step further when it
wanted to
push adotpion of Internet Explorer: it gave the product away for free
(at a time Netscape was charging a lot of money) and it provided a lot
of documentation there, too.
Bob Cochran

Post by Octavian RÃ¢snita
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

Octavian Râsnita

2009-02-16 02:31:58 UTC

Post by Jay Kuri
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

Ashley

2009-02-16 03:00:32 UTC

Post by Octavian RÃ¢snita
"The list of CPAN modules you shouldn't use because they are not good:"

Everyone should consider writing more reviews on the CPAN reviews
site too.
It's directly connected with them. It wouldn't carry the same sort of
"authority" as a formal list from a group but I make my choices of
what to at least try first based on reviews somewhat often.

See also: http://www.perlfoundation.org/perl5/index.cgi?
recommended_cpan_modules

-Ashley

Zbigniew Lukasiak

2009-02-16 03:29:04 UTC

Post by Octavian RÃ¢snita
"The list of CPAN modules you shouldn't use because they are not good:"

I've once tried to start a discussion at PerlMonks about that:
http://perlmonks.org/?node_id=515728

Everyone should consider writing more reviews on the CPAN reviews site too.
It's directly connected with them. It wouldn't carry the same sort of
"authority" as a formal list from a group but I make my choices of
what to at least try first based on reviews somewhat often.
http://www.perlfoundation.org/perl5/index.cgi?recommended_cpan_modules

To add to this - I've also started a page for comparing Form
Processing modules at this same p5p wiki:

http://www.perlfoundation.org/perl5/index.cgi?form_processing

I've tried to start from the little, well designed tasks - and later
go to the bigger more difficult fields like comparint full web
frameworks, but sure enough there is also a web framework page at the
p5p wiki:

http://www.perlfoundation.org/perl5/index.cgi?web_frameworks

But there is one even more important point that I would like to make -
I think it is time that we all start writing reviews. It is not an
easy task - and only with practice we'll learn how to do it right, how
to do it so that the whole community will benefit instead of starting
a fight. I personally find it very difficult to write a good critique
without hurting the authors feelings, but it also goes the other way -
if we have more critical reviews the authors (and thats all of us
n'est ce pas?) the authors will learn to treat them as tips how to
improve their software rather as something attacking them.

--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

Dan Dascalescu

2009-02-16 09:53:26 UTC

Post by Zbigniew Lukasiak
http://perlmonks.org/?node_id=515728

Nice but old and too centralized. I suggest adding a "Modules to

Post by Zbigniew Lukasiak

http://www.perlfoundation.org/perl5/index.cgi?recommended_cpan_modules

Again, Data::Dumper mentioned there (before my edit).

Post by Zbigniew Lukasiak
To add to this - I've also started a page for comparing Form
http://www.perlfoundation.org/perl5/index.cgi?form_processing

Cool!

Post by Zbigniew Lukasiak
http://www.perlfoundation.org/perl5/index.cgi?web_frameworks

Wow. I had no idea about WebGUI. Great, another framework to evaluate.
Oh, and Egg, Konstrukt, Solstice, ClearPress and TripleTail too.

...

WebGUI does have a nice least of recommended practices (albeit for
internal developers) at
http://www.webgui.org/community-wiki/development-best-practices. That
inspired me to dig the Catwiki for something similar and found KD's
stub, which I extended and moved to
http://dev.catalyst.perl.org/wiki/best_practices.

I've also conflated a section from the FAQ into this:
http://dev.catalyst.perl.org/wiki/recommended_plugins

Post by Zbigniew Lukasiak
But there is one even more important point that I would like to make -
I think it is time that we all start writing reviews.

And use star ratings! This is ridiculous:
http://search.cpan.org/dist/Catalyst-Controller-BindLex/ has 5 stars.

(kudos to Yuval for warning against using his own module, but please,
add star ratings! It's fun to be sarcastic and not star-rate -
http://cpanratings.perl.org/dist/Moose - but that often ends up being
misleading)

Another odd problem is that some prominent folks in the Catalyst
sphere won't touch the wiki, no matter what (they're not at a loss for
words - they explain things in great detail on IRC). I don't really
know what to say to that. Maybe making an IRC bot that can be told to
write to the catwiki would be a solution.

To sum up:

1. Please star-rate and review modules you (dis)like at
http://cpanratings.perl.org/dist/My-Module

2. As Jay pointed out, Catalyst developers are indeed extremely
helpful on the IRC channel. What I'd like to ask is that when they
explain an FAQ or best practice, or anything that's been asked before,
please copy/paste your explanation on the Catwiki, and I promise I'll
format the stuff.

Dan

PS: Eventually, maybe we can then get a bot running to query catwiki
and return the top search result, a-la:
n00b: purl, Catalyst diet?
purl: Catalyst diet is thin controller, fat model or
http://dev.catalyst.perl.org/wiki/.search?search_type=all&q=catalyst+diet

Kieren Diment

2009-02-16 03:13:55 UTC

I've written two single-user run-the-dev-server-to-get-the-front-end
apps with Catalyst in the last 4 months or so (using Catalyst rather
than a gui toolkit because 1. I don't know how to program a real gui,
and 2. the apps functions are both very closely coupled with the
www). One is a simple web publishing tool that once I've written the
developer docs I will open source this week. The second is a text
mining tool that integrates with Zotero ( http://zotero.org whose 45
table database schema I have to interrogate, and integrate with a much
smaller metadata-database) I need to polish this a little bit more
before I can release it into the wild. Oh yeah, both these apps work
on OS X, Windows and Linux systems, and as the user base are windows
users on managed desktops, I've even got an installer that will
reliably get my apps deployed without bugging the administrators.

So my point is that Catalyst scales well at both ends. 9 million
requests per day? Make sure you've got some competent systems
architects on your team. Single user app? That's a pretty simple
deal if you have a developer or small team who understand the problem
space properly (as a lone gun I've found that feature creep is my
biggest enemy). Once you're through the learning curve, Catalyst's
flexibility is a sunk cost, and the subsequent learning that you have
to do is generally much more closely related to the problem space for
your app than the mechanics of the framework ( I think this is
noticably different with other less flexible frameworks). So the goal
of the book we're writing at the moment isn't a walk-through tutorial,
but a set of materials designed to get you from raw beginner through
the entire catalyst learning curve as quickly as possible - i.e.
minimising the cost of the learning curve.

My experience watching IT projects (I am not a real programmer) is
that project success is frequently a function of the size of the team
- there's a sweet spot or somewhere between 3 to 5 developers where
productivity is maximised. Once you get over 10 develoers then it
seems to me that there are too many parts in the system, and you get
bogged down by friction. I think java, .net and maybe python are
probably more suitable for large teams due to the relative
inflexibility of the syntax, and the verbose approach to semantics -
this provides some compensatory lubricant for large teams. OTOH I
think that perl can't be beat for teams at the ideal size - Ruby is
competing in this space, and we'll see how they go over the next
decade. Oh if you have a large project + high levels of political
input + not directly related to government revenue collection
activities = FAIL :)

Octavian Rasnita

2009-02-16 13:49:42 UTC

Post by Kieren Diment
I've written two single-user run-the-dev-server-to-get-the-front-end
apps with Catalyst in the last 4 months or so (using Catalyst rather
than a gui toolkit

I have also written *only* 1-person projects in Catalyst, because I don't know any Perl developer in my area, but if we want to target absolutely everything, we won't target anything.

Octavian

Dan Dascalescu

2009-02-17 16:48:58 UTC

So the goal of the book we're writing at the moment isn't a walk-through
tutorial, but a set of materials designed to get you from raw beginner
through the entire catalyst learning curve as quickly as possible - i.e.
minimising the cost of the learning curve.

I bought the first book and I'll buy this one as soon as it becomes
available. But there's an interesting point about writing the book at

http://tinyurl.com/closed-books
eq
http://www.shlomifish.org/philosophy/philosophy/closed-books-are-so-19th-century/#admission-of-failuret

Dan

Kieren Diment

2009-02-17 16:58:14 UTC

So the goal of the book we're writing at the moment isn't a walk-
through
tutorial, but a set of materials designed to get you from raw
beginner
through the entire catalyst learning curve as quickly as possible
- i.e.
minimising the cost of the learning curve.

I bought the first book and I'll buy this one as soon as it becomes
available. But there's an interesting point about writing the book at
http://tinyurl.com/closed-books
eq
http://www.shlomifish.org/philosophy/philosophy/closed-books-are-so-19th-century/#admission-of-failuret

Ali M.

2009-02-17 18:03:36 UTC

Kieren Diment you really seem like such a nice, tolerant and decent person.
I could buy the book "God willing" only to make you happy, seriously.

I personally think that 30$ for a nice book, it worthwhile.
Of course if you feel like buying 20 books, 20 * 30 = 600$ , well not
so nice then.

But as Kieren predicted, books and publisher will eventually have to
offer a lot more added value
to create customers. As more ppl blog and write docs for and about
their technologies of choice
less people will be willing to pay for books.

Not to divert from the thread main topic, I believe, we are bit
ignoring the elephant in the room.
When Catalyst is not chosen I personally believe it the combination of
two things
1. Perl is no longer perceived as an easy language, or language that
make development easier.
2. Catalyst perceivably doesn't offer enough added value for
developers who are not that much into Perl
to make the sacrifice and use Perl anyway.

Blaming it on too much choice is not really there.
New Perlers (and I consider my self one) know what the best modules are
DBIx::Class
DateTime
XML::LibXML
Catalyst, CGI::App for starter CGI for complete beginners
Moose
HTML::FormFu
and so on ....

I want to say, that today, there seem to be a general consensus on
what the best modules are ...
New Perlers are not confused.
Those who disagree, maybe old Perlers.

I do wish to see good existing success stories about Perl in sites like
infoq, hackernews (ycombinator) and any other site that is popular
enough to spread the good word.

The community will benefit from more bloggers and success stories ....
and books :)

I bought the first book and I'll buy this one as soon as it becomes
available. But there's an interesting point about writing the book at
http://tinyurl.com/closed-books
eq
http://www.shlomifish.org/philosophy/philosophy/closed-books-are-so-19th-century/#admission-of-failuret

Aye, but I wouldn't have time to get things moving without the resources of
a publisher to pay me an advance. Plus there's the other stuff ...
editorial, people beating you to make sure you reach deadlines etc. Yes
publishers are in trouble, espeically in the software sector, but no,
they're not obsolete.
_______________________________________________
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/

Octavian Rasnita

2009-02-17 18:58:41 UTC

Post by Ali M.
When Catalyst is not chosen I personally believe it the combination of
two things
1. Perl is no longer perceived as an easy language, or language that
make development easier.

More exactly,, Perl is considered a language hard to learn, that creates a code hard to maintain, a language that uses a strange OOP style (because I guess there are no books for Perl beginners that teach about Moose or Mouse), a language which is too flexible and because of this it is not prefered by the large teams of programmers because each of them could have a different style.

Post by Ali M.
2. Catalyst perceivably doesn't offer enough added value for
developers who are not that much into Perl
to make the sacrifice and use Perl anyway.

If the programmers are "not that much into perl", this means that they don't know how to use DBIx::Class and Catalyst and possibly other few modules which are usually used by Catalyst developers, and in that case they can't understand the power of Catalyst.

If Catalyst wants to compete with RoR or other frameworks, it should be as easy to install as those frameworks, and the simple apps should be also very easy to create.

The comparisons between web frameworks are not based on the number of the requests they serve, or on the number of database tables they manage, or on the number of backend servers they are installed on, but on the number of web sites that use those frameworks, so those comparisons might show that there are 100 sites that use RoR and only 5 that use Catalyst, but don't tell that 3 from those 5 sites that use Catalyst have 3 times more visitors than all those 100 sites that use RoR.
And of course, the conclusion is that RoR is much better.

I think that the success of other languages, especially Python is also due to the fact that they support better Windows than Perl.
WxPython is better developed than WxPerl, there are even screen readers that interact with the GUI of the OS in Windows and Linux, and finally... the number of programmers for Windows is bigger than the number of programmers for Linux.
Most Perl programmers use to consider good to publicly despise Windows and those who use Windows, and also consider that Perl is a language for the web, while those who use Python or even Ruby consider them very good languages for creating programs with a desktop GUI.

PerlScript as a client language, or one which is used in .hta applications or Windows Scripting Host, is pretty hard to use if we compare it with VBScript or JScript, and even if we can say that Perl can be used in places where other languages can't be used, practicly it can't be used really successfully. Of course, there are no manuals or training materials for using PerlScript, which are newer than 7 or 8 years.

Even on Symbian, Python is better developed than Perl, which practicly I don't think it is really used on the mobile phones.
I've seen a few persons that say that yes, there are many perl developers that create modules for CPAN, which is great, but the core Perl development team is probably very thin, Perl 6 is not ready yet, while Python 3 was launched and it has a great and powerful core team.

Python is sustained by Gmail and Sun, which create programs that use it, but Perl, even though it is used by big companies like Oracle, just use it, and don't seem to sustain its development.

I think these disadvantages also influence the potential users to think that even the Python frameworks are better, which is not true.

Octavian

Matt Pitts

2009-02-19 21:12:45 UTC

-----Original Message-----
Sent: Tuesday, February 17, 2009 7:56 AM
To: The elegant MVC web framework
Subject: Re: [Catalyst] RFC: The paradox of choice in web development

Post by Ali M.
When Catalyst is not chosen I personally believe it the combination

Post by Ali M.
two things
1. Perl is no longer perceived as an easy language, or language that
make development easier.

More exactly,, Perl is considered a language hard to learn, that
creates a code hard to maintain, a language that uses a strange OOP
style (because I guess there are no books for Perl beginners that

teach

about Moose or Mouse), a language which is too flexible and because of
this it is not prefered by the large teams of programmers because each
of them could have a different style.

Post by Ali M.
2. Catalyst perceivably doesn't offer enough added value for
developers who are not that much into Perl
to make the sacrifice and use Perl anyway.

case

they can't understand the power of Catalyst.
If Catalyst wants to compete with RoR or other frameworks, it should

as easy to install as those frameworks, and the simple apps should be
also very easy to create.
The comparisons between web frameworks are not based on the number of
the requests they serve, or on the number of database tables they
manage, or on the number of backend servers they are installed on, but
on the number of web sites that use those frameworks, so those
comparisons might show that there are 100 sites that use RoR and only

that use Catalyst, but don't tell that 3 from those 5 sites that use
Catalyst have 3 times more visitors than all those 100 sites that use
RoR.
And of course, the conclusion is that RoR is much better.
I think that the success of other languages, especially Python is also
due to the fact that they support better Windows than Perl.
WxPython is better developed than WxPerl, there are even screen

readers

that interact with the GUI of the OS in Windows and Linux, and
finally... the number of programmers for Windows is bigger than the
number of programmers for Linux.
Most Perl programmers use to consider good to publicly despise Windows
and those who use Windows, and also consider that Perl is a language
for the web, while those who use Python or even Ruby consider them

very

good languages for creating programs with a desktop GUI.

Sad to say, but I completely agree with this. It's quite ironic how the
drive of open source has only furthered the need for OS agnostic
software and platforms, which in turn, has actually made life harder for
things like Perl that have strong origins in *nix OSes.

"Oh yeah, we love Linux as a platform for its [list of goodies], but we
can't ask our day-to-day workforce to switch desktops, so we need OS
agnostic platforms that we can build in Windows and deploy in Linux."
Seems to be the credo echoing from the business world.

I myself am currently trying to support multiple developers (content &
perl) working on a Catalyst app from Windows desktops and it's been a
bit of a process. Cygwin seems to be providing the best solution right
now, but Cgywin Perl fork()ing breaks frequently for me in Vista, so no
HTTP::Prefork, which makes development much, much slower.

I really, really want to be able to "just run" my Cat apps in Windows,
and I probably could get it going under ActiveState or Strawberry if I
stuck to it, but I _need_ it to not be that hard. I'm sure I'm not the
only one.

In today's world of software that is cross-platform and OS agnostic at
its core, Perl 5 is showing its age. Still love it though.

v/r
-matt pitts

Cosimo Streppone

2009-02-19 21:29:43 UTC

Post by Octavian Rasnita
I think that the success of other languages, especially Python is also
due to the fact that they support better Windows than Perl.
[...]

Does that mean that you haven't tried?

Post by Matt Pitts
but I _need_ it to not be that hard. I'm sure I'm not the
only one.

It's _not_ that hard.
Perl has been good in the Windows world for long.
Strawberry has improved this a great deal.

Perl on Windows runs most of CPAN without problems.
And yes, I sent my small amount of patches too, whenever
it hurt me.

Perl fully supports building on MSVC from 6 to 2008,
and Win32 GCC.

Post by Matt Pitts
In today's world of software that is cross-platform and OS agnostic at
its core, Perl 5 is showing its age.

Cross-platform is one point where Perl excelled, and
I think it's still very strong.

Then if WxPerl is not developed as WxPython is not Perl's fault.

--
Cosimo

Matt Pitts

2009-02-19 22:02:11 UTC

-----Original Message-----
Sent: Thursday, February 19, 2009 10:30 AM
To: The elegant MVC web framework
Subject: Re: [Catalyst] RFC: The paradox of choice in web development
In data 19 februar 2009 alle ore 16:12:36, Matt Pitts

Post by Octavian Rasnita
I think that the success of other languages, especially Python is

also

Post by Octavian Rasnita
due to the fact that they support better Windows than Perl.
[...]

Sad to say, but I completely agree with this. It's quite ironic how

the

Post by Matt Pitts
drive of open source has only furthered the need for OS agnostic
software and platforms, which in turn, has actually made life harder

for

Post by Matt Pitts
things like Perl that have strong origins in *nix OSes.
[...]
I really, really want to be able to "just run" my Cat apps in

Windows,

Post by Matt Pitts
and I probably could get it going under ActiveState or Strawberry if

Post by Matt Pitts
stuck to it

Does that mean that you haven't tried?

I have, but I stopped working on CPAN installs in Strawberry when
Data::UUID was failing with a build error that I don't remember.

Post by Matt Pitts
but I _need_ it to not be that hard. I'm sure I'm not the
only one.

It's _not_ that hard.
Perl has been good in the Windows world for long.
Strawberry has improved this a great deal.
Perl on Windows runs most of CPAN without problems.
And yes, I sent my small amount of patches too, whenever
it hurt me.

Yes, I need to be more proactive about it and figure out why it's not
working, maybe when I get some tuits.

Perl fully supports building on MSVC from 6 to 2008,
and Win32 GCC.

Thanks for the pointers. Talking about it makes me want to try and
figure it out again.

v/r
-matt

Stuart Watt

2009-02-19 22:06:45 UTC

Post by Cosimo Streppone
It's _not_ that hard.
Perl has been good in the Windows world for long.
Strawberry has improved this a great deal.

Actually, our experience has been pretty horrendous. The problem for us =

has not been Perl but deploying Catalyst apps under Windows. We've used =

IIS and FastCGI, which eventual hard-won success, and we now have a =

60-page installation guide as a result.

Strawberry for us had the same issues as ActiveState - a Perl =

distribution that worked fine, but neither was updated all that =

frequently, and both have no debugging support which makes memory leak =

tracing somewhere between very hard and impossible. In the end I built =

my own Perl, with MinGW, and found it only slightly harder than using =

Strawberry. This was because there had been a core bug in both =

distributions which broke DBI with a memory leak - since the indexing =

part of our app does tens of millions of SQL queries, we could never get =

it to run to completion under Windows. The time it took for the core =

patch to make it into the distribution was about four months.

On Windows, for the most part, Perl is the easy bit. Getting it to talk =

to some parts of Windows is a bit harder. Getting it to run to a =

production standard with Microsoft technology is almost unbelievably =

complex. It would probably be much easier with Cygwin, Apache, etc., but =

then, the whole point of them is to hide Windows, so that isn't really a =

help.

Some of our nasties included:

* ActiveState's PerlEx induced memory errors in file access at a
level below Perl -- these all went away under FastCGI
* File locking under Windows is not always as sound as we'd like (we
hit frequent deadlocks in KinoSearch, which depends on it)
* CPAN installations depending on external libraries sometimes
require help to find the right DLLs (e.g., SSL stuff, XML::LibXML,
XML::LibXSLT) - this seems to be very non-standard across CPAN,
with each module working entirely differently to find DLLs
* Under MinGW, I have even had to manually edit export files to get
DLLs working right
* Windows permissions for FastCGI - let's not even go there! Have
you any idea how many policy settings and permissions are involved
in getting IIS and Perl FastCGI to work?

OK, a lot of this is not actually Perl, but you need a very solid =

background in operating systems in general, networking, DLLs, makefiles, =

etc., if you want to get the whole of Catalyst up from a solid basis.

I'd love to see a Strawberry-type distribution that included a solid =

Catalyst base and the bridge to FastCGI, preferably under both IIS and =

Apache, etc. Give it a proper installer, capable of handling enough =

about IIS/Apache configuration to get a base Catalyst application up and =

running, with decent performance under Windows. If we'd had this, we =

would have saved months of work, and this is not an exaggeration.

All the best
Stuart
-- =

Stuart Watt
ARM Product Developer
Information Balance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090219/d8ac6=
995/attachment.htm

Octavian Râsnita

2009-02-19 23:24:31 UTC

From: Stuart Watt =

On Windows, for the most part, Perl is the easy bit. Getting it to talk=

to some parts of Windows is a bit harder. Getting it to run to a =

production standard with Microsoft technology is almost unbelievably co=

mplex. It would probably be much easier with Cygwin, Apache, etc., > but th=
en, the whole point of them is to hide Windows, so that isn't really a help.

Getting Perl to talk to some parts of Windows and get information from di=
fferent parts of Windows is very hard and it requires knowing very well the=
low level details of Windows, which is a big disadvantage of Perl.
Unfortunately I don't think that this situation will change.

If we talk about "Perl" as that low level functional language that have m=
ore than 200 internal functions, and don't care about CPAN modules, we can'=
t say that it can always create portable programs, because not all those fu=
nctions work well under Windows.

If we consider Perl with all the CPAN modules, then we also can't say tha=
t it is very portable, because there are very many CPAN modules that can't =
be installed at all under Windows, and some other CPAN modules could be ins=
talled but they are just not made very well so they can't be compiled very =
easy.

Perl isn't good for Symbian either and it is not as good as Java for othe=
r devices, but I think that even the lack of portability is a very big issu=
e, it is not the biggest.

I think the biggest issue is the fact that Perl with its CPAN modules are=
very hard to install, because even if perl is installed, many CPAN modules=
can be installed only if the user has root access and shell access, which =
in 99% of the times, it is not the case.

Somebody asked me yesterday if I can create a web site for his small comp=
any, a little web shop which for the beginning should be very simple, no cr=
edit card payments required, and now I think that the costs involved for cr=
eating that site would be much bigger if I would use Perl and Catalyst than=
if I would use PHP.

There are very many sites that offer PHP and MySQL access for a few dolla=
rs per month, and for some more they can offer more other features, but for=
using a host that offer shell access, I would need to have at least a virt=
ual server where I could have root permissions in order to be able to insta=
ll everything I need, including Catalyst and all other Perl modules, but th=
is would cost much more, so that guy might want to choose something cheaper=
for the beginning.

Of course that if his business will succeed, he might want to add new fea=
tures to his site, and he might need to have even a dedicated server, but i=
n that moment I doubt that he will decide to go for a Perl solution and aba=
ndon PHP.

If Perl would offer a solution of deploying the Catalyst apps without nee=
ding to install anything with a root or shell access, using PAR or somethin=
g else, Perl would have a much bigger success.

Octavian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090219/4495a=
351/attachment.htm

Matt Pitts

2009-02-20 00:27:44 UTC

All this talk about Perl/Catalyst/CPAN pains, has got me thinking...

Anybody like the idea of having a local::lib "bootstrap" option to
CatalystX::Starter and possible integration of a script that would
launch a CPAN shell for installing into the local::lib folder?

Or, maybe a separate module Catalyst::Starter::LocalLib?

The idea would be to help folks bootstrap Cat apps and get all the deps
inside the app folder right from the start for easier deployment. Of
course it won't eliminate the need for a shell, but it's still an
improvement.

I could probably put together a patch if I can get some "best practice"
ideas.

v/r
-matt pitts

Tomas Doran

2009-02-20 22:25:36 UTC

Post by Matt Pitts
All this talk about Perl/Catalyst/CPAN pains, has got me thinking...
Anybody like the idea of having a local::lib "bootstrap" option to
CatalystX::Starter and possible integration of a script that would
launch a CPAN shell for installing into the local::lib folder?

CatalystX::Starter is for boot strapping a Catalyst component, not an
application. You'd be looking to add to Catalyst::Devel

Post by Matt Pitts
Or, maybe a separate module Catalyst::Starter::LocalLib?
The idea would be to help folks bootstrap Cat apps and get all the deps
inside the app folder right from the start for easier deployment. Of
course it won't eliminate the need for a shell, but it's still an
improvement.

You'd be looking to have local::lib support built into the scripts &
etc which Catalyst generates, and an additional shell script in your
scripts directory to start a CPAN shell pointing at your
application's local::lib and tricks to install all the non perl core
dependencies into that directory?

That sounds like a good idea, and I've considered hacking on it
myself, but never found the tuits.

Post by Matt Pitts
I could probably put together a patch if I can get some "best
practice"
ideas.

I'm thinking of rails' ability to 'freeze' rails into your
application here. In actual fact, I've never found this feature very
useful as I want to freeze all the dependencies too (this is
possible, but involves hacking environment.rb and etc in the same way
as manually attaching a local::lib to your Cat app).

I guess the biggest argument is likely to be what the correct name
for the directory containing your local::lib is. I also expect there
would be a fair amount of toolchain related yak-shaving to get it
right, but its certainly a feature I'd like to see happen.

Cheers
t0m

Matt Pitts

2009-02-23 00:15:13 UTC

-----Original Message-----
Sent: Friday, February 20, 2009 3:16 AM
To: The elegant MVC web framework
Subject: Re: RFC local::lib + CPAN shell support in CatalystX::Starter
(was:Re: [Catalyst] RFC: The paradox of choice in web development)

CatalystX::Starter is for boot strapping a Catalyst component, not an
application. You'd be looking to add to Catalyst::Devel

Ok, I see why it shouldn't be in CX::Starter, but if it's in C::Devel it
defeats the purpose of it being a bootstrapper because C::Devel requires
Catalyst.

My thinking was to have a system with an absolute minimum Perl/CPAN
install. My current baseline is an up-to-date CPAN (1.92+) via
Bundle::CPAN and Path::Class, but after that no other dists installed
system-wide. For this reason, I was imagining a stand-a-lone dist
(CatalystX::Bootstrapper?) that itself only requires Path::Class,
local::lib and maybe a couple of other "basic" modules.

The usage would then look something like:

$ perl -MCPAN -e 'install CatalystX::Bootstrapper'
...
$ catalystx_bootstrapper.pl MyApp
$ cd MyApp
$ script/myapp_server.pl

The only trick to this is that the bootstrapper command would have to do
all of the following:

- setup initial directories (MyApp, MyApp/locallib, MyAPP/script)

- write its files (script/AppBootstrap.pm, script/myapp_cpan_shell.pl)

- invoke the CPAN shell for the 1st time to install
(Catalyst, Catalyst::Devel, others) this is the tricky part

- invoke catalyst.pl MyApp (the one now installed under locallib) to
actually generate the app

- patch the newly created script files to use AppBootstrap.pm
(maybe there's a way to "hook" catalyst.pl instead of doing this?)

This all might be a bit rough, maybe folks out there have some better
ideas.

Actually, the bootstrapper CPAN shell script would install everything
into locallib. If the user wants something installed system-wide, they
can just use a normal cpan shell. Ideally, the bootstrapper wouldn't
make any assumptions about what should go where.

That sounds like a good idea, and I've considered hacking on it
myself, but never found the tuits.

I currently have this working well for me across a couple of apps. Using
local::lib it didn't turn out to be as tricky as I thought it might, but
I still have trouble with Module::Build based modules because sometimes
it doesn't honor --install_base -or- wants to use an existing one even
though o conf mbuildpl_arg was set.

The other part of this worth mentioning is that all the bootstrap code
is in a separate file (script/AppBootstrap.pm), which makes it easy for
additional scripts to bootstrap the local libs like so:

use FindBin;
use lib("$FindBin::Bin");
use AppBootstrap;

I'm doing this for multiple scripts that need MyApp->... for various
"jobs" as well as _server.pl, etc.

Post by Matt Pitts
I could probably put together a patch if I can get some "best
practice"
ideas.

I haven't played with Rails enough to get this far. Sounds similar,
though.

I guess the biggest argument is likely to be what the correct name
for the directory containing your local::lib is. I also expect there
would be a fair amount of toolchain related yak-shaving to get it
right, but its certainly a feature I'd like to see happen.

Currently, I'm just calling the directory 'locallib', but since the idea
of the module would be a bootstrapper, the name could be a command-line
option that then becomes hard-coded into the bootstrap code. Also, no
yak-shaving as of yet, but there might be some things I'm missing.

Thanks for your input t0m.

v/r
-matt pitts

Octavian Râsnita

2009-02-19 21:30:01 UTC

-----Original Message-----
Sent: Tuesday, February 17, 2009 7:56 AM
To: The elegant MVC web framework
Subject: Re: [Catalyst] RFC: The paradox of choice in web development

Post by Ali M.
When Catalyst is not chosen I personally believe it the combination

Post by Ali M.
two things
1. Perl is no longer perceived as an easy language, or language that
make development easier.

More exactly,, Perl is considered a language hard to learn, that
creates a code hard to maintain, a language that uses a strange OOP
style (because I guess there are no books for Perl beginners that

teach

about Moose or Mouse), a language which is too flexible and because of
this it is not prefered by the large teams of programmers because each
of them could have a different style.

Post by Ali M.
2. Catalyst perceivably doesn't offer enough added value for
developers who are not that much into Perl
to make the sacrifice and use Perl anyway.

case

they can't understand the power of Catalyst.
If Catalyst wants to compete with RoR or other frameworks, it should

readers

very

good languages for creating programs with a desktop GUI.
Sad to say, but I completely agree with this. It's quite ironic how the
drive of open source has only furthered the need for OS agnostic
software and platforms, which in turn, has actually made life harder for
things like Perl that have strong origins in *nix OSes.
"Oh yeah, we love Linux as a platform for its [list of goodies], but we
can't ask our day-to-day workforce to switch desktops, so we need OS
agnostic platforms that we can build in Windows and deploy in Linux."
Seems to be the credo echoing from the business world.
I myself am currently trying to support multiple developers (content &
perl) working on a Catalyst app from Windows desktops and it's been a
bit of a process. Cygwin seems to be providing the best solution right
now, but Cgywin Perl fork()ing breaks frequently for me in Vista, so no
HTTP::Prefork, which makes development much, much slower.
I really, really want to be able to "just run" my Cat apps in Windows,
and I probably could get it going under ActiveState or Strawberry if I
stuck to it, but I _need_ it to not be that hard. I'm sure I'm not the
only one.
In today's world of software that is cross-platform and OS agnostic at
its core, Perl 5 is showing its age. Still love it though.
v/r
-matt pitts

As someone said it many years ago (but I don't remember who was), Perl is
dead... or something like that was the idea.
With that ocasion came the idea of creating Perl 6 that should be totally
different, but who knows when it will be ready.

A better native OOP support in Perl would be wonderful, but I think those
other ideas about how Perl 6 should look like are more important, like to
have a kind of virtual machine like in DotNet or Java, and to use bytecode
precompiled binaries which are totally portable.

Octavian

Andrew Rodland

2009-02-20 00:12:04 UTC

Post by Matt Pitts
In today's world of software that is cross-platform and OS agnostic at
its core, Perl 5 is showing its age. Still love it though.

This isn't as much a Perl problem as it seems to be -- it's the rule all
around that writing code that works on _everything but Windows_ is ten times
easier than writing code that works on everything including Windows. Perl is
just in a unique place to show this. In C, which is hardly more than a
portable(-ish) layer on top of assembler, and which has a small standard
library, code isn't portable at all without significant work (and even still,
Windows is usually the hardest target to hit.) In Java, portability is
considered paramount, so OS facilities are exposed through thick
compatibility layers or else not at all. Perl sits in the middle ground.
Sufficiently "pure perl" code will run on a million and one platforms, but at
the same time Perl was never afraid to expose OS facilities (like stat or
SysV IPC) more or less directly, to allow more powerful code. This has made
it easy to write code that, even though it doesn't use XS as all, is
platform-specific enough to crash and burn on windows. But if it's a
shortcoming in Perl, how do we fix it? By taking all the goodies away from
the Unix folks so everyone has to write to the least common denominator?

Matt Pitts

2009-02-20 01:51:53 UTC

-----Original Message-----
Sent: Thursday, February 19, 2009 1:12 PM
To: The elegant MVC web framework
Subject: Re: [Catalyst] RFC: The paradox of choice in web development

Post by Matt Pitts
In today's world of software that is cross-platform and OS agnostic

Post by Matt Pitts
its core, Perl 5 is showing its age. Still love it though.

I don't see it as a shortcoming and I can't imagine Perl without its
low-level goodies. I'm just saying that by not having a "common
denominator" Perl is a harder adoption as a "platform" in today's world
of cross-OS lifecycles.

Maybe perl6 will provide that "common denominator" without sacrificing
the low-level goodies.

v/r
-matt pitts

Kirby Krueger

2009-02-20 02:08:56 UTC

Post by Matt Pitts
Maybe perl6 will provide that "common denominator" without sacrificing
the low-level goodies.

I've followed the perl6 development some, and the approach is a little
different.

Unlike now, there's not going to be a 'blessed' set of source code
that is a particular perl version.

Instead, perl versions are described by a test suite. If it passes
the test suite, it's perl 6. Whether it's written in C, Haskell,
Lisp, or whatever. It's a different way of looking at things, and far
be it from me to predict if it will work.

That's what's up with the various perl 6 projects right now, like
Rakudo and Pugs. They're sharing the 'spec' test suite and jointly
developing the definition of what is Perl 6, but implementing at a
different rate.

Rakudo continues to make progress (that's the one I'm betting on
crossing the finish line), with more big things working than not, but
like any massive software project, it takes a while to knock off the
last 20% of a project. Here's the birds-eye view:
http://www.perlfoundation.org/perl6/index.cgi?rakudo_feature_status

You can probably write useful projects in Rakudo Perl 6 today, but of
course it'd be crazy to use it for professional development at this
point.

-- Kirby

Stuart Watt

2009-02-20 02:28:43 UTC

A feeling of deja vu has grown. I used to be a Lisp developer, and =

remember a conference presentation by Richard Gabriel about the =

difference between languages emphasizing internal correctness and =

consistency, compared to those emphasizing something that works and =

integrates well. Since then, I found that Perl gave me all the bits I =

liked in Lisp (e.g., hashes, symbolic processing, higher-order functions =

and even closures) but also gave me access to the system (I gave up Lisp =

when I ended up having to build my own web server from socket functions =

up).

There are some nice follow-ups to this at: =

http://www.dreamsongs.com/WorseIsBetter.html. Anyway, maybe this is a =

helpful tool in thinking through the issues for web frameworks. =

Certainly, PHP scores on getting 50% of functionality out there easily. =

Even if extending and maintaining it is a total pain. Although the =

message I'd take is that platforms are in an ecology rather than =

straight competition. i.e., why not just build outstanding Catalyst apps =

when it's the right tool for the job.

--S
-- =

Stuart Watt
ARM Product Developer
Information Balance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090219/22b83=
731/attachment.htm

Dave Rolsky

2009-02-20 01:20:38 UTC

Post by Matt Pitts
I myself am currently trying to support multiple developers (content &
perl) working on a Catalyst app from Windows desktops and it's been a
bit of a process. Cygwin seems to be providing the best solution right
now, but Cgywin Perl fork()ing breaks frequently for me in Vista, so no
HTTP::Prefork, which makes development much, much slower.

Getting _way_ off-topic, but if your target environment is Linux, this is
insane. VMWare is easy to set up and would let your Windows developer run
the app in something much closer to its target environment.

-dave

/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/

Matt Pitts

2009-02-20 02:07:52 UTC

-----Original Message-----
Sent: Thursday, February 19, 2009 2:21 PM
To: The elegant MVC web framework
Subject: RE: [Catalyst] RFC: The paradox of choice in web development

Post by Matt Pitts
I myself am currently trying to support multiple developers (content

Post by Matt Pitts
perl) working on a Catalyst app from Windows desktops and it's been a
bit of a process. Cygwin seems to be providing the best solution

right

Post by Matt Pitts
now, but Cgywin Perl fork()ing breaks frequently for me in Vista, so

Post by Matt Pitts
HTTP::Prefork, which makes development much, much slower.

Thanks for the input...

VMs were considered as an option, but since the Windows folks aren't
Linux-savvy, this means even more systems I have to maintain, perl CPAN,
updates, etc. Not to mention the system resources used by the VM which
could be quite taxing on some of our developers' systems. For me, this
was the insane option.

In reality, two of the devs _are_ currently running the app on Linux, in
their $HOME on a shared DEV server, and using Samba to access their
$HOME from windows. This setup has its own issues that I won't go into.

Anyway, this is a long story, I'll stop ranting. My point was just that
there is no easy way to "just run" the Cat app in Windows.

v/r
-matt pitts

Dan Dascalescu

2009-02-20 09:38:41 UTC

Post by Matt Pitts
Anyway, this is a long story, I'll stop ranting. My point was just that
there is no easy way to "just run" the Cat app in Windows.

I understand the idea of developing a Catalyst app on Windows and
running it on a *nix web server. This is what I currently do, and it's
easy to "just run" an app on Windows with the last Strawberry Perl
(5.10.0.4, released last month) and the internal myapp_server.pl.
After installing Strawberry, `cpan Catalyst::Runtime` and `cpan
Catalyst::Devel` completed successfully, without any intervention.
This is markedly different from alpha version of Strawberry, when
random things would crash in various ways.

Strawberry won me and I've just ditched ActiveState perl, because
indeed, you have various problems with SSL modules, ActiveState's PPM
repository is way out of date, and it doesn't come with the gcc
binaries to compile modules off CPAN. The latest Strawberry, I'm
surprised but happy to say, does that flawlessly.

Dan

Kieren Diment

2009-02-20 09:55:45 UTC

On Fri, Feb 20, 2009 at 2:38 PM, Dan Dascalescu

Post by Matt Pitts
Anyway, this is a long story, I'll stop ranting. My point was just that
there is no easy way to "just run" the Cat app in Windows.

I understand the idea of developing a Catalyst app on Windows and
running it on a *nix web server.

Umm, I've been doing it the other way round recently. Development on
unix and deployment on windows (desktops in my case). Aside from some
sticky cpan issues (which notest install fixes after appropriate
investigation), it's been working well for me.

Tomas Doran

2009-02-20 22:25:51 UTC

-----Original Message-----
Sent: Thursday, February 19, 2009 2:21 PM
To: The elegant MVC web framework
Subject: RE: [Catalyst] RFC: The paradox of choice in web development

Post by Matt Pitts
I myself am currently trying to support multiple developers (content

Post by Matt Pitts
perl) working on a Catalyst app from Windows desktops and it's been

<snip>

Thanks for the input...
VMs were considered as an option, but since the Windows folks aren't
Linux-savvy, this means even more systems I have to maintain, perl CPAN,
updates, etc.

Where are you finding perl programmers from who can't use ubuntu?

Also, how does having people building software for a platform they're
unfamiliar with work for you?

Post by Matt Pitts
Not to mention the system resources used by the VM which
could be quite taxing on some of our developers' systems. For me, this
was the insane option.

I'm sorry, but if you're not prepared to buy your developers
reasonable workstations then you've already lost - it doesn't take
much effort to do a cost/benefit analysis and the cost of developing
on a platform which (a) is causing you pain, and (b) is nothing like
your production environment.

This cost cannot be trivial even with the simple factors, and even
higher once you factor less easy to analyze things such as the
additional risk of your software having had less testing an the
correct environment, and the staff motiviation as developing your
application sounds painful.

How many days of lost time/work is the cost of a reasonable
workstation? 2, 3? Less than a week certainly..

The highest cost to a knowledge based organisation is human
resources, and so not providing your people the right kit to do their
jobs effectively is just cutting your own throat.

Post by Matt Pitts
In reality, two of the devs _are_ currently running the app on
Linux, in
their $HOME on a shared DEV server, and using Samba to access their
$HOME from windows. This setup has its own issues that I won't go into.

Shared dev servers are fail to start with for a number of reasons -
each developer needs their own environment they can mess up as they
wish.

That aside, I don't see why there is any need to share a home
directory between where you're developing and where your workstation
is - all your code is in revision control, right? I suppose you'd
want this if you used a graphical editor, but remote X works nicely
in cygwin, so that could theoretically be a solution (other than the
fact that having several people run a desktop environment on the same
box is going to suck pretty quickly).

I'd recommend having a 'standard' development vmware rig which people
can download, use, trash (and delete / get another one when they
trash) isn't any more effort to setup than 1 new machine +
development environment.

Keeping it up to date after that is again keeping 1 machine up to date.

Don't worry about the individual workstations, they're disposable
(and developers should be able to say sudo apt-get upgrade or
equivalent).. Again, if you _can't_ get your development environment
down to this level of isolation, then something is horribly, horribly
wrong somewhere..

Post by Matt Pitts
Anyway, this is a long story, I'll stop ranting. My point was just that
there is no easy way to "just run" the Cat app in Windows.

I do feel your pain, but I think that's down to the modules you're
using in your application, rather than Catalyst itself (which as many
people will attest, installs and runs fine on windows).

Cheers
t0m

Matt Pitts

2009-02-23 01:56:51 UTC

-----Original Message-----
Sent: Friday, February 20, 2009 4:08 AM
To: The elegant MVC web framework
Subject: Re: [Catalyst] RFC: The paradox of choice in web development

-----Original Message-----
Sent: Thursday, February 19, 2009 2:21 PM
To: The elegant MVC web framework
Subject: RE: [Catalyst] RFC: The paradox of choice in web

development

Post by Matt Pitts
I myself am currently trying to support multiple developers

(content

Post by Matt Pitts
perl) working on a Catalyst app from Windows desktops and it's been

<snip>

Getting _way_ off-topic, but if your target environment is Linux,
this
is
insane. VMWare is easy to set up and would let your Windows

developer

run
the app in something much closer to its target environment.

Thanks for the input...
VMs were considered as an option, but since the Windows folks aren't
Linux-savvy, this means even more systems I have to maintain, perl CPAN,
updates, etc.

Where are you finding perl programmers from who can't use ubuntu?

We're not, 2 of the devs are content guys who also work on M$ projects
(.NET). I don't expect them to learn Ubuntu nor do I want to further
confuse their day-to-day work effort by making them boot a VM and learn
basic Linux skills in order to work on this one client (yes, we only
have one Perl/Catalyst client right now). Maybe I'm being too nice.

The other dev (besides me) also works on M$ projects as a coder and has
become our Perl newbie - she volunteered to learn Perl/Catalyst and
become my backup. The Perl newbie is open to whatever method I want to
use for her to run the app, but the content devs would have a tough go
with VMs and I don't want to support more than one type of DEV
environment.

Also, how does having people building software for a platform they're
unfamiliar with work for you?

Because we're a small outfit and we're trying to stay lean due to the
current economy. Hiring any more full-up Perl devs is not an option.
Yes, it's a risk, but it's one we're probably just going to live with.

Besides, part of the appeal of Catalyst (and web frameworks in general)
is that they abstract away the low-level details, so for my perl newbie
I don't consider her role "Linux dev", I consider it "Perl/Catalyst
dev". Maybe that will change once she feels more comfortable with
Perl/Catalyst, but for now, she's helping to offload some of my work and
it makes a big difference. I actually have time to participate in the
mailing list now :-).

Post by Matt Pitts
Not to mention the system resources used by the VM which
could be quite taxing on some of our developers' systems. For me,

this

Post by Matt Pitts
was the insane option.

Agreed and if I really wanted to run VMs I'm confident that the $boss
would approve any performance upgrades necessary for users' machines. As
for (b), I have been very impressed with Catalyst's cross-platform
consistency. After 2 years of production (SLES10 on x86_64), I've never
once had a bug related to actual app code (not performance or server
config related) that I couldn't duplicate in DEV (either cgywin or
Ubuntu x86).

This cost cannot be trivial even with the simple factors, and even
higher once you factor less easy to analyze things such as the
additional risk of your software having had less testing an the
correct environment, and the staff motiviation as developing your
application sounds painful.
How many days of lost time/work is the cost of a reasonable
workstation? 2, 3? Less than a week certainly..
The highest cost to a knowledge based organisation is human
resources, and so not providing your people the right kit to do their
jobs effectively is just cutting your own throat.

Agreed. Agreed. Agreed.

Because the content devs have a set of tools they like to use and are
most productive in - and they run in Windows.

I'd recommend having a 'standard' development vmware rig which people
can download, use, trash (and delete / get another one when they
trash) isn't any more effort to setup than 1 new machine +
development environment.

If I decide to go with VMs, this will likely be the route I take, but
I'd _prefer_ to just be able to run the app native in Windows - this
goes back to my original statements about Windows, Linux and Perl. It's
not a request, or a complaint; it's just a desire and if I get
determined enough I'll probably get it working one day.

Keeping it up to date after that is again keeping 1 machine up to date.
Don't worry about the individual workstations, they're disposable
(and developers should be able to say sudo apt-get upgrade or
equivalent).. Again, if you _can't_ get your development environment
down to this level of isolation, then something is horribly, horribly
wrong somewhere..

Post by Matt Pitts
Anyway, this is a long story, I'll stop ranting. My point was just that
there is no easy way to "just run" the Cat app in Windows.

I do feel your pain, but I think that's down to the modules you're
using in your application, rather than Catalyst itself (which as many
people will attest, installs and runs fine on windows).

Agreed. The original point I was trying to make was just that Catalyst,
because of Perl and CPAN dependencies, is less likely to be adopted as a
platform by many companies because it's not as inherently easy to
install and run in Windows as it is in *nix platforms. It wasn't a
statement _against_ Perl or Catalyst is was _just_ a statement.

Thanks for your thoughts on this t0m.

v/r
-matt pitts

Jonathan Rockway

2009-02-18 01:21:45 UTC

Post by Ali M.
The community will benefit from more bloggers and success stories ....

Actually, the community will probably benefit most from writing code.
Talking about talking about something doesn't actually buy you much.
New modules that make programming easier are definitely more appealing
all around.

It's also important to keep in mind that 99% of people that read social
news sites (like Programming Reddit) are idiots that only read things
they agree with. Wasting your time trying to "educate" these folks is
just going to make you very, very bitter.

I'm not bitter... not at all...

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

Kirby Krueger

2009-02-18 01:40:03 UTC

Post by Ali M.
The community will benefit from more bloggers and success
stories ....

Well, yes and no. Not everyone has the same skillset. Some people
you want spending time working on the code and please don't use your
special brand of 'help' on new people. Other people have excellent
communication skills, and may not necessarily be at the level of coder
you want making best-practices tools for others (but Catalyst helps
them write their own stuff that still works, even if they've still got
a few lumps to take as a coder.)

Post by Jonathan Rockway
It's also important to keep in mind that 99% of people that read social
news sites (like Programming Reddit) are idiots that only read things
they agree with. Wasting your time trying to "educate" these folks is
just going to make you very, very bitter.

There's a lot of truth to this. There's a reason that programming
language discussions in the wild Internet are so personal - because
they are. I've invested a lot of time becoming a perl expert, not a
java expert, and so I do care that most of the semi-technical people
out there incorrectly think that java is a better language - it means
less job postings, so less likelihood I'll be able to end up with
something where I like the work and salary. But since these things
are so personal and high stakes, they're deeply unpleasant to
participate in and not winnable. Never post in the comments of a
programming language discussion on Slashdot - it's just unpleasant.

On the other hand, there are less hostile forums, and they do matter.
Not that long ago, I was starting up a major web project and needed to
pick a platform to start with. I chose Catalyst for several reasons.
This active mailing list is a big one, the existence of your book was
another. Being able to work through the example in a few days gave me
a lot of confidence that I could work with the framework. Seeing
Catalyst mentioned in talks at the Open Source conference, seeing it
mentioned in blog posts, it helps the person choosing to think, "This
is the project that's actively improving and I won't regret sticking
with in six months." As opposed to, for instance, Solstice - the
mailing list is almost dead, there's very little that turns up on a
web search for help, no basic 'make a sample app in a day!' document,
no buzz.

It's obviously much more important that Catalyst works well, is
extensible, and has good support, but that sort of thing is very hard
to actually see when you're buzzing by options if people aren't
talking about them. I think Catalyst's primary market right now is
experienced perl developers that have built frameworks from scratch
and don't want to do it again, and it's emitting decent pollen to
attract those. It doesn't do much for the new developer looking for
an easy way to make a dynamic web site - Ruby on Rails is winning
that. And maybe everyone is happier that way?

I guess, my point is don't utterly give up on the idea of benefits for
talking about things. Avoid the trolly parts of the Internet, target
places where perl is already the cultural norm, but it does matter
that we've attracted a lot of bright minds to this project, and
they're telling people about it.

-- Kirby

Dan Dascalescu

2009-02-18 04:33:09 UTC

Post by Jonathan Rockway
Actually, the community will probably benefit most from writing code.
Talking about talking about something doesn't actually buy you much.
New modules that make programming easier are definitely more appealing
all around.

Well, yes and no. Not everyone has the same skillset. Some people you want
spending time working on the code [...] Other people have excellent
communication skills, and may not necessarily be at the level of coder
you want making best-practices tools for others

Exactly. As mst said [1],

"If you aren't good enough to write code, submit patches. If you
aren't good enough to submit patches, write documentation. If you
don't know enough about the project to write documentation, point out
what's missing from the documentation to make the project easy to
understand. Anyhow, CONTRIBUTE!"

[1] http://www.shadowcat.co.uk/archive/conference-video/yapc-eu-2008/you-arent-good-enough/

There's a reason that programming language
discussions in the wild Internet are so personal - because they are.

Paul Graham's last essay is exactly about this:
"Keep your identity small" - http://www.paulgraham.com/identity.html

I chose Catalyst for several reasons. This active
mailing list is a big one, the existence of your book was another. [...]
Seeing Catalyst mentioned in talks at
the Open Source conference, seeing it mentioned in blog posts

Spot on, again. When someone language-agnostic makes a decision to use
a web framework, what can they do?
a) try building a sample project in a few different frameworks from
the ~130 out there
b) evaluate what's being *talked about* those frameworks.

People in the a) group are extremely few, and never get far. Take
http://chrislaco.com/articles/ as an example. And of course they don't
get far in objectively evaluating a bunch of frameworks:
- it takes time to learn enough about each framework to know that you
haven't disqualified it due to your own ignorance
- it takes effort to actually build your sample project and iron out the kinks
- once you pick 1 out of N frameworks, most of the knowledge learned
about the other N-1 ones will soon become useless
- sample projects may have little to do with how a framework would
handle real-world complexities and scenarios.

If this isn't a good example of analysis paralysis or the paradox of
choice, I don't know what is.

What will therefore someone who wants to pick a framework most likely do? b).

I guess, my point is don't utterly give up on the idea of benefits for
talking about things.

I hope I reinforced that.

Dan

Dan Dascalescu

2009-02-15 15:04:08 UTC

First: Perl jobs are not decreasing. While there is not a ton of 'Buzz'
http://tiny.cc/kkcCM
Perl is above all the others by some margin.

Short version: that graph is misleading. Click the "Relative" link.

Longer version: Yes, Perl is above the rest by some margin, thanks to its
history. There are existing Perl applications that need to be maintained,
and some momentum that keeps the demand for Perl jobs going. But click the
"Relative" link in the graph, and see the percentage growth for Ruby jobs.
It skyrockets when compared with both PHP and Perl.

There are two problems I see, really. One problem I think David points out
correctly... there is precious little 'easily accessible' means to learn
about catalyst and what the conventional 'preferred' pieces are... so those
that learn it are those that really need it's power, and have come searching
for it. Those that are just trying to pick something and go will piss off
to some more spoonfeed-easy-to-learn framework.
I'm not convinced that's a bad thing. The second problem I see is that we
don't seem to know who we want to market Catalyst to. We look over and see
Rails and Django getting a lot of press and raves and such, and think 'I
want to go to there.'
Overall, though, I think that most of us who have used Catalyst for any
period of time know that it is not a beginners platform. It is a powerful
set of tools to solve difficult and complex problems.
I think we need to take a page out of the old Unix'ers handbook. Stop
looking to be as accessible to newbies as the other options, and embrace our
true position... which is simply Catalyst is better. Not because it's
easier to learn, and certainly not because it forces you into one (easy or
not) way of doing things.... but because you can bend it to whatever form
you need to solve whatever problem you have, even the ones that are less
computer science-y and more computer-room-in-the-office-y. (though we can
certainly do the former as well)
When someone says 'well, Why isn't catalyst as
clear-cut and simple to use like Rails?' we should encourage them... tell
them 'Go... Go play with rails... and when you grow out of it, we'll be
waiting for you.'

After someone makes the decision to learn Rails (at the expense of
Catalyst - this is important), and the investment to keep learning,
then build a web application, and maintain it for a year or two, what
happens if they run into issues? They'll ask for support. And they'll
find a way to solve the problem. It may be an ugly solution, but in
the vast majority of cases, the issues will not be serious enough to
warrant ditching Rails, picking up Catalyst, learning its quirks, then
rewriting the web application from scratch in a framework they won't
be nearly as familiar with.

In other words, I estimate the deconversion rate from almost any web
framework to Catalyst to be very low. When that happens, it will most
likely be in the form of the same developer taking on a new project,
but the old app won't be rewritten.

We should position Catalyst as the big-sister framework, the one whose there
for you when you are ready to take on big problems that can't be solved by a
bit of automatic CRUD, the ones that can't be stuffed into the channels that
someone else has already dug. We should communicate an attitude of 'yes,
we can solve easy problems too, but we are particularly good at solving the
harder ones.'
The fact is that Oracle does not try to compete for the low end of the
market with MySQL. They don't want it. They never did. Why do we?

I think I can agree with that. What I'm saying is that there's simply
too much useless choice. Random example:

Data::Dumper
vs.
Data::Dump.

I've just discovered Data::Dump but it appears to beat the crap out of
Data::Dumper. Yet does it say anywhere "Hey, if you're getting started
with Perl and need to dump variables, use Data::Dump, and don't waste
your time investigating other modules"? If I were the author of
Data::Dumper, I'd somehow retire the module, or plaster a note in the
POD redirecting people to Data::Dump. Imagine a programmer new to Perl
picks up an example that uses Data::Dumper. Will they find out about
Data::Dump? No. Someone picks up the Catbook and learns about
FormBuilder. Does http://www.formbuilder.org/ mention FormFu anywhere?
No. It mentions its last update, March 2007.

Positive feedback (does it count as "feedback" if it's from the
author? :) idea #1: module conflation. Kinda hard to do because people
tend to feel strongly for their pet projects even when there are
clearly better alternatives.

The list goes on. As Octavian noted, the wheel is reinvented and
solutions are forked off all the time. Mojolicious - yet another Perl
web framework. I remember wasting a few hours looking into it a while
ago, trying to figure out how it's different from Catalyst and if
there are grounds to reconsider my choice of a Perl web framework.

Is there some sort of comparison matrix of Perl solutions, like
http://wikimatrix.org? Not really. There's CPAN ratings, but that's
very rudimentary and very few bother to use it.

Positive feedback idea #2: Use CPAN ratings.

And this is ideas #3, that could really reduce the amount of choice:
it should be WAY easier to make an informed choice. Imagine you're
looking for a wiki software. Go to
http://www.wikimatrix.org/wizard.php. Brilliant.

Dan

Andrew Rodland

2009-02-15 15:34:03 UTC

First: Perl jobs are not decreasing. While there is not a ton of 'Buzz'
http://tiny.cc/kkcCM
Perl is above all the others by some margin.

Short version: that graph is misleading. Click the "Relative" link.
Longer version: Yes, Perl is above the rest by some margin, thanks to its
history. There are existing Perl applications that need to be maintained,
and some momentum that keeps the demand for Perl jobs going. But click the
"Relative" link in the graph, and see the percentage growth for Ruby jobs.
It skyrockets when compared with both PHP and Perl.

Of course it does. Look at the "absolute" graph. The 2005 figure for Ruby is,
to within the resolution of the graph, zero. It's not hard to have ten
thousand percent growth from zero! The absolute graph would have you believe
that the huge "threat" is from Ruby which has gone from zero to perhaps a
quarter as big as perl, while the absolute graph makes it clear that the
real "competition" is from the black line representing PHP. And yet if
everyone were to abandon PHP tomorrow in favor of Perl it *still* wouldn't
make a blip on the relative graph. Why? Because the relative graph is
braindead.

Andrew

Octavian Râşniţă

2009-02-15 17:29:08 UTC

Post by Dan Dascalescu
I've just discovered Data::Dump but it appears to beat the crap out of
Data::Dumper. Yet does it say anywhere "Hey, if you're getting started
with Perl and need to dump variables, use Data::Dump, and don't waste
your time investigating other modules"? If I were the author of
Data::Dumper, I'd somehow retire the module, or plaster a note in the
POD redirecting people to Data::Dump. Imagine a programmer new to Perl
picks up an example that uses Data::Dumper. Will they find out about
Data::Dump? No. Someone picks up the Catbook and learns about
FormBuilder. Does http://www.formbuilder.org/ mention FormFu anywhere?
No. It mentions its last update, March 2007.

I also agree, but unfortunately I don't know what should be the solution for
this kind of problems.

One of the biggest issues for the perl programmers, Catalyst users or not,
is to choose the right module for sending email, because I guess there are
tens of modules for this task.

And to increase the confusion, I have also added one more
(Mail::Builder::Simple) and a helper for Catalyst
(Catalyst::Helper::Model::Email) that helps using it in a Catalyst app.

This is because I wanted to have a perl module that can send email which
automaticly encodes the body and headers to UTF-8, in order to be able to
include special chars in them, to be able to add attachments, inline images,
to create a multipart with a text and html version without needing to create
those parts manually, to be able to create the body of the message and the
attachments by using templates, and I couldn't find a perl module that can
do this.

So a Catalyst beginner will hear that he can send email from Catalyst by
using a View, then he will find that he can also send email by using a
model, and after a few experiences like these, he won't be sure that he uses
the "right tool".

I would be very glad to hear that there is a better module for sending email
than the one I wrote, that would be higher level, that would require less
code, that would be able to send email using more types of servers, and when
I'd find it, I would surely specify in the POD documentation of that module
that I recommend the other, and I will surely start using it myself.

Octavian

Dermot

2009-02-15 18:44:35 UTC

Post by Dan Dascalescu
I think I can agree with that. What I'm saying is that there's simply
Data::Dumper
vs.
Data::Dump.

I imagine there is some kudos in getting a module on CPAN hence there
is a lot of overlap. Rather that developers extending or maintaining
existing module, there may be a number of reasons for starting from
scratch, original maintainer has moved on, new libraries become
available, or they simply did not like the way the first worked.

In this case Dumper is a core module which opens another issue, on
what basis do you decide if a module should be core at the expense of
another or worse still, have 2 modules that achieve the sames ends
which would be taking TIMTOWTDI to the extreme.
Dp.

Ashley

2009-02-16 02:20:56 UTC

First: Perl jobs are not decreasing. While there is not a ton of 'Buzz'
http://tiny.cc/kkcCM
Perl is above all the others by some margin.

Short version: that graph is misleading. Click the "Relative" link.

You had some great points below this but I think this one isn't.
The relative graph is the misleading one and something so put
in print and in conversations with tech managers. The relative
graph makes it look like there are tons of RoR jobs. There
aren't. Job seekers who need a job now outweigh those that like
to gamble on trends and getting hired in the future. A lot of
devs, most(?), today are not CS guys. It's not just the kit
they'd be investing in but the language. It's not Cat or RoR,
it's Perl or Ruby. Perl is simply a better choice for tech work
if you're only able to handle one and I personally don't
see that changing for a long time.

Maybe more important than a user case is a dev case. I've been
brought into two projects to do Catalyst and the big concern in
both was that there weren't enough developers who knew the
framework.

And while others have made good points there were many that
weren't so hot. Using a big company as an example of a place
that picks the best is ridiculous; their size and bureaucracy
often mean they can't. When I was at Amazon I watched
them burn millions of dollars on dead end projects because
they picked the wrong tool for the job. They picked Java
to create a highly agile customer service tool. It was an
unmitigated disaster that was abandoned for a Perl rewrite
18 months after it was still too slow, too buggy, and
incomplete. It's my understanding, though I wasn't there
for this one, that they did a project with Ruby to do
employee reviews where the whole thing was ditched for
the legacy version the day it was to go live because it
didn't work outside the dev env. There's some good FUD:
Java and Ruby lead the failure of Amazon.com projects
and the loss of millions of dollars.

I liked everything Jay said about it. My own 2? would be
that we should each take as much time to make Cat
developer-friendly (docs, examples, blog posts) as we
can; and some of you are doing a great job at this already.
We have a great kit, a great community, and the more obvious
and accessible it is, the more we ensure continued success.

-Ashley

Octavian Râsnita

2009-02-16 03:06:44 UTC

Post by Ashley
And while others have made good points there were many that
weren't so hot. Using a big company as an example of a place
that picks the best is ridiculous; their size and bureaucracy
often mean they can't. When I was at Amazon I watched
them burn millions of dollars on dead end projects

It might not be a good example for developers, but it surely is a good
example for the managers.

All the managers want to use the same tools used by the important companies,
because they can trust the big companies much more than the smaller and
unknown ones, and if they would hear that Google uses Catalyst, Ebay uses
Catalyst, Amazon uses Catalyst, and successfully, they will trust Catalyst
more.

Octavian

Ashley

2009-02-16 03:14:49 UTC

Post by Octavian RÃ¢snita
It might not be a good example for developers, but it surely is a
good example for the managers.
All the managers want to use the same tools used by the important
companies, because they can trust the big companies much more than
the smaller and unknown ones, and if they would hear that Google
uses Catalyst, Ebay uses Catalyst, Amazon uses Catalyst, and
successfully, they will trust Catalyst more.

I know what you're saying and it's not without marketing merit but I
argue it's only a good example for bad managers. A manager at a mid-
sized or small company knows he/she cannot waste 10s of millions of
dollars without tanking the company. Big companies can make huge
mistakes, some of them do for years and years, and still clammer
along through stored fat, sheer cash flow volume, 50-60 hour weeks
over entire salaried departments, dropping permanent employees in
favor of permatemps, etc. Good managers at this level are the sorts
who are either on this list right now or have a dev or two on it for
them. So I say. :)

-Ashley

Octavian Rasnita

2009-02-16 13:49:39 UTC

Post by Ashley
I know what you're saying and it's not without marketing merit but I
argue it's only a good example for bad managers. A manager at a mid-
sized or small company knows he/she cannot waste 10s of millions of
dollars without tanking the company. Big companies can make huge
mistakes, some of them do for years and years, and still clammer
along through stored fat, sheer cash flow volume, 50-60 hour weeks
over entire salaried departments, dropping permanent employees in
favor of permatemps, etc. Good managers at this level are the sorts
who are either on this list right now or have a dev or two on it for
them. So I say. :)

Of course you are right, but it seems that you consider good managers only those that either have IT knowledge, or either delegate the responsability of deciding what to choose in this field to those who know. I also think that, but unfortunately there are incredibly many cases where the managers decide beeing based only on their own knowledge, and that knowledge in the IT field may come from media, from what they know from other managers, and not from what they studied.

With other words, we should try to beat them with their own arms.

Octavian

Zbigniew Lukasiak

2009-02-16 16:19:32 UTC

On Sun, Feb 15, 2009 at 10:04 AM, Dan Dascalescu

Post by Dan Dascalescu
I think I can agree with that. What I'm saying is that there's simply
Data::Dumper
vs.
Data::Dump.
I've just discovered Data::Dump but it appears to beat the crap out of
Data::Dumper. Yet does it say anywhere "Hey, if you're getting started
with Perl and need to dump variables, use Data::Dump, and don't waste
your time investigating other modules"? If I were the author of
Data::Dumper, I'd somehow retire the module, or plaster a note in the
POD redirecting people to Data::Dump. Imagine a programmer new to Perl
picks up an example that uses Data::Dumper. Will they find out about
Data::Dump? No.

There is also:

http://search.cpan.org/~jmcnamara/Data-Dumper-Perltidy-0.01/lib/Data/Dumper/Perltidy.pm

And frankly I think this naming convention is the way to go - this is
much better findable than Data::Dump. And there is also
Data::Dumper::HTML, that just recently I found very useful for
debugging in web context.

And to complicate the things - I cannot say for sure that this is the
reason, but it is quite probable that Data::Dumper would have much
better interface now if it was not in the Core. Modules that get into
the Core generally get frozen and stop evolving because too many
things rely on them. This is a complex matter and I lean towards the
'steady release cycles plus rigorous deprecating' proposed by
chromatic in his recent Modern Perl blog notes
(http://www.modernperlbooks.com/mt/).

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

Kevin Monceaux

2009-02-15 08:58:05 UTC

Catalyst Fans,

Post by David Steiner
i added my comments to the article, suggesting that we step up on the
documentation and marketing! we need to give the layperson a easier ride in
starting out with catalyst. and that requires more tutorials/screencasts,
better official documentation, and more books being written. tell me what you
people think of the article and how we can get catalyst more used and known.

As a newbie I can certainly agree that all of the above suggestions
regarding documentation/books/tutorials/screencasts would be good things.
I have a couple of sites I'm considering switching to Catalyst, one of
which is currently Django based and still running running version 0.97.
I haven't really been keeping up with Django lately and have hardly looked
at the 1.x branch yet. I keep trying to develop a fondness for Python,
but it hasn't happened yet. But, a recent Django documentation discovery
has me considering trying harder to love Python. A couple of days ago I
discovered that with the documentation sources included in the Django
source tarball one can generate documentation in a variety of formats,
including pdf. Projects with pdf documentation always score extra points
with me. It would be better if the pdf manual was available on the Django
site, but being able to generate it from sources is still a plus in
Django's favor. Even if viewing on screen, I like documentation that at
least looks like a book. And, I frequently print out bits of
documentation to read in bed. I generated the available pdf Django docs
and ended up with a 748 page manual!!! And, from a quick search on Amazon
it appears half a dozen up-to-date Django books have come out in the last
few months. I'm impressed with the available Django docs.

Kevin
http://www.RawFedDogs.net
http://www.WacoAgilityGroup.org
Bruceville, TX

Si hoc legere scis nimium eruditionis habes.
Longum iter est per praecepta, breve et efficax per exempla!!!

Kieren Diment

2009-02-15 09:50:54 UTC

Post by Kevin Monceaux
Catalyst Fans,

Post by David Steiner
i added my comments to the article, suggesting that we step up on the
documentation and marketing! we need to give the layperson a easier ride in
starting out with catalyst. and that requires more tutorials/
screencasts,
better official documentation, and more books being written. tell me what you
people think of the article and how we can get catalyst more used and known.

As a newbie I can certainly agree that all of the above suggestions
regarding documentation/books/tutorials/screencasts would be good
things. I have a couple of sites I'm considering switching to
Catalyst, one of which is currently Django based and still running
running version 0.97. I haven't really been keeping up with Django
lately and have hardly looked at the 1.x branch yet. I keep trying
to develop a fondness for Python, but it hasn't happened yet. But,
a recent Django documentation discovery has me considering trying
harder to love Python. A couple of days ago I discovered that with
the documentation sources included in the Django source tarball one
can generate documentation in a variety of formats, including pdf.
Projects with pdf documentation always score extra points with me.
It would be better if the pdf manual was available on the Django
site, but being able to generate it from sources is still a plus in
Django's favor. Even if viewing on screen, I like documentation
that at least looks like a book. And, I frequently print out bits
of documentation to read in bed. I generated the available pdf
Django docs and ended up with a 748 page manual!!! And, from a
quick search on Amazon it appears half a dozen up-to-date Django
books have come out in the last few months. I'm impressed with the
available Django docs.

Hmm,

quick and dirty but apparently it works: I'm doing it from an svk
checkout, but I suppose it would be even simpler if you did it in the
right bit of @INC:

find Catalyst-Runtime/5.80/trunk/lib/ Catalyst-Manual/5.70/trunk/lib/ -
name '*' > /tmp/files

# change the order of stuff in /tmp/files around here if you want.

for i in `cat /tmp/files`; do perldoc -T -u $i >> /tmp/catpod.pod ;
done;

cd /tmp/

pod2latex -full -out catpod.tex catpod.pod

pdflatex catpod.tex

and there you go, a pdf of all 363 pages of the catalyst docs.

(actually this is a similar process to what we're doing to make the
first drafts of the catalyst book (err with our own original material,
not the catalyst project pod). Unfortunately for us, the publisher's
workflow eventually requires that we use file format compatible with a
word processor we will not name?)

Oh if you want super brownie points, go and learn haskell, and provide
a pod translator for pandoc (http://johnmacfarlane.net/pandoc). Or
even better an equivalent arbitrary-markup-language parser written in
perl.

Kevin Monceaux

2009-02-16 20:09:13 UTC

Post by Kieren Diment
and there you go, a pdf of all 363 pages of the catalyst docs.

Well, that's a start. I think it would need some polishing to compete
with the available Django docs. For easier comparison I've tossed a copy
of the Django pdf manual up on my site:

http://www.RawFedDogs.net/DjangoManual.pdf

Kevin
http://www.RawFedDogs.net
http://www.WacoAgilityGroup.org
Bruceville, TX

Si hoc legere scis nimium eruditionis habes.
Longum iter est per praecepta, breve et efficax per exempla!!!

bill hauck

2009-02-18 09:59:53 UTC

My experience ...

I'm trying to put together a project to rewrite a job tracking database currently running in FileMaker. The functionality and scope of the job tracking system has changed so instead of throwing more money in a proprietary, closed system that requires a costly application on each desktop I'm suggesting writing it as a web application with Perl & Catalyst. The only problem is that I've been told we would have to use Java & Struts since it's our "corporate standard" for web applications. Perl, ironically, is used in quite a few places in the company, mainly in utility scripts. However, since we don't have anyone whose job title is "Perl developer" we can't use it for web applications.

Regards,

bill

Dave Rolsky

2009-02-18 12:55:49 UTC

Post by bill hauck
I'm trying to put together a project to rewrite a job tracking database
currently running in FileMaker. The functionality and scope of the job
tracking system has changed so instead of throwing more money in a
proprietary, closed system that requires a costly application on each
desktop I'm suggesting writing it as a web application with Perl &
Catalyst. The only problem is that I've been told we would have to use
Java & Struts since it's our "corporate standard" for web applications.
Perl, ironically, is used in quite a few places in the company, mainly
in utility scripts. However, since we don't have anyone whose job title
is "Perl developer" we can't use it for web applications.

This is hardly unreasonable.

I've worked at a number of smaller shops where we were developing a
Perl-based app. If a developer had decided that they wanted to throw
together some important tool in Java (or Python or Haskell or Smalltalk or
...), that would have been problem.

The investment in a language is bigger than just the programmers, even.
You have build & deployment tools, automated testing setups (you do, don't
you? ;), sysadmin knowledge, packaging infrastructure, and so on.

Some of that may be language-agnostic, but often a lot of it ties into the
language and its tools.

Once you've made that investment, it makes sense to stick with it. Just
because Catalyst and Perl are great tools for webapps doesn't mean that
they're the _right_ tool at your job.

-dave

/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/

Kieren Diment

2009-02-18 13:41:58 UTC

Post by Dave Rolsky

Post by bill hauck
I'm trying to put together a project to rewrite a job tracking
database currently running in FileMaker. The functionality and
scope of the job tracking system has changed so instead of throwing
more money in a proprietary, closed system that requires a costly
application on each desktop I'm suggesting writing it as a web
application with Perl & Catalyst. The only problem is that I've
been told we would have to use Java & Struts since it's our
"corporate standard" for web applications. Perl, ironically, is
used in quite a few places in the company, mainly in utility
scripts. However, since we don't have anyone whose job title is
"Perl developer" we can't use it for web applications.

This is hardly unreasonable.
I've worked at a number of smaller shops where we were developing a
Perl-based app. If a developer had decided that they wanted to throw
together some important tool in Java (or Python or Haskell or
Smalltalk or ...), that would have been problem.
The investment in a language is bigger than just the programmers,
even. You have build & deployment tools, automated testing setups
(you do, don't you? ;), sysadmin knowledge, packaging
infrastructure, and so on.
Some of that may be language-agnostic, but often a lot of it ties
into the language and its tools.
Once you've made that investment, it makes sense to stick with it.
Just because Catalyst and Perl are great tools for webapps doesn't
mean that they're the _right_ tool at your job.

Yes indeed. To balance that, management also need to work with the
idea that rules are not dogmatic but designed for practical purpose.
In my (academic - research and practical) experience, the larger the
organisation, the more likely they are to believe dogma is more
important than pragmatism, especially if you go through the official
IT channels. If you go through the unofficial channels this may
change, depending on the structure of the organisation, and the
quality of your unofficial channels.

Stuart Watt

2009-02-18 20:58:46 UTC

I've actually done the reverse switch. Although I was a Perl developer =

for a good while, I previously used Apache::ASP and real ASP on Windows, =

with raw DBI and a hand-crafted search engine for most of this time. I =

then had to pick up Java and Spring with Hibernate for a while, for a =

second project. Since I started on my current task, which involved a =

large legacy code base in Perl, taking up Catalyst with DBIx::Class has =

been a great experience, as I get all the concepts from Spring and =

Hibernate with the development simplicity and CPAN assistance of Perl. =

Also, many of my colleagues have basic Perl, mostly pre-OO scripty =

style. Some of it is truly awful code!! Even they are beginning to see =

the flexibility that Catalyst has started to add into the development.

We're now trying to recruit additional staff, and as Catalyst is a rare =

(and pricey) skill, we're also looking at Java folks, ideally with some =

knowledge of Spring and Hibernate, as a good base to move into Catalyst.

There are still a few things I miss from Spring - notably the =

flexibility of its dependency injection for configuration. Configuration =

in Catalyst was actually far the hardest issue for me, and I still find =

it a little awkward. We began with YAMLs, and I still regret this from =

time to time. But this was an area where the examples were less detailed =

than helped the transition for me. Also, we found some highly =

inexplicable errors -- largely where Module::Pluggable loads everything =

in @INC, even when it is not where you expected. (PERL5LIB had been set =

to an old site, and loaded old components with different names.) For me, =

configuration is an area where the multiple alternatives really is a =

problem for Catalyst. My colleagues (and our clients) struggle with =

YAMLs. I'd rather one strongly preferred syntax was clearly set (and =

documented with detailed examples), although with an API that allows =

code to be used, through which others can be used for legacy apps.

All the best
Stuart

Post by Dave Rolsky

I'm trying to put together a project to rewrite a job tracking =
database currently running in FileMaker. The functionality and scope =
of the job tracking system has changed so instead of throwing more =
money in a proprietary, closed system that requires a costly =
application on each desktop I'm suggesting writing it as a web =
application with Perl & Catalyst. The only problem is that I've been =
told we would have to use Java & Struts since it's our "corporate =
standard" for web applications. Perl, ironically, is used in quite a =
few places in the company, mainly in utility scripts. However, since =
we don't have anyone whose job title is "Perl developer" we can't use =
it for web applications.

This is hardly unreasonable.
I've worked at a number of smaller shops where we were developing a =
Perl-based app. If a developer had decided that they wanted to throw =
together some important tool in Java (or Python or Haskell or =
Smalltalk or ...), that would have been problem.
The investment in a language is bigger than just the programmers, =
even. You have build & deployment tools, automated testing setups (you =
do, don't you? ;), sysadmin knowledge, packaging infrastructure, and =
so on.
Some of that may be language-agnostic, but often a lot of it ties into =
the language and its tools.
Once you've made that investment, it makes sense to stick with it. =
Just because Catalyst and Perl are great tools for webapps doesn't =
mean that they're the _right_ tool at your job.
-dave
/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Post by Dave Rolsky
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/

-- =

Stuart Watt
ARM Product Developer
Information Balance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090218/67c4e=
956/attachment.htm

bill hauck

2009-02-19 07:47:28 UTC

Subject: Re: [Catalyst] RFC: The paradox of choice in web development
Date: Wednesday, February 18, 2009, 7:41 AM

Post by Dave Rolsky
This is hardly unreasonable.
I've worked at a number of smaller shops where we

were developing a Perl-based app. If a developer had decided
that they wanted to throw together some important tool in
Java (or Python or Haskell or Smalltalk or ...), that would
have been problem.

Post by Dave Rolsky
The investment in a language is bigger than just the

programmers, even. You have build & deployment tools,
automated testing setups (you do, don't you? ;),
sysadmin knowledge, packaging infrastructure, and so on.

Post by Dave Rolsky
Some of that may be language-agnostic, but often a lot

of it ties into the language and its tools.

Post by Dave Rolsky
Once you've made that investment, it makes sense

to stick with it. Just because Catalyst and Perl are great
tools for webapps doesn't mean that they're the
_right_ tool at your job.
Yes indeed. To balance that, management also need to work
with the idea that rules are not dogmatic but designed for
practical purpose. In my (academic - research and
practical) experience, the larger the organisation, the more
likely they are to believe dogma is more important than
pragmatism, especially if you go through the official IT
channels. If you go through the unofficial channels this
may change, depending on the structure of the organisation,
and the quality of your unofficial channels.

No, I totally understand that. If the company is using Java, PHP, Python, etc. then the other projects should use the same language if possible.

Um, if by "automated testing" you mean sending an email to the crew and saying, "Ok, give it a try ..." then, yeah, we've got automated testing.

However, we don't really have Java developers for this project. Sure, the company has lots of Java developers but none that are funded by us (corporate communications) and available. We don't really have any funding for the project, either, so a contractor is out as well. I proposed that we write the application in Perl using Catalyst since I know Perl pretty well and my system administrator needs to learn it since many utilities have been / will be written in Perl. I guess I could learn Java, Servlets, and JSPs, but it'll take me a lot longer to write than in Perl. And it'll be a whole lot less fun.

Cheers

bill

Dermot

2009-02-19 08:12:02 UTC

2009/2/19
* Template::Toolkit
* Text::Template
* Text::FastTemplate
* Text::Templar
* HTML::Template
* HTML::KTemplate
* HTML::Mason
* HTML::Seamstress
* dTemplate
* Jemplate

Yes there is, at first glance, a lot of choice but is there. I would
say TT and Mason are the only realistic choices (for HTML). And ONE of
the reasons why is because they have both been published and by the
patron of Perl, O'Reilly. Unless your being published by O'Reilly (or
Addison) your not hitting the right audience.

There is lot's of choice out there but you don't have to dig very far
to find out what "best" is.
Dp.

Dan Dascalescu

2009-02-19 10:36:04 UTC

A discussion on slashdot called "Twitter Leads Social Networks In
Downtime" made me post a link to an interview with Twitter developer
Alex Payne, in which he describes the problems he encountered with
Rails:
http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/

One of the answers to that interview made a very good point:
http://slashdot.org/comments.pl?sid=1132589&cid=26906541

---8<---

All the convenience methods and syntactical sugar that makes Rails such
a pleasure for coders ends up being absolutely punishing, performance-wise.

It's also worth mentioning that while all of the Twitter alternatives
may have enjoyed better uptime, they haven't had nearly the amount of
traffic that Twitter does. We don't really know if they can scale --
but even supposing they can, Twitter was there first. And while they
complain about those nice features being slow, they probably owe their
success to those features for getting their product out the door
faster than their competitors.
-->8---

Dan

Jonathan Rockway

2009-02-19 20:51:42 UTC

Post by Dermot
Yes there is, at first glance, a lot of choice but is there. I would
say TT and Mason are the only realistic choices (for HTML).

If by "realistic" you mean "unmaintainable for both designers and
developers", then yes, you've described Mason and TT.

The only qualities that Mason and TT have over other options is that
they have been around for a while.

Post by Dermot
And ONE of the reasons why is because they have both been published
and by the patron of Perl, O'Reilly. Unless your being published by
O'Reilly (or Addison) your not hitting the right audience.

LOL. Just so you know, O'Reilly recently fired pretty much everyone
Perl-related. Perl.com is basically dead, and they probably won't be
publishing any more Perl books. That, IMHO, is not particularly
supportive of Perl.

Post by Dermot
There is lot's of choice out there but you don't have to dig very far
to find out what "best" is.

The key to finding the "best" is not by doing what books tell you to.
It's by trying the various options, and seeing which one works best
according to your mental model of the problem you want to solve. I know
everyone wants easy answers and wants to avoid thinking... but if that's
you, you've chosen the wrong field.

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

Dermot

2009-02-19 21:09:48 UTC

Post by Dermot
Yes there is, at first glance, a lot of choice but is there. I would
say TT and Mason are the only realistic choices (for HTML).

Ohh that's painful to hear. Is the venerable Mr Wall still there?
That's going to hurt Perl.
Dp.

Aristotle Pagaltzis

2009-02-19 21:29:13 UTC

Post by Dermot
Ohh that's painful to hear. Is the venerable Mr Wall still
there? That's going to hurt Perl.

Eh? Larry has been off the O?Reilly payroll in a very long time.

Regards,

--
Aristotle Pagaltzis // <http://plasmasturm.org/>

Kieren Diment

2009-02-20 02:51:36 UTC

Post by Dermot
Yes there is, at first glance, a lot of choice but is there. I would
say TT and Mason are the only realistic choices (for HTML).

If by "realistic" you mean "unmaintainable for both designers and
developers", then yes, you've described Mason and TT.
The only qualities that Mason and TT have over other options is that
they have been around for a while.

LOL. Just so you know, O'Reilly recently fired pretty much everyone
Perl-related. Perl.com is basically dead, and they probably won't be
publishing any more Perl books.

Beyont the current trifecta of Learning, Intermediate and Programming
I doubt it, although PBP might get a 2nd edition too.

Devin Austin

2009-02-20 02:53:43 UTC

Post by Dermot
Yes there is, at first glance, a lot of choice but is there. I would
say TT and Mason are the only realistic choices (for HTML).

If by "realistic" you mean "unmaintainable for both designers and
developers", then yes, you've described Mason and TT.
The only qualities that Mason and TT have over other options is that
they have been around for a while.
And ONE of the reasons why is because they have both been published

Post by Dermot
and by the patron of Perl, O'Reilly. Unless your being published by
O'Reilly (or Addison) your not hitting the right audience.

LOL. Just so you know, O'Reilly recently fired pretty much everyone
Perl-related. Perl.com is basically dead, and they probably won't be
publishing any more Perl books.

Beyont the current trifecta of Learning, Intermediate and Programming I
doubt it, although PBP might get a 2nd edition too.
Electronic media is the future! Embrace or perish!

-- =

Devin Austin
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090219/321a9=
1da/attachment.htm

Byron Young

2009-02-20 04:29:50 UTC

Post by Dermot
Yes there is, at first glance, a lot of choice but is there. I would
say TT and Mason are the only realistic choices (for HTML).

If by "realistic" you mean "unmaintainable for both designers and
developers", then yes, you've described Mason and TT.
The only qualities that Mason and TT have over other options is that
they have been around for a while.

Jonathan,

Can I ask - what are the limitations with Mason (and TT) in your opinion? I have been using it as the templating language for my Cat app (seemed better than TT because I could exclude having to learn a new language for the templates - I can just keep writing perl code). It's been working well for me, in part because I've been striving to keep the template files short and organized.

What are some templating languages (either existing, in progress, or theoretical) that overcome the limitations you perceive with TT and Mason?

-Byron

Dermot

2009-02-20 17:06:28 UTC

Post by Byron Young

Post by Dermot
Yes there is, at first glance, a lot of choice but is there. I would
say TT and Mason are the only realistic choices (for HTML).

If by "realistic" you mean "unmaintainable for both designers and
developers", then yes, you've described Mason and TT.
The only qualities that Mason and TT have over other options is that
they have been around for a while.

TT is perl. It's not a different language. It's a bit of a learning
curve. It provides familiar methods* like keys, splice, exists and
substr.
I <*_*> TT
Dp.

* http://template-toolkit.org/docs/manual/VMethods.html

Aristotle Pagaltzis

2009-02-20 17:56:09 UTC

Post by Dermot
TT is perl. It's not a different language.

You?re joking, right?

Post by Dermot
It provides familiar methods* like keys, splice, exists and
substr.

By that argument, Javascript is Perl.

Regards,

--
Aristotle Pagaltzis // <http://plasmasturm.org/>

Dermot

2009-02-20 18:15:39 UTC

Post by Dermot
TT is perl. It's not a different language.

You're joking, right?

narff. Perhaps written in Perl.

Post by Dermot
It provides familiar methods* like keys, splice, exists and
substr.

By that argument, Javascript is Perl.

The point is the are familiar functions. There isn't nothing new in it.
Dp.

Byron Young

2009-02-21 03:06:25 UTC

Post by Dermot

Post by Dermot
TT is perl. It's not a different language.

You're joking, right?

narff. Perhaps written in Perl.

Post by Dermot
It provides familiar methods* like keys, splice, exists and
substr.

By that argument, Javascript is Perl.

The point is the are familiar functions. There isn't nothing new in it.
Dp.

Of course there's something new in it: it's different syntax that I have to remember. I'm already switching between perl and javascript and sql and pod, using TT just adds another syntax for me to potentially bungle. Not that it's a hard syntax to use, but why bother? I find using Mason makes the transition from coding a controller to coding a template pretty smooth.

-byron

Dan Dascalescu

2009-02-20 17:23:31 UTC

Post by Byron Young
What are some templating languages (either existing, in progress, or theoretical)
that overcome the limitations you perceive with TT and Mason?

Not speaking for Jonathan here, but I liked his blog post
http://blog.jrock.us/articles/Template::Refine.pod

HTH,
Dan

Byron Young

2009-02-21 03:13:18 UTC

Post by Byron Young
What are some templating languages (either existing, in progress, or
theoretical) that overcome the limitations you perceive with TT and
Mason?

Not speaking for Jonathan here, but I liked his blog post
http://blog.jrock.us/articles/Template::Refine.pod
HTH,
Dan

I just read the blog post - I like it! Very cool. Anybody using Template::Refine in a Cat app? I don't see a specific C::V::Template::Refine, but it seems like you could possibly use C::V::Template::Declare for it (or maybe I've misunderstood that module).

I misunderstood what Jonathan said earlier when he said

Post by Dan Dascalescu
If by "realistic" you mean "unmaintainable for both designers and
developers", then yes, you've described Mason and TT.

Ali M.

2009-02-22 21:42:25 UTC

I recommend you also take a look at
Template::Declare

I only saw a presentation about it from this presentation
http://www.slideshare.net/obrajesse/beijing-perl-workshop-2008-hiveminder-secret-sauce-presentation

looks pretty similar to Groovy builders.

Don't know how popular it is thought.

Post by Byron Young