**Our Take**
This is the most impressive Excel work we've seen in years, not because it's clever, but because it's honest about what the tool can and cannot do. The author solved 100 Project Euler problems using nothing but single-cell formulas, and in doing so, they exposed something most spreadsheet users never encounter: the real limits of Excel's engine and the creative workarounds those limits demand. This isn't a story about how Excel is secretly a programming language. It's a story about how deep understanding of a tool lets you push it far beyond what its designers intended.
What matters most here is what the author learned about Excel's actual behavior under stress. The Sieve of Eratosthenes, a textbook algorithm that should be faster than brute force, turns out to be unusable past 10,000 in Excel because the engine cannot efficiently update arrays. Meanwhile, a naive prime generator that checks every odd number runs exponentially faster up to 500,000. That's not a bug. That's a fundamental constraint of how Excel evaluates formulas, and it flips conventional programming wisdom on its head. Anyone who builds spreadsheets for serious work should take note: the fastest approach in Python can be the slowest in Excel, and the only way to know is to test.
The author also discovered that REDUCE is the most powerful function in modern Excel, used in 59 of their solutions. It replaces for loops, handles iterative accumulation, and passes arrays as arguments in ways that LAMBDA alone cannot. This is practical knowledge. If you are building complex formulas today, REDUCE combined with SEQUENCE and HSTACK is your best path to performance. The biggest headaches in this project, big numbers requiring custom digit-wise arithmetic, recursion limits around 6,400 calls, and the impossibility of dynamic programming, are not theoretical. They are the ceiling you will hit if you try to do real computation in a spreadsheet.
The takeaway is straightforward: Excel can solve hard math problems, but only if you abandon what you think you know about how to solve them. The author had to build their own multiplication functions that store numbers as text, bypass the recursion limit by using built-in functions instead of pure LAMBDA calls, and accept that some problems take five to ten minutes when the engine is grinding through 50,000 rows of work. That is the price of doing serious computation in a tool designed for business tables. If you are willing to pay that price, you can get answers that would otherwise require a full programming environment. But you need to know the limits first, and this project maps them better than any documentation ever could.