5 ms·

Well, that's nothing more like the most basic case of string usage. Of course that works. For a rather complex multithreaded client/server program that reads a

by buster 13y ago

Well, that's nothing more like the most basic case of string usage. Of course that works. For a rather complex multithreaded client/server program that reads and writes difference sources (http, webdav, ldap, file, terminal) with a lot of dependencies it really was a nightmare, trust me. Maybe i didn't get some obvious global "do that unicode stuff right" switch and i am just too dumb. But even then, i've never had such problems in _any_ other language. Interestingly i did need to write a very similar tool one year later in python and i had much less problems. And that was python 2.x which is always said to have bad unicode support. Maybe it's just because in python (afaik) you only have to take care of some str() or unicode() semantics and not about a gazillion of use statements, open() parameters and whatnot. Maybe Perl5 has perfect unicode support but how to use and achieve that is a freaking nightmare in a non-trivial program.

Mithaldu 13y ago
Quite honestly, there's not even any need for the "use" statements. When dealing with unicode you only need to do one thing: When dealing with any input/output, find out whether you read/write bytes from/to it or characters, and depending on what you find, decode or don't. I'm very sure that the only reason you had trouble with your first tool was a lack of knowledge and thus a lack of pervasive diligence, leading to you leaving some inputs/outputs unhandled or even worse, handled double. Then you ended up doing that stuff more correct on your second try, since python asks you to do the same things. All the use statements in Perl do is make it so you actually don't need to do that because it makes certain operations work in incode mode by default. In short: Please try to actively separate your own past shortcomings and growth as a developer from judgements on the capability of a language.
- buster 13y ago
  Mh, no. That's not it, since in the beginning the code didn't use those statements. I was taking ownership of the code and then had weird warnings popping up all over the place. The fix for them was always one of those things from the stackoverflow list. So, no, i'm not convinced perl has good unicode support in terms of actually supporting the programmer. Mind you, that was 2 or 3 years ago, so maybe the situation is different now. To me, it was just a stupid task of creating new tests, finding a warning and then trying to figure out what the fix is. Sometimes the fix broke other parts or libraries and then you go to fix #2 (because of course there are a gazillion ways in Perl to do a single task). To me it was really not a very good experience. And really, just look at that stackoverflow article. That's a consistent and good unicode support? No. Maybe the current perl is different, though (i think the project ran 5.12 or 5.14).
  - Mithaldu 13y ago
    Man, i didn't want to trot this out at the start, but well, it turned out my initial hunch was entirely correct. You took software that was made by flailing at it like a monkey, then flailed at it some more. No wonder it turned out as an unpleasant experience. Also, as to your question about the SO post. You claim: "The fix for them was always one of those things from the stackoverflow list." I find myself thoroughly baffled by that, since over half that post busies itself with promoting warnings into fatal errors that end the program with stacktraces. Honestly, i'd love to see your warnings-spitting tool, just so i could straighten it out some.

by buster 13y ago

Mithaldu 13y ago

Quite honestly, there's not even any need for the "use" statements. When dealing with unicode you only need to do one thing: When dealing with any input/output, find out whether you read/write bytes from/to it or characters, and depending on what you find, decode or don't. I'm very sure that the only reason you had trouble with your first tool was a lack of knowledge and thus a lack of pervasive diligence, leading to you leaving some inputs/outputs unhandled or even worse, handled double. Then you ended up doing that stuff more correct on your second try, since python asks you to do the same things. All the use statements in Perl do is make it so you actually don't need to do that because it makes certain operations work in incode mode by default. In short: Please try to actively separate your own past shortcomings and growth as a developer from judgements on the capability of a language.

buster 13y ago
Mh, no. That's not it, since in the beginning the code didn't use those statements. I was taking ownership of the code and then had weird warnings popping up all over the place. The fix for them was always one of those things from the stackoverflow list. So, no, i'm not convinced perl has good unicode support in terms of actually supporting the programmer. Mind you, that was 2 or 3 years ago, so maybe the situation is different now. To me, it was just a stupid task of creating new tests, finding a warning and then trying to figure out what the fix is. Sometimes the fix broke other parts or libraries and then you go to fix #2 (because of course there are a gazillion ways in Perl to do a single task). To me it was really not a very good experience. And really, just look at that stackoverflow article. That's a consistent and good unicode support? No. Maybe the current perl is different, though (i think the project ran 5.12 or 5.14).
- Mithaldu 13y ago
  Man, i didn't want to trot this out at the start, but well, it turned out my initial hunch was entirely correct. You took software that was made by flailing at it like a monkey, then flailed at it some more. No wonder it turned out as an unpleasant experience. Also, as to your question about the SO post. You claim: "The fix for them was always one of those things from the stackoverflow list." I find myself thoroughly baffled by that, since over half that post busies itself with promoting warnings into fatal errors that end the program with stacktraces. Honestly, i'd love to see your warnings-spitting tool, just so i could straighten it out some.