21–27 of 27 posts
Earlier quoted context omitted.
If it was a purely functional interaction, shouldn't the same request always get the same response? Yes. This is why things like Rail's "flash" breaks the Internet... or at least your web app.
Well, each time I go to twitter.com I hope to see something slightly different than last time and that's not part of the internet being broken.
Earlier quoted context omitted.
Indeed. The language of implementation does not matter much, what matters is what sort of data structure you use. When you can just read a piece of text from a database, it makes little sense to create an opaque state-carrying object dependent on the memory space of one process. news.arc is about as far from "functional programming" as you can get. People often use Darcs as an example of why functional programming is…
You know what would knock the planet's socks flat on their asses? If the Haskell and Erlang people got together. I definitely fall on the Erlang side, but (especially if you shrug off the fanatic outliers) the differences are actually quite minor.
Anyone find this comment (in a suggested answer) strange: >Yahoo! Store was written by Paul Graham, who is a big Lisp advocate. He also wrote Hacker News, which is, effectively, a Reddit clone.
That being said, saying that different applications by same programmer doesn't count(as the SO comment implies) is ridiculous.
There are various interesting things in the various functional worlds in the very early phases of being interesting, but unless you are the sort of web programmer who routinely just programs up their own frameworks I couldn't really recommend any of them right now if you're not already a pretty good functional programmer and you're actively interested in participating in such early experiments. Possible exceptions wo…
"Possible exceptions would include Seaside, which I've never used but has been around for a while and from what I can see has a genuinely different approach to web development that actually does exploit Scheme." Unless we are talking 'bout a different framework, Seaside is Smalltalk.
Earlier quoted context omitted.
If it was a purely functional interaction, shouldn't the same request always get the same response? Yes. This is why things like Rail's "flash" breaks the Internet... or at least your web app.
Each request should get the same "logical" response. There is nothing wrong with the content varying with each request. A resource that represents "The last 10 items processed" will always contain just that, even if the response is different at the html level. This is why cache-invalidation is important. A resource can also be composed of parts of other resources. For instance, you can have an order resource which is…
Consider: user submits form that loads slowly, application sets flash and slowly begins sending response. User gets bored and visits yoursite.com. Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops.
State breaks the internet.
Earlier quoted context omitted.
Well, each time I go to twitter.com I hope to see something slightly different than last time and that's not part of the internet being broken.
Yes, but each time you go, the input data (like the microsecond since 1970) is different.
If you use git, it's like the HEAD reference. It's a pointer to the immutable commit. The reference itself is mutable.
Earlier quoted context omitted.
Each request should get the same "logical" response. There is nothing wrong with the content varying with each request. A resource that represents "The last 10 items processed" will always contain just that, even if the response is different at the html level. This is why cache-invalidation is important. A resource can also be composed of parts of other resources. For instance, you can have an order resource which is…
I don't think it breaks the internet at all. Consider: user submits form that loads slowly, application sets flash and slowly begins sending response. User gets bored and visits yoursite.com. Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops. State breaks the internet.
Doesn't really seem like an oops to me.
State breaks the internet.
You submitted a form. That presumably changed the state of the resources at that url too.
The page should set the flash state when the state transition is done, not when it starts. It shouldn't matter if the user sees the message on the page after the form or from a different page altogether. What if every page had a history of all of the flash messages ever produced? You wouldn't call that "state" any more or less than the state of the objects you were trying to change in the form itself.
I think the part of this you actually don't like is that the following GET implicitly deletes the state (which is why we can optimize and store it in session rather than the db). But when the state is "messages unseen by the user" then it seems reasonable to me.
I think we can agree that any state where it matters what page they view the message on is probably not a good candidate for flash. I'm not even a rails programmer but I think there are better examples for the state-is-bad idea.