4 ms·

Why is it harder to maintain codebases in Perl if you follow the "Best Practices" book?

by berntb 17y ago

idlewords 17y ago
Several reasons: - sigils make it difficult to scan code - there is poor IDE support for perl - it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. - it's common to pass around a hashref (a.k.a. magic blob of data) as an argument. Finding out what the proper internal structure of this is can involve jumping around a lot of code - there can be spooky 'action at a distance' effects. For example, the URI module calls 'require' deep within a private internal class. This can crash your program if, for example, you've forgotten to properly implement the STORE method for a tied hash in a completely unrelated part of your program. For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. - not everyone has read the best practices book, including the authors of very widely used CPAN modules - Chasing up and down inheritance chains can be very unpleasant. See MovableType. Again, nothing wrong with Perl, it just has certain features that make it a bear to work with when the project size exceeds a certain threshold, or when there are multiple programmers.
- berntb 17y ago
  >- there can be spooky 'action at a distance' effects. Yeah, those are unique to Perl... :-) >- not everyone has read the best practices book True, it is unique that Perl has programmers which doesn't follow the coding standards of the group... :-) >- Chasing up and down inheritance chains can be very unpleasant. True, it is only Perl which have over complex OO libs. :-) >> For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. I don't know much about Unicode. You mean that using Unicode characters would require loading a library? Can you give a reference to that "three orders of magnitude"?! If you count the startup time of the lib as run time, I am disappointed. >- there is poor IDE support for perl Huh? Afaik that IDE from Activestate gets good reviews, but Perl programmers use Emacs (or Vim) anyway. Than we have Padre on the way. >- sigils make it difficult to scan code >- it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. (More or less the same point.) At least partly correct, I guess. I generally check the synopsis, first. Their existence probably comes from this. >- it's common to pass around a hashref (a.k.a. magic blob of data) ... Create an object, if it is complex. Edit: Moved answers to strange claims to top.
- berntb 17y ago
  Please answer this before I do recommendations... :-) >- there is poor IDE support for perl Komodo, the ActivesState IDE, is bad? I've only heard good things. I think there are some other products out there. Are they bad, too?
abalashov 17y ago
I think some of it stems from the fact that Perl's OO really is just a very, very fancy namespace hack, but one which allows deep introspection.
- berntb 17y ago
  Well, that was a serious point. :-) Moose is rapidly becoming a standard feature. It seems to be the state of the art for OO today (for mainline programming languages).
  - abalashov 17y ago
    I confess to fearing the complexity of the Moose.
    - berntb 17y ago
      The normal/common use is simple. The rest I hope to learn myself, with time. :-) The largest problem for now imho, is the startup time.
      - abalashov 17y ago
        That's the largest problem with anything. :(
        berntb 17y ago
        Huh, what are you doing where start up of processes are so critical? If you must have fast startup, use C. Or a client connecting to a running server. If you meant start up as in the learning process of learning some new library, well. I feel your pain. But that is the reason we do computers, isn't it? Always new stuff to learn, never ending...

Why is it harder to maintain codebases in Perl if you follow the "Best Practices" book?

by berntb 17y ago

Why is it harder to maintain codebases in Perl if you follow the "Best Practices" book?

Several reasons: - sigils make it difficult to scan code - there is poor IDE support for perl - it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. - it's common to pass around a hashref (a.k.a. magic blob of data) as an argument. Finding out what the proper internal structure of this is can involve jumping around a lot of code - there can be spooky 'action at a distance' effects. For example, the URI module calls 'require' deep within a private internal class. This can crash your program if, for example, you've forgotten to properly implement the STORE method for a tied hash in a completely unrelated part of your program. For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. - not everyone has read the best practices book, including the authors of very widely used CPAN modules - Chasing up and down inheritance chains can be very unpleasant. See MovableType. Again, nothing wrong with Perl, it just has certain features that make it a bear to work with when the project size exceeds a certain threshold, or when there are multiple programmers.

berntb 17y ago
>- there can be spooky 'action at a distance' effects. Yeah, those are unique to Perl... :-) >- not everyone has read the best practices book True, it is unique that Perl has programmers which doesn't follow the coding standards of the group... :-) >- Chasing up and down inheritance chains can be very unpleasant. True, it is only Perl which have over complex OO libs. :-) >> For another example, using unicode in a regex somewhere can cause files to be pulled from disk, suddenly slowing your app by three orders of magnitude. I don't know much about Unicode. You mean that using Unicode characters would require loading a library? Can you give a reference to that "three orders of magnitude"?! If you count the startup time of the lib as run time, I am disappointed. >- there is poor IDE support for perl Huh? Afaik that IDE from Activestate gets good reviews, but Perl programmers use Emacs (or Vim) anyway. Than we have Padre on the way. >- sigils make it difficult to scan code >- it can be very hard to figure out what arguments are being passed, or what arguments a subroutine or method expects. (More or less the same point.) At least partly correct, I guess. I generally check the synopsis, first. Their existence probably comes from this. >- it's common to pass around a hashref (a.k.a. magic blob of data) ... Create an object, if it is complex. Edit: Moved answers to strange claims to top.
berntb 17y ago
Please answer this before I do recommendations... :-) >- there is poor IDE support for perl Komodo, the ActivesState IDE, is bad? I've only heard good things. I think there are some other products out there. Are they bad, too?

abalashov 17y ago

I think some of it stems from the fact that Perl's OO really is just a very, very fancy namespace hack, but one which allows deep introspection.

berntb 17y ago
Well, that was a serious point. :-) Moose is rapidly becoming a standard feature. It seems to be the state of the art for OO today (for mainline programming languages).
- abalashov 17y ago
  I confess to fearing the complexity of the Moose.
  - berntb 17y ago
    The normal/common use is simple. The rest I hope to learn myself, with time. :-) The largest problem for now imho, is the startup time.
    - abalashov 17y ago
      That's the largest problem with anything. :(
      - berntb 17y ago
        Huh, what are you doing where start up of processes are so critical? If you must have fast startup, use C. Or a client connecting to a running server. If you meant start up as in the learning process of learning some new library, well. I feel your pain. But that is the reason we do computers, isn't it? Always new stuff to learn, never ending...