Cost of computing
We accept that the costs of things change throughout history, but the sheer magnitude of that change can be staggering when you step back and contemplate it.
For example, the light we emit in our homes on any given night would have cost a small fortune (in today's money!) 700 years ago.
Moore's law is another example of radical price changes.
Another example is solar energy prices (note the log scale!).
What about the cost of writing programs?
Admittedly, I'm probably not the right person to answer this question. I think this is a question at the intersection of software engineering and economics. I know a great deal about one, and not the other. I'm sure someone's had this thought before, but I can't find a lot on the topic.
Historically, I know that writing programs used to be more expensive. There was a time when you wrote programs on punch cards. There was a time when you wrote programs in Assembly.
In my own experience writing software over the last couple decades, the cost of writing programs has been stagnant. Some things have gotten easier, and some things harder, but these changes have been marginal. Dependency management is much easier than it used to be. So is virtualization. Linux containers make you feel confident that your system mirrors production. But, on the other hand, we didn't have elaborate frontend systems in 2003 or complex container orchestration. This is all beside the point, though. The point is any change in the cost of writing programs is marginal, and has been eaten up by the larger and larger demands of new programs.
What would a radical departure in the cost of writing programs look like? Spreadsheets.
Spreadsheets let you construct elaborate models. They're not text files, they're dynamic programs. They're not exactly easy to learn, but they're vastly more accessible than pretty much any other programming language. I'm not aware of any programming environment since Spreadsheets that have fundamentally altered the cost of composing programs, at least none that have enjoyed widespread adoption.
What could it mean for society if programs were radically cheaper to create?
Again Victor does an incredible job here. It's about an hour long, I'd encourage you to watch it if you have time.
The Humane Representation of Thought from Bret Victor on Vimeo.
If programmers were radically cheaper, all sorts of thought work would be faster and better and more accessible. We'd have better doctors, buildings, climate solutions, laws, movies, airplanes, pillowcases, etc.
The impact of future innovation can be hard to imagine. I'll borrow some examples from Victor if you didn't have time to watch. To illustrate the magnitude, we only have to look at the past.
There was a time, in the not too distant past, when the plot had not been invented. Data was represented in tables like this.
Then, William Playfair invented a visual representation of the same information.
Can you imagine contemplating recessions, COVID numbers, or the climate crisis without Playfair's plot?
This is what a leap forward looks like. And it can happen for programming too. We can have programs that are radically simpler to read and write.
To make this happen, focus on the ambitious learner
In order to make programming cheaper, we need to focus on novices. Professionals have too many assumptions about what programming is. We need to focus on people who have no existing notions of data structures, code, or debugging.
The feedback loop is simple. Take a group of smart people, and teach them how to make programs. The goal should be to get them to "bicycle of the mind status," meaning that they can support themselves and let the computer take them wherever their mind wants to go.
This process will undoubtedly have hiccups. Write these down. Focus on these. Retool the curriculum, and take another batch of students. Rinse and repeat.
Don't worry about teaching these students the latest technologies that everyone is using. Don't worry about giving them conventional wisdom. The point is to diverge from conventional wisdom.
Don't be afraid to take on projects that seem very ambitious. Write better programming languages. Write better standard libraries. Write better IDEs. But, optimize them for the learner.
(Note: Making programs cheaper ≠ making programmers cheaper.
They're related, but different concepts. But, we can use the learning process as a sort of "debugger" for the entire concept of programming. It can illuminate the rough parts.)
- Next: How to help a student get unstuck
- Previous: Playing with Hilbert