This has nothing to do with learning a programming language and everything to do with learning how to process text in a computer. Being a C programmer doesn't m

This has nothing to do with learning a programming language and everything to do with learning how to process text in a computer. Being a C programmer doesn't mean you have only a PDP-11's understanding of text ("it can be ASCII or EBCDIC, and I know how to convert between the two!"). When I learned C# (in 2003?), I learned that String in an array of Char and Char is 16 bit, and that .NET used the same encoding as Windows NT (UTF-16 in native endian). I knew that both WinNT and Java made the mistake of being designed at a time when people assumed 16 bits are enough and consequently caused the surrogate pairs mess. I knew that Java assumes UTF-16BE and Windows assumes UTF-16LE. I knew what UTF-16 means in C/C++ and how to work with it or transform such data to and from UTF-8 and UCS-4. When learning a new programming language, I know to look up whether strings are mutable and whether they're sequences of bytes, code units or code points. If they's immutable, I look up how to create a copy instead of a reference when using substring and when they're not bytearrays I look up how real bytearrays are called in this language. Should early programmers be taught this? Absolutely. At what stage? I don't know. But they must be taught from the start that this has nothing to do with a programming language and everything to do with how data is represented in memory.