On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: > On Dec 6, 2007 7:22 PM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > > # from Bill Ward > > # on Thursday 06 December 2007 16:23: > > > > >Cute experiment, but I REALLY hope nobody tries releasing useful > > >modules to CPAN that depend on this... > > > > Cute comment, but I really hope nobody puts any stock in it. What skin > > is it off of your nose if a useful module uses something you're afraid > > of? > > Sorry to be snarky. What I was getting at was that I need to support > Perl modules in a production environment, and experiments like this
How do you support Perl modules in a production environment ? My preference is to not allow developers near the production servers and my clients (in theory) make the developers test the code on the staging server. Any modules available system wide, I build individually (or get from the o/s - debian). I try to avoid CPAN because of automatic dependency import. > may be academically interesting but introduce levels of instability > and inefficiency that are not consistent with that environment. If > modules that we need to use are based on it, then I have a difficult > decision as to whether the module is wotrh that risk just so Perl can > be written in a more Lisp-like manner. > > Experimenting with the language itself should be reserved for new > development such as Perl 6, not for trying to add yet more layers on > top of Perl 5. And from a Perl advocacy perspective, instead of TMTOWTDI. You are way way too late for this. > making Perl more attractive to the hordes of Lisp programmers out > there, I think we should be more interested in making Perl 5 > attractive for real world uses. I'm switching to python wherever practical. DRY is much less chaotic. -- --gh
