Some thoughts riffing on LoGlo (2 posts above): https://archive.org/details/akkartik-2020-06-17-LoGlo. 5.5 minutes.

You said "I don't understand spreadsheets", so I'd like to explore this. A spreadsheet is a document for presenting, visualizing and working with financial data. Historically, it is a sheet of paper, marked with a grid, in which financial data is recorded and totals calculated manually. The mathematical relationships between the numbers in the grid are implicit: they are understood (by the human viewer) from context, and not written down. So when we represent a spreadsheet on a computer, and automate the process of computing the sums, we of course show the important financial data, and hide the boring, trivial code that computes the sums. Why would you show the code? The point of a spreadsheet is not to write a program, it is to visualize and work with your financial data.

That is indeed helpful. I was kinda aware of it, but I hadn't focused on it. Historically, was the exact same template reused for page after page? To rephrase my question: what is the essence of spreadsheets' success? Does LoGlo violate this essence, thereby rendering it just another speculative programming model? Or does it preserve the essence, just adding a nice feature that helps with some use cases? This is what I don't understand. History (particularly pre-software history) feels like one input here, but not the whole answer. The point of programming is not to write a program either. The point of programming is to build a tool. The skill of programming is to not make a mess in the face of complexity creep. Paper naturally provides guardrails against messes. It restricts the menu of formulae available. And if you were doing something new you probably had a lower density of formulae on the page. And there was a tendency for large formulae to take up more space on the page. Moving to virtual paper eliminates these restrictions. Mechanisms in regular programming (named functions, compound types, tests) can help manage the new, unconstrained landscape. So programming is interested in spreadsheet creators even if they aren't interested in programming.

Loglo is a tool for creating laser cutter designs, which are line art (vector graphics). The designs are procedurally generated. The UI, instead of only showing you just the final form, also lets you simultaneously display intermediate forms and alternate designs, which is great. Hiding the code and showing the sketches also seems like the right choice. How well does the Loglo UI succeed at the task for which it is designed? (Part of) the essence of spreadsheet's success is duplicating the best features of an already existing paper technology. To judge Loglo, I would look at artist sketchbooks. Eg, consider this image: There are two intermediate forms on the left, and the final result on the right. The explanatory text beside each image is kind of like the "code". If you play the video, the first page of the sketchbook hides the explanations behind the images, which you have to open up like greeting cards. This seems like a metaphor for hiding the code behind the image until you request to see it, in a UI. Visual artists prefer to organize their ideas in 2D space (this is a lesson I learn from the extreme popularity of node+wire visual languages for graphics, relative to text languages, and from looking at sketchbooks created by visual thinkers). Requiring all of the sketches to fit into equal size cells on a regular grid seems like a limitation of Loglos. I think you'd want to organize the sketches on a 2D canvas, and allow for different intermediate forms to have different sizes, depending on their importance and internal complexity. Loglo shows you a series of intermediate forms generated by applying successive operations in a pipeline. That's valuable, but I would also want the ability to display a collection of forms generated by the same function with different parameter values.