Python Worlds | Hacker News Reader

Python Worlds

sigusr2.net

35 pointsandreyf17 comments

Hm, so he complains about the impossibility of 'bending a mainstream language to ones will', as in: to make it use a certain feature implicitly, like his transaction system.

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.

There's no doubt that abuse can happen in a model that allows openness. But, if you're worried about your inferior programmers abusing features of the language, that's a management problem. Do code reviews and hire people that aren't going to abuse the features, but instead use them for enhancement.

You are completely right, when this is possible.

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.

And thus was created Java, which deliberately breaks your wrists the first time you use it, just in case you were planning to write bad code.

"We are in an age of programming where mainstream programming languages are unable to adapt to our needs as programmers."

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

My solution is a little bit more hackish, but more usable imo. Not thoroughly tested though, might have some implications I haven't thought of.

http://pastebin.com/m7cc84252

Dumping the current state with deepcopy is probably prohibitively expensive for real world use. Toss in some copy-on-write, and I think you've got something simple and usable...

much more usable than my example, but the copy on write is tricky, which I alluded too. In the case of objects, you need the entire object in order to act upon it, which means you have to copy the whole thing. Of course, if this was an actual language feature, it could be done with some sort of tracing probably, which would make it more efficient. Not sure how you could do that from user code...

I heard a talk from someone who was selling a linux app that completely saved program state so that you could restart from that point at any time. Last time I checked, gdb has some basic abilities in that respect.

For every situation I can conceive of offhand where this "worlds" abstraction could be useful, I can immediately think of a simpler way to achieve the same results. Perhaps I'm being naive?

Perhaps you're thinking in blub?

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

Exception catching. Worlds only handle your local memory (and remote resources via destructors if you can use them).

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 ....: ..."?

You're missing the point. Here's the basic transaction paradigm for remote resources:

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

How do you do the same thing when modifying a local variable? You might try making a copy, modifying that, and then assigning back, but that's boilerplate, and it's easy to get wrong. Worlds are a more primitive mechanism that would be baked into a language, such that building a generic transaction api for local actions on top of worlds would be trivial. The fact that it could look exactly like the transaction api that you currently know and love for remote resources is a feature.

Ok... maybe it's because I like to program the functional way (in imperative languages), but I've never found a reason to rollback local variable changes. That's because local variables don't "fail" and don't need to be rolled back. I see why it's a nice solution but I've never really seen the problem.

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.

http://en.wikipedia.org/wiki/Software_transactional_memory

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.

The Worlds concept, as far as I can tell, is actually more general than STM and what you described

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.

I got the impression you didn't see it as more general than that. And I think it's worth noting that STM is a solution the problem you presented.

Reply on news.ycombinator.com