[optymizer]

"code blocks" is why they invented functions and procedures half a century ago (and even those differ only in how they return). I think people forget (or don't know) that these are all labels to jump or branch to. So your named functions, functions, lambdas, code blocks, etc, become.. well.. equivalent. Hipsters, don't confuse the young ones with your 30 ways of jumping into a block of code. Cheers!

[stcredzero]

Not the whole story. Code blocks can be used to protect encapsulation and create DSLs which are first class citizens of their host language.

So your named functions, functions, lambdas, code blocks, etc, become.. well.. equivalent.

They can also become so lexically awkward as to be unusable. For example, one code a toy "fuzzy logic" system in Smalltalk with a handful of methods. The result looks like a 1st class member of the language, just like the control structures that are already there. (Same goes for the loops)

    "Here is the standard if-else"
    (condition)
        ifTrue: [ ... ]
        ifFalse: [ ... ]

    "Here is what my DSL can look like"
    (condition)
        ifTrue: [ ... ]
        ifFalse: [ ... ]
        ifMaybe: [ ... ]

Doing this with named functions is going to scatter code between different functions. It's semantically equivalent, but harder to read. Write anything involved in such a way, and it becomes untenable. Blocks can make such DSLs an order of magnitude more readable.

Hipsters, don't confuse the young ones with your 30 ways of jumping into a block of code. Cheers!

A good heaping fraction of hipsters don't understand what's good about code blocks.

[optymizer]

"Code blocks can be used to protect encapsulation". So can functions, which are already in the language.

"Doing this with named functions is going to scatter code between different functions". Please show an example.

"A good heaping fraction of hipsters don't understand what's good about code blocks." That's one way of phrasing it.