Hacker News new | past | comments | ask | show | jobs | submit login

Replies to this top comment have been quite a job to juggle. My approach has been to reply and then detach them, so as to minimize distraction at the top of the thread. Unfortunately, that has led to the same questions being asked over and over, so I'm going to move all the replies underneath this stub, and then collapse it. The reason for a stub root comment rather than just collapsing all the replies is that a list of dozens of collapsed replies would take up most of the page.

I'm also going to partition them by topic, since there are so many.

If you want to reply about pagination, do so here.

If you're worrying about infinite scrolling, don't; we'd never.

Please don’t make it infinite scroll instead. Begging you. Please.

I believe the implementation is learning towards sticking all the comments on one page, but of course I'm not the one designing this ;)

Never. Be at peace.

I fully agree. Especially on a site that literally only has comments.

(We intend to get rid of pagination once the next implementation of Arc is ready.)

So you are adding endless-scroll? One of the Web UI things that the HN community regularly complain about on other sites?

Please make it optional. :)

> So you are adding endless-scroll?

Not necessarily. I seem to remember that HN used to be without pagination, all the comments were just listed on one page (without any JS to load more comments etc) but servers started to struggle when HN got more users which led to sometimes too many comments, so they added the pagination.

Somehow I associate this with the thread when Steve Jobs died, but not sure how accurate that is. My memory is kind of sucky.

What is endless about it? You’d assume there will be a finite amount of comments when you load the thread page, and the new implementation can just render that.

AI will generate new comments as you scroll... :)

As with many things in "modern" web development, "endless-scroll" is not really endless (as nothing is endless). It's a technique similar to how Facebook, Twitter and others continue to automatically load content when you reach the bottom, giving the impression of "endless" content. Of course, even Facebook and Twitter would eventually run out of content to show, but somehow that pattern got the name "endless scroll".

See also: isomorphic, real-time, serverless and countless others examples of poorly named concepts in web development.

I know the feature they alluded to, thanks for the explanation. Comments on a thread are finite at any moment in time though, you wouldn't find "related content" as you were scrolling a specific thread page on HN. That was my point.

I was very surprised when I first found out FB would run out content. I had assumed that it would just go further back in time, even if the feed was not strictly chronological.

Pardon me; nothing is further from my mind. See replies elsewhere in this subthread.

> We intend to get rid of pagination

Please don't. Or just make it optional. Infinite scrolling is evil.

Oh I certainly didn't mean HN would do infinite scrolling. That'd be gross, too complicated, and would contradict the old-web style of the site. But if we can just generate entire pages quickly enough, I don't see why we wouldn't go back to doing that.

Strong agree here. Infinite scrolling is painful. I would rather be given an ENTIRE page to scroll as I see fit.

Why would it be infinite? Just load all the comments at once! Show me everything.

Modern caching strategies mean it wouldn't be any database load or concerning computational overhead? I'm no expert on HN-scale sites though.

Anyway, my 2 cents is I'd prefer everything loaded at once, no pagination, no infinite scroll.

As a quick fix, can you add a hyperlink to the next pages at the top of the page [“Page 2”, “Page 3”], rather than just a single “More” hyperlink at the bottom of the page?

>We intend to get rid of pagination once the next implementation of Arc is ready.

Why? Pagination seems like a good idea for really long threads.

People frequently think that their comment has been deleted because it doesn't show up on the first page. We introduced it as a performance workaround, so if performance recovers, I'd rather stop. If rendering the whole page causes other trouble, we can reconsider the problem from scratch.

Why would pagination be a good idea? From my perspective, there's no downside (HN is exclusively text and fetching+rendering the entire first page of comments for this submission takes the same amount of time on my computer as rendering a no-comment submission) and several upsides (no need to open several tabs to see all comments, no need to make several more round trips and wait several more seconds per page of comments, no "attention cliff" where comments on the n+1th page are significantly less noticeable than those at the bottom of the nth page, allow pagination to be handled by user agent/browser instead of being enforced by server).

The downside is having to serve larger pages which consist primarily of content which will not be read. This site is running on some resource-limited hardware as I understand it, so limiting the maximum potential size of each page served means more pages can be served more quickly, especially if you just cache the first page of a thread (which is all most people will engage with) rather than the entire thread.

You're confusing cause and effect - most people only interact with the first page of comments because they're on the first page, and they don't want to click through. If you disable pagination, then suddenly far more people will read those comments that would be on the second page.

Additionally, request count matters more than data transferred. It's much easier to serve 1MB to each of 100 users than 1KB to each of 100K users. n people are already going to view the comment thread for a submission - a several-dozen-KB increase in the amount of data that you send each of them (assuming you're serving them statically) results in anywhere from "little" to "imperceptibly" additional CPU load.

This was my first interpretation (and question), too

I'm assuming that what he means is that they'll replace the need to click on a link with the 'infinite scrolling' that you see on Fb, etc.

If you want to reply about Arc, do so here.

> once the next implementation of Arc is ready

A nice example of how using the wrong programming language for your project impedes your progress/feature delivery.

Oh you guys. More an example of how using the perfect programming language for your project allows it to succeed, thrive, and eventually meet the challenges of growth :)

HN wouldn't exist without Arc, so it's pointless to argue about this. But I love talking about it so I'm going to anyway.

The feedback loops between the language, the HN software, and the living system of the community go very deep. I could write a lot about that. It's one of the most interesting things about the project, though unfortunately not visible. The software just works its Lispy magic behind the scenes, remaining small and malleable. It's still only 15k lines of code, including the language implementation, and that code does a lot.

On performance, it's pretty cool that Arc has managed to run HN through 12+ years of growth without much optimization. It's a good sign, not a bad one, that we're only doing major rework for performance reasons now. HN is far from Reddit-scale, but still: the application runs on a single core. (Though we do cache pages for logged-out users and serve those from an Nginx front end.)

As long as we're on the topic, consider this: 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.

I'm not saying that everyone should use Arc—language/programmer fit is a key part of language/project fit. But when all three variables align, incredible things become possible. Not only HN, but YC would not exist without Arc. Another case that came up recently was Cloudflare; very different language, project, and programmer, but a similar story (https://news.ycombinator.com/item?id=22883548).

I appreciate you taking the time to reply to this, but come on, “YC would not exist without Arc” is a definite exaggeration. YC’s impact as a platform is immeasurable, but the software is quite simple that could be coded in any other programming language just as well (I’d argue better since users wouldn’t be waiting now for new features to land if it weren’t for the language update).

You can write any program in any Turing-complete language, so that's obviously not my point.

Rather, it's that there's a deep interdependency between the three variables of language, programmer, and problem that give rise to a system like HN+YC (which was a single program until 2014). If you changed any one of those variables you'd either have gotten something radically different or nothing at all. So my statement is a bit like saying that YC would not exist without PG; and your objection is a bit like saying: that's an exaggeration, any person who did the same steps at the same time could have arrived at the same place (and perhaps better since that person might have been a better manager as well).

(Not only PG built YC, of course! But PG wrote the software and that was a critical piece.)

I'm not saying that all programs have this property about programming languages—rather, that some do, and they tend to be particularly interesting and creative. For another example, one might say that Unix would not exist without C.

There would be more interesting and creative systems in the world if we were more open as a community to these unexplored spaces. We exclude them in order to have the feeling that we know what we're doing, and we reinforce this by ridiculing and dismissing deviants. The social dynamics that exclude new creative possibilities are incredibly strong, which is one reason why when systems like this do end up succeeding, they tend to be the work of loners, weirdos, or people who have some strange mutation to withstand social pressure. (This by the way is the origin of the "$weird-language is only good for solo programmers" meme, ironically confusing cause and effect.) No doubt other fields work the same way; software is just the one I know well enough for the mechanisms to be obvious to me.

An analogy just occurred to me, which I want to note so I don't forget it. The relationship between a program and the language it's written in is like the relationship between a piece of music and the instrument it was composed for. To say "this system could have been built in some other language" is like saying "this music could have been composed for some other instrument". That may technically be true; music gets transcribed for other instruments all the time, just as programs get ported to other languages. But it misses the most important thing: the creative process by which the music or program got written in the first place.

There are intimate feedback loops between the mind of the composer, the developing music, and the design of the instrument—which possibilities it makes natural/easy vs. which it discourages/excludes. Every instrument and every programming language has a different set of these. They may not differ in what can theoretically be played on them, but they differ immensely in how they organize the space of possibilities—which ones are near at hand vs. out of reach. You can play the same scales on the piano, the cello, and the guitar, but where the mind goes next as it composes a new sequence of notes—not a scale, but a sequence that has never existed before—is deeply conditioned by the instrument it's working with, which is the medium it's growing in. Some next-notes are far more likely than others, and which next-notes those are differs greatly between instruments. In the same way, a program grows by accruing constructs (expressions, statements, forms, types), and the ones that are most likely to get added next are the ones that are most natural and nearest-to-mind, given the program so far. Which next-constructs those are differs greatly between languages.

Since each next-note or next-construct is deeply conditioned by the sequence it's adding to, this effect compounds as the system grows. It follows that, at least for the most interesting and creative systems, a program is literally unthinkable apart from the language it grows in. So much for "languages don't matter"—yet how often that untrue truism is repeated! The reason for this fallacy is that we take a program as if it existed prior to being written, which is impossible.

So when I say HN/YC would not exist without Arc (or Lisp really), I mean it in the sense that https://www.youtube.com/watch?v=rGgG-0lOJjk#t=14 would not exist without the cello even though https://www.youtube.com/watch?v=mhfxM5FOzjQ#t=3 is a thing, https://www.youtube.com/watch?v=x6GZ6xeGnJQ#t=15m would not exist without the piano even though https://www.youtube.com/watch?v=XXGCfW-cGoE#t=91 is a thing, and https://www.youtube.com/watch?v=skdE0KAFCEA would not exist without the electric guitar even though https://www.youtube.com/watch?v=kNFpOh2seqo is a thing.

Seems to me, he's an insider who is in the know and he's made an effort to explain why he sees it that way:

As long as we're on the topic, consider this: 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.

I mean, you don't have to agree, but his opinion is probably more informed on the topic than yours is.

Maybe. And maybe it's just a simple, single category message board :)

Or maybe, because you need a handle here to apply for YC to begin with (or did the last time I looked), it's part of their funnel and business model.

And maybe, because they launch YC companies here and let them advertise job openings here, it's part of their business model.

I'm trying to write this in a way that does not come across as sarcastic or ungracious, but does it strike anyone else as odd that this change blocks on the next version of the underlying programming language?

Given that both the language and the forum are developed in tandem, and are linked to the degree that they ship together, it wouldn't be surprising that changes in Arc would be made specifically with the forum in mind.

Given that this is, to the best of my understanding, one of if not the only things Arc is doing.


It probably could be done in the current version, just not done well.

Are there some relevant limitations in the current implementation of Arc? Also, numbered pages would be quite useful as well.

Just performance limitations. The two implementations should be identical otherwise.

What would numbered pages look like?

> What would numbered pages look like?

e.g. "1 2 3 4 ... 10" links or something like that instead of a single "More".

Also when we save a page the number is in the title.

That's interesting, mind elaborating on this? How is the next version of Arc going to help with pagination? Is this a memory limit thing?

It's a speed thing, but related to memory pressure because if we use too much memory then the GC uses too much CPU.

Is Arc open source?

The language, yes[0], but AFAIK the maintainers don't take pull requests.

Arc has a public fork called Anarki[1], which is built on Racket[2]. The Anarki version of the forum differs from the Arc forum, which differs from HN's own custom instance, which is closed because of various YCombinator business reasons.




And to be a little more specific (because I really like Arc), the releases are very rare, and minor at this point. I would be surprised if the Arc that was running HN was the latest released version of Arc, the news library notwithstanding.

For example, the latest release, Arc3.2, came out in 2018, and was relatively minor (http://arclanguage.org/item?id=20772). Arc 3.1 was released in 2009 (http://arclanguage.org/item?id=10254).

next implementation of Arc

Are there any details about this anywhere? What's it written in?

Will the next implementation of Arc also include the ability to delete posts and comments?

Surely there might be some portion of the 1,200 people who posted today that may want to delete their submission in the future.

Allowing them to do so would be civil don’t you think?

(There may also be those who figured out there is a risk here and just avoid sharing anything anymore, but that’s another story).

Your many posts and emails about this are beginning to resemble harassment. We've given you many lengthy explanations and I've deleted dozens of posts at your request. I've spent hours engaging with you about this, answering questions and objections and explaining HN's approach in deep detail.

As I've explained many times in these conversations, we're happy to delete specific posts and to redact identifying information. What we don't allow is wholesale deletion of account history. You disagree with that—you've said so dozens of times—and this has now become repetitive and your behavior has become abusive. Actually, it became abusive months ago, including with surprisingly vicious comments in email. We try give people the benefit of the doubt and cut them slack for as long as we can, but I don't see what else to do at this point but ban your account and ask you to stop.

So the person with all the power, the one who speaks in plural about what he allows is suddenly some how the victim?

Please just delete all my comments. Including this one.

It's time to stop.

If you want to reply about comment sorting and ordering, do so here.

Question - is this at the top because you've pinned it there, or because people voted it so? I've been around here for 6-ish years now, and don't think I've seen any pinned mod comments before.

I pinned it. I usually do that for more boring reasons, like linking to a previous submission when an item is a dupe. But sometimes there are admonitions like https://news.ycombinator.com/item?id=23158853 from a couple days ago, and https://news.ycombinator.com/item?id=22827249 from a month ago, that try to steer a thread in a more guidelinesy direction. That works. But I try to do it sparingly.

I follow Dang's comments because I find it interesting how he moderates the site. I have definitely seen comments like this one which always appear at the top of threads, so I'm quite sure they're pinned.

This is absolutely pinned. I prefer to imagine that since we haven't noticed such comments on the regular means this power is not habitually abused to float a particular opinion/angle to the top of threads. That policy is not guaranteed to be enforced, so I'd prefer a visible indication (eg. via an icon, akin to Reddit) indicating the comment has been pinned. Transparency for the win.

Of course, a truly Evil™ company would have both options available: a visible icon for transparently pinned comments, but also the ability to invisibly pin a comment to influence readers. There is no real foolproof method, unfortunately.

I don't know if pinning is even necessarily a chief tactic as I presume they're also able to arbitrarily modify a comment's votes, or at least to overlook manipulation of votes from an entity they've given agency to.

All pretty cynical, though.

Seems like a public announcement. Don't see any problem with pinning it to the top.

I'm quite sure thare's pinning functionality in HN, it just that HN doesn't mark it like reddit does.

Why there is no sort by rating like on Reddit? I’d prefer reading top comments, not random of 1600

To be honest I don't know there's a reason why, beyond not having thought about it much. I'll add it to the list to think about.

Is it possible to add some basic sort options for comments - latest and top score?

The problem with "by top score" is it would itself influence the scoring, even if only some people used it. The oldest comments would stay at the top of such a list, because they get seen more and thus have more opportunities for upvotes, creating a self-sustaining cycle. You always need a time counterweight.

That would be nice. And also a way to wrap all comments that are replies to first-level comments so that we can see all these and only reaf discussions on projects that interest us.

What do you mean by 'wrap'?

Sorry, it may not be the right word. I mean the effect that clicking on the little "[-]" does. A way to automatically clic this for all second-level comments, so that only first-level comments that directly answer the "Ask HN" appear.

Got it. I think this would be useful. But where in the UI would we put all these options? This is my main concern.

If you find a place for comments sorting options (what my parent comment initially suggested), it could go there too (it's also related to comments display settings).

Maybe a line between the "add comment" button and the first displayed comment?

Have made a site out of links collected from this page. Check it out https://born-out-of-covid.f22labs.com/

Planning to add sorting and voting (If this interests people)

It's on the list to consider.

Let me know if you like the site, we can put it out in a proper domain and add submissions, sorting etc.

I struggled with whether this point is closest to pagination or sorting/ordering and ultimately chose here.

Is there any chance to get client-side thread collapsing?

Use case: suppose I'm interested in reading about side projects and not pagination or I'm "done" reading about side project X and want to get on to side project Y. If I could click to collapse the entire pagination thread (client-side only) and then later collapse project X's thread, that would represent an improvement in experience on this thread. (It's less clear that this applies generally to topics with 50 comments, but over 250, it could help.)

Sorting by new might be nice also, in comments, for this type of thread.

That's a great idea. I don't even think it's on our list. I'll add it.

We have an experimental feature to highlight new comments if you or anyone wants to give it a try - email hn@ycombinator.com. But you'll still have to scroll through the pages to find the new ones.

That feature would be useful on the user's personal 'threads' page to respond to new comments, I'll email you!

It doesn't work on 'threads' yet but it will.

Consider whether we might be better off without that feature, which also makes it super easy to keep aging threads alive, which is something HN has subtly discouraged thus far.

I've definitely been considering it, but it's also the most-requested feature by the people who've been using the highlighting so far. I think as long as we make it relatively passive, i.e. you still have to scroll to see the new things, it might not be too much of an unwanted catalyst.

Worst case, if it did turn out to have a major negative effect, I hope (I pray?) we would have enough killer instinct to claw it back.

Hi dang, Honestly I don't know how to say this other than I am so thankful that you take your job so seriously.

I can honestly say that I've never seen you act on HN other than in a positive way, and reading your contributions is part of the delight of visiting this site =)...

Sorry, it's just I can think of so few other sites where my first thought on seeing a mod post is not, "Oh what happened now..." and I just wanted to thank you for all the effort that you put in.


Hey Dang, another side project born right from this post. I've listed all possible links from this post across pages and listed down here. https://born-out-of-covid.f22labs.com/

Let me know your thoughts, will add more details and links after i wake up tomorrow.

Stay safe everyone.

Nice! That could form the basis for a future thread. (One observation in case it's helpful: I'm seeing lots of duplicates on that page.)

Edit: while I have you: you've posted several links to that already, plus you posted 10 of these: https://news.ycombinator.com/item?id=23189273. That's not allowed on HN—users consider it spamming—so please don't. It's of course ok to link occasionally to your own work when it's relevant, but not to use HN threads aggressively for promotion. The idea is always conversation, and one can't have a conversation with a commercial.

Gotcha! Will converse more. Thanks for your observation. Will fix the duplication

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact