Front page | perl.perl5.porters |
Postings from March 2000
More patching! Less whining!
From:
Tom Christiansen
Date:
March 31, 2000 21:24
Subject:
More patching! Less whining!
Message ID:
18319.954566629@chthon
>As for why it was released early
It wasn't. It was released late--about a whole year late.
See below for what I mean, and why.
>I have no idea, but wouldn't mind seeing
>this thread following to fruition.
I somewhat doubt that. The only thing fruity I've seen in this
thread is most of its postings, yours being far from the least
exaggerated in this regard.
>I am seeing companies and groups deny
>pressuring Sarathy for an early release. This is quickly becoming an
>_embarrassment_ to this group and the Perl community,
It is? Really? You're calling a working, dramatically improved,
and far more than simply timely release an EMBARRASSMENT? Surely
you jest! Does twitterpation run in neck of the woods? I haven't
checked the moon lately. Perhaps that's it.
I have not, to the best of my recollection, seen even a single
compatibility issue between the previous release and this one amongst
any one of the thousands or so Perl programs runig on my system,
nor even a burp in compiling any external module. While it is
possible of course possible that my memory is selective here, it
seems also possible that the faultometer points to the notion that
just maybe there's something wrong with *your* environment. The
build failures I've seen come in have all appeared to my casual
inspection ephemeral at worst. Again, I'm not Andy and such, so
that's not subject matter to quickly catch my eye.
As some of you have doubtless noticed, I've been stress-testing and
feature-testing various pieces of Perl. And guess what? Yep, some
things are broken! However did you guess? Now guess what else:
These things, nearly to the very last of them, have in fact *ALWAYS*
been broken! Why are you not excoriating the previous release
managers for having the temerity to emit a version of Perl that
was, in fact, imperfect?
I'll tell you why: because software has bugs. All software has bugs
and infelicities. It always has and it always will, and if you wait
until it doesn't, you're going to be wait a long, long time.
>and there seems no reason to doubt that this will worsen in a very
>short time.
Now you're simply being needlessly paranoid by spreading this sort
of silliness. *WHAT* is going to worsen? This non-existent
`embarrassment'? Well, feel free to embarrass yourself all you
want to, but this is a release whose contributors should be proud
of. Why? Because it's a *good* release, and it is far past time
that it were released to the world.
>I also suspect that the culprit will emerge shortly as well.
Perhaps so, but if that happens, there'll be no question whom to
blame: follow the hand that's holding the mirror.
Yes, that's right. The only `culprits' here are those very individuals
seeking to cast aspersions of negligence at precisely those targets
where such defamations are in fact the least called for. The sheer
mass of people who sit on their butts and expect somebody *else*
to slave away for them is astounding.
>There was also no warning that I've seen that 5.6 was an early beta, or
It wasn't.
>early-beta-ish, though that's certainly where it's stands.
You're wrong. As I shall presently prove.
>The Win32
>community is convinced that 5.6 is out, stable, and available only from one
>source.
And just whose fault might you be construing *that* to be? If the
helpless and hapless demand that all be handed them on a silver
platter because they are either too lazy or too incompetent to seek
their own solutions, how can you blame the hand that holds out a
platter to those bleating multitudes in such earnest need? There
is no guilt to distribute here. Nothing stops anyone from solving
their own problems, nor does it stop anyone else from becoming
>I would also qualify "stable" with the stability of the more popular
>modules, Tk, LibWin32, LibWWW, LibNet, GD, DB_File, and other biggies, many
>of which do not compile at all with 5.6 without "relatively minor tweaking".
You're fear mongering. There was one bug related to Tk. DB_File
is standard. LibWWW and LibNet have no problems. And I'll leave
the remaining crud to the already crudded to crud on their cruddy
own.
>Without these modules, Perl is not Perl.
Rubbish and poppycock. And less savory bits, too.
>I am at the dawn of the first
>official release of CodeMagic, Perl's only world-class editor at this time
HAHAHAHAHAHHAAHHAHHAHAHAHHAAHAHAAHAHAHHAHAH
Ok, I've nearly recovered from my uncontrolled paraxyms of streaming
hilarity, I have just one question for you, David. For just how
long have you had this obvious addiction to WORLD-CLASS HALLUCINOGENS?
>soon to go cross-platform, which depends on a stable Perl as a backbone: and
>after officially declaring 5.6 ready, this group is now wondering why it was
>released at all so quickly?
It wasn't. It was released incredibly, unprecedentedly SLOWLY.
First of all, to the people who think there's nothing here that
merits a release: you're cracked.
It has been my perception--completely unverified, but nevertheless
my honest impression--that if one were to examine the changes
recorded in the 5.3-to-5.6 perldeltas, that one would find the
greatest functional distance between any pair of consecutive releases
to lie between 5.5 and 5.6. This might even be true all the way
back to 5.0.
Did you read these?
Core Enhancements
Interpreter cloning, threads, and concurrency
Lexically scoped warning categories
Unicode and UTF-8 support
Support for interpolating named characters
our declarations
Support for strings represented as a vector of ordinals
Improved Perl version numbering system
New syntax for declaring subroutine attributes
File and directory handles can be autovivified
open() with more than two arguments
64-bit support
Large file support
Long doubles
more bits
Enhanced support for sort() subroutines
C<sort $coderef @foo> allowed
File globbing implemented internally
POSIX character class syntax [: :] supported
Improved C<qw//> operator
pack() format 'Z' supported
pack() format modifier '!' supported
pack() and unpack() support counted strings
Comments in pack() templates
Weak references
Binary numbers supported
Lvalue subroutines
Some arrows may be omitted in calls through references
Boolean assignment operators are legal lvalues
exists() is supported on subroutine names
exists() and delete() are supported on array elements
Pseudo-hashes work better
Automatic flushing of output buffers
Better diagnostics on meaningless filehandle operations
Where possible, buffered data discarded from duped input filehandle
eof() has the same old magic as <>
binmode() can be used to set :crlf and :raw modes
C<-T> filetest recognizes UTF-8 encoded files as text
system(), backticks and pipe open now reflect exec() failure
Improved diagnostics
Diagnostics follow STDERR
syswrite() ease-of-use
Better syntax checks on parenthesized unary operators
Bit operators support full native integer width
Improved security features
C<require> and C<do> may be overridden
$^X variables may now have names longer than one character
New variable $^C reflects C<-c> switch
New variable $^V contains Perl version as a string
Optional Y2K warnings
Modules and Pragmata, new or improved
Modules
[zillions]
Pragmata
[various]
Utility Enhancments
dprofpp
find2perl
h2xs
perlcc
perldoc
The Perl Debugger
Improved Documentation
Performance enhancements
Simple sort() using { $a <=> $b } and the like are optimized
Optimized assignments to lexical variables
Faster subroutine calls
Installation and Configuration Improvements
-Dusethreads means something different
New Configure flags
Threadedness and 64-bitness now more daring
Long Doubles
-Dusemorebits
-Duselargefiles
installusrbinperl
SOCKS support
C<-A> flag
Enhanced Installation Directories
Platform specific changes
Supported platforms
DOS
OS390 (OpenEdition MVS)
VMS
Win32
Significant bug fixes
<HANDLE> on empty files
C<eval '...'> improvements
All compilation errors are true errors
Implicitly closed filehandles are safer
Behavior of list slices is more consistent
C<(\$)> prototype and C<$foo{a}>
C<goto &sub> and AUTOLOAD
C<-bareword> allowed under C<use integer>
Failures in DESTROY()
Locale bugs fixed
Memory leaks
Spurious subroutine stubs after failed subroutine calls
Taint failures under C<-U>
END blocks and the C<-c> switch
Potential to leak DATA filehandles
New or Changed Diagnostics
New tests
That's a smeg of a lot of feepers crawling up your trousers. Sure,
some of them are a bit shakey, but this is nothing new. What's
good enough? What do you bloody WANT, man? You want something
that never was nor shall ever be, that's what you want. Look here
at this, from perlhist:
5.0 1994-Oct-17
5.1 1995-Mar-13
5.2 1996-Feb-29 Prototypes
5.3 1996-Jun-25 Security Release
5.4 1997-May-15 Major Maintenance Release
5.5 1998-Jul-22 Oneperl.
El Zilcho All of 1999
More Nada? All of 2000
Is that really what you wanted recorded for 2000? More nothingness?
We have not had a new Perl release since July 22nd, 1998. Did you
realize that? By the time TPC4 gets here, there shall have passed
us by what is starting to approach a number perilously proximate
to TWO LONG YEARS of twenty four months (plus a rare leap day :-)
since our last release.
Why is that? What does it mean?
I believe I can tell you what it means: expectations are inappropriately
superset. Look at the notes next to those releases up there. These
releases do *not* need to completely change the whole world. In
fact, they oughtn't. If that's what they're expecting, then they're
expecting perl6, not perl5.6! And having everything and having it
perfect -- threads, events, signals, compilers, unicode, feep, feep,
feep -- such a thing does not deserve to be called 5.6 if the past
is to be any guide to the future.
Have you no sense of the past? Do you know how much work as gone
into it? Watch this. You'll see the patch rate (well, check-in
rate; some "patches" actually patch many files) over the last few
years:
1997 1998 1999 2000
03/97 4 01/98 59 01/99 212 01/00 187
04/97 4 02/98 156 02/99 312 02/00 441
05/97 16 03/98 230 03/99 187 03/00 520
06/97 7 04/98 68 04/99 52
07/97 9 05/98 159 05/99 212
08/97 4 06/98 203 06/99 49
09/97 40 07/98 407 07/99 279
10/97 104 08/98 102 08/99 208
11/97 144 09/98 118 09/99 200
12/97 50 10/98 267 10/99 236
11/98 236 11/99 97
12/98 122 12/99 144
Notice how the recent activity levels have set new records on
contributed changes. What more are you asking!? This has been on
the pot far too long, and lone Sarathy (admittedly with help on
some pieces from Jarkko, Andy, Larry, along with, I'm horribly sorry
to have to say, *depressingly* few others), has seemed, really, to
have by and large done nearly everything that's been getting done
in terms of the brandspanking new superfeature expansions all on
his very own. Certainly the unification and buck-stopping reside
at his doorstep. But continued expectations that Sarathy should
toil evermore to happify everyone's favorite feep are neither
charitable nor sustainable.
These inhuman expectations of perfection and infinite work from
folks sitting around on their thumbs and spining are just intolerable.
This is a volunteer organization! There's nobody you can sue, and
there's no one you can blame save YOURSELF for not having put in
the work. What did YOU work on? Did you break it? Did you fix it?
How long in your eyes should this terribly tardy release have sat
there stewing? What's good enough for you? Don't you think TWO
FRICKING YEARS was good enough? No release could EVER have seen
the light of day if were held to these insane criteria you apparently
expect to see met. It's never been that way before, and you're
positively pixilated to expect it now.
"Programs, like books, are never finished; they are merely
abandoned."
Eventually it comes time to tidy up the stray feathers and push the
fledgling out of the nest. It's finally been done, and thank
goodness for that! This is merely 5.6, not Perl6. It's just not
that big a deal, so get over it already. 5.6.1 will be along by
and by. Why aren't you working on it RIGHT NOW???
Less whining! More patching!
--tom