The Web is an ads platform with useful functionality as bait.
That's all there really is to it: Mosaic added image support. Investors got excited and asked if the images could animate, if they could record click data and credit card data, if they could add video and additional presentational elements. Holistic user experiences were secondary.
To move forward we have to accept that most of this wasn't an accident and it needs some breaking changes.
Forth could make a case for "faster" in compilation, at least, since it's aggressively machine-level(in a traditional assembly-up bootstrapped system) but blends a mix of interpreted and compiled. Readable and fast in the real-world cases, OTOH, is a matter of taste and engineering practice. I'm doing hobby Forth and it's a blast - it starts off as a crude load-and-store Fortran-like language, and gradually evolves as you stumble into new idioms. If I had to work with a team, I would probably yearn for a Pascal where some bureaucratic boundaries exist on what can be done.
I don't really see this as a Waymo story(although they are a bad actor) because this kind of blockage is mostly a combination of urban design, infrastructure and norms. Traffic is experienced individually as "that guy cut me off" or "you parked in the bike lane" or "stop riding on the sidewalk" but the accidents and delays are about the times when two people both end up taking the same risk at a conflict point. Those are things that have to be addressed long before the incident, and some countries have done so, while others have not and prefer to displace it onto "individual responsibility", which doesn't change how people drive, it just favors being the biggest on the road and relying on insurance to cover the rest.
The principal thing that changes in this story is that Waymo centralizes the responsibility for the risk-taking, and therefore is easier to hold accountable than a horde of interchangable gig workers, impulsive teenagers, etc. When a Waymo car actually does damage, they don't enjoy the same cost structure as the rest of us. The probability is high that they reached a utilitarian conclusion on the bike lane issue favoring their current approach as "the best across all key metrics". Those metrics can be changed by enforcement, or by fixing the streets. They can use words like "unrealistic" but they are mostly speaking within a particular legislative and infrastructural reality. That reality can change if we expect it to, but it means going back on the individual-responsibility outlook.
Some of the sound drivers would be paired with a machine code monitor, and therefore you could interactively develop by modifying hex bytes, which when you think about it, is basically the prototype for a tracker workflow.
There was definitely a tendency to do "compose on the piano, then arrange" with a lot of the early chiptune workflows though. With Galway's stuff there is more reliance on proceduralism to get those long evolving sequences, something which is actually easier to access when it's built from source files and you can define rhythms, chords, dynamics, modulation as forms of indirection.
This rebuttal only deepens the actual point of the author. All of those tools are made to solve problems specifically formulated within a utilitarian corporate logic, which in turn is going to be socially constructed around the legal and technical environment. Nothing about them reflects inherent goals and challenges of programming.
If you are really doing "personal" computing, you can't scale to the point where you need to think about monorepo vs anything else, you don't have access to departments of specialists, and it is unergonomic to expect yourself to pretend scaling is a thing you will want just because the software ecosystem is shaped that way by default, when your real problem fits in a spreadsheet. Everything you do with data ultimately must be crunched down into something legible within your own bandwidth. This is something everyone who pursues personal information management tooling in their lives ultimately has to come to terms with - overdoing it and ending up with a useless pile of notes and references instead of good distilled information is a typical outcome.
There's an artistic thread in game coding - one that isn't the norm, but which I think RCT is exemplary of - that holds that mechanical sympathy is important to the game design process. A limit set around NPOT maximums and divisions and lengths of pathfinding is allowing the machine to opine, "you will actually do less work if you set the boundary here". Setting those limits tends to inform the shape of resulting assets as something tiny and easy to hardcode.
The thing that changed during the 90's is that mechanical sympathy became optional to achieving a large production. The data input defining the game world was decoupled into assets authored in disconnected ways and "crunched down" to optimized forms - scans, video, digital painting, 3D models. RCT exhibits some of this, too, in that it's using PCM audio samples and prerendered sprites. If the game weren't also a massive agent simulator it would be unremarkable in its era. But even at this time more complex scripting and treating gameplay code as another form of asset was becoming normalized in more genres.
From the POV of getting a desired effect and shipping product, it's irrelevant to engage with mechanical sympathy, but it turns out that it's a thing that players gradually unravel, appreciate and optimize their own play towards if they stick with it and play to competitive extremes, speedrun, mod, etc.
The 64kb FPS QUOD released earlier this year is a good example of what can happen by staying committed to this philosophy even today: the result isn't particularly ambitious as a game design, but it isn't purely a tech demo, nor does it feel entirely arbitrary, nor did it take an outrageous amount of time to make(about one year, according to the dev).
They can produce idioms that resemble the flow of Forth code but when asked to produce a working algorithm, they get lost very quickly because there's a combination of reading "backwards" (push order) and forwards (execution order) needed to maintain context. At any time a real Forth program may inject a word into the stack flow that completely alters the meaning of following words, so reading and debugging Forth are nearly the same thing - you have to walk through the execution step by step unless you've intentionally made patterns that will decouple context - and when you do, you've also entered into developing syntax and the LLM won't have training data on that.
I suggest using Rosetta Code as a learning resource for Forth idioms.
I have just spent a month writing about 2000 lines of Forth. My answer is no, at least w/r to generating something that looks like the by-hand code I wrote. LLMs coast by on being able to reproduce idiomatic syntax and having other forms of tooling(type checkers, linters, unit tests, etc.) back them up.
But Forth taken holistically is a do-anything-anytime imperative language, not just "concatenative" or "postfix". It has a stack but the stack is an implementation detail, not a robust abstraction. If you want to do larger scale things you don't pile more things on the stack, you start doing load and store and random access, inventing the idioms as you go along to load more and store more. This breaks all kinds of tooling models that rely on robust abstractions with compiler-enforced boundaries. I briefly tested to see what LLMs would do with it and gave up quickly because it was a complete rewrite every single time.
Now, if we were talking about a simplistic stack machine it might be more relevant, but that wouldn't be the same model of computation.
Korg satisfies both ends of this spectrum in its different products. The Microkorg 2 is the update of its record-setting best-seller built around "here is a giant preset knob that has sounds organized by genre". You can program a Microkorg and it does have plenty of depth, but the general idea of it is to be a go-to "recall" box for the quintessential synth sounds.
While the feature is useful, in some senses it's not terribly important to have a sound be exact, because you're giving a performance to the circumstance. Acoustic instruments react to temperature and humidity and all of that - it worked fine for thousands of years of music.
TBH I think the greatest benefit is on the documentation/analysis side. The "write the code" part is fine when it sits in the envelope of things that are 100% conventional boilerplate. Like, as a frontend to ffmpeg you can get a ton of value out of LLMs. As soon as things go open-ended and design-centric, brace yourself.
I get the sense that the application of armies of agents is actually a scaled-up Lisp curse - Gas Town's entire premise is coding wizardry, the emphasis on abstract goals and values, complete with cute, impenetrable naming schemes. There's some corollary with "programs are for humans to read and computers to incidentally execute" here. Ultimately the program has to be a person addressing another person, or nature, and as such it has to evolve within the whole.
I'm pretty sure that it's not exactly about the code, it's a case of having honed skills and techniques from multiple different sources - John Romero was bouncing around the industry and working on both larger and smaller productions, multiplatform ports, and different approaches to engine/content(he got his hands on both Origin's and Infocom's stuff, as well as a few other places) - the number of references he brought to the table could not be underestimated. John Carmack didn't have that same experience but would have been able to take a description from Romero of "at Origin we did it like this" and aim to make a very efficient version of it - his growth into borrowing academic research for inspiration came a little later. And there was also the early influence of Tom Hall who was older, able to communicate what he wanted as a producer and probably steered the programming team away from wrong turns a few times.
When you have the experience, you already know how long it takes to implement the majority of the game, when we're speaking of these early 2D games using bitmaps, tiles, small animations and some monospace text. The gameplay code is game-jam sized in most instances, so a majority of it was I/O code and asset pipelines. You can chart a safe course to get through one tiny project, and then another, and another, and build a best-of the routines that worked. The coding style would be assembly-like at this time even if they were using C - no deep callstacks, mostly imperative "load and store", which allows for a lower level form of reuse than is typical these days by breaking down the larger algorithm into "load", "mutate", "mutate", "mutate", "store" each as separate routines. So you end up with some tight code when you get to run it through a lot of projects. Softdisk provided the opportunity for building that and getting paid.
I think the gap comes from the collective/individual divide found elsewhere in Japan/US comparisons. It's just a bit less obvious w/r to art.
In Japan there is a presumed collective endeavor to creativity. That starts in school and continues into the professional world: mangaka will plagiarize from each other in the pursuit of a collective storytelling lamguage (a concept introduced to me by Even A Monkey Can Draw Manga, a great humorous short read on simple realities of the industry with practical advice). Someone who makes a bad drawing is given a lot of leeway to be "pulled back in line", for better or or worse. The professionals complain that everyone copies from everyone else overly much, and the pressure at the top level to continuously put out high level work is deadly intense, but it creates the high standard of uniformity.
But the US culture guarantees a lot of awkward standoffish scenarios because, if you make art, it's positioned relative to the worst framing of your ambition, and this typically means you are viewed as a speculator, someone who is plotting a way to cash in without doing something for others. It's far more acceptable to say that you are an art teacher than an artist because then it locates you within the structure of the firm and the state, which is the "hidden" collective tendency in US culture: be as individual as you want if it builds the nation in balance sheet terms, otherwise you are a failure. Thus the observation from earlier in the thread that a sports fan is more deserving of respect than an amateur athlete - the fan is a consumer, they are participating in the market.
There's a cruel truth to electing to use any dependency for a game, in that all of it may or may not be a placeholder for the final design. If the code that's there aligns with the design you have, maybe you speed along to shipping something, but all the large productions end up doing things custom somewhere, somehow, whether that's in the binary or through scripts.
But none of the code is necessary to do game design either, because that just reflects the symbolic complexity you're trying to put into it. You can run a simpler scene, with less graphics, and it will still be a game. That's why we have "10-line BASIC" game jams and they produce interesting and playable results. The aspect of making it commercial quality is more tied to getting the necessary kinds and quantities of feedback to find the audience and meet them at their expectations, and sometimes that means using a big-boy engine to get a pile of oft-requested features, but I've also seen it be completely unimportant. It just depends a lot on what you're making.
I think the main reason not to go full-throttle into "vibes -> machine code" (to extrapolate past doing it in C) is because we have a history of building nested dolls of bounded error in our systems. We do that with the idea of file systems, process separation, call stacks, memory allocations, and virtual machines.
Now, it is true that vibes results in producing a larger quantity of lower-level code than we would stomach on our own. But that has some consequences for the resulting maintenance challenge, since the system-as-a-whole is less structured by its boundaries.
I think a reasonable approach when using the tools is to address problems "one level down" from where you'd ordinarily do it, and to allow yourself to use something older where there is historical source for the machine to sample from. So, if you currently use Python, maybe try generating some Object Pascal. If you use C++, maybe use plain C. If there were large Forth codebases I'd recommend targeting that since it breaks past the C boundary into "you're the operator of the system, not just a developer", but that might be the language that the approach stumbles over the most.
You will still need the tool but the interface to it may start to change.
A lot of the editing functions for 3D art play some role in achieving verisimilitude in the result - that it looks and feels believably like some source reference, in terms of shapes, materials, lights, motion and so on. For the parts of that where what you really want to say is "just configure A to be more like B", prompting and generative approaches can add a lot of value. It will be a great boost to new CG users and allow one person to feel confident in taking on more steps in the pipeline. Every 3D package today resembles an astronaut control panel because there is too much to configure and the actual productions tend to divvy up the work into specialty roles where it can become someone's job to know the way to handle a particular step.
However, the actual underlying pipeline can't be shortcut: the consistency built by traditional CG algorithms is the source of the value within CG, and still needs human attention to be directed towards some purpose. So we end up in equilibriums where the budget for a production can still go towards crafting an expensive new look, but the work itself is more targeted - decorating the interior instead of architecting the whole house.
I believe Lisp is relatively more understood than Forth these days, in that most of the "big ideas" that have been built in it have also been borrowed and turned into language features elsewhere. We have a lot of languages with garbage collection, dynamic types, emphasis on a single container type, some kind of macro system, closures, self-hosting, etc. These things aren't presented with so much syntactical clarity outside of Lisp, but they also benefit from additional engineering that makes them "easy to hold and use".
Lisp appeals to a hierarchical approach, in essence. It constrains some of the principal stuff that "keeps the machine in mind" by automating it away, so that all that's left is your abstraction and how it's coupled to the rest of the stack. It's great for academic purpose since it can add a lot of features that isolate well. Everyone likes grabbing hierarchy as a way to scale their code to their problems, even though its proliferation is tied to current software crises. Hierarchical scaling provides an immediate benefit(automation everywhere) and a consequent downside(automation everywhere, defined and enforced by the voting preferences of the market).
Forth, on the other hand, is a heavily complected thing that doesn't convert into a bag of discrete "runtime features" - in the elementary bootstrapped Forth, every word collaborates with the others to build the system. The features it does have are implementation details elevated into something the user may exploit, so they aren't engineered to be "first class", polished, easy to debug. It remains concerned about the machine, and its ability to support hierarchy is less smoothly paved since you can modify the runtime at such a deep level. That makes it look flawed or irrelevant(from a Lisp-ish perspective).
But that doesn't mean it can't scale, exactly. It means that the typical enabled abstraction is to build additional machines that handle larger chunks of your problem, but the overall program structure remains flat and "aware" of each machine you're building, where its memory is located, the runtime performance envelope, and so on. It doesn't provide the bulldozers that let you relocate everything in memory, build a deep callstack, call into third-party modules, and so on. You can build those, but you have to decide that that's actually necessary instead of grabbing it in anger because the runtime already does it. This makes it a good language for "purposeful machines", where everything is really tightly specified. It has appealing aspects for real-time code, artistic integrity, verification and long-term operation. Those are things that the market largely doesn't care about, but there is a hint of the complected nature of Forth in every system that aims for those things.
Bloat mostly reflects Conway's law, with the outcome of it being that you're building towards the people you're talking to.
If you build towards everyone, you end up with a large standard like Unicode or IEEE 754. You don't need everything those standards have for your own messages or computations, sometimes you find them counter to your goal in fact, and they end up wasting transistors, but they are convenient enough to be useful defaults, convenient enough to store data that is going to be reused for something else later, and therefore they are ubiquitous in modern computing machines.
And when you have the specific computation in mind - an application like plotting pixels or ballistic trajectories - you can optimize the heck out of it and use exactly the format and features needed and get tight code and tight hardware.
But when you're in the "muddled middle" of trying to model information and maybe it uses some standard stuff but your system is doing something else with it and the business requirements are changing and the standards are changing too and you want it to scale, then you end up with bloat. Trying to be flexible and break up the system into modular bits doesn't really stave this off so much as it creates a Whack-a-Mole of displaced complexity. Trying to use the latest tools and languages and frameworks doesn't solve this either, except where they drag you into a standard that can successfully accommodate the problem. Many languages find their industry adoption case when a "really good library" comes out for it, and that's a kind of informal standardizing.
When you have a bloat problem, try to make a gigantic table of possibilities and accept that it's gonna take a while to fill it in. Sometimes along the way you can discover what you don't need and make it smaller, but it's a code/docs maturity thing. You don't know without the experience.
That's all there really is to it: Mosaic added image support. Investors got excited and asked if the images could animate, if they could record click data and credit card data, if they could add video and additional presentational elements. Holistic user experiences were secondary.
To move forward we have to accept that most of this wasn't an accident and it needs some breaking changes.