develooper Front page | perl.perl5.porters | Postings from February 2000

Re: use octets; and "escaping the piranha's"

Mark Mielke
February 11, 2000 08:59
Re: use octets; and "escaping the piranha's"
Message ID:
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.


-- __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | 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...

                  Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About