Live data from Hacker News

Why does HN generate unique URL's for the 'more' pages?

news.ycombinator.com

11–20 of 44 posts

Re: Why does HN generate unique URL's for the 'more' pages?

#11
dchest answered more of the 'what' than why

the answer to the why is news.arc (what this site runs) is the pet example of Arc, which is pg's lisp dialect focused on making lisp web apps with continuation passing style

as such, the technical purity to the idea is more important than UX, as otherwise it would mean admitting that trying to implement pretty simple web app that passes around continuations like this is a fool's errand

(actually, arc and the ideas work great for rapid prototyping but just do not work well once you reach more than all but the smallest of scales)

Re: Why does HN generate unique URL's for the 'more' pages?

#12
It's called a continuation. Continuations are essentially closures being passed around to represent state (hence "fnid"), check the Wikipedia page on them for a proper, computer sciencey definition. The nature of Lisp really lends itself to continuation-based programming. Sometimes (like on HN) it's used in web applications. In the context of web applications, it's a different approach than, for example, REST/MVC. It has a few nice properties, such as easy state management. This can be very useful when a web application is an interface to a process (e.g. checkout in a web store) as opposed to CRUDA. On HN, it allows paging that "remembers" the order of things at the time you visited the first page. Reddit uses a similar mechanism. The obvious downside is that you have to keep track of all those states and if you lose them (for example because they expire), the user workflow is interrupted (hence the error message).

It's not the trendiest programming technique around these days but it's a useful tool in the toolkit of a good developer.

Re: Why does HN generate unique URL's for the 'more' pages?

#14
post #7
post #6

Earlier quoted context omitted.

Arc server stores closures on server (see the patent for the similar technique). Links include unique ids of these closures. Closures expire. This has been explained numerous times here on HN, see the search link in my different comment.

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.

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.

Re: Why does HN generate unique URL's for the 'more' pages?

#15
post #7
post #6

Earlier quoted context omitted.

Arc server stores closures on server (see the patent for the similar technique). Links include unique ids of these closures. Closures expire. This has been explained numerous times here on HN, see the search link in my different comment.

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.

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.

Re: Why does HN generate unique URL's for the 'more' pages?

#16

It's called a continuation. Continuations are essentially closures being passed around to represent state (hence "fnid"), check the Wikipedia page on them for a proper, computer sciencey definition. The nature of Lisp really lends itself to continuation-based programming. Sometimes (like on HN) it's used in web applications. In the context of web applications, it's a different approach than, for example, REST/MVC. It…

"The nature of Lisp really lends itself to continuation-based programming."

This comes up occasionally on HN. I've never seen anyone say anything positive about it.

It seems like a software detail that's unnecessary exposed to users. It doesn't make the site better, it makes it worse.

Re: Why does HN generate unique URL's for the 'more' pages?

#17
post #3
post #2

See this patent: http://www.freepatentsonline.com/6205469.html Also: http://www.hnsearch.com/search#request/all&q=expired+lin...

or, for a slightly less advertising-ridden interface, http://www.google.com/patents/US6205469

irony defined

Re: Why does HN generate unique URL's for the 'more' pages?

#18
I've read the bits about implementation based on continuations in various other comments.

Given that:

- the ranking of HN stories likely is in constant flux ...

- and that some users might want a consistent view of stories across multiple pages ...

- and that having .../page1-, .../page2-, .../page3-style URLs might result in some user seeing the same story presented twice in their browsing, once on page1 and then again on page2 as its rank changes ... or worse, missing a story that got promoted to page1 from page2 during a session

... do the continuations as implemented on HN present a static view of the ranked stories with a non-changing ordering (as long as links don't expire)? To do this with straight URL's one would need to present different URL links at different times to different users to get different page-2 contents reflecting what was on page2 at the time they started their HN visit. If so, that would be a feature.

Re: Why does HN generate unique URL's for the 'more' pages?

#19

It's called a continuation. Continuations are essentially closures being passed around to represent state (hence "fnid"), check the Wikipedia page on them for a proper, computer sciencey definition. The nature of Lisp really lends itself to continuation-based programming. Sometimes (like on HN) it's used in web applications. In the context of web applications, it's a different approach than, for example, REST/MVC. It…

"The nature of Lisp really lends itself to continuation-based programming." This comes up occasionally on HN. I've never seen anyone say anything positive about it. It seems like a software detail that's unnecessary exposed to users. It doesn't make the site better, it makes it worse.

I completely agree, but I wouldn't mind it nearly so much if the "expired link" page at the very least had a link to the home page.

Re: Why does HN generate unique URL's for the 'more' pages?

#20

It's called a continuation. Continuations are essentially closures being passed around to represent state (hence "fnid"), check the Wikipedia page on them for a proper, computer sciencey definition. The nature of Lisp really lends itself to continuation-based programming. Sometimes (like on HN) it's used in web applications. In the context of web applications, it's a different approach than, for example, REST/MVC. It…

Reddit does not use a similar mechanism. Here's an example of one of their next page links: http://www.reddit.com/?count=100&after=t3_q1sxk

The count is the number of stories to skip, the after is the id of the last story on the previous page.

Post reply on HN