Scripting News podcast

<p><i>As before I asked Claude.ai to do a synopsis, from its point of view. I added a link to Brent's post and a postscript. As always if you really want to know what I said you have to listen. :-)</i></p><p>Dave opens by riffing on a <a href="https://micro.inessential.com/2026/03/13/code-is-a-liquid-now.html">post</a> by Brent Simmons, who described feeling, for the first time in his career, that he has his app completely under control — no chaos in the source code. Dave almost believes it's possible, but notes the catch: you can only get there on the fourth or fifth implementation of a given piece of software. The more complex the app, the harder that is to achieve.</p><p>He reflects on the tension between experimentation and stability. You can't try out new ideas on a mature codebase without actually building them out fully — there's no halfway. Like driving a car, you can't get a real feel for a feature if you leave out the steering wheel. So you build the whole thing, knowing you might throw it away.</p><p>Dave admits he's not in that place with anything he's working on now. The one exception, by design, was Frontier — built to be extended by users, which gave it a different kind of coherence.</p><p>From there he shares a vivid memory: demoing an early outliner at the West Coast Computer Fair, probably 1979, with Ted Nelson standing right next to him. Nelson watched the demo and said, simply, "That's virtuality." Dave unpacks what he meant: the suspension of disbelief. When software is truly good, you forget you're using it. Your fingers work at the base of your spine, your ideas appear on screen, and your full conscious attention is on the work itself — not the tool.</p><p>He extends the analogy to skiing: your first run you're thinking about mechanics and fear; by the third run, you're just going down the hill being yourself. That's the same feeling. Bike riding gets there faster with less overhead, which Dave notes is, honestly, a better deal.</p><p>He closes by thanking Brent for the thought, and wonders if AI tools might make that state of software mastery more broadly achievable.</p><p><i>Notes prepared by Claude.ai</i></p><p>PS: This is Dave. I never got around to explaining what was awful about reading Ted Nelson's book. It was awful because I thought I had had <i>original</i> ideas, but someone got there before me, Doug Engelbart, and Nelson wrote up Engelbart's ideas in great agonizing detail in Dream Machines. </p>

<p><i>As before I asked Claude.ai to do a synopsis. I corrected one factual error (informing it, waiting for a new version, not correcting the writing). And I think it may have missed the big points of both, but I will respect its opinion. As always if you really want to know what I said you have to listen. :-)</i></p><p>Dave Winer responds to a recent episode of the David Frum podcast, in which Frum's guest was Tim Miller of The Bulwark. The topic that caught his attention: why young men are turning to Trump. He has thoughts, but first he has a detour to make.</p><p>The detour is MeToo. Winer remembers it vividly as a social media-enabled phenomenon that did real damage — to people's careers, to trust, to the basic norms of adult interaction. He watched friends lose everything to accusations he found implausible, and he remembers modifying his own behavior in ways he describes as "horrific." The fear was pervasive and real. He credits the movement with catching genuine predators like Harvey Weinstein, but he also remembers the stampede quality of it — the way platform dynamics allowed something that couldn't have happened before social media. He got a small, personal taste of unwanted physical contact — a forced hug from someone who'd knocked him off his bike in Manhattan — and it clarified something for him about how violation feels.</p><p>On the young men question, Winer offers no clean answer — just honest acknowledgment that their complaints about housing costs and economic lockout have merit. What frustrates him is the solution they chose. Trump, he argues, is dismantling the very things young people will need: healthcare, environmental protection, institutional stability. He closes with a characteristic mix of irritation and optimism, pointing to Minnesota as evidence that something better is still possible.</p><p><i>Notes prepared by Claude.ai</i></p>

<p><i>As with <a href="https://shownotes.scripting.com/scripting/">previous</a> podcasts I asked Claude.ai to write the show notes based on a machine-generated <a href="https://s3.amazonaws.com/scripting.com/publicfolder/downloads/podcasts/2026/02/21/theKillerAppForAi.txt">transcript</a>. It makes mistakes, so you have to listen to the podcast if you want to know what I really think. But it's pretty good, and will help search engines find this. </i></p><p>Dave Winer's Twitter account was hijacked, and the experience crystallized something he's been thinking about: AI's first killer app in tech should be customer service.</p><p>The incident unfolded quickly and confusingly. Dave received an email from Twitter claiming copyright infringement on content he himself had created, threatening to take down his account within 24 hours unless he could explain why — something that seemed to require a lawyer. While he was on his Peloton, his phone rang three times in 30 minutes with no voicemail, no caller ID, just a mysterious urgency that made him fear someone had died. Then he was locked out of the account entirely. A friend on Bluesky mentioned the same copyright notice had hit them simultaneously, confirming this was some kind of mass attack. Dave still has no idea what happened or how to fix it, and he has 63,000 followers on an account he's maintained since 2006.</p><p>The deeper frustration isn't just the hack — it's the complete absence of recourse. He pays $8 a month for Twitter Blue, yet there's no way to reach an actual human being for help. This is where his proposal gets pointed: tech companies should deploy AI not for generating content slop or automating essays, but for solving the customer service crisis they've created by refusing to hire support staff. If X really has Grok as a serious AI system, Dave argues, it could read the <a href="https://s3.amazonaws.com/scripting.com/publicfolder/downloads/podcasts/2026/02/21/theKillerAppForAi.txt">transcript</a> of this podcast, cross-reference it with server logs, understand what happened, and simply restore his account by reverting the email address to [email protected] and requiring a fresh password reset.</p><p>This would be the economic benefit of AI that actually matters — fixing the broken relationship between platforms and their paying users. Dave frames it as both an immediate solution to his problem and a broader challenge to the industry: stop looking for frivolous AI applications and address the fundamental flaw in how these systems treat people.</p><p>Notes prepared by Claude.ai</p>

<p><i>As <a href="https://shownotes.scripting.com/scripting/2025/12/18/whatWouldFirefoxDo.html">with</a> <a href="https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html">previous</a> <a href="https://shownotes.scripting.com/scripting/2026/01/05/bloggerOfTheYear.html">podcasts</a> I asked Claude.ai to write the show notes based on a machine-generated transcript. It makes mistakes, so you have to listen to the podcast if you want to know what I really think. But it's pretty good, and will help search engines find this. Additionally, I refer to the <a href="http://scripting.com/2025/08/28/140604.html#a141421">Think Different</a> piece as revealing the big missing piece in web apps, the problem I hope to solve with WordLand and the competitive products that I want to encourage. </i></p><p>Dave Winer reaches back nearly four decades to tell the story of Frontier, his scripting system for the Macintosh, and draws a direct line from that experience to what he's working on today.</p><p>The backstory begins with Winer's company riding the Mac wave in the mid-1980s. While most developers abandoned the platform during its lean early years, his team stuck it out, kept their revenue flowing through a PC product, and were perfectly positioned when Apple removed the hardware limitations in January 1986. That loyalty paid off in relationships — Winer had contacts throughout Apple, including <a href="https://en.wikipedia.org/wiki/Jean-Louis_Gass%C3%A9e">Jean-Louis Gassée</a>, the top product executive just below the CEO level. </p><p>After selling his company and taking a well-deserved winter off skiing, Winer set to work on something he'd always wanted to build: a scripting system for the Mac. It was an elegant product — it added a menu to the Finder, provided a proper script editor, and made apps scriptable. He developed it with the knowledge and informal blessing of his friend at the top of Apple's product organization, who met with him regularly and gave feedback. When the demo landed in front of Apple's executives, it went well — they asked for a proposal. Winer went back with what he considered a fair deal: a per-machine license capped at $14 million, after which Apple would owe nothing. He thought it addressed their concerns directly, particularly their frustration over the ongoing royalty payments to Adobe on every LaserPrinter sold.</p><p>What came back instead was rejection — and then the revelation that Apple had an internal project all along, something called "Family Farm," a scripting system that would let users "script in English." That project eventually shipped as AppleScript, which Winer regards as technically inferior to what he'd built. The internal reaction to his proposal, he suspects, had less to do with the merits and more to do with the psychology of salaried employees who saw him as someone who shouldn't be profiting at their level. He kept developing Frontier for years afterward, building it into a much larger product than originally planned — but the moment had passed.</p><p>Now, Winer says, he finds himself in a structurally similar position. There's something missing from the web that has been missing for over 30 years: a real developer platform. Mobile has a rich app ecosystem; the web doesn't, and he thinks there's a specific, answerable reason why. The solution, as he sees it, involves an API for storage — and that's where WordPress comes in. He frames WordPress not just as a publishing tool but as a storage platform, the foundation piece that a proper web developer ecosystem has been lacking.</p><p><i>Notes prepared by Claude.ai</i></p>

<p><i>As with the <a href="https://shownotes.scripting.com/scripting/2026/01/05/bloggerOfTheYear.html">previous podcast</a> I asked Claude.ai to write the show notes. It makes mistakes, so you have to listen to the podcast if you want to know what I really think. This time it wrote it in the first person, not third person which I would have preferred. At the end I have some of my own notes. DW</i></p><p>This story about XML-RPC's creation in 1998 feels relevant because we're on the verge of something similar today, but this time it might go much further.</p><p>Frontier was a comprehensive scripting environment with object database, editor, debugger, and extensive verb set that provided one unified way to do things instead of JavaScript's fifty million ways. It had excellent networking capabilities and was deeply integrated for desktop publishing and magazine pre-production.</p><p>Apple felt threatened and didn't appreciate what we were doing - there was a lot of bad stuff happening at Apple, and we were part of one of the bad things that happened there. We couldn't depend on the Mac anymore and had to convert to Windows.</p><p>The core problem was communication between Mac and Windows systems with their completely incompatible networking. The solution hit me and I wrote a <a href="http://scripting.com/davenet/1998/02/27/rpcOverHttpViaXml.html">blog post</a> called 'HTTP plus XML equals RPC' - a way to make everything work the same way.</p><p>Bob Atkinson from Microsoft called after reading my blog. Bill Gates was a regular reader and would forward posts around the company, asking people what they thought. This meant everyone at Microsoft was up to date on what I was doing.</p><p>We set up a meeting at Microsoft in Redmond with Bob and another programmer whose name he changed later. These were experienced Microsoft programmers who had done important projects but didn't want to become managers - they wanted to keep programming.</p><p>The spoiler: it's much easier for an independent guy like me to do something like this than for guys inside a big company. Even well-compensated programmers with big titles can't get something like this to happen inside their company.</p><p>I'd seen this before at Apple with the number two guy who wanted me to do a scripting environment because he couldn't get the Apple engineers to do it. Once Apple engineers got wind of it, they put roadblocks in our way - developers shouldn't hold back progress.</p><p>Don Box, another independent guy, joined our one or two day meeting at Microsoft. We had discussions, sketched ideas, then went back and worked. The Microsoft team sent me an example, and I questioned every detail over the phone.</p><p>Their idea of networking was radically different from mine. My idea was RPC - remote procedure calls - because every programmer understands function calls at the most basic level. Everything is a function call if you go deep enough to machine language.</p><p>They wanted objects, classes, and extensibility. I said let's go for it and documented everything immediately. I sent the document to the other three guys and never heard back from any of them - complete silence despite my follow-ups.</p><p>I published XML-RPC without their names, feeling conflicted since it wasn't entirely my creation. But we built the reference implementation in Frontier, put up a test server, and evangelized it like crazy through my widely-read blog.</p><p>Years later, it surfaced inside Microsoft as SOAP, which went to the W3C. I attended the first meeting with 100 people in the room - full-time standards people and representatives from major tech companies ensuring they were represented.</p><p>The W3C process didn't yield anything useful, whereas XML-RPC did. The problem was that within large, complicated companies, ideas couldn't stay simple - they had to accommodate everything. This was what was wrong with the tech industry being brought to the web.</p><p>The warning for today: be careful when you think 'what can go wrong?' Just because you haven't thought of a problem doesn't mean it's not there.</p><p><b>Notes (written by DW)</b></p><p>I got the name of the blog post totally wrong. It was <a href="http://scripting.com/davenet/1998/02/27/rpcOverHttpViaXml.html">RPC over HTTP via XML</a>. </p><p>I sound really tense in this podcast, I needed to do it quickly, but my memory of what happens was imperfect. Didn't have the time to do all the research that's pretty much all in my blog posts in <a href="http://scripting.com/davenet/index.html#y1998">1998</a>. </p><p>And I did make one big mistake, but corrected it quickly. I knew what happened inside Microsoft very soon after XML-RPC was released, it was SOAP, a process I explain here. Collectively, they were just trying to recreate the networking world they all were familiar with, and trying to come up a way to bridge all the different approaches. I think we all would have done much better to skip all the W3C meetings and start to build apps on XML-RPC, and convene a meeting a year later with the developers only and figure out what we want to do next, based on actual experience using the earlier work. </p><p>XML-RPC was a seed, but even thought Microsoft internally fully understood the potential, they never built on it. </p><p>2026 to me feels similar to 1998, but as with the last time, the potential is in the web, and getting away from corporate strategies, instead following the grain of the web, and leaving it up to the companies to adapt. That can work, btw -- it happened with podcasting. But you have to be scrupulous, working for all developers, not just ones at big corporations, and empowering users, or you don't do it. ;-)</p><p><b>Current links</b> </p><p>In 2019, I did an overhaul of XML-RPC website, and created a reference implementation in JavaScript, both client and server (Node.js). </p><p>XML-RPC <a href="https://xmlrpc.com/">website</a>. </p><p>XML-RPC <a href="https://github.com/scripting/xml-rpc">GitHub repo</a>.</p><p><a href="https://xmlrpc.com/docs/xml-rpc-in-json.md">JSON encoding</a>.</p><p>The original website was <a href="http://1998.xmlrpc.com/">preserved</a>.</p>