From everything I've been learning about Raku, it's a wonder it isn't adopted more readily. It will fix multiple problems for me with my coding, unicode being just one of them. I also very much like the named function parameters that it allows, as for me this will also be a major improvement, not needing to put everything into a hash of variables to be passed, only a portion of which are actually required for a particular subroutine (versus creating a unique hash just for each subroutine--an even worse option). Up to now, I've been forced to maintain a strict ordering of parameters, and many of my subroutines have so many parameters as to make such code a nightmare to maintain or amend. It would be no better at all with the present Perl 5 way of handling so-called "named" parameters--which is basically just to pass them in in hash form. For my code, quite a few subroutines would have parameter lists longer than the rest of their internals, which makes the code excessively bloated to be readable--if one still considers it readable.
But Perl 5 is simply not the best tool for those working with unicode characters on a daily basis. Even the Perl manual which I have in hardcopy form says this:
In the case of Unicode, we must suffer the migration from byte semantics to character semantics. Since, through an accident of history, Perl was invented by an American, Perl has historically confused the notions of bytes and characters. In migrating to Unicode, Perl must somehow unconfuse them. (Programming Perl, p. 402)Unfortunately, in all flavors of Perl 5, this confusion is still very much an issue for the programmer, who must be meticulous about keeping track of proper encodings for all I/O.
Blessings,
~Polyglot~
In reply to Re^6: Converting Unicode
by Polyglot
in thread Converting Unicode
by BernieC
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |