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.
Speaking of postgrest, it looks like the article links to `www.postgrest.org` which has been "hijacked"? The correct url should be https://postgrest.org
Sure but fear created by biosphere collapsing all around, massive human migrations, desertification and miscellaneous climate catastrophes are not things that mere terrorist groups can plot. :)
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.
create table log (dt timestamp not null primary key, msg text not null)
is usually all you need to start sifting through the haystack. Problem with this approach is if you aren't diligent, you'll end up killing you app AND you're db.
We already established that log sifting at scale isn’t productive nor does it work for reasons outlined in the article. This was just an answer to how to do it in a smaller scale. Yeah, primary key is going to give you problems, a simple index shouldn’t but the issue is this, logs are not event sources - or shouldn’t be. The only time you should be looking is when your looking for stack trace and even then there’s better options like sentry.
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)
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...".
The purpose of evidence is to provide support for a claim. However in colloquial speech we generally speak of someone having "evidence" of something when they have absolute proof.
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).
To be fair, average salary varies per city* and if you earn the average salary in any city*, chances are you'll be able to rent but not buy. I've tried a few London post codes and their average salaries: deep red can't buy can't rent. I've also picked a few random places up north and around Manchester, and it came out orange. I wouldn't be surprised if the conclusion was the same for most of the country!
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.