Amen! Java and C# are too "stiff" to handle many kinds of changes/expansions that say Smalltalk or Lisp would have no problem with. Lambda's and "annotations" a

Amen! Java and C# are too "stiff" to handle many kinds of changes/expansions that say Smalltalk or Lisp would have no problem with. Lambda's and "annotations" are doing many things that objects should be doing so that special additions or inconsistent parts are not needed to plug the holes. Make blocks of code just be blocks; and how they relate to other blocks be a library or code configuration instead of a block "type" or language construct because types don't handle combinations of traits very well: they like clean hierarchies to work well. But hierarchies are limiting. It's why RDBMS replaced IMS, for example. The same lessons apply to code blocks: hierarchies are too stiff for non-trivial change management. The scope profile/ranges and "parent pointers" of each block should either be dynamic or configurable just before compiling[1]: "This block has traits X, Y, Z, etc.". A buffet instead of numbered dishes. The boundaries between "object", "class", "lambda", "function", "annotation", etc. should be blurred and mixable. Don't force hierarchical or stiff taxonomies unless you really have to. We've outgrown trees just as we outgrew IMS. Block "types" are an archaic concept that the future will laugh at like they do to go-to oriented code now. (I'm currently experimenting with a "meta-language" that has TypeScript-like syntax but lets the libraries define how blocks behave instead of the language itself. You can make your own control structures and block types any way you want via just library changes...if things go to plan. Some say, "why not just use Lisp?", but too many find Lisp hard to read. This meta language thus borrows syntactical elements from the C family. Parameter blocks are visually different from code blocks, for example, giving the eyes more cues.) [1] Or both. Perhaps have "locked" blocks and unlocked blocks that can change their scope/parent configuration during run-time if given permission to do so. But that's Phase II. Phase I should keep it simple until the idea gets road experience in compiled languages.