Re: In defence of Perl
* James Powell ([EMAIL PROTECTED]) wrote: > On Tue, Feb 13, 2001 at 12:16:57PM +, Greg McCarroll wrote: > [snip] > > > > > > > As one of the requirements listed was content management you can > > > through in the BBC, especially the interactive telly division. Heck, > > > they even gave a presentation at YAPC::Europe. > > > > > > > they even won a BAFTA for some of the stuff they (we) did with perl > > > > http://www.mccarroll.uklinux.net/pics/greg_bafta_bw.jpeg > > You've just photoshopped a BAFTA on to a picture of meatloaf > receiving his lifetime achievement award at the VH-1 music awards! > i'll take that as a compliment, thanks to my reality distortian glasses i am wearing today (they are rose tinted) ;-) -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: In defence of Perl
On Tue, Feb 13, 2001 at 12:16:57PM +, Greg McCarroll wrote: [snip] > > > > > As one of the requirements listed was content management you can > > through in the BBC, especially the interactive telly division. Heck, > > they even gave a presentation at YAPC::Europe. > > > > they even won a BAFTA for some of the stuff they (we) did with perl > > http://www.mccarroll.uklinux.net/pics/greg_bafta_bw.jpeg You've just photoshopped a BAFTA on to a picture of meatloaf receiving his lifetime achievement award at the VH-1 music awards! jp
Re: In defence of Perl
* Simon Wilcox ([EMAIL PROTECTED]) wrote: > At 11:48 13/02/2001 +, you wrote: > > [snip] > > >As one of the requirements listed was content management you can through > >in the BBC, especially the interactive telly division. Heck, they even > >gave a presentation at YAPC::Europe. > > Does anyone know if that presentation is available online anywhere ? > i might have it in one of a several 100Mb of wav files awaiting checking and mp3ing however, having been at the presentation i dont think it is what you need -- Greg McCarroll http://www.mccarroll.uklinux.net
RE: In defence of Perl
At 11:48 13/02/2001 +, you wrote: [snip] >As one of the requirements listed was content management you can through >in the BBC, especially the interactive telly division. Heck, they even >gave a presentation at YAPC::Europe. Does anyone know if that presentation is available online anywhere ? Simon
Re: In defence of Perl
* Neil Ford ([EMAIL PROTECTED]) wrote: > >> > >> This is a plea for help. Here is the situation: > > > >[situation snipped] > > > >> My belief is that the LAMP type route provides a very cost effective, > >> portable and scalable solution but I concede that bigger backends are > >> needed for volume transaction systems. > > > >Funnily enough I am about half way through an article for the new > >www.onlamp.com site that is quite relevant to your situation. I'll whip > >myself to get it finished soon. > > > >> The help I need is in answering some questions: > >> > >> What big corporates are using perl in web development and > >> how/for what ? > > > >Lots. In the last couple of weeks alone I've run across one operating stock > >exchange heavily built around Perl, and the content management system / > >e-marketplace hubstorm (www.hubstorm.com) is almost entirely Perl based. > >Neither are trivial applications, although I don't vouch for how effective > >they are or if Perl was the right tool to use. > > > As one of the requirements listed was content management you can > through in the BBC, especially the interactive telly division. Heck, > they even gave a presentation at YAPC::Europe. > they even won a BAFTA for some of the stuff they (we) did with perl http://www.mccarroll.uklinux.net/pics/greg_bafta_bw.jpeg -- Greg McCarroll http://www.mccarroll.uklinux.net
RE: In defence of Perl
>> >> This is a plea for help. Here is the situation: > >[situation snipped] > >> My belief is that the LAMP type route provides a very cost effective, >> portable and scalable solution but I concede that bigger backends are >> needed for volume transaction systems. > >Funnily enough I am about half way through an article for the new >www.onlamp.com site that is quite relevant to your situation. I'll whip >myself to get it finished soon. > >> The help I need is in answering some questions: >> >> What big corporates are using perl in web development and >> how/for what ? > >Lots. In the last couple of weeks alone I've run across one operating stock >exchange heavily built around Perl, and the content management system / >e-marketplace hubstorm (www.hubstorm.com) is almost entirely Perl based. >Neither are trivial applications, although I don't vouch for how effective >they are or if Perl was the right tool to use. > As one of the requirements listed was content management you can through in the BBC, especially the interactive telly division. Heck, they even gave a presentation at YAPC::Europe. And of course BBC Online is predominantly Perl. Neil. -- Neil C. Ford Yet Another Computer Solutions Company [EMAIL PROTECTED]
RE: In defence of Perl
> > Is there any benchmarking available of salary bands for > > differing skills, > > i.e. are perl guys much more than ASP guys who can also do > > the other bits ? > > Any other arguments I should be making ! >Yeah, Perl people cost more than ASP people and they're frickin >impossible to find, and vary wildly in quality. This is IMHO Perl's >single greatest barrier to acceptance, and in business terms it's an >entirely valid point. >From my experience, in the current contracting market ASP coders are more expensive then Perl developers (by around 10-15%). The variation in quality of output would hold for both sides. IMHO Perl developers tend to know more about good coding practices than VB/ASP coders (whether they practice them is another matter) since VB isn't exactly a difficult language and pretty much anyone can pick it up quickly. This could be a factor with long term development/maintenance if you have staff turnover. Ian _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: In defence of Perl
* Jonathan Stowe ([EMAIL PROTECTED]) wrote: > On Tue, 13 Feb 2001, Greg McCarroll wrote: > > > > this is the sort of analysis that IT managers should be good at > > > > Emphasis on *should* as opposed to *are* . > hey i was trying to put it in a nice way -- Greg McCarroll http://www.mccarroll.uklinux.net
RE: In defence of Perl
> > This is a plea for help. Here is the situation: [situation snipped] > My belief is that the LAMP type route provides a very cost effective, > portable and scalable solution but I concede that bigger backends are > needed for volume transaction systems. Funnily enough I am about half way through an article for the new www.onlamp.com site that is quite relevant to your situation. I'll whip myself to get it finished soon. > The help I need is in answering some questions: > > What big corporates are using perl in web development and > how/for what ? Lots. In the last couple of weeks alone I've run across one operating stock exchange heavily built around Perl, and the content management system / e-marketplace hubstorm (www.hubstorm.com) is almost entirely Perl based. Neither are trivial applications, although I don't vouch for how effective they are or if Perl was the right tool to use. > Why perl is better (or could be better) than a combination of > ASP/VBScript/VB/MTC How long have you got? :-). On the grounds that its better to attack weaknesses than strengths, I'd concentrate on: VBscript is a poor language. ASP environment is very hard to debug - even worse than mod_perl :-0 ASP provides a poorer abstraction model than the latest perl offerings - TemplateToolkit, AxKit and the like. Locked into MS technologies. > Is there any benchmarking available of salary bands for > differing skills, > i.e. are perl guys much more than ASP guys who can also do > the other bits ? > Any other arguments I should be making ! Yeah, Perl people cost more than ASP people and they're frickin impossible to find, and vary wildly in quality. This is IMHO Perl's single greatest barrier to acceptance, and in business terms it's an entirely valid point. > My big problem is that with a huge investment in the MS code > base, I am > fighting a rearguard action to prevent having to adopt MS stuff, just > because we've already spent loads on it, which seems false > economy to me. It isn't necessarily a false economy. You can't tell until you can show what the ongoing costs are of the Perl system vs the MS system. Either you can get out Excel and start doing a spreadsheet, putting in cost assumptions, and showing that your way pays off over n months, or you can argue that no switch should be made until the two strategies can be compared for cost effectiveness. Either way I'd be very interested in the results :-) As for 'chucking out code' - well, most code gets chucked out pretty soon. Is that ASP stuff really so good it's worth keeping? What you normally want to avoid chucking out is knowledge - familiarity with APIs, knowledge of the strengths and weaknesses of a platform, bugs to avoid, tricks of the trade, and so forth. Ask yourself if you really have anything here vis a vis the ASP code? Or is just alot of lines of nothing very exciting? > My preferred approach would be to stick with MS tech for > maintenance of the > existing code base and continue to sub out for developers, > and use open > source tech for new development, with commercial backends > when we need that > level of sophistication. Anyone have any comment on this ? I would not especially recommend Perl for an environment with high staff turnover, such as might be the case with contract work. Is your internal documentation and structure good enough that new perl programmers can easily get up to speed on the project? > Thank you for your attention, all advice gratefully received. >
Re: In defence of Perl
On Tue, 13 Feb 2001, Greg McCarroll wrote: > > this is the sort of analysis that IT managers should be good at > Emphasis on *should* as opposed to *are* . /J\ -- Jonathan Stowe | http://www.gellyfish.com | I'm with Grep on this one http://www.tackleway.co.uk |
Re: In defence of Perl
* Simon Wilcox ([EMAIL PROTECTED]) wrote: > At 11:12 13/02/2001 +, you wrote: > > > This is all fine but there is a big cloud. We have a new IT manager who > > > wants to bring all development into one team and use a single toolset for > > > web based applications. > > > >why dont you just track both projects for a while and get some results > >about the current productivity of both teams, say a month or two. > > We don't actually have any developers and deciding what to recruit is at > the core of the issue. I covered the code development for the intranet but > I have to spend too much time on managing the process now & the job > management system sub-ed out all the development. > > We could go forward with contract staff for a few months but there is > already a perception that they don't want to "waste" development in one > language by ditching it later. > ok then carry out the analysis on historical information that is relevant to your company, to even the playing field, cost yourself as a contractor and see which of the two projects has the post functionality vs. cost this is the sort of analysis that IT managers should be good at -- Greg McCarroll http://www.mccarroll.uklinux.net
Re: In defence of Perl
At 11:12 13/02/2001 +, you wrote: > > This is all fine but there is a big cloud. We have a new IT manager who > > wants to bring all development into one team and use a single toolset for > > web based applications. > >why dont you just track both projects for a while and get some results >about the current productivity of both teams, say a month or two. We don't actually have any developers and deciding what to recruit is at the core of the issue. I covered the code development for the intranet but I have to spend too much time on managing the process now & the job management system sub-ed out all the development. We could go forward with contract staff for a few months but there is already a perception that they don't want to "waste" development in one language by ditching it later. >then put it into an analysis model showing the cost of moving either >team to the others toolset and the perceived cost reductions in the >long term supporting just one toolset. > >these things always need to be analysed properly rather than gut >instincts and who can argue the best. Agree 100% ! >Greg > >-- >Greg McCarroll http://www.mccarroll.uklinux.net
Re: In defence of Perl
At Tue, 13 Feb 2001 11:12:47 +, Greg McCarroll <[EMAIL PROTECTED]> wrote: > > This is all fine but there is a big cloud. We have a new IT manager > > who wants to bring all development into one team and use a single > > toolset for web based applications. > > why dont you just track both projects for a while and get some results > about the current productivity of both teams, say a month or two. > > then put it into an analysis model showing the cost of moving either > team to the others toolset and the perceived cost reductions in the > long term supporting just one toolset. > > these things always need to be analysed properly rather than gut > instincts and who can argue the best. Ro, why not just threaten to track the productivity of both teams for a while and see who gets the most edgy :) Dave...
Re: In defence of Perl
> This is all fine but there is a big cloud. We have a new IT manager who > wants to bring all development into one team and use a single toolset for > web based applications. why dont you just track both projects for a while and get some results about the current productivity of both teams, say a month or two. then put it into an analysis model showing the cost of moving either team to the others toolset and the perceived cost reductions in the long term supporting just one toolset. these things always need to be analysed properly rather than gut instincts and who can argue the best. Greg -- Greg McCarroll http://www.mccarroll.uklinux.net
In defence of Perl
Good morning all, This is a plea for help. Here is the situation: Over the last year I have been building an intranet type site based on Linux/Apache/MySQL/mod_perl. This is delivered via the internet, suitably authenticated (mod_perl/LDAP) and encrypted (mod_ssl), as most of our 1,700 people use client supplied PC equipment. It has been very successfully received and much more development is wanted. To accommodate all the requirements I have asked for funding for two perl developers to rebuild the site in a more modular and easy to manage form and add content management, forums, document management etc etc. This is all fine but there is a big cloud. We have a new IT manager who wants to bring all development into one team and use a single toolset for web based applications. The other development team has been working for 3 years on a web-based job management system which has been developed/enhanced by several third parties (we own the code but sub for the development resources). It is an NT system, using IIS, ASP, VBScript, VB dlls, MTC components and a MS SQL backend with stored procedures etc etc. This system is deployed on our client sites and does not at any time run over the internet. They now have a need to redevelop large parts of the application as the original requirements have changed considerably and are looking to bring the development in house. We are now locked in argue^H^H^H^H^Hdiscussion about how to standardise our toolsets. My belief is that the LAMP type route provides a very cost effective, portable and scalable solution but I concede that bigger backends are needed for volume transaction systems. The help I need is in answering some questions: What big corporates are using perl in web development and how/for what ? Why perl is better (or could be better) than a combination of ASP/VBScript/VB/MTC Is there any benchmarking available of salary bands for differing skills, i.e. are perl guys much more than ASP guys who can also do the other bits ? Any other arguments I should be making ! My big problem is that with a huge investment in the MS code base, I am fighting a rearguard action to prevent having to adopt MS stuff, just because we've already spent loads on it, which seems false economy to me. My preferred approach would be to stick with MS tech for maintenance of the existing code base and continue to sub out for developers, and use open source tech for new development, with commercial backends when we need that level of sophistication. Anyone have any comment on this ? Thank you for your attention, all advice gratefully received. Regards, Simon Wilcox
