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/
