Re^6: Mugged by UTF8, this CANNOT be right

You see? 50% of your code was dealing with encoding. That's "wrong". Programming shouldn't be like that.

I have been preached to over the years, over and over and over, that Perl is great and "does the right thing" and it always has, until now. Now Perl is completely obliterated by Unicode/UTF8|16 in the "doing the right thing" department. Now suddenly, instead of following process logic, I have to be worrying about what format strings are?! If I have to worry about these things then I might as well go back to C or assembly and at least get a performance boost for my efforts.

But yes ikegami, you are correct, it IS possible to work with UTF8 just somewhat impractical, and I would put forth the theory that the reason no definitive guide to working with UTF8 and Unicode in Perl exists is because by the time a 100% no-fail solution is written up the author is forced to realize that the solution is too damaging to the reputation of the language.

Tosh

Comment on Re^6: Mugged by UTF8, this CANNOT be right

Replies are listed 'Best First'.
Re^7: Mugged by UTF8, this CANNOT be right by ikegami (Patriarch) on Jan 27, 2011 at 18:17 UTC
100% of that code was dealing with encoding. I was testing the encoding and decoding functions. You're conclusions are based on this being a representative program, and it's not. But as a I mentioned earlier, I do concur there's room for simplification. If you would like tips on how to get started at making those changes, let me know. Now Perl is completely obliterated by Unicode/UTF8\|16 in the "doing the right thing" department. The alternative is that Perl would only work with single-byte encodings. It's not trying to "do the right thing", it's simply trying to work. Because it had to be converted from working with single-byte encodings, that's hard, but the problems are being worked out. You should see Java with chars above U+FFFF, and Java was designed with Unicode in mind from the start! Now suddenly, instead of following process logic, I have to be worrying about what format strings are?! No, you don't, not unless you write XS. I wish people would stop bringing it up. Especially since those that do usually get it wrong.	[reply]

Replies are listed 'Best First'.

Re^7: Mugged by UTF8, this CANNOT be right
by ikegami (Patriarch) on Jan 27, 2011 at 18:17 UTC

100% of that code was dealing with encoding. I was testing the encoding and decoding functions. You're conclusions are based on this being a representative program, and it's not.

But as a I mentioned earlier, I do concur there's room for simplification. If you would like tips on how to get started at making those changes, let me know.

Now Perl is completely obliterated by Unicode/UTF8|16 in the "doing the right thing" department.

The alternative is that Perl would only work with single-byte encodings.

It's not trying to "do the right thing", it's simply trying to work. Because it had to be converted from working with single-byte encodings, that's hard, but the problems are being worked out. You should see Java with chars above U+FFFF, and Java was designed with Unicode in mind from the start!

Now suddenly, instead of following process logic, I have to be worrying about what format strings are?!

No, you don't, not unless you write XS. I wish people would stop bringing it up. Especially since those that do usually get it wrong.

[reply]