[unconed]

The part that confuses me is that 'this has been discussed before' is considered a valid answer, as opposed to say 'yes it's horribly broken and no-one is willing to fix it'. The site routinely fails to return results for links it generated just minutes before. How that is not considered a bug, on a site that represents forward thinking web development, mystifies me.

[jadc]

Here's pg's explanation (from http://news.ycombinator.com/item?id=3098756) 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 hard-coded urls. Lately traffic has grown rapidly (it usually does in the fall) and I've been working on other things (mostly banning crawlers that don't respect robots.txt), so the rate of expired links has become more conspicuous. I'll add a few more hard-coded urls and that will get it down again.

[statictype]

a) This isn't really a site representing forward thinking web-dev. If anything, some of the more valuable bits I've picked up here point at your web dev stack being less important to the success of your company than many other factors.

b) Someone would argue that using closures to represent page links is clever and forward thinking, even if the current implementation is broken.

But, yes, it is annoying and wish it could be fixed.

[kennu]

I think storing state on servers is always a bad idea. State should be stored in a cookie in the user's browser, letting him decide when it expires.

[dchest]

I gave a valid answer to the question in the title: "Why does HN generate unique URL's for the 'more' pages?" I agree that it's broken.