JackC

> What Reame is NOT for — said plainly, because trust is built here

It is so weird (or, used to be) to see an LLM's internal thought process pop up this way. Like imagine how strange it would be to read human writing that accidentally included thoughts undercutting the ongoing sentence. It's the moment you know that nothing you're reading has necessarily been seen by a human before or relates to reality.

I mean, we're talking about an administration that has already over-reached in regulating this specific company out of personal bias; is openly seeking leverage over companies for favoritism and graft; hires on the basis of loyalty to whims of a narcissist; makes fun of the whole idea of competent government based on expertise; provides a range of conflicting explanations for whatever it chooses to do; and has been unable to field a team capable of understanding or explaining whatever real risks are here.

Your question is like asking what evidence would convince us that a bag of rocks doesn't have rocks in it. Easy, just take the rocks out.

"They may speed up the good programmers a little, but those people were able to program anyway without LLMs."

I don't think this is realistic. I'm a good programmer, and it speeds up my work a lot, from "make sense of this 10 repo project I haven't worked on recently" to "for this next step I need a vpn multiplexer written in a language I don't use" to, yeah, "this 10k line patch lets me see parts of design space we never could have explored before." I think it's all about understanding the blast radius. Sonetimes a lot of code is helpful, sometimes more like a lot of help proving a fact about one line of code.

Like Simon says, if I'm driving by someone else's project, I don't send the generated pull request, I just file the bug report / repro that would generate it.

The article argues that shared memory and message passing are the same thing because they share the same classes of potential failure modes.

Isn't it more like, message passing is a way of constraining shared memory to the point where it's possible for humans to reason about most of the time?

Sort of like rust and c. Yes, you can write code with 'unsafe' in rust that makes any mistake c can make. But the rules outside unsafe blocks, combined with the rules at module boundaries, greatly reduce the m * n polynomial complexity of a given size of codebase, letting us reason better about larger codebases.

> The president has something to offer as a solution. For everything.

Unfortunately it is not a coincidence that the solution to all problems is always (a) make a loud noise (b) take your stuff (c) take away your ability to object to taking your stuff. Amoral sadistic narcissist gonna amoral sadistic narcissist. If you think you don't have enough information to predict how that's going to play out as far as family members you care about, ok.

Opinion from 10 years ago, I suspect still valid:

There are a million python libraries and tools to do some overlapping subset of the things you'd want to do with a pdf.

There are no doubt another million in other languages.

These are each basically bundles of some of the transformations you'd want to make to the same underlying data structure.

So, complex pdf scripts often need two or three different libraries to get their thing done, which is wasteful at borh a dev effort and computational level.

The ecosystem would be greatly improved if someone made a great (probably rust based) in-memory low level pdf reading and writing data structure.

PDF libraries in any language could switch to using that structure and library internally, with the carrot that the switch would result in needing less code, and likely being some combination of faster and safer.

And then if they just exposed get_structure_pointer() and set_structure_pointer(), they could all interoperate for free. (Another carrot for joining -- small libraries could usefully add features and be adopted without needing to pick an existing popular library to glom onto.)

Not sure what would economically cause this to happen, but it would be great.

> First people complain the app store has a ridiculous approvals process and people keep getting rejected unfairly. Now people complain that they are too loose and letting in shovelware. What’s it going to be?

At best a walled garden is collective bargaining -- a group of users (buyers) lock into requiring vendors to negotiate with their representative, and because their business is collectively valuable vendors have to meet higher privacy standards or whatever the users care about, which they couldn't extract if negotiating individually with huge companies like Facebook.

So, Apple will get yelled at whenever it fails to be a good agent in collective bargaining -- either by excluding quality vendors and driving up their costs, or by including low-quality vendors. Either one gives up the benefits to users of the walled garden.

An index of reliable apps is, you know, fine. An index with a business structure that ensures better collective bargaining gets interesting.

This is why Slay the Spire is as loved as it is -- clearly defined skill and luck checks delivered one after the other at the precise limits of your ability.

Minesweeper is more like a quirky old wooden board game, charming because it's always been what it is, warts and all.