The Programming Language That Solved Everything in the 90s (And Nobody Cared)

You’ve probably never written a line of Standard ML. And that’s exactly the problem.

I stumbled across Poly/ML the way most people discover uncomfortable truths: by accident. A GitHub repo. A PDF. And one sentence that stopped me cold: “Standard ML is a functional programming language, in the sense that the full power of mathematical functions is present.” Wait — what? The full power of mathematical functions? In a language from the 1990s? The same decade that gave us CGI and the blinking marquee tag?

Here’s the uncomfortable truth the software industry doesn’t want you to know: We’re spending billions duct-taping functional features onto bloated languages when the perfect version already exists, has existed for thirty years, and is basically invisible.

Standard ML (SML) is a functional programming language that treats functions the way mathematicians do — pure, composable, mathematically sound. No side effects. No mutable state to chase through 10,000 lines of code. No “this variable changed somewhere — good luck finding where.” It’s the programming equivalent of a Swiss watch in a world of plastic toys.

And yet, go to any tech conference. Ask about SML. You’ll get blank stares. Meanwhile, Java adds lambdas, C++ adds ranges, Python adds pattern matching — and each addition is celebrated as a breakthrough. It’s like watching someone reinvent the wheel and charge for it, while a complete wheel factory sits abandoned in the corner.

Ecosystem momentum and hype cycles decide what we use, not language quality. SML never had a corporate sugar daddy. No Google, no Apple, no Amazon evangelized it. It lived in universities, in compilers textbooks, in the quiet brilliance of researchers who actually understood computation.

Let me give you a concrete example. A friend of mine — a senior engineer at a FAANG company — spent three weeks debugging a race condition in a Python microservice. Three weeks. The same logic, expressed in SML, would have been mathematically impossible to break. Not “harder to break.” Impossible. Because the type system won’t let you have data races. The purity guarantees mean you can reason about the code like a formula.

But we don’t choose languages based on soundness. We choose based on the size of the community, the number of npm packages, or whatever framework is trending on Hacker News this week. The industry doesn’t reward elegant solutions. It rewards ecosystem buy-in.

I’m not saying you should drop everything and rewrite your web app in SML. That would be naive. What I am saying is that every time you struggle with null pointer exceptions, every time you chase a ghost through a React useEffect, every time you mutter “this should be easier” — you’re living proof that the industry has chosen convenience over correctness.

And SML sits there, quietly perfect, waiting for no one.

The innovations you’re chasing today were solved decades ago — in languages you’ve been taught to ignore. That’s not a complaint. It’s a call to look up from the hype and realize that the foundations of computation aren’t trending on Twitter. They’re just true.

So here’s my challenge: find the Poly/ML repo. Read the PDF. Write one function — just one — in pure SML. See what it feels like to write code that you can actually trust. And then ask yourself: why aren’t we building on this?

The answer will tell you more about our industry than any tech blog ever will.