I think you're spot on. I just wanted to share a little trick, with regards to:
Second, improving back button behavior is a matter of
setting all the right nocache attributes. If you use forms,
you're likely to have trouble with back navigation no matter
what you do ("The page contains expired POST data").
The key is to use a 302 redirect immediately after a successful post rather than a 200. This makes using the back button take you back to the form, rather than trying to POST it again.
On the other hand, I find the ability to resubmit forms with the back button very useful at times, so I'm not sure this is always the right thing to do. But it's a neat trick.
One thing I've noticed about languages: you can't really tell which is better from such a short sample.
Paul calls Prolog pattern matching great for writing basic list manipulation functions, then downhill from there. But if you're looking at those kinds of toy problems (how do you write reduce?) you get a biased sample.
Really, you have to try writing something representative of your problem space. And that code snippet is not at all representative of my experience writing web applications; it lacks:
* Persistent storage
* Large pages with multiple possible forms and actions
* Javascript
* Caching
* Complicated queries
* Pagination
In fact, what the demo code amounts to is a 2 step wizard. And in all of Justin.tv, we only have two wizards. So I don't think this is a good test for length of a web app.
One extremely important question: What would be? Is there some kind of canonical example application that could be designed?
Typically, you'd never write the program that way in Ruby. All the popular ruby web frameworks are not continuation or closure based. Instead, you'd keep the state in memory on the server, tied to the session. You'd also use three templates, one per page. In Rails:
def said
if request.method == :post
session[:said] = params[:said]
render :action => "clickhere"
else
render :action => "result" if session[:said]
end
end
default template said.rhtml:
<% form_tag do %><%= text_field_tag "said", "" %><%= submit_tag %><% end %>
clickhere.rhtml:
<%= link_to "click here", "" %>
result.rhtml:
You said <%= session[:said] %>
But now that you mention it, ruby has callcc...let me see what that implies...
Neat, thanks. (Not quite "right" since I can change &foo=myinput on page 2, but I'm guessing that could easily be fixed with an extra closure somewhere).
And in 3.0, Python is adding a bytes type, so b"foo"[0]==102
Obviously both ways are useful. If I had to guess what Arc ends up doing, I'd guess : whatever leads to the programmer having to type less tokens, or whatever facilitates clever macro definitions, leading to same.
I would suggest that marking a literal vector of bytes is not the most useful role double quotes could play. Python has a lot of history of using that, due to exactly this kind of confusion of strings and vectors of bytes, leading to b"", u"", etc.