251–260 of 389 posts
Earlier quoted context omitted.
IMO the repo is the code However, I would have done a simpler commit and linked to an issue where I explained the problem/solution in more detail
This assumes your issue tracker doesn't change. I've been at my current position 8 years, and in that time we've had 3, and the first 2 are shut down.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Final paragraph: > All in all, I believe this proves that software developers as a whole and as a culture produce worse results than drug addicted butt fucked monkeys randomly hacking on typewriters while inhaling the fumes of a radioactive dumpster fire fueled by chinese platsic toys for children and Elton John/Justin Bieber crossover CDs for all eternity. I also nominate this commit.
Pure, rage-filled, git commits are possibly the most honest form of art.
Earlier quoted context omitted.
…or fix the non-Unicode compatible systems that are consuming the commit messages and breaking? If they fail with an nbsp then they’re probably also going to fail with more obviously useful non-ASCII characters.
How often are non-breaking spaces purposely inserted vs accidentally? And the tools might handle them fine but will produce strange results or errors. An example is inserting a non-breaking space in a document or string. It will prevent word wrap, which might not have been the user intent. A linter that requires these spaces to be explicitly set in encoded form would avoid these issues.
Earlier quoted context omitted.
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 man…
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.
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.
Earlier quoted context omitted.
It’s a shame you see it only as complaint, the brilliant thing about the text you’re replying to is that it educates the reader as to the bigger problem, as well as being very funny. Does your complaint do either? Understanding why C locales are broken may very well contribute to the lasting growth of humanity. Did you note that Eric Raymond fully agreed?
You’re assuming from a distance I can’t get the point at all. You’re assuming also ESR is some God incapable of normal human failures in reason. The issue is a real thing in C. Github to me is Arxiv. I don’t see a lot of research papers making a point with caustic words for the universe. But my background and education is math, my way of having to communicate issues and ideas is different. To me MPV is a few build sc…
> I don’t really care about social media norms and use throwaways liberally
Did you mean that to be funny? It’s quite ironic following your “rant by someone with no real responsibility” comment. That seems pretty funny to me, but not clear that was the intent.
Earlier quoted context omitted.
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 man…
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.
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.
For anybody wondering, the likely origin of the invalid character is somebody using an Apple Ireland/UK keyboard layout where # is Option-3 (AltGr-3), and non-breaking space is Option-Space (AltGr-Space).
To an extent I find this lazy and even a humorous take is giving it attention it doesn’t deserve I can complain about anything Can this person build a language that’s still as broadly useful as C that no programmer will find issue with “Oh boy I encountered a particular odd and annoying thing. I won’t bother to offer an alternative. I’ll just complain about others efforts while ignoring they ultimately enabled me to…
This comment comes across really mean and judgmental. I didn’t read all of the original commit, but it read to me as informative and passionate with all of the frustrations solving a difficult problem comes with. Honestly, this comment is so over the top I can’t even detect whether you’re serious or not.
I’m trying to solve my own problems using Github. If I wanted to bullshit I’ll hit you up on IRC.
How much of these things are in source code we import into our systems? It’s enough reading through lines of obscure code. I don’t really want the lift of parsing others emotions.
Time & place, children.
Earlier quoted context omitted.
Then use `git log --oneline` and you don't have to see the lengthy details, until the inevitable day when you find you need them.
How do you surface them when you need them, though? git grep?