RE: [Catalyst] RFC: The paradox of choice in web development
> -Original Message- > From: Tomas Doran [mailto:bobtf...@bobtfish.net] > 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 > > > On 19 Feb 2009, at 20:07, Matt Pitts wrote: > > >> -Original Message- > >> From: Dave Rolsky [mailto:auta...@urth.org] > >> 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 > >> > >> On Thu, 19 Feb 2009, Matt Pitts wrote: > >> > >>> I myself am currently trying to support multiple developers > (content > >> & > >>> perl) working on a Catalyst app from Windows desktops and it's been > > a > > >> 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 :-). > > 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. 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. > > 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 w
RE: RFC local::lib + CPAN shell support in CatalystX::Starter (was:Re: [Catalyst] RFC: The paradox of choice in web development)
> -Original Message-
> From: Tomas Doran [mailto:bobtf...@bobtfish.net]
> 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)
>
>
> On 19 Feb 2009, at 18:27, Matt Pitts wrote:
>
> > 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
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.
> > 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?
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.
> > 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 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 calli
Re: [Catalyst] RFC: The paradox of choice in web development
On 19 Feb 2009, at 20:07, Matt Pitts wrote: -Original Message- From: Dave Rolsky [mailto:auta...@urth.org] 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 On Thu, 19 Feb 2009, Matt Pitts wrote: I myself am currently trying to support multiple developers (content & perl) working on a Catalyst app from Windows desktops and it's been a 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? Also, how does having people building software for a platform they're unfamiliar with work for you? 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. 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.. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: RFC local::lib + CPAN shell support in CatalystX::Starter (was: Re: [Catalyst] RFC: The paradox of choice in web development)
On 19 Feb 2009, at 18:27, Matt Pitts wrote: 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 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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Fri, Feb 20, 2009 at 2:38 PM, Dan Dascalescu wrote: > On Thu, Feb 19, 2009 at 12:07 PM, Matt Pitts wrote: >> 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Thu, Feb 19, 2009 at 12:07 PM, Matt Pitts wrote: > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Thu, Feb 19, 2009 at 1:51 PM, Kieren Diment wrote: > > On 20/02/2009, at 1:51 AM, Jonathan Rockway wrote: > > * On Wed, Feb 18 2009, Dermot wrote: >> >>> 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 >>> 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! ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 20/02/2009, at 1:51 AM, Jonathan Rockway wrote: * On Wed, Feb 18 2009, Dermot wrote: 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 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] RFC: The paradox of choice in web development
> -Original Message- > From: Dave Rolsky [mailto:auta...@urth.org] > 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 > > On Thu, 19 Feb 2009, Matt Pitts wrote: > > > 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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] RFC: The paradox of choice in web development
> -Original Message- > From: Andrew Rodland [mailto:arodl...@comcast.net] > 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 > > On Thursday 19 February 2009 09:12:36 am Matt Pitts wrote: > > 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? 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] RFC: The paradox of choice in web development
On Thu, 19 Feb 2009, Matt Pitts wrote: 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) */ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RFC local::lib + CPAN shell support in CatalystX::Starter (was: Re: [Catalyst] RFC: The paradox of choice in web development)
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Thursday 19 February 2009 09:12:36 am Matt Pitts wrote: > 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? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 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. Getting Perl to talk to some parts of Windows and get information from different 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 more 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 functions work well under Windows. If we consider Perl with all the CPAN modules, then we also can't say that 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 installed 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 other devices, but I think that even the lack of portability is a very big issue, 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 company, a little web shop which for the beginning should be very simple, no credit card payments required, and now I think that the costs involved for creating 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 dollars 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 virtual server where I could have root permissions in order to be able to install everything I need, including Catalyst and all other Perl modules, but this 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 features to his site, and he might need to have even a dedicated server, but in that moment I doubt that he will decide to go for a Perl solution and abandon PHP. If Perl would offer a solution of deploying the Catalyst apps without needing to install anything with a root or shell access, using PAR or something else, Perl would have a much bigger success. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
Cosimo Streppone wrote: 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] RFC: The paradox of choice in web development
> -Original Message- > From: Cosimo Streppone [mailto:cos...@streppone.it] > 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 > ha scritto: > > >> I think that the success of other languages, especially Python is > also > >> 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 > > 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. > > > > [...] > > > 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 > > 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. > > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "Matt Pitts" -Original Message- From: Octavian Rasnita [mailto:orasn...@gmail.com] 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 From: "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. > 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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
In data 19 februar 2009 alle ore 16:12:36, Matt Pitts ha scritto: I think that the success of other languages, especially Python is also 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 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. [...] 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 Does that mean that you haven't tried? 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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] RFC: The paradox of choice in web development
> -Original Message- > From: Octavian Rasnita [mailto:orasn...@gmail.com] > 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 > > From: "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. > > > 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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
2009/2/19 Jonathan Rockway : > * On Wed, Feb 18 2009, Dermot wrote: >> 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). > > 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. Ohh that's painful to hear. Is the venerable Mr Wall still there? That's going to hurt Perl. Dp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
* On Wed, Feb 18 2009, Dermot wrote: > 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 > 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. > 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 $,=$" ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
--- On Wed, 2/18/09, Kieren Diment wrote: > From: Kieren Diment > Subject: Re: [Catalyst] RFC: The paradox of choice in web development > To: "The elegant MVC web framework" > Date: Wednesday, February 18, 2009, 7:41 AM > On 18/02/2009, at 5:55 PM, Dave Rolsky wrote: > > > > > 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. > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 Dave Rolsky wrote: On Tue, 17 Feb 2009, bill hauck wrote: 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) */ -- Stuart Watt ARM Product Developer Information Balance ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 18/02/2009, at 5:55 PM, Dave Rolsky wrote: On Tue, 17 Feb 2009, bill hauck wrote: 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Tue, 17 Feb 2009, bill hauck wrote: 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) */ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Mon, Feb 16, 2009 at 2:25 AM, Dan Dascalescu wrote: > I have no idea who's behind AppliedStacks Update: it's Daniel Cer - http://dmcer.net. > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
Dan Dascalescu wrote: > >> 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) > > Most of the sites added have been crawled by bots from pages > listing "Web sites powered by..." > 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
>> 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Feb 17, 2009, at 11:21 AM, Jonathan Rockway wrote: 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. 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.) 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
> 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 $,=$" ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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. > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 :) On Tue, Feb 17, 2009 at 12:58 PM, Kieren Diment wrote: > > On 17/02/2009, at 9:48 PM, Dan Dascalescu wrote: > >> On Sun, Feb 15, 2009 at 1:13 PM, Kieren Diment wrote: >>> >>> 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 > > > 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. > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 17/02/2009, at 9:48 PM, Dan Dascalescu wrote: On Sun, Feb 15, 2009 at 1:13 PM, Kieren Diment wrote: 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 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Sun, Feb 15, 2009 at 1:13 PM, Kieren Diment wrote: > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
I thought you refer to youporn.com ;-) - Alex Am Sonntag, den 15.02.2009, 13:39 +0100 schrieb Dan Dascalescu: > > Aye, that it is: > > > 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 > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* 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. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 On Feb 16, 2009, at 2:32 AM, Cosimo Streppone wrote: In data 15 februar 2009 alle ore 15:05:33, Octavian Râsnita > ha scritto: From: "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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Sun, 15 Feb 2009, Kieren Diment wrote: 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!!! ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
> 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. > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Sun, Feb 15, 2009 at 10:04 AM, Dan Dascalescu wrote: > > 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. 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/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
In data 15 februar 2009 alle ore 15:05:33, Octavian Râsnita ha scritto: From: "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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
> I've once tried to start a discussion at PerlMonks about that: > http://perlmonks.org/?node_id=515728 Nice but old and too centralized. I suggest adding a "Modules to avoid" section on each page at the wiki page below: >> http://www.perlfoundation.org/perl5/index.cgi?recommended_cpan_modules Again, Data::Dumper mentioned there (before my edit). > 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 Cool! > but sure enough there is also a web framework page at the p5p wiki: > > 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 > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Sun, Feb 15, 2009 at 10:00 PM, Ashley wrote: > On Feb 15, 2009, at 12:31 PM, Octavian Râsnita wrote: >> >> "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. > > See also: > 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/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Feb 15, 2009, at 1:06 PM, Octavian Râsnita wrote: 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 16/02/2009, at 7:31 AM, Octavian Râsnita wrote: From: "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. 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 :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Feb 15, 2009, at 12:31 PM, Octavian Râsnita wrote: "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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinf
Re: [Catalyst] RFC: The paradox of choice in web development
On Feb 15, 2009, at 1:04 AM, Dan Dascalescu wrote: 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 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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. 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. 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... 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 On Feb 15, 2009, at 8:12 AM, Robert L Cochran wrote: 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
Re: [Catalyst] RFC: The paradox of choice in web development
>> 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 > > ___ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > > ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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. Aye, that it is: 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 15.02.2009, at 13:39, Dan Dascalescu wrote: Aye, that it is: 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
2009/2/15 Dan Dascalescu : > > 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 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 15.02.2009, at 09:40, Octavian Râsnita wrote: 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
> Aye, that it is: > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 15.02.2009, at 09:58, Kieren Diment wrote: On 15/02/2009, at 7:50 PM, Russell Jurney wrote: 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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Sunday 15 February 2009 03:04:04 am Dan Dascalescu wrote: > > 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 > > > > 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
> 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 > > 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 Ca
Re: [Catalyst] RFC: The paradox of choice in web development
On 15/02/2009, at 7:50 PM, Russell Jurney wrote: 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
Yahoo has posted some Catalyst specific job listings, so presumably they use Catalyst for something. Russell Jurney rjur...@lucision.com On Feb 15, 2009, at 3:40 AM, Octavian Râsnita wrote: 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: "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' 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. 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. 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. 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
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 On Feb 13, 2009, at 4:37 PM, Octavian Râsnita wrote: 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" > To: Sent: Saturday, February 14, 2009 12:01 AM Subject: [Catalyst] RFC: The paradox of choice in web development 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 an
Re: [Catalyst] RFC: The paradox of choice in web development
On 15/02/2009, at 1:57 PM, Kevin Monceaux wrote: Catalyst Fans, On Fri, 13 Feb 2009, David Steiner wrote: 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
Catalyst Fans, On Fri, 13 Feb 2009, David Steiner wrote: 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!!! ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [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" To: Sent: Saturday, February 14, 2009 12:01 AM Subject: [Catalyst] RFC: The paradox of choice in web development 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] RFC: The paradox of choice in web development
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
