4 ms·

I don’t mean to be rude, but is HN a refutation of the Lispy vision it was meant to demonstrate? There has been a bug where comment pages can only show a limite

by sfeng 5y ago

I don’t mean to be rude, but is HN a refutation of the Lispy vision it was meant to demonstrate? There has been a bug where comment pages can only show a limited number of entries for years, and the wonderful mods like dang continually report it is being worked on. It’s hard for me to believe it wouldn’t be fixed much faster if it occurred in a more practical language.

Waterluvian 5y ago
What's the bug? Isn't there a "more..." At the bottom of those long comment pages?
- tzs 5y ago
  I wouldn't necessarily call it a bug, but the way the pagination works does not work well for active threads which is probably why they want to replace it at some point with code than can handle long threads on a single page. A problem with pagination as implemented on HN is that the algorithm to display page N seems to be functionally (no pun intended!) equivalent to this: Render all the comments as one long virtual page Split it into smaller pages Render the Nth page from that set of smaller pages Note! I'm not saying that is how it works. Just that it produces the same result as that. So you read page 1 of an active discussion. You get to the end of the page and hit "more". But while you were reading page 1, other people were commenting, and other people were voting. Now, when it goes to render page 2 for you other comments have moved to the top, pushing the stuff you already read on page 1 down to page 2. Or maybe what was just after page 1 when you were reading page 1 has moved up due to voting, and when you go to page 2 you end up past it. It's like if you had a book that went through several editions, with significant changes between editions (including rearranging the order of chapters), and someone put together a printing by taking the first 10 pages from the first edition, the second 10 pages from the second edition, and so on. This could be fixed while retaining pagination by saving a timestamp when you go to page 1, and then when you go to subsequent pages use a snapshot of the comment database from that timestamp instead of the current comments. If you want to update to the current comments you'd have to hit refresh or go back to page 1. Another approach while retaining pagination would be keep track of what top level comments you've seen. If when rendering page N it sees that due to comment order changes one of the comments that is going to end on the page is one you've already seen it could omit it. Or maybe omit it unless the tree starting at that comment has changed since you last saw it. (If going this route, I'd also suggesting adding something to the UI to highlight what has changed in the tree and/or dehighlight what you've already seen). That second approach could still be annoying. You could still get stuck on a single comment that is getting a lot of relies. That could be fixed, but then you are getting into probably needing to add new controls or settings. I'm sure they have thought of both of those approaches and more, but probably want to keep the interface clean and simple and retain minimal state, hence the plan to someday make it handle very long comment threads on a single page.
  - jobigoud 5y ago
    > Now, when it goes to render page 2 for you other comments have moved to the top, pushing the stuff you already read on page 1 down to page 2. Reddit pagination works the same way. When you click the next page link the order may have moved things around and you might see entries you have already seen.
    - ravel-bar-foo 5y ago
      I believe Reddit pagination only updates once every half hour... or at least that's what I heard about /all. Perhaps HN has more continuous updates resulting in more problems (the main page certainly feels more dynamic on HN.)
Zababa 5y ago
On the other hand, I see spam and flamewars very rarely, and I know they have protection in place against it. I'd take that over seeing all the comments in one page.
Wowfunhappy 5y ago
> There has been a bug where comment pages can only show a limited number of entries for years, and the wonderful mods like dang continually report it is being worked on. It's not a bug per se, it's a concession to conserve server resources, which will be removed once some optimization work has been completed. You might respond "well why is HN so resource-hungry?" Answer: it's not! HN is run off a single core of a single CPU. https://news.ycombinator.com/item?id=23187455 https://news.ycombinator.com/item?id=23187455 > The software for both HN and YC was just a single Arc program (and not a large one) for the first 9 years of their existence, during which they went from nothing to massively successful to industry-changing. Written by one person, programming part-time. That is a staggering achievement. The power of using the right language for your project goes far further than most people dream. Our imagination about this is crippled by path dependence, social proof, and the conditioning that comes from only ever doing things the same few ways, like those fish in experiments (which may be urban legends?) who stick to their corner of the aquarium even after a glass barrier has been removed. The solution space of software and programming is so much larger than most of us want to imagine that it is. Sad.
- bastawhiz 5y ago
  A post from a week or two ago about APL and cellular automata (I cannot find it) perhaps illustrated OP's sentiment better: it's easy for a language to do something easily and elegantly, but quickly become fantastically difficult to accomplish with the introduction of new—and sometimes mundane—constraints. The post showed how it was trivial to implement certain cellular automata in APL, but massively difficult to do when the automata became slightly more complex (while being trivial to update a Java implementation to accommodate the new complexity). The practical difference between running on one server with one core and five servers with four cores is nothing—to YC it's a rounding error either way. If there's a meaningful problem (e.g., comments being computationally expensive to paginate well) that the language/runtime/system/etc cannot solve easily enough for it to be remedied in O(months), it does call into question whether the choice of language is the right one. Yes, it can be patched over by a human moderator. But it still highlights a significant weakness in the technology's core function. Perhaps ironically, most YC companies (and by consequence, YC) would fail miserably if they chose purism and principle over pragmatism when it came to technology decisions.
erik_seaberg 5y ago
With Arc and HN and now Bel, I think pg is still exploring what a system could look like without major compromises to accommodate the limits of today’s hardware. For example, the first cut at pagination put something like a continuation ID into a URL, which only worked until that continuation was GC’d or the one and only server process got bounced. If you wanted a highly scalable HN and nothing more, you’d let Postgres or some graph database do the heavy lifting, add a Racket or Clojure frontend, and call it a day. But that’s pretty boring plumbing work, and doesn’t get you closer to the hundred-year language he’s aiming for.

by sfeng 5y ago

Waterluvian 5y ago

What's the bug? Isn't there a "more..." At the bottom of those long comment pages?

tzs 5y ago
I wouldn't necessarily call it a bug, but the way the pagination works does not work well for active threads which is probably why they want to replace it at some point with code than can handle long threads on a single page. A problem with pagination as implemented on HN is that the algorithm to display page N seems to be functionally (no pun intended!) equivalent to this: Render all the comments as one long virtual page Split it into smaller pages Render the Nth page from that set of smaller pages Note! I'm not saying that is how it works. Just that it produces the same result as that. So you read page 1 of an active discussion. You get to the end of the page and hit "more". But while you were reading page 1, other people were commenting, and other people were voting. Now, when it goes to render page 2 for you other comments have moved to the top, pushing the stuff you already read on page 1 down to page 2. Or maybe what was just after page 1 when you were reading page 1 has moved up due to voting, and when you go to page 2 you end up past it. It's like if you had a book that went through several editions, with significant changes between editions (including rearranging the order of chapters), and someone put together a printing by taking the first 10 pages from the first edition, the second 10 pages from the second edition, and so on. This could be fixed while retaining pagination by saving a timestamp when you go to page 1, and then when you go to subsequent pages use a snapshot of the comment database from that timestamp instead of the current comments. If you want to update to the current comments you'd have to hit refresh or go back to page 1. Another approach while retaining pagination would be keep track of what top level comments you've seen. If when rendering page N it sees that due to comment order changes one of the comments that is going to end on the page is one you've already seen it could omit it. Or maybe omit it unless the tree starting at that comment has changed since you last saw it. (If going this route, I'd also suggesting adding something to the UI to highlight what has changed in the tree and/or dehighlight what you've already seen). That second approach could still be annoying. You could still get stuck on a single comment that is getting a lot of relies. That could be fixed, but then you are getting into probably needing to add new controls or settings. I'm sure they have thought of both of those approaches and more, but probably want to keep the interface clean and simple and retain minimal state, hence the plan to someday make it handle very long comment threads on a single page.
- jobigoud 5y ago
  > Now, when it goes to render page 2 for you other comments have moved to the top, pushing the stuff you already read on page 1 down to page 2. Reddit pagination works the same way. When you click the next page link the order may have moved things around and you might see entries you have already seen.
  - ravel-bar-foo 5y ago
    I believe Reddit pagination only updates once every half hour... or at least that's what I heard about /all. Perhaps HN has more continuous updates resulting in more problems (the main page certainly feels more dynamic on HN.)

Zababa 5y ago

On the other hand, I see spam and flamewars very rarely, and I know they have protection in place against it. I'd take that over seeing all the comments in one page.

Wowfunhappy 5y ago

> There has been a bug where comment pages can only show a limited number of entries for years, and the wonderful mods like dang continually report it is being worked on. It's not a bug per se, it's a concession to conserve server resources, which will be removed once some optimization work has been completed. You might respond "well why is HN so resource-hungry?" Answer: it's not! HN is run off a single core of a single CPU. https://news.ycombinator.com/item?id=23187455 https://news.ycombinator.com/item?id=23187455 > The software for both HN and YC was just a single Arc program (and not a large one) for the first 9 years of their existence, during which they went from nothing to massively successful to industry-changing. Written by one person, programming part-time. That is a staggering achievement. The power of using the right language for your project goes far further than most people dream. Our imagination about this is crippled by path dependence, social proof, and the conditioning that comes from only ever doing things the same few ways, like those fish in experiments (which may be urban legends?) who stick to their corner of the aquarium even after a glass barrier has been removed. The solution space of software and programming is so much larger than most of us want to imagine that it is. Sad.

bastawhiz 5y ago
A post from a week or two ago about APL and cellular automata (I cannot find it) perhaps illustrated OP's sentiment better: it's easy for a language to do something easily and elegantly, but quickly become fantastically difficult to accomplish with the introduction of new—and sometimes mundane—constraints. The post showed how it was trivial to implement certain cellular automata in APL, but massively difficult to do when the automata became slightly more complex (while being trivial to update a Java implementation to accommodate the new complexity). The practical difference between running on one server with one core and five servers with four cores is nothing—to YC it's a rounding error either way. If there's a meaningful problem (e.g., comments being computationally expensive to paginate well) that the language/runtime/system/etc cannot solve easily enough for it to be remedied in O(months), it does call into question whether the choice of language is the right one. Yes, it can be patched over by a human moderator. But it still highlights a significant weakness in the technology's core function. Perhaps ironically, most YC companies (and by consequence, YC) would fail miserably if they chose purism and principle over pragmatism when it came to technology decisions.

erik_seaberg 5y ago

With Arc and HN and now Bel, I think pg is still exploring what a system could look like without major compromises to accommodate the limits of today’s hardware. For example, the first cut at pagination put something like a continuation ID into a URL, which only worked until that continuation was GC’d or the one and only server process got bounced. If you wanted a highly scalable HN and nothing more, you’d let Postgres or some graph database do the heavy lifting, add a Racket or Clojure frontend, and call it a day. But that’s pretty boring plumbing work, and doesn’t get you closer to the hundred-year language he’s aiming for.