3 ms·

"All the value judgments" you accuse me of apparently means a single word, "overeducated", which I used as a tongue-in-cheek synonym for "perhaps a little too s

by SiVal 12y ago

"All the value judgments" you accuse me of apparently means a single word, "overeducated", which I used as a tongue-in-cheek synonym for "perhaps a little too sophisticated for their own good in this case". I think you're being a little oversensitive about it, but just in case, let me formally (and literally, not sarcastically) express my gratitude to the makers of HN for creating a website of great value to me. Now, having said that, this is a website where the discussion of the pitfalls of one dev approach vs another is why we're here, and I was seriously suggesting that this might have been a case where the naive approach of a "less-educated" developer might have worked even better. I wasn't claiming to be a less-educated developer myself (ahem). ;-) As I said, I could easily be overlooking something, and I won't be building my own Hacker News in outrage over the issue, but it still seems to me that just letting me have more items at a time on each page would solve the problem well enough (for me) with no need for anything fancier.

brudgers 12y ago
What may be overlooked is that continuations are a useful way of storing state when using a stateless protocol such as HTTP or when dealing with asynchronous communications in general. They are useful because they are lightweight. There's no serialization/deserialization, no read/write from persistent storage, no additional tiers, no additional layers. It's a simple mechanism that's provided directly by the programming language in which the application is written. Out of curiosity, what problem do you experience due to the 30 item constant?
- andreasvc 12y ago
  It's not the continuations which are the problem, it's relying on state at all. As the submission describes, storing the state used too much RAM and required pruning. The solution was to reformulate the problem so as not to require state, if possible.
  - brudgers 12y ago
    I don't claim expertise, but my understanding is that it is considered difficult to compute without states because the critical question is, "What is the next state?" Continuations are a way of answering that question asynchronously in regard to the timing of the invocation of the transition function from the current state to the next state. The cost/benefit is the absence of shared global state. My continuation is different from your continuation. The alternative is to determine the next state synchronously with the invocation of the transition function for the next state by reading a shared state. If I invoke the transition function at time t1 I will get the same result as you would get if you invoked the transition function at t1...assuming of course that we did not both invoke it at the same time [then it's just a matter of convention as to who gets what].

by SiVal 12y ago

brudgers 12y ago

What may be overlooked is that continuations are a useful way of storing state when using a stateless protocol such as HTTP or when dealing with asynchronous communications in general. They are useful because they are lightweight. There's no serialization/deserialization, no read/write from persistent storage, no additional tiers, no additional layers. It's a simple mechanism that's provided directly by the programming language in which the application is written. Out of curiosity, what problem do you experience due to the 30 item constant?

andreasvc 12y ago
It's not the continuations which are the problem, it's relying on state at all. As the submission describes, storing the state used too much RAM and required pruning. The solution was to reformulate the problem so as not to require state, if possible.
- brudgers 12y ago
  I don't claim expertise, but my understanding is that it is considered difficult to compute without states because the critical question is, "What is the next state?" Continuations are a way of answering that question asynchronously in regard to the timing of the invocation of the transition function from the current state to the next state. The cost/benefit is the absence of shared global state. My continuation is different from your continuation. The alternative is to determine the next state synchronously with the invocation of the transition function for the next state by reading a shared state. If I invoke the transition function at time t1 I will get the same result as you would get if you invoked the transition function at t1...assuming of course that we did not both invoke it at the same time [then it's just a matter of convention as to who gets what].