Shlomif's Technical Posts Community - Changing the Seldon Plan [entries|archive|friends|userinfo]
Shlomif's Technical Posts Community

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| Shlomi Fish's Homepage Main Journal Homesite Blog Planet Linux-IL Amir Aharoni in Unicode open dot dot dot ]

Changing the Seldon Plan [Nov. 27th, 2009|05:46 pm]
Previous Entry Add to Memories Share Next Entry

shlomif_tech
[shlomif]
[Tags|, , , , , , , , , , , , ]
[Current Location |Home]
[Current Music |The Pretenders - Hymn to Her]

In Isaac Asimov's book "Second Foundation", the second foundation are in charge of the Seldon Plan, the grand "psychohistory" plan for the advancement of the galaxy, and one thing that is mentioned there is that it should by no means be considered holy and that changing it according to the circumstances is expected and even necessary. This mentality has an affect on us as open-source programmers, who should do our best to remedy bad open-source code as we find it.

Recently, in the Perl world there has been a continuous trend to shift from Ancient Perl to Modern Perl, and often people ask for our help on Perl 5 code they found (possibly on CPAN - possibly elsewhere) with "Ancient Perl" paradigms. That doesn't necessarily mean that Perl 5 code is very old, because often people who wrote it didn't know any better, and there are plenty of Perl 5 (or even Perl 4) tutorials or books still floating around the Net teaching bad practices. As a result, we normally tell them to either abandon or convert the code completely for a better trusted and more modern CPAN module, or alternatively to modernise it.

So far, so good. However, some people who've asked for us help said something like "I do not consider myself capable of rewriting his module and [it] has demonstrated robust stability over the years [so] I have little reason to.". So essentially, all the comments that we have given on it were dismissed due to apparent lack of competency on the part of the code's end-user, and that Ancient Perl code will still linger in use. The link I gave is not the only place where I saw it - I also saw it in at least another place (though I think it was on IRC).

I think that this spirit stands in opposition to the spirit of open-source and possibly even the Hacker Ethos. By all means, if we consider all the millions of lines of open-source out there as the Seldon Plan which powers all the open-source programs in use, and empowers us and end-users, then we should not feel detrimental or afraid to change the code that we use everyday. And people should not deploy code that they are not confident enough in changing, modernising and adapting to their needs.

One cannot usually expect code to remain the same forever. As time progresses, we can expect there to be code rot, features that needs to be added, tests that need to be added, or as is often the case in Perl 5 and other languages, paradigms that are considered to be bad and that should be changed to newer and safer paradigms. If you're lucky, the original developer or a co-maintainer can do that for you, but sometimes an end-user needs to stand up and volunteer to do that.

The open source nature of "Free and Open Source Software" permits everybody to create derivative works of the software and distribute them. So we don't have legal reservations from improving them and contributing our improvements to the general public, and should not have any moral or ethical ones, either. "Hacker sees bug. Hacker doesn't want bug. Hacker fixes bug.".

LinkReply

Comments:
From: (Anonymous)
2009-11-28 09:56 am (UTC)

You seem to forget...

(Link)

...that "if it ain't broke, don't fix it" is also part of the hacker ethics. Modernizing a module for the sole sake of modernizing it -- without any evidence of actual problems in it -- sounds like a bad idea, worthy of Joel's famous "Don't throw out the code" admonition.
From: szabgab.myopenid.com
2009-11-28 05:57 pm (UTC)

Re: You seem to forget...

(Link)

And I thought that is what one would call refactoring
[User Picture]From: shlomif
2009-11-30 07:41 pm (UTC)

Re: You seem to forget...

(Link)

Hi!

First of all, I should note that szabgab responded below and expanded on it on his blog where he got some comments.

First of all I should note that ESR does not mention "If it ain't broke, don't fix it." in his summary of the hacker's ethos (link above). That put aside, it is my belief that if you can invest enough time, you should make sure your code (in whatever programming language or technology that you are using) will follow the best practices. Naturally, and I didn't mention that, you likely need to juggle some other priorities, and cannot spend 100% of your time refactoring and modernising. However, you should invest time doing that because, like Martin Fowler says in his "Refactoring" book, refactoring is a practice that programmers have been doing because it allows them to write code faster and save time in the long run. Without refactoring, the code deteriorates into a very ugly mess, that is hard to maintain, harder to salvage and often becomes non-functional and buggy.

The same is also true on modernising Perl 5 code. Modern Perl has evolved from (and is still backwards compatible to) Perl 1 through Perl 5, and many of features that are still maintained will be happily executed by the interpreter, but are no longer advisable. Doing open FH, $filename is unsafe and wrong, and code without use strict; and use warnings; is also prone for many subtle and hard to catch bugs upon modification. There is no good reason to invest the necessary time and remedy them, assuming you do.

The first point I was trying to convey was that you should be confident enough and willing to refactor and modernise Perl code as you encounter it. The person who asked for help in my link did not lack the time to revamp the code - he just wasn't confident enough. While some ancient Perl code is still mostly working fine and can be left alone, you shouldn't still any bad code with an aura of holiness, especially not if you're seeking help with it.

I don't advocate throwing away working code, but even Joel on Software has advocated spending three weeks to refactor existing code, while preserving its integrity along the way. There's a huge difference between refactoring code, and rewriting it all from scratch.

I didn't intend to imply that you should stop everything you're doing right now and modernise and refactor all the Perl code you have and/or use to make it squeaky clean. But you do need to do it if you're constantly using or tweaking it, and please do it before and after you've asked the Perl experts for help on it, because we don't know where and how "ancient", non-idiomatic or inelegant Perl code will break, and we care too much about code craftmanship. The issues being discussed are not unique to Perl, but they influence Perl to a possibly larger extent.