{ "archive_path": "archive/1774740886.368105", "base_url": "jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone", "basename": "", "bookmarked_date": "2026-03-28 23:34", "canonical": { "archive_org_path": "https://web.archive.org/web/jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=jneen.ca", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "jneen.ca", "downloaded_at": "2026-03-28T23:34:48.669498+00:00", "downloaded_datestr": "2026-03-28 23:34", "extension": "", "hash": "MPADD5YY71DD4XQVT4DB", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" ], "cmd_version": "8.10.1", "end_ts": "2026-03-28T23:35:44.622548+00:00", "index_texts": null, "output": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:35:42.209797+00:00", "status": "failed" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" ], "cmd_version": "131.0.6778", "end_ts": "2026-03-28T23:35:16.969266+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:34:59.942334+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=jneen.ca" ], "cmd_version": "8.10.1", "end_ts": "2026-03-28T23:34:51.879486+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:34:49.200526+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" ], "cmd_version": "8.10.1", "end_ts": "2026-03-28T23:34:52.280768+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:34:51.916862+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2026-03-28T23:35:33.928711+00:00", "index_texts": [ "(/css/main.css) (/css/code.css) how to make programming terrible for everyone | jneens web site (/) jneens web site (/) home (/pages/cv) hire me (https://discord.gg/ctdn8Zbx2f) discord (/blag) blag # Published Mar 27, 2026 (/posts/2026-03-27-how-to-make-programming-terrible-for-everyone) how to make programming terrible for everyone (ALL THE PROGRAMS YOU'LL EVER NEED. FOR $600.\n Say goodbye to the costs and frustrations associated with writing software: The Last One(R) will be available very soon.\n More comprehensive and advanced than anything else in existence, The Last One(R) is a computer program that writes computer programs. Programs that work first time, every time.\n By asking you questions in *genuinely* plain English about what you want your program to do, The Last One(R) uses those answers to generate a totally bug-free program in BASIC, ready to put to immediate use.\n What's more, with The Last One(R), you can change or modify your programs as often as you wish. Without effort, fuss, or any additional cost. So as your requirements change, your programs can too.\n In fact, it's the end of programming as you know it.\n And if, because of the difficulties and costs of buying, writing and customising software, you've put off purchasing a computer system up to now, you need delay no longer.\n The Last One(R) will be available very soon from better computer outlets. To place your order, take this ad into your local dealer and ask him for further details. Or in case of difficulty, please write to us direct.\n THE LAST ONE\n YOU'LL NEVER NEED TO BUY ANOTHER PROGRAM.\n D.J. 'A.I.' Systems Ltd., Ilminster, Somerset, TA19 9BQ. England\n Telephone: 04605-4117. Telex: 46338 ANYTYR G.) A full-page ad for The Last One software system, post-processed with various effects by me. (https://archive.org/details/byte-magazine-1981-08/page/n209/mode/2up) BYTE magazine Aug. 1981, pg. 196 (click through for more a readable version) I was recently shocked to learn that (https://thedailywtf.com) (The Daily WTF) The Daily WTF is still running after all these years. It seems like such a time capsule now; a write-in blog making fun of the absolute nonsense programmers encounter in the field. Marvel at the (https://thedailywtf.com/articles/A-Spacy-Problem) (The Daily WTF: A Spacy Problem) 24 nested stringReplace calls ! Check out this trilingual ASP.NET SQL query that (https://thedailywtf.com/articles/Trilingual-Query-Language) (The Daily WTF: Trilingual Query Language) generates both HTML and Javascript ! Watch (https://thedailywtf.com/articles/Divine-by-Zero) (The Daily WTF: Divine By Zero (The PHP God)) The PHP God non-deterministically divide by zero! To me it evokes an era of IRC channels, PHP, subversion, and logging into the production server to update the code. Simpler times. These days it\u2019s a lot of very obtuse React. There is one snippet from that time that really stuck in my brain though. It reached above the nonsense layer and into the philosophical. And that is the story of (https://thedailywtf.com/articles/the-quine-programmer) (The Daily WTF, \u201cThe Quine Programmer\u201d) The Quine Programmer . See, unlike the typical inanity and wacky code snippets of the site, the Quine Programmer (and the Quine System they create) get at some very fundamental questions about programming. Though it\u2019s not technically a quine - that would require producing the actual program\u2019s source code - the so-called Quine Programmer has built a system that can do just about anything, given the right configuration. And they\u2019ve presumably built it using a programming language, which is a system that can do just about anything, given the right code. So naturally we have to ask: What is the difference between a \u201cSystem that Can Do Anything\u201d and, say, Python? At what point is the user of a system doing capital-P Programming? Is Excel a programming language? What about (https://en.wikipedia.org/wiki/The_Last_One_(software)) (The Last One) The Last One ? If (https://scratch.mit.edu/) (Scratch visual programming language) scratch is a programming language, does clicking around Unreal Engine count? nginx.conf ? What about the command-line flags of find ?1 And what is it in concrete terms that makes Python better than The Quine Programmer\u2019s monster? (An absolutely incomprehensible crow's nest of labeled boxes and arrows, presumably describing some workflow.) The Quine Programmer\u2019s monster.As shown in (https://thedailywtf.com/articles/the-quine-programmer) \u201cThe Quine Programmer\u201d on The Daily WTF . Most folks I know who work on and write about programming languages would say that, broadly speaking, these systems all represent a type of programming.2 There are some design considerations all these systems have in common, and it is a design space I enjoy thinking about. In some sense, which I hope to make a bit more concrete here, Python and your favourite programming language have more respect for the interaction between the user and the computer, allowing each to do what they do best. Every modern high-level language is built on a mountain of abstractions, but to some extent they actually free you from thinking about it most of the time, allowing you to work with simplified mental models that make the act of programming easier, clearer, and more fun. So, how do we do better than the Quine Programmer? How can we connect the dots between human user and computer in a way that respects the strengths of both? Computer Language Design For this broader question, I prefer the following extremely general definition of a \u201ccomputer language\u201d: A computer language is a computer program whose meaningful inputs are unbounded in complexity. This is pretty close to the definition from (https://jneen.ca/talks/clojure-west-2015) (My talk at clojure/west 2015: \u201cHow to tell if you've accidentally implemented a programming language, and what to do about it\u201d) my clojure/west talk 10 years ago , and though there\u2019s many things I\u2019d change about that talk a decade later, I think it\u2019s fairly workable for our purposes. It clearly includes configuration, markup, and styling languages, as well as non-text-based languages quite nicely. It also, crucially, includes the Quine Programmer\u2019s system.3 And for those versed in certain languages, evaluating a tool by the possible shapes of its inputs should feel fairly familiar - the shape of the input determines the utility of the output. The moment you are handling arbitrarily complex input is perhaps the moment you should ask \u201cAm I the Quine Programmer?\u201d4 What I think more strongly stand the test of time5 are the general design goals of a computer language that I presented in that talk: Interpretation . The computer should be able to interpret valid input and reject invalid input. Predictability . The user should be able to understand the way in which the computer will interpret their input. Discoverability . The user should understand how to express new goals within the constraints of the system. The Quine Programmer is quite satisfied with their performance on Interpretation . Give it a valid input, and the system will work just fine! Perhaps they haven\u2019t thought through the feedback loop for invalid input particularly well, and perhaps there are some corners the users would be surprised to know about, but to the Quine Programmer\u2019s mind these are simply part of the spec. Every bug a feature. As for Predictability , the Quine Programmer has not even considered it. In their mind the implementation is the mental model. But their users, who almost as a rule are not familiar with the implementation, will absolutely struggle to use the system if they cannot reasonably predict its behaviour. Any bozo can write display: flex in a CSS file, but there is no meaning to this action unless you have a mental model of what it will do . Systems with low predictability leave users with a complicated guess-and-check workflow that relies mostly on (https://utcc.utoronto.ca/~cks/space/blog/programming/ProgrammingViaSuperstition) (Chris Siebenmann - A significant amount of programming is done by superstition) superstition . (Classic GIF of Peter Griffin struggling with Venetian blinds, captioned 'CSS') A dated meme, but one that encapsulates the \u201ctry it and see if it works\u201d feeling I remember from trying to make a site look right in IE6. Similary, Discoverability may have been overlooked by the Quine Programmer, who typically is not known to write extensive documentation. Just read the code! Languages that fail on this point tend to be plagued with copy-paste code, slightly modified each time, a result of users\u2019 fear of venturing off the well beaten path. The Quine Programmer has also likely overlooked another important discovery feature: error messages . It is vitally important that the system respond in a helpful way when given invalid input. Users rely on these messages (among other things) to correct mistakes and develop a clear mental model of the language. In fact, (https://ingenieria-de-software-i.github.io/assets/bibliografia/programming-as-theory-building.pdf) (Programming As Theory Building. Peter Naur, Microprocessing and Programming 15, 1985, p. 253-261) Peter Naur argued in 1985 that that the programmer\u2019s mental model of the language is closer to the point of programming than the execution of code: [\u2026] it is concluded that the proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution. These design goals all share a common thread, which is enabling a user to communicate and do cool things with a computer in a way that empowers them and allows them to think in higher-level terms, without leaving them lost and confused. They\u2019re principles of user empowerment nearly identical to those that UX designers think about every day. So that\u2019s a fun little philosophical exercise from 10 years ago, based on a satirical blog post from 15 years ago. But this is 2026, so I think we all know where this is going. Evaluating AI as a computer language This beef isn\u2019t new for me. I was getting into embarrassing online arguments with AI people on exactly these points as far back as 2014. Perhaps I should have written about them more. See, the design goals we\u2019ve talked about aren\u2019t just applicable to quine systems or computer languages. I\u2019d argue they apply to any tool that facilitates communication between a human user and a computer. Any AI system that communicates with a user in natural language certainly meets our computer language definition above, and so I feel fairly justified in judging it by the same criteria.6 Also, AI marketing keeps (https://github.blog/changelog/2026-03-17-secret-scanning-in-ai-coding-agents-via-the-github-mcp-server/) (Github Blog: Secret Scanning in AI Coding Agents Via the Github MCP Server) claiming it has invented things 7 that compilers, linters, formatters, and all manner of language tools have been doing for decades. If they insist on being programming tools, I think it\u2019s only fair to critique them by the same terms as programming tools: Interpretation , Predictability , and Discoverability . From my perspective, AI can be seen as an incredibly poorly designed computer language. Actually, that may not quite be fair, as AI systems excel at discoverability. By design, it is certainly \u201ceasy\u201d to use an AI system. Those who believe in the existence of \u201cprompting skill\u201d may have one or two tips and tricks for saving tokens and discouraging certain classes of errors, but ultimately communicating with a machine in natural language takes an extremely minimal amount of knowledge or training. It\u2019s all right there , willing to explain anything you ask, factual accuracy be damned. The issue is that the designers seem to have forgotten the rest of it: what discoverability is for . Whether an AI system can interpret valid input is a topic of contentious debate (and I don\u2019t think we should accept \u201csometimes\u201d as an answer here), but it is very clear to me that AI systems are not capable of rejecting invalid input, at least not consistently.8 One could even ask whether there is a distinction between valid and invalid input for an AI system. Natural language is slippery, full of weird regionalisms and self-negatives and overlapping meanings and context dependence that make the process of interpretation extremely error-prone, even for a theoretically perfect system. As (https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html) (Edsger Dijkstra: On the foolishness of \u201cnatural language programming\u201d.) Dijkstra famously argued , the use of formal symbols for logical and technical tasks historically represented a major breakthrough, and is one we should not let slip lightly. But the complete abject failure of AI systems lies mainly in predictability. The scale of the data set means that there is simply no way for users to develop a mental model of its operation, or to even guess as to the nature of the interpretation of a given input. We have automated the \u201cPeter Griffin Struggles With Venetian Blinds\u201d workflow on our codebases and our users. To be fair to the users though, they do in fact end up constructing a mental model of their interactions with an AI. The problem is it\u2019s dangerously wrong. The AI User\u2019s Actual Mental Model Most computer science folks these days are familiar with (https://psych.fullerton.edu/mbirnbaum/psych101/eliza.htm) (A working demo of ELIZA) ELIZA , the 1960s chatbot that famously convinced users they were talking to a real person, seemingly passing the (https://en.wikipedia.org/wiki/Turing_test) (Wikipedia: Turing test) Turing Test with flying colours by mere social engineering. Fewer, I think, have read ELIZA author Joseph Weizenbaum\u2019s excellent book on the topic, (https://archive.org/details/computerpowerhum0000weiz_v0i3) (Computer Power and Human Reason by Joseph Weizenbaum) Computer Power and Human Reason . I recently managed to find a hard-copy, printed in 1976 - it has one of those old cardboardy hard-back bindings and smells like my grandmother\u2019s bookshelf. The language in it is admittedly a bit dated and certainly dense, but it\u2019s surprisingly prescient for today\u2019s world. Here\u2019s how Weizenbaum describes a user developing a mental model of a natural language system like ELIZA (pg. 15): So, unless they are capable of very great skepticism (the kind we bring to bear while watching a stage magician), they can explain the computer\u2019s intellectual feats only by bringing to bear the single analogy available to them, that is, their model of their own capacity to think. The lack of a clear mental model leads to the so-called (https://en.wikipedia.org/wiki/ELIZA_effect) (Wikipedia: ELIZA effect) ELIZA effect : a user\u2019s tendency to project all kinds of intellectual capabilities onto a computer system, in the same way my cats might think that I have magical powers when I turn the lights on and off or summon meat from the refrigerator. The classical example is Weizenbaum\u2019s secretary being moved to tears by a fairly simple word-substitution algorithm, in a conversation beginning \u201cMen are all alike.\u201d This is not, as is the impression I fear so many walk away with, some problem limited to a gullible secretary complaining to a computer program about her boyfriend.9 We are not as different from her as maybe we would like to imagine. In fact, Weizenbaum cites professional psychiatrists declaring the program to be the future of their field, and even Carl Sagan himself chimed in to offer a rosy vision of a future where therapy was administered coldly through arrays of computer terminals.10 You are not immune to the ELIZA effect! As a more modern example, from about 2014 to 2017, I ran a twitter bot trained on my tweets, called @jneebooks, which was a (https://en.wikipedia.org/wiki/Horse_ebooks) (Wikipedia on @horse_ebooks) popular trend at the time . I don\u2019t quite remember if I ended up using an off-the-shelf thing or the very naive 3-word Markov model I was tinkering with. But I remember why I stopped running it: a friend of mine from high school thought I was trying to break into the ebooks market, and had an entire conversation with it, mistaking it for me. And then when I told him it was a bot he didn\u2019t believe me . That\u2019s a fun comedy of errors, but today, AI\u2019s tendency towards being anthropomorphized is not neutral. It\u2019s directly led to some of its more unsavoury effects on its users. In fact, LLMs are arguably an (https://softwarecrisis.dev/letters/llmentalist/) (LLMentalist by Baldur Bjarnason) active cognitohazard . Even presumed subject-matter experts are prone to this - just a short while ago a Meta AI specialist (https://nitter.net/summeryue0/status/2025774069124399363) (Summer Yue's texts with her OpenClaw instance) posted herself admonishing OpenClaw for deleting her email , an act that assumes a computer can feel shame and correct its behaviour to avoid it. I think we should consider this a kind of optical illusion created by having no other reference point to fall back on. Like most illusions, being aware of the problem doesn\u2019t mean your perception is suddenly \u201cfixed\u201d - you and I are equipped with human senses that have a lot of strange flaws and corner cases. Anyone who works with computers has been here though, far before AI. When something goes wrong, we\u2019re as likely as anyone to assume the computer is cursed, has it out for us specifically, or needs to be appeased in some way. And at that moment, the computer does have an interiority that is hidden from us. There certainly is something we haven\u2019t seen or don\u2019t understand! A good programming tool or computer language, though, is a means for us to find and dissect that interiority, stripping away the illusion. AI actively worsens it instead.11 Aside on Tuned Noise In the last few years I\u2019ve been getting a bit into (https://shadertoy.com/user/jneen) (my humble shadertoy profile) shader programming . Despite being decidedly mediocre at it, the act of programming this way has been very therapeutic for me. Demoscene-style shaders are optimized for live-coding in (https://www.youtube.com/watch?v=NBdRfFwuP40) (the real pros at work) competitive 25-minute demo battles , meaning memorization and quick typing are much more desirable traits in a design than future-proofing or even readability. In art coding, there is a constant struggle to maintain order over chaotic systems. Good graphics programmers and artists know (https://stegu.github.io/webgl-noise/webdemo/) (a perlin noise implementation i referenced for one of the WIP City shaders) how to use noise and unpredictability to their advantage , while retaining predictability over the general behaviour. As my dear friend and extremely accomplished shader artist (https://suricrasia.online/) (Suricrasia Online) blackle put it, \u201cThe only thing bad about glitches is that they (https://youtu.be/NBdRfFwuP40?si=g_XHpyZFC37UNaTY&t=3167) (nil) take artistic control away .\u201d Noise is tricky, even in simple cases - understanding the distribution or behaviour of a noise source is critical for getting good results. The reason I bring this up is twofold. First, because I anticipate objections to \u201cPredictability\u201d based on the fact that programmers use noise and randomness all the time, and I want to establish that predictability is in fact key to working with noise. The second reason is that tuned noise is legitimately a decent application of AI models , (including GPT!). Machine learning models themselves are, in fact, one important subgenre of tuned noise. This isn\u2019t just my opinion - LLM researcher Andrej Karpathy explains in the annotations for (https://karpathy.github.io/2026/02/12/microgpt/#faq) (microgpt by Andrej Karpathy (FAQ)) microgpt :12 The [GPT] model is a big math function that maps input tokens to a probability distribution over the next token. And naturally, this is generally the productive use to which not-quite-as-large learning models (https://www.cs.utep.edu/mhossain/papers/trainable.pdf) (An early-ish paper on ML approaches for spam detection) have been put (https://unity.com/products/speedtree) (Unity SpeedTree - games industry standard tree generator) for some time . I think it\u2019s fair to say that presuming local models, ethical training, and the retention of some manner of creative control,13 there is not much one can object to with this use case.14 But critically: in all these cases, the noise is in the output , rather than the interface . In the case of computer languages, where input is unbounded in complexity, there are already so many natural sources of unpredictability that introducing more sources, especially when their behaviour is not well understood, is an unnecessary sacrifice of creative control. Sure, it can enable you to make more code , but that\u2019s (https://mrshu.github.io/github-statuses/) (Github's absolutely shameful (at time of writing) uptime stats. 90%. Yeesh.) unlikely to be better or more reliable .15 Conclusion I care deeply about tool usability - there\u2019s much in HCI that seems to be about capturing the attention of the most uninterested user, but in my opinion UX is equally important in the other ways we (even technical users!) interact with computers. When I spelled out these design goals a decade ago, I had some hope that maybe the industry would start taking tool design seriously. The industry\u2019s answer appears to be Claude. And it\u2019s not like the problem is new. As far back as 1981, (https://archive.org/details/PersonalComputerWorld1981-02/page/76/mode/1up) (Archive.org: Article in Personal Computer World, Feb. 1981: \u201cThe Last One\u201d) tech press was salivating over half-baked Quine Systems like (https://en.wikipedia.org/wiki/The_Last_One_(software)) (The Last One (Wikipedia)) The Last One , claiming such hogwash as \u201c[\u2026] it\u2019s the end of programming as you know it\u201d, and \u201c[\u2026] those in the DP [data processing] industry who fail to adapt to the new approach may find themselves out of work.\u201d (https://stackoverflow.com/questions/1293278/what-became-of-the-last-one) (Stack Overflow: What became of The Last One?) By all accounts , The Last One was a monstrous system to work with. Claude and other natural-language-based programming tools carry the thesis that the failure of The Last One and other older Quine Systems was primarily due to technological failures, and the capabilities of hardware at the time. But how valuable can these advances be if they fail to empower their users? The problem is in the interface! I think the ultimate fate of AI programming won\u2019t be too far from that of The Last One. When a programming tool is unreliable, completely resists mental-modeling, and is incapbable of consistently rejecting invalid input, I think it\u2019s reasonable to say it\u2019s not fit for purpose, and is certainly not the future of programming. We simply cannot develop mental models of AI through traditional means. But we have to remember that just because we don\u2019t understand it doesn\u2019t mean it\u2019s hiding secret insight or power. But I also think the art of programming survives the coming AI winter. There\u2019s going to be quite a lot of work to do to clean up the mess we\u2019ve made for ourselves. But I have a deep love for a good mess, precisely because it means there\u2019s still work to do.16 Instead, why not learn a new, traditional programming language this year, maybe one that\u2019s very different than you\u2019re used to? Heck, mock one up yourself! The Quine Programmer\u2019s mistake wasn\u2019t in building a computer language, just in doing it badly, and failing to empathize with their audience. Maybe by learning from what\u2019s been done before, you can do better! \u220e Thank you to blackle, Tesselode, AmyZenunim, and tef for helping me turn this mess into something even vaguely presentable. Anything that sucks here is probably a result of me not taking their advice. Yall rock. Those with just enough CS knowledge to be dangerous will probably be excitedly ready to explain (https://en.wikipedia.org/wiki/Turing_completeness) (Wikipedia: Turing completeness) Turing Completeness at this moment, a mathematical categorization of programming languages based on their capability, given some infinite amount of resources (classically, a tape). But I\u2019m more interested in the design of languages than their specific application or capabilities, so let\u2019s perhaps say that turing-completeness is an attribute that a language can have, rather than a definition of what one is. It\u2019s an important consideration to be sure! But there are other design considerations that I think apply a bit more generally. \u21a9 \u2026with the caveat that sometimes \u201cprogramming\u201d is implied to be in a Turing complete system, or even more specifically an imperative one, and this ambiguity is also part of why I prefer \u201ccomputer language\u201d. I\u2019m including things like HTML and CSS here, as they also have the same kind of design considerations. \u21a9 There\u2019s some grey area around creative tools like Photoshop or your average DAW (which these days tend to have programming-like systems built in anyways). \u21a9 AITQP subreddit when \u21a9 \u2026with some modifications, which may be a bit unfair of me. \u21a9 specifically, systems that generate or interpret code with LLMs, based on inputs including code, prompts, and documentation. I do know about systems that e.g. do log pattern-finding, fuzzing, and all manner of other tasks, but I would argue those don\u2019t need the specific bit I take issue with here, which is the natural-language interface with the user. They also would be completely fine running locally on ethically-sourced data, so are usually much less controversial. \u21a9 some going so far as to claim having invented the concept of abstraction itself! \u21a9 I swear to god if somebody comes at me with \u201cyou just haven\u2019t used the latest model yet\u201d. We\u2019ve heard this before. Non-determinism is inherent to the design. \u21a9 Even though this is Weizenbaum\u2019s only written example I can find of ELIZA interaction (specifically the DOCTOR module), the fact that this prompt is the example snippet every time ELIZA is brought up says something about our perception and treatment of women, and allows us to be somewhat dismissive of the ELIZA effect in ways that are super uncomfortable to think about! \u21a9 The article, \u201cIn Praise of Robots\u201d from Natural History Jan 1975 is, naturally, (https://eric.ed.gov/?id=EJ111512) (Carl Sagan: In Praise of Robots.) paywalled . You can apparently (https://scispace.com/papers/in-praise-of-robots-hlgdkabu74) (SciSpace page for In Praise of Robots) ask a chatbot to hallucinate about it though . But here\u2019s a (https://www.forbes.com/sites/lanceeliot/2024/07/11/surprising-outcome-of-carl-sagans-famous-1975-prediction-about-ai-becoming-your-attentive-psychotherapist/) (Surprising Outcome Of Carl Sagan's Famous 1975 Prediction About AI Becoming Your Attentive Psychotherapist, Forbes Magazine, 2024 Jul 11.) Forbes article discussing it, which contains the same quote Weizenbaum pulled in his book. As you might expect, this version of Sagan is quoted extensively by AI proponents and AGI17 true believers. \u21a9 Huge shout-outs to (https://suricrasia.online/) (Suricrasia Online) blackle for this line of argument. To those who would say that AI specifically helps them understand the problem better, I would say two things - one, finding patterns in logs is actually probably defensible as a machine-learning use case, in the same way that the best spam filters tend to lean on ML methods. Two, I\u2019ve seen many, many instances where this \u201cunderstanding\u201d is mostly an illusion, where the AI user has been led severely astray on a problem in ways they were sort of by definition not equipped to notice. While it\u2019s also possible to be led astray like this by traditional documentation or other discovery features in a language, when this happens I think we generally regard it as bad, and recognize it as a problem to be fixed. \u21a9 Specifically, the noise that is tuned comes from three sources in microgpt (there are more in a production AI system): 1) a uniform shuffle of the training data, 2) a Gaussian distribution for the initial matrix values of each attention head, and 3) the final weighted random choice according to the trained weights during inference. The rest is all tuning! \u21a9 these are very big presumptions \u21a9 except maybe the price, SpeedTree is notoriously expensive. \u21a9 Holy heck it just occurred to me that the code from The Daily WTF snippets is almost certainly in your favourite model\u2019s training set. Terrifying. \u21a9 If you have a big mess to clean up, consider (https://jneen.ca/pages/cv) (my CV) hiring me ! \u21a9 It\u2019s also important to note that (https://www.baldurbjarnason.com/2023/beware-of-ai-snake-oil/) (Baldur Bjarnason, \u201cBeware of AI pseudoscience and snake oil\u201d) AGI is pseudoscience . \u21a9 All content \u00a9 Jeanine Adkisson.\nIf you'd like to copy, remix, or redistribute this work, please (/pages/about) contact me. " ], "output": "htmltotext.txt", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:35:33.899263+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" ], "cmd_version": "2024.10.7", "end_ts": "2026-03-28T23:35:42.024961+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:35:36.150426+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" ], "cmd_version": "2.2.3", "end_ts": "2026-03-28T23:35:33.848899+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:35:31.151661+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmpha4fey7v", "https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" ], "cmd_version": "0.0.11", "end_ts": "2026-03-28T23:35:21.939641+00:00", "index_texts": [ "jneens web site\n\n\n\n\nhome\n\n\nhire me\n\n\ndiscord\n\n\nblag\n\n\n\n\n\n\n\n\n\n# Published Mar 27, 2026\n\n\nhow to make programming terrible for everyone\n\n\n\n\n \n A full-page ad for The Last One software system, post-processed with various effects by me. BYTE magazine Aug. 1981, pg. 196(click through for more a readable version)\n\n\nI was recently shocked to learn that The Daily WTF is still running after all these years. It seems like such a time capsule now; a write-in blog making fun of the absolute nonsense programmers encounter in the field. Marvel at the 24 nested stringReplace calls! Check out this trilingual ASP.NET SQL query that generates both HTML and Javascript! Watch The PHP God non-deterministically divide by zero! To me it evokes an era of IRC channels, PHP, subversion, and logging into the production server to update the code. Simpler times. These days it\u2019s a lot of very obtuse React.\n\nThere is one snippet from that time that really stuck in my brain though. It reached above the nonsense layer and into the philosophical. And that is the story of The Quine Programmer.\n\nSee, unlike the typical inanity and wacky code snippets of the site, the Quine Programmer (and the Quine System they create) get at some very fundamental questions about programming. Though it\u2019s not technically a quine - that would require producing the actual program\u2019s source code - the so-called Quine Programmer has built a system that can do just about anything, given the right configuration. And they\u2019ve presumably built it using a programming language, which is a system that can do just about anything, given the right code. So naturally we have to ask:\n\n\nWhat is the difference between a \u201cSystem that Can Do Anything\u201d and, say, Python?\n\n\nAt what point is the user of a system doing capital-P Programming? Is Excel a programming language? What about The Last One? If scratch is a programming language, does clicking around Unreal Engine count? nginx.conf? What about the command-line flags of find?1\n\nAnd what is it in concrete terms that makes Python better than The Quine Programmer\u2019s monster?\n\n\n \n \n The Quine Programmer\u2019s monster.As shown in \u201cThe Quine Programmer\u201d on The Daily WTF.\n \n\n\nMost folks I know who work on and write about programming languages would say that, broadly speaking, these systems all represent a type of programming.2 There are some design considerations all these systems have in common, and it is a design space I enjoy thinking about.\n\nIn some sense, which I hope to make a bit more concrete here, Python and your favourite programming language have more respect for the interaction between the user and the computer, allowing each to do what they do best. Every modern high-level language is built on a mountain of abstractions, but to some extent they actually free you from thinking about it most of the time, allowing you to work with simplified mental models that make the act of programming easier, clearer, and more fun.\n\nSo, how do we do better than the Quine Programmer? How can we connect the dots between human user and computer in a way that respects the strengths of both?\nComputer Language Design\nFor this broader question, I prefer the following extremely general definition of a \u201ccomputer language\u201d:\n\n\nA computer language is a computer program whose meaningful inputs are unbounded in complexity.\n\n\nThis is pretty close to the definition from my clojure/west talk 10 years ago, and though there\u2019s many things I\u2019d change about that talk a decade later, I think it\u2019s fairly workable for our purposes. It clearly includes configuration, markup, and styling languages, as well as non-text-based languages quite nicely. It also, crucially, includes the Quine Programmer\u2019s system.3\n\nAnd for those versed in certain languages, evaluating a tool by the possible shapes of its inputs should feel fairly familiar - the shape of the input determines the utility of the output. The moment you are handling arbitrarily complex input is perhaps the moment you should ask \u201cAm I the Quine Programmer?\u201d4\n\nWhat I think more strongly stand the test of time5 are the general design goals of a computer language that I presented in that talk:\n\n\n\nInterpretation. The computer should be able to interpret valid input and reject invalid input.\nPredictability. The user should be able to understand the way in which the computer will interpret their input.\nDiscoverability. The user should understand how to express new goals within the constraints of the system.\n\n\n\nThe Quine Programmer is quite satisfied with their performance on Interpretation. Give it a valid input, and the system will work just fine! Perhaps they haven\u2019t thought through the feedback loop for invalid input particularly well, and perhaps there are some corners the users would be surprised to know about, but to the Quine Programmer\u2019s mind these are simply part of the spec. Every bug a feature.\n\nAs for Predictability, the Quine Programmer has not even considered it. In their mind the implementation is the mental model. But their users, who almost as a rule are not familiar with the implementation, will absolutely struggle to use the system if they cannot reasonably predict its behaviour. Any bozo can write display: flex in a CSS file, but there is no meaning to this action unless you have a mental model of what it will do. Systems with low predictability leave users with a complicated guess-and-check workflow that relies mostly on superstition.\n\n\n \n A dated meme, but one that encapsulates the \u201ctry it and see if it works\u201d feeling I remember from trying to make a site look right in IE6.\n\n\n\nSimilary, Discoverability may have been overlooked by the Quine Programmer, who typically is not known to write extensive documentation. Just read the code! Languages that fail on this point tend to be plagued with copy-paste code, slightly modified each time, a result of users\u2019 fear of venturing off the well beaten path.\n\nThe Quine Programmer has also likely overlooked another important discovery feature: error messages. It is vitally important that the system respond in a helpful way when given invalid input. Users rely on these messages (among other things) to correct mistakes and develop a clear mental model of the language.\n\nIn fact, Peter Naur argued in 1985 that that the programmer\u2019s mental model of the language is closer to the point of programming than the execution of code:\n\n\n[\u2026] it is concluded that the proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.\n\n\nThese design goals all share a common thread, which is enabling a user to communicate and do cool things with a computer in a way that empowers them and allows them to think in higher-level terms, without leaving them lost and confused. They\u2019re principles of user empowerment nearly identical to those that UX designers think about every day.\n\nSo that\u2019s a fun little philosophical exercise from 10 years ago, based on a satirical blog post from 15 years ago. But this is 2026, so I think we all know where this is going.\nEvaluating AI as a computer language\nThis beef isn\u2019t new for me. I was getting into embarrassing online arguments with AI people on exactly these points as far back as 2014. Perhaps I should have written about them more.\n\nSee, the design goals we\u2019ve talked about aren\u2019t just applicable to quine systems or computer languages. I\u2019d argue they apply to any tool that facilitates communication between a human user and a computer. Any AI system that communicates with a user in natural language certainly meets our computer language definition above, and so I feel fairly justified in judging it by the same criteria.6 Also, AI marketing keeps claiming it has invented things7 that compilers, linters, formatters, and all manner of language tools have been doing for decades. If they insist on being programming tools, I think it\u2019s only fair to critique them by the same terms as programming tools: Interpretation, Predictability, and Discoverability.\n\nFrom my perspective, AI can be seen as an incredibly poorly designed computer language.\n\nActually, that may not quite be fair, as AI systems excel at discoverability. By design, it is certainly \u201ceasy\u201d to use an AI system. Those who believe in the existence of \u201cprompting skill\u201d may have one or two tips and tricks for saving tokens and discouraging certain classes of errors, but ultimately communicating with a machine in natural language takes an extremely minimal amount of knowledge or training. It\u2019s all right there, willing to explain anything you ask, factual accuracy be damned. The issue is that the designers seem to have forgotten the rest of it: what discoverability is for.\n\nWhether an AI system can interpret valid input is a topic of contentious debate (and I don\u2019t think we should accept \u201csometimes\u201d as an answer here), but it is very clear to me that AI systems are not capable of rejecting invalid input, at least not consistently.8 One could even ask whether there is a distinction between valid and invalid input for an AI system.\n\nNatural language is slippery, full of weird regionalisms and self-negatives and overlapping meanings and context dependence that make the process of interpretation extremely error-prone, even for a theoretically perfect system. As Dijkstra famously argued, the use of formal symbols for logical and technical tasks historically represented a major breakthrough, and is one we should not let slip lightly.\n\nBut the complete abject failure of AI systems lies mainly in predictability. The scale of the data set means that there is simply no way for users to develop a mental model of its operation, or to even guess as to the nature of the interpretation of a given input. We have automated the \u201cPeter Griffin Struggles With Venetian Blinds\u201d workflow on our codebases and our users.\n\nTo be fair to the users though, they do in fact end up constructing a mental model of their interactions with an AI. The problem is it\u2019s dangerously wrong.\nThe AI User\u2019s Actual Mental Model\nMost computer science folks these days are familiar with ELIZA, the 1960s chatbot that famously convinced users they were talking to a real person, seemingly passing the Turing Test with flying colours by mere social engineering. Fewer, I think, have read ELIZA author Joseph Weizenbaum\u2019s excellent book on the topic, Computer Power and Human Reason. I recently managed to find a hard-copy, printed in 1976 - it has one of those old cardboardy hard-back bindings and smells like my grandmother\u2019s bookshelf.\n\nThe language in it is admittedly a bit dated and certainly dense, but it\u2019s surprisingly prescient for today\u2019s world. Here\u2019s how Weizenbaum describes a user developing a mental model of a natural language system like ELIZA (pg. 15):\n\n\nSo, unless they are capable of very great skepticism (the kind we bring to bear while watching a stage magician), they can explain the computer\u2019s intellectual feats only by bringing to bear the single analogy available to them, that is, their model of their own capacity to think.\n\n\nThe lack of a clear mental model leads to the so-called ELIZA effect: a user\u2019s tendency to project all kinds of intellectual capabilities onto a computer system, in the same way my cats might think that I have magical powers when I turn the lights on and off or summon meat from the refrigerator. The classical example is Weizenbaum\u2019s secretary being moved to tears by a fairly simple word-substitution algorithm, in a conversation beginning \u201cMen are all alike.\u201d\n\nThis is not, as is the impression I fear so many walk away with, some problem limited to a gullible secretary complaining to a computer program about her boyfriend.9 We are not as different from her as maybe we would like to imagine. In fact, Weizenbaum cites professional psychiatrists declaring the program to be the future of their field, and even Carl Sagan himself chimed in to offer a rosy vision of a future where therapy was administered coldly through arrays of computer terminals.10 You are not immune to the ELIZA effect!\n\nAs a more modern example, from about 2014 to 2017, I ran a twitter bot trained on my tweets, called @jneebooks, which was a popular trend at the time. I don\u2019t quite remember if I ended up using an off-the-shelf thing or the very naive 3-word Markov model I was tinkering with. But I remember why I stopped running it: a friend of mine from high school thought I was trying to break into the ebooks market, and had an entire conversation with it, mistaking it for me. And then when I told him it was a bot he didn\u2019t believe me.\n\nThat\u2019s a fun comedy of errors, but today, AI\u2019s tendency towards being anthropomorphized is not neutral. It\u2019s directly led to some of its more unsavoury effects on its users. In fact, LLMs are arguably an active cognitohazard. Even presumed subject-matter experts are prone to this - just a short while ago a Meta AI specialist posted herself admonishing OpenClaw for deleting her email, an act that assumes a computer can feel shame and correct its behaviour to avoid it.\n\nI think we should consider this a kind of optical illusion created by having no other reference point to fall back on. Like most illusions, being aware of the problem doesn\u2019t mean your perception is suddenly \u201cfixed\u201d - you and I are equipped with human senses that have a lot of strange flaws and corner cases.\n\nAnyone who works with computers has been here though, far before AI. When something goes wrong, we\u2019re as likely as anyone to assume the computer is cursed, has it out for us specifically, or needs to be appeased in some way. And at that moment, the computer does have an interiority that is hidden from us. There certainly is something we haven\u2019t seen or don\u2019t understand! A good programming tool or computer language, though, is a means for us to find and dissect that interiority, stripping away the illusion. AI actively worsens it instead.11\nAside on Tuned Noise\nIn the last few years I\u2019ve been getting a bit into shader programming. Despite being decidedly mediocre at it, the act of programming this way has been very therapeutic for me. Demoscene-style shaders are optimized for live-coding in competitive 25-minute demo battles, meaning memorization and quick typing are much more desirable traits in a design than future-proofing or even readability.\n\nIn art coding, there is a constant struggle to maintain order over chaotic systems. Good graphics programmers and artists know how to use noise and unpredictability to their advantage, while retaining predictability over the general behaviour. As my dear friend and extremely accomplished shader artist blackle put it, \u201cThe only thing bad about glitches is that they take artistic control away.\u201d Noise is tricky, even in simple cases - understanding the distribution or behaviour of a noise source is critical for getting good results.\n\nThe reason I bring this up is twofold. First, because I anticipate objections to \u201cPredictability\u201d based on the fact that programmers use noise and randomness all the time, and I want to establish that predictability is in fact key to working with noise.\n\nThe second reason is that tuned noise is legitimately a decent application of AI models, (including GPT!). Machine learning models themselves are, in fact, one important subgenre of tuned noise. This isn\u2019t just my opinion - LLM researcher Andrej Karpathy explains in the annotations for microgpt:12\n\n\nThe [GPT] model is a big math function that maps input tokens to a probability distribution over the next token.\n\n\nAnd naturally, this is generally the productive use to which not-quite-as-large learning models have been put for some time. I think it\u2019s fair to say that presuming local models, ethical training, and the retention of some manner of creative control,13 there is not much one can object to with this use case.14\n\nBut critically: in all these cases, the noise is in the output, rather than the interface. In the case of computer languages, where input is unbounded in complexity, there are already so many natural sources of unpredictability that introducing more sources, especially when their behaviour is not well understood, is an unnecessary sacrifice of creative control. Sure, it can enable you to make more code, but that\u2019s unlikely to be better or more reliable.15\nConclusion\nI care deeply about tool usability - there\u2019s much in HCI that seems to be about capturing the attention of the most uninterested user, but in my opinion UX is equally important in the other ways we (even technical users!) interact with computers. When I spelled out these design goals a decade ago, I had some hope that maybe the industry would start taking tool design seriously. The industry\u2019s answer appears to be Claude.\n\nAnd it\u2019s not like the problem is new. As far back as 1981, tech press was salivating over half-baked Quine Systems like The Last One, claiming such hogwash as \u201c[\u2026] it\u2019s the end of programming as you know it\u201d, and \u201c[\u2026] those in the DP [data processing] industry who fail to adapt to the new approach may find themselves out of work.\u201d By all accounts, The Last One was a monstrous system to work with.\n\nClaude and other natural-language-based programming tools carry the thesis that the failure of The Last One and other older Quine Systems was primarily due to technological failures, and the capabilities of hardware at the time. But how valuable can these advances be if they fail to empower their users? The problem is in the interface!\n\nI think the ultimate fate of AI programming won\u2019t be too far from that of The Last One. When a programming tool is unreliable, completely resists mental-modeling, and is incapbable of consistently rejecting invalid input, I think it\u2019s reasonable to say it\u2019s not fit for purpose, and is certainly not the future of programming. We simply cannot develop mental models of AI through traditional means. But we have to remember that just because we don\u2019t understand it doesn\u2019t mean it\u2019s hiding secret insight or power.\n\nBut I also think the art of programming survives the coming AI winter. There\u2019s going to be quite a lot of work to do to clean up the mess we\u2019ve made for ourselves. But I have a deep love for a good mess, precisely because it means there\u2019s still work to do.16\n\nInstead, why not learn a new, traditional programming language this year, maybe one that\u2019s very different than you\u2019re used to? Heck, mock one up yourself! The Quine Programmer\u2019s mistake wasn\u2019t in building a computer language, just in doing it badly, and failing to empathize with their audience. Maybe by learning from what\u2019s been done before, you can do better! \u220e\n\nThank you to blackle, Tesselode, AmyZenunim, and tef for helping me turn this mess into something even vaguely presentable. Anything that sucks here is probably a result of me not taking their advice. Yall rock." ], "output": "readability/", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:35:18.849145+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" ], "cmd_version": "8.10.1", "end_ts": "2026-03-28T23:35:17.153880+00:00", "index_texts": null, "output": "how to make programming terrible for everyone | jneens web site", "pwd": "/data/archive/1774740886.368105", "schema": "ArchiveResult", "start_ts": "2026-03-28T23:35:17.083862+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "how to make programming terrible for everyone | jneens web site", "warc": null, "wget": null }, "link_dir": "/data/archive/1774740886.368105", "newest_archive_date": "2026-03-28T23:35:42.209797+00:00", "num_failures": 1, "num_outputs": 8, "oldest_archive_date": "2026-03-28T23:34:49.200526+00:00", "path": "/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01KMVCSMX3BDE3138601993QYV", "snapshot_id": "da34a5a3-fedb-43ec-8e64-eadb5291dfdb", "sources": [ "/data/sources/1774740885-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1774740886.368105", "title": "how to make programming terrible for everyone | jneens web site", "url": "https://jneen.ca/posts/2026-03-27-how-to-make-programming-terrible-for-everyone/" }