NP-Overrated

What people fixed was the article's sloppiness around "optimal" and "provably optimal". NP-hardness still rules out a fast exact algorithm for every instance, unless P equals NP. You do not beat that with vibes. You win by changing the game. Package managers drop constraints like single-version uniqueness, use simplified selection rules such as Go's minimum version selection, or lean on heuristics and timeouts. Type systems avoid hard fragments, except in notorious cases like Swift where expressive inference can blow up badly enough for developers to notice. SAT and mixed-integer optimization look magical in practice because industrial instances often have structure. Cryptographic constructions are the opposite. They are built to manufacture the pathological search spaces that shred heuristics. The clearest practical consensus was that complexity theory is underrated as a steering tool. Knowing a problem is NP-hard tells you not to spend months hunting for a universally fast exact solver. It tells you to carve out tractable subsets, parameterize the hard part, accept approximation when the business objective allows it, and design safeguards for adversarial or worst-case inputs. Several people also pushed a second correction that matters just as much in production: polynomial time is not the same as usable. An O(n^3) algorithm can be hopeless on billion-scale inputs, while an exponential-time method like simplex can still dominate because real instances and real hardware favor it.