Natural counting isn't 1-indexed. You usually count things after you tally them, not before. (You don't start counting beans by saying "one bean" and then waiting for that bean to arrive.)
Besides, it is not all that clear if someone just says "Jan 1 marks year one" whether it marks the end of the first year or the beginning. With dates, it usually marks the beginning. That's why it is 1-indexed. We hardly count anything else that way, so why would you assume it is 'natural counting'?
>It's sad that 538 has turned into a pop-stats site that runs on volume and snappy headlines.
It's our fault, they're catering to our demands. You can't run a media company any other way. No one wants to read read (although I'd bet on average everyone spends far more time reading). So you get wham-bam, buzzfeed-esque content. Even on HN, long form articles will inevitably be met in the comment section with a "tl;dr?".
There's nothing wrong with asking for a tl;dr when you're trying to find out if the long form is worth your time. (Most are not.) In academics, the tl;dr is called the abstract, and it would be silly to think that they should be eliminated because people ought to just read everything.
Any "feature" that encourages people to spend more energy thinking about the reasons for being down voted is just promoting whinging and self-absorbed discontent. (Which, a: no one wants to see, and b: is bad for the people going through it!)
I do feel that down votes should not be used for disagreement, but the practical matter of fact is that they are and will be, both because pg endorses the idea, and because people are people. If they have a negative response to reading something, and a down arrow is convenient, it will be used.
Downvotes are not punishment. They just mean someone didn't like what you wrote, but couldn't be arsed to respond. Maybe what you wrote didn't deserve a response, maybe they were confused, maybe the topic is incredibly important to you but not to them. Who cares? We're adults, ja?
As an alternative, I wouldn't be disappointed if the threshold for greying out was reduced to -3 or so. And full death at -10?
And for new users who might not know why they're being downvoted, how about a link to the rules next to any comment of yours that is score-negative? HN already puts an orange star next to your comments, so the pages are dynamic at least to that extent.
Personally, I use downvotes exclusively for hostility. I upvote any greyed comment that is respectful, coherent, and relevant.
I agree with that part, but disagree with the proposed solution, completely.
I suggested an idea to inform new users in a post upthread (link to guidelines next to any comment of yours that is score-negative), but it would probably be better to link to a page with the guidelines plus a blurb about accidents, confusion, and just not taking it too seriously.
Tone policing disenfranchises minority views, period. Doesn't matter whether the context is social justice or database performance; Unless the tone is beyond well-known bounds (e.g. is abusive, flippant, way off-topic, etc.) I don't think it is generally constructive.
Edit: I think we're talking past each other on where "tone policing" becomes regular old moderation.
>As an alternative, I wouldn't be disappointed if the threshold for greying out was reduced to -3 or so. And full death at -10?
I think this would go a long way toward resolving people's negative attitudes toward downvotes. The fact that one errant idiot could grey out your post and make it harder for others to read is a bit too far IMO.
While I was reading the thread, this comment just posted mentioned that the site founder, pg, has endorsed the idea that the site's rules permit downvoting to express disagreement. By the site rules, implicitly, some comments should be downvoted on sight.
"Essentially there are two rules here: don't post or upvote crap links, and don't be rude or dumb in comment threads."
Yes, downvote thoughtfully, and downvote to improve the overall quality of discussion here, but a downvote in an active discussion to silently indicate a comment is 1) uncivil and unconstructive, or 2) factually incorrect, or 3) both is okay.
A comment that is solely on the issue of being downvoted is subject to being downvoted on sight, because those sorts of comments are never constructive to the discussion and disfavored by the site guidelines.
"Resist complaining about being downmodded. It never does any good, and it makes boring reading."
The site founder, pg, (who no longer has an active day-by-day role in moderating the site) has commented that downvotes for disagreement are permitted here.
(In order of time of posting.)
"I think it's ok to use the up and down arrows to express agreement. Obviously the uparrows aren't only for applauding politeness, so it seems reasonable that the downarrows aren't only for booing rudeness."
"If there's one thing I wish I could do to improve HN, it would be to detect this sort of middlebrow dismissal algorithmically.
. . . .
"The problem with the middlebrow dismissal is that it's a magnet for upvotes. The 'U R a fag's get downvoted and end up at the bottom of the page where they cause little trouble. But this sort of comment rises to the top. Things have now gotten to the stage where I flinch slightly as I click on the 'comments' link, bracing myself for the dismissive comment I know will be waiting for me at the top of the page."
This is an ongoing issue, but the key idea is both to upvote and to downvote (and, for that matter, to submit stories and to post comments) in way that elevates the quality of discussion here. Grow a thick enough skin to learn from other users' behavior here, and develop curiosity about why other users might disagree with you, and all will be well.
Continuations are "easy" (if you have decent language support or can glom it on) but that's keeping state on the server side. The author describes continuation tokens that "never expire", which is incompatible with server-side state.
Without state, a token can be a bookmark into a predefined ordered dataset. That's more reliable than an offset, but just as inflexible, and much more expensive on the server side.
One thing to note is that while the continuation token is just a blob of data from the clients perspective, the server can actually use it to store the required state information.
A simple method would be to take the state information the server needs in order to continue the enumeration (e.g. sorting order, how far along it was in the enumeration, etc.), JSON-encode it, encrypt&sign it, and then base64 encode it.
Return that token to the client, and if the client wants more data it can pass that token back to the server, which can decode it into all the information it needs to resume the enumeration.
I like this approach, but this requires storing the rest of the enumeration. I think that you would want to the continuation token to expire after a reasonable period of time (10 minutes to 1 hour). When the token expired, you would remove the rest of the enumeration from your data store.
This isn't what the author recommends, but I think this is a good approach.
To ensure that it is easy to resume the enumeration, the API can fudge the number of returned items so that the returned data always breaks at a nice "post_time" boundary. The goal here is to make it easy for the client to get all the data in the enumeration without implementing all this logic themselves.
True, it will only work efficiently for some types of queries, but a lot of the common queries can be reworked into something like that.
You suggest that the continuation token, is basically an encoding of the query parameters, to fetch results from the API. If you go with this approach, then you don't have to store any state on the server. This is a good approach, because it's simple, but it doesn't solve the issue, where the response from the API changes while you making the paging API calls. The example used in the article is where an order was deleted, while you were calling the API.
I was thinking of using a uuid to generate a continuation token, and storing a copy of the results from the API. Subsequent calls that use the continuation token, would take a subset of these results. This requires storing more state on the server, and managing that state. The benefit to this approach is that results you get back from paging are consistent. This solves the issue, where the results from the API change while you are calling the API multiple times. The downside to this approach is that you have to store more state in server. If you are storing the full results for all of these paging API calls, then this could be quite large.
Actually, deleted orders are not a problem with continuation tokens. The deleted order is only an issue if you use traditional paging requests, which was the point of the article.
The only case I can currently think of that cannot be solved using continuation tokens sent to the client is where the order of the items that are enumerated may change between calls to the API. For example, imagine that you are fetching items sorted by score, and somebody upvotes or downvotes an item while you are enumerating them. In that case it is very difficult to encode enough information in the continuation token. (I can think of complicated ways to make it work, but the resulting database queries would be horrible.)
But for simple stuff like deleted items and similar, it is easy. If you leave out sorting it is trivial to implement as well -- all you need is to enumerate the items based on an internal ID that is guaranteed to always increase, filtering them as required. The continuation token will simply be the ID of the last item you evaluated and the filter that is applied. On the next request you just resume from that ID. If that item ID happens to be deleted in the meantime it is no problem. You just resume from the next one available. I.e.:
SELECT * FROM items WHERE id > :last_returned_id AND [insert-filter-here] ORDER BY id LIMIT 100;