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.
Thanks, that sounds interesting. I learned a tiny bit for Forth for fun a long time ago but no one else seems to use it and it does not seem to have much of an ecosystem so it looks like its only for niche hobby projects? What sort of projects do you use it for?
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.
Thanks for your reply.
In fact, I've grown tired of programming by myself — I do 95% of my coding with Claude Code. But the remaining 5% of bugs can't be solved by the AI agent, which forces me to step in myself. In those cases, I'm thrown into a codebase I've never touched before, and code readability becomes key. That's what drew me to this article and to Forth.
I would look into the Rosetta.
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.
> It has a stack but the stack is an implementation detail, not a robust abstraction.
Not exactly. Not only the stack is central in the design of Forth (see my comment over there [1]).
It seems to me that a point-free language like Forth would be highly problematic for an LLM, because it has to work with things that literally are not in the text. I suppose it has to make a lot of guesses to build a theory of the semantic of the words it can see.
Nearly every time the topic of Forth is discussed on HN, someone points out that the cognitive overload* of full point-free style is not viable.
I didn't finish my second sentence: not only the stack is a central element in the design of Forth, it also has 2 of them: data stack and return stack. the return stack is also used directly by programmers.
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.
reply