in reply to Perl 5.20.0

Thanks for the heads-up, tobyink.

For me, the things that I found most interesting, was (as you mentioned); better UTF-8 support. Any improvements in this area come as welcomed news. It just seems so unnecessarily difficult, as it is.

The Better-64 bit support has some interesting points too:

the internal array functions now use 64-bit offsets, allowing Perl arrays to hold more than 2**31 elements
Now it'll be even easier to make poorly designed routines. ;)
The regular expression engine now supports strings longer than 2**31 characters.
WOW! This, I think, will be welcomed news to those working with huge database tables, and such.

Thanks again, tobyink.

--Chris

¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

Replies are listed 'Best First'.
Re^2: Perl 5.20.0
by Your Mother (Archbishop) on May 27, 2014 at 18:14 UTC

    Regarding better UTF-8, I don't think you're reading it the same way I am. Perl has long had the best Unicode support of any of the high level languages. The only changes I saw were an update to the current spec, which is to be expected and has been the norm, and some locale fixes which are welcome but locale is probably still a big global space mess everyone can avoid in code with proper encoding/decoding layers.

    So it hasn't been improved exactly. And it's as difficult, unfortunately, as it needs to be.

    I only mention this because a lot of the complaints I hear about an admittedly painful part of hacking seem to slight Perl. Perl is a shining handhold in a sea of muck WRT Unicode handling. It's not easy but it is in no way Perl's fault.

[reply]
[d/l]
[select]
      Thanks for the clarification, Your Mother.

      But please do note; I never intended to insinuate that Perl performed poorly, in any way, where UTF-8 was concerned. Only, that anything that might make the production of GOOD UTF-8, any easier, or more efficient. Was welcomed news. :)

      Thanks again.

      --Chris

      ¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH

[reply]

In Section Perl News