People keep saying this "everyone can switch" thing, but it's not my experience at $VeryBigCorp. We don't have an Anthropic contract at all. Is this different in other places? The bigger and more bureaucratic an org is, the less I would expect it to have contracts with all the providers. Curious about others' experiences.
At my company (not massive but not tiny either - I think its about 8000 global employees) we get a choice between pretty much all available Google, OpenAI, Anthropic, XAI models.
Using an agent-agnostic harness like Pi switching is trivial - I run into occasional disconnects and slowdown and switch quite easily.
Yeah, I think there are lots of places that have a semi-official preferred AI vendor but also some backup subscriptions floating around. For example, at my workplace, we generally use Claude, but I also have some kind of Codex subscription too, which I'd use if Claude went down.
But then what does it mean when the FT writes that that "revenue" number already accounts for the 15 billion losses? That the FT doesn't use these terms correctly either, and we can't really know what its reporting means?
That’s the correct usage. Revenue includes gains and losses. Profit will take that number and subtract out the operational costs (salaries, market data subs, etc).
The text you quoted is purely about copyright/licensing, not about the maintainers' sanity.
The more relevant quote is: "In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches from random people on the internet. There is a process to get a patch accepted, but that process is involved and for smaller changes is not normally worth the effort." Though this is still about copyright, not about being swamped with PRs.
The issue of the maintainers sanity is the onslaught of random people or LLM's submitting packages, So how is not both quotes equally valid for the intended outcome of describing the restrictions required as to collaborate???
You're right that the outcome may be similar, in that trivial contributions are discouraged. But the reasoning to getting there is completely different. Sqlite's copyright.html talks about copyright, not about maintainer overload.
An otherwise overloaded maintainer of another project may probably be willing to accept individual brilliant contributions from brilliant contributors. Sqlite will not, no matter how brilliant, if the contributor doesn't sign an affidavit. Independent of Sqlite maintainer load.
A known Sqlite contributor who has signed an affidavit, and has a history of good, accepted contributions, may also start spamming trivial contributions that may lead to maintainer overload, and nothing in copyright.html will prevent that.
This is from a vaguely interested outsider, I hope an expert chimes in.
My understanding is that in choreographic programming, the protocol/choreography is considered an explicit "thing". That explicit thing is explicitly defined in one place, as opposed to the implementation being divided up across multiple places, like the client, server, etc. This is the explicit opposite of "reason[ing] about each object/microservice in isolation", at least with regards to the protocol. Since the protocol is one "thing", there is no reason for abstraction: Abstraction is for when you combine multiple "things".
In the example, the client's network code may know about internals of the service's network code, but that's not a problem. This doesn't mean that the client's business logic knows about the service's business logic. It's also not a problem that the client knows that there is a separate login provider that could be communicated with. You may be thinking, "oh, if the client knows about the login provider, it might try to talk to it directly". But no, because the entire network code is generated based on the protocol specification, and the protocol specification doesn't include this.
You might take the generated network code and break it by hand. I guess the response to that is, "please don't".
Again, I hope someone can correct this or explain it better.
Hmm, what's a stack machine AST? I can't follow your description of the transform, what does "remove" mean here? I can remove all of the internal nodes of a tree, which leaves me with a soup of leaf nodes, but how is that an AST for a stack machine?
I should have said instruction set or intermediate representation (IR). For a stack machine a program is an array of instructions. For a tree-walking interpreter a program is a tree of instructions. The duality transforms one instruction set into the other.
It's a transform on the instruction set. If you have the following instruction set for a tree walking interpreter (Scala syntax)
enum Expr:
case Add(left: Expr, right: Expr)
case Lit(val: Double)
the corresponding stack machine instruction set is
enum Expr:
case Add
case Lit(val: Double)
The transformation in this direction is purely syntactic: where you see that a case has a parameter of type Expr in the instruction set, you simply remove that parameter for the corresponding stack machine instruction.
The transformation in the other direction is not purely syntactic as you have to know that, e.g., Add gets two parameters from the stack and add those parameters back in.
Got it, thank you! I had read your "remove any occurrence of the expression type in the tree-walking AST" as removing nodes from the AST, but in some sense it's about removing edges, as in, the references from one operation to others.
Not the OP and I honestly have no idea what they mean, but the translation of a tree-walking interpreter for expressions to a stack-machine compiler is almost trivial. For example, if you have (in pseudo-code):
class Add : Node {
Node left;
Node right;
int interpret() {
int l = left.interpret();
int r = right.interpret();
return l + r;
}
}
Given that GCC was first released in 1987, that would mean that tail call optimization, including of indirect calls, has been around for more than half of GCC's lifetime. So it's indeed fair for the parent article to say that "[GCC has] had tail-call optimizations for most of [its] existence".
That is not exactly true, because for a long time tail call optimizations had a lot of restrictions in gcc, so they could be used only seldom.
What is said in TFA is correct in the sense that only in recent years the support for tail call optimization became good enough to be able to rely on it, if you use appropriate compilation options.
"AI-generated copy that says a lot and commits to nothing." Haha.
Seriously, it's nice that Kimi did the investigation, and it's good that that's disclosed at the end (would be better at the top). But please, do a pass of human review for the most grating inconsistencies and style issues.
reply