2 ms·

I knew that kind of comment would pop up, and oddly enough, I have the exact opposite opinion. I am NOT a native English speaker. I cannot even write my name w

I knew that kind of comment would pop up, and oddly enough, I have the exact opposite opinion. I am NOT a native English speaker. I cannot even write my name with ASCII letters. To me, the situation looks exactly the reverse of your comment, I see the urge of putting Unicode everywhere as an essentially white savior syndrome that nobody asked for. I want to be able to write name in Word or other text processing software, but nothing more. The command line, network protocols, etc. There are not the realm of fancy dynamic length characters. I want simple glyphs with fixed size bytes mapping. I don't want to embed a complicated Unicode parsing library in every software. When I'm in the realm of programming, I'm not here to do politics. I'm here for the most reasonable, straightforward, working solution for a set of problems. If that means accepting a fixed set of characters, I'm 100% fine with that.

usrbinbash 5y ago
> The command line, network protocols, etc. There are not the realm of fancy dynamic length characters. So how does one write, say, the backend for a reservation system managing thousands of hotel room bookings every hour, all over the world? I'm pretty sure there will be ALOT of customers with non-ascii names, not to mention adresses and hotel names. How does one write a system like twitter, where messages in every known system of writing need to be be sent, processed, stored, delivered, commented, displayed? And btw. network protocols and backends work with arbitrary data all the time: Audio & video streaming, networked gaming, sensor readouts, images. Even plaintext webpages are often transmitted in compressed form. So if these systems are the "realm" of arbitrary bytestreams to encode everything from classical music, over sha-hashes, to gifs of dancing dogs, they may as well encode a few hundred different systems of writing and some smiley faces.
colejohnson66 5y ago
You may not care about putting your non-ASCII name in a file, but others do. As a programmer, you shouldn’t be preventing the user from doing what they want when other software lets them do it just fine. Especially things as simple as file names. You can’t say you’re just solving problems when you ignore the requirements of those problems. Internationalization requires Unicode support. The cat is out of the bag, and if your software doesn’t support Unicode. you’re limiting what your users can do with it. Maybe that’s fine with you and a certain program, but it’s not for a lot of people. You also don’t need to embed full Unicode parsing/support libs if you just treat the user’s input as a byte stream. When programmers try to get fancy and ToUppercase() a byte blob with no regard for what that blob represents - that’s when we have problems.

usrbinbash 5y ago

> The command line, network protocols, etc. There are not the realm of fancy dynamic length characters. So how does one write, say, the backend for a reservation system managing thousands of hotel room bookings every hour, all over the world? I'm pretty sure there will be ALOT of customers with non-ascii names, not to mention adresses and hotel names. How does one write a system like twitter, where messages in every known system of writing need to be be sent, processed, stored, delivered, commented, displayed? And btw. network protocols and backends work with arbitrary data all the time: Audio & video streaming, networked gaming, sensor readouts, images. Even plaintext webpages are often transmitted in compressed form. So if these systems are the "realm" of arbitrary bytestreams to encode everything from classical music, over sha-hashes, to gifs of dancing dogs, they may as well encode a few hundred different systems of writing and some smiley faces.

colejohnson66 5y ago

You may not care about putting your non-ASCII name in a file, but others do. As a programmer, you shouldn’t be preventing the user from doing what they want when other software lets them do it just fine. Especially things as simple as file names. You can’t say you’re just solving problems when you ignore the requirements of those problems. Internationalization requires Unicode support. The cat is out of the bag, and if your software doesn’t support Unicode. you’re limiting what your users can do with it. Maybe that’s fine with you and a certain program, but it’s not for a lot of people. You also don’t need to embed full Unicode parsing/support libs if you just treat the user’s input as a byte stream. When programmers try to get fancy and ToUppercase() a byte blob with no regard for what that blob represents - that’s when we have problems.