|From:||Aristotle Pagaltzis <pagaltzis-AT-gmx.de>|
|Subject:||Stop the presses! [was: Either clear the Unicode air--or make a release-blocker?]|
|Date:||Sun, 26 Feb 2012 06:32:41 +0100|
I shall address your concern here in roughly reverse order: * Tom Christiansen <email@example.com> [2012-02-25 23:35]: > Since we won't let either of those happen, I figure that either > > —— all #1 .. #9 of my numbered points above are completely safe and > proper, preferably always but minimally along with the #0 fatalization > > —— or else they need to be made so before we dare release v5.16. 5.16 *must* be released whatever the state of this issue. To not do so is to fall into the thinking and behavioural pattern that stifled the release of 5.10 by several years. Perl 5 switched to a timeboxed release cycle because “this one more thing has to be polished before we can ship it” meant it never shipped at all. It has been a rousing success. The key to said success is that no feature, no matter how exceptional it may appear, is special. If it isn’t ready in time, it can wait – because it will not have to wait long, because when time arrives for it to ship it will not have to wait for any *other* feature in turn, because none are exceptional. No matter how important any one particular issue may appear: for the new regime to work, none must be considered more important than the release schedule. The trains must run on time. > Why? Simple: remove those 9 simple ways to approach implicit Unicode > processing in Perl, and you so gut Perl's Unicode dwimmer that nobody > save the very most diligent and élite [sic] of Perl gurus will ever dare > use Perl with Unicode. That would be tragic, maybe disastrous even. I am rather more sanguine about that. Let me help you relax by giving you the reason – two of them, in fact. Firstly: > We should not have to endure five more tedious years of people getting > tonguelashed and flamenagged into writing horribly complicated code > all because something deep down in Perl's dwimmer is flawed. > > I say five years, not one year, because of how long it takes to get > vendors to get themselves updated. If this is a legit issue, and we > push it off till 2013's v5.18, then it will be a further 2–4 years > past that until people can have reasonable Unicode processing in their > vendor Perl. That puts us into the 2015–2017 (!) time frame, and... > that's just not acceptable, eh? You ignore here that by this calculation, the question is *only* whether the 4-year trickle-down process starts now or next year. Neither is there any (known) non-linear process at work that would make a delivery now trickle down much quicker than a delivery next year – the 4-year process is identical either way. So your worst-case scenario has to be compared against a parallel better case of 4 years. It is not “ship it this time and get it now or wait 5 years”: it is “ship it this time and get it in 4 years or leave it to be shipped next year and get it in 5, counting from now”. Accounting for constant factors, the difference between the scenarios is just 1 year, no matter what else the full process involves. Then the gravity of the decision to consider is the gravity of one year. Secondly: > By that time, one or both of two things will have happened. Either > untold zillions of lines of code will have been written that either > conform to this ridiculous amount of monkeywork, entrenching a bad > pattern forever, or else untold zillions of line of code will have > been written that ignore it and are themselves open to the kind of > spooky catastrophic failure that people allude to, thereby rendering > all Perl a security hole of Chicken Little proportion. This ignores a third option à la “use Try::Tiny until we have sane exceptions in core”. We have the CPAN. It is no alternative to fixing the core language – but *is* an alternative to copy-pasting workaround patterns all over code. And it can trickle out *much* faster than an update to the core ever will be able to. Since according to your premises we are looking at 4 years in the best-worst case, no matter how this plays out, then if the situation is as grave and perilous as it appears to you, maybe the thing to do is start to think *now* about how to create an interim DWIM solution that can live on CPAN. And incidentally, maybe it is also time to consider whether and where the points that utf8::all implicitly argues (by virtue of its existence) mean the design of the core language should be moving toward regarding Unicode. So with all that said, let us take a breath and focus on strategy, and leave the release schedule to care for itself. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds