Re: What hurts you the most in Perl?
On Thu, Dec 02, 2010 at 08:19:32AM +0100, Matija Grabnar wrote:
Right now? I need support for IPv6, actually support for dual-stack
in standard library
calls and in the major CPAN modules. Preferably transparent one, not
one involving loading
a special library, and patching third party modules to call Socket6
instead of Socket, or whatever.
Does
IO::Socket::IP
look like it'll help you?
I am at this very moment working on getting proper IPv6 handling into
core perl - bleadperl's Socket.xs already has
{pack,unpack}_sockaddr_in6, and I am working on getaddrinfo /
getnameinfo now. I hope to be able to have IO::Socket::IP in core by
5.14.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: What hurts you the most in Perl?
On 12/10/2010 02:07 PM, Paul LeoNerd Evans wrote:
Does
IO::Socket::IP
look like it'll help you?
Yes, it does. Now I need to start bothering other module writers to use
it in
modules where I need dual stack support.
Thank you!
I am at this very moment working on getting proper IPv6 handling into
core perl - bleadperl's Socket.xs already has
{pack,unpack}_sockaddr_in6, and I am working on getaddrinfo /
getnameinfo now. I hope to be able to have IO::Socket::IP in core by
5.14
Thank you, thank you, thank you. Any idea when that might be time-wise?
Re: What hurts you the most in Perl?
We hear the same argument in reverse that people should work on Perl 5 instead of Perl 6, as if the people who are working on Perl 6 would _of course_ be working on Perl 5 if 6 didn't exist. There's no reason to think this is true, and many reasons to think it's not. Many Perl 6 people never contributed to Perl 5 the way they do with 6. Maybe there are others that said that, but I have said something related and I want to be more clear. I wasn't attributing this idea to you. The idea that Perl 6 has drained development resources from Perl 5 has come up many times over the years. For some reason this reminds me of the idea that's come up several times, that learning DBIC is quicker and easier than learning SQL if you don't know SQL already. Another idea I don't agree with, although I concede the idea that people would be working on Perl 6 if it weren't for Perl 5 focus is pure assumption based on no real evidence; much like the idea above. As I recall, there was something of a glut of volunteers in 2000 gumming up the perl 5 maintenance works: one thing the perl 6 project immediately succeeded at was, reduce the noise in p5p. Also: ECMAscript is a standard, and is perfectly fine for what it is, migrating systems other than client-side web page automations to it continues to be wise. Also: going the way of FORTRAN or COBOL looks, based on statistical facts, to be a good thing -- an immense installed base of mission-critical systems -- opposed to, say, going the way of Simula or ALGOL, and being a fascinating historical footnote. COBOL is the rivets in Big Iron. -- It is merely a matter of persistence. -- Albert Camus
Re: What hurts you the most in Perl?
On Thu, Dec 2, 2010 at 1:58 AM, Octavian Rasnita orasn...@gmail.com wrote: From: Gabor Szabo szab...@gmail.com I am now trying again to build an .exe for Windows using PAR. If that is successful then we might have a chance to build similar packages for Linux and OS X.. Please dont forget about ActivePerl. :-) As far as I know there are ppm packages for Padre maintained by Mark Dootson. He just announced the latest versions 2 weeks ago: http://mail.perlide.org/pipermail/padre-dev/2010-November/002149.html Are those not working for you? regards Gabor ps. Probbaly we should mentione them on our download page as well http://padre.perlide.org/download.html
Re: What hurts you the most in Perl?
On Thu, Dec 2, 2010 at 9:41 AM, Eric Wilhelm enoba...@gmail.com wrote: # from Gabor Szabo # on Wednesday 01 December 2010 13:46: Many modules on CPAN also need improvements. But even what we have today we could achieve much better results if the perception of people was better. With my original question I wanted to know what technological and perception related issues people see. We already got some material but I'd be happy to see more comments. Especially from those who work with people who are not involved in the Perl community. How do your peers and your bosses see Perl? We have all heard the conventional wisdom that perl is dead. But, anything related to perception which cannot be solved by writing modules is probably off-topic for this list. I think this is one of the issues we have. For every topic we tend to setup a separate mailing list (or sometimes more) and try to segregate the people to that list. So there is an advocacy list a marketing list - both are almost deserted. The latter does not even have a public archive. In the meantime module-authors arrive to the conclusion that they need to change language in order to put food on the table. And I don't blame them. I'd go further. Because we have all these perl specific mailing list we tend to talk among ourselves. Which is safe (well, except of the occassional trashing and bashing) but which means others don't hear us and we don't hear others. Technological issues with the CPAN and its modules abound. We have 20+ years worth of code and archives to maintain and we're running short on maintainers. See here: http://kfsone.wordpress.com/2010/11/30/take-that-python/ So what are the plans. How do we get more people to maintain code on CPAN? And what are the priorities? Most people will want to spend their time on writing new fun code. Maintaining old code, documenting it, fixing obscure bugs, making sure it also works on windows. None of these are priorities of the average Open source Perl developers. OTOH companies invested in Perl tend to want that too. Gabor ps. Have I already mentioned that this is the gap we are trying to bridge with the Perl Ecosystem Group?
Re: What hurts you the most in Perl?
On Wed, Dec 01, 2010 at 11:19:07PM +0200, Gabor Szabo wrote: On Wed, Dec 1, 2010 at 7:21 PM, David Cantrell da...@cantrell.org.uk wrote: [re Padre] And is there a working binary for OS X that I can just download and run without wasting a day fighting against Wx? Unfortunatelly not. Hmmm, I see that there's a PPM of it, and that Activestate support OS X. But before I go ahead and install that, does anyone know where Activeperl installs? I don't want it trampling all over any of my current perl builds! -- David Cantrell | Official London Perl Mongers Bad Influence
Re: What hurts you the most in Perl?
In re the hashref vs list argument the motivation forme is that I gain very little from using Perl's parameter prototyping. Indeed we have modules such as Params::Validate because others feel the same way. Perl is a weakly typed language. It doesn't have type-based method dispatch as Java does. Those want that use a module that helps or roll their own. It doesn't have real type checking at compile time. It barely does at run time. There is no difference between an integer and real or floating point. Despite this people have some elegant math packages in Perl. I admit that if I wanted to do some signal processing I would not reach for Perl to write my Fourier Transform or do spread spectrum analysis (I personally would reach for C, my professor from grad school uses MathCAD). The nice thing is I CAN reach for statistics modules and get a coefficient of variance o a dataset I pull from a database with Perl. Perl is many things to many people. Small changes in syntax to fix things like multiway branching are great. I think not only threading but threadsafe modules for thr major threaded tasks are important. Anything with I/O needs thread safety. Layered IO might be needing this such as IO::Compress::Bzip2. Certainly database interfaces to major dbms: DBI, DBD::Oracle, DBD::Pg, DBD::MySQL etc. Those all have dbms-side treads (SQLite does not its not a separate process) Sent from my BlackBerry® smartphone with Nextel Direct Connect
Re: What hurts you the most in Perl?
On 10-12-02 11:36 AM, Dana Hudes wrote: In re the hashref vs list argument the motivation forme is that I gain very little from using Perl's parameter prototyping. Indeed we have modules such as Params::Validate because others feel the same way. Perl is a weakly typed language. It doesn't have type-based method dispatch as Java does. Those want that use a module that helps or roll their own. It doesn't have real type checking at compile time. It barely does at run time. There is no difference between an integer and real or floating point. I like Perl's lack of datatypes. Don't forget datatypes were invented by compiler writers to make their job easier. They do not make programming easier. People do not think in terms of datatypes. For example: Java. In Java, you declare your variables like: int iCount = 0; Notice they all start with a sigil to indicate the datatype. That's there to remind the programmer what the datatype is. Another example: Go out into the real word and ask, How do you multiple by ten? The answer you get is, Put a zero on the end of it. Thaat is string manipulation, not arithmetic. In the real world, people automatically switch datatypes, depending on what they're doing. Having datatypes just means more bookkeeping. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. The secret to great software: Fail early often. Eliminate software piracy: use only FLOSS.
Re: What hurts you the most in Perl?
On Thursday, December 2, 2010, Shawn H Corey shawnhco...@gmail.com wrote: On 10-12-02 11:36 AM, Dana Hudes wrote: In re the hashref vs list argument the motivation forme is that I gain very little from using Perl's parameter prototyping. Indeed we have modules such as Params::Validate because others feel the same way. Perl is a weakly typed language. It doesn't have type-based method dispatch as Java does. Those want that use a module that helps or roll their own. It doesn't have real type checking at compile time. It barely does at run time. There is no difference between an integer and real or floating point. I like Perl's lack of datatypes. Don't forget datatypes were invented by compiler writers to make their job easier. They do not make programming easier. People do not think in terms of datatypes. Compared to other dynamically typed languages you'd say Perl has *some* static typing, that's kinda what sigils are in my view.
Re: What hurts you the most in Perl?
On 02/12/2010 02:57, Dave Rolsky wrote: On Thu, 2 Dec 2010, Octavian Rasnita wrote: From: Dave Rolsky auta...@urth.org We hear the same argument in reverse that people should work on Perl 5 instead of Perl 6, as if the people who are working on Perl 6 would _of course_ be working on Perl 5 if 6 didn't exist. There's no reason to think this is true, and many reasons to think it's not. Many Perl 6 people never contributed to Perl 5 the way they do with 6. Maybe there are others that said that, but I have said something related and I want to be more clear. I wasn't attributing this idea to you. The idea that Perl 6 has drained development resources from Perl 5 has come up many times over the years. For some reason this reminds me of the idea that's come up several times, that learning DBIC is quicker and easier than learning SQL if you don't know SQL already. Another idea I don't agree with, although I concede the idea that people would be working on Perl 6 if it weren't for Perl 5 focus is pure assumption based on no real evidence; much like the idea above. Lyle
Re: What hurts you the most in Perl?
To add my five cents, the thing that hurts me the most is that Perl is not an accepted language when it comes to the differnet new platforms. Our work has adopted Drupal as a CMS and it's written in PHP. It would be awesome if it was written in Perl, but as someone else posted in this thread, we can pick up languages pretty easily (better than foreign languages, no? ;)) and be productive in a few weeks. I'm also attracted to the new Android and iPad platforms, but there's no Perl there, either. There's no Perl when it comes to creating client-side web applications (using JavaScript). IMHO, Perl is getting relegated to server-side/backend applications and when more power is getting brought to the front, it's losing mindshare/focus. - Jason http://use.perl.org/~Purdy/journal/31280 On 11/24/2010 07:01 AM, Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. So I wonder what hurts *you* the most in Perl? Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/
Re: What hurts you the most in Perl?
On 01/12/2010 07:37, Bill Ward wrote: I think Perl 6 may be the death of Perl. I think it's Perl's last hope. I think minds and time spent on slow Perl 6 ish things like Moose for Perl 5 will be the death of Perl. It's already at least five years too late to make any real impact as a new version of Perl. Maybe if it is given a different name and not presented as being a new version of Perl, but instead a whole new language that is an outgrowth of the Perl community (the way Ruby is) then it might have a shot. I only ever heard Perl programmers talking about Ruby. Overall I wouldn't say it's uptake is good at all. But really, it boils down to marketing. Perl has no marketing behind it, and in fact most of the people in the Perl community seem to view marketing as beneath them. Here there are two very, very valid points. Some attitudes of key community members drastically affect the way Perl is promoted and new members are treated. Perl needs a lot, lot more marketing; I only see this coming through Perl 6. No matter what's added to Perl 5, it's still the old language with awkward objects or at best, very slow trying to be Perl 6 style objects. I think much of what Octavian said is right on the button. Lyle
Re: What hurts you the most in Perl?
On Wed, 1 Dec 2010, Lyle wrote: On 01/12/2010 07:37, Bill Ward wrote: I think Perl 6 may be the death of Perl. I think it's Perl's last hope. I think minds and time spent on slow Perl 6 ish things like Moose for Perl 5 will be the death of Perl. This is a ridiculous statement. You seem to assume that the people who work on Moose would otherwise be putting all their energy into Perl 6, if not for Moose. I can't speak for the other people who work on Moose, but I know that I wouldn't. I have nothing against Perl 6, and I look forward to using it in the future. However, right now, Perl 5 meets my needs far better than Perl 6 (a mature language with a large set of libraries available). If Moose didn't exist I'd still be putting my energy into Perl 5 development of some sort. We hear the same argument in reverse that people should work on Perl 5 instead of Perl 6, as if the people who are working on Perl 6 would _of course_ be working on Perl 5 if 6 didn't exist. There's no reason to think this is true, and many reasons to think it's not. Many Perl 6 people never contributed to Perl 5 the way they do with 6. If anything, I think the back and forth between 5 and 6 has helped both languages quite a bit. The work Stevan did on the Perl 6 object system has led to Moose. The work on Moose has (I hope) influenced the actual implementation of the Perl 6 object system. If _you_ think Perl 6 is Perl's last hope, than I strongly encourage you to get involved, but please don't shit on other people's work. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: What hurts you the most in Perl?
On 01/12/2010 16:01, Dave Rolsky wrote: On Wed, 1 Dec 2010, Lyle wrote: On 01/12/2010 07:37, Bill Ward wrote: I think Perl 6 may be the death of Perl. I think it's Perl's last hope. I think minds and time spent on slow Perl 6 ish things like Moose for Perl 5 will be the death of Perl. If _you_ think Perl 6 is Perl's last hope, than I strongly encourage you to get involved, but please don't shit on other people's work. I wasn't *shitting* as you put it, on other peoples work. At least no more so than Bill's original comment about Perl 6. I expressed my opinion only and should be free to do so. Don't take things so personally. I haven't seen moose bring any new programmers to Perl; I've only seen excitement about it from some Perl 5 developers, I've seen it cause frustrations for others. The ones I've seen excited about it have mostly been so due to the belief that it's a step towards Perl 6, allowing them to learn some Perl 6 in advance. Note the language again there, I said I've only seen, not there aren't any. I'm not one to blindly follow popular opinions. I can talk from my own experiences and perceptions only. For me Moose is a real pain, mostly due to performance and Octavian's point: - Another thing that hurts in Perl and which is also a reason why many programmers don't like Perl is that it is not possible to install an application to a server by just uploading the files there and give some permissions, especially if that app uses XS, and not everyone has access to a shell; Lyle
Re: What hurts you the most in Perl?
On Sun, Nov 28, 2010 at 08:03:54PM -0800, Jarrod Overson wrote: The inability for an IDE to help me thoroughly refactor code is the biggest problem for me. Can Padre do that yet? And is there a working binary for OS X that I can just download and run without wasting a day fighting against Wx? -- David Cantrell | Reality Engineer, Ministry of Information What profiteth a man, if he win a flame war, yet lose his cool?
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 6:21 PM, Lyle webmas...@cosmicperl.com wrote: I wasn't *shitting* as you put it, on other peoples work. At least no more so than Bill's original comment about Perl 6. I expressed my opinion only and should be free to do so. I already asked Bill in my response to refrain from such comments. I don't think that having freedom of speech means we should not care about the feelings of our fellow Perl mongers and we should not respect their work. Don't take things so personally. I don't think Dave really needs me here but I don't think he took it personally. I think you felt you have a right to trash Moose because Perl 6 was trashed. Can we drop this direction of the discussion now? BTW installing Moose takes some time. It might even be very difficult on a server where you don't have command line access but I never tried that. I don't think that is the source of the problem. I think we had of the difficult installation issue a lot before Moose was developed. With that said, we need solution for that. Gabor
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 7:21 PM, David Cantrell da...@cantrell.org.uk wrote: On Sun, Nov 28, 2010 at 08:03:54PM -0800, Jarrod Overson wrote: The inability for an IDE to help me thoroughly refactor code is the biggest problem for me. Can Padre do that yet? In a very limited way. There has been some work providing some refactoring tools and IMHO all of them were already integrated with vim but it is very far from what I wanted. And is there a working binary for OS X that I can just download and run without wasting a day fighting against Wx? Unfortunatelly not. I am now trying again to build an .exe for Windows using PAR. If that is successful then we might have a chance to build similar packages for Linux and OS X.. Regardless if your favorit editor can integrate with external scripts then you can try to integrate the same tools as have been done with vim and we can further cooperate on refactoring tools. Gabor
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 1:11 PM, Gabor Szabo szab...@gmail.com wrote: On Wed, Dec 1, 2010 at 6:21 PM, Lyle webmas...@cosmicperl.com wrote: I wasn't *shitting* as you put it, on other peoples work. At least no more so than Bill's original comment about Perl 6. I expressed my opinion only and should be free to do so. I already asked Bill in my response to refrain from such comments. I don't think that having freedom of speech means we should not care about the feelings of our fellow Perl mongers and we should not respect their work. I wasn't shitting on Perl 6. I just don't think it stands a snowball's chance in hell of being adopted in place of Perl 5, unless some serious marketing energy is thrown behind it (like getting rid of the Perl name which is more of a liability these days). People will hear Perl 6 and assume it's just a new version of an obsolete language, when really it's almost a whole new language. But I'm not shitting on Perl 6 itself. I think it's got some beautiful ideas in it. But it's been in design/development for so long that it seems like it will always be vaporware, and in the meantime Perl 5 has been neglected. What's called Perl 6 should be a whole new language with a new name, and the things about Perl 5 that are so out of date should have been fixed in that codeline. As for Moose, I have similar concerns. I think it changes the nature of the language too much to be considered Perl, but not enough to be considered a new language. Maybe if Moose was more like a repackaging of Perl with the Moose stuff more tightly integrated, and presented as a new language that's based on and backward-compatible with Perl 5, then maybe it would make more sense. But as it is, it's just Perl with some weird changes to the OO practices that are incompatible with the majority of Perl5 code out there. The technology is fine. But we (collectively, the Perl community) suck at marketing. The perception I hear everywhere I go is that Perl is a dead-end language, and will soon go the way of Fortran or COBOL. It's too late to change that. But maybe if Perl 6 were released under a totally new name it could gain traction the way Ruby has done.
Re: What hurts you the most in Perl?
On Wed, Dec 1, 2010 at 11:22 PM, Bill Ward b...@wards.net wrote: I wasn't shitting on Perl 6. Oh, then sorry for my wording. The technology is fine. But we (collectively, the Perl community) suck at marketing. The perception I hear everywhere I go is that Perl is a dead-end language, and will soon go the way of Fortran or COBOL. It's too late to change that. But maybe if Perl 6 were released under a totally new name it could gain traction the way Ruby has done. Sure, Perl needs some technological improvements and I think people involved in p5p have been doing some nice things lately at an increasing speed. Many modules on CPAN also need improvements. But even what we have today we could achieve much better results if the perception of people was better. With my original question I wanted to know what technological and perception related issues people see. We already got some material but I'd be happy to see more comments. Especially from those who work with people who are not involved in the Perl community. How do your peers and your bosses see Perl? I don't think it is too late. I think we just need to get up and start talking to people outside of the Perl community. That's what I have been trying to push forward with varrying success via the TPF Events group. https://www.socialtext.net/perl5/index.cgi?events Gabor
Re: What hurts you the most in Perl?
From: Gabor Szabo szab...@gmail.com I am now trying again to build an .exe for Windows using PAR. If that is successful then we might have a chance to build similar packages for Linux and OS X.. Please dont forget about ActivePerl. :-) Thanks. Octavian
Re: What hurts you the most in Perl?
From: Dave Rolsky auta...@urth.org We hear the same argument in reverse that people should work on Perl 5 instead of Perl 6, as if the people who are working on Perl 6 would _of course_ be working on Perl 5 if 6 didn't exist. There's no reason to think this is true, and many reasons to think it's not. Many Perl 6 people never contributed to Perl 5 the way they do with 6. Maybe there are others that said that, but I have said something related and I want to be more clear. I said that because Perl 6 was announced 10 years ago, in the latest years there were very few Perl 5 books published, so I was referring only to the work of creating books. This is true, but I don't know, maybe I am wrong and there are other reasons for which there are fewer Perl books in the last period, not only because the interest for Perl 5 decreased... Octavian
Re: What hurts you the most in Perl?
On Thu, 2 Dec 2010, Octavian Rasnita wrote: From: Dave Rolsky auta...@urth.org We hear the same argument in reverse that people should work on Perl 5 instead of Perl 6, as if the people who are working on Perl 6 would _of course_ be working on Perl 5 if 6 didn't exist. There's no reason to think this is true, and many reasons to think it's not. Many Perl 6 people never contributed to Perl 5 the way they do with 6. Maybe there are others that said that, but I have said something related and I want to be more clear. I wasn't attributing this idea to you. The idea that Perl 6 has drained development resources from Perl 5 has come up many times over the years. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: What hurts you the most in Perl?
2010/12/1 Jason Purdy ja...@journalistic.com: To add my five cents, the thing that hurts me the most is that Perl is not an accepted language when it comes to the differnet new platforms. Our work has adopted Drupal as a CMS and it's written in PHP. It would be awesome if it was written in Perl, but as someone else posted in this thread, we can pick up languages pretty easily (better than foreign languages, no? ;)) and be productive in a few weeks. I'm also attracted to the new Android and iPad platforms, but there's no Perl there, either. Veering off-topic briefly. Perl is available through the android scripting engine http://code.google.com/p/android-scripting/ although only Java has first-class support with access to all the GUI and other stuff. You can run command-line perl no problem so you can script fetching things to your phone etc. You could also run a server in Perl and interact with it through the browser (I know of at least one python app that does this for android), F There's no Perl when it comes to creating client-side web applications (using JavaScript). IMHO, Perl is getting relegated to server-side/backend applications and when more power is getting brought to the front, it's losing mindshare/focus. - Jason http://use.perl.org/~Purdy/journal/31280 On 11/24/2010 07:01 AM, Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. So I wonder what hurts *you* the most in Perl? Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/
Re: What hurts you the most in Perl?
2010/12/1 Gabor Szabo szab...@gmail.com: On Wed, Dec 1, 2010 at 11:22 PM, Bill Ward b...@wards.net wrote: With my original question I wanted to know what technological and perception related issues people see. We already got some material but I'd be happy to see more comments. Especially from those who work with people who are not involved in the Perl community. How do your peers and your bosses see Perl? Usually bosses don't care (except biased cases with personal preferences), usual points are - how to reach the goal in most efficient way, and how to maintain the solution afterwards. With wide CPAN repository first point could be achieved for certain tasks quickly using Perl. However it becomes a real nightmare afterwards for a second point - maintenance %) Long dependencies of hardly or not-at-all maintained packages are making it really tough to justify the choice when writing support documentation - you need either to fetch and pre-pack all packages, making final solution bloated and redundant, or copy-paste required fragments of code from modules into own lightweight-all-purpose-toolkit module %) Second point also implies using common language in single environment, thus if Perl is already used in some area, it is wise to follow the line. I don't think it is too late. I think we just need to get up and start talking to people outside of the Perl community. That's what I have been trying to push forward with varrying success via the TPF Events group. Frankly this is first time I hear perl is dead and comparing it to long-dead languages seems for me a bit strange. Especially given Perl has production-ready web application container (mod_perl) - such a popular technology nowadays %) -- Looking forward to reading yours. Ruslan N. Marchenko
Re: What hurts you the most in Perl?
Books of this sort in general are fewer due to the web. Sent from my BlackBerry® smartphone with Nextel Direct Connect -Original Message- From: Octavian Rasnita orasn...@gmail.com Date: Thu, 2 Dec 2010 02:14:47 To: Dave Rolskyauta...@urth.org; Lylewebmas...@cosmicperl.com Cc: module-authors@perl.org Subject: Re: What hurts you the most in Perl? From: Dave Rolsky auta...@urth.org We hear the same argument in reverse that people should work on Perl 5 instead of Perl 6, as if the people who are working on Perl 6 would _of course_ be working on Perl 5 if 6 didn't exist. There's no reason to think this is true, and many reasons to think it's not. Many Perl 6 people never contributed to Perl 5 the way they do with 6. Maybe there are others that said that, but I have said something related and I want to be more clear. I said that because Perl 6 was announced 10 years ago, in the latest years there were very few Perl 5 books published, so I was referring only to the work of creating books. This is true, but I don't know, maybe I am wrong and there are other reasons for which there are fewer Perl books in the last period, not only because the interest for Perl 5 decreased... Octavian
Re: What hurts you the most in Perl?
On Mon, 29 Nov 2010 19:08:46 -0500, Sven Dowideit svendowid...@home.org.au wrote: out of curiosity, did you try Devel::Leak::Object ? http://search.cpan.org/~adamk/Devel-Leak-Object-1.01/lib/Devel/Leak/Object.pm No, I didn't find that one. When I was tracking down a leak somewhere in foswiki, i added some functionality to AdamK's module (which he's now released) and it found them for me pretty quickly. I had no idea where the problem would be, and did suffer from a few false positives, but it did solve the issue. The documentation is brief, but it does paint a very pretty picture. I'll pass it along to the guy who took over the bug from me after I hacked in an ugly but temporarily-effective solution. Thanks -- Paul (PWBENNETT)
Re: What hurts you the most in Perl?
On Nov 29, 2010, at 6:52 PM, Bill Ward wrote: What hurts me is that Perl has fallen out of favor so much ... I'm contemplating jumping ship myself, and moving to Ruby or Python, not because of anything intrinsic to the language but just because Perl is going the way of Cobol or Fortran. In the early stages of my last big Perl project, a sysadmin happened to mention to the non-technical project lead that Perl is a dead language. While that clearly was (and is) a falsehood, it nearly killed the project. To me, the mere *perception* that Perl is a troubled platform hurts the most. The funny thing, though, is that I've never worked in a language that hasn't been maligned by my peers or customers at some point. Perl, C, C++, csh, Java, Actionscript, Python, Lisp, PHP, VB, Javascript, etc -- it always seems like there's someone in a position of authority who wants to trash-talk the technology. Why is that? Chris
Re: What hurts you the most in Perl?
On Tue, Nov 30, 2010 at 5:36 PM, Chris Dolan ch...@chrisdolan.net wrote: On Nov 29, 2010, at 6:52 PM, Bill Ward wrote: What hurts me is that Perl has fallen out of favor so much ... I'm contemplating jumping ship myself, and moving to Ruby or Python, not because of anything intrinsic to the language but just because Perl is going the way of Cobol or Fortran. In the early stages of my last big Perl project, a sysadmin happened to mention to the non-technical project lead that Perl is a dead language. While that clearly was (and is) a falsehood, it nearly killed the project. To me, the mere *perception* that Perl is a troubled platform hurts the most. Yeah, whenever I tell people I write Perl I often get the response people still use that? The funny thing, though, is that I've never worked in a language that hasn't been maligned by my peers or customers at some point. Perl, C, C++, csh, Java, Actionscript, Python, Lisp, PHP, VB, Javascript, etc -- it always seems like there's someone in a position of authority who wants to trash-talk the technology. Why is that? Programming languages are like religions. People invest so much time in a language they feel that it is inherently superior to the alternatives. The reality is, any of us can pick up a new language in a few weeks if we work full-time at it.
Re: What hurts you the most in Perl?
languages, for example by Python is very low; - Because we all hope that Perl 6 will make our life easier (soon, on the Christmas :) there are fewer and fewer Perl 5 books published, and perldoc is not enough in case of many Perl modules. For example the documentation for WxPerl is very poor; - A big problem which hopefully will be solved by Perl 6 is that Perl 5 offers a very poor support for Windows threads - they consume a lot of resources and the objects can't be share among threads...; - It also hurts that there are no many well known projects in Perl anymore. Even the Perl projects use Mailman which is written in Python, MediaWiki written in PHP, I also use Mercurial (written in Python) as a source control system because GIT is not very compatible with Windows command prompt, Bazaar source control is also written in Python, SVK source control which is written in Perl was abandoned, there are even 2 screen readers one for Windows and one for Linux (made by Sun) written in Python, and it would be very hard if not impossible to write such a thing in Perl. Wordpress written in PHP is also much well known and used than Movable Type...; - The POD syntax looks worse than the syntax of the documentation used by other languages because of its notation and lots of empty lines. If there would be a good and portable IDE for Perl that could hide the documentation when not needed, it wouldn't be such a problem; - There is no good and recommended Perl distribution for Windows yet. I have tried to install DBD::Oracle under Strawberry Perl (after someone else also tried) but without success until now and I have also tried to install latest version of Padre under ActivePerl without success, so I can't really follow the recommendation of using Strawberry Perl and it is also not very nice to maintain 2 Perl distributions on the same machine; - Another thing that hurts in Perl and which is also a reason why many programmers don't like Perl is that it is not possible to install an application to a server by just uploading the files there and give some permissions, especially if that app uses XS, and not everyone has access to a shell; - CPAN is also great, but it is the haystack that contains too many needles, beeing hard to find which of them is the wanted one, and the Perl productivity decreases with the time of finding the right modules; Octavian - Original Message - From: Chris Dolan ch...@chrisdolan.net To: Bill Ward b...@wards.net Cc: Gabor Szabo szab...@gmail.com; module-authors@perl.org Sent: Wednesday, December 01, 2010 3:36 AM Subject: Re: What hurts you the most in Perl? On Nov 29, 2010, at 6:52 PM, Bill Ward wrote: What hurts me is that Perl has fallen out of favor so much ... I'm contemplating jumping ship myself, and moving to Ruby or Python, not because of anything intrinsic to the language but just because Perl is going the way of Cobol or Fortran. In the early stages of my last big Perl project, a sysadmin happened to mention to the non-technical project lead that Perl is a dead language. While that clearly was (and is) a falsehood, it nearly killed the project. To me, the mere *perception* that Perl is a troubled platform hurts the most. The funny thing, though, is that I've never worked in a language that hasn't been maligned by my peers or customers at some point. Perl, C, C++, csh, Java, Actionscript, Python, Lisp, PHP, VB, Javascript, etc -- it always seems like there's someone in a position of authority who wants to trash-talk the technology. Why is that? Chris
Re: What hurts you the most in Perl?
[BTW, I'm wondering if this thread should be moved to advocacy] Nicholas Clark n...@ccl4.org writes: On Sun, Nov 28, 2010 at 08:03:54PM -0800, Jarrod Overson wrote: Once a full rewrite is on the table it's hard for a team and/or company to not at least question whether or not perl is the right language to use going forward. For almost every project i've worked on in the past several years, it hasn't. Good perl programmers are hard to find and keep and the bad ones write the code that eventually has to get rewritten. And that isn't true for any other language? Yes. A company not a million miles from me (but more than 1000) has just written a disaster, in Java. And I'm curious in a couple of years how the majority of recently written Rails apps turn out. (Particularly Rails, because it's rapidly become very trendy, which means that demand for programmers will have outstripped experience with it) Very true. Nevertheless most people/companies will want to have functionality that works, and they want it now. If someone steps up and says I'll do it, in time, at a competetive pricing noone will question the language and tools used to write it. Proof? VB, PHP, Ruby, and so on. Other people/companies have followed the strategy of going with future-proof new developments. So they migrated from Assembler to COBOL, from COBOL to C, 4Gen, Java, you mention it. Did they get better software? I have my doubts. Perl is not the best language for everything. Maybe not even the best language for anything. It's just fun to write... -- Johan
Re: What hurts you the most in Perl?
On Wed, 24 Nov 2010 10:54:31 -0500, Sébastien Aperghis-Tramoni sebast...@aperghis.net wrote: So I wonder what hurts *you* the most in Perl? In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. I have to second this. Trying to track down a memory leak recently in a fairly large and complex multi-fork()ing application left me with a bunch of modules that basically stated use this on the data structure or piece of code you already know to be leaking, and you'll get a lot of technical diagnostic information, but there seemed to be nothing I could just attach to the application in any way that would help me *find* the data structure or piece of code that was leaking. Coming up with unit tests that were complicated enough to stably reproduce the condition essentially boiled down to rewriting the entire application from scratch in a TAP-oriented way. -- Paul (PWBENNETT)
Re: What hurts you the most in Perl?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 out of curiosity, did you try Devel::Leak::Object ? http://search.cpan.org/~adamk/Devel-Leak-Object-1.01/lib/Devel/Leak/Object.pm When I was tracking down a leak somewhere in foswiki, i added some functionality to AdamK's module (which he's now released) and it found them for me pretty quickly. I had no idea where the problem would be, and did suffer from a few false positives, but it did solve the issue. Sven On 29/11/10 23:59, Paul Bennett wrote: On Wed, 24 Nov 2010 10:54:31 -0500, Sébastien Aperghis-Tramoni sebast...@aperghis.net wrote: So I wonder what hurts *you* the most in Perl? In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. I have to second this. Trying to track down a memory leak recently in a fairly large and complex multi-fork()ing application left me with a bunch of modules that basically stated use this on the data structure or piece of code you already know to be leaking, and you'll get a lot of technical diagnostic information, but there seemed to be nothing I could just attach to the application in any way that would help me *find* the data structure or piece of code that was leaking. Coming up with unit tests that were complicated enough to stably reproduce the condition essentially boiled down to rewriting the entire application from scratch in a TAP-oriented way. -- Paul (PWBENNETT) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz0QIsACgkQPAwzu0QrW+moBgCgh7iXVaacpFo/Ze8Nl5ziiUv5 +xwAnjxxuK+kztEoWNo+AqXGtx49a7UO =y1vv -END PGP SIGNATURE-
Re: What hurts you the most in Perl?
What hurts me is that Perl has fallen out of favor so much ... I'm contemplating jumping ship myself, and moving to Ruby or Python, not because of anything intrinsic to the language but just because Perl is going the way of Cobol or Fortran. On Wed, Nov 24, 2010 at 4:01 AM, Gabor Szabo szab...@gmail.com wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. So I wonder what hurts *you* the most in Perl? Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/ -- Check out my LEGO blog at http://www.brickpile.com/ View my photos at http://flickr.com/photos/billward/ Follow me at http://twitter.com/williamward
Re: What hurts you the most in Perl?
The inability for an IDE to help me thoroughly refactor code is the biggest problem for me. With new code written with modern perl practices in mind, it's not as big of a dea (though worse than other languages)l; with code written 5-10 years ago though, it is a massive problem. Couple that with massive dependency lists for some of the newer frameworks and you need to decide whether or not a full rewrite from scratch on an up-to-date perl isn't the cleaner option. Once a full rewrite is on the table it's hard for a team and/or company to not at least question whether or not perl is the right language to use going forward. For almost every project i've worked on in the past several years, it hasn't. Good perl programmers are hard to find and keep and the bad ones write the code that eventually has to get rewritten. -- Jarrod. On Nov 24, 2010 4:01 AM, Gabor Szabo szab...@gmail.com wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. So I wonder what hurts *you* the most in Perl? Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/
Re: What hurts you the most in Perl?
The biggest problem with fork() is communication between the child and parent. For that, you need Inter-Process Communication (IPC). This is why we have threads. In general one has kernel threads and user threads. The scheduler is aware of the former not the latter therefore blocking on an event in latter blocks the whole process. Threads in Perl are an evolving technique. What was in 5.6 isn't used in 5.12. Sent from my BlackBerry® smartphone with Nextel Direct Connect
Re: What hurts you the most in Perl?
Paul LeoNerd Evans wrote: On Wed, Nov 24, 2010 at 04:54:31PM +0100, Sébastien Aperghis- Tramoni wrote: In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. Have you tried either Test::Refcount Test::MemoryGrowth Didn't see these. But one of my problems is that the programs I wanted to debug are daemons or code running in an embedded Perl (within Nagios in my case). Many of the existing tools rely on eval'ing the code or rely on an END block being executed, making them a bit hard to use in the case of embedded code.. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: What hurts you the most in Perl?
The point of threads is shared address space. They are lighweight and fast to create. It isn't just parallel processing with fork a new process. Please understand what threading is ntended to provide before you make recommendations to do something else nstead. Sent from my BlackBerry® smartphone with Nextel Direct Connect -Original Message- From: Todd Rinaldo to...@cpanel.net Date: Fri, 26 Nov 2010 10:20:24 To: Sébastien Aperghis-Tramonisebast...@aperghis.net Cc: Gabor Szaboszab...@gmail.com; module-authors@perl.org Subject: Re: What hurts you the most in Perl? On Nov 24, 2010, at 9:54 AM, Sébastien Aperghis-Tramoni wrote: Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. When in need to execute things in parallels, I use fork() or POE. I love the fork module. It's great how it's a drop in replacement for the threads module. It allows me to easily swap over to threads when I move code over to a machine that can use threads. I very much wish, however, that forks could get a return variable from the fork process like threads can. This has always frustrated me. To be honest, though, the fact that Linux forks are copy on write, takes much of the value out of threads as far as I'm concerned.
Re: What hurts you the most in Perl?
On Nov 24, 7:54 am, sebast...@aperghis.net (Sébastien Aperghis- Tramoni) wrote: [...] the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. Allow me to recommend my own Test::Weaken. This is powerful enough that it has found a bug in Perl itself. It has received a lot of use for debugging Gtk2, so much so there's a spinoff: Test::Weaken::Gtk2. Test::Weaken works by creating weak references, then freeing the original memory objects. If all is working, and the original memory objects went away like they should, the weak references will now be undefined. If there are leaks, the weak links will point to the leaked memory. Jeffrey Kegler
Re: What hurts you the most in Perl?
On Wed, Nov 24, 2010 at 04:54:31PM +0100, Sébastien Aperghis-Tramoni wrote: In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. Have you tried either Test::Refcount Test::MemoryGrowth ? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: What hurts you the most in Perl?
On Nov 26, 2010, at 5:24 AM, Paul LeoNerd Evans wrote: On Wed, Nov 24, 2010 at 04:54:31PM +0100, Sébastien Aperghis-Tramoni wrote: In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. Have you tried either Test::Refcount Test::MemoryGrowth I like this one for finding design flaws in complicated data structures: Test::Memory::Cycle Chris
Re: What hurts you the most in Perl?
On Nov 24, 2010, at 9:54 AM, Sébastien Aperghis-Tramoni wrote: Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. When in need to execute things in parallels, I use fork() or POE. I love the fork module. It's great how it's a drop in replacement for the threads module. It allows me to easily swap over to threads when I move code over to a machine that can use threads. I very much wish, however, that forks could get a return variable from the fork process like threads can. This has always frustrated me. To be honest, though, the fact that Linux forks are copy on write, takes much of the value out of threads as far as I'm concerned.
Re: What hurts you the most in Perl?
On 10-11-26 11:20 AM, Todd Rinaldo wrote: I love the fork module. It's great how it's a drop in replacement for the threads module. It allows me to easily swap over to threads when I move code over to a machine that can use threads. I very much wish, however, that forks could get a return variable from the fork process like threads can. This has always frustrated me. To be honest, though, the fact that Linux forks are copy on write, takes much of the value out of threads as far as I'm concerned. Sorry but fork(2) has been around longer than Perl. It is not something new but something very, very old (that's computer old, not human old). In Perl, fork() does return a value: * if it fails, undef * for the child process, zero * for the parent, the process-ID (pid) of the child With the child's pid returned to the parent, the parent can monitor the child and perform tasks on its completion. The biggest problem with fork() is communication between the child and parent. For that, you need Inter-Process Communication (IPC). See `perldoc perlipc`for details. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. The secret to great software: Fail early often. Eliminate software piracy: use only FLOSS.
Re: What hurts you the most in Perl?
On Fri, 26 Nov 2010, Shawn H Corey wrote: Sorry but fork(2) has been around longer than Perl. It is not something new but something very, very old (that's computer old, not human old). He's talking about forks.pm - http://search.cpan.org/dist/forks/ -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: What hurts you the most in Perl?
On Fri, Nov 26, 2010 at 11:20 AM, Todd Rinaldo to...@cpanel.net wrote: I very much wish, however, that forks could get a return variable from the fork process like threads can. This has always frustrated me. To be honest, though, the fact that Linux forks are copy on write, takes much of the value out of threads as far as I'm concerned. See Parallel::Iterator for an example of how to do this. It pipes data to the child process and reads back a result. -- David
Re: What hurts you the most in Perl?
Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. When in need to execute things in parallels, I use fork() or POE. 2) Using signals and signal handlers regularly crashes perl. I don't remember seeing regular crash because of signals. I even wrote some badly designed daemons which relied on a heavy use of signals. They had bugs, but not because of the signals per se. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. I still have not been bitten yet by this. Probably because I don't have heavy OO needs. And if I did, I would now use Moose. So I wonder what hurts *you* the most in Perl? In terms of Perl itself, apart from the reference syntax, the thing that really annoyed me recently was the lack of advanced debug tools, for example to find memory leaks. None of the tools I found or was pointed to worked in my case. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
What hurts you the most in Perl?
The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. So I wonder what hurts *you* the most in Perl? Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/
Re: What hurts you the most in Perl?
On Wed, Nov 24, 2010 at 7:01 AM, Gabor Szabo szab...@gmail.com wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. Out of curiosity, do you know what version of Perl they were running? With respect to #1, I'd like to see more energy around lightweight processes. E.g. what can we steal from Erlang. Parallel::Iterator is a nice example of what can be done using processes instead of threads, but it's not a general solution. With respect to #3, it doesn't sound like a technical objection, but a style objection. There is pretty much no privacy in perl at all -- it has nothing to do with objects. Even inside out objects can be defeated with PadWalker. I think the only option to overcome an objection like that is to attempt to demonstrate the benefits of flexibility to choose the right OO system for a particular purpose. Need stronger encapsulation, look at Class::InsideOut or Object::InsideOut. Want a powerful (if slowish) post-modern OO framework, choose Moose. Etc. -- David
Re: What hurts you the most in Perl?
On Wed, Nov 24, 2010 at 07:26:27AM -0500, David Golden wrote: On Wed, Nov 24, 2010 at 7:01 AM, Gabor Szabo szab...@gmail.com wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. 2) Using signals and signal handlers regularly crashes perl. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. Out of curiosity, do you know what version of Perl they were running? Because #2 sounds like it's pre 5.8.1 Nicholas Clark
Re: What hurts you the most in Perl?
On 24/11/10 12:01, Gabor Szabo wrote: The other day I was at a client that uses Perl in part of their system and we talked a bit about the language and how we try to promote it at various events. Their Perl person then told me he would not use Perl now for a large application because: 1) Threads do not work well - they are better in Python and in Java. I don't use threads, if there is a need to run parallel operations I use fork. 2) Using signals and signal handlers regularly crashes perl. I've not seen this. There are some issues I've seen with signals when a Perl module depends on non-Perl library and that defines signal handlers e.g. DBD::Oracle and Oracle's instant client - there is even a recent thread on dbi-dev about this. 3) He also mentioned that he thinks the OO system of Perl is a hack - that the objects are hash refs and there is no privacy. As David said, I don't really see a good technical argument here, more a personal one. So I wonder what hurts *you* the most in Perl? 1. Interfaces from Perl to C libraries via XS. Memory leaks, signal issues (above), seg faults, changes in PERL_POLLUTE which has knock-on effects to every XS module. Many are coding errors but these seem more common in XS and harder to find/fix. 2. huge dependency trees which are often moving targets e.g., module A needs modules B..Z, module B needs module BB which needs BC..BZ and then module BZ is changed to need Perl 5.10.1 and suddenly anyone using module B, BB or A needs 5.10.1. I have seen this one (although I cannot remember where right now) but it is not that uncommon to see more minor dependency changes that have large knock-on effects. 3. modules dying with insufficient details to see what went wrong without resorting to a debugger. 4. modules which fail tests and are at the bottom of a long module list chain. 5. modules with little or no documentation for a minimum of the most common usage cases. 6. HTTP/FTP modules (or modules using them) which don't handle env_proxy - particularly annoying as I am behind a firewall most of the time. 7. modules which prompt during install but don't use prompt so they don't work in non-interactive sessions (I've even come across some which loop forever in non interactive sessions). Saw a lot of this when I was smoking. Do I report any of this to the authors? mostly, but sometimes I do just move on and find something else. In particular, when I was running a smoker I used to report 6 and 7 a lot but hit them so often my patience waned and I started adding them to the ignore list (IIRC Apache::* had a lot of 7's.) Perhaps this is sounding a little grouchy and it is not intended to - you did ask. There are a lot of very good modules (and I greatly appreciate them and the work their authors do) but I'm not sure everyone adding a dependency to their module thinks so carefully about it and the implications if that module is changed a lot or tends to fail tests. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
