When we write programs in a conventional programming language, what we're doing with the data is shown front and centre, and the data itself is sidelined or often not even present. In a spreadsheet, this is reversed: the data is prioritised, and the formulae are hidden.
There's an immediacy to a spreadsheet: the user can start with very literal actions on data, and slowly introduce abstractions like formulae. In conventional programming, the programmer has nothing but abstractions with which to work.
It's reminiscent of one of Fred Brooks' remarks about how showing the data structures makes the algorithms obvious, but showing the algorithms reveals little about the data structures.
I think similar remarks can be made in regard to Jupyter notebooks and their popularity among scientist, engineers and data people. Yes, they are still more in the conventional programming realm, where the code is in the foreground, yet to some extent they bring more immediacy. The fact that you can look and investigate at the data you are dealing with at every step (print the table, make a plot etc) is powerful.
Another thing would be of course powerful REPL environments.
And there are also visual environments like Matlab's Simulink and Modelica. Can you write control algorithm or a bunch of differential equations in any language? Yes. But control engineer can just take a quick look at screenshot of a Simulink model and already have a good idea on what is going on there. This cannot be said about the code.
This may be rather unpopular among hackers, where TTY clones and vi emulation rules everything, but computers and software seem to me most powerful and enabling outside the usual coding context of putting streams of characters into the source file using a keyboard.
As developer starting coding in the 1980's, that always valued high level approaches to computing than plain bits and bytes, I find this a kind of tragedy, given that productive tools helps everyone.
I love a quote from from some VB folks, that while others laught of them using VB, they were laughing all the way to the bank themselves.
My only complaint about visual environments, is that not all offer modular tools, the EEE IC version of a module or function, some are quite primitive only allowing one screen for the whole flow.
I wonder what place will be left for the TTY clones and vi emulation folks, when everything on the system is driven by systems programmed in agentic tools, command line wizardry replaced by MCP like tools and such.
Even just regular matlab gives you some of that data immediacy because you can just ctrl-enter on a block of code which will execute just that block and show you results in the console. Very handy for seeing what various bits do to the data.
The immediacy is you are looking at the data. What you’re going to do with it may not yet be known Is it the right data? What are the values? What are the features?
I write scripts at work and tell colleagues if they want my help they should first work it out in Excel and write an outline of the details. If they can’t do that, then the problem may not be a candidate for _script automation_.
Our pipeline is not fully automated, but that’s how I describe it. The rest is Excel Carpentry.
I've had a lot of experience with dealing with exactly this problem in ML.
There is no replacement for visualizing the data and intermediates. You have to see what is going on, it's the only way to catch bugs and issues and make good performance improvements.
Like actually looking at the gradients and weights and activations and predictions and stuff often shows you that something janky is going on, its great for adjusting architectures. Looking into specific high loss test samples and mispredictioms and stuff will show you that there are problems with your data or normalization and whatnot.
The issue is that there are basically an infinite number of intermediates you could potentially look at. So ignoring almost all of them is the only thing that scales and you have to be extremely deliberate.
Now that you mention it, that’s one of the things I always appreciated about working with Adobe Flash as a developer - the vector graphics and key frame tweeting is prioritized, while the Actionscript is hidden. Most visual elements you can change immediately by clicking and dragging with your mouse.
That is an interesting take on spreadsheets. I wonder if it is possible to establish some way to switch back and forth between 'programming view' vs 'spreadsheet view'.
I think the best we have at the moment debugger view; in other words a snapshot of the state of the system. Maybe with a dashboard you can see some progression over time ?
(I somehow though of the videogame Factorio and of that thing called Labview, but I cannot form a coherent thought about it)
You're in for a treat. The quote, in case you haven't looked it up yet, is "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." The canonical work is The Mythical Man-Month: Essays on Software Engineering
There's an immediacy to a spreadsheet: the user can start with very literal actions on data, and slowly introduce abstractions like formulae. In conventional programming, the programmer has nothing but abstractions with which to work.
It's reminiscent of one of Fred Brooks' remarks about how showing the data structures makes the algorithms obvious, but showing the algorithms reveals little about the data structures.