I feel like I’m getting old and crotchety. Every time I go back and watch the canon of FoC videos, I more and more disagree with statements of the form: If only everyone had followed this good old idea, everything would be great by now! Examples: - Alan Kay in “The Computer Revolution Hasn’t Happened Yet” says HTML and browser wars are stupid because we should be shipping the renderer with the file itself. - Bret Victor in “The Future of Programming” says it’s crazy that we’re programming in text files because Smalltalk had a function-centered IDE. But I feel these examples always miss some important context. Social context, technical context, economic context. Shipping a rendering engine with an HTML file would be a technical nightmare. Programming still happens in text files because text files are an incredibly durable, universal format that can be passed around to dozens of auxiliary tools (e.g. code review -- see why everybody hates collaborating on Jupyter). These talks are still obviously insightful, both for reminding us of computing history, and pointing out important issues in the status quo. But I’m always extremely skeptical when they don’t address why programming became the way it is. I have yet to see a talk that grapples with the messy reality of the world, how we have to daily work with huge systems coded by thousands of people who we barely trust. Gone are the days where 10 smart people at PARC can hack together an OS themselves with absolutely no concerns for security, accessibility, backwards-compatibility, … I would love to see more visions for FoC that take these realities into account.

I am certainly biased in this conversation. I do agree that world is inevitably messy and that we have to deal with it. It is for this reason that I believe a new language to create systems, while well intended, is unlikely to address the problem of existing systems already out there. At the same time, I do believe that we can make significant advances by focusing on the reverse part. The skill of reading the code we have is essential. And that cannot be improved significantly if the only form we have to read is text. We should distinguish between a storage or exchange format for a content, and the interface through which we interact with the content. I can send an HTML file around, and still choose to view it in a browser. The two are distinct and still can coexist. The way we read doesn’t have to, and should not be the same as the way we edit.

Here's a fellow crotchety old Will. 🍷 I do like to factor in why-are-things-the-way-they-are when thinking how they might be different. Sometimes it's an accident. Sometimes there are deep reasons. Text is awfully flexible. Once you get into it, there's quite the gravitational pull.

One possible reading of "shipping the renderer" is that the document can be shipped as a program that renders the desired output in a resolution independent manner as a side effect of it being run. If this sounds like a crazy idea, consider that all Postscript and PDF documents are exactly this (the underlying language is essentially a dialect of FORTH). The inventor of those technologies was John Warnock who was at Utah with Kay (in fact, they shared a PhD advisor in David C. Evans; Warnock's other advisor was Ivan Sutherland, the person who made SketchPad).

I fully agree. Well, mostly, in fact, I could discuss the part about text files, but I guess you only mean (or don't you? 🙂 ) it as an illustration, so I skip this discussion... As for the context, I agree it is a very important aspect. It is which gives lots of inertia to what is happening and what we can change. And you have to be aware of that when you work on FoC projects. To use the cost function metaphor, we are at a local minimum. And all the social/technical/economic contexts explains why we are at this minimum. They are the force that pull us down to it. So what is this local minimum? Is there other lower minima? Where are they? What is the path to go there? etc. And as Foc builders I agree with that we must know all this: the minima we want to reach and the path to go there. And you will do some compromises. As an illustration, in my case, I identified that one context aspect of the current local minimum that is hard to go away for me, is the web plateforme. If I want to provide something that can be used by most of the people soon, I know the web plateforme is a very good fit. And even if it has lots of technical problems that I want to get rid of. So I decided to stick with this aspect of the current local minimum of "the present of coding" and choose to work on other aspects. Here is another illustration of how to be aware and how to deal with these context aspects that are local minima. It is about adoption and audience. Something about the social context that is very costly to "move", is the current "programming audience". It is very hard to change habits and well established "standards", even if there are problems with them you want to change (random concrete example that I encountered: bash scripting). So one very risky and difficult strategy is to decide not to target this audience first and hope it will be convinced later. So I guess I will try this strategy, I want to propose new programming tools that I know most of today programmers won't want to use, so I will first target new programmers, that are not bias by the current programming context. Then if things go well, keeping the good parts of what I will build, maybe current "established" programmers will use them. So it is an other way to be aware of the context and try to deal with it to build a FoC vision.

But I’m always extremely skeptical when they don’t address why programming became the way it is.

It's important to consider the context. Why things are the way they are today. But also why things were the way they were yesterday. Back then is was assumed that to use a computer one has to be a programmer. There was no distinction between programmer and user. It was the same. We've given that up, clearly. Even though many of us here seem to question if it has to be like that. We are much further down a certain branch of the design space and it only ever gets more complicated from here. There's only so much we can "fix" here, if we stay on the same branch, take the present as given, and only look towards the future. But what other places could we find, if we're willing to backtrack to a much earlier time and take a different branch from there?

Shipping a rendering engine with an HTML file would be a technical nightmare.

My FoC project will eventually do this on the browser using Web Assembly and WebGPU. Shipping your own renderer is what WebGPU is for. As a specific example, my FoC includes zoomable UIs (ZUIs), one of those really good ideas from the 1970's (eg MIT's "Dataland") that never became mainstream. You can build a ZUI in the browser if you ship your own renderer. Eg, see http://wdobbie.com/warandpeace/

If only everyone had followed this good old idea, everything would be great by now!

I disagree which statements of this form too. I don't get this sense from most "FoC cannon" though. My interpretation is more like "hey this research trajectory looked really promising but never got funded, explored, developed, (in fact due to social and economic factors)". Possibly in the alternative reality we would have a new set of problems and issues. The FoC group (that's us in the alternative present!) would be discussing those problems and solutions in this slack really advanced multi media collaborative space . The question I ponder is: would we be looking at Unix + text files etc. (the "alternative that didn't happen") as something potentially better? I tend to answer "no".

Shipping a rendering engine with an HTML file would be a technical nightmare

It's called "an app", in a large number of cases. And yes, technically a bodge.

@Will: Yeah. To the extent that the future of software is inseparable from the future of critical thinking, these statements feel counter-productive. Even if they lead to good ends (which is questionable), means matter in the long term. Our canon feels impoverished for being phrased in terms of stone tablets from on high. Too much emphasis on aesthetics ("how cool is a retrohistorical talk?!") Here, I'm going to spin up a new thread..

Certainly a respect for the constraints of our predecessors will avoid us from tripping over Chesterton's fence. However, it's worth noting how most tools are designed to edge toward a local min or max rather than a global one. I appreciate the "What if" because we don't know what a local min or max would have been like if a different paradigm had been embraced. Sadly we are often left in situations where we have built quite the city in a valley when we realise that the next valley over would have been a better location. I am not presumptuous enough to expect an entire city to get up, move over, and rebuild in unfamiliar lands, with new materials, and new constraints. However, I do expect that new city to grow while the old one slowly crumbles-- if those that settle the new city are right.