4 ms·

Perl 5 is the software equivalent of duct tape or superglue. Great for thousands of tasks you never really thought of and for lashing stuff together but just li

Perl 5 is the software equivalent of duct tape or superglue. Great for thousands of tasks you never really thought of and for lashing stuff together but just like you wouldn't use duct tape for building a house, you need to make sure you use Perl for the things its good at. That said Python is now getting close to usurping Perl as software superglue.

justinator 13y ago
The thing about metaphors is after awhile, they breakdown when you attempt to use them for all facets of a subject. Perl's used in large projects just fine, with similar problems found in all large projects. The solutions to those problems may be Perlish, but that's just rather than Rubyish or Python-ish, etc.
- spiralpolitik 13y ago
  In my experience when Perl is used in large projects it quickly becomes unmaintainable once the original developers move on. A lot of the recent work I've been doing has been migrating Perl projects to languages that are much more maintainable in the long term. While you can get the same problems with other languages, its much easier for a Perl project to disintegrate into anarchy even when careful managed.
  - kbenson 13y ago
    I suspect this is a problem with any project once the original developers move on and there's a break in institutional knowledge about the architecture and design reasoning behind a project. I also suspect it's more of a problem the more powerful the ability of the language to introspect and self-modify. Lastly, I suspect this is also paired with gains in efficiency in the design and implementation phase. If that's true, it's a matter of trade-offs, not a clear negative, and it becomes a matter of recognizing those downsides and dealing with them accordingly (whether that be avoiding certain features except where specifically called for, better documentation, or preventing that loss of institutional knowledge).
    - spiralpolitik 13y ago
      At least in the Enterprise world, the maintenance phase significantly outlasts the design and implementation phase in the majority of projects so any gains in those phases are usually dwarfed by the latter phases. The system I'm currently migrating has been in production for 10 years. The original developers are long gone, as are the generation after that. It's code archeology at its finest. As you say its a trade off, but IMHO its always better to pick maintainability over efficiencies in design and implementation for most long term projects. (Not you say can't write maintainable Perl, its just much more difficult than in other languages and requires a solid culture to support it).

justinator 13y ago

The thing about metaphors is after awhile, they breakdown when you attempt to use them for all facets of a subject. Perl's used in large projects just fine, with similar problems found in all large projects. The solutions to those problems may be Perlish, but that's just rather than Rubyish or Python-ish, etc.

spiralpolitik 13y ago
In my experience when Perl is used in large projects it quickly becomes unmaintainable once the original developers move on. A lot of the recent work I've been doing has been migrating Perl projects to languages that are much more maintainable in the long term. While you can get the same problems with other languages, its much easier for a Perl project to disintegrate into anarchy even when careful managed.
- kbenson 13y ago
  I suspect this is a problem with any project once the original developers move on and there's a break in institutional knowledge about the architecture and design reasoning behind a project. I also suspect it's more of a problem the more powerful the ability of the language to introspect and self-modify. Lastly, I suspect this is also paired with gains in efficiency in the design and implementation phase. If that's true, it's a matter of trade-offs, not a clear negative, and it becomes a matter of recognizing those downsides and dealing with them accordingly (whether that be avoiding certain features except where specifically called for, better documentation, or preventing that loss of institutional knowledge).
  - spiralpolitik 13y ago
    At least in the Enterprise world, the maintenance phase significantly outlasts the design and implementation phase in the majority of projects so any gains in those phases are usually dwarfed by the latter phases. The system I'm currently migrating has been in production for 10 years. The original developers are long gone, as are the generation after that. It's code archeology at its finest. As you say its a trade off, but IMHO its always better to pick maintainability over efficiencies in design and implementation for most long term projects. (Not you say can't write maintainable Perl, its just much more difficult than in other languages and requires a solid culture to support it).