I have to say: This is a good thing, to a certain extend. Take Python, and consider Python's metaclasses (basically classes of classes (of objects)). Certainly, they allow you to do some things easier, but now imagine some Three-star-programmer abuses those metaclasses to subvert the class creation mechanism in nontrivial ways and bases the entire application on these metaclasses (and, of course, does not document this well). If you are supposed to maintain this, you are in trouble.

So, my point is: It certainly is fun to have a very dynamic language which can do a lot of things easily, but this is a great power and requires great responsibility and the larger the project will be, the more responsibility is required, and -- being a careful person -- I don't want to assume that everyone touching that gigantic project is responsible and careful enough to handle this well. Thus, I like dynamic languages for my own small projects, but I can understand why those dynamic languages are not mainstream.

The problem is that it is often not possible. The team lead in charge of actual implementation often has limited control over who is on the team.

Even when the team leads have the luxury of chosing their own people, getting the type of people that understand capabilities like that and both can and will document them and refrain from abusing them are hard to find and expensive. Worse, if you need to hire from the outside, it can be very hard to know during a relatively short interview process if you have found such a person.

If the lead manages to get such a team together and finish the project, it still needs to be maintained, enhanced, and extended. Gaurunteeing that your entire string of maintainers will be at least good enough to understand not break this beautifully constructed project can be very hard indeed, even if you managed to carefully create documentation at every step and keep the documentation in synch.

In short, while a great idea in theory (and sometimes in practice) it may be nigh impossible in practice, especially for a mid sized or larger company.

Speaking on Python's behalf for a moment, don't confuse inability with unwillingness.

http://pastebin.com/m7cc84252

edit: Can you give examples? How do you roll back side effects in your solutions?

But even if you could rely on world destruction, do you really want to deal with situation where 2 worlds have to roll back 2 different remote resource modification? Can you do it reliably? If you need to write more than 1 line to do it, how is it different from old-style "except ....: ..."?

    try:
        remote_resource.start_transaction()
        #dostuff
        remote_resource.commit()
    except e:
        remote_resource.rollback()

What I normally do is: operate on temporaries (or copied parameters), change remote resource (it's safe to just rollback resource changes and exit here in case of problems), then change "the state" when operations cannot fail any more. Is there any real-live problem that needs local variables rollback? (that is shorter / nicer than returning the result from temporary locals) I'd really like to see it.

It's a heavily researched topic right now. The Worlds concept, as far as I can tell, is actually more general than STM and what you described. In STM, there's the global state everyone can see, and then there's local states that try to commit atomically to the global state. With Worlds, I don't think there's one true global state. I think it would give you more explicit control, which I'm not convinced would be a good thing.

Where in my comment did I describe Worlds in a limited way? I just gave one small example of one possible application of them, in reply to a comment specifically about their relationship to transactions.