Is Excel a programming language?

Is Excel a programming language? Ask the people who build budgets in it and most will say no. They write formulas, not code. Ask computer scientists and the answer has been yes for more than twenty years. Microsoft, which makes Excel, goes further and calls its formulas the most widely used programming language in the world.

For FP&A this is more than a label. If a driver-based forecast is a program, the people who build it are programmers, and the language they write in is one its maker is still extending. This page is part of the research behind our essay In defence of Excel, which calls Excel the most successful programming language ever shipped. Here is the evidence for that claim, with what has been measured kept apart from what has only been said.

Is a spreadsheet a program?

A program is a set of instructions that turns inputs into outputs, and a worksheet is exactly that, with the instructions written into cells. In a 2003 paper for ICFP, ACM’s International Conference on Functional Programming, Simon Peyton Jones of Microsoft Research, Alan Blackwell of Cambridge University and Margaret Burnett of Oregon State University showed it with three cells. Print them as text, one per line (A1 = 3, then A2 = A1-32, then A3 = A2 * 5/9), “and then it plainly is a (functional) program.”

A functional program computes each value from its inputs and changes nothing else along the way. Peyton Jones put it in plainer words on the Microsoft Research podcast in 2021, recalling his thinking when he first joined Microsoft:

“And then I thought, ‘Well, Excel is the world’s most widely used functional programming language.’ It’s not a very powerful one, perhaps, but when you write a formula in a spreadsheet, you are writing in a purely functional language. So, no side effects.”

End-user programming

The research name for people who program this way is end-user programmers: people who write programs to get their own work done, rather than writing software as their job. The 2003 paper defined one as “a teacher, an engineer, a physicist, a secretary, an accountant, a manager, in fact almost anything except a trained programmer.” The standard survey of the field, by Amy Ko and thirteen co-authors in ACM Computing Surveys (2011), puts the scale plainly: “Most programs today are written not by professional software developers, but by people with expertise in other domains working towards goals for which they need computational support.”

On the same podcast, Peyton Jones’s colleague Andy Gordon reached for finance. Excel users, he said, are “really keen to get some other job done, like they’re an accountant, they’re someone working in finance”, and “they’re what are known as end-user programmers.” In that framing a SUMIFS over a ledger extract is a query, and a driver-based forecast is a program.

The model for reactive and dataflow programming

Two more terms help. Dataflow programming describes a program as a network in which each value is worked out from the values it depends on. Reactive programming is the style in which those values update automatically the moment an input changes. Anyone who has changed a growth driver and watched the whole P&L move has used both. A 2013 survey of reactive programming in ACM Computing Surveys, by Engineer Bainomugisha and colleagues at the Vrije Universiteit Brussel, says plainly where the idea comes from:

“This property of automatic management of data dependencies can be observed in spreadsheet systems, arguably the most widely used end-user programming language. A spreadsheet typically consists of cells, which contain values or formulas. If a value of a cell changes then the formulas are automatically recalculated. Reactive programming is essentially about embedding the spreadsheet-like model in programming languages.”

A whole branch of computer science, in other words, set out to copy into conventional languages what a budget model does every time you press Enter. In 2016 researchers at TU Delft, Felienne Hermans and five co-authors, went further: “Spreadsheets can be considered to be the world’s most successful end-user programming language. In fact, one could say spreadsheets are programs.” They credited that success to “liveness, directness and an easy deployment environment”. In our terms: you see the result as you type, you work on the numbers themselves, and you share the model by sending the file.

Notice the hedges, “arguably” and “can be considered”. The 2003 paper settled for “a popular, but limited, end-user programming paradigm”. The research treats the spreadsheet as the reference case for end-user, reactive and dataflow programming, but it is careful with the superlative, and anyone quoting it should be too.

How many people program with spreadsheets?

There is one rigorous, peer-reviewed estimate. Chris Scaffidi, Mary Shaw and Brad Myers of Carnegie Mellon University published it in 2005 at VL/HCC, the IEEE symposium on visual languages and human-centric computing. They took 2001 survey data from the US Bureau of Labor Statistics (BLS) and the Census and projected it to 2012:

“With these improvements to Boehm’s method, we estimate that in 2012 there will be 90 million end users in American workplaces. Of these, we anticipate that over 55 million will use spreadsheets or databases (and therefore may potentially program), while over 13 million will describe themselves as programmers, compared to BLS projections of fewer than 3 million professional programmers.”

That is more than 18 spreadsheet and database users for every professional programmer. Their middle estimate, if half of those users write programs, was that “around 25 million spreadsheet and database end users could be programming.” Spreadsheet use at work, the paper notes, “rose sharply from 32% to 62%” between 1997 and 2001, while only 15% of users in 2001 said they “did programming”.

Three caveats come with the numbers. They cover the United States only. They are a projection for 2012, made in 2005. And “over 55 million” counts people who use spreadsheets or databases, not people who write formulas. The paper cites a study of Australian workers in which “only 47% used the ‘if’ function”, and one of spreadsheets on the web in which “only 44% contained any formulas at all”. Even so, the people who program in spreadsheets far outnumber the people who program for a living.

Where the famous “55 million” came from

You may have seen an older version: 55 million end-user programmers against 2.75 million professionals, twenty to one. It measured something else. In 1995 Boehm, in a report on COCOMO 2.0, a model for estimating the cost of software projects, predicted “55 million performers” of “end-user programming” in the United States by 2005. It was repeated in later work, including the 2003 Microsoft Research paper.

In a February 2005 technical report (not peer-reviewed), Scaffidi, Shaw and Myers went back to the source. The number, they found, “actually estimates the number of computer users in businesses”, not programmers, and “it assumes constant computer usage rates”. The 1995 report had even set the work aside as too small to model: “The User Programming sector does not need a COCOMO 2.0 model. Its applications are typically developed in hours to days, so a simple activity-based estimate will generally be sufficient”. The famous figure is history, not a current statistic. Confusingly, the corrected estimate also lands on 55 million, but it counts people using spreadsheets or databases at work in 2012. That is the one to quote, labelled as a US projection.

Who called Excel “the most widely used programming language”?

Microsoft did. The phrase doesn’t come from an academic paper, and the 2003 paper never used the superlative. The earliest use we have found is by Brian Jones of the Excel team, announcing LAMBDA on 3 December 2020: “Excel formulas are the world’s most widely used programming language, yet one of the more basic principles in programming has been missing, and that is the ability to use the formula language to define your own re-usable functions.” On 25 January 2021 Andy Gordon and Simon Peyton Jones repeated it on the Microsoft Research blog, writing of Excel:

“It’s also the world’s most widely used programming language. Excel formulas are written by an order of magnitude more users than all the C, C++, C#, Java, and Python programmers in the world combined.”

On the podcast in May 2021 Peyton Jones went further still, off the cuff: “there must be a hundred times as many users of formulae in Excel as there are professional programmers in the entire planet.” Taken literally, that would mean billions of formula writers, more than the 1.2 billion Office users Microsoft itself reported in 2016. It is best heard as a figure of speech.

Does the claim hold up?

Nobody has measured it. It is Microsoft describing Microsoft, and no Microsoft Research paper gives a counting method. It can be checked for plausibility, though. An industry estimate by the developer-research firm SlashData, not peer-reviewed, put professional developers worldwide at 36.5 million in early 2025. “An order of magnitude more” than that means hundreds of millions of formula writers, which matches the wording Microsoft uses for Excel’s users. Plausible, then, but resting on two sources that were never designed to be combined. Even a generous discount leaves the point standing.

What the language was missing

In 2003 Peyton Jones, Blackwell and Burnett named the formula language’s central weakness:

“spreadsheets lack the most fundamental mechanism that we use to control complexity: the ability to define re-usable abstractions. […] Can you imagine programming in C without procedures, however clever the editor’s copy-and-paste technology?”

Every analyst knows that copy-and-paste technology: January’s formula, dragged across twelve months and forty cost centres, because there is no way to package the logic once and call it by name. In 2021 Gordon and Peyton Jones named two historic shortcomings: the language “really only supported scalar values” (single numbers, text or true-or-false values, not whole ranges), and “it didn’t let users define new functions.” The milestones below are largely the story of fixing both.

How many people use Excel?

Microsoft does not publish a count of Excel users, and we know of no independent worldwide count. Here is what Microsoft has said on the record:

• 2015. “Today for our productivity services we have 1.1 billion users.” (Qi Lu, executive vice president for applications and services, at an investor conference on 2 March.)
• 2016. “Today, we have 1.2 billion users using all versions of Office products.” (Qi Lu at Microsoft’s Build conference on 31 March, a day after Satya Nadella gave the same 1.2 billion.)
• 2025. Excel is “a foundational tool used by hundreds of millions of people across industries, roles, and continents” (Excel Blog, 30 December).
• 2026. “paid M365 commercial seats grew 6% year-over-year to over 450 million”, mainly in small and medium business and frontline worker plans (chief financial officer Amy Hood, 28 January).

These measure different things. The 1.2 billion covers every version of every Office app and is ten years old. The 450 million are paid business licences, not active spreadsheet users. The only figure for Excel itself is “hundreds of millions”, and like the rest it is Microsoft describing Microsoft, with no published method. For a board paper, “hundreds of millions of people (Microsoft, 2025)” is the wording you can defend.

The “750 million Excel users”

The most repeated number is the one to avoid. “750 million Excel users” turns up in blogs and news stories as recently as June 2026, often attributed to Satya Nadella in 2017. It cannot be traced to any Microsoft transcript, report or post. It sits inside Microsoft’s own range, which may be why it survives. If you use it at all, call it a widely repeated estimate with no known source.

How the formula language grew, 2018 to 2026

Excel debuted on the Macintosh on 30 September 1985. Forty years on, its formula language is still gaining major features, and much of that work came out of the Calc Intelligence project at Microsoft Research Cambridge, which describes a “long-standing partnership with the Excel team to transform spreadsheet formulas into a full-fledged programming language”. The work also went through peer review. A paper at ESOP 2020, a programming-languages conference, gave “the first formal calculus of spreadsheets with spilled arrays” and proved that the process deciding which arrays spill “converges deterministically”. The #SPILL! error, in other words, is designed behaviour with a proof behind it, not a quirk. A 2020 paper in the Journal of Functional Programming tested with spreadsheet users how a function built for a twelve-month range can work on a range of any size, the reuse problem of every rolling forecast.

The dates come from Microsoft’s own announcements, with the preview first and general availability second.

The two biggest steps, dynamic arrays and LAMBDA, fix the two shortcomings Gordon and Peyton Jones named. One formula can return a whole schedule, such as a sorted list of cost centres, and Ctrl+Shift+Enter is legacy. A long nested IF can become named steps (rate, base, uplift) that the next analyst can read. And a team can keep its own function library, a standard allocation or a day-count rule, inside the workbook, without VBA or add-ins.

What “Turing-complete” means

A Turing-complete language can, in principle, compute anything: given enough time and memory, it can express any calculation any other programming language can. Excel got there through recursion, a function that calls itself. In Brian Jones’s words: “If you create a LAMBDA called MYFUNCTION for example, you can call MYFUNCTION within the definition of MYFUNCTION. This is something that before, was only possible in Excel through script (like VBA / JavaScript).” Gordon and Peyton Jones gave the verdict: “With LAMBDA, Excel has become Turing-complete. You can now, in principle, write any computation in the Excel formula language.”

Formulas had come close before. In 2013 Felienne Hermans built a Turing machine, the textbook model of a general-purpose computer, in Excel “using formulas only”, with one row for each state. Gordon and Peyton Jones called her blog post “lovely” but noted that the number of steps “is limited by the number of rows.” LAMBDA removed that limit. So when a forecast model struggles, the cause lies in how it was designed, not in what Excel can compute.

AI beside the grid, not inside it

Most of the AI work has happened next to the formula language rather than in it. In August 2025 Microsoft put AI inside a cell with the =COPILOT function, which recalculated with the data. It was withdrawn on 14 September 2026, with users pointed to “the Copilot side pane”. Agent Mode, an assistant that builds and edits formulas, became generally available on Windows in January 2026, and the Copilot Skills of June 2026 took finance work as their examples: “building a DCF model, closing the books, refreshing a monthly reporting model, or preparing a variance analysis.” Microsoft gave no reason for retiring =COPILOT. The effect is that the formulas themselves stay deterministic: the same inputs always give the same answer.

What the evidence doesn’t show

No one has counted the world’s spreadsheet programmers. The one rigorous estimate is American, dates from 2005 and projects only to 2012, and we know of no peer-reviewed update. Any global comparison, ours included, sets Microsoft’s descriptions of its own product against an industry estimate of developers.

“The world’s most widely used programming language” is a claim, not a measurement, from a company that publishes no method for it and no monthly count of Excel users. Independent researchers hedge it. And headline user numbers say how many people have Excel, not how many write formulas in it.

None of this weakens the case we make in In defence of Excel. The one rigorous count finds spreadsheet users far outnumbering professional programmers, three research communities treat the spreadsheet as their reference case, and the language is still growing forty years on. For how finance shaped the tool, see How budgeting built the spreadsheet; for why it is so easy to start, see Why the grid fits how we think. The next post in the series looks at where Excel breaks.