Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Hi Ovid!

    I just returned from work when I saw your message and I can understand it and relate to it. There may be one of the so-called "anti-patterns" [wikipedia.org] about this, but since there are quite a few of them, I'm not sure if it will be easy to find. I'm not much of a pattern/anti-pattern freak myself (as I like to think of good solutions to problems when they are needed, and not waste precious memory remembering tons of patterns), but there are people who are more into this kind of thing. I can try asking someone I know (even IRL) who is a pattern-freak and see if he can recall anything.

    While this is obviously a bad pattern, I think that refactoring is generally touted to be done in small steps where none of the steps break the behaviour of the program. Martin Fowler's "Refactoring" book contains some large-scale refactorings which aren't like that, but that's usually a rare case.

    I think the main problem here is not in coding, but in management. If the management does not allocate enough time for programmers to finish refactoring, then it's a problem with the management. I'm pretty sure there's a "We-shouldn't-do-any-refactoring" or "We don't have time for refactoring" anti-pattern. Usually such management will get the project to crash and burn.

    I personally believe that as long as the code works and is mostly bug-free, it can almost always be salvated (i.e: refactored and then extended). There were some successful rewrites, mainly in the open-source world, but I was never involved in that particular stage of one to know if they were completely justified.

    One pattern I've been doing to some extent, which is different than that is something I call "lazy refactoring" or "just-in-time" refactoring. (for not knowing the correct terminology). What I do is refactor the program just enough to accomodate for a change while leaving other (none-critical) issues in place. I've successfully used this to develop Freecell Solver [berlios.de], which I wrote from scratch in C, and then heavily extended, enhanced and optimised in future releases. While sometimes I did a lot of refactoring, I often did just enough refactoring or generalisation to later implement a certain enhancement.

    At present, the code still has some issues, but it's still in a shape that can accomodate later changes. I've received some negative criticism about it from people who read it and tried to understand it claiming it was badly written. To my critique, I agree that it's unreadable and sometimes possibly over-optimised (possibly even over-micro-optimised), but it is still in good shape.

    BTW, today we discussed the pro's and cons of the proliferation of programming languages on Freenode's #web channel. One item we touched upon is that there's a lot of "legacy" code out there, which may be too costy to rewrite. So for example there's a lot of COBOL code, which is still maintained, because people are afraid to rewrite it in something better. (albeit IMO rewriting COBOL code in Perl would be much easier than rewriting Python (for example) or even C code in Perl, because you can do much more in one statement of Perl than in one statement of COBOL). But still it's probably easier to maintain the code in COBOL at least for the short term.

    On the other hand, there's a lot of code in Perl and a lot of code in Python, and no-one wants to rewrite it from the "legacy" language to the "better" one, because it is easier to maintain it and extend it as is. As languages evolve and more powerful and more succint languages come up (I.e: C→Awk→Perl→Ruby→Perl 6), you still have the inertia not to re-implement all the code in the new language that's only slightly better. And eventually we get a COBOL-vs.-Perl 5 situation which seems incredibly ridicolous.

    One of the issues we discussed was whether this fragmentation between languages that are peers (i.e: offer much the same power and roughly the same succintness, but differ greatly, like Perl, Python, Ruby, Tcl and PHP) is a good thing and whether there is any hope of preventing it. The reason why it's not good is because it makes it harder to interoperate between codes written in different languages, and also encourages different implementations.

    I diverted a little bit, but I hope it's OK. Cheers, and thanks for sharing this thought with us.

    • Well, I talked with my "patterns" guy. He said that one may find what you're describing in the "Big Ball of Mud" [laputan.org] article that describes how a software project goes on to having a lot of bad code, possibly in terminal state. (Note that I have yet to read it)

      As for my "lazy refactoring" or "just-in-time refactoring" - he called that "continuous refactoring", or at least thought it was a good name for it, and said refactoring should be done at small, atomic steps. You can consult Joel on Software's Rub-a- [laputan.org]

      • You've nailed it. Originally I didn't think about that because I had the incorrect impression that a big ball of mud primarily referred to a reasonable system which decayed with age. From reading the first bit, I see that the BBOM also refers to what I described. I think I need to reread that article again. Thanks, Shlomi!