What they're describing is well documented, but my understanding is that the reality is a blend of what you're describing and what they're describing.
To this day there's significant social pressure to not acknowledge how much racism and racial division played a role in them growth of suburbs in the US, but ultimately it's the documented history which is revealed to those who research the topic.
In many cases individual families were not overtly racist but they were caught up in the economic effects created by racist dynamics and felt they had no choice to go along. If property prices in your neighborhood are decreasing, because neighbors are leaving, and you have the means would you not feel compelled to leave to somewhere with rising property values? Real estate firms intentionally tried to create waves of fear to get people to rush to move, selling low, and then profiting on selling to newer Black families.
It was common for suburbs to have deed restrictions limiting areas by race, and for a while federal housing guidelines would not underwrite developments that did not racially segregate.
At the same time there were massive amounts of state & federal funding pouring into suburbs and highly disruptive unpopular overhauls occurring in cities while cities were also losing tax revenue. For people with the option the future of good living seemed like it was in the suburbs independent of segregation, but part of what fueled the frenzy was the racial segregation.
I think it's important to remember that the 1950s and 1960s were the time when western society really started to swing the government around for each and every thing in a way what we think is normal now but was fairly unprecedented at the time. When the government is seemingly capriciously regulating your life, pulling strings to get neighborhoods redeveloped in accordance with some new vision, bulldozing other neighborhoods for highways, that's not someplace you want to put down roots, raise your family or be in it for the long haul.
Hate to break it to you but that wasn't new in the 50s and 60s. The mechanisms by which it was done were changing away frome the machine politics of earlier eras - but ways to regulate what can and can't be done by neighborhood have been around since the birth of the country. Use of eminent domain for public works private ventures is at least as old as the railroads. Planned suburbs, company towns, bedroom communities and the like are all 19th century "new" things in the US.
The "new" part was who it was happening to. Instead of just stealing some poor hicks town for a dam and reservoir (after circling the plan for years to depress land values of course) they were interfering with substantially more established communities in far more volume than the railroads ever had. And it was more than just the highways, zoning codes and all manner of municipal regulation proliferated hugely over this time bringing government into people's lives (remember, the economy was way different too, people didn't all work in cube farms with a compliance department between them and the rules).
All those centrally planned things you mentioned were green(ish) field developments
I've thought about it a bunch over the years and my advice is to follow a few principles: procedural elements should almost always impact how the player plays, procedural elements should cross-interact with each other as much as possible, and procedural elements should be understandable to the player.
As an example in No Man's Sky the player immediately starts with a jetpack. It makes it so the terrain is approached the same way every time: you just jetpack over it. Very rarely something is tall enough to require you to walk around.
Legend of Zelda: Breath of the Wild is a positive counter example. You have stamina so you're constantly thinking about the height of cliff faces, you can glide so you're thinking about height points and straight lines through the world, cliff faces cannot be climbed in rain so you think about the weather, slopes can be slid down on a shield, etc. There are a bunch of systems that may you think about the topology of the terrain, so even just varying the height map becomes interesting.
Similarly in No Man's Sky there are different resources but they work the same way on each planet and the player interacts with them pretty much the same way everywhere.
When I say elements should be "understandable" what I mean is that a trap, which Dwarf Fortress falls into, is to add a vast simulation which the player feels they can never really grasp. Simulations should not be a black box because then they begin to feel like a random number generator.
The aim shouldn't be to make an "infinite" game but to make a very interesting system for the player to slowly understand and master. The developer shouldn't just add stuff, but they should think about the long journey (and eventual mastery) a player might take as they spend significant time with the systems.
I'm far outside the music creation space so you're basically asking me to spitball something, but I'll try!
I think "make it observable" is a good principle for a lot of software, but also is useful here. Like if you have something changing in how it operates think about perceptual clues that are unobtrusive but give the user a sense of what's going on. Think a car engine sounding weird, a laptop getting hot, or a water bottle being filled up rising in pitch.
Being able to rapidly clue in to how something is running in a bunch of different ways is useful. In synth plugin systems I've seen with node graphs I think having some sort of perception of data traveling that you can assess at a glance could be useful. I can see both color and perhaps the "texture" (dotted, dashed, etc.) of the connections being mapped to some important property of what's being transmitted.
On the "cross interactions" thing perhaps there's a design opportunity to find interesting properties of different components you wouldn't normally expose that you can feed into other systems. Perhaps if audio were to clip that is both something you don't want but also a control signal that can feed into something that self-corrects, or even entirely changes the composition. With that you might have some sort of dynamic gain that as it approaches clipping it steps into a new composition creating a strange "ecosystem" of sound.
In general there's some interesting opportunities to try to create real systemic components that try to make mechanisms with interesting properties rather than precisely controlled things. Perhaps you add an input that pulls the current moon phase, astrological signs, time of day, or weather. Then your composition could change and be a sort of live work each time, but not in a totally arbitrary way. If you wanted to extend the idea of "observability" all the way to the user you could by convention add some brief narration at the start describing the conditions of the composition "It is Wednesday. Rain is forecasted. The following composition has been changed accordingly."
It also may be interesting to weave in more sophisticated mathematical systems, or physics simulations, and then feed them into other components. It'd be quite odd but I can imagine like a bunch of balls on ice floating around and when they touch that creates a signal output, but you could have an input that's like "table shake". It'd be fun to see a program triggering these sort of rube goldberg-esque chain of things to create some sort of interesting sound scape.
Very helpful, thank you. Great ideas. Some of those exact things I've actually already planned or implemented, for the exact purposes you describe, and some are things I haven't at all thought of but which are definitely worth looking into.
That’s technically correct, but it still means that someone has to write the formal specs that Claude’s output is verified against, and someone has to design the formal languages the specs are written in. And once you have formal specs that truly covers all aspects that you ever will care about, it’s unclear if you couldn’t instead build a non-LLM mechanism that efficiently and deterministically spits out an implementation of such a spec.
I expect in the future it will become hybrid. Formal specs provide guardrails for LLMs / AI but within those guards LLMs will author traditional compiler programs and at times drop-down to manually compile / prove certain snippets.
Could we describe the first humans manually writing Assembly and their own higher level abstractions as "compilers"? Loosely I think we could, and LLMs fit the same mold.
I disagree in the sense that source code (compiler input) leaves little space as to the behavior of the resulting program. With LLMs, either there is much more implied leeway, in which case I’d argue that it’s different in nature. Or the specs will restrict the LLM output to a similar extent as a conventional programming language restricts a compiler’s freedoms, in which case it’s not clear that LLMs are the most expedient technology for generating that output.
Levels of abstraction actually matter with regard to how much observable behavior they leave unspecified, and with regard to how much control is needed over each respective behavioral aspect.
I don't think this is accurate. AI is driving the cost of software towards 0 and these AI models themselves are software.
Releasing the models for free accelerates the trend but if you're a startup that needs leverage it's a good way to build brand and customer momentum that will be relevant in the more established future market.
I can see an American company taking on the same strategy, and in fact Thinking Machines based out of San Francisco did that just a few days ago by releasing their first model with open weights.
