As to why pg can't use normal pagination instead of user-specific state, I dunno, why not just use Ruby or Python (or PHP!) for the site instead of Arc? Short answer is, I suppose, because he can, and he's likely more interested in satisfying intellectual curiosity than designing a normal pagination system. jm2c.

I suspect that PG's approach is something more than peccadillo. The HN software appears to afford a great deal of power for managing the community, and managing the community is much more important than worrying over expired links. I'll add that I've never seen someone quit HN over expired links, but several over community behavior.

Seeing as YC applications require HN accounts, it is unlikely that YC takes HN's functions lightly.

I can think of one reason:

* A user loads the front page.

* By the time the user clicks "More" at the bottom, page 1, and all subsequent pages, have been updated with new content.

* So the server can't provide the old page 2 to a user who just saw the old page 1, for the reason that neither of the original pages even exists any more.

* To avoid confusing the reader, instead of providing an out-of-sync page 2, the server instead shows a "expired link" message.

Thanks for the reply, I've replied to this answer (above/below/Unknown or Expired Link).

1. HN deals with your interaction by assigning a session index to your initial contact.

2. This index allows HN to keep track of which page of which section you're visiting, so if you click "More" the HN sever knows what do to -- it has a stored context for your request.

3. The HN server has limited resources, so if an index goes unused for more than a few minutes, the server reclaims the index for reuse.

4. If you wait too long before making a server request like clicking "More", it's possible that your index will have been reclaimed and assigned to another user. If this happens, you see the "expired link" message.

5. After your index has expired and been reclaimed, the HN server has no way to interpret your command to proceed -- proceed to where?

6. Also, if you wait long enough, the front page (and all subsidiary pages) will have changed contents, so the pages you're viewing are no longer current, consequently the server can't deliver "page 2" for the simple reason that that version of the page no longer exists.

I understand how it works technically, but I think this illustrates a classic debate between developer and user/customer.

As a developer I can see the functional beauty.

As a user, I think it sucks and I don't give a damn about "session indexes". As a user I just want to see the next page of cool links. I think most people here are 'users'. So why not just have a stateless solution? (aka just linking to ..page=2 as suggested?)

The reverse. :)

> So why not just have a stateless solution? (aka just linking to ..page=2 as suggested?)

You seem to have missed the point that, if you wait long enough to advance to page 2, the page that logically follows from the page you're viewing no longer exists (along with the page you're viewing). In other words, assuming that the HN content changes between your initial view and clicking "More", the new page 2 may contain what page 1 contained, and people will complain that they're looking at the same items on page 2 that they viewed on page 1 just five minutes ago.

[I'm putting my "User" hat on here.]

Lets look at two "user cases" here:

1. I'm on page 2 and I want to look at page 3. I click "More", and I get page 3 but with a few greyed out links I have already seen.

2. I'm on page 2 and I want to look at page 3. I click "More", and I get "Unknown or Expired Link". I firkdanggurbleblast and manually delete the fnid out of the URL and hit enter which takes me back to the first page, then I click on the second page, and then click on the third page, which also contain greyed out links.

Which of the above user cases do you think is preferable?

As I said previously, I'm really just trying to illustrate the difference between technical beauty and what users perceive as beauty.

At the very least, the expired link page should provide a button to reload the page. The reloaded page will contain articles I've already seen, but it beats having to start on page 1 again, after manually editing the URL, and clicking "more" until I find my place again.

Ideally I'd like the site to try to load the index link, and if it's timed out, fallback seamlessly to loading the page by number.

WHy are we debating on 'or' of the option. Expired message or latest page. None of them alone gives satisfactory use experience. Have them both, tell them link has expired and serve them default.