Fix things spotted by @jcorbin

Author: dfellis

docs/blog/posts/gpus_lisp_machines.md

@@ -32,9 +32,9 @@ Lisp Machines have many [foundational Lisp functions implemented as CPU instruct
 
 I would argue that it is the *lack* of ABI stability that the Lisp Machines exhibited. [Even from the same company in the same series of Lisp Machines](https://en.wikipedia.org/wiki/Lisp_machine#Initial_development) core elements of the ABI such as the byte length of [CPU words](https://en.wikipedia.org/wiki/Word_(computer_architecture)) would change, let alone the instruction set they run. The stable API of the machines was the *lisp language itself*. This was text-based and largely cross compatible between the various Lisp Machines, even from different companies. You could not distribute binaries of Lisp Machine applications, you *had* to distribute source code, because the binary, if you even bothered to access it, would differ wildly between machines.
 
-If you've played a modern PC game, you may have noticed while the game is starting it saying "Compiling Shaders" or "Compiling Vulkan Shaders." (Or worse, noticed some modern games stutter at random points that would have run without a hitch on older games.) These shaders are similar in many ways to the Lisp that ran on Lisp machines, though the shader languages ([and there are a few](https://en.wikipedia.org/wiki/Shading_language)) are an almost abhorrently anti-Lisp requiring mutable, sometimes hidden, state to even function.
+If you've played a modern PC game, you may have noticed while the game is starting it saying "Compiling Shaders" or "Compiling Vulkan Shaders." (Or worse, noticed some modern games stutter at random points that would have run without a hitch on older games.) These shaders are similar in many ways to the Lisp that ran on Lisp machines, though the shader languages ([and there are a few](https://en.wikipedia.org/wiki/Shading_language)) are a kind of anti-Lisp requiring mutable, sometimes hidden, state to even function.
 
-They represent the units of execution the GPUs are tasked with and must be distributed as source code because the GPUs from different manufacturers and between generations from the same manufacturer have different ABIs -- [the GPU drivers include a shader compiler](https://developer.nvidia.com/docs/drive/drive-os/6.0.8.1/public/drive-os-linux-sdk/common/topics/graphics_content/GLSLCShaderProgramCompiler1.html#ariaid-title1) that the game must invoke to translate their shader code into what the GPU can run. Well-written games compile them at startup, and potentially cache them for your particular GPU + driver version (because the driver may also [update the firmware the GPU runs](https://nvidia.custhelp.com/app/answers/detail/a_id/5411/~/nvidia-gpu-uefi-firmware-update-tool) so old compiler output is no longer valid) so they only have to be compiled on the first start of the game and never again, while lesser games lazily evaluate them as needed, and this can cause a stutter in frame generation while it is waiting on the necessary code to be run to actually be available to run.
+They represent the units of execution the GPUs are tasked with and must be distributed as source code because the GPUs from different manufacturers and between generations from the same manufacturer have different ABIs -- [the GPU drivers include a shader compiler](https://developer.nvidia.com/docs/drive/drive-os/6.0.8.1/public/drive-os-linux-sdk/common/topics/graphics_content/GLSLCShaderProgramCompiler1.html#ariaid-title1) that the game must invoke to translate their shader code into what the GPU can run. Well-written games compile them at startup, and potentially cache them for your particular GPU + driver version (because the driver may also [update the firmware the GPU runs](https://nvidia.custhelp.com/app/answers/detail/a_id/5411/~/nvidia-gpu-uefi-firmware-update-tool) so old compiler output is no longer valid) so they only have to be compiled on the first start of the game and never again, while other games lazily evaluate them as needed, and this can cause a stutter in frame generation while it is waiting on the necessary code to be run to actually be available to run.
 
 ## Use-cases for GPUs and Lisp Machines
 
@@ -48,7 +48,7 @@ There's a common thread in all of these: they're either at the edge of what we c
 
 ## It's the Finance and Tech Bros Again?
 
-First, I consider the "Tech Bro" and "Finance Bro" stereotype mostly unhelpful and often founded in a sense of jealousy. I'm closer to a stereotypical nerd, but I worked with men (and a few women, shoutout to Brophia, she knows who she is 😉) who worked out, partied on the weekends, and were also razor-sharp, kind to their peers, and seemingly in control of their life to a degree that felt impossible. They're great to work with and are unfairly lumped in with those who I *think* the "Bro" stereotype is levvied at: those who seem to coast through life doing what they want with the confidence that they can do anything and using social connections to erase their mistakes from the record. It is *that* collection of "Bros", both the good and the bad, that is the audience of GPUs now and Lisp Machines then.
+First, I consider the "Tech Bro" and "Finance Bro" stereotype mostly unhelpful and often founded in a sense of jealousy. I'm closer to a stereotypical nerd, but I worked with men (and a few women, shoutout to Brophia, she knows who she is 😉) who worked out, partied on the weekends, and were also razor-sharp, kind to their peers, and seemingly in control of their life to a degree that felt impossible. They're great to work with and are unfairly lumped in with those who I *think* the "Bro" stereotype is levied at: those who seem to coast through life doing what they want with the confidence that they can do anything and using social connections to erase their mistakes from the record. It is *that* collection of "Bros", both the good and the bad, that is the audience of GPUs now and Lisp Machines then.
 
 Lisp running on Lisp Machines and GPU Shaders on the GPU are both high-level abstractions on the hardware, but the hardware is meant for high performance code that deeply understands the hardware to extract the most amount of performance out of it possible, but the hardware is highly variable from vendor to vendor, even generation to generation in the same vendor, and both the hardware and the compiler may have bugs or idiosyncrasies to work around. To write code for that environment requires a depth of knowledge, a confidence that you can adapt, and energy to persevere that is most common in young, smart professionals.
 
@@ -110,6 +110,6 @@ This is an explicit objective of the Alan programming language. The focus at the
 
 The language will work on any CPU architecture (testing on x86-64 and ARM64, was testing on RISC-V until I melted my test board), any GPU (testing on nVidia, AMD, Intel, Apple, and Broadcom GPUs), and any operating environment (testing on Windows, MacOS, Linux, and Chromium right now. Want to expand to BSD, Android, and iOS eventually), while looking similar-ish to Typescript for easier adoption. It's *already* much nicer to work with than the WebGPU API and capable of 90% of the same things.
 
-The unfortunately poor management of Symbolics doomed it, but that wouldn't have doomed the entire Lisp Machine concept. What doomed them all was an lack of desire or inability to make them more accessible to "regular" developers, increasing the supply of talent, some of whom would be hired by the existing demand that they had demonstrated, and some of whom would become new sources of demand as they came up with new and interesting ways to use it. By raising the bar on who could use it by raising the stakes so high on its use, they strangled the ecosystem before it could self-support without outside funding propping it up.
+The unfortunately poor management of Symbolics doomed it, but that wouldn't have doomed the entire Lisp Machine concept. What doomed them all was a lack of desire or inability to make them more accessible to "regular" developers, increasing the supply of talent, some of whom would be hired by the existing demand that they had demonstrated, and some of whom would become new sources of demand as they came up with new and interesting ways to use it. By raising the bar on who could use it by raising the stakes so high on its use, they strangled the ecosystem before it could self-support without outside funding propping it up.
 
 Alan will provide a GPGPU programming language for the rest of us, and it will ride on the coattails of the backlog of PC games and the WebGPU initiative to normalize the behavior across GPUs and make the leaky abstraction, if not less leaky, then less murky, so it is less difficult to debug when something goes wrong.