Thanks for the video. Yeah ok actually ~~clankers cavern~~ (no wait that was banjo kazooie, I meant that one with all the sea serpents) was hella laggy, you've brought it all back

I heard somewhere more recently that they probably did it on purpose because they didn't know if the game would be stable using the different settings. Nintendo was known for quality back then so if the game crashed, even a bit more, they thought it would hurt their bottom line.

shlubs who barely passed undergrad data structures and algorithms courses.

And that's the problem with most people getting into IT nowadays, they expect to go to an algorithms course or a development bootcamp and come out knowing everything to make a 6 figure salary, but don't even try to learn what a software dependency is or how to fix their dev environment and expect GPT to shlub it up, when in reality many of these old school software programmers were self learning nerds who were just trying to solve (a) problem, and spent hours doing so.

Common Lisp and Smalltalk provided live development environment where you could run any code as you write it in the context of your application. Even the whole Lisp OS was modifiable at runtime, you could just open code for any running application or even the OS itself, make changes on the fly, and see them reflected. A fun run through Symbolics Lisp Machine here https://www.youtube.com/watch?v=o4-YnLpLgtk

Here are some highlights.

The system was fully introspective and self-documenting. The entire OS and development environment was written in Lisp, allowing deep runtime inspection and modification. Every function, variable, or object could be inspected, traced, or redefined at runtime without restarting. Modern IDEs provide some introspection (e.g., via debuggers or REPLs), but not at the same pervasive level.

You had dynamic code editing & debugging. Functions could be redefined while running, even in the middle of execution (e.g., fixing a bug in a running server). You had the ability to attach "before," "after," or "around" hooks to any function dynamically.

The condition system in CL provided advanced error handling with restarts allowed interactive recovery from errors (far beyond modern exception handling).

Dynamic Window System UI elements were live Lisp objects that could be inspected and modified interactively. Objects could be inspected and edited in structured ways (e.g., modifying a list or hash table directly in the inspector). Modern IDEs lack this level of direct interactivity with live objects.

You had persistent image-based development where the entire system state (including running programs, open files, and debug sessions) could be saved to an image and resumed later. This is similar to Smalltalk images, but unlike modern IDEs where state is usually lost on restart.

You had knowledge-level documentation with Document Examiner (DOCX) which was hypertext-like documentation system where every function, variable, or concept was richly cross-linked. The system could also generate documentation from source code and comments dynamically. Modern tools such as Doxygen are less integrated and interactive.

CL had ephemeral GC that provided real-time garbage collection with minimal pauses. Weak references and finalizers are more sophisticated than most modern GC implementations. Modern languages (e.g., Java, Go, C#) have good GC but lack the fine-grained control of Lisp Machines.

Transparent Remote Procedure Calls (RPC) allowed Objects to seamlessly interact across machines as if they were local. Meanwhile NFS-like but Lisp-native file system allowed files to be accessed and edited remotely with versioning.

Finally, compilers like Zeta-C) could compile Lisp to efficient machine code with deep optimizations.