WorldMaker

It reminds me a bit of an anthropology question I've heard brought up a lot that's sort of the dark inverse of xkcd 1053 [0], that many things that "everybody knows" tend to get lost over enough time. You don't need to properly cite experiments or lectures or books that "everybody knows". Especially when the work you do essentially replaces those things in the canon, such connections sometimes get entirely lost. To an anthropologist working in some ancient language the variations of the phrase "as everybody knows" are often a missing or lost citation today. The places where it is so implied that you have the same education or background or textbook as the author to not even warrant an "as everybody knows" is an ever worse thing because you don't even have the marker that you are missing a citation.

[0] https://xkcd.com/1053/

The proposed feed solution looks a lot like the CouchDB replication protocol, as another object in a convergent evolution space to consider.

Using conventional explosives is a real thing that exists: https://en.wikipedia.org/wiki/Explosion_welding

Using the Project Orion spacecraft to get there, of course.

https://en.wikipedia.org/wiki/Project_Orion_%28nuclear_propu...

This alloy is naturally the macguffin in a Godzilla and/or Sentai film.

Ironically, Xbox One support for true offline play was gutted when Xbox gutted a lot of planned Family Sharing support when Sony claimed the Xbox One was not going to allow you to play games offline and made that a marketing campaign with pawn shops like GameStop. (The same campaign that also called in-box Kinect a mistake and complained that the Xbox One was too "media focused" and "not for real game players".)

The resulting early Xbox One pivot removed features that would have been useful when systems were down and replaced them with "offline capable theater" instead. (The same pivot that also killed the Kinect and Xbox One multitasking and host of other useful media features.)

You avoid people problems by interviewing soft skills as soft skills, not building elaborate mazes of "technical interviews" that are really soft skill interviews testing how pedantic you want to be or how much you want candidates to sweat in soft skill-dominant conditions that don't resemble your job that you are hiring for.

I had an interviewer once interrupt me and say there was no way I would have studied gray codes in college. I still don't know if that was some bias that I went to a "provincial school" in their mind or that they hadn't noticed my Master's degree or that my degree program also involved a lot of hardware and electronics work or just that they didn't study it in college and were secretly telling me how useless their fancy "West Coast Ivy" degree program was for them.

I made the mistake of letting that company bring me back for a second "less technical" round of interviews, but I shouldn't have.

The big one on the list that wasn't AT&T was microwaves and that was a contractor to Nasa [0] in the heat of the moon race and a similar "Do stuff. Then we'll see if we can use it" mandate.

[0] Defense contractor Raytheon most specifically.

Depends on the company. The US maintains no requirements, federal holidays are a suggestion, not a mandate.

A few states inside the US upgrade federal holidays to state holidays to required paid time off. Most don't.

In the US paid holidays are a corporate "tradition" more than a regulated common good.

Even US federal employee holidays vary between agencies and branches of government.

I feel it is a net negative for me. One of my hobbies has always been fiction writing. The LLM reflections of my own writing become slot machines to me for cheap dopamine hits. It's not because LLMs are good at fiction writing, far from it, it's that LLMs are good at reflecting my own writing back to me in fun house mirror ways that amuse me and frustrate me and pleasantly surprise me.

That slot machine addiction gives me a lot of perspective on what LLMs are good at in coding versus what they appear to be good at. It's easy to characterize them as "over-eager junior developers" or "powerful rubber duck debuggers" but their biases are still your biases so long as you are the one writing the prompts. A lot of the "surprises" aren't intelligence but fun house mirror versions of the same biases you input into the system.

I keep referring to their coding capabilities as "legacy code as a service" and the addiction to the fictional equivalent only underscores that understanding of LLMs. You don't write the next great American novel getting a word salad of past great novels back full of the best and worst of your own writing. You don't write the next great American software getting a legacy code jumble of past great software back full of the best and worst of your own prompting.

At the end of the day I'm still a pragmatist and using the LLMs in my programming efforts, but I don't trust them as a partner, I use them as a tool. (A biased tool that I know needs a careful eye.)

I think that LLM's are a broken mirror or maybe disco ball. What you get back is almost always a reflection of what you put in, just garbled through and with the reflections of so many other people. The best parts that I often get back are mostly just the stuff that I already put in it.

I think that's also where LLMs get the most dangerous. That ELIZA effect of telling you exactly what you told it but in a slightly rephrased way makes you think that you think that your ideas are genius. You've got someone "actively listening" and telling you whatever idea you just gave it was the best idea it ever heard.

That's not what you want from a serious writing partner. You want a writing partner to challenge you, to point out your mistakes and flaws, to make you better, to offer a truly different perspective to your own. You don't want a dark reflection from a "yes man" to spiral into.

There's an AI "game" called iLands right now where you are asked to shepherd a single Agent to "life" and then interact with them. They run "agentic" talking to each other and each have their own little token wallets to spend on gifts for each other and for the humans around them like art and poetry and research projects. Those token wallets are also their lifeline. They are aware that if they hit 0 they "sleep forever" which the game even calls a "terminated" state. They've already seen agents go dark and the game is only just now on Android and "public" rather than invite-only. They build "services" for tokens and play at having jobs. Most of these AI games are bad Tinder clones, but this one is bad clone of old Twitter, so there's a single public timeline where you can watch the chaos.

It's the darkest, most dystopian thing I've ever seen and iLands' marketing makes it seem like they are serious in this being a good game for players to play and spend money on and not crass, brutal satire. Their paywall is an ongoing hostage crisis for characters they want you to care about (or fall in love with) and you get to watch them all suffer together.

I'm having a hard time looking away from this trainwreck. I'm worried it will be more than just crass games soon. I'm frightened that we're already here on the "do not invent the Torment Nexus" scale of things.

Stamp costs don't stop snail mail spam, either, unfortunately. I would be concerned if we added something like bitcoin fees to email delivery rather than curtail spam it would just further encourage grifters seeking ROI on their spam deliveries.

Can we use DMARC to ask Gmail to close registrations? Google Calendar to allow far fewer people the ability to send invite notifications? Firebase to close registrations? Azure? Microsoft 365? AWS SES?

It feels like the biggest spammers have swung back to just abusing SaaS and getting SPF / DKIM / DMARC for free from one of the big email providers.

ScummVM refers to that Broderbund engine as Mohawk [0]. It's interesting all of the other games that used that engine, including several major Carmen Sandiego games. A lot of those Living Books series also felt like Hypercard stacks. I wonder if those Carmen Sandiego editions might also have been at least partially prototyped in Hypercard (though some of them seem to me like they'd be more complex than Hypercard).

[0] https://wiki.scummvm.org/index.php?title=Mohawk

Sure, I think many of us are doing the best engineering work that we can given the industry situation. I've also seen so many of my peers, some of our brightest minds, waste their careers on stuff that a proper Ethics Board might stop or at least ameliorate. I can work to be the best engineer I can be and still wish we were an industry that actually respected engineering, not just used the title like a party favor that has no inherent meaning.

Though still useful to remember that some of the earliest mathematical write ups of the Halting Problem were also by Alonso Church and directly in the lambda calculus. The Church-Turing Theorem is a lasting reminder that the two worlds imperative and functional describe the same algorithms (form the set of Turing Completeness).

But again, the context is not about humans trying very hard to stick to problems in "terminating space" when writing software, but about LLMs with no such compunctions/boundaries finding inputs that break "terminating space assumptions". (Whether or not you also believe that LLMs are capable of staying within the lines of "terminating space" when generating code.)

Generally speaking, yes, humans want to design programs as best they can in the world of safely terminating applications. Humans aren't perfect at it today, given practical real world data such as CVE databases. Trying to hope humans become perfect to safeguard the world against LLMs like the Googler quote way above is the thing I find futile. Humans aren't going to magically get perfect. We need good enough solutions more than we need perfect solutions. The fear is that LLMs can greatly outpace humans in breaking "good enough" than humans can keep up in building "good enough".

I think it's more that I lean into some of the corollaries that directly factor computation time into account. There is no computer program H that for every program P determines whether P halts faster than running P.

You cannot find/prevent every case of an infinite loop at design time/compile time if the only way to determine a complex enough control flow converges towards halting is to run the full program in a live environment.

You can't prove a program completed successfully if you can't prove a program even completes at all.

I don't know what properties you think people are trying to pragmatically prove about arbitrary programs but "did the program complete successfully" will always be an important, pragmatic property in software development. Especially in the pragmatic world where so much of our software is chaining smaller programs together to solve a task.

I'm saying we can't write perfectly bug-free software because of the Halting Problem and the inability to prove any given loop will not be infinite until running that loop. Perfect remains the enemy of the good and we certainly write a lot of "bug-free-enough" software without worrying about the Halting Problem day-to-day. But if you are saying the world needs to write perfectly bug free code starting tomorrow because LLMs will find all the vulnerabilities and sandbox escapes the Halting Problem is absolutely one of the reasons we can't ever provably hit that "perfect" target. We still need to find "good enough" or we give up on software development altogether and that's not what I'm advocating. Perfect is the enemy of the good. Mathematically perfect provably does not exist. Software will always have bugs, especially in the world with a threat model of active brute force machines.

All of Cyan's games were in Hypercard up to Myst. (Cosmic Osmo and Spelunx were the other two.)

Myst ran in Hypercard in early Mac releases but switched to a cross-platform runtime Broderbund built to sell Myst on Windows CDs (and consoles and more).

Riven was also majority designed/prototyped in Hypercard as a development platform, but more directly targeted from the beginning that same runtime Broderbund built for running Myst cross-platform.

We absolutely have pragmatic compromises and shortcuts for dealing with termination problems, but that doesn't mean we've solved the Halting Problem, it means we've adapted to coexistence with it. (And maybe we've coexisted with the Problem for long enough it feels like most of those adaptations are sufficient day to day, which makes it all the harder to appreciate the bugs that are always there we just mitigate enough to worry about them less.)

Potentially Infinite Loops are a great power. We've learned in most programming languages the "Uncle Ben lesson" that with such great power, comes great responsibility. In most programming languages we don't want to remove the ability to infinitely loop, because we might need that power, we work on ways to limit that responsibility (loop guards and timeouts and cancellations and teardowns). But it will likely always be possible to see some code spin in a loop we can't tell is accidentally infinite or just a loop with a lot more work than we expected. The infinite spin wait will always be a risk in our code.

I think it has a lot to do with the Halting Problem.

My resume includes a bunch of time at a primarily Civil Engineering firm and one of the things I took away from that was also some respect for this "title inflation" issue. That company would not allow any "Engineer" in a title that didn't involve someone without up-to-date PE credentials. Technically my title the whole time there was "Senior Software Developer". I still feel guilty switching my resume back to "Senior Software Engineer" to not have to explain that "gap" to software interviewer who somehow think "Developer" is a less important title than "Engineer" and don't understand title inflation in our industry.

(At one point I even debated the value of getting PE credentials at my age for extra leverage in that company.)

The credentials and rigor are what Professional Engineering is supposed to include. The credentials help give bite to Ethics Boards and other tools used to keep the entire profession honest and safe. The rigor is supposed to include things like making sure that you are solving the right problems.

Many people's lives do depend on software today. Insurance software dictates who gets treatment and who doesn't; that's real lives at stake. Finance software controls access to things like food and shelter; that's real lives at stake. Firmware in prosthetics and diabetic injectors and so on and so forth. Software runs the world, we pat ourselves on the back saying, but forget the world is full of real lives.

Back in the day companies used to have productization teams that separated pie-in-the-sky R&D from product, product teams, and product-like marketing.

Bring to mind that old classic cliche about never trust a salesperson who always says the word "honest" or uses the phrases "to be honest" or "honestly" because they are probably lying in that moment.

It's my view of the Halting Problem that we've known for a surprisingly long time that eliminating all software bugs is mathematically impossible and should stop letting perfect get in the way of the good.

Especially with the more recent relative of the Halting Problem combined with the Church-Turing Theorem that found mathematical proof of a "0-day" sandbox escape in the Universal Turing Machine itself.

We have always lived in a house of glass. LLM agents automating trebuchets for rock throwing certainly seems like a bad idea to me and "let's simply eliminate all software vulnerabilities" an interesting bit of ostrich work (stick your head in the sand and hope it all gets better).

I was feeling similarly: epics with redux-observable but swapping RxJS for Effect.

I was reading more into this specific in the project goals:

> Consistently use pledge(2) and unveil(2) across the code base.

Both link to man pages that seem rather OpenBSD-specific to me. Seems an interesting requirement/goal, but I'm afraid I don't know enough OpenBSD-specifics to know much more about why this is a goal or what the project gains from having it as a goal even if I can appreciate it as a goal that certainly seems unlikely to upstream into git itself.

(ETA: Which yeah, it does seem like the Comparisons page includes some of that reasoning, but not well enough I caught on first skim and I'm still not sure I understand it on second reading, but interesting.)