I've a retrocomputing project which has been gathering dust since before I used an LLM. The idea is to render an isometric view with Quake-style lightmaps; if scrolling is slow enough I only need to render a small slice of the screen each time. I got as far as a proof of concept on a simulated 286 which indicates the pixels-per-second I can achieve is fast enough. Testing on a real 286 would be the next step.
All the assembly code, and the C harness which loads the textures etc, was hand done by me, and period correct. That's where the fun is!
Outside of that, there are so many anachronisms. I actually built the test geometry as a quake map, and processed it using Quake's BSP/lightmap tools. That's 1996 vintage.. except I'm using a newer Quake editor (Trenchbroom, 2013) and modern forks of the tools. All natively on a modern system with a 4K monitor. Building and non-performance testing of the DOS code happens in a Windows XP (2001) VirtualBox (2007) using its' Shared Folder feature.
I might have time to pick this up again soon. My post-processing of the Quake .bsp presently only handles axis-aligned 64x64 surfaces with some hardcoded texturing assumptions. I'll want a full .bsp-to-isometric-data "renderer" - either written from scratch or somehow derived from Quake's source. But this is all just to enable the 286 assembly code noodling, which is what I want to spend time on!
So I'll probably use Claude to assist with the tooling side. By "assist" I mean "do as much as possible to produce the file format I specify". It doesn't seem much worse to me than all the other modernisms I'm already relying on outside of the core task.
I knew very little of this. I know about the Inns of Court, but I didn't know this was such an Inn; I know what a chancery court is (Delaware has them!) but similarly not that it applied in this case. I've no idea what Michaelmas is, but like Christmas, I assume it's an event and/or season which occurs periodically.
I could still read the text! And it's useful to read texts and understand 95%, or 80%, or even 50%! IMO "fully understand what you're reading" versus "can't understand what you're reading" is a harmfully discouraging dichotomy. You can often gloss over such things rather than struggle with them.
I just wanted to get across that there's more detail to be wrung out of even the first line. You don't need to get all nuances on first read, but they're there. Dickens was known for his observational detail, and also he'd spent a lot of time in London courts on account of his father so knew all these terms well.
Everyone has their own comfort level with reading, and we do just skim things we think unimportant... I often do that until suddenly the book stops making sense, and I have to go back some pages and re-read things which I'd skipped that were clearly important. Different authors have different densities of load-bearing words.
I think it's forgivable if you gloss over this first line and think it might be set in a hotel during a holiday, with some random high-ranking person, because the next 800 pages will make it pretty clear it's about a court. But I am worried that these students, hoping to get an degree in English, would rather guess what's being said, when they had the opportunity to look things up. An afternoon on Wikipedia would do them a world of good.
It strikes me as like setting up an IDE. People have preferences, switching is possible, but there are advantages to saying "we are a Visual Studio + Resharper shop" or "everyone uses IntelliJ to work on this project".
Browser behavior like mixed content warnings (and a clear slide towards discouraging all non-HTTPS traffic) was the impetus for us at Twitch to TLS all our video in the mid-2010s. Mixed content delivery on a website would, I think, also fall below the bar for doing certain kinds of commerce, and ejecting people from your webapp to a separate payment flow discourages spending.
EDIT: I recall reading that the Netflix client can continuously select between multiple content caches. I'm guessing they do this because it's a quality-of-service and capacity win over making a "best guess" at the start of a session, and sticking with it. It should also enable transparent recovery from a broken or slow cache node. If you test in a busy place with multiple caches, the loss of one needn't be a big deal.
> Bizarrely, to protect dBase, there was no compatible Turbo C++ objects integration in dBase (you could import OBJ files from Microsoft C++). There was no way to natively use dBase from Turbo C++ or TurboPascal.
I'm guessing dBase was itself built using Microsoft's compilers, so pulling in other code from the same compiler was plausible. Not a product choice re: the Turbo compilers, just a disjoint path dependency between two acquired product lines (Ashton-Tate's dBase, and Wizard C).
This is the reason that Clipper, a third-party dBase compiler, could only link against .OBJs from particular versions of Microsoft C. Clipper compiles to p-code whose interpreter is implemented in Microsoft C; "linking" a Clipper program is actually linking a Microsoft C program with a static array comprising the Clipper compiler's output. So you can mix in a .OBJ expecting that version of the Microsoft C runtime library. Not a .OBJ expecting the Turbo C++ runtime library.
All the assembly code, and the C harness which loads the textures etc, was hand done by me, and period correct. That's where the fun is!
Outside of that, there are so many anachronisms. I actually built the test geometry as a quake map, and processed it using Quake's BSP/lightmap tools. That's 1996 vintage.. except I'm using a newer Quake editor (Trenchbroom, 2013) and modern forks of the tools. All natively on a modern system with a 4K monitor. Building and non-performance testing of the DOS code happens in a Windows XP (2001) VirtualBox (2007) using its' Shared Folder feature.
I might have time to pick this up again soon. My post-processing of the Quake .bsp presently only handles axis-aligned 64x64 surfaces with some hardcoded texturing assumptions. I'll want a full .bsp-to-isometric-data "renderer" - either written from scratch or somehow derived from Quake's source. But this is all just to enable the 286 assembly code noodling, which is what I want to spend time on!
So I'll probably use Claude to assist with the tooling side. By "assist" I mean "do as much as possible to produce the file format I specify". It doesn't seem much worse to me than all the other modernisms I'm already relying on outside of the core task.