51–60 of 142 posts
Earlier quoted context omitted.
Hacker News is open source, so it seems as if nobody is interested in fixing it. Or are there fixes and pg has rejected them?
Or it's so ingrained in the architecture of the software that a fix isn't possible without completely rewriting it and changing the entire design philosophy.
I'm getting this error when using the login link right now! EDIT: The only way I was able to login was to use the 'add comment' button on this post.
It also reliably happens clicking the "next page" link on the bottom of the front page; by the time I'm done reading the front page the next page link usually expires.
Please fix?
You get that when your session expires, which takes just slightly less time than writing a well thought out comment.
PG is using a really cool programming technique that I'm afraid is ahead of its time relative to current hardware. An upgrade to the HN server should allay the problem. To see the potential, look at this code snippet from an academic paper on the topic. The web server presents a form asking for a number, then presents a form asking for another number, then displays their product. This technique makes event-driven web…
It's not so much that it's ahead of its time relative to hardware as it is something you do in the early versions of a program. Using closures to store state on the server is a rapid prototyping technique, like using lists as data structures. It's elegant but inefficient. In the initial version of HN I used closures for practically all links. As traffic has increased over the years, I've gradually replaced them with…
You should hard-code that one too.
PG is using a really cool programming technique that I'm afraid is ahead of its time relative to current hardware. An upgrade to the HN server should allay the problem. To see the potential, look at this code snippet from an academic paper on the topic. The web server presents a form asking for a number, then presents a form asking for another number, then displays their product. This technique makes event-driven web…
It's not so much that it's ahead of its time relative to hardware as it is something you do in the early versions of a program. Using closures to store state on the server is a rapid prototyping technique, like using lists as data structures. It's elegant but inefficient. In the initial version of HN I used closures for practically all links. As traffic has increased over the years, I've gradually replaced them with…
Earlier quoted context omitted.
It's not so much that it's ahead of its time relative to hardware as it is something you do in the early versions of a program. Using closures to store state on the server is a rapid prototyping technique, like using lists as data structures. It's elegant but inefficient. In the initial version of HN I used closures for practically all links. As traffic has increased over the years, I've gradually replaced them with…
Out of curiosity, are there any places where the hn codebase would be smaller if you used full continuations instead of just closures, allowing code akin to what I quoted from the PLT paper?
Good question, but in my opinion it's somewhat rhetorical. Given bugs like these, the ongoing optimization battle, and fairly reasonable feature requests (see the huge HN topic on that), isn't it about time Paul Graham hired someone full or part time to work all these issues out? Given how important HN is to YC, I would think it's worth it. Are any of these tasks really things pg has to do or are the best use of his…
Earlier quoted context omitted.
It'd work robustly enough if the links didn't expire, and if we believe other posts on this page, the links are expiring due to memory limits on the system. (The other possibility is a timeout, I guess, which is easily fixed.) If it's running out of memory to store the closures it would run out of memory to store the interaction state. In other words, there's a problem here, but it's not the programming model that pg…
> If it's running out of memory to store the closures it would run out of memory to store the interaction state. Not necessarily. The way I would approach this is to keep the link cache in memory, but have the links contain the minimal necessary state to reconstruct the link from disk-based storage in the case where the cache is gone. That gives the same excellent median performance without any breakage.
It's not a cache, and you clearly don't understand the issue. These are callbacks to closures, embedding the state in the URL is what they attempt to avoid because doing that is tedious.
Earlier quoted context omitted.
It'd work robustly enough if the links didn't expire, and if we believe other posts on this page, the links are expiring due to memory limits on the system. (The other possibility is a timeout, I guess, which is easily fixed.) If it's running out of memory to store the closures it would run out of memory to store the interaction state. In other words, there's a problem here, but it's not the programming model that pg…
Except the links do expire, so its not robust. I expect that when I visit a web page, I can let it sit for an extended period of time before moving on to the next page and have it work. HN doesn't work. Furthermore, the technique of holding important state authoritatively in memory like this is not a good web-development practice for various reasons. Doubly so if its state data which can be round-tripped. Links shoul…