C-style languages tend to have squiggly brackets which can limit scope somewhat, but not as totally as you describe.

For example:

   doThing(){
      x = 7; //x visible in whole function
      {
         y = x*2; //y only visible in this block.
      }
      // x still visible, y no longer visible
   }

Explicitly removing things from scope doesn't seem to be a feature though.

The application i am working on right now has a 766-line setup method written like this. Each block corresponds to the setup of one component. If there is something from that block that needs to be reused (typically, the channels that the component published data to), it is declared immediately above the block.

Many small bits of logic are broken out into their own methods (checking if today is a public holiday, configuring the HTTP server, configuring the KV store client, etc), but the setup of the domain logic components is all in one method.

There's no way to split the setup of the components into methods without either introducing a comparable volume of boilerplate, or having to write some kind of framework to make it easier. Neither would be a win.

A caveat: this codebase uses a language which doesn't have out parameters or multiple-value returns. If it could use those, the boilerplate involved in breaking up the setup method would be considerably smaller. But still probably not worth it.

It does exist, through closures. The syntax in most languages doesn't improve the readability of the code though:

    DoAll() {
      // A
      a1 = ...
      a2 = ...
      a3 = ...

      // B
      b2 = lambda(x,y) {
        b1 = f(x)
        b2 = g(y)
      }(a1,a3);
      
      // C
      lambda(x) {
        c1 = h(x)
      }(b2);
    }

I've added explicit intermediates to better visualize where the scope binding happens, but most languages allow the compiler to bind these variables implicitly whenever an anonymous function references variables from outer scope. That helps with readability, but not with scoping.

But that doubly defeats the purpose.

1. If you have good reasons to restrict variable access in subsections of your long procedure, then it DOES make sense to factor them out as separate functions.

2. Closures automatically close over variables from the surrounding scope (duh), so they don't protect you from accidentally using a variable in a section that you're not supposed to use it in.

The lambda approach avoids "I can't think of what I should call this, I'll call it `foo` for now" problem...

Which isn't a problem we should be avoiding. Naming things in a way that other coders will understand is an important skill, and can be difficult.

How does it avoid that problem?

The lambda doesn't help me understand what that part actually does any more than calling the function "foo_helper" or "foo_partN" or something like that would do.

> Which isn't a problem we should be avoiding

I believe we're actually arguing the same thing.

Anonymous functions aren't the end of the world, but self-documenting code is better.

In the JS/JQuery world, breaking away from anonymous functions would represent such a fundamental shift in practice, I'm not going to do it on my own, but in Angular, I stay away from anonymous functions.