A function packages a reusable block of code that can be called repeatedly from different places in a program without rewriting the same logic each time. Scope determines exactly which variables a given piece of code can actually see and use at a specific point, typically limited to variables defined in the same function or in an enclosing function around it. A closure is a genuinely special case: a function that keeps access to variables from the specific scope it was originally created in, even after that surrounding scope has technically finished executing and would normally have discarded those variables entirely.
Scope normally means a variable disappears once its enclosing function finishes
Under ordinary scope rules, a variable defined inside a function only exists for as long as that function is actually running, and once the function returns, its local variables are normally discarded entirely, freeing up the memory they were using and making them permanently inaccessible to any code running afterward. This is exactly the behaviour most programmers expect and rely on: a function's internal working variables are private to that one call and don't linger around cluttering memory once the function's job is done.
A closure is a function that keeps a genuine, working link back to its birth scope
A closure breaks that normal expectation deliberately and usefully: when an inner function is defined inside an outer function and then returned or passed elsewhere to be called later, that inner function retains a genuine, live reference to the specific variables from its outer function's scope, even after the outer function itself has already finished running and would otherwise have discarded them. This lets a closure carry its own private, persistent state around with it wherever it goes, which is exactly why closures are widely used to build things like counters that remember their own running total, or functions configured once with specific settings that stay attached to every later call.
What we're still unsure about
That closures retain genuine, working access to their creation scope's variables even after that scope has finished executing is well established, confirmed language behaviour across the many programming languages that support closures. What's more genuinely a matter of language-design and practical debate is exactly how heavily a codebase should actually rely on closures for managing persistent state versus using more explicit, visible alternatives, since a closure's captured variables aren't always immediately obvious just from reading the code that uses it later, and different programming communities and style guides continue to hold genuinely different views about how much implicit, closure-based state a well-organised codebase should actually carry.
This sits inside Functions, Scope & Closures, one of eight topics in Programming, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.