Comment by simias | Hacker News Reader

Comment by simias | Hacker News Reader

Parent Full thread

The commit was complaining specifically about the way locales were designed, not C as a whole. While C was very successful, I don't think you could argue that C locales ever reached the same level of popularity.

That being said I do agree with you that this complaining is not massively productive. Dealing with localization and non-ASCII text is notoriously difficult. Look at Java, Python 3, Windows, PHP 6 and how many "misconceptions about Unicode" articles you can find online. You could spend hours pointing out how each approach has tons of drawbacks but clearly the perfect solution doesn't seem to exist so a compromise had to be found.

In particular I'm not sure I agree with his complaints about locales being global state. How else would you handle them? You need to have some kind of global config flag somewhere to decide what local the user wants to use. Having explicit versions of the stdlib taking locales as parameters could be nice I suppose.

This bit in particular seems to completely miss the point:

>Idiotically, locales were not just used to define the current character encoding, but the concept was used for a whole lot of things, like e. g. whether numbers should use "," or "." as decimal separaror.

Of course if this programmer assumes that locales and charsets should be the same thing they'll end up frustrated.

When locales were invented, it was reasonable to assume that the locale would determine the character set. With the subsequent invention of Unicode that no longer needs to be the case, but code standards live forever.

It wasn't really that reasonable as soon as it was made global. It's exactly the kind of assumption that mostly works but has dark corners from the beginning.

Some imaginable version of locales was probably a good approach at the time, but that wasn't what got standardized.

I don't disagree, I've run into those dark corners myself. But the ease of use of globals is undeniable - there's a reason the Singleton pattern is still popular after all the ridicule it attracts.

Sure, it's easy to use. But that isn't the job of standardization bodies, or the right test to use on something as low level as this. It's harder to get right, but it is exactly these sort of failures in standardization that cause the most global pain, because they wend their way through everything.

In this case I don't think the locale functions were designed by committee, I think they were accepted as-is from a popular implementation. And they were implemented that way because it was the simplest most straight-forward way (I'll admit I'm just guessing now). Were they part of K&R C?

No, of course not.

>When locales were invented, it was reasonable to assume that the locale would determine the character set

Sure, but that's not what the commit is saying. Instead it's saying that it should only determine the charset and that Unicode effectively makes locales pointless. That's absolutely not the case, there's a lot more to locales than character encoding.

I think we're in agreement. There are lots of aspects to a locale, and character sets are only a small part of that. Possibly the most visible part though.

Unicode doesn't make character sets pointless, it only makes them deprecated. It's still useful to have a way to convert from one set to another, and it's a shame the standard library doesn't have an easy way to do that. The deficiencies of locales are visible only in hindsight.

Locales being global state only makes sense for single-user applications. That assumption is no longer true once you have a server where every request may be from a different user. A better way to handle this is something like Go's context object, which gets passed explicitly.

That's not a very common use case for C, either now or back then (arguably you probably had more user-facing C cgi back then, but it was still one invocation per user so arguably you could set the locale for each call). Some webapps use C in the backend but generally don't deal with the localization at this level.

I'm not saying that C locales aren't bad and limited, I'm saying that it's a compromise that makes some sense. In particular when you're trying to bolt something into an already extremely popular language instead of designing a new thing from the ground up.

Can you imagine the churn if the C standard suddenly introduced a whole new set of string functions just to deal with the locales? Well, you don't really have to imagine, just look at the way it works on Windows with their wide strings.

Reply on news.ycombinator.com