Spreadsheets were a formative element of my introduction to programming. I learned them while learning programming and ideas from each influenced my understanding of the other. Generally, since I programmed a lot more, I tended to think in how a standard structural/imperative language would do things, and my spreadsheets started to have more and more complex macros.

Looking back though, what is interesting is that most spreadsheets are a pure functional system. I would say that Excel is the most deployed functionally programmed system. The biggest impediment of an Excel pro to learning conventional programming might be understanding the stateful, imperative, mutating model in the most common application programming languages and frameworks.

For example, if Excel were a programming language, you might say something like

A1 = 3.0
B1 = A1 * 2.0
A1 = 4.0
print(B1)

And you would naturally expect this to print 8.0.

The way to write it is more like this (in Swift)

var A1 = { 3.0 }
var B1 = { A1() * 2.0 }
A1 = { 4.0 }
print(B1())

This prints 8.0 as expected.

In other words, all cells are functions, not expressions or constants. Excel just simplifies your code by wrapping them for you.

Another way would be to use reactive programming, like Combine

let A1 = CurrentValueSubject<Double, Never>(3.0)
let B1 = A1.map { $0 * 2 }
A1.send(4.0)
B1.sink { print ($0) }

Simple, right? It is more in the spirit of what is happening in Excel and lets us use constants instead of variables.

It’s no wonder Excel is popular.

When I was in High School, I had a job in the accounting department of a non-profit. This was the mid-eighties, so a spreadsheet was a giant piece of green paper with cells drawn on them. The department had a mainframe and used computers to process invoices, but a lot of accounting work was still done on paper. I helped file that paper.

At some point, they got a couple of PCs and they installed Lotus 123 on them, but no one was really using them. They knew that I was into computers, and so they asked me to transcribe the paper spreadsheets to Lotus 123 as more of a data-entry clerk.

This work was a seed which grew and grew. At some point I discovered SUM and showed it to someone. I learned more about formulas and built spreadsheets that could auto calculate when the underlying numbers changed. You know, spreadsheet stuff.

By the time I left, my spreadsheets made extensive use of macros and more complex formulas.

In a very real sense, those spreadsheets were programs, and learning how to do that alongside with learning how to program made me better at both.

I think that a lot of people that are good at Excel could learn how to write conventional applications if they wanted to. Even if they aren’t currently writing macros, the main ideas of cells, formulas, range processing, grid-layout, and styling map pretty cleanly onto application software concepts.

If you follow a programming tutorial, at the end you will have some working code. You will hopefully have some idea of how it works.

But, you haven’t learned how to make this code. Programming is different from woodworking or playing a guitar in this way, because they require training your hands. Watching and repeating what you see will work to help you learn and improve.

In programming, it’s good to type fast, but most of what is happening when you make new code is in your head, and tutorials don’t train that part.

This is why I think Programming Tutorials Should be Vaguer. Programming is taking a nebulous problem and breaking it down, understanding it, trying to find building blocks, and then building up something that solves the problem.

The final form is concrete, but it is made by going through multiple phases where you took unclear ideas and made them clearer.

We need tutorials that ask more questions and provide fewer answers.