But the evidence is clear from this incident: What people "can do" and what people "actually do" are VERY different things.

I'm sure I'll get flamed, but this is why C (and other languages that don't provide mechanisms to BOUND the length of a string) are actively dangerous in The Real World. Look at the massive effort and time to mitigate this VERY COMMON AND WELL UNDERSTOOD vulnerability.

Boeing and Airbus? I'm OK with that.

Well, we should certainly be able to distinguish between 'policy that has value for the community at large' and 'policy that supports a single stakeholder's objective (even when that's the stakeholder with the gold)'. So I don't disagree with you.

"When everyone is thinking alike, no one is thinking."
https://quoteinvestigator.com/...

See https://www.iso.org/standard/7... And for the history of COBOL language standardization, see the table here https://en.wikipedia.org/wiki/...

Programming languages managed buy ISO committees change slowly. That's a FEATURE. I worked a bit on the Ada standard. Each proposed change was carefully weighed for its impact on existing code, as well as the value for new code. The standard was updated roughly every 10 years.

By your powers combined, I am... the British Colonies!

The main aim of Stop Killing Games is to ensure the practice of rug-pulling eventually comes to an end. They are not trying to save MMOs, for example.

Moreover they don't demand that every game currently on the market comply with open-sourcing requirements: at a minimum, companies always have the option of simply providing customers with adequate notice before shutdown. Open-sourcing the server would be nice, but it's hardly the only way to protect consumers' interests. Scott has, for example, suggested game boxes being marked with an estimated expiry date for online service functionality.

But most importantly: because this is about future games, not the present, the market has time to change. If studios and publishers are designing their games with a fair EOL in mind, then they can make decisions from the get-go to avoid licensing dependencies that they won't be able to release in a possible 'afterlife' version of the game. As suggested by your example of GameSpy in C&C: Generals, when a commercial dependency is crucial to a game's success, it tends to be a client-side library, but typically the problematic dependencies aren't crucial; they're e.g. add-ons for Unity or Unreal that the studio bought to save time. In a world with SKG laws, the providers of these dependencies aren't going to be a stagnant target either—demand for compliant libraries will motivate development of open-source versions.

Interestingly, the will for doing this does exist among game developers; they just need the institutional support from legislation to twist the arms of the studios and publishers. Ross Scott has talked to a lot of devs who are burnt out from having their projects cancelled, leaving them with huge gaping holes in their resumes and portfolios where they've spent years on unreleased projects that are stuck under NDA. In general they tend to see SKG as a path to ensuring the games that do see the light of day aren't also scrapped, which would erode their work histories even further. (Apparently it also just plain feels bad to have your work erased from history. Shocking, I know.)

Sorry I don't have moderator points for parent! +1 interesting

Fear not! It's entirely possible the category was chosen by an AI. Editorial automation would probably reduce the error rate here.

Yes! Particularly in languages with rich semantics and a tradition of meaningful identifiers, the primary focus on documentation where I've worked has been on 'why' rather than 'what.' In Ada, which separates specification/API from implementation, the comments in the spec explained what the package did (including errors/exceptions), and the comments in the body concentrated on capturing what was not obvious -to a maintainer- in the code. Ada culture strongly emphasized maintainability, and that was emphasized in code reviews.

On one project, I ended up as "the first maintainer", having to rewrite a package that was widely used throughout the large application. I had to live with that specification, although I did add comments on errors that could be signaled by the various operations. But I rewrote that package body twice, the first time for time performance, and the second time to minimize space (it was a generic package. The compiler was unable, due to the complexity, to do 'code sharing' automatically, so I ended up using a lot of compiler specific dirty tricks to manually implement shared generics. And I documented all the tricks and knowledge about what I was doing in that package body. I also delivered a 'warranty' with that, telling my successor afterI left that job, "If you get a bug report, contact me and I'll work with you to fix it." She never called, and about 10 years later we connected, and I asked: "Any bugs on that code?" "No, it worked perfectly.")

For me, it was a Xerox XDS (formerly SDS) Sigma 7... And I learned a lot about programming from studying the BASIC source code of that application. I got yelled at by one of the university's system programmers when I asked her a question "why did they do it this way?" Then she answered my question.

Great point. It's also really unclear how many Mythos found that are not/would not be found by open weight models.

This is pure marketing FUD, which is one of Anthropic's most advanced forms of "intelligence".

While I agree that many in the industry want the cheapest and the fastest to build regardless of quality, my question is about the demand side.

Who wants these apps? What is is that they do that someone is willing to pay for? How does that address the cost of the other inputs that make apps worth enough money or other rewards that someone wants to maintain them?

We are 18 years out from the launch of iPhone App store, and even though humans are far slower than AI in building apps, after nearly two decades I don't think there are massive parts of human activity that are un-apped. In pharmaceutical development, the dearth of "undrugged diseases" has led pharma companies to focus on rare and orphan diseases - bringing VERY high cost drugs to market to serve small numbers of people.

Where are the "orphan applications" that these apps are there to serve?

Vibecoding a delivery app stack will not make DoorDash obsolete - somebody still has to recruit drivers and food sellers and offer something to each of those parties that makes them want to drop DoorDash. DoorDash may be able to automate away some labor (though I suspect it will be less than they think).

In the enterprise, the theoretical "un-automated work" seems to be in two main buckets:
1- making presentations, dashboards, documents automatically, and
2 - building software automatically

Both of these clearly have some value, but I think the AI boffins and investors are wildly overlooking all of the human stuff that goes along with those tasks.

Also, it's obvious that AI makes that kind of stuff a commodity, meaning that its value goes down as its volume increases. So yeah, AI can make a lot of slop, but it's not obvious how that makes there be more valuable stuff.

It's all a small price to pay for Eat Your Veggies.