I've been using Emacs since the early 80s, first Gosling's Emacs and shortly after switch to GNU Emacs when it was first released in 1985. In college we had a DEC-10 system and I used Teco on that one.
Mergers are also a huge factor, and the recent Warner/Paramount merger is going to cost a lot of jobs (even more so because the merged company will be so deeply in debt that it will have to aggressively cut expenses).
Please don't use quotes in this context, you're putting words in someone else's mouth that the person did not say and did not mean. In this case, the contributor is making a good faith effort to help, providing data that no one else is in a position to provide, and worries less because any issues can be corrected. In the AI case, anyone can run the slop generator and massive changes can be produced that overwhelm the ability of maintainers to check. It's not the same.
To maximize hype, a company has to be losing money, but with a story about how it will eventually be making massive money. Stable companies that make some money, are growing steadily but with no hope of growing massively, aren't so exciting, and that's what EDA companies are.
Also the other way around (Cadence shipping Synopsys IP). Big chips wind up with IP blocks from many sources and (at least usually) the right people get paid. And EDA engineers bounce around between Cadence, Synopsys, and Mentor (now Siemens EDA).
That isn't why he did it, it was not "to balance the budget". It was to make up for the panic after Putin invaded Ukraine. US gasoline prices soared, going up to $4.84 per gallon in June 2022. Releasing the oil caused it to drop. It wasn't given away, it was sold. The reserve was on the way back up in 2024, through when Biden left office. Furthermore, the government turned a large profit: they sold oil when it soared in price, and bought it back at a lower price.
"California is the third-largest state in the United States, with a population of around 153 million people. It is also the most populous state in the United States, with a population of around 325 million people. The state is also the most populous in terms of GDP, with a GDP of $1"
I wonder how much of this attack had precedents in text that had been previously published to the web, for example, in hacking contests. In particular, tricks for doing more than expected when you're only allowed to make GET requests. Finding material like that might have helped the agents discover the trick faster.
They chose BnB to suggest "bed and breakfast", a common term for a small hotel that was typically just an old house where the owners lived and would host, as we all know. So we know what the right result will be. But since it's a giant corporation versus a person with no resources, we may get the wrong result.
They seem to be mixing together things that are actually harmful to the public, with things that are merely harmful to their business model (which is their claim that they can grab whatever data that they want regardless of the wishes of the owners of the data and use it to improve their models, but competitors can't do that to them).
Even before LLMs were a thing, it wasn't this way: rapidly generating code was not the most valuable skill. As you say, it's much more important that the code can be confidently modified and extended, and reused, not just now, but then. In a mature product, the initial writing of the code will be the least of the work; maintenance is much more expensive. Ideally, design decisions should appear only once in the code when this can be achieved, because then there's one place to fix or one place to modify, instead of dependencies on some detail that appear all over the code. It's too easy with auto-generated code to wind up with redundancy and code duplication, resulting in a brittle mess.
Hopefully in this world, someone figures out how to deliver the performance equivalent of a B300 GPU for about 1/100th the power of a current B300 (which can be up to 1400 watts), or the world will bake.
For traveling salesman that's more than good enough. But in many cases an O(n^3) algorithm can't be used because n is in the billions. I remember interviewing a candidate who asserted that register retiming in digital circuits was a non-problem, so they were surprised that we were still working on improvements, because they had learned that the Leiserson-Saxe algorithm gives an optimal solution in O(n^3) time. But because real circuits are so large that that approach can't be used. Polynomial time often isn't good enough; even quadratic time often isn't tolerable.
I spent my career in electronic design automation, where practically every interesting problem is NP-hard, but we have to solve them, or approximately solve them at least, and because real-life problems often have structure, with the right approach very large problems can be solved exactly despite the theoretical complexity, and when exact solutions can't be found a decent bound can often be found that is an acceptable solution.
Sales people still have to plan their trips even though finding the optimal solution is NP-hard (to give one example). No matter; there are decent heuristic methods.
It's been common in electronic design automation tools to have license terms like that (forbidding use to create a competing product). However, competing companies have often found workarounds, either by finding loopholes or just breaking rules and hoping not to get caught.
In many cases, I found that when colleagues said "we didn't change anything" they mean "we didn't change anything relevant" which winds up meaning "we didn't change anything we think could be relevant to this issue" and then "whoops, turns out it was relevant after all".
It was the preferred lab computer in the mid to late 1970s and into the 80s. I got my first job because I knew PDP-11 assembly language, and worked with both DEC's operating systems for them (RT-11 and RSX-11) and later Unix (the lab I worked with had some machines running Version 6, though Version 7 was the first that I used seriously. It had a very clean and symmetric instruction set that used the program counter as if it were another general purpose register. I had an LSI-11 board (the single-board version of the machine) with 4K 16-bit words of core memory and a paper tape punch with a tiny loader in ROM to read in the tape and peek and poke memory, and I'd sometimes initialize the core memory to a known state by running the one-instruction program
mov -(pc), -(pc)
or 014747 in octal. It would fill all of memory with 014747.
I had to turn off that gmail feature, because to enable it you also have to enable the horrible AI stuff. So gmail is less useful to me now than it used to be. You can't have the good features (automatic categorization, reminders of plane flights) without the intrusive son-of-Clippy crap I can't stand.
Cool. So we benefit by prediction markets surfacing insider information about Trump's plans in the Iran conflict, and unknown insiders making hundreds of millions on that information with massive trades minutes before each announcement benefited the people watching prices in the oil market? That doesn't seem right.
If the result is statistically significant, it just barely makes it. 84.8% isn't that much higher than 80.8% and they had only 250 prompts, if I'm reading this right.
That would matter if we were asking the AI to generate code open-loop: someone probably already wrote something close to what you asked for in Python. But if the agent generates code, tries to compile it, sees the detailed error messages and acts on those messages to refine the code, it's going to produce a higher quality result. rustc produces really good diagnostics. And there's a lot of Rust code online now, even if there's so much more Python and Javascript/Typescript.