crq-yml

This is exactly how it was back then, roughly from when the 386-based PC clones appeared up through Windows 7. The best thing you could do was ask the local computer stores about what configurations they were building, since they got to see more hardware come through. But they struggled too. The system the store built for me in 2001 had an Athlon Thunderbird running 1.4GHz and cooling tech hadn't caught up so it hit the failsafe temps during long sessions of Counter-Strike and Serious Sam. Later, wiser me eventually figured out, two computers later, that the power supply was probably the culprit, but this wasn't much of a topic of discussion yet - power supply efficiency wasn't a priority in the 90's.

Unmentioned elephant: Work. From. Home.

Downtown SF has not had lively nightlife in most living memory, but the commuter crowd filled it up and gave it some bustle. That era ended with 2019 and all the activity has shifted to the neighborhoods, which always had the better activity destinations.

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.

I'm actually really happy to see a fresh "just Pascal", and one that is aiming for a slim bootstrap at that.

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.