(We intend to get rid of pagination once the next implementation of Arc is ready.)
What should it be called? What day should it go out?
The list of bi-weekly paychecks for 2020 is here: https://www.nfc.usda.gov/Publications/Forms/1217n_20.pdf
Meaning that June's thread should be on the 20th. July on the 18th. August on the 15th. September on the 12th. October on the 10th.
So, people who start working on something new at the beginning of the month are ready to talk about their projects
I'm also going to partition them by topic, since there are so many.
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.
Let me know your thoughts, will add more details and links after i wake up tomorrow.
Stay safe everyone.
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.
If you're worrying about infinite scrolling, don't; we'd never.
Why? Pagination seems like a good idea for really long threads.
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.
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.
Please don't. Or just make it optional. Infinite scrolling is evil.
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.
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. :)
See also: isomorphic, real-time, serverless and countless others examples of poorly named concepts in web development.
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 would numbered pages look like?
e.g. "1 2 3 4 ... 10" links or something like that instead of a single "More".
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).
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.
Please just delete all my comments. Including this one.
A nice example of how using the wrong programming language for your project impedes your progress/feature delivery.
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).
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.
And maybe, because they launch YC companies here and let them advertise job openings here, it's part of their business model.
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.)
Not all programs have this property about the language they're written in—but 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 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 possibilities are 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.
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 important thing: the 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 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 related to, which is the medium it's growing in. Some next-notes are more likely than others, and which next-notes those are differs 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 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.
Are there any details about this anywhere? What's it written in?
No.
It probably could be done in the current version, just not done well.
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.
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).
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.
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.
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.
All pretty cynical, though.
Maybe a line between the "add comment" button and the first displayed comment?
Planning to add sorting and voting (If this interests people)
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.)