Excel

Microsoft Excel is best known as a spreadsheet application, but inside that application is a programming language: the Excel formula language, a cell-referenced, declarative, functional language that has been continuously developed since 1985. Hundreds of millions of people use it — most of them without ever calling themselves programmers — to express calculations, data transformations, and increasingly sophisticated logic by typing expressions into rectangular grids of cells. Since the introduction of the LAMBDA function in the early 2020s, the worksheet formula language has been formally Turing-complete, capable of expressing recursive user-defined functions entirely in cells without any host programming language.

This page is about the formula language itself, not the broader Excel application or the VBA macro language that ships with desktop Excel. The formula language is a small, opinionated functional language that grew out of the spreadsheet idea pioneered by VisiCalc in 1979 and has since become arguably the most widely used programming language in the world.

History & Origins

Microsoft’s spreadsheet ambitions began with Multiplan, a character-mode product first shipped in 1982 that competed against VisiCalc and, later, against Lotus 1-2-3 — the IBM PC market leader of the early 1980s. Multiplan used a numeric R1C1 addressing scheme, did not run especially well on the IBM PC, and was largely outsold by Lotus 1-2-3 after that product’s 1983 release.

Microsoft’s response was a fresh project, led internally by Bill Gates and Jeff Raikes, that targeted the new Apple Macintosh and its bitmap display. The formula engine was designed by Doug Klunder; the project introduced what would become Excel’s signature features: A1-style addressing, on-screen WYSIWYG formatting, and a recalculation strategy based on tracking cell dependencies so that only affected formulas were re-evaluated when an input changed. Excel 1.0 shipped for the Macintosh in September 1985.

Excel 2.0 followed for Windows in 1987, becoming one of the first headline applications for the still-fledgling Windows 2.x platform (it reportedly shipped with a runtime copy of Windows for users who did not yet have it installed). Through the late 1980s and early 1990s, Excel steadily gained market share against Lotus 1-2-3, helped both by its graphical interface and by Microsoft’s bundling of Excel into the Office suite. By the mid-1990s Excel had become the dominant spreadsheet, and its formula language had become the dominant spreadsheet formula language by extension.

Design Philosophy

The Excel formula language is shaped by the spreadsheet model itself. A workbook is a grid of cells; each cell holds either a literal value or a formula. The language is:

• Functional — formulas are pure expressions over their inputs, with no statements, no mutation of cells from inside a formula, and no explicit control flow beyond conditional functions like IF, IFS, and SWITCH.
• Declarative and reactive — the user writes what a cell equals; the calculation engine decides when to evaluate it based on a dependency graph derived from cell references.
• Cell-referenced rather than variable-referenced — the primary “names” in a formula are spatial: A1, $B$2:$B$100, Sheet2!C3. Named ranges and (more recently) the LET function provide ways to introduce variables, but cells remain the fundamental binding mechanism.
• Universal-by-design — the language must be usable by accountants and analysts who are not professional programmers. Syntactic minimalism is enforced ruthlessly: there are no statements, no semicolons in the English-locale grammar, and no separate type system to learn.

A consequence of these choices is that programs in the Excel formula language tend to be short formulas distributed across many cells, rather than long pieces of code in one place. Logic is read by following the dependency graph between cells, often visualized with the Trace Precedents and Trace Dependents tools.

Key Features

Cell References, Ranges, and Three-Dimensional Addressing

The fundamental syntactic device is the cell reference. Excel supports several reference styles:

The relative/absolute distinction is one of the language’s signature pieces of ergonomic design: copying a formula across a region transforms its references in geometric ways that are nearly impossible to express as concisely in any conventional programming language.

Functions

The standard library is large — Microsoft 365 ships well over 500 worksheet functions — and divided into broad categories: math and trigonometry, statistical, financial, logical, text, date/time, lookup and reference, information, engineering, cube, database, and (recently) web/AI integration. A few representative examples:

=SUM(B2:B100)
=AVERAGE(IF(category="Engineering", salary))
=VLOOKUP(empId, employees, 3, FALSE)
=XLOOKUP(empId, employees[Id], employees[Salary], "n/a")
=INDEX(MATCH(...), MATCH(...))
=NPV(rate, cashflows) + investment
=TEXT(today, "yyyy-mm-dd")

XLOOKUP, introduced around 2019–2020, was a notable language-level addition: it replaced the long-criticized VLOOKUP with a function that accepted lookup-and-return arrays directly, removed the column-offset argument, and supported approximate match modes more cleanly.

Dynamic Arrays

Historically, an Excel formula returned a single value into the cell that contained it. Array formulas existed but required entering with Ctrl+Shift+Enter and pre-allocating a destination range. The dynamic arrays update, rolled out across Microsoft 365 starting in 2018 and broadly available by 2020, changed the calculation engine so that a single formula could spill its results into adjacent cells automatically:

=UNIQUE(orders[Customer])
=SORT(FILTER(sales, sales[Region]="EU"))
=SEQUENCE(10)

These functions return arrays whose shape is determined at calculation time; the engine handles allocating the spill range and recalculating dependents when the array’s size changes. This was the largest change to the formula language’s evaluation model in decades.

LET and LAMBDA

Two functions introduced in the early 2020s elevated the worksheet language from a calculator into a small but complete functional programming language:

• LET binds names to intermediate expressions inside a formula, eliminating repeated subexpressions:

  =LET(
      revenue, SUMIFS(sales[Amount], sales[Year], 2025),
      cogs,    SUMIFS(costs[Amount], costs[Year], 2025),
      margin,  revenue - cogs,
      margin / revenue
  )
  

• LAMBDA defines an anonymous function. Bound to a name in the Name Manager, it becomes a first-class user-defined function:

  // Defined in Name Manager as DISCOUNT
  =LAMBDA(price, rate, price * (1 - rate))
  
  // Called from any cell
  =DISCOUNT(B2, 0.10)
  

Combined with helper functions such as MAP, REDUCE, SCAN, BYROW, BYCOL, and MAKEARRAY, LAMBDA enables a recognizably functional style — including recursion, since a LAMBDA can refer to itself via its bound name. This is the development that is usually cited as making the worksheet formula language Turing-complete.

Errors as Values

Excel’s formula language treats errors as first-class values rather than as exceptions. #DIV/0!, #VALUE!, #REF!, #NAME?, #N/A, #NUM!, and #NULL! propagate through formulas and can be intercepted by IFERROR, IFNA, and the introspection function ERROR.TYPE. This propagating-error model is closer to the Maybe/Either style of statically typed functional languages than to the exception model of mainstream imperative languages.

Data Types

The formula language has a small, dynamic type system: numbers (stored as IEEE 754 double-precision), text, booleans, errors, and arrays of these. Dates and times are numbers under the hood (days since the workbook epoch). More recent versions added linked data types — rich record-like values for entities such as stocks, geographies, currencies, and (in some channels) custom organizational data types — accessed with the . operator (A1.Population, A1.Price).

Evolution

Although Excel as an application has shipped many releases over four decades, the formula language itself has historically evolved more slowly than the surrounding application. The most consequential language-level changes are concentrated in two periods.

The “modern revival” period is sometimes informally credited to a small Microsoft research group — including Andy Gordon and Simon Peyton Jones — that argued publicly for treating the formula language as a programming language deserving of language-design attention. The 2020 paper “LAMBDA: The ultimate Excel worksheet function” announced LAMBDA in essentially those terms.

Current Relevance

The Excel formula language is, by reasonable estimates, one of the most widely used programming languages in the world. Microsoft has stated on multiple occasions that Excel has hundreds of millions of users; the share of those users who write at least simple formulas is plausibly in the same order of magnitude. Excel files are a lingua franca for tabular data exchange across business, government, and academia, even where the recipients use Google Sheets, Apple Numbers, or LibreOffice Calc as their primary tool — all three of which implement substantially compatible formula dialects.

Excel’s role has also visibly shifted in the last decade. Pure analytical workloads have migrated toward Python, R, and SQL-based BI tools; in response, Microsoft has both made the formula language more powerful (LAMBDA, dynamic arrays) and integrated other languages directly: M and DAX inside Power Query and Power Pivot, and Python in Excel for users with Microsoft 365 subscriptions. The application is increasingly a multi-language environment in which the worksheet formula language remains the central, default surface.

The language also continues to receive language-design research attention. Microsoft researchers and academic collaborators have published work on calculated columns, type inference for spreadsheets, and program synthesis (including the Flash Fill feature, which infers transformations from examples). The Calc.ts and Power Fx work at Microsoft generalizes Excel-style formulas to other application surfaces, including low-code platforms.

Why It Matters

Excel matters as a programming language for three intertwined reasons.

First, it is a functional language whose users overwhelmingly do not know they are using a functional language. Pure expressions, no mutation, dependency-driven re-evaluation, and a large library of higher-order-friendly array functions describe a language closer to ML or Haskell in semantics than to C or Python — yet the typical user is an accountant, an analyst, or a scientist with no formal training in functional programming. Excel is, in this sense, the most successful real-world deployment of pure functional programming ever shipped.

Second, the spreadsheet model has a software-engineering profile that is genuinely distinct from text-file programming. Programs are spatial: the layout of formulas across a sheet matters for both correctness and readability. Bugs are local in the dependency graph but can be hard to see in the grid. There is no version control story comparable to text-based diffs, although Microsoft and third parties have built tools that approximate it. Studying Excel as a programming language has helped clarify what general programming environments take for granted — and what they could borrow.

Third, Excel is load-bearing infrastructure. It runs the financial close at most public companies, a great deal of small-business accounting, and substantial parts of public-sector data handling. High-profile failures — the public-health row-limit incident of 2020, the gene-symbol-to-date corruption that led HUGO to rename approximately 27 genes in 2020, the JPMorgan “London Whale” 2012 trading-loss model errors — illustrate how seriously the language’s quirks can affect the world when models are deployed without engineering discipline. That those incidents are programming failures, in a programming language, is part of why Excel deserves a place in any serious encyclopedia of languages.