Re^4: length() miscounting UTF8 characters?

[raiph]

You seem to be thinking that Moritz is suggesting you use or look in to Perl 6. I'm pretty sure he is not.

Yes, Perl 6 does aim to enable working from the high-level perspective you describe.

No, it's not worth you looking in to Perl 6 if you just want to get stuff done and don't care to have fun figuring out how it works and contributing to the Perl 6 effort by fixing and working around bugs and speed problems etc.

Moritz mentioned Perl6::Str. This is a perl 5 module he wrote that must be used by perl 5 scripts. It is one of several perl (5) modules written by perl 5 programmers who chose to use the Perl6 namespace in CPAN to reflect the module being somehow related to Perl 6.

To quote the Perl6::Str module description:

Perl 5 offers string manipulation at the byte level (for non-upgraded strings) and at the codepoint level (for decoded strings). However it fails to provide string manipulation at the grapheme level, that is it has no easy way of treating a sequence of codepoints, in which all but the first are combining characters (like accents, for example) as one character.

Perl6::Str tries to solve this problem by introducing a string object with an API similar to that of Perl 6 (as far as possible), and emulating common operations such as substr, chomp and chop at the grapheme level. It also introduces builtin string methods found in Perl 6 such as samecase.

In summary, aiui: for production grade grapheme level handling, it's best to rely on perl 5, accepting all the intricacies and complications that inevitably arise; for some Perl 6 like features in perl 5 that attempt to hide some of that complexity (in trade for some loss of some magic and speed) you can consider Perl6::Str; and for the ideal simpler Unicode handling scenario you described, there's no better prospect than Perl 6 but it's not yet ready for most users and use cases.

[AppleFritter]

Ah, I see! Yes, I was thinking that he suggested I look into Perl 6. I didn't realize Perl6::Str was actually a Perl 5 module. Thanks for the correction of my assumption there!

This is perhaps veering off-topic, but since you mention "[getting] stuff done" (Perl 5) vs. "[having] fun figuring out how it works and contributing to the [...] effort by fixing and working around bugs and speed problems etc." (Perl 6) -- just how does Perl 6 really compare to Perl 5, then, how ready for production use is it? I keep getting conflicting information; on one hand there's advocates who will tell you that Perl 6 is Right Here to use, Right Now, while on the other you've got chronic naysayers making all sorts of disparaging statements.

I reckon the truth is somewhere in between, but-- where? Performance problems aren't a big deal for me since I really only deal in small scripts; usually it's throw-away ones that only get used once, and if they get reused after all, it's usually only to massage data. Other than inefficiently-written code, speed is rarely an issue, and even inefficient code's often not such a big problem: I'd rather spend 10 seconds waiting for a script to finish if I'm only using it once than to spend 10 minutes optimizing it so it'll run in 1. ;)

Bugs are a more serious matter. Of course they're inevitable in any language, and perl is gonna be no exception no matter whether we're talking about Perl 5 or Perl 6, but just how bug-free are the Perl 6 implentations (I gather there's several, right?) right now?

for the ideal simpler Unicode handling scenario you described, there's no better prospect than Perl 6 but it's not yet ready for most users and use cases.

What I'm taking home from this is "Perl 6 will be great once it works reliably, but it doesn't yet". Does that sound about right?

[raiph]

»»» This post is about the immature Perl 6, not the rock solid Perl 5 «««

Performance problems aren't a big deal for me

What if something that took a minute in P5 took a week in P6? OK, so it's no longer that bad, but Rakudo's speed can still be a problem for folk who don't think they care about speed. (This page of benchmarks appropriately takes forever to load.)

how bug-free are the Perl 6 implentations (I gather there's several, right?)

P6 is defined by a spec, so there have been multple implementations, and others could one day emerge, but realistically Rakudo is the only serious game in town.¹

I don't think I can usefully answer your "bug-free" question. So I'll be conservative and go with "expect lots of bugs".

There are other serious issues, eg patchy documentation, very few modules, and no way to call Perl 5 code. Maybe one day...

---

If the above hasn't put you off P6, use an IRC client or click this link to visit the freenode IRC channel #perl6 (log) between 6am and 6pm EST (most core devs are European), ask lots of (respectful!) questions, and type code in to the on-channel evalbots. If it isn't fun, forget P6. If it is, then maybe it'll also become useful to you. Either way, please post back here at the monastery about your take away. :)

---

¹ Rakudo relies on the underlying NQP compiler toolchain, so you may hear about that too. And NQP in turn runs on multiple backends including Parrot, JVM and the new MoarVM. So you may hear about those too. But these are all about Rakudo.

[AppleFritter]

Thanks, this is all quite informative!

What if something that took a minute in P5 took a week in P6?

OK, that would less than ideal after all.

[Anonymous Monk]

How about something that took months in Perl 5 taking decades in perl-6? I mean of course making something usable.