Translations are inherently lossy, especially for cases like the bible that use less common dialects and have conflicting source versions. Are any biblical translators claiming that their work is a 100% reproduction of the original? I doubt it. Most I'm familiar with readily acknowledge that it's a very messy process and two experts acting in good faith will produce different translations in many cases.
For starters, there are simply many possible goals one can achieve with a translation: Translating it as literal as possible (which can result in barely readable results in the target language, if the languages are far enough apart), translating it so that what thinks its meaning is is understandable, translating it assuming a particular worldview that might shape which alternatives to pick and so on.
A very loose translation could be how the "same program", as defined in its lambda calculus form, or as assembly code, is equivalent to dozens of programming languages, all with different goals and ways to reach their goal (declarative vs. imperative, functional vs. OOP, readable for beginners like Python versus APL, ...)
> Why do you assume a (sic) entire team of biblical scholars, working for years to translate the Old Testement (sic) for the NIV didn't know what they were doing?
That assumption does not appear anywhere in their comment.
Your rude strawman question only makes sense if assuming that ivrit-tirvi is not a fluent speaker of Hebrew and is somehow translating the Hebrew into something else that they understand ... which is quite unlikely, since ivrit (עִבְרִית) is the Hebrew word for the English word "Hebrew".
And the NIV translation into English reflects ideological interpretation that one can avoid by reading the original Hebrew if one understands it.
Have the comments been combined with another story? Because this isn't about a LLM reading and sending contents of the file to be processed, but the agent framework uploading every single file in /home/user to a random server.
Yes, but the underlying problem is a lack of exact specification what the agent is allowed or not allowed to do. It must have access to some (most?) of my files (but I'm too lazy to specify which ones exactly, e. g. by setting appropriate filesystem permissions). It must have access to some servers (but not those that I consider "random", which again I'm too lazy to specify). It is even expected to upload files (e. g. by checking them into git and pushing, or to reason about them in case I'm not running a local version of Grok). But please - not to a server that I deem "random". (And again, I of course won't tell you what makes a "random" host via exact firewall rules or anything like that!)
We have a lot of implicit assumptions when it comes to security. If we leave out the step of formalizing these assumptions into exact rules and instead stick to ambiguous and unclear natural language all the time, then these things will happen.
(Addendum: But indeed, the failure to formalize our assumptions into enforcable rules isn't specific to agents / LLM-based applications. For any desktop app, we have implicit assumptions like "please only read and write your own config files", that we never care to enforce via filesystem permissions, running them in a vm or similar. But with these almighty agents that are supposed to guess our will from just a couple of words, the risk of them violating our unwritten assumptions gets so much higher...)
> For compatibility with other computer languages, the following classic Lua operators can be written in a more customary syntax:
Why though? What does changing `and` to `&&` actually achieve? Were people confused?
Changing the syntax seems very surface level. It's not actually fixing any problems, just making Lua no longer look like Lua. It's not going to help anyone write/learn Lua. It will make everything more complicated as there are now two ways to do everything.
This feels like adding braces to Python because you don't like indenting your code.
Ruby has both kinds of operators as well, and it's fine. The thing in Ruby, though, is that the English logical operators have lower precedence than the symbolic logical operators, so you can use them in place of parentheses. Sometimes that's confusing, other times it can be used to make code very readable.
In general, I would expect symbolic operators to be desirable in complex boolean expressions, because "loud punctuation" stands out among English words when reading the code.
yes, ruby inherited this from perl, though 'or' has lower precedence than 'and' in perl, and they're equal in ruby. Which sounds like something going to cause mistakes, but I yet to see 'and' and 'or' together in the same expression in ruby.
I've always found it odd that and/or in Ruby isn't just considered equal to &&/||, and I have never really used the english operators except for the usual modifiers like if and unless.
What is a practical use case where the lower precedence makes sense?
I can't imagine that making the differences between the languages more subtle would improve the performance of chatbots. Subtleties aren't their strong suit.
Creationism does not want to say "magic" and admit that God is intentionally trying to deceive people. So that's why some of these responses seem silly. I mean they are, but only because the pro-creationism arguments are silly.
Why do you assume a entire team of biblical scholars, working for years to translate the Old Testement for the NIV didn't know what they were doing?
But you do?