eyko

As a EU citizen I believe in the citizen's freedom to pick their social media platform, but when it comes to official accounts (e.g. government, the president or prime ministers, etc) I've always believed we should favour open protocols and federation. Public funding of course. Probably an unpopular opinion.

I'm in my 40s and * is self-censorship to me. It must be a cultural thing.

Agreed, and the same goes for most strategic sectors: energy, agriculture, animal husbandry, semiconductors, communications, space, the infrastructure to support all these, education, etc.

It's also worth considering that certain industries (fisheries and agriculture for instance) are subsidised. It's in our national interest to maintain production capacity, so profits are the least of our concerns. Both the UK and the EU's agricultural sectors are heavily subsidised mainly for this reason. It's cheaper to import than to produce locally, especially with our environmental standards and targets, but we need to keep producing. More so in the current geopolitical climate.

And whilst nobody wants to risk being starved to submission, it's also equally important to promote more profitable sectors, and tax accordingly, so that we can support our more strategic sectors. I wouldn't say we're doing a good job at that for what its worth.

I do not speak latin, although I studied it for two years in high school and I'm a native speaker of a romance language, so my understanding of latin is pretty much basic to guesswork.

This is a really cool tool -- I often read latin texts with the original on one page and the translation on the other, just because I think it's interesting to see how they wrote/spoke at the time, but for the most part certain words or declinations throw me off guard. Inline literal translations really help there.

That being said, I noticed whilst reading some of the texts that the inline literal translations are still in latin, e.g. in "Part IV. I Some Barbarous Customs", most of the translated text is just latin. I guess OpenAI won't take all our jobs just yet!

I do have one suggestion for improvement though. Many of these texts have translations that are already in the public domain (older translations). It would be helpful to display the original Latin and a fluent English translation side by side, whilst still being able to toggle the literal translation on or off. This setup would make it easier to compare the original text with a fluent English translation, similar to the format used in some bilingual books.

Fear of death is not the only kind of terror.

And don't get me started on North Americans and "yams" for sweet potates/kumaras.

If you're going to treat logs as a db entry and afford them a schema, then by all means knock yourself out.

The main point he's trying to make is not just about the logs you wrote but about logs coming from other systems or services, e.g. monitoring kernel logs in your OS. As he rightly points out, one of the reasons is that logs are not an API.

> One reason this happens is that almost no one considers log messages to be an API, and so they feel free to change log messages at whim.

To be fair a slightly better comparison would be MMS, but even then it doesn't compare. It's simply because data is cheap, the app is free, and the rich media features that came before iMessage/RCS existed (voice, photos/video, attachments, group chats, voip/video calling, etc), and because it's multiplatform (ios to android usage is near 50/50 or 60/40 depending on the country)

And all it takes is a few typographic rules in a style tag.

Perhaps it's because English is not my first language, but I find it confusing to read "this is evidence that .... might ....". Isn't the purpose of evidence to prove a claim? If there is no conclusive evidence, I would expect it to be phrased along the lines of: "Preliminary evidence suggests that... might...".

Can't speak for the parent commenter but their situation felt familiar. I'm in a new role where I'm contributing to a very large Python codebase (first commit from over a decade ago) and whilst there's a lot of more recent code written with type hints, they're not enforced and they're not always reliable or consistent. On my second contribution, I introduced a bug that pyright immediately spotted after I upped the checks from basic to strict. Our Sentry reports a lot of non-critical bugs that are being triggered in production that in many cases are _already_ highlighted by the type checker. It's just a big enough codebase that it's not practical to attempt to fix them all.

If I were starting a project today in Python, I would definitely try setting up my tooling and processes to enforce type checking to at least some extent. Fortunately, we have a lot of guardrails that recover from the typical exceptions that occur in those cases, but as I experienced first hand, it's very easy to introduce new bugs when relying only on my intuition for those difficult-to-spot cases. Tooling definitely helps there.

My previous role had me writing TypeScript and Rust so there's always the temptation, or bias, to advocate for strict typing everywhere, but I'm conscious that it's neither practical nor feasible in large codebases with hundreds of contributors (most of whom may be more accustomed to dynamically typed languages).