3 ms·
> like this one, only ever works with ASCII, no attempt whatsoever to handle UTF-8 I mean if your viewpoint is to handle heavy UIs then yes maybe C is not your
by smaudet 2y ago
> like this one, only ever works with ASCII, no attempt whatsoever to handle UTF-8
I mean if your viewpoint is to handle heavy UIs then yes maybe C is not your go-to language. However, there are other solutions to the character space problem besides UTF-8. Rather than complaining that your screwdriver can't bang nails, perhaps try using a screw?
No, you won't be able to support a language like chinese within a 256 bit charset, but perhaps it's not important to in all situations. The strength of ascii is that its small, simple. If that's too anglo-centric for you, maybe there's a better symbolic tiny charset that is more applicable. I'd support something like https://lojban.io/ https://lojban.io/ becoming more prevalent, but there could be advantages to having a simple(r) symbolic transmission language not burdened with anglo-centric concepts.
- anamexis 2y agoAdvocating a new global constructed language to accomodate C's shortcomings seems like the wrong direction to be thinking.
- smaudet 2y agoLess a global constructed language, more a "better" encoding. Base64 works really well for arbitrary binary-in-text encoding, for instance.
- estebank 2y agoUnicode is that better encoding. The "small and efficient per locale encoding" that you proposed was the status quo, and was an endless source of mojibake. There is a reason we moved away from that.
- smaudet 2y agoI think there is a misunderstanding, which I tried to address but evidentally failed. UTF-8 is fine for a display encoding. However, not every string encoding need be a display encoding, which the parent post seems to not be considering. You could also have multiple display encodings, if it makes sense to (a tool only intended for use in a certain part of the world for instance), however that is not what I mean.