What you probably won’t find, though, is the programmer’s else: “If X, Y. Else [meaning: if not X], Z.”
176 karma · joined January 29, 2018
The programmer’s if-else goes like “If the window is open, close it. Else, leave it closed.” This is not a natural construction outside of programming, people would use “otherwise” or “if not” instead.
(“Else” stands for “if the window is not open” in the above.)
The Crime and Punishment if-else is more like “If the window is open, close it. Else, cold air will enter.” This is normal English.
(“Else” stands for “if you don’t close it” here. It can’t stand for “if the window is not open”.)
It’s not being used in the programming if-else sense here. He’s not saying “if you don’t love me, I shall begin to hate you”. He’s saying “if you don’t give me up, I shall begin to hate you”.
Wow, that was fast!
Dropping the Sectigo root along with the eMudhra root is the easy and safe solution, and maybe this is what Apple should have done (it’s the workaround they recommend!). But it means that some small percentage of certificates that are fine won’t be accepted.
Dropping the Sectigo root along with the eMudhra root is the easy and safe solution, but it means that some small percentage of certificates that are fine won’t be accepted.
Yes, svat’s comment accounts for that by using little-o notation* in o(n log n). This was only achieved in the 2026 result.
What kind of change impacts fewer than 1 services or applications? Is this meant to say “at most N”?
Flexible array members don’t allocate a dynamic amount of memory on the stack.
Another related nice property that UTF-8 has: substring search reduces to bytestring substring search. I.e. given two Unicode strings in UTF-8 encoding, you can check if one is a substring of the other by just treating them as bytestrings and checking if one bytestring is a substring of the other bytestring. This is a stronger property than self-synchronization: UTF-8 has it, but UTF-8000 doesn’t.
I think a sinking ship is a reasonably good metaphor though. A sunken ship is a horrible, terrible outcome.
In the metaphor, a codebase is sunken when it’s unviable to continue using it. The organization stops working on it and no longer runs it. At this point, the code is completely worthless to the business, like a ship at the bottom of the ocean. True, you could imagine the code getting worse theoretically. But in reality, it will just sit there and rot.[0] The business might attempt a rewrite or just discontinue the product.
It’s possible, but not a given, that a business sinks with one of its codebases. This can happen with a ship too, if a business relies heavily on it.
What I should have said is that in the case of İ/i/I/ı, using str::to_lowercase for string matching wouldn’t be any less correct than using their locale-independent casefold.
The third character in the list, final sigma, is a good example that illustrates why using str::to_lowercase for string matching isn’t good.
> “Suppose […] they type straße and you’ve stored STRASSE. To make these count as matches, you need […]”
Really bad example, because as the article says later on, this casefold crate won’t match those two strings because the ß → ss conversion isn’t done.
> “[str::to_lowercase and case folding] diverge on real characters—ß, İ, final sigma”
The main point is true (case folding is different from lowercasing), but two of the three examples are wrong. The casefold operation that they use maps ß to itself, as does str::to_lowercase. The casefold operation maps İ to U+0069 U+0307 regardless of locale, as does str::to_lowercase.
When I’m reading an article, these kind of mistakes in the introduction make me doubt the accuracy of the whole article. Which is a shame, because again, it’s an interesting write-up. The mistakes also make the article harder to follow, since the examples imply ß is folded to ss.
Location: Europe (UTC+2)
Remote: yes
Willing to relocate: no
Technologies: Python, SQL, C, Java, Go, PHP, JavaScript, Typescript, Claude Code, Analytics, Git
LinkedIn: https://linkedin.com/in/lukas-gelbmann
Email: me@lukasgelbmann.com
You comparing arsonists/pop with firefighter-arsonists/arsonists. That’s the wrong comparison. You should be comparing arsonists/pop with firefighter-arsonists/firefighters. Or firefighters/pop with firefighter-arsonists/arsonists.
(On top of that, mixing numbers from different sources can be problematic. For example, how are repeat convictions treated in the different sources? Who counts as a firefighter?)
Our aim isn’t to try and line up with the calendar that was in use at the time, 2026 years ago.
Instead, the aim (for 28times) is to implement the rules of the proleptic Gregorian calendar[0] correctly. The bug was that those rules weren’t followed for some rare values.
But to address your comment properly, I think I should justify why on Earth someone would want to use the proleptic Gregorian calendar for year 0 and before. In short, because it’s a useful fiction.
The biggest reason is interoperability: a lot of software follows proleptic Gregorian rules, aligning around ISO 8601. Probably a clear majority of date/time software. We want to line up with all that existing software that assigns a specific meaning to a string like "0000-02-01". That’s the first of February in the proleptic Gregorian calendar, even though it was a different date in the ancient Romans’ calendar.
The other reason is to keep it simple: since most people use the Gregorian calendar in present times, it’s simplest (for us as implementors, but also for users) to extend its rules into the distant past and distant future. The alternative for be to have multiple sets of rules, e.g. Julian and Gregorian calendar. (You might say it would be even simpler to just not allow timestamps before 1582. But there are use cases, e.g. in astronomy or history, where people want to work with timestamps before 1582, and even before 1 AD.)
[0] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
Instead of running `git log -n1` on every file, I think you can walk through the commits backwards, skipping any files that have been seen. Something like this (these two commands could be followed by bttf commands):
git log --pretty=format:"DATE:%aI" --name-only |
awk '/^DATE:/ {date=substr($0, 6); next} $0!="" && !seen[$0]++ {print date, $0}'
git ls-files |
awk '
# Read all existing files from git ls-files into an array
NR==FNR { lsfiles[$0]; next }
# Process the git log stream
/^DATE:/ { date=substr($0, 6); next }
$0!="" && ($0 in lsfiles) && !seen[$0]++ { print date, $0 }
' - <(git log --pretty=format:"DATE:%aI" --name-only)For example, let’s say I want to run some piece of software that I’ve heard about, and let’s say I trust that the software isn’t malware because of its reputation.
Most of the time, I’d be installing the software from somewhere that’s not GitHub. A lot of package managers will let anyone upload malware with a name that’s very similar to the software I’m looking for, designed to fool people like me. I need to defend against that. If I can find a GitHub repo that has a ton of stars, I can generally assume that it’s the software I’m looking for, and not a fake imitator, and I can therefore trust the installation instructions in its readme.
Except this is also not 100% safe, because as mentioned in TFA, stars can be bought.
It seems that different software handles that question in different ways.