On Fri, Feb 11, 2000 at 10:02:11AM +0000, "Martyn Pearce" wrote: > Mark Mielke writes: > | I never suggested that backwards compatibility be sacrificed. I suggest > | that the code should eventually be fixed. MajorDomo is one of those tools > | that hasn't been touched in years (unless I'm wrong here), and NEEDS > | some clean up. > Hm, I'm missing some logic here: > 1) MajorDomo you've heard of and are familiar with. Therefore, I > deduce, you are using it. Thus, it is useful. It was useful. Now, anybody with any sense of project management would never choose it as a mailing list agent BECAUSE it is no longer being maintained. Ever heard of having too many dependencies? Especially ones without any sort of guarantee on them? > 2) It hasn't been touched in years (you think). I deduce that it > is is operating within acceptable bounds. The "you think" part is only because I know that as of a few months ago there were many people trying to decide whether to re-write the thing, or what, because several things in it _are_ "broken" (less than adequate). If a new maintainer has taken over it in very recent history, I am unaware of this, but I'm sure it would be quite appreciated by many. > So, why does it "NEED" some clean up? Ain't broke, don't fix, yadda > yadda. What a myth for the lazy programmer... :-) All software has a maintenance cycle, and all software eventually becomes obsolete unless it evolves with the times. Imagine perl had stayed at perl4.036? "If it ain't broke don't fix it" huh? Or perl3 even? > This may seem trivial and/or obvious, but is one of the underpinning > concepts supporting the backward compatibility police. I'm quite sure I > don't fancy the task of maintaining working code: i've got quite enough > broken code to keep me amused. > Mx. Gads... I never suggested breaking backwards compatibility... haha. Get off your beef with me... :-) There is a difference between breaking compatibility and encouraging people to upgrade. Evolution of a language is wonderful, but eventually, backwards compatibility SHOULD be broken, just to reduce code bloat. If the user wants to use perl3 features, then they can keep their perl3 binaries. Deprecation is along this path, just taking it easy on the poor coders. Encouraging them to fix code is just one step before deprecation, meaning that they have lots of time to upgrade it. I can honestly tell you now that I haven't seen one bit of perl4 code that couldn't be better and more cleanly written in perl5. mark -- markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | SIR Tools (7H12) |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/