Resource Discussion
Ian tried commenting here, but it apparently didn't work - that Javascript form may be more trouble than it's worth. Anyway, to the meat of his new post: he says that I missed his point, by assuming that by "resources" all he meant was memory. Based on his original post, that is how I took it. However, he explains further, and lists resources that GC doesn't typically handle: database connections, sockets, (etc, etc).
Here's why I didn't consider that - because all of that is at issue in any web app that maintains some kind of session state on the server. Whether you use continuations or cached data in some other form, you end up dealing with all of that (unless you re-open everything on each submit - which tends to get expensive). Typically, you use the finalization mechanisms of your language/library of choice to deal with that: the session times out, finalization kicks in, and you clean up. I fail to see how continuations make this more (or less) complex.
As to this on the back button amd continuations:
I'm not claiming that it's impossible to handle the back button this way. I'm just saying it's a bad idea, because you need to be able to write code that can tolerate being wound back and forth at the user's whim.
That's precisely the complexity that continuation based servers remove from your purview. In a "standard" we app, you tend to toss some kind of page key around, so that you can tell where you are (as opposed to where your app thinks it is on the server). How that's simpler, I have no idea. Having written a number of web apps in the standard way, I'm not prepared to call it simple.
Comments
Papering over the cracks
[Ian Griffiths] May 26, 2006 5:37:58.000
It's not that continuations make resource management more complex per se. It's that they make mistakes in resource management harder to spot. Code that creates a resource on one page and frees it on the next constitutes a bug for certain kinds of resources. Continuations let the code for multiple pages occupy a single function, which makes it very easy to create a resource on one page and free it on the next without realising it. You'd have to go out of your way to make the same mistake without continuations, so the bug would tend to be a lot more visible.
And regarding arbitrary rewinds...
Continuations don't "remove from your purview" this kind of complexity. They hide it. That's very very different. Hiding complexity without removing it is a bad idea - it's like papering over the cracks.
I believe you're making the same mistake that this sentence makes: "Technologies such as DCOM and RMI remove the complexity inherent in distributed systems by presenting interactions with remote systems through the simple and popular idioms of objects and method invocations." Just as you did, this sentence uses "remove" when it should say "hide". The reality of technologies like DCOM and RMI is that hiding the complexity didn't make it go away. Hiding simply resulted in a lot of people writing a lot of naive code that worked in controlled test environments, but failed as soon as it hit any of the things that make distributed systems completely unlike objects and method invocations.
For a long time I made a good living out of exactly this sort of thing - I've done a lot of work fixing code that failed because the original developer thought things were as simple as they appeared to be. This is why I think that merely hiding complexity is a mistake - if you can't make the complexity going away, hiding it makes things worse.
So while in a controlled test environment, web site interactions might look quite a lot like execution of code, the fact remains that there are lots of ways in which it can be completely unlike that. This application of continuations simply tries to hide that fact. It does not remove it. Hiding complexity without removing it is, in my experience, a recipe for failure.
Hmm. State is State
[ James Robertson] May 26, 2006 7:41:00.681
Comment by James Robertson
Ian:
This is no different than in a "standard" app that tries to manage the back button via state-holding in cookies (hidden fields, etc). You still hold the resources for some indefinite period of time, and release them as appropriate based on state. All continuations do is give you a different way to manage state - they don't change the fundamental rules. I don't buy that continuations hide this complexity anymore than other approaches.
Back in the 90's, we had a web framework (we still do, actually) called VisualWave, that took existing guis and "HTML-ized" them for the web. It handled the back button through state caching, and the problem you worry about was no more - or less - bad.
Also, anyone who thinks an RPC mechanism even hides complexity hasn't worked on one enough. The first time you get a failed message send, you notice how unhidden the problem is.