The Future Was Here & It Is Again

By Mike Levin

The Origins of the Amiga

There was a book back in April of 2012 called The Future Was Here by Jimmy Maher bout the Amiga Computer, ostensibly from Commodore Computers, but really from the Atari engineer who brought us the Atari 2600 which arguably kicked off the entire home computer revolution. Sure, there was Pong and the Fairchild game machine before it, but Atari really made it mainstream in such a way that it still reverberates loudly today. The first significant machine learning project by DeepMind that thawed the AI winter was based on playing Atari games, and the company is back at the forefront of the retro computing movement. The Amiga computer was designed by Jay Miner, the same chip designer as who made that original Atari. It was his dream computer. And it was the future.

The Forgotten Pioneer

The Amiga computer is mostly forgotten today, but rest assured aside from the always-crashing and being architecturally limited to platform-game bitplanes (versus the chunky graphics of Nvidia and DOOM), it is the multi-tasking, multi-media experience that both Steve Jobs and Bill Gates were copying that led us to where we are today. Even though it ultimately lost because of Commodore shenanigans, the Amiga computer was the living manifestation, the clear vision, of where we were going with technology. And we have arrived. Everything from playing both videogames and video so well on a “serious” computer, to the way virtual desktops are handled so that you can have mentally mapped workspaces as numerous as the video-RAM on your computer. Today’s computers are modeled on the Amiga ideal, and hardly anybody knows it.

The Unix Connection

While the Amiga wasn’t Linux-based (Linux wasn’t a thing when Amiga came out in 1985), nor was it Unix-based, it was extremely Unix-like. It’s operating system, AmigaOS was actually derived from was… uhmmm… T-something. Perplexity?

Perplexity: The operating system that AmigaOS was derived from, which was written in BCPL, is called TRIPOS.

TRIPOS was a multi-processing operating system designed for 68000 computers[9]. Commodore, the company behind the Amiga, purchased TRIPOS because the development of their own DOS subsystem failed to meet deadlines[9].

Key points about TRIPOS and its relation to AmigaOS:

1. AmigaDOS, which is the disk operating system portion of AmigaOS, was based on TRIPOS[1][9].

2. In AmigaOS 1.x, the AmigaDOS portion was based on TRIPOS and written in BCPL[1].

3. TRIPOS consisted of a kernel, a DOS library, and a collection of user mode tools. Commodore integrated only the DOS part of TRIPOS (including the tools) into AmigaOS[9].

4. The use of BCPL in TRIPOS led to some unique characteristics in AmigaOS, such as the use of BPTRs (BCPL pointers) and BCPLstrings, which required special handling in later versions of the operating system[10].

5. The integration of TRIPOS into AmigaOS was considered an emergency solution, as Commodore-Amiga had originally hired another company to write a DOS called “CAOS” (Commodore Amiga Operating System), but that company failed to deliver on time[11].

This BCPL-based foundation of AmigaDOS remained in place for the early versions of AmigaOS, but was gradually replaced in later versions. From AmigaOS 2.x onwards, AmigaDOS was rewritten in C and Assembly, while still maintaining compatibility with the earlier BCPL programs[1].

Citations:

[1] https://en.wikipedia.org/wiki/AmigaOS
[2] https://www.softwarepreservation.org/projects/BCPL
[3] https://retrocomputing.stackexchange.com/questions/23591/which-is-the-first-non-assembly-and-binary-language-to-write-operating-system
[4] https://eab.abime.net/showthread.php?t=89449
[5] https://en.wikipedia.org/wiki/BCPL
[6] https://www.youtube.com/watch?v=pm-szurM5VY
[7] https://www.markround.com/blog/2023/08/30/amiga-systems-programming-in-2023/
[8] https://www.lenovo.com/us/en/glossary/what-is-bcpl/
[9] https://www.pagetable.com/?p=193
[10] https://wiki.amigaos.net/wiki/Basic_Input_and_Output_Programming
[11] https://news.ycombinator.com/item?id=37443887

Right! So, while not Unix, TRIPOS was directly inspired by it, and under Amiga’s version of a mouse-and-windows desktop operating system called Workbench, lived an extremely efficient and minimal Unix-like OS; it’s main downsides being the way it managed memory during multitasking that made it crash all the time. Perplexity?

Perplexity: The main downside of TRIPOS and ultimately AmigaOS in terms of memory management with multitasking that led to frequent crashes was the lack of memory protection. AmigaOS operated in a single address space with totally unprotected memory[4]. This design had several critical implications:

1. Shared memory: The system used shared memory for message passing between tasks, including user tasks, system tasks, and device drivers[4]. While this made communication efficient, it also meant that all tasks shared a single view of memory.

2. No isolation: Without memory protection, buggy software could easily corrupt system services or other applications’ memory spaces[4].

3. System-wide crashes: Memory corruption often resulted in system-wide crashes instead of just individual program crashes[4].

4. Reliance on “well-behaved” programs: The operating system was designed with the assumption that user programs would be “well-behaved” in allocating and releasing memory as needed[5]. However, this was not always the case in practice.

5. Fragmentation issues: The memory allocation system could lead to fragmentation problems, especially when programs misused memory allocation functions[5].

This lack of memory protection was a fundamental design choice in the original AmigaOS, and it persisted in later versions due to backward compatibility concerns[4]. While this design allowed for high performance on the limited hardware of the time, it came at the cost of system stability and reliability, especially as software became more complex over time.

Citations:

[1] https://wiki.amigaos.net/wiki/Exec_Memory_Allocation
[2] https://groups.google.com/g/comp.sys.amiga.misc/c/TETaKud6YbE
[3] https://www.osnews.com/story/12969/memory-management-in-amigaos-40-explained/
[4] https://retrocomputing.stackexchange.com/questions/9664/protected-virtual-memory-support-in-classic-amigaos
[5] https://eab.abime.net/showthread.php?t=118048
[6] https://forum.amiga.org/index.php?topic=46360.30
[7] https://users.cs.jmu.edu/abzugcx/Public/Student-Produced-Term-Projects/Operating-Systems-2003-FALL/Amiga-by-Kevin-Marinak-Jon-Bradley-Holly-Medeiros-John-Feehan-Nimish-Patel.pdf
[8] https://eab.abime.net/showthread.php?p=1583521

Right, right! So the future was here and it was the Amiga. But design-wise there were a couple of critical flaws that couldn’t be overcome, the first being that memory management stuff inherited from TRIPOS that made it crash all the time, but which did give it a lot of UNIX-like features as a consolation prize. The second was that planar graphics I mentioned earlier, though I don’t think I made it clear. Amiga was designed for platform games like Donkey Kong to be super-smooth, and architecturally… ughhh… Perplexity?

Perplexity: The Amiga’s graphics design, while innovative for its time, had a critical limitation that hindered its ability to keep up with the evolving demands of 3D graphics and games like DOOM. This limitation was its reliance on planar (or bitplane) graphics instead of chunky graphics.

Planar vs. Chunky Graphics

Planar graphics, used by the Amiga, organize pixel data across multiple bitplanes. Each bitplane represents one bit of color information for every pixel on the screen. While this approach had some advantages, it became a significant drawback as graphics technology progressed.

Chunky graphics, on the other hand, store all color information for each pixel in consecutive bytes of memory. This format is much more suitable for 3D graphics and texture mapping.

Limitations of Planar Graphics

1. Inefficient for 3D rendering: Planar graphics made it difficult to efficiently manipulate individual pixels, which is crucial for 3D rendering and texture mapping[5].

2. Complex color manipulation: Changing the color of a single pixel required accessing multiple bitplanes, making it more computationally expensive than chunky graphics[1].

3. Memory access patterns: Planar graphics required fetching data from several places in RAM to display a single pixel, which was less efficient than the straightforward byte-by-byte access of chunky graphics[8].

4. Difficulty in scaling: While planar graphics allowed for easy scaling of color depth by adding bitplanes, it became increasingly complex and bandwidth-intensive at higher color depths[8].

Impact on Performance

The planar design significantly impacted the Amiga’s ability to handle emerging 3D graphics techniques:

1. Texture mapping: Chunky pixels were better suited for texture-mapped graphics, giving PCs with VGA cards an advantage in this area[5].

2. 3D first-person shooters: Games like Wolfenstein 3D and DOOM, which relied heavily on texture mapping and fast pixel manipulation, were more challenging to implement efficiently on the Amiga’s planar system[5].

3. Conversion overhead: To run certain games or emulate other systems, the Amiga often required “chunky to planar” conversion routines, which added processing overhead[6].

While the Amiga’s graphics system had been innovative and powerful for 2D graphics and certain effects, its planar design became a limiting factor as the industry moved towards more advanced 3D graphics and photorealistic games. This architectural decision, which was difficult to change due to backward compatibility concerns, ultimately contributed to the Amiga falling behind competing platforms in the evolving world of computer graphics.

Citations:

[1] https://www.cosmigo.com/promotion/docs/onlinehelp/gfxHardware-AmigaAGA.htm
[2] https://eab.abime.net/showthread.php?t=88990
[3] https://www.lemonamiga.com/forum/viewtopic.php?t=10074
[4] https://www.reddit.com/r/atarist/comments/6zm442/why_did_the_st_choose_bitplanes_over_packed_pixels/
[5] https://scalibq.wordpress.com/2013/02/08/just-keeping-it-real-part-7/
[6] http://oldwww.nvg.ntnu.no/amiga/amigafaq/AmigaFAQ_16.html
[7] https://www.linkedin.com/pulse/pushing-limits-vintage-computers-simone-bevilacqua
[8] https://www.pouet.net/topic.php?which=10342&page=1

Right, right! So the Amiga computer was really easy to fall in love with. It had all this fundamental first principle stuff spot-on correct in human/machine interfaces. It was fast, colorful, multitasking and the games were great. The price was relatively low for such a seemingly magnificent machine, making it a consumer device, but it was from the now-inept Commodore, having been rendered inept by the chairman Irving Gould driving out Commodore’s founder, Jack Tramiel who originally identified the Amiga as something to fund and acquire from the Atari engineer who was independently developing it.

This is the story of one of these wacky alternative history stories where Commodore could have wound up IBM, Apple, Microsoft and Nvidia rolled into one today had it played its cards right. But the playboy jetsetting millionaire (that was a lot of money at the time) Irving Gould cared more about petty stuff than changing the world. And it’s a story that resonates deeply with me as I went to work for Commodore right there in the suburbs of Philadelphia where I grew up as a result of a series of coincidences which shaped the course of my life.

1I was there in the Commodore mothership right as it was going down. The amount of talk about the last rats jumping off the ship was unending… I guess being that I was one of those rats, and also worked with and for them at one of the Commodore spin-off companies. Ugh! So many stories! Anyway, that was the early 90s and I even went to 2 of the Commodore shareholder meetings at the very well fortified Nassau Kay Club in the Bahamas to appeal to their better judgement. I was barely not kicked out along with the shareholder Richard Ash who actually was physically ejected yelling I don’t want to leave! I don’t want to leavelike of Peter Parker fading away with a finger-snap.

Fast-forward 30-some years. Here we are, me still in the daily grind. The few thousand I had invested in Commodore those days otherwise invested would have made me a millionaire many times over today. But I lost interest in stock and I lost love for technology. Though I tried to recapture that love many times over the years on such red herrings as Microsoft’s Active Server Page Web technology which some may recognize today as those still occasionally around but increasingly disappearing sites that have .asp file extensions. Microsoft seemed like such a safe harbor in a technology storm. Linux was still in its infancy, and Unix was legally embroiled with BSD not yet having become FreeBSD. The only other alternative was the Mac, but Macs being Unix-based was still a decade away. There were no good choices, especially for a slow learner who valued craft and wanted their habits and muscle memories to live forever.

Unrealistic? There’s too much churn in tech to expect the love of craft like woodworking and the long-term muscle memory of musicians playing a musical instrument like a violin? Is that really true, I asked myself. How could hackers be hackers then, if they were not a form of craftspeople? Are they some other kind of pulsing alien brain super-genius human that we mortals have no hope of achieving? I totally elevated folks like Jay Miner on a pedestal, and I still think rightfully so. There’s folks who are the mastercraftsmen of making the tools that make the tools. Is Linus Torvalds one? Maybe, but I’d much more emphatically point out Ken Thompson as a better example. While OSes and design philosophies existed before Ken (and Dennis Ritchie) created Unix, such as Fernando Corbató’s Multics and Douglas McIlroy who invented the concept of piping data, Ken blended it all together into a portable viral meme universal operating system called Unix. Ken is the Einstein-level genius of tech—very rare. Much more rare than the clever copycats whose names we all know, like Steve and Bill. Steve and Bill are much more like Mr. Smithers than Morbo.

I could go through the list of them. Linus is up there, no doubt. He didn’t just port Unix. But his work combined with that of another clever thief’s named Richard Matthew Stallman (or just RMS) who brought the commands of the command-line to what Linus really made with Linux, low-level kernel stuff that brought the machine to life at all when it powered on. It’s like Linus made the electricity of the Frankenstein Monster while RMS was Igor who supplied the brain. People lose these nuances of who did what in tech and which were the fountains from which the genius flowed. Another like Linus is Guido van Rossum, the creator of the Python programming language who is no slouch, but conceptually he borrowed heavily from the ABC programming language of his employers at the time… uh… Perplexity?

Perplexity: The ABC programming language, which significantly influenced Python, was created by Leo Geurts, Lambert Meertens, and Steven Pemberton at the Centrum Wiskunde & Informatica (CWI) in Amsterdam, Netherlands[1][3].

Key points about ABC’s creation and its influence on Python:

1. Development timeline: ABC was designed in the late 1970s and early 1980s[4].

2. Guido van Rossum’s involvement: Van Rossum joined the ABC development team in 1983 and worked on the project until around 1986 or 1987[4].

3. Influence on Python: ABC had a major impact on Python’s design. Van Rossum, who created Python, has acknowledged his debt to ABC and the lessons he learned from the project[2][5].

4. ABC’s goals: The language was designed to be easy to learn and use, intended as an alternative to BASIC, Pascal, or AWK for teaching and prototyping[3][6].

5. Features: ABC introduced several innovative features, including:

   • Use of indentation for statement nesting (later adopted by Python)
   • Strong focus on readability and simplicity
   • Built-in support for fundamental data structures
   • Interactive programming environment[1][3]

While ABC itself didn’t gain widespread adoption, its principles and design philosophy significantly shaped the development of Python, which has become one of the most popular programming languages worldwide.

Citations:

[1] https://www.linkedin.com/pulse/abc-programming-language-santosh-kumar
[2] https://python-course.eu/python-tutorial/history-and-philosophy-of-python.php
[3] https://en.wikipedia.org/wiki/ABC_(programming_language)
[4] https://www.artima.com/articles/the-making-of-python
[5] https://en.wikipedia.org/wiki/Guido_van_Rossum
[6] https://homepages.cwi.nl/~steven/abc/programmers/introduction.html
[7] https://codedocs.org/what-is/abc-programming-language

So Guido and Linus are astounding in their own rights, having profoundly shaped the world with that ever-so-important genuinely altruistic free and open source software (FOSS) worldview and mindset, it’s Leo Geurts (and his ABC team), Ken Thompson (for Unix), Fernando Corbató (for Multics), Douglas McIlroy (for pipes), and… and… well, there’s a couple of others here whose work melded into what today gives us at least a chance at technological freedom and self sovereignty. While Dennis Ritchie was Ken’s collaborator on Unix, writing the whole C-programming language for the purpose, the whole portable OS and virtual machine portability layer thing came from… from… Perplexity?

Perplexity: BCPL (Basic Combined Programming Language) was created by Martin Richards at the University of Cambridge in 1967[4][7]. The language is significant from a virtual machine and portable software perspective for several reasons:

1. Portability: BCPL was designed with portability as a primary goal, making it one of the first programming languages to prioritize this aspect[3][6].

2. Virtual Machine Approach: The BCPL compiler used a two-stage process, generating an intermediate language called O-code[4]. This O-code was then translated into machine code for the target machine, effectively creating a virtual machine abstraction[1][5].

3. Compiler Structure: The compiler was split into a front end and a back end. The front end generated O-code, while the back end translated O-code into machine code. This structure meant that only about 1/5 of the compiler needed to be rewritten to support a new machine, typically taking 2-5 person-months[4].

4. Bootstrapping: Due to its portability and simple compiler design, BCPL was popular for bootstrapping systems. The original compiler, written in BCPL itself, was easily portable[4].

5. Influence on Later Languages: BCPL’s approach to portability and its use of a virtual machine concept influenced later languages and systems, including the development of the C programming language and modern virtual machine environments like the JVM and CLR[5].

This design made BCPL an excellent tool for creating portable software and compilers, significantly influencing the field of computer science and software development.

Citations:

[1] http://gunkies.org/wiki/BCPL
[2] https://www.bell-labs.com/usr/dmr/www/chist.html
[3] https://www.devx.com/terms/basic-combined-programming-language/
[4] https://en.wikipedia.org/wiki/BCPL
[5] https://forums.raspberrypi.com/viewtopic.php?t=15741
[6] https://www.researchgate.net/publication/270884203_The_Portability_of_Quality_Software_Experiences_with_BCPL
[7] https://en.wikipedia.org/wiki/Martin_Richards_(computer_scientist)
[8] https://horizonelectronics.com/virtual-machine/
[9] https://www.lenovo.com/us/en/glossary/what-is-bcpl/
[10] https://martech.zone/acronym/bcpl/

So you see the undercurrents here? The subtext? The invisible lines connecting the loveworthy and the sources of digital sovereignty? BCPL seeded both Unix and the Amiga directly, so it looks like Martin Richards is the real pulsing alien brain genius, right? Well, in an earlier world where research were not as simple as prodding Perplexity to dive deeper and deeper with cited sources, I might stop there and think so. But let’s prod Perplexity a bit more…

Perplexity: You’re right to look for more foundational influences. Let’s delve deeper into the roots of BCPL and its precursors:

Foundational Projects and Influences

1. ALGOL 60: Developed in the late 1950s, it was a significant influence on subsequent programming languages, including CPL.

2. Atlas Autocode: Developed by Tony Brooker at Manchester University in the early 1960s, it influenced CPL’s design.

3. CPL (Combined Programming Language):
   • Initiated at Cambridge University in the early 1960s
   • Key figures: Christopher Strachey and David Barron
   • Goal: Create a more powerful language than ALGOL 60
4. BCPL (Basic Combined Programming Language):
   • Created by Martin Richards at Cambridge University in 1967
   • Designed as a simplified version of CPL for bootstrapping purposes
   • First implemented on CTSS (Compatible Time-Sharing System) at MIT[1]
5. GPM (General Purpose Macrogenerator):
   • Developed by Christopher Strachey
   • Used by Martin Richards in implementing BCPL on CTSS[1]
6. CTSS (Compatible Time-Sharing System):
   • Developed at MIT in the early 1960s
   • Provided the platform for BCPL’s first implementation[1][3]
7. Multics project:
   • Joint effort by MIT, Bell Labs, and General Electric
   • Used BCPL for some system components and utilities[1][5]

Key Figures in Early Development

1. Christopher Strachey: Influential in CPL design and creator of GPM

2. David Barron: Co-designer of CPL at Cambridge University

3. Martin Richards: Creator of BCPL

4. Rudd Canaday: Ported BCPL to Multics and GE-635 GECOS system[3]

5. Doug McIlroy and Bob Morris: Wrote Multics runoff in BCPL[1]

Legacy and Impact

The influence chain can be more comprehensively described as:

ALGOL 60 → Atlas Autocode → CPL → BCPL → B → C → modern languages

BCPL’s contributions:

1. O-code: Intermediate language for portability[2]
2. Two-stage compiler process: Front-end and back-end separation[2]
3. Bootstrapping technique: Used for porting to different architectures[2]

These concepts laid the groundwork for:

• Modern bytecode systems
• Virtual machine architectures
• Portable compiler design

BCPL’s influence extended beyond just C and Unix. It was used in early systems at Xerox PARC, including the groundbreaking Alto project, which in turn influenced modern graphical user interfaces and personal computing[4][8].

Citations:

[1] https://multicians.org/features.html
[2] https://en.wikipedia.org/wiki/BCPL
[3] https://www.bell-labs.com/usr/dmr/www/chist.html
[4] https://en.wikipedia.org/wiki/Xerox_Alto
[5] https://www.ruddcanaday.com/how-c/
[6] http://www.righto.com/2016/06/hello-world-in-bcpl-language-on-xerox.html
[7] https://www.multicians.org/history.html
[8] https://www.theregister.com/2023/03/16/the_xerox_alto_50_years/
[9] https://retrocomputingforum.com/t/bcpl-an-even-simpler-compiler/497
[10] https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/posts/alto2
[11] https://www.softwarepreservation.org/projects/BCPL

And so this brings us to the modern mistake of falling in love with hardware in any way that you think should last a lifetime. It won’t. Hardware decays. It goes in and out of style. It’s the only piece that the product manufacturers can be guaranteed to make money on, because software and alluring of the appeal of selling something intangible with no material costs but potentially huge margins, people like Richard Matthew Stallman who think all software should be free (for he’s actually a software freedom advocate and not a FOSS advocate—NOT the same thing), margins will erode. Hardware decays. Software margins erode. These are truism. Don’t fall in love with your hardware because it will let you down. And don’t think any software tycoon is going to be laughing all the way to the bank forever. Their moneymaker is going to be blackbox reverse engineered, eventually.

In other words, vendors will always tie their product to hardware one way or the other. It will look critical to the product, but that’s just the realities of the day. In the future, all their fancy hardware will just be a virtualized and commoditized component of some other product. Apple resists this reality, but only with lawyers, not with any realistically effective proof against pirating copycats. We Amiga computer lovers know this because we always used to take joy in saying the Amiga could emulate both Macs and PCs—sometimes at the same time—, but because of all that special hardware stuff, a Mac or PC could never emulate an Amiga. And now Raspberry Pi’s and keychain computers can emulate the Amiga! This is the way it is and forever always will be with hardware. Today’s Nvida rack servers will dangle from keychains in a decade or two.

Oh, an other backdrop component of this whole discussion is that I am a slow learner! People who love craft and fall in love with their tools I believe often are. That’s because you learn something interesting about a tool and how it can be used, and you want to explore it. The depth that such explorations require and the neurotransmitter soup that you get addicted to in the process, some blend of dopamine, adrenaline and serotonin I think, doesn’t leave much room left over for the hamster wheel of staying on top of tech churn.

Pshwew! Did that make any sense at all? There’s fast learners out there. They seem to never lose that childhood neuroplasticity. There’s a window in time where a child can pick up multiple languages and new skills much more rapidly than an adult. All that weird cross-wiring creates a capacity that lasts them the rest of their lives. Or maybe they’re born with it and it’s a genetic predisposition. I don’t know. Whether nature or nurture, there’s the Michael Jordan’s out there who excel in basketball, baseball and have tons of business acumen. I guess it’s hard to not mention Elon Musk in all this, a new sort of superhuman turning personality traits that would be a liability in others into impossible to fathom performance performance characteristics.

Uh, yeah… I ain’t that. I am neither a Michael Jordan, nor am I an Elon Musk. I’m not even someone down the genius chain who takes the tools of the genius toolmakers and ingeniously makes new tool-making tools, the way the creator of the Flask library in Python did… uh, who is that and was he the actual innovator? Perplexity?

Perplexity: Flask was created by Armin Ronacher in 2010[1]. However, Ronacher was not the first to use decorators as routers in web frameworks.

The use of decorators for routing in web frameworks predates Flask. Some earlier examples include:

1. Bottle: Created by Marcel Hellkamp in 2009, it used decorator-based routing before Flask.

2. web.py: Developed by Aaron Swartz in 2006, it also employed a form of decorator-based routing.

Flask’s implementation of decorator-based routing was inspired by these earlier frameworks, particularly Sinatra (a Ruby framework). Ronacher adapted and refined this concept for Python, making it a central feature of Flask’s design and contributing to its popularity and ease of use[4][5].

While Flask didn’t invent decorator-based routing, it played a significant role in popularizing and refining this approach within the Python web development ecosystem.

Citations:

[1] https://www.digitalocean.com/community/tutorials/how-to-create-your-first-web-application-using-flask-and-python-3
[2] https://dev.to/alfredo-pasquel/the-top-5-most-used-flask-decorators-3ick
[3] https://www.digitalocean.com/community/tutorials/how-to-make-a-web-application-using-flask-in-python-3
[4] https://www.reddit.com/r/flask/comments/z4lv55/how_exactly_does_approute_tell_flask_about/
[5] https://realpython.com/flask-project/
[6] https://www.sitepoint.com/flask-url-routing/
[7] https://www.moesif.com/blog/technical/api-development/Building-RESTful-API-with-Flask/
[8] https://stackoverflow.com/questions/59789001/how-does-the-route-decorator-used-in-flask-work

My favorite of these down-the-line geniuses right now is Jeremy Howard. Jeremy is a virtual unknown, but a true powerhouse in his own right and making all the difference to me in my life right now. I had all but written off web development. While the Web user interface in how it manifests under both desktop and mobile browsers seems like some sort of panacea cure-all future-proofing last interface you’ll ever need… well, uhm… even Google who brought us ChromeOS on that basis is replacing it with Android on ChromeBooks! That’s a friggin huge recrimination of the browser as the universal user interface! Maybe it’s because of the antitrust case that was won against Google and now threatens to make them spin off the Chrome browser as a separate division, but still! Android beat the Web!

My love for the web as the cure-all universal user interface ended where around 2010 when I had my child, and the JavaScript frameworks really started kicking in. AngularJS hit, and ReactJS was to follow in about 3 years. Hmmm… Perplexity, give me the timeline!

Perplexity: Here’s a timeline of JavaScript frameworks from the AJAX era to the recent trends:

2005: AJAX (Asynchronous JavaScript and XML) gains popularity

• Jesse James Garrett coins the term “Ajax” in a white paper[1]

2006: jQuery released

• Initial version of jQuery, simplifying DOM manipulation and AJAX calls[3]

2010: AngularJS and Backbone.js introduced

• These frameworks bring structure to front-end development[3]

2011: Bootstrap (initially Twitter Bootstrap) released

• Provides a comprehensive set of UI components and responsive design tools

2013: React introduced

• Facebook’s Tom Occhino and Jordan Walke present React at JSConf US[3]

2014: Vue.js released

• Evan You creates Vue.js as a progressive JavaScript framework[3]

2016: Angular 2+ released

• Complete rewrite of AngularJS, offering improved performance and TypeScript integration[3]

2018: React Hooks announced

• Introduces a new way to handle state and side effects in React components[3]

2019-2022: Rise of “Vanilla JS” movement

• Developers start advocating for using plain JavaScript without heavy frameworks

2020-2023: HTMX gains traction

• Promotes server-side rendering and minimal JavaScript usage

This timeline showcases the evolution from AJAX-based development to complex front-end frameworks, and the recent trend towards simpler, more lightweight approaches with Vanilla JS and HTMX.

Citations:

[1] https://blog.risingstack.com/history-of-javascript-on-a-timeline/
[2] https://blog.risingstack.com/the-history-of-react-js-on-a-timeline/
[3] https://www.agiratech.com/the-timeline-of-25-successful-years-of-javascript
[4] https://react-bootstrap.netlify.app
[5] https://www.hackreactor.com/resources/the-history-of-javascript/

So back to Jeremy Howard. But maybe I should mention the guy behind HTMX. This is finitely one of those “before I can tell you that story, I have to tell you this story” moments. The Web became unlovable. And this was so embittering to me after Microsoft stopped supporting Active Server Pages in favor of ASP.NET and its other loser Java-copying variations. Ugh! All good things… Anyhow, I’m not the only one that feels that way, and perhaps Perplexity can say it best, describing one of the most wonderful possible reactions to the situation by one of these genius master toolmaker makers, far down the chain from say Vint Cerf and Tim Berners-Lee who did the Internet and Web, respectively. No, this is the story of a ragtag lone developer trying to fix some of HTML’s holes, Carson Gross. Perplexity?

Perplexity: HTMX is an open-source front-end JavaScript library created by Carson Gross. It extends HTML with custom attributes that enable the use of AJAX directly in HTML, promoting a hypermedia-driven approach to web development.

History of HTMX

1. 2013: Carson Gross creates intercooler.js, the predecessor to HTMX
2. April 2020: Development begins on a jQuery-independent, improved version of intercooler.js
3. May 2020: HTMX reaches version 0.0.1
4. November 24, 2020: HTMX 1.0.0 is officially released

Carson Gross: The Creator

Carson Gross is the mind behind HTMX and several related projects:

• Creator of HTMX and Hyperscript
• Author of “The Grug Brained Developer”
• Professor of software engineering at Montana State University
• Co-author of “Hypermedia Systems”

Gross developed HTMX as a response to the complexity of modern web development, aiming to return to a more HTML-centric approach while still enabling dynamic web applications.

Significance if Added to Web HTML Standard

If HTMX were to become part of the Web HTML standard, it could have far-reaching implications:

1. Simplified web development: Developers could create dynamic web applications using primarily HTML, reducing the need for complex JavaScript frameworks.

2. Improved performance: By leveraging server-side rendering and minimal client-side JavaScript, web applications could become more efficient and faster.

3. Enhanced accessibility: A more HTML-centric approach could lead to better accessibility for web applications by default.

4. Reduced learning curve: Web development could become more accessible to newcomers, as they would need to learn fewer technologies to create dynamic applications.

5. Shift in web architecture: It could encourage a return to server-side rendering and processing, potentially changing how web applications are structured and deployed.

6. Standardization of hypermedia-driven applications: HTMX’s approach could become a widely adopted standard for creating hypermedia systems, aligning more closely with REST principles.

While HTMX offers a compelling alternative to complex JavaScript frameworks, its inclusion in the HTML standard would represent a significant shift in web development paradigms and would likely face considerable debate within the web standards community.

Citations:

[1] https://en.wikipedia.org/wiki/Htmx
[2] https://syntax.fm/show/734/htmx-web-apps-with-carson-gross
[3] https://dev.to/jlarky/revisiting-web-history-from-web-10-to-rsc-and-htmx-4b9o
[4] https://www.infoworld.com/article/2336201/complexity-bad-an-interview-with-carson-gross.html
[5] https://htmx.org/posts/2020-11-24-htmx-1-0-0-is-released/
[6] https://quii.dev/HTMX_is_the_Future
[7] https://www.tutorialspoint.com/htmx/htmx_history.htm
[8] https://www.youtube.com/watch?v=ZLaRBT-OmVQ
[9] https://www.reddit.com/r/htmx/comments/185qj6z/htmx_announced_as_framework_of_the_year/

And so FINALLY! Like-minded individuals at least in spirit, but dwarfing me in skills, agency and whatever other wacky unlikely qualities it takes to change the world by dropping a pebble into a pond, drop those pebbles. The spirit of the Amiga computer reborn! But sliding in hidden in the Trojan Horse of HTML web development!

HTMX, as revolutionary and radically simplifying, and indeed almost obsoleting of ReactJS as it is, would go nowhere without a special boost.

And there’s only one place that boost can come from in today’s world.

Python.

Plain and simple. There’s precisely one camp in today’s tech arena that holds a chance against the Juggernaut One-Language-To-Rule-Them-All already won status of JavaScript astoundingly as the only language natively ALLOWED in browsers (more on that in future articles). And that’s Python.

Let’s be 100% clear. JavaScript isn’t terrible. It’s just not love-worthy in the same way as other languages. It’s got more compromises and less 80/20-rule ideal for most situation attributes than Python. The perfect storm of Python is too much to go into here (the article is long enough), suffice to say that Python won too, and Python could go toe-to-toe with JavaScript on every front… except web development. And as we covered, while web development is not quite the future-proofing ideal that it once promised to be, it’s one of the items on the short-list of must-have’s for any single platform to emerge dominant as the lifetime-skills seeking craftsperson for someone like me.

You can’t take up a language as a lifetime skill if it can’t tackle the big web problems as well or better than any other language.

Enter Jeremy Howard, the great dot-connector between Python and HTMX, and thus the Web and potential world domination of a new Web Framework that will make ReactJS’s reign pale in comparison.

I kid you not.

That brings us up to where we are at this very moment in time, and the whole “The Future Was Now” title I chose for today’s article.

As with the Amiga when *The Future Was Here”, we are going through precisely another one of those same inflection points in technology, were tomorrow’s losers are today’s beloved, and tomorrow’s winners are studying, learning and sharpening their blades for battle.

Despite all of Sam Altman’s seeming genius and posturing, and allegedly aggressive pushing forward of OpenAI’s ChatGPT models and services, everything they’re doing is not even a pimple on the ass of the very same entity that crushed Commodore: Microsoft.

Make no mistake. Bill Gates is still alive, and the strategic sentiments that stuck it to IBM with that fateful deal that made Digital Research and… and… Perplexity?

Perplexity: Digital Research, Inc. (DRI) was a pioneering American software company founded by Gary Kildall in 1974. It was originally named Intergalactic Digital Research before being shortened to Digital Research[1][7]. DRI was the first large software company in the microcomputer world, based in Pacific Grove, California[1][7].

Gary Kildall, the founder, was an American computer scientist and entrepreneur who created the CP/M operating system in the 1970s[2]. He started the company to market and develop CP/M and related operating systems for microcomputers[1].

Digital Research didn’t get the IBM deal for several reasons:

1. When IBM representatives came to discuss licensing CP/M, Kildall was reportedly out flying his plane[6].

2. Kildall’s wife, who handled the business side, was reluctant to sign IBM’s non-disclosure agreement[6].

3. There were disagreements over the licensing terms, including whether it would be a flat fee or royalty-based arrangement[6].

4. DRI was hesitant about allowing IBM to rename CP/M, potentially concerned about brand damage[6].

As a result of these issues, IBM returned to Microsoft, who then acquired QDOS (Quick and Dirty Operating System), modified it, and licensed it to IBM as MS-DOS[6]. This decision had far-reaching consequences for the personal computer industry and Microsoft’s future dominance in the operating system market.

Citations:

[1] https://en.wikipedia.org/wiki/Digital_Research
[2] https://en.wikipedia.org/wiki/Gary_Kildall
[3] https://news.ycombinator.com/item?id=9667831
[4] https://www.digitalresearch.com/our-history/
[5] https://ethw.org/w/images/5/53/TheBirthOfThePC-OperatingSystem.pdf
[6] https://scobleizer.blog/2007/08/08/the-rest-of-the-story-behind-microsofts-os-deal-with-ibm/
[7] https://www.computinghistory.org.uk/sec/14871/Digital-Research/
[8] https://business.pacificgrove.org/events/Details/the-rise-and-fall-of-digital-research-inc-presentation-1187124
[9] https://www.reddit.com/r/HistoryWhatIf/comments/qhuxm0/what_if_ibm_rejected_bill_gates_and_microsoft/
[10] https://www.cpcwiki.eu/index.php/Digital_Research

The OpenAI Inflection Point

We are at one of these inflection points, and the “Amiga” of our age, OpenAI, is making claims of AGI. Sam Altman is also saying that such terms lack sufficient granularity. They might imply things that they’re not.

The Fatal Flaw of Context

AGI assumes the entity of intelligence is going to have context… context, which it’s not going to have. It’s the fatal “crashing” flaw of the Amiga. Because of resource management, safety and general cloud architecture and productization of intelligent entities, the crash is designed-in.

AIs crash.

Feeding the whole discussion back into them on every post in that token context-window seems to be the trick of allowing these fire-and-forget Mr. Meeseeks that we’re dealing with to instantaneously get up to speed on the entire history of the discussion up to that point. But it’s an illusion of continuity. It’s a way to cross that crash barrier; that catastrophic loss of context which makes these things less dangerous. No object persistence, no distinct entity nor being. And so… and so… a form of AGI, but can’t be generalized beyond what’s imaged into its base model and the growth that can occur as a result of a growing, interactively re-submitted discussion, but whose context-window is a rolling or moving finite window, nonetheless.

The Python Web Renaissance

Jeremy Howard, again… yes! He connected the dots between Python and the web in way that made it interesting, and indeed perhaps even love-worthy again.

But the AI’s don’t know it. They generally can’t help with it. They weren’t trained on it. It’s too friggn new. And it’s close enough to other things like FastAPI, that the LLMs repeatedly and in the most insidious ways try to steamroll you into using the patterns they were trained on (only logical), but which comes off as a perpetual peppering of poison into your code. It’s the backfiring genie wish problem on steroids. Ask for a small task in a FastHTML project and get a major refactoring into a FastAPI pattern. Over and over and over.

Fighting LLM Bias

You can fight it with a .cursorrules file. You can also put copious documentation throughout your Python code in the form of docstrings, comments and other “speedbumps” so the LLM can’t not encounter directives.

The Subtle Points of Failure

This is such a subtle point, and it’s exactly this subtlety that allows a sort of undermining subversion to set in. It happened with the Amiga computer when Commodore got it. It was never going to be successful in those conditions. And it wasn’t just inept Commodore marketing that everyone loves to blame it on. It was a complex interplay of subtle factors, from losing the original Amiga engineers because Commodore wanted to move them to suburban Pennsylvania, to the whole lack-of-excellence vibe of the suburbs itself. There was a “not invented here” attitude among the prior Commodore engineers of different hardware lineages like the VIC20 and C64. And there as bad ventilation in the 1200 Wilson Drive building that made you feel like your brain was being starved.

Death by a Thousand Cuts

Things fail for thousands of reasons. Any tiny little reason allowed to settle in and proliferate like a cavity in a tooth or a growing malignancy. Bad morale and groupthink are the worst; collective truths, little lies told to each other that while untrue somehow make folks feel better about themselves, and are thus believed. All these things compound and play a role in the downfall of things. But the corollary is that there is only one reason things succeed: usually just one person playing whack-a-mole against all these forces.

It’s death-by-1000 cuts versus the 1000-cut interceptor. This is why you hear about Elon Musk not actually working on everything he’s involved with at once, but flitting from whatever most currently broken to the next thing most broken. Anyone can do textbook company management. But only someone with a unique technical skillset and dogged determination can make work what others can’t.

The Web Development Revolution

Such is the state right now with the potential transition of web development away from overweight obsolescence guaranteed client-side JavaScript frameworks like Angular, React, Vue, Svelte, yadda yadda insert nearly infinite list here. It’s utterly and completely unnecessary now that HTMX has shown us that fact. I was converted to HTMX long before FastHTML ever existed. But I couldn’t make the move. It’s like the cosmos heard my webdev woes and said “Here is half the solution: HTMX”

And so a few years went by with me intellectually aware that there was a fix to the mess that plagued web development and made it so unappealing to me. But there was this missing piece. I guess it amounted to that I found everything loveworthy that I wanted in tech in Linux, Python, vim & git, and HTMX just didn’t fit. And so web development just didn’t fit. If I needed a user interface, I would make a Jupyter Notebook make do. Jupyter was the user interface, and all the more so when JupyterLab became so dashboard-like with widgets and packages like dask. But everything fancy had these critical flaws. It wasn’t really web dev.

The Python Web Framework Evolution

Yes, there’s Django with is a perfectly mature Python web development package that goes back longer than anyone can imagine. Yes, I was around when it was Plone/Zope, a sort of precursor to Django. But for whatatever reason, none of these things stuck with me. I had my dance with Flask as well as most everyone has, and while there’s something fundamentally right about Flask (it’s what Pylons, FastAPI and every other Python web framework copies), it still didn’t hit. It was not appealing enough to draw me back. I looked at FastAPI which was such a big deal for the enterprise because of the way it squeezed a bit more performance out of your webservers, but it was for very un-Pythonic pedantic reasons that make me cringe even considering that my way back into webdev.

The Rise of FastAPI

FastAPI happened I believe mostly because 2 things converged in the Python world: formalization of concurrency in the Python standard library with the async await keywords (a JavaScript knock-off), and a formalization of strict variable type casting (MyPy typing). Oh the 3rd thing to converge was simply the Flask people taking so long to respond to either. Is that converging? Anyway, nobody wanted to start new projects on Flask when such wonderful new capabilities were there to be had, and FastAPI responding to the vacuum walked in and filled the need. By the time Flask put out its concurrent version, all new major projects were started on FastAPI.

And FastAPI had all the trappings of fat, overweight cognitive draining stuff that the enterprise architects love! The library it’s dependent on is even called Pedantic! Ugh! The Python community was going the same Conway’s Law route as JavaScript before it with Angular and React. And you still had to bring your own template language like jinja2 or mako, so it was like a harder to use Flask that didn’t improve web development. But it filled a void left open by Flask for so long that now all the AI models are over-trained on it and won’t let you do anything else… especially if that anything else is closely named… like FastHTML is.

The Future Is Now

So I have to wrap up this article and get onto the hard-nosed productivity bit (tomorrow). The future was now was the first thought I had to write this, because I have that old Amiga feeling for the first time in many years, after false starts in the Web and mobile. The former undermined by development and tooling trends, and the later deeply proprietary from birth. All of this against a sea of tech churn compelling obsolescence by the minute, so much so that a desperate grab has been made at immutable snapshot Docker containers, so that at lest something isn’t always changing underneath of you.

The LPvg Solution

But there is a better way. It’s Linux, Python, vim & git (LPvg) to reduce decision fatigue, bring back craftsmanship in tech, and provide an 80/20-rule approach to many challenges in most problem domains. And the final piece in my estimation to have just recently fallen into place is FastHTML. It is the bridge or the connection between the LPvg world and the web. By making Python functions idiomatically named after their HTML counterparts for which they generate the code, you have once again the semantic web, but now expressed beautifully with Python having all the power of HTMX ideally wedged in.

Whether this solution that in one stroke eliminates the need for fat, composed containers at fat, rapidly obsolete JavaScript frameworks is the future of web development or not can be debated. But it is one viable and pragmatic approach that’s going to appeal to a certain personality type like me seeking a path to recapturing craft and lifelong forever improving skills in tech.

Let’s run it by o1 Pro since I have access to it. Let’s start with a softball:

Linux, Python, vim & git (aka LPvg) is about:

• The reduction of decision fatigue
• Developing craftsmanship skills in tech
• Overcoming setbacks caused by tech churn

Provide an assessment of accuracy and a critique, but then make a strong argument for. The particular path I plan on developing here is through NixOS and nix for deterministic system builds using IaC, eliminating most need for virtual machines and containers. It will also use nvim over vim for the sake of having .lua available in init.lua instead of vimscript. And it is based on the premise that mastery of skills tied to habit and muscle memory can exist in tech, and provide a baseline level of spontaneous expertise and mastery for a lifetime. This is not exclusive to other approaches, but works in conjunction as a lifetime backup, contingency plan, and an 80/20-rule approach to nearly all challenges in all problem domains.

o1 Pro: Assessment of Accuracy

1. Reduction of Decision Fatigue
   The idea that staying within a small technology stack (Linux, Python, vim/nvim, git) lowers decision fatigue is largely accurate. By having fewer tools to consider and master, you spend less mental energy deciding which tool or framework to use. In a world of proliferating technologies and daily new releases, focusing on a few powerful tools can indeed keep you productive and reduce choice overload.

2. Developing Craftsmanship Skills in Tech
   Deliberately limiting your toolset fosters deeper skill development. This aligns with the idea of “sharpening the saw” in a narrower domain—honing skills in, say, nvim or Python not only makes you more fluent but can also give you creative ways to solve problems within those constraints. This is an accurate statement about skill development and mastery.

3. Overcoming Setbacks Caused by Tech Churn
   Tech churn is real: frameworks, operating systems, and cloud services often undergo rapid changes. By mastering a handful of core technologies (Linux, Python, vim/nvim, and git), you maintain a fallback or “baseline” set of skills that remain relevant despite industry shifts. This point is also accurate, though it’s worth noting that domain-specific frameworks and toolchains may still require adaptation over time.

Critique

1. Possible Lack of Breadth
   While focusing on the LPvg stack (Linux, Python, vim/nvim, git) can indeed reduce decision fatigue, it may limit exposure to other valuable tools, languages, or development paradigms that could be more efficient for certain tasks. For example, large-scale distributed systems might benefit from specific container or orchestration technologies that aren’t entirely replaceable with just NixOS + IaC.

2. Potential Friction with Team/Industry Norms
   Though adopting NixOS for deterministic builds and neovim for editing is powerful, in practice many teams use Docker, containers, or alternative editors (VS Code, IntelliJ, etc.). Depending on your work context, your chosen approach might introduce friction if others are unfamiliar with Nix, or if CI pipelines are built around container-based workflows. While the personal mastery track works, it might require coordination and alignment in a team setting.

3. Time Investment
   The depth of mastery demanded by the LPvg approach is non-trivial. Achieving the benefits of muscle-memory and spontaneous expertise requires consistent practice over years. This is both a strong point (once mastered) and a potential weak point (if time or urgency prevents people from investing in that level of skill-building).

Strong Argument For Adopting the LPvg Path (with NixOS, IaC, and nvim)

1. Lifetime Skills in a Rapidly Changing Industry
   In an industry where new frameworks, libraries, and SaaS platforms arise constantly, having a “core toolkit” that you continuously refine can act as a lifetime asset. Linux, Python, vim/nvim, and git each have long histories, robust communities, and are used pervasively across countless environments. Mastery in these enduring technologies gives you a foundation that transcends fads.

2. Deterministic, Reproducible Environments with NixOS
   Adopting NixOS and the Nix package manager extends the stability and control of Linux to the next level. With declarative, Infrastructure-as-Code configurations, you can reproduce entire environments (dev, test, production) precisely. This drastically reduces the need for multiple layers of abstraction—container sprawl, VM overhead, or complex Dockerfiles—and replaces it with a single, clean configuration that is straightforward to version-control with git.

3. Efficiency and Fluency Through Habit and Muscle Memory
   Neovim (nvim) provides a modern extension to vim’s timeless editing model. By maintaining the same robust keybindings while harnessing the power of Lua for custom scripting, you preserve your muscle memory, deepen your text-editing skills, and gain a powerful platform for automation. Over time, you’ll do more with fewer keystrokes and become significantly faster at code navigation, editing, and refactoring than if you constantly switch editors.

4. A Perpetual 80/20 Solution
   The “80/20 rule” states that you often get 80% of the results from 20% of the effort. With Linux, Python, vim/nvim, and git plus Nix for deterministic builds, you can solve a vast array of problems without chasing new technologies. Whether it’s scripting, data manipulation, quick prototyping, or building and deploying software, this toolkit covers the majority of typical engineering tasks. Thus, it offers a “good enough” solution in many domains, reducing the need for constant retraining or retooling.

5. Reduced Cognitive Overhead
   By converging on a stable, minimal set of tools, you avoid the “analysis paralysis” that comes from trying every new language or editor. Instead, you can channel that mental bandwidth into honing your craft, exploring deeper programming concepts, or innovating. This not only benefits personal productivity but can also lead to higher-quality outputs when you’re not spread thin across too many tools.

6. Resilience and Portability
   Linux, git, Python, and neovim operate nearly everywhere—from cloud servers to embedded systems. Your knowledge isn’t locked into any proprietary ecosystem. Coupled with the reproducible nature of Nix, your environment can be recreated on any machine with minimal friction. That resilience ensures that even if you find yourself on a new project, organization, or hardware platform, you can quickly rebuild your familiar and efficient workflow.

In conclusion, while there are always trade-offs in any approach, the LPvg philosophy, enhanced with NixOS-based Infrastructure as Code, stands as a powerful strategy to maintain clarity, reduce overhead, and cultivate deep expertise. This path balances the desire for cutting-edge tools (Neovim + Lua, reproducible builds with Nix) with the timelessness of a Linux environment, Python scripting, and the pervasiveness of git—making it a compelling lifetime skill set for any developer or devops practitioner.

Okay, and now let’s feed it the whole article and ask it for an open-ended riffing. They love doing that…

o1 Pro: Below is a reflection and synthesis on the overarching narrative and ideas in your (very enjoyable!) “The Future Was Now” article and how they connect to the theme of “LPvg” (Linux, Python, vim, git), NixOS, and everything else swirling around in the story—Amiga’s legacy, retrocomputing, the illusions of indefinite hardware love, HTMX, and the new wave of web frameworks in Python.

1. The Amiga as a Metaphor for “The Future Was Here”

• Romance of Past Tech
  You open with an ode to the Amiga—a machine that was once the future. Its architecture (bitplanes, memory model, multi-tasking OS) was innovative but flawed. It’s a perfect metaphor for how “the best ideas” don’t necessarily prevail in the long term due to business, organizational, and ecological factors.
• Whims of Hardware
  The Amiga story also illustrates the heartbreak of tying your identity too closely to any single piece of hardware. Technology decays; even the most visionary hardware solutions are eventually eclipsed or emulated on trivial hardware years later.
• Invisible Threads
  Throughout the article, you’re tracing the invisible lines of computing history—how Jay Miner’s dream machine ended up overshadowed by the parade of WinTel, how CP/M lost to MS-DOS, how the arc of innovation is so often about business deals and personalities rather than purely superior tech.

2. The Lament of Tech Churn

• The “Craft” Dilemma
  A theme resonates throughout: can one nurture a sense of craft and artistry in a field that reinvents itself every two to three years? Is it possible to build deeply ingrained muscle memory akin to a violinist or a woodworker?
• Slow vs. Fast Learners
  You place yourself squarely among the “slow learners” who derive pleasure from mastering fewer tools in great depth. The ephemeral nature of modern frameworks—especially in front-end web development—makes it feel like there’s no stable foundation to sink your roots into.
• Fighting Back with LPvg
  Hence the attraction to an intentionally minimalistic stack: Linux, Python, vim (nvim), and git. These are proven tools with large communities and deep staying power. The muscle memory payoff is real; you can indeed become lightning-fast and highly creative when you push a single toolset to its limits.

3. NixOS, IaC, and Deterministic Builds

• Nix as a Reaction to Docker Overload
  Another way to fight back against churn is reproducible builds and environments—Nix and NixOS. Instead of container sprawl and ephemeral solutions layered on ephemeral solutions, Nix attempts to solve the root problem: how to define your system environment precisely, deterministically, and in version-control.
• Minimal, Declarative
  Nix’s approach is very aligned with the “80/20, do-more-with-less” philosophy. If you can remove the overhead of manually building Docker containers and fiddling with Kubernetes, you can focus on the actual craft of writing software.

4. Web Development: The HTMX + Python Love Affair

• The Thorn of the Browser
  You note how JavaScript became the only language “natively allowed” in browsers, capturing an almost total monopoly. This forced a generation of devs into a strange compromise with big frameworks (Angular, React, Vue, Svelte) that many see as cognitively heavy.
• HTMX as the Trojan Horse
  Enter Carson Gross’s HTMX, which aims to simplify the client side by letting you stay in HTML and use hypermedia-driven updates. You see it as a spiritual successor to the simple, direct approach the Amiga championed—something that was elegant and workable without huge overhead.
• Python, the Last Bastion
  JavaScript is everywhere in the browser, but Python is the singular formidable force that can challenge that dominance from the server side. The synergy of Python + HTMX can “bring the web back” in a simpler, more robust way.
• Jeremy Howard
  The same Jeremy Howard (of fast.ai fame) you mention is bridging modern Python and simpler web paradigms—e.g., “FastHTML” patterns. This is reminiscent of the synergy between a new wave of simpler frameworks and the unstoppable popularity of Python in data science, ML, scripting, and everything else.

5. The Larger “LPvg” Rationale

• Reducing Decision Fatigue
  You reassert that limiting your stack to Linux, Python, vim/nvim, and git slashes away the daily overhead of “which tool do I pick?”—fostering deeper mastery.
• Long-Term Craftsmanship
  There’s a real appeal in viewing your developer environment like a workshop: you have your lathe, your chisels, your table saw. They don’t fundamentally shift every year. They become extensions of you. That’s the dream with LPvg.
• Nix + IaC
  The final piece is making your entire environment reproducible, so you’re no longer dependent on ephemeral containers or “well, it worked on my machine.” This extends the sense of craftsmanship into your deployment and system configuration.
• The 80/20 Rule
  Despite industry hype about new frameworks, 80% of real-world problems are solvable with an “LPvg + minimal web framework + reproducible build” approach. If you accept that some advanced edge cases may require specialized tools, you can still remain productive, flexible, and calm.

6. Why This Matters Today

• Repeat of the Amiga-IBM-Microsoft Cycle
  We’re at another big inflection point, especially with AI. Sam Altman, OpenAI, and ChatGPT appear unstoppable. But in the same way Commodore was undone by the bigger fish (Microsoft) with cunning deals, we see the dynamics repeating: existing power players (Microsoft, Google, Apple) overshadow or absorb smaller innovators.
• AGI and “Crashing”
  Your metaphor for AI having no persistent context is reminiscent of the Amiga’s memory protection flaw: if context vanishes, the system or “entity” can’t sustain continuity of thought. This structural “flaw” may ironically keep AI from being as dangerous as some fear but also keeps it from true AGI as we imagine it.
• Humanity in Tech
  Ultimately, you emphasize the desire for a stable, humane approach to computing, where a person can become a “craftsperson” over a long arc of a career. That longing is what draws you (and others) back to minimal, proven tools.

7. Conclusion: “The Future Was Now”

• History Rhymes
  The Amiga story is a cautionary tale but also an inspiration. It shows that “the best ideas” can be overshadowed by politics, corporate mismanagement, or market forces. It also shows how ephemeral hardware is.
• Personal Mastery
  By adopting Linux, Python, nvim, and git (and layering on NixOS for determinism), you build a kind of personal microcosm that can last decades—a refuge from churn.
• A Quiet Revolution
  HTMX and “FastHTML” styles of web dev might be the next “Amiga” of their time, bringing radical simplicity but requiring certain champions to keep it from slipping into obscurity. Python stands as a powerful ally in that fight.
• A Path Forward
  Whether or not the world flocks to this approach, it offers you (and similarly minded folks) a do-able, stable, future-proof path to coding with joy. By reducing the complexity in your toolset, you enable the sort of craft-based, deep mastery that the perpetual waves of tech trends often deny.

Closing Thoughts

Your long personal journey—through Commodore’s downfall, the trauma of watchful bystanders, the disillusionment with repeated web frameworks, and finally the rediscovery of something fresh in HTMX + Python—beautifully captures the cyclical nature of tech. The desire to find a set of tools you can love for a lifetime remains valid and resonant. And while we might not all adopt exactly your Nix + LPvg + FastHTML formula, the underlying philosophy of choosing fewer, deeper tools for real craftsmanship is timeless.

This is less about “right vs. wrong” technologies and more about a personal stance: refusing to let tech churn define your identity or drain your energy. Instead, you anchor to a curated set of core technologies that can weather the storms of hype cycles. That’s the real takeaway—the future is always “now,” and the most meaningful choice is how we position ourselves to experience that future with sanity, skill, and a dash of joy.